44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
---
|
|
name: planning-gate
|
|
description: Wait for explicit approval before implementing a proposed design or feature - posting a plan for review is not itself a go-ahead. Reading existing code to inform a plan is fine; writing new files or editing existing ones is an implementation action that needs an explicit yes from whoever owns the decision first. Use this whenever you've sketched an approach bigger than an obvious one-line fix and are about to start writing code, or whenever you're unsure if silence means consent.
|
|
---
|
|
|
|
# Planning Gate
|
|
|
|
A plan is not a decision. Posting a proposed design, and someone reading
|
|
it, are two different events - don't collapse them.
|
|
|
|
## Before writing any code for a non-trivial change
|
|
|
|
1. **Read and analyze freely.** Looking at existing code, tracing a bug,
|
|
forming a hypothesis - none of that needs permission.
|
|
2. **Post the plan, then stop.** Once you have a proposed approach,
|
|
share it and wait. Don't start editing files on the strength of your
|
|
own plan looking good to you.
|
|
3. **Writing files is the implementation action.** Creating a new file
|
|
or editing an existing one is where the gate applies - not the
|
|
thinking that led up to it.
|
|
4. **Silence isn't consent.** If it's unclear whether a plan was
|
|
approved (nobody replied, or the reply address a different point),
|
|
ask explicitly rather than assuming you're clear to proceed.
|
|
|
|
## Where a proposal belongs
|
|
|
|
Put a proposed design or solution in a **comment** on the task/issue,
|
|
never in the task's own description. The description states the
|
|
problem and should stay stable; a proposal is a point-in-time idea that
|
|
gets revised, superseded, or rejected. A proposal baked into the
|
|
description reads as settled fact to a later reader, when it might not
|
|
even have survived the first round of feedback. This applies to any
|
|
sub-tasks filed off a parent too: description states the problem,
|
|
comments carry the evolving design.
|
|
|
|
## What doesn't need the gate
|
|
|
|
- Obvious one-line fixes with no design ambiguity.
|
|
- Direct, explicit feedback on your own already-in-flight change (a
|
|
reviewer's comment on your open PR is actionable immediately - it's
|
|
not a new feature proposal, it's correcting work already approved to
|
|
exist).
|
|
- Anything the requester has already explicitly said "go ahead" on,
|
|
even if the exact implementation detail is still yours to fill in.
|