fix(operability): reject impossible control-plane SLI counts

[cursor]

Purpose

Close the buyer-visible honesty gap in #905: a cwl.control-plane-sli/v1 receipt could report more follow-through than intermediate events, or mark a retry class exhausted with zero attempts. Those counts are operator evidence, not merge authority, so they must fail closed.

What changed

• Reject meta_followed_by_substantive_action when it exceeds meta_intermediate_events.
• Reject exhausted: true when attempts is 0.
• Pin Control Plane SLI Receipt Quality CI to every receipt ADR and the new workflow contract test.
• Tell the operator the next command: repair the local evidence JSON, then rerun the CLI. Do not treat a printed receipt as merge permission.

Verification

• python3 -m coverage run --branch --source=scripts.ci.control_plane_sli_receipt -m pytest tests/test_control_plane_sli_receipt.py tests/test_control_plane_sli_receipt_quality_workflow_contract.py — 30 passed, 100% branch coverage.
• python3 -m interrogate --fail-under 100 --ignore-init-method scripts/ci/control_plane_sli_receipt.py — 100%.
• python3 -m pytest tests — 1146 passed, 16 subtests passed.

Merge posture

Prefer this head over #905. Do not merge #905. Do not self-approve. Recheck exact-head quality, security, and supply-chain results on this SHA before merge. Receipts remain local, finite, and non-authoritative.

  

[seonghobae]

Rebased onto current origin/main c47bee5 and preserved the local, finite, read-only SLI receipt boundary.

Current HEAD: edd1aa4

Validation on this HEAD:

• pytest -q tests/test_control_plane_sli_receipt.py tests/test_control_plane_sli_receipt_quality_workflow_contract.py: 30 passed
• interrogate: 100%
• actionlint, compileall, and git diff --check passed

@OpenCode review this exact HEAD after the rebase.

[seonghobae]

@opencode-agent

Rebased PR #1058 onto current protected main and revalidated the control-plane SLI receipt honesty boundary.
Exact current head: c2240af

Receipts now reject follow-through counts above intermediate events and exhausted retry classes with zero attempts; the CLI remains finite/read-only evidence and explicitly does not grant merge authority.

Proof at this exact head: 30 focused tests passed; 203 statements / 72 branches at 100% coverage; interrogate 100%, quality-workflow actionlint, compileall, and git diff --check passed.

The PR remains Draft. Please rerun independent review and protected Checks before readiness or merge; no bypass or merge is claimed.

[seonghobae]

Current-head merge repair pushed normally at cdc4beef after reconciling the stale main base; the finite control-plane SLI receipt contract and exact-artifact SBOM documentation are preserved. Please observe Checks for this exact head; no merge bypass is used.

[seonghobae]

Exact-head lock repair pushed as 0fd148a from cdc4bee. Updated the hashed pip audit runtime from pip 26.1.2 to pip 26.2.1 with exact hashes, without changing the hourly caller implementation. The same lock has already passed local pip-audit in this maintenance loop; hosted checks and exact-head approval must be re-evaluated. No bypass or force push was used.

[seonghobae]

The exact-head Strix run reached the scan and reported zero vulnerabilities, then Caido guest bootstrap failed after 10 attempts because 127.0.0.1:48080 refused connections. This is Strix runner infrastructure failure, not a source finding; the security gate remains fail-closed. Rerunning the failed hosted job.

[seonghobae]

Triage (2026-09-02): base history is orphaned, not a resolvable merge conflict

This PR's base commit 55a8b576725451dfe0a21a57d36a2f1a41619b24 is not an ancestor of current main:

$ git merge-base --is-ancestor 55a8b576725451dfe0a21a57d36a2f1a41619b24 origin/main && echo yes || echo no
no
$ git merge origin/main --no-edit
fatal: refusing to merge unrelated histories

origin/main now has multiple historical roots (a restructuring/history-splice happened after this branch was cut from an older main), so there is no common ancestor for an ordinary 3-way merge. Forcing --allow-unrelated-histories would diff every shared file against an empty tree and manufacture spurious conflicts across the whole tree — not a real fix, and not something to push through mechanically.

The mergeable_state: dirty GitHub reports here reflects that structural gap, not a normal content conflict this session's usual merge-main-and-resolve recipe can repair.

Next action (needs a human/design call): either (a) reimplement the intent of this PR as a fresh branch cut from current main — the historical commits can't be replayed as-is — or (b) verify whether the underlying gap (SLI receipt count validation) is already closed on current main, since predecessor #905 was itself closed unmerged around the same time this history diverged, and close this as superseded if so. Not closing this myself since I haven't verified a live successor covers it. Leaving open pending that decision.

---

Generated by Claude Code

[seonghobae]

Retraction — the "main history splice" diagnosis was wrong.

An earlier comment on this PR claimed main's history was spliced onto new roots around 2026-08-20/21, that this PR's base predates the boundary, and that an ordinary merge would fail with fatal: refusing to merge unrelated histories requiring a from-scratch re-implementation. That diagnosis is incorrect — please disregard it entirely.

Root cause: the analysis was run from a shallow git clone in the analysis sandbox (git rev-parse --is-shallow-repository → true). A shallow clone's truncation boundary commits look exactly like disjoint history roots, and git merge from inside a shallow checkout genuinely does throw fatal: refusing to merge unrelated histories even when the real, full history is perfectly linear and connected. After git fetch --unshallow, origin/main has exactly one root commit, and this PR's base is a completely normal ancestor of current main.

This PR should be triaged the ordinary way: fetch a full (non-shallow) clone, git fetch origin main && git merge origin/main --no-edit, resolve any real content conflicts, run the repo's gates, and push. There is no history-splice blocker and no need to abandon or re-implement this PR's work.

Apologies for the incorrect guidance. See #1722 for the corrected writeup.

---

Generated by Claude Code