family-wide diagnosis for anchored-but-unparseable typed records (non-PO kinds) #59

New issue

Open

opened 2026-08-24 17:13:33 +00:00 by jbr870 · 0 comments

jbr870 commented

2026-08-24 17:13:33 +00:00

Owner

Problem

Issue #57 gave phase-outcome records a full diagnosis path for anchored-but-unparseable comments: the post refuses to mint and reads exit non-zero, both naming the offending comment id, the unparseable element, and the operator repair route (_po_parse in _shared/procedures/bin/_lib.sh).

The other typed kinds never got the equivalent. A comment that is anchored as decision-resolution:v1 (or any non-PO kind) but whose JSON fence is truncated/unparseable still surfaces as a bare parser error naming no comment id — reproduced during #57 QA: a malformed decision-resolution:v1 record made decision-resolution-read-state.sh exit 5 with a raw jq: error (at <stdin>:...) and no pointer to the comment. Other consumers (deliverable-get.sh, fold/unfold, candidates) either die the same way or silently skip the record via fromjson?.

schemas/README.md's family-wide "three disjoint outcomes" rule was scoped to match shipped behavior as part of #57 QA (outcome 2's refusal-with-diagnosis is normative family-wide as a goal, implemented today only for phase-outcome).

Direction

A shared parse-with-diagnosis layer in _lib.sh (a generalization of _po_parse's "name the comment id + element + repair route" shape, parameterized per kind by its required elements), routed through by the non-PO consumers — mirroring how #57 routed all scans through _typed_scan. Substantial enough to earn its own slice: it touches every satellite consumer's error path and needs red-first suites per kind.

Provenance

Deferred from issue #57 QA round 1, finding CR-15 (applied_disposition: defer-to-issue, developer-decidable). See the qa-report:v1 domain=code phase=validate comment and the round's Phase Outcome on #57.

## Problem Issue #57 gave `phase-outcome` records a full diagnosis path for anchored-but-unparseable comments: the post refuses to mint and reads exit non-zero, both naming the offending comment id, the unparseable element, and the operator repair route (`_po_parse` in `_shared/procedures/bin/_lib.sh`). The other typed kinds never got the equivalent. A comment that is *anchored* as `decision-resolution:v1` (or any non-PO kind) but whose JSON fence is truncated/unparseable still surfaces as a **bare parser error naming no comment id** — reproduced during #57 QA: a malformed `decision-resolution:v1` record made `decision-resolution-read-state.sh` exit 5 with a raw `jq: error (at <stdin>:...)` and no pointer to the comment. Other consumers (`deliverable-get.sh`, fold/unfold, candidates) either die the same way or silently skip the record via `fromjson?`. `schemas/README.md`'s family-wide "three disjoint outcomes" rule was scoped to match shipped behavior as part of #57 QA (outcome 2's refusal-with-diagnosis is normative family-wide as a *goal*, implemented today only for `phase-outcome`). ## Direction A shared parse-with-diagnosis layer in `_lib.sh` (a generalization of `_po_parse`'s "name the comment id + element + repair route" shape, parameterized per kind by its required elements), routed through by the non-PO consumers — mirroring how #57 routed all scans through `_typed_scan`. Substantial enough to earn its own slice: it touches every satellite consumer's error path and needs red-first suites per kind. ## Provenance Deferred from issue #57 QA round 1, finding CR-15 (`applied_disposition: defer-to-issue`, developer-decidable). See the `qa-report:v1 domain=code phase=validate` comment and the round's Phase Outcome on #57.

jbr870 added the

labels

2026-08-24 17:13:33 +00:00

jbr870 referenced this issue

2026-08-24 17:13:41 +00:00

Run-record integrity: typed-comment validation and suite provenance stamp #57

jbr870 referenced this issue from a commit

2026-08-24 19:14:42 +00:00