Development record
spc-63's payload item shape disagrees with the shipped cold-reading definitions: the spec states items[] = {pattern_named, body} with body fields claim, candidate, characterization, why, while every definition under agents/ instructs a FLAT item carrying pattern plus the record schema's own body fields (claim_surfaced, candidate_id, characterisation, why_a_tension), which is also what issueschema.ReadingBodyFields declares and what capture.IngestReading writes. Building the verb to the spec's table would refuse every output the shipped instrument can produce.
spc-63's payload item shape disagrees with the shipped cold-reading definitions: the spec states items[] = {pattern_named, body} with body fields claim, candidate, characterization, why, while every definition under agents/ instructs a FLAT item carrying pattern plus the record schema's own body fields (claim_surfaced, candidate_id, characterisation, why_a_tension), which is also what issueschema.ReadingBodyFields declares and what capture.IngestReading writes. Building the verb to the spec's table would refuse every output the shipped instrument can produce.
Grounds
- pursued: one vocabulary reaches from the definition through the payload to the record, so no rename sits between producer and consumer; a definition instructing a key the ingest refuses would show this wrong
Frontmatter
| id | iss-2608311123267602 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2608311123267602-spc-63-s-payload-item-shape-disagrees.md
open on GitHub ↗ · commit history ↗
mentions1
- spc-63The cold-reading output contract: a strict per-position schema, a supply-regime gate, and a staged ingest that leaves evidence or nothing