Clarify missing candidate SHA versus live-control proof mismatch

[100yenadmin]

Problem

The 1.6 release proof validators intentionally fail closed when approved live-control evidence is supplied without a valid expected candidate SHA. Today the operator-facing blocker groups a missing --candidate-sha, an invalid SHA, and a true proof mismatch under approved_live_control_candidate_mismatch.

This is safe, and the release runbook always supplies the candidate SHA, but the diagnostic can send an operator toward tamper investigation when the command invocation merely omitted the flag.

Acceptance criteria

• Distinguish a missing or invalid expected candidate argument from a valid-but-mismatched proof candidate.
• Preserve fail-closed release readiness behavior.
• Keep preflight, bundle, and demo-status diagnostics aligned.
• Add focused tests for missing, invalid, and mismatched candidate inputs.

Provenance

Follow-up from the exact-head evaOS review of PR #772. Classified P3 and not a 1.6 release blocker because the documented release path supplies the flag and current behavior fails safely.

[coderabbitai]

🔗 Related PRs

#28 - Add release preflight manifest [merged]
#395 - Fix live-control failure proof reports [merged]
#510 - feat: add GA smoke release aggregator [merged]
#660 - fix: harden historic review proof gates [merged]
#767 - Prepare LCO 1.6.0 release truth [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #774 - Clarify missing candidate SHA versus live-control proof mismatch
State: open

Related issues/PRs: #772.
Existing labels: bug, safety, milestone-tracker, orchestrator.
Suggested labels: docs, tests.
Suggested owners: none.

Related context

• Fix release proof binding and incremental FTS probe #772 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: Clarify missing candidate SHA versus live-control proof mismatch - ## Problem The 1.6 release proof validators intentionally fail closed when approved live-control evidence is supplied without a valid expected candidate SHA. Today the operator-facing blocker groups a missing
Product fit: Implementation issue; keep product fit lightweight unless VISION.md/repo policy raises a constraint.
Implementation wedge: Start with a focused fixture or dry-run path that proves the issue shape before widening behavior.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: deferred; no product, architecture, UX, library-choice, integration, roadmap, or market-positioning trigger detected.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: Issue metadata contains same-repo references.
• [deferred] allowlisted_cross_repo_github: Deferred until product, UX, market-positioning, or library-choice signal appears.
• [deferred] external_oss_examples: Deferred for low-research-value issue class.
• [deferred] library_api_docs: Deferred unless a library/API decision is present.
• [deferred] current_market_examples: Deferred for implementation-only issues.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.

[100yenadmin]

Retaining after exact-main audit at 3cd3c5b. Current validators still group missing, invalid, and valid-but-mismatched approved-live-control candidates under the same mismatch blocker. Owner: @100yenadmin. Revisit when separate reason codes/messages and focused tests cover all three cases across preflight, bundle/status, and demo-status while preserving fail-closed behavior.