[aviggiano]

Summary

• fixes Property fan-in requires a ledger_ids field on every canonical property, but the schema and prompt both make it conditional #297
• confirmed from live artifacts; it has cost two consecutive Aave v4 runs a full property-specification-fanin attempt
• three components disagreed about whether ledger_ids is conditional, and the gate was the outlier

The failure

R45 (18:46:01Z) and R46 (~20:05Z) both failed fan-in with a long list of:

Properties Markdown must preserve canonical property "property-1" with its description, category,
priority, and sources (missing "ledger_ids")

Both passed on a retry, so the pipeline survives — at the cost of a wasted agentic node attempt each time and a coin flip on a node every run must pass.

The measurement that settles it

Read from R46's own fan-in artifacts on the volume:

	count
canonical properties in properties.json	219
of those, with a non-empty ledger_ids	78
blocks in properties.md	219
occurrences of ledger_ids in properties.md	78

The model rendered the field for exactly the properties that have one. That is what it was told to do (property-specification-fanin.md:86 — "add a ledger_ids array to every canonical property that represents one or more ledger entries") and what the schema allows (canonicalPropertySchema.ledger_ids is .optional()).

The gate never consulted property.ledger_ids:

const missingLedgerField = block !== undefined && ledgerFieldValues.length !== 1;

So all 141 properties with no ledger mapping were rejected for omitting a field the schema calls optional and the prompt does not ask for.

The fix

const expectsLedgerField = (property.ledger_ids ?? []).length > 0;
const missingLedgerField = block !== undefined && expectsLedgerField && ledgerFieldValues.length !== 1;

Nothing is weakened. Once a property does have ledger IDs, the checks below still enforce that each one is rendered, the right number of times, with no extras — and a regression pins that half explicitly so this cannot be read as dropping ledger parity.

Both my tests were green for the wrong reason first

Worth stating, because the exit status lied: the fixtures omitted the project-discovery evidence ledger, so the gate short-circuited on INVARIANT_LEDGER_MISSING before reaching any parity code, and the "does not demand" test passed against unfixed source. This is the same trap a reviewer caught in #290, and I only found it by reading the diagnostics rather than the pass count. With the ledger supplied, the red state reproduces R46's message verbatim.

Validation

• new regression proven red before the fix, with the production message
• companion regression pins that a property WITH ledger IDs must still render the field
• artifact-gates.test.ts 48 pass / 0 fail
• verified this rule has a single implementation — no generated-template twin, unlike Invariant scan probes are validated as regular files, so a directory probe fails project-discovery #289
• typecheck, eslint, prettier, git diff --check clean; full monorepo suite running

Why this keeps happening

Fifth defect of the same family: a gate enforcing something stricter than the prompt asks and the schema declares. #289 (directory scan probes), #291 (prompt silent on directory probes), #293 (identifier shape), #292 (unfalsifiable probe text), and now this. Individually small; together they are why no run has yet reached report.md. Worth someone auditing the gate/prompt/schema triple systematically rather than one live failure at a time.

Greptile Summary

The PR aligns the property fan-in artifact gate with the optional ledger_ids schema contract, requiring the Markdown field only for canonical properties that contain ledger IDs.

• Conditions the field-presence check on a non-empty canonical ledger_ids array.
• Adds regressions covering properties both without and with ledger IDs.

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness or security issues identified.

The conditional requirement matches the optional canonical field, while existing parity checks continue rejecting missing or extra ledger mappings for properties that contain ledger IDs.

Important Files Changed

Filename	Overview
packages/runtime/src/artifact-gates.ts	Correctly narrows the ledger field-presence requirement while retaining existing missing, extra, and duplicate ID parity checks.
packages/runtime/test/artifact-gates.test.ts	Adds focused fixtures that reach the parity gate and verify both optional-field acceptance and required-field rejection.

_{Reviews (1): Last reviewed commit: "fix(runtime): require a ledger_ids field..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Runtime: Run Orchestration Lifecycle

[aviggiano]

Full monorepo suite green on 052f54e: 442 tests / 428 pass / 0 fail / 14 skipped, EXIT=0.

Deliberately not relaunching a run for this one. R47 launched at 20:06Z from d78fe3a and R46 is at stateful-invariant-setup; this defect costs a wasted fan-in attempt but retries have recovered from it in both runs that hit it, so a third ~$400 run to pick it up would buy very little. It lands for whatever comes next.

[aviggiano]

Both reviews: merge, no blocking findings

Both reviewers attacked the coverage question directly and both landed in the same place: the "every ledger entry is mapped" guarantee never lived in the check this PR relaxes. It lives at artifact-gates.ts:477-488 (INVARIANT_LEDGER_REFERENCE_MISSING), a JSON-level check in the entry direction that runs before markdown is opened. The relaxed check is a markdown-level check in the property direction. Orthogonal.

The adversarial reviewer built seven fixtures and ran them against both origin/main and this head:

fixture	scenario	result on this head
ledger entries with zero properties referencing them, ledger_ids omitted everywhere	the feared regression	rejected — INVARIANT_LEDGER_REFERENCE_MISSING ×2
2 entries, only 1 mapped	partial coverage	rejected
property has ["ev-1","ev-2"], markdown renders only ev-1	under-render	rejected — MAPPING_MISSING
property has IDs, markdown has two ledger_ids: lines	arity	rejected
property has no IDs, markdown invents one	forged mapping	rejected — MAPPING_EXTRA
"ledger_ids": [] in JSON	empty list	rejected — PROPERTIES_SCHEMA_INVALID

No fixture changed pass/fail between main and this head. The unconditional demand was duplicate noise layered on checks that already fire.

That also answers the [] question: minItems: 1 / .min(1) means an empty array cannot reach the code at all, so (property.ledger_ids ?? []).length > 0 is exactly equivalent to !== undefined post-validation — defensive, not wrong.

Mutation testing killed both mutants, one test each: forcing expectsLedgerField true (≡ main) fails only the "does not demand" test; forcing it false fails only the "still requires" test. Neither survives, and no other test constrains the line in either direction. One reviewer noted the companion test adds coverage that did not previously exist — before this PR nothing pinned the "exactly one ledger_ids field" rule even for properties that do have IDs.

On whether R46's 141 unmapped properties are themselves the defect: no. R46 passed fan-in on retry, which means INVARIANT_LEDGER_REFERENCE_MISSING was satisfied — every ledger entry was covered by the 78 mapped properties. The other 141 are lens-derived properties with no doc-ledger backing, which is legitimate.

The one finding, filed not bundled → #299

Both reviewers flagged that the prompt still reads unconditionally at :93-94 ("include its complete ledger_ids list in that block"), and a fixture confirms a model obeying that literally is rejected with MAPPING_EXTRA — the mirror image of this bug, still live. It is a one-clause prompt change, but changing a prompt changes model output, so it belongs between runs rather than in a gate fix on the critical path of a live investigation. Filed as #299, with a suggestion to land it together with #291 as one prompt-clarity change.

Not acting on the - ledger_ids: none variant a reviewer raised as SUSPECTED: there is no evidence any model emits it, and adding speculative spellings to the filter is the whack-a-mole this series of fixes has been trying to stop.

Validation

• artifact-gates 48/48; monorepo 442 / 428 pass / 0 fail / 14 skipped
• every release-gates step reproduced locally
• Greptile, semgrep and both Socket checks green

Merging with the same recorded deviation as #284, #290, #294 and #296: hosted runners are still evicting queued jobs, so release-gates never ran on CI.

One environment note for future reviewers of this repo, found the hard way twice: in a fresh worktree without node_modules, bare npx tsc fetches a decoy package that prints "This is not the tsc command you are looking for", exits 0, and compiles nothing — so tsc && node --test yields a green run with zero tests executed. And artifact-gates.test.ts test 1 reads dist/topology.yml, a build output, so it fails in any worktree where pnpm build has not run.