Preflight: empty plan exposes merge/completion permissions without verifier identity

[pengfei-threemoonslab]

Priority and bounded outcome — PM review 2026-10-01

P0 control correctness, based on the September 24 reproduction already recorded here: an empty preflight plan exposes merge/report-complete permissions without a current verifier identity. This is an operational permission-contract defect, independent of new reader breadth or qualified-corpus completion.

Implement the selected planning-only completion semantics deliberately across runtime, schemas, projections and consumers, preserving predecessor compatibility. Acceptance must demonstrate that an empty plan cannot confer publication/merge/completion authority, while the existing verify-required and human-review routes remain intact. This triage changes priority only; it does not claim a new reproduction, fix or verifier clearance.

---

Found by a positive schema round-trip while implementing #545. Deferred from this implementation pass; this issue owns the operational meaning of a completed planning result, not a new release gate.

Problem

On main 42818ec25b06cf39d5c95024e2ba7884bffa4166, build_preflight_result(workspace=...) with no changed files returns control.state: complete with the shared complete permission vector, including update_pr, merge and report_complete. It publishes no verified current-control identity. The model allows this completed-plan case, while PreflightResultV3's generated schema unconditionally constrains control.permissions.update_pr to false. A valid runtime empty-plan response therefore fails its published schema.

#545's successor preflight schema will reflect the existing model's conditional constraint so current payloads validate, leaving frozen predecessor files and runtime permissions unchanged. The deeper product question remains: a coding agent reading a planning envelope can mistake completion of planning for authority over an evaluated change, despite the documentation saying preflight is only a routing/projection surface.

Required implementation

Reconcile completed-plan semantics with the canonical current-control boundary. Specify whether an empty plan should use a planning-only result or an exact verification route; do not mint a release verdict, receipt or merge authority from absence of planned edits. Apply one decision consistently across model validators, generated schemas, CLI/MCP projections, instructions and consumer tests. Preserve explicit predecessor compatibility.

Acceptance

• An empty or docs-only plan cannot be used as evidence that a repository change has been verified or is mergeable.
• The runtime payload and published JSON schema agree for empty, verify-required and human-review plans, with positive validation before negative controls.
• Consumers have one explicit way to distinguish planning completion from a current verifier-bound permission vector.
• Existing required-verify and human-review routes cannot be cleared by omitting a changed-file plan or replaying an old planning response.

Boundaries

No current-control reader or release decision changes in #545. This follow-up needs a deliberate compatibility decision, rather than silently reusing the shared complete label with different permission semantics. No release qualification is claimed from an empty-plan test.

Refs #545, #552, #572.

[pengfei-threemoonslab]

Days 1–5 current reproduction: both PyPI 1.1.0/contract 40 and main d9a6d0e/contract 41 return state=complete, completion_allowed=true and all six permissions true (including merge/report_complete) for preflight with {"changed_files": []}, without a current verifier identity. A README-only plan returns agent_action_required, an exact verify route and all permissions false. PR #869 records the setup and result. Select planning-only completion with no publication/merge authority; implement deliberately across model, schemas, projections and consumers, retaining predecessor compatibility. This is a reproduced open defect, not a fix or clearance from an empty plan.