feat(aidd-dev): track plan lifecycle status in frontmatter#251
Draft
alexsoyes wants to merge 6 commits into
Draft
feat(aidd-dev): track plan lifecycle status in frontmatter#251alexsoyes wants to merge 6 commits into
alexsoyes wants to merge 6 commits into
Conversation
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>
1d37c05 to
befed2a
Compare
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🎯 What & why
SDLC plans never left their initial state at the end of a run — the
.pending → .donefilename lifecycle the template advertised belongs to For Sure, and no SDLC step advanced it. This moves the lifecycle into a frontmatterstatusfield so plans reflect real progress and can back a kanban that links user stories to plans.🛠️ How it works
statuslives 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 writestatus; only orchestration does (01-plan→pending,03-implement→in-progress/done,04-review→verified).09-for-sureuntouched — it keeps its filename-suffix mechanism.🧪 How to verify
pending → in-progress → done → verifiedwhile the filename stays suffix-less.grep -rn 'in-progress | done | verified' plugins/aidd-dev/skillsreturns only the reference doc (single source).blockedis a valid value but written manually (escalation only).05-reviewdoesn't auto-setverified— the caller does (keeps that agent-reachable skill read-only on the plan).🤖 Generated with Claude Code