fix(commercial): fail closed release readiness on exact-head review and check evidence

[seonghobae]

Buyer-visible gap

The commercial release-candidate evidence currently encodes a fail-open governance rule that conflicts with the repository's protected merge/release policy.

Originally observed on predecessor #96 head 89ad7cb7abea020ca72983943f1ea4e5902edf11; that identity is historical. The live #96 head revalidated for planning is 3703d0da9823b8258a0be94f1801aa5d61bfad9f on protected-main base 6841b71935e0b7cb98fb52bcb4709cc5100c8d87, but #96 remains Draft and lacks qualifying independent approval:

• docs/commercial_release_candidate.md states that review delay, review-bot delay, queued model review, and pending checks without a concrete failure are non-blocking;
• the runtime/test contract exposes release_summary.review_process_is_blocker = false;
• tests/test_commercial_release_candidate.py explicitly requires both of those semantics.

That can make buyer-facing evidence read as release-ready-with-warnings while qualifying independent review or required exact-head checks are pending/absent. For acquisition, procurement, release, and audit evidence, absence/pending/stale evidence must not be represented as success.

Required contract

Make the buyer-facing commercial readiness chain fail closed for release authorization evidence while keeping ordinary product/runtime telemetry separate from merge/release authority.

At minimum:

1. distinguish product evidence completeness from release authorization;
2. require one exact integrated protected-head identity for release authorization;
3. treat required checks that are queued, pending, skipped-required, cancelled, absent, failed, neutral-required, stale-head, predecessor-head, or synthetic-merge-only as not passing;
4. require qualifying independent non-author approval for the exact release head when repository policy requires it;
5. require zero valid unresolved human, CodeRabbit, GitHub Advanced Security, Dependabot, OpenCode, Noema, Strix, and other automated findings;
6. do not let ready_with_warnings mask a missing release-authority gate;
7. preserve an explicit local/product evidence state for useful buyer demonstrations that are not release-authorized;
8. expose machine-readable blocker reasons and evidence identities rather than a blanket review_process_is_blocker=false boolean;
9. keep provider credentials, private reasoning, and reviewer credentials out of the evidence payload;
10. update the admin surface, OpenAPI contract, buyer handoff/due-diligence artifacts, authoritative commercial documentation, and CHANGELOG consistently.

Test-first acceptance

Add deterministic RED contracts before changing production semantics. Cover at least:

• all required exact-head checks green + independent approval + zero valid findings -> release authorization may pass;
• queued/pending/absent required check -> blocked;
• stale/predecessor-head success -> blocked;
• synthetic merge-tree evidence without required contributor/protected-head evidence -> blocked;
• author-only approval when independent approval is required -> blocked;
• unresolved valid automated or human finding -> blocked;
• product evidence complete but release authority incomplete -> product evidence remains inspectable while release authorization is blocked;
• warnings unrelated to release authority remain warnings rather than blockers;
• no boolean/type confusion in status inputs;
• public API/admin/documentation describe the same fail-closed semantics.

Maintain 100% production statement and branch coverage and complete beginner-readable public docstrings for the bounded implementation.

Integration order / writer lease

Do not deepen the implementation stack on an obsolete base. The live repository chain remains Draft #96 at exact head 3703d0da9823b8258a0be94f1801aa5d61bfad9f on protected main 6841b71935e0b7cb98fb52bcb4709cc5100c8d87.

The central prerequisite remains outside protected central .github main, but the obsolete #906/#929/#907 snapshot has been superseded by this live replacement set (refetched 2026-08-12):

• protected .github main: 6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba;
• open .github#937: exact head 67d834f510fe044dd9d53cd4f4b9783353e303bd, with 11 terminal-success exact-head workflows, zero unresolved review threads, CodeRabbit COMMENTED evidence only, and no qualifying approval;
• open .github#939: exact head ac5665148bb113f92e97d2fc49a729bca2f050b5, with nine terminal-success exact-head workflows, zero unresolved review threads, and no formal review; and
• open .github#943: exact head 601b254f3a8ea4cc593e7089d6baeadd9d8d3ee4, the bounded trusted-download User-Agent repair, with nine terminal-success exact-head workflows, zero unresolved review threads, and no formal review.

These candidates are read-only dependencies here. Their success evidence does not make them protected-main authority, and no predecessor evidence transfers after a head change.

First integrate and operationally revalidate those central repairs under their owning maintenance path, then integrate and revalidate #96 under this repository's protection. Only afterward implement this issue as one bounded vertical slice on the exact integrated main, with one repository writer, exact-head/blob refetch before every write, fresh exact-head checks, zero valid unresolved findings, and qualifying independent review before merge. Treat every SHA above as dated planning evidence and refetch it before implementation.

This issue does not authorize writes to ContextualWisdomLab/.github or any downstream repository.

[seonghobae]

Implementation on PR #112 (fix/fail-closed-release-authorization): product_evidence_status vs release_authorization + evaluate_release_authorization. Auto-merge armed; awaiting independent approval + required checks on main.

[seonghobae]

Live implementation checkpoint — 2026-08-12

PR #112 is open Draft at exact contributor head 91ffe42a2ad46fafe9b149a2aeed1bff793929c6 on protected main@6841b71935e0b7cb98fb52bcb4709cc5100c8d87. Exact-head Tests 31589910042, Security 31589909969, Fuzz 31589910085, SAST Semgrep 31589909951, and Security Scan 31589909984 are terminal-success. There are zero observed inline threads and zero formal reviews; qualifying independent non-author approval is absent.

The branch implements a useful semantic prototype:

• product/demo completeness is exposed separately as product_evidence_status;
• missing, pending, failed, skipped, cancelled, neutral, stale-head, author-only, and unresolved-finding inputs block release_authorization;
• release_status cannot appear ready while the supplied authorization object is incomplete; and
• deterministic tests cover absent, pending, stale, author-only, unresolved-finding, and nominal-success dictionaries.

It does not yet satisfy this issue's authoritative release-admission contract. evaluate_release_authorization() trusts a caller-supplied dictionary: arbitrary matching strings can pose as protected/exact SHAs, a fabricated successful check can satisfy the required-check list, any non-author reviewer string counts as independent, and unresolved_findings=[] is accepted without proving that all required human and automated sources were queried. The implementation does not fetch or verify repository rulesets, required contexts, aggregate reviewDecision, branch protection, last-push approval, reviewer eligibility/dismissal/head identity, protected-main membership, synthetic-vs-contributor evidence, or complete current-head finding inventories. The ordinary HTTP path supplies no trusted authority object and therefore always remains blocked; this is fail-safe but not operational authorization.

The issue remains open. After #96 reaches protected main, rebuild the semantic split around a trusted read-only authority collector/binder, add spoofing/duplicate/stale/synthetic/incomplete-inventory RED tests, remove unrelated suppression-only security annotations, regenerate exact 100% quality/security/review evidence, obtain qualifying independent approval, and require protected-main operational acceptance before closure.