Split out of vreko-dev/vreko#511 per META-93's own model. vreko-dev/vreko#511 is a finite remediation arc — it closes when generated.fileIndex is restored. This is the permanent counter that arc should have produced and never had: it does not close, ever, and folding it into a bug ticket means the moment vreko-dev/vreko#511 goes Done, the ratchet has no issue, no owner, and no counter — in four months nobody knows it exists until it fails silently and someone deletes it as dead code.
The instrument
apps/local-service/test/integration/gsd-plugin-consumer-contract.test.ts (vreko-dev/vreko#508/vreko-dev/vreko#511) is the actual gate: it generates .agents/workspace.json from a real repo through the real runInitScan → WorkspaceJsonEmitter pipeline (no daemon, no checked-in fixture) and reads the emitted JSON. It currently checks two sites independently — the bootstrap path (fresh scan, no existing file) and the merge path (existing file present, mergeWorkspaceIntelligenceFromScan's own inline construction, which spreads ...existingGenerated before its own explicit field assignments and can therefore mask a broken assignment if a prior write already had the field correct). Both are separately red-proofed: deleting generated.fileIndex from either site independently fails exactly the test that covers that site, nothing else.
A second, cheaper static check exists in tests/architecture/invariants.test.ts ("fast static complement, not the real gate") — it greps the emitter source for field assignments. It is explicitly demoted: it cannot observe the emitted JSON (would pass if a field were assigned undefined or stripped by a later prune step), and its claim of "both places" is unfalsifiable — it cannot prove a third construction site doesn't exist uncovered. The behavioral test above is the one to trust if the two ever disagree.
Counter
counter.workspace_json_field_gap — count of fields declared required (non-optional) in @workspacejson/spec's published generated.* shape that are absent from a freshly-generated .agents/workspace.json, verified by running the real pipeline (not by reading source).
Value today: 0. (fileIndex and frameworkManifest — the two required fields — both present as of the vreko-dev/vreko#511 fix, dev f97781984 / phoenix c7275bde4.)
Job that computes it: apps/local-service/test/integration/gsd-plugin-consumer-contract.test.ts, run as part of @vreko/local-service's normal test suite (already wired into CI via the package's pnpm test).
What would make this fail in the future
- A new required field added to
@workspacejson/spec without the emitter being updated to write it (the forward-looking version of what happened here).
- A future refactor of either
assembleOutput() or mergeWorkspaceIntelligenceFromScan() that drops an existing required field — caught independently at either site per the red-proof above.
- A third construction site added later, if it isn't exercised by generating from a real repo — this is the coverage gap the static check cannot see and the behavioral test can only close by actually being run against every real write path. If a third site is ever added, this issue's scope grows to cover it (extend the fixture test, not add a new counter).
Non-goals
- Not tracking
manual.fragileFiles / manual.coChangePatterns — those are user-authored per the v0.3 schema, optional, and the emitter correctly does not fabricate them. Their absence is not a gap this counter measures.
- Not a general "does workspace.json have everything Jasper wants" tracker — scoped strictly to spec-declared-required-but-absent, the mechanically checkable claim.
Related
- vreko-dev/vreko#511 (the finite arc that produced this counter — closes independently of this issue)
- META-93 (portfolio governance model — this is filed as an Evidence Integrity studio-line instance per that model's own rules: "a blocker is not a blocker unless a job computes it")
- META-93 also names an "enumeration probe" as workspace.json's broader trust-surface work (
paths(scalars) against a live artifact + evidence source per path) — that is the more general instrument; this issue is the narrower, already-computable slice of it (required-field presence only), filed now because the job already exists and the counter is already real, not blocked on the broader probe landing.
Done condition
This issue has no done condition in the closing sense — it is a permanent ratchet. Its only state changes are: the counter goes non-zero (investigate immediately, do not let a red counter under other work quietly free the slot), or the instrument's scope grows to cover a newly discovered construction site.
Split out of vreko-dev/vreko#511 per META-93's own model. vreko-dev/vreko#511 is a finite remediation arc — it closes when
generated.fileIndexis restored. This is the permanent counter that arc should have produced and never had: it does not close, ever, and folding it into a bug ticket means the moment vreko-dev/vreko#511 goes Done, the ratchet has no issue, no owner, and no counter — in four months nobody knows it exists until it fails silently and someone deletes it as dead code.The instrument
apps/local-service/test/integration/gsd-plugin-consumer-contract.test.ts(vreko-dev/vreko#508/vreko-dev/vreko#511) is the actual gate: it generates.agents/workspace.jsonfrom a real repo through the realrunInitScan→WorkspaceJsonEmitterpipeline (no daemon, no checked-in fixture) and reads the emitted JSON. It currently checks two sites independently — the bootstrap path (fresh scan, no existing file) and the merge path (existing file present,mergeWorkspaceIntelligenceFromScan's own inline construction, which spreads...existingGeneratedbefore its own explicit field assignments and can therefore mask a broken assignment if a prior write already had the field correct). Both are separately red-proofed: deletinggenerated.fileIndexfrom either site independently fails exactly the test that covers that site, nothing else.A second, cheaper static check exists in
tests/architecture/invariants.test.ts("fast static complement, not the real gate") — it greps the emitter source for field assignments. It is explicitly demoted: it cannot observe the emitted JSON (would pass if a field were assignedundefinedor stripped by a later prune step), and its claim of "both places" is unfalsifiable — it cannot prove a third construction site doesn't exist uncovered. The behavioral test above is the one to trust if the two ever disagree.Counter
counter.workspace_json_field_gap— count of fields declared required (non-optional) in@workspacejson/spec's publishedgenerated.*shape that are absent from a freshly-generated.agents/workspace.json, verified by running the real pipeline (not by reading source).Value today: 0. (
fileIndexandframeworkManifest— the two required fields — both present as of the vreko-dev/vreko#511 fix,devf97781984/ phoenixc7275bde4.)Job that computes it:
apps/local-service/test/integration/gsd-plugin-consumer-contract.test.ts, run as part of@vreko/local-service's normal test suite (already wired into CI via the package'spnpm test).What would make this fail in the future
@workspacejson/specwithout the emitter being updated to write it (the forward-looking version of what happened here).assembleOutput()ormergeWorkspaceIntelligenceFromScan()that drops an existing required field — caught independently at either site per the red-proof above.Non-goals
manual.fragileFiles/manual.coChangePatterns— those are user-authored per the v0.3 schema, optional, and the emitter correctly does not fabricate them. Their absence is not a gap this counter measures.Related
paths(scalars)against a live artifact + evidence source per path) — that is the more general instrument; this issue is the narrower, already-computable slice of it (required-field presence only), filed now because the job already exists and the counter is already real, not blocked on the broader probe landing.Done condition
This issue has no done condition in the closing sense — it is a permanent ratchet. Its only state changes are: the counter goes non-zero (investigate immediately, do not let a red counter under other work quietly free the slot), or the instrument's scope grows to cover a newly discovered construction site.