Development record
The fidelity review request carries no verdict-JSON schema and names no place to read one. auditPromptBody ends with "Run the intent-auditor agent over the criteria and the delivered diff, then ingest its verdict JSON", and abcd intent audit ingest --help documents a single flag; the concrete verdict shape (verdict enum, scope_conditions with condition_id and disposition, the two sha256 provenance fields) lives only in the bundled intent-auditor agent definition. A host without that agent, or a reviewer working from the request alone, has nothing to write against and learns the shape from ingest refusals. Relayed from the Gropius managed-repo session gropiusllm-56 on 2026-09-18 after seven fidelity audits at v0.9.0. Wanted, either: the request quotes the verdict shape beside the rubric, or a read-only abcd intent audit schema verb prints it, and the ingest help points at whichever exists. Filed apart from the scope-condition identities finding because the remedies differ: that one is about which items the verdict must cover, this one about the shape it must take.
The fidelity review request carries no verdict-JSON schema and names no place to read one. auditPromptBody ends with "Run the intent-auditor agent over the criteria and the delivered diff, then ingest its verdict JSON", and abcd intent audit ingest --help documents a single flag; the concrete verdict shape (verdict enum, scope_conditions with condition_id and disposition, the two sha256 provenance fields) lives only in the bundled intent-auditor agent definition. A host without that agent, or a reviewer working from the request alone, has nothing to write against and learns the shape from ingest refusals. Relayed from the Gropius managed-repo session gropiusllm-56 on 2026-09-18 after seven fidelity audits at v0.9.0. Wanted, either: the request quotes the verdict shape beside the rubric, or a read-only abcd intent audit schema verb prints it, and the ingest help points at whichever exists. Filed apart from the scope-condition identities finding because the remedies differ: that one is about which items the verdict must cover, this one about the shape it must take.
Addendum (2026-09-19, Gropius session gropiusllm-66, relayed to abcd-17).
The missing schema has a second cost: with no --verdict-json dry-run
validator, every lane in a forty-lane sweep rewrote the same pre-ingest
checker. A validate-only mode on the ingest (parse and shape-check, write
nothing, exit as the ingest would) is the same remedy family as printing the
shape, and either one retires the hand-written checkers.
Grounds
- pursued: a reviewer working from the request alone writes a verdict the ingest decodes; a field on the verdict struct absent from the stated shape, or a stated field the ingest refuses as unknown, would show it wrong
Frontmatter
| id | iss-2609181121305984 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609181121305984-the-fidelity-review-request-carries-no.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2609262011046013The consistency review request carries no findings-JSON shape and names no place to read one. consistencyPromptBody in internal/core/intent/consistency.go states the five classes and the rubric, while the findings shape (_type, receipt_id, verifier, policy, and findings carrying class, severity, summary, explanation and two ends of path and quote) is published only in the Role 2 section of agents/intent-auditor.md, so a reviewer working from the request alone learns the shape from ingest refusals. It is the Role 2 sibling of iss-2609181121305984 on the fidelity review request, confirmed while fixing that record; the same remedy applies: the request states the shape rendered from the struct the ingest decodes, never a second copy.