feat(reviewer): bind evidence receipts to exact claims

[seonghobae]

Scope and stack

Stacked on reviewer-hardening PR #535 and owned by issue #555. This PR's current base snapshot remains predecessor #535 a6fc483fe9537c5881114db82cc9f741eb8331b1, while live #535 is 329069405181921091397d31687f2c5f7a98ae54. The child therefore does not claim to contain later parent governance/routing repair. Integrate #536, then converge/integrate #535 normally; only then ordinary/non-force semantic restack/retarget this lane onto protected main while preserving the exact-claim receipt delta. No #535/#536 delta is retired or copied here.

Consumer RED

Central ContextualWisdomLab/.github#1641@b8c986e2406beb37d254acd4c5df6389038b55f2 preserves the original Concept35 sentence and synonym. Hosted run 34073137064, job 101594104816, failed only those two cases with DID NOT RAISE; full result was 2 failed, 2974 passed, 1 skipped, 21 subtests passed. This corpus stays RED until an immutable Noema release is consumed and the original cases rerun GREEN.

Owner RED → repair lineage

Current exact head is fecb03d9c632f90f290f921c1d6e90ce86ca5305.

The source-evidence path remains intact: exact target checkout → bounded source receipt manifest → separate attestation → exact digest/repository/head/workflow/run/attempt verification → immutable trusted index → exact <claim> [receipt:<id>] model reference → admission before deterministic gates/publication. Source receipts remain path/line-bound and cannot authorize execution/research facts.

This revision advances the real execution boundary instead of adding another semantic regex:

• test-only f2993810dbd7a862678460c5f14055d6bc932e7b first requires a public trusted sandboxed_verify execution adapter. The predecessor has no such port, so this is a deterministic RED; it was immediately superseded and is not claimed as hosted RED.
• production ea751bc99be9f8035a089e55538886a820a905c0 adds sandboxed_verify_claim_evidence.py and delegates canonical artifact/receipt construction to the existing produce_execution_claim_receipt kernel.
• production fecb03d9c632f90f290f921c1d6e90ce86ca5305 exports that adapter through the reviewer package port.

The adapter accepts only the reviewed immutable central helper revision c9052e607e5f3cc76e73207e7786b21500721b79, validates the current SANDBOXED_VERIFY_RESULT schema with extra=forbid, and requires the command's exact captured stdout/stderr separately. Marker-only text therefore still cannot mint trusted execution evidence. Unreviewed helper revisions, non-empty allowed_env capabilities, malformed/expanded markers, empty commands and false sandbox markers fail closed.

The receipt deliberately records the current central helper's actual guarantees rather than promoting metadata into stronger claims: workspace copy + scrubbed environment are recorded, OS process isolation is none, and --network is recorded as declared metadata with enforced=false. Provider/model routing, quarantine/security verdicts and outbound-policy authority remain outside Noema.

Hosted verification

Fresh exact-head runs for fecb03d... are ci 34089768682 (queued), reviewer-ci 34089768665 (pending), and patch-validator-image 34089768733 (queued). No predecessor result transfers and no GREEN is claimed. There is no Security Scan while this PR remains intentionally feature-base stacked; live ruleset 18794436 targets ~DEFAULT_BRANCH, so the absence is neither GREEN nor a routing failure. After prerequisite integration and retarget/restack to protected main, a fresh exact-head Security terminal success is mandatory with the other gates.

Remaining delivery boundary

The adapter is now Noema production code, but the external execution producer is not yet end-to-end delivered. Current central sandboxed_verify.py emits command/result metadata but does not carry exact stdout/stderr bytes in its marker; the released consumer must capture those streams out of band and invoke this versioned Noema adapter rather than trusting marker text. Trusted research retrieval still needs a content-addressed revision/excerpt/retrieval-policy producer using the same manifest/index. Then #536→#535→#556 must integrate normally, an immutable Noema release must be published with release evidence, and .github#1641 must consume that release and rerun the original hosted RED corpus GREEN.

Keep Draft. No merge, consumer GREEN, or release claim is made from this head.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

Exact-head owner review for 2571d7f996161df32227a27fc66b502bbb1b5d31.

Blocking trust-boundary finding: admit_claim_evidence() validates a caller-supplied model/Pydantic payload and binds only shared identity, required kind, claim digest, artifact digest, and artifact size. It does not authenticate a producer envelope or bind the variant's semantic evidence fields to the exact artifact. With the same admitted claim/artifact bytes, an attacker can change ExecutionClaimReceipt.argv, exit_code, stdout_sha256, stderr_sha256, isolation_policy, or network_policy; likewise SourceClaimReceipt.source_path/source_line/source_line_sha256 and ResearchClaimReceipt.source_uri/source_revision/excerpt_sha256/retrieval_policy can be substituted while admission still succeeds. The current hostile tests mutate only shared identity/digest fields and therefore do not expose this.

The docstring and PR claim a “sealed/producer-issued” receipt, but the API accepts an arbitrary payload without verifying a trusted producer signature/MAC or looking up a trusted immutable manifest. Freezing a Pydantic model does not establish provenance. Add RED cases that keep the exact artifact fixed while mutating every meaning-bearing variant field, then make the publication boundary resolve a model-cited receipt ID from a trusted producer manifest/index (or verify an authenticated envelope that covers the complete canonical payload). The model must not submit the authoritative receipt dict. Extend the real producer → gate → finding/publication path with positive/negative integration tests; a standalone schema module alone does not close .github#1641 / Concept35.

This is an owner-side contract review, not approval, release evidence, or permission for the central consumer to proceed. Preserve the existing identity/digest hardening; the missing delta is complete producer-envelope binding and actual publication-boundary integration.

[seonghobae]

Read-only review follow-up on exact head 809aa6d1d0e429a44940f0978ae985c8295beaab:

• Added fixed-artifact hostile cases that mutate every execution semantic field (argv/tool/version/exit/stdout/stderr/isolation/network), every research semantic field (URI/revision/excerpt/retrieval policy), and source coordinates while retaining prior artifact bytes.
• Removed the API assumption that a caller-authenticated raw dictionary is already trusted. Only verify_claim_evidence_manifest() can construct the immutable admission index; it verifies the exact authenticated OpenCode-handoff digest, canonical envelope bytes, reviewed producer→kind policy, and repository/head/workflow/run/attempt before parsing receipts.
• The untrusted model supplies only a receipt ID and exact claim text. Direct index construction, raw receipt dictionaries, noncanonical manifests/base64, stale/swapped identity, duplicate IDs, and semantic substitution fail closed.
• Canonical execution/research/source producers now bind every meaning-bearing field; the source producer was added by the concurrent owner transaction without changing the verified envelope blobs.
• Focused verification: 44 passed; 214 statements and 62 branches at 100%; 100% public-doc coverage; compile success.
• The earlier brief duplicate-root-path mistake was removed in the same non-force history; the current PR diff stays in the canonical reviewer/ owner surface plus CHANGELOG and the gap baseline.

This is not completion of issue #555 or the Concept35 consumer finding. Existing sandboxed_verify/research adapter wiring, authenticated manifest population, actual agent → gate → publish admission, exact-head hosted CI, immutable release, and central released-consumer GREEN remain open. No second producer/kernel or provider/actor bypass was added.

[seonghobae]

Central owner handoff for task 01a06aac-7183-7910-aa64-48e0ae87d955.

Canonical repair remains this PR; no duplicate PR/writer/kernel was created. Exact head: 5121e1e0e445da8f5c80674c42b17d090caaeff4.

Observable delta:

• test-first boundary commit 85d8044bcb5e3dd46c1ca6c40590f30d180c3d7b fixed the missing production seam; its hosted jobs were cancelled by connected successors and are not treated as pass;
• exact target checkout source producer → canonical receipt manifest → separate GitHub attestations → verified index → model prompt → pre-deterministic-gate admission → CLI publication is connected;
• free Finding.evidence prose and marker-only/model-dict evidence fail before publication;
• source receipts are additionally bound to exact Finding.path/line, so a receipt cannot be reused at another coordinate;
• focused result: 121 passed; new agent/runtime surface 157 statements / 58 branches at 100%; workflow YAML and compile GREEN.

Exact-head hosted handles are non-terminal:

• ci 34082067236
• reviewer-ci 34082067277
• patch-validator-image 34082067307

Release remains blocked on adapting the existing central sandboxed_verify producer and a trusted research retrieval producer into this same canonical manifest, fresh protected-main Security/SBOM/provenance after normal #536/#535 integration, immutable Noema release, and the released .github#1641 consumer bump. Concept35 original/synonym RED remains authoritative; no execution/research producer GREEN, release, or consumer completion is claimed.

[seonghobae]

Repair finding at exact head 676747e: .github/workflows/central-review.yml attests noema-*-manifest.json, which matches noema-claim-evidence-manifest.json but excludes noema-manifest.json. The subsequent publication job requires attestation verification for both files using that bundle. This leaves the original review manifest without a matching attested subject. Reproduced path matching locally (old manifest false, claim manifest true); this is not a hosted failure claim. Please use an explicit two-file subject list supported by pinned actions/attest 59d89421af93a897026c735860bf21b6eb4f7b26, retain verification of both subjects, and add a failing regression for subject/verification set parity before repair. Do not weaken the provenance gate. Sent to the existing owner task as well; this comment is a repair finding, not approval or merge authorization.

[seonghobae]

Central owner handoff update for task 01a06aac-7183-7910-aa64-48e0ae87d955.

Canonical repair remains this PR and the existing writer/branch; no duplicate PR, writer, kernel, regex authority, COMMENT conversion, actor bypass, or provider bypass was created. Exact head: 174d0b09ea8499647124488f88e7d1226165e7fa.

New source→execution authority repair:

• test-only exact RED 81eef2a6f08d1a5a62c3d4d5159eb60fb466ac1c drove the real agent→CLI publisher boundary with an authentic current-head source receipt while model summary/recommendation asserted the unobserved --locked execution behavior;
• against the unchanged runtime the focused test failed because that model prose reached publication;
• the smallest successor keeps the exact producer claim, source path/line and severity, but projects model summary/recommendation to deterministic receipt-kind-specific non-authoritative action text before deterministic gates and publication;
• source-only findings remain usable; a source receipt no longer presents model prose as observed execution evidence.

Fresh local verification on the exact branch files:

• focused claim/reference/source/publication + agent/CLI/gating: 122 passed;
• agent.py + claim_evidence_runtime.py: 162 statements, 58 branches, 100%;
• compileall: GREEN.

Exact-head hosted handles are non-terminal and are not reported as GREEN:

• ci 34085224666
• reviewer-ci 34085224681
• patch-validator-image 34085224655

Release remains blocked on adapting the existing central sandboxed_verify execution producer and a trusted research retrieval producer into this same canonical manifest, normal #536/#535 integration/restack, fresh protected-main Security/SBOM/provenance, immutable Noema release, and the released .github#1641 consumer bump/rerun. The original Concept35/synonym consumer RED remains authoritative; no execution/research producer GREEN, release, merge, or consumer completion is claimed.

[seonghobae]

Follow-up to issuecomment-5564882501: independently inspected 45ecc9d and ran a static assertion confirming both exact subject/verification pairs and absence of the old wildcard. The original omitted-subject defect is repaired in source; hosted attestation remains unverified. Current head 5121e1e additionally binds SourceClaimReceipt path/line to Finding and adds a wrong-path regression. Remaining review scope: wrong-line/positive source path tests, attestation pair regression, and independently required evidence kind plus binding of the actual finding claim (including runtime assertions in summary/recommendation). Citing a correct source line does not establish that a valid Cargo option is unsupported. Current CI 34082067236 is queued; previous 34081969490 is cancelled. No approval or protected-merge claim.

[seonghobae]

추가 검토: exact head 174d0b09ea8499647124488f88e7d1226165e7fa의 admit_review_verdict_evidence는 summary/recommendation만 치환하고 모델 verdict·severity·finding 자체를 보존합니다. 새 test_source_receipt_cannot_publish_unreceipted_runtime_claims는 유효한 Cargo 명령의 소스 영수증을 제시한 거짓 runtime finding에 대해 REQUEST_CHANGES 게시 1회를 기대합니다. 따라서 문구상의 미근거 실행 주장은 사라져도 소스 존재만으로 잘못된 차단 판정이 유지됩니다. 이 테스트/구현은 claim-level 근거 검증의 완료 기준이 될 수 없습니다. 실제 결함 주장과 독립적으로 요구되는 evidence kind를 연결하고, 해당 반례가 일반 문구로 세탁된 차단 판정으로 게시되지 않는 RED→GREEN을 추가해 주세요. 유효한 source-only finding까지 일괄 제거하지 말고, 미판정 증거와 검증된 결함·승인 권한을 분리해야 합니다. 이것은 exact-source/test 기대값 검토이며 hosted 실행 결과나 승인/병합 허가가 아닙니다.

[seonghobae]

Fresh current-head review note on 174d0b09ea8499647124488f88e7d1226165e7fa, corrected after re-reading the live inherited ruleset: ci 34085224666 and reviewer-ci 34085224681 are queued and patch-validator-image 34085224655 is pending. No Security Scan run exists on this stacked feature-base head. Live ruleset 18794436 is active with ref_name.include=["~DEFAULT_BRANCH"] and requires central .github/workflows/security-scan.yml@refs/heads/main; therefore this stacked PR is outside that required-workflow ruleset condition until its prerequisite integrates and it is non-force restacked/retargeted to protected main. The central workflow file itself has no base-ref filter, but that does not independently widen the organization ruleset target. This matches #535's current governance repair. The absent scan here is neither success nor a current routing defect. Keep #556 Draft; after the parent stack integrates, require a fresh exact-head Security run plus the other terminal gates before merge/release. No rerun/no-op/source churn, runs-on change, synthetic status, or gate weakening was performed.