Bind C-25 JSON to the scanned source commit (STATE-WP-0094-T03)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Build and Publish Multi-Context Image / build-and-push (push) Successful in 32s

The checker JSON reports per repository repo_slug, source_revision (full
40-hex HEAD SHA) and source_revision_reason; C-25 findings repeat them so a
findings-only consumer can bind. A dirty workplans/ tree, a non-git path,
a missing HEAD or a tree changing mid-scan yields null plus a reason, never
HEAD or a branch name. plan_owner_returns validates and passes the revision
into every candidate and refuses findings bound elsewhere.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 692292@bnt-lap001
Assistant-Session: 89c7d8e8-e1b3-47eb-9411-a0ab227fca2f
This commit is contained in:
tegwick 2026-10-04 13:33:24 +02:00
parent a0083ab78c
commit 150cb0b201
6 changed files with 284 additions and 1 deletions

View file

@ -105,3 +105,19 @@ a comment or receipt does not promote it. Terminal predecessors/resolved
non-human decisions and elapsed windows can leave an owner-return wait
`reviewable`; that disposition permits review preparation only and never clears
the wait marker, task status, human gate or any other field.
## Scanned source revision
The checker JSON (`--json`) states the commit it scanned, per repository:
`repo_slug`, `source_revision` (full 40-hex lowercase HEAD SHA) and
`source_revision_reason`. Every C-25 finding repeats the same three fields so a
consumer of the findings alone can bind. The revision is claimed only when
`workplans/` has no modified, staged, untracked or ignored change and the tree
did not move while the files were read and C-25 ran; otherwise
`source_revision` is `null` with a reason (`not_a_git_tree`, `no_head_commit`,
`unsupported_object_format`, `dirty_workplans`, `git_status_failed`,
`changed_during_scan`, `not_scanned`). It is never a branch name or a guess.
`plan_owner_returns` validates it (40-hex or null), refuses findings bound to a
different repository/revision and copies it into every candidate; the
deduplication event identity stays revision-independent. Activity Core's
eligibility builder compares it to its `scan_revision`, so `null` refuses.