Require planning checkpoint disposition at orchestration handoff; separate planning and implementation commit authority

2026-09-13 22:26:51 +02:00
parent 1a94fe83c9
commit aed2e1d629
2 changed files with 11 additions and 1 deletions
@@ -50,6 +50,7 @@ Before delegating implementation, run a readiness preflight:
 1. Establish current state.
   - Read project instructions first.
   - Establish context from the plan, checklist, prompt map, current handoff/review and relevant git/worktree state. On continuation, read changed instructions/contracts and affected scope rather than reloading unchanged history.
   - Before initial implementation delegation, verify the reviewed planning package against its checkpoint and actual working files. If relevant planning changes remain uncommitted, honor an explicit uncommitted disposition or applicable planning-checkpoint authorization; otherwise finish applicable document checks, identify the exact files and proposed commit, and ask before proceeding. Planning-checkpoint permission and accepted-chunk commit permission are separate. Exclude unrelated changes; do not repeat a resolved checkpoint request or turn routine execution-status updates into a new planning checkpoint gate. Record the verified baseline, including relevant uncommitted inputs when explicitly allowed.
   - Read any existing readiness audit. If no readiness audit exists, create one before writing the first implementer prompt.
   - Initially classify every chunk as `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`. Subsequently verify affected entries/dependencies; broaden when a shared contract changes or applicability is uncertain.
   - Surface all contract blockers and small freezes to the user before implementation starts.
@@ -269,7 +270,7 @@ If there are no findings, state an acceptable verdict clearly before summaries.
 ## Commit Rules
-Commit behavior is controlled only by the explicit commit policy. Supported policies are:
+Implementation-chunk commits are controlled by the explicit commit policy. Planning checkpoints require their own applicable authorization under the preflight rule; neither permission grants the other. A broader user instruction forbidding commits or requiring confirmation for every commit still applies to both scopes unless explicitly changed. Supported implementation policies are:
 - `authorized-for-accepted-chunks`
 - `ask-before-each-commit`
@@ -259,6 +259,14 @@ End implementer prompts by asking for a proposed commit message. When a chunk ID
 When the user asks the planner for a commit message, output a one-line commit message. If multiple sentence-like clauses are needed, separate them with semicolons.
 ## Planning Checkpoint Before Orchestration
 At the final handoff to start orchestration, verify that the reviewed planning package is committed. Do not interrupt ordinary plan/checklist/prompt-map drafting or review with checkpoint requests. Finish the requested documents and applicable checks first, then inspect the exact staged, unstaged and untracked planning changes. If a checkpoint is missing and no applicable authorization exists, identify the proposed files and one-line commit message, explain that the planning baseline is uncommitted, and ask whether to commit it before orchestration. The handoff may be prepared, but must not claim this boundary is resolved while the answer is pending.
 Reuse explicit planning-checkpoint authorization already granted; otherwise ordinary planning work or permission to start orchestration does not itself authorize that commit. Keep planning-document authorization separate from the implementation-chunk commit policy: neither implies the other. Commit only reviewed planning changes within the authorized scope, preserving unrelated changes, and verify the resulting commit covers the intended baseline. Report its commit ID with the final handoff; no document needs to embed its own commit hash.
 Respect explicit instructions to leave the planning package uncommitted. Record that disposition and the baseline commit plus relevant uncommitted planning files in the handoff so the orchestrator can verify the actual inputs. Do not repeatedly ask for a checkpoint already made, authorized or explicitly waived; unrelated dirty files do not by themselves require another commit.
 ## Orchestrator Handoff Prompts
 When asked to write, produce, or prepare an orchestrator prompt, treat it as an official durable handoff artifact, not casual chat output.
@@ -276,6 +284,7 @@ Every orchestrator prompt must include:
 - prompt output directory or naming convention
 - validation expectations
 - commit policy
 - planning checkpoint status: verified baseline or explicit uncommitted disposition under **Planning Checkpoint Before Orchestration**
 - cleanup authority: explicit scope/source, or not authorized; required retention and resource handoff
 - stopping conditions