feat: control-plane polish batch — prove issue-to-PR evidence value

[spytensor]

Problem

CoreRoom has reached a solid v0.9 implementation state, but continued optimization must not drift into generic multi-agent cockpit work. The next phase needs a narrow, evidence-backed product thesis:

CoreRoom is the AI engineering control plane that makes agent work issue-scoped, PR-backed, evidence-carrying, reviewable, and rollback-aware.

The project needs a small tracked polish batch that proves this thesis before broader feature expansion.

Proposed solution

Use this issue as the tracking umbrella for the control-plane polish batch. The batch is intentionally limited to positioning, preflight, delivery evidence, delivery-readiness UI, and external validation.

Child issues:

• feat(docs): reposition CoreRoom around issue-to-PR evidence #403 — README / public positioning around issue-to-PR evidence
• feat: add issue-to-PR evidence-loop dogfood harness #404 — deterministic issue-to-PR evidence-loop dogfood harness
• feat: add host issue-pickup preflight summary #405 — host issue-pickup preflight summary
• feat: render delivery-readiness gaps in the live room #406 — delivery-readiness gaps in live room/status surface
• feat(docs): define external dogfood scorecard and stop/go criteria #407 — external dogfood scorecard and stop/go criteria

Recommended order:

1. feat(docs): reposition CoreRoom around issue-to-PR evidence #403 and feat(docs): define external dogfood scorecard and stop/go criteria #407 first, to lock product thesis and validation criteria.
2. feat: add host issue-pickup preflight summary #405 next, to make the engineering contract visible before work starts.
3. feat: add issue-to-PR evidence-loop dogfood harness #404 next, to prove the full loop deterministically.
4. feat: render delivery-readiness gaps in the live room #406 last, to surface the proven evidence model in the UI.

Alternatives considered

• Continue broad v0.10 feature development. Rejected: too likely to optimize the cockpit rather than the control-plane value.
• Pick a new milestone before writing issues. Rejected for now because AGENTS.md says Active milestone: none; this batch is direct user-scoped maintenance/polish.

Scope target

v0.x or later (deferred is fine)

Acceptance criteria

• All child issues are either closed with PR evidence or explicitly deferred with a reason.
• At least one deterministic dogfood path proves issue/direct-intent -> PR evidence readiness without real engine quota.
• README and first-run narrative make the control-plane thesis clear before role/TUI mechanics.
• A stop/go external dogfood scorecard exists before broader feature expansion resumes.
• No child issue claims semantic completion, release readiness, or tracker closure from model prose alone.

Validation

• Each child PR includes the Required PR Evidence from AGENTS.md.
• If Primary tracker remains none, each child PR explicitly says tracker update is not applicable and cites this direct user-scoped polish batch.
• Before closing this umbrella, summarize completed PRs, validation evidence, remaining risks, and whether the stop/go thresholds recommend continuing.

Out of scope

• No new active milestone is created by this issue alone.
• No autonomous issue pickup beyond the direct user-scoped batch unless AGENTS.md is updated or the user explicitly scopes follow-up work.
• No hosted SaaS or replacement for GitHub/CI/reviewer authority.