Development record
The fidelity review request's delivered line still leaves the diff range to the host: auditPromptBody in internal/core/intent/audit.go writes 'the diff/commit range that realised ALL of spc-… (host supplies the range)', and an orchestrator hand-composes the base-to-merge range into the auditor's brief. This is the third addendum of iss-2609181121301638, left open when that record's scope-condition identities and criterion count were fixed, because it needs a design call the other two did not: the range is knowable from the specs' close commits and the merge commit, but a value read from git inside the hashed prompt body breaks the ingest's byte-for-byte prompt_hash recomputation unless the emit pins it (in the receipt marker, say), while a range stated outside the prompt, beside the Routing section, is unattested. Wanted: the request states the delivered range, attested or plainly marked as not.
The fidelity review request's delivered line still leaves the diff range to the host: auditPromptBody in internal/core/intent/audit.go writes 'the diff/commit range that realised ALL of spc-… (host supplies the range)', and an orchestrator hand-composes the base-to-merge range into the auditor's brief. This is the third addendum of iss-2609181121301638, left open when that record's scope-condition identities and criterion count were fixed, because it needs a design call the other two did not: the range is knowable from the specs' close commits and the merge commit, but a value read from git inside the hashed prompt body breaks the ingest's byte-for-byte prompt_hash recomputation unless the emit pins it (in the receipt marker, say), while a range stated outside the prompt, beside the Routing section, is unattested. Wanted: the request states the delivered range, attested or plainly marked as not.
Remedy grounds (2026-09-29)
- The three options are the ones ruling AQ lists; the remedy states the change and the proof for each and picks none, since the ruling is the technical facilitator's.
- Rejected: writing the git-read range inside the hashed prompt body, which breaks the byte-for-byte prompt_hash recomputation the record names.
Frontmatter
| id | iss-2609262011091645 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2609262011091645-the-fidelity-review-request-s-delivered.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2609181121301638The fidelity review request lists the acceptance criteria but never the scope-condition identities the verdict must dispose. auditPromptBody in internal/core/intent/audit.go writes an Acceptance Criteria block numbered ac-1..ac-K and the rubric, while the verdict schema (verdictCondition, keyed on condition_id) and the intent-auditor contract require scope_conditions to cover the intent's conditions exactly, one disposition per cond-… identity; the identities reach the auditor only as HTML comments in the intent record that the request does not quote. Relayed from the Gropius managed-repo session gropiusllm-56 on 2026-09-18 after seven fidelity audits at v0.9.0: the reviewer scraped the cond comments by hand, and a miscount quarantined the verdict at ingest. Wanted: the request carries a Scope Conditions block listing each cond-… identity with its text, as it carries the criteria, so the auditor disposes exactly the set the ingest will check. The prompt body is hashed for provenance, so the block is part of the pure composition and the prompt_hash policy version moves with it.