Skip to content

feat(aidd-dev): track plan lifecycle status in frontmatter#251

Draft
alexsoyes wants to merge 6 commits into
mainfrom
feat/plan-status-lifecycle
Draft

feat(aidd-dev): track plan lifecycle status in frontmatter#251
alexsoyes wants to merge 6 commits into
mainfrom
feat/plan-status-lifecycle

Conversation

@alexsoyes
Copy link
Copy Markdown
Contributor

@alexsoyes alexsoyes commented Jun 7, 2026

🎯 What & why

SDLC plans never left their initial state at the end of a run — the .pending → .done filename lifecycle the template advertised belongs to For Sure, and no SDLC step advanced it. This moves the lifecycle into a frontmatter status field so plans reflect real progress and can back a kanban that links user stories to plans.

🛠️ How it works

  • status lives in plan frontmatter (pending | in-progress | done | verified | blocked), never in the filename — a stable identity is what kanban links need. Canonical table: plan-status.md, loaded once via @ from 01-plan/SKILL.md.
  • done = implemented, verified = reviewed — split so each actor writes only what it can know. Agents never write status; only orchestration does (01-planpending, 03-implementin-progress/done, 04-reviewverified).
  • 09-for-sure untouched — it keeps its filename-suffix mechanism.

🧪 How to verify

  • A scratch plan from the template advances pending → in-progress → done → verified while the filename stays suffix-less.
  • grep -rn 'in-progress | done | verified' plugins/aidd-dev/skills returns only the reference doc (single source).

⚠️ Heads-up

  • blocked is a valid value but written manually (escalation only).
  • Standalone 05-review doesn't auto-set verified — the caller does (keeps that agent-reachable skill read-only on the plan).

🤖 Generated with Claude Code

alexsoyes and others added 2 commits June 7, 2026 11:06
SDLC plans never advanced past their initial state: the
`.pending -> .in-progress -> .done` filename-suffix lifecycle advertised
by the shared plan template actually belongs to For Sure (09-for-sure),
the only surface that renames files. The SDLC flow has no step that
advances a filename suffix, so the promise was never kept.

Move the lifecycle into a frontmatter `status` field
(`pending | in-progress | done | verified | blocked`), giving a stable
file identity for kanban views that link user stories to plans. `done`
means implemented; `verified` means reviewed - so each actor only writes
what it can know.

Ownership (status written only by orchestration / plan creation, never by
the read-only reviewer or per-milestone implementer agents):
- 01-plan creates the plan with `status: pending`
- SDLC 03-implement: in-progress at start, done at end of the milestone
  loop (orchestrator judgment, not per-pass completion_score)
- SDLC 04-review: verified on `ship`, back to in-progress on `iterate`
- 02-implement (standalone): in-progress then done
- 05-review stays read-only on the plan (it is reachable by the reviewer
  agent, whose charter forbids modifying the validator)

For Sure (09-for-sure) is untouched and keeps its filename-suffix
mechanism.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
Apply minimal "less is more" style to the status transition prose:
drop articles/filler, use `→` for causality, fragments over full
sentences. No behavior change - same transitions, same ownership.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
@alexsoyes alexsoyes force-pushed the feat/plan-status-lifecycle branch from 1d37c05 to befed2a Compare June 7, 2026 11:47
alexsoyes and others added 4 commits June 7, 2026 13:56
Fold the two trailing blockquote notes (02-plan, 02-review-functional)
into their owning Process steps, per the action-file convention that
Process is numbered imperative steps. No behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
The status enum + ownership were duplicated across action files and
templates (R6 smell). Extract the canonical lifecycle into a Markdown
table at 01-plan/references/plan-status.md and load it once from
01-plan/SKILL.md via @-reference, so every 01-plan action inherits it.

Other skills (00-sdlc, 02-implement, 05-review) keep only their bare
status transition - no @-reference (cross-skill @ has no precedent and
breaks skill self-containment). No behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
`blocked` was the only status nothing wrote. Add a short reference
(02-implement/references/blocked.md) listing when a plan is blocked -
physically impossible for the AI (payment, OAuth/biometric login, an
unreadable secret) or a stuck loop - loaded once via @ from the
implement SKILL.md.

The implementer agent decides (surfaces `BLOCKED` in notes,
completion_score 0); the implement layer writes `status: blocked` and
escalates - standalone 02-implement and SDLC 03-implement, which stops
before review. Keeps the invariant that agents never write status.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
Retries were unbounded ("until 100%" / "until tests pass"), so the
stuck-loop block never triggered. Define the retry budget in
blocked.md (max 3 no-progress attempts per milestone, or 10 total) as
the single source; the implement loops (02-implement, SDLC 03-implement)
reference it instead of restating numbers.

Also split detection by who can observe it: the stateless implementer
agent reports only physically-impossible blocks; the implement layer
counts re-spawns and writes status: blocked on budget exhaustion.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant