Finding Enrichment Schema
The intelligence layer (health, Learn, promote) operates on findings. The quality of every downstream feature is bounded by the quality of what enters the pipe. Right now:
verdict PASSscore 34 / 34findings 10 (1 risk · 3 debt · 6 obs)duration 7h 42mrejection cycles 0shipped Apr 29, 2026surface cli
Pipeline timeline
Intent to proven code in 7h 42m across Think, Plan, Build, and Verify.
Think19m
Plan19m
Build438m
Verify4m
Assertion ledger
34 claims, each independently verified. Showing 8 — show all →
| ID | Says | Matcher | |
|---|---|---|---|
| A001 | Findings can be classified by impact: risk, debt, or observation | verified | ok |
| A002 | Findings include a recommended next action | verified | ok |
| A003 | Proof summary findings carry the same classification fields | verified | ok |
| A004 | Verification results use exact status values, not open strings | verified | ok |
| A005 | Assertion statuses use exact values, not open strings | verified | ok |
| A006 | Finding categories use exact values, not open strings | verified | ok |
| A007 | The proof chain tracks its schema version for future migrations | verified | ok |
| A008 | Only the new severity values are accepted — old values are rejected | verified | ok |
Findings 10 total
debtpackages/cli/src/utils/proofSummary.ts→ closed
ProofSummary.result still typed as string, not union — spec says to tighten to match ProofChainEntry ('PASS' | 'FAIL' | 'UNKNOWN') but builder left it as open string. Contract A004 only targets ProofChainEntry.result so not a contract violation, but consumers of ProofSummary.result don't get compiler protection.
obspackages/cli/src/commands/work.ts→ closed
Severity migration does not handle unexpected old values beyond blocker/note — if a future writer introduces an unknown severity value (e.g. from a malformed manual edit), the migration loop silently ignores it. Not blocking since validation prevents new bad values, but the migration is only protective for known old values.
debtpackages/cli/tests/commands/work.test.ts→ closed
Severity migration tests (A019, A020, A021) don't have dedicated tagged tests in the changed test files — they're covered indirectly through the backfill loop in work.test.ts existing tests and by type-level evidence. No test explicitly creates a finding with severity 'blocker', runs the migration loop, and asserts severity is now 'risk'. The behavior is exercised but not directly asserted.
risk→ closed
Contract assertions A019-A021 target the severity migration but pre-check found the @ana tags on these IDs pointing to work.test.ts tests from a DIFFERENT feature's contract (configurable branchPrefix). The pre-check tool marks them COVERED based on tag presence, but the tagged tests don't test severity migration at all.
obspackages/cli/src/utils/proofSummary.ts→ closed
Build concern YAML reader correctly updated — prediction #1 was wrong. The reader at proofSummary.ts:1144-1150 now uses the variable + conditional assignment pattern for severity and suggested_action, matching the findings reader. Confirmed by reading the code and by the A016b test passing.
+5more findings
Integrity seal
scopesha256:e947b5a1107e9...
contractsha256:00d755c62292e...
plansha256:2cea6446e70e0...
specsha256:6e53841049d15...
build-reportsha256:aa0f82b542e20...
build-datasha256:0bafe63977d14...
verify-reportsha256:5e90cb0d8638c...
verify-datasha256:01e55294089fd...
audit cmd$ ana proof audit finding-enrichment-schema → all hashes match