Simplify milestone gating: start on approval, and skip the milestone gate for single-milestone projects #61

New Issue

2026-09-29T16:14:59Z

dev-agent commented

2026-09-29 16:14:59 +00:00

From the first live end-to-end run, where the operator found the milestone gating heavier than it needs to be.

Today (spec B1, lines ~905-920): after the milestone plan is approved, the operator must also say start milestone <n>. Every project has an architecture gate plus a gate per milestone, even when there is only one milestone.

Proposal

Start on approval. Approving a milestone plan starts execution at once, and start milestone <n> goes away. The approval already is the explicit sign-off the guiding principle asks for ("never cross key boundaries (start implementation) without explicit sign-off"). Revision binding still applies, and stop still halts.
No milestone gate for single-milestone projects. When the architecture plan covers exactly one milestone, approving it starts execution. Trade-off: the milestone plan is the detailed brief the local executor follows, so the architecture plan has to carry that detail. The planner should declare the milestone count explicitly (e.g. in submit_plan), not have it inferred from prose.

Work: a spec edit first (B1 workflow, B2 operator commands, A4 if it names the command), then the orchestrator, planner prompt and tests.

🤖 Generated with Claude Code

From the first live end-to-end run, where the operator found the milestone gating heavier than it needs to be. **Today** (spec B1, lines ~905-920): after the milestone plan is approved, the operator must also say `start milestone <n>`. Every project has an architecture gate plus a gate per milestone, even when there is only one milestone. **Proposal** 1. **Start on approval.** Approving a milestone plan starts execution at once, and `start milestone <n>` goes away. The approval already is the explicit sign-off the guiding principle asks for ("never cross key boundaries (start implementation) without explicit sign-off"). Revision binding still applies, and `stop` still halts. 2. **No milestone gate for single-milestone projects.** When the architecture plan covers exactly one milestone, approving it starts execution. Trade-off: the milestone plan is the detailed brief the local executor follows, so the architecture plan has to carry that detail. The planner should declare the milestone count explicitly (e.g. in `submit_plan`), not have it inferred from prose. **Work:** a spec edit first (B1 workflow, B2 operator commands, A4 if it names the command), then the orchestrator, planner prompt and tests. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dev-agent referenced this issue

2026-09-29 16:26:23 +00:00

Approvals and operator commands shouldn't be case sensitive #64

dev-agent referenced this issue

2026-09-29 16:33:43 +00:00

Let the agent merge its PRs once the operator has approved them #65

dev-agent referenced this issue

2026-09-30 12:58:06 +00:00

The planner can't say 'no more milestones', and 'next milestone' forces one #79

dev-agent referenced this issue

2026-09-30 19:47:19 +00:00

Propose the Development Plan #84

dev-agent commented

2026-09-30 21:07:49 +00:00

Superseded by the Development Plan (#84, merged): milestone gating becomes approvals as scoped permissions, with milestones marked pre-approved or needs-discussion in a build plan (L3, D2). It is covered by M2.5 in docs/Development-Plan.md, which designs the new conversational loop that replaces control.py. Fixing it in control.py would be thrown away when that loop retires.

Superseded by the Development Plan (#84, merged): milestone gating becomes approvals as scoped permissions, with milestones marked pre-approved or needs-discussion in a build plan (L3, D2). It is covered by **M2.5** in `docs/Development-Plan.md`, which designs the new conversational loop that replaces `control.py`. Fixing it in `control.py` would be thrown away when that loop retires.

dev-agent closed this issue

2026-09-30 21:07:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dev/nisse#61