feat(aidd-dev): track plan lifecycle status in frontmatter#251
Draft
alexsoyes wants to merge 20 commits into
Draft
feat(aidd-dev): track plan lifecycle status in frontmatter#251alexsoyes wants to merge 20 commits into
alexsoyes wants to merge 20 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) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
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) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
alexsoyes
force-pushed
the
feat/plan-status-lifecycle
branch
from
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) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
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) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
`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) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
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) <[email protected]>
Signed-off-by: alexsoyes <[email protected]>
…dup examples The blocked condition examples (payment, OAuth/biometric, unreadable secret) belonged in blocked.md only. The agent now points to the reference instead of restating them. Agents can't @-include (that mechanism is scoped to skills), so it is a named pointer; the full list reaches the agent via the SKILL.md @-load on the 02-implement path. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
F1: plan-status.md attributed the blocked decision to "implementer decides", but the stuck-loop case is decided by the implement layer (it counts retries); the agent only surfaces physically-impossible. Set written-by to "implement layer". F2: the 02-implement transversal rule restated the two blocked categories already in blocked.md; now it only points to the reference. F3: blank line after blocked.md frontmatter for consistency. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
Major: master-plan-template used `blocked` for sequencing gates, which contradicts the centralized lifecycle meaning (blocked = needs a human). A gated, not-yet-started child is `pending`; reword gate language to "gated until" so `blocked` is reserved for the lifecycle state. Minor: plan-status.md said "agents never write status", but the planner agent runs 01-plan which writes `pending`. Scope the claim to the reviewer and implementer agents. Reviewer verdict was ship (quality 86); these are the two real findings. The @-citation finding is intentionally left as prose (SKILL.md does the @-load; actions reference by name). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
…only notes plan_status was produced (planner, 02-plan) but consumed nowhere, and it collided with the persisted `status` field (same "done" word, opposite phase). Remove it; planning outcome is already conveyed by plan_path and decisions_blocked. Drop the "reviewer is read-only" reminders in 04-review and 02-review-functional: the reviewer agent's charter (reviewer.md) is the single source, and the review skills run as that agent. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
01-plan plans no longer carry `success_condition`, `iteration`, or `created_at`: none are read by the SDLC flow (only `objective` is, in 05-ship). They were For-Sure execution mechanics left over from when the template was shared. For-Sure keeps `success_condition` (it runs the command) and `iteration` (it increments), drops only `created_at` (unread). Also removes the stale "synced from 01-plan" note — the two templates now diverge by design. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
…ename "plan_path carries status: done" read as if the status were in the path or filename. Reword to "the plan's frontmatter status is ..." and "in the plan frontmatter at plan_path" so there is no ambiguity — the filename has no status suffix. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
The SDLC 03-implement action should not carry implement-layer status or blocked logic - that lives in the implement skill (02-implement) and the blocked reference. Revert this file to its original state. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
blafourcade
reviewed
Jun 7, 2026
| | `pending` | created, not started | `01-plan` | at plan creation | | ||
| | `in-progress` | implementation started | implement layer (SDLC `03-implement`; standalone `02-implement`) | at the first implementer pass | | ||
| | `done` | implemented, not yet reviewed | implement layer | whole plan implemented (no milestones remain, `items_remaining` empty) | | ||
| | `verified` | reviewed and approved | review layer (SDLC `04-review`) | review verdict = ship / approve | |
Contributor
There was a problem hiding this comment.
Pas possible de mettre shipped ? Ca me parait compliqué @alexsoyes
Contributor
Author
There was a problem hiding this comment.
shipped ça implique une MEP et c'est pas forcément le cas, ça peut être local ou remote btw
Contributor
There was a problem hiding this comment.
La notion de shipped pour nous c'est poussé en remote si tu regardes partout et les slides, pas de notion de MEP
…ter status For Sure tracked task state via filename suffix (.pending.md -> .in-progress.md -> .done.md). Move it onto the same frontmatter `status` field as the rest of the lifecycle: stable filename `<task-name>.md`, state in `status` (pending -> in-progress -> done). - init-tracking: stable filename; resume/detection reads frontmatter `status` instead of globbing suffixes; creates with `status: in-progress`. - autonomous-loop: on success_condition TRUE, set `status: done` instead of renaming to .done.md; dropped final_file output. - template/SKILL/README updated; no filename status suffix anywhere. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
…e source Rules were restated as prose in action/template/SKILL files instead of living once in their reference. Each rule now has a single home: - "filename carries no status suffix" + ownership: only plan-status.md (removed from 01-plan action, plan-template, for-sure template, the 04-review "(orchestrator, not agent)" parenthetical). - blocked escalation rule: only blocked.md (removed the 02-implement SKILL transversal rule that duplicated it; trimmed the action step to the bare write). Actions now just do their step; the rules are read from the reference. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
The retry budget (3 no-progress / 10 total) and stuck-loop counting were over-engineered for the need. `blocked` now means one thing: the work is physically impossible for the AI (payment, human login, unreadable secret) -> set `status: blocked` and escalate. The implementer surfaces it; the implement layer writes the status. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
03-implement re-described the spawn/loop/status logic that 02-implement already owns. Make it a thin delegate: invoke `aidd-dev:02-implement`, which loops to completion and writes the plan `status` (in-progress -> done, or blocked). The orchestrator stays thin, status is written once (in 02-implement), and the SDLC flow advances the plan again - pending (01) -> in-progress/done (03 via 02-implement) -> verified (04). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
`items_remaining` was the implementer agent's per-pass field. Since 03-implement now delegates to 02-implement, that looping is internal to the implement skill; the only SDLC-level iterate input is `fix_list` (returned by 04-review). Removed the dead reference. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
Independent review (iterate, 58/100) caught a broken delegation contract and several doc defects. Fixes: - Revert the 03->02-implement delegation: 02-implement accepts plan/branch, not the plan_path/fix_list that 03 claimed to pass, so review-driven scope narrowing was silently lost. 03 again spawns the implementer directly and writes status itself (in-progress/done/blocked). This also un-breaks 00-sdlc/SKILL.md, whose action table already describes 03 as "implement via implementer". - plan-status.md: phrase the done/in-progress rows in plan terms, drop the implementer-only `items_remaining` from the canonical status doc. - For Sure: differentiate the tracking template (name: for-sure-tracking, documents why it extends 01-plan with success_condition/iteration); fix the README claims that it "uses the 01-plan template"; create at status: pending and let the loop move it to in-progress; resume detector handles pending. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
Re-audit (88/100) found the 01-plan template still described itself as "the autonomous-loop tracking file", contradicting the For-Sure template separation: both templates claimed that role. The autonomous-loop tracking file is now exclusively for-sure-tracking. Trim the 01-plan description to a plain plan and regenerate CATALOG.md. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: alexsoyes <[email protected]>
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
2 participants
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 was never advanced. This moves task/plan lifecycle into a frontmatterstatusfield (filename suffixes removed everywhere, For Sure included) so plans reflect real progress and can back a kanban that links user stories to plans.🛠️ How it works
statuslives in frontmatter (pending | in-progress | done | verified | blocked), never in the filename — stable identity for kanban links. Canonical table: plan-status.md, loaded once via@from 01-plan/SKILL.md. Every rule lives in its reference; actions just do their step.done= implemented,verified= reviewed. Agents never writestatus; only plan creation and orchestration do.pending01-plan(creation)in-progress/done02-implement(SDLC03-implementdelegates to it; also used standalone)verified(or back toin-progress)04-reviewblocked03-implementdelegates to02-implementinstead of re-describing the loop; the spawn/loop/status logic lives once in the implement skill.<task-name>.md, state instatus; the loop setsstatus: donewhensuccess_conditionpasses (instead of renaming to.done.md) and resumes by readingstatus.success_condition/iteration/created_atfrom 01-plan (unread by the SDLC — onlyobjectiveis, in05-ship) and the unconsumedplan_statusoutput. For Sure keepssuccess_condition/iteration.🧪 How to verify
pending → in-progress → done → verifiedwhile the filename stays suffix-less.grep -rn '\.pending\.md|\.in-progress\.md|\.done\.md' plugins/aidd-devreturns nothing — no filename status suffix anywhere.05-reviewdoesn't auto-setverified(the caller / SDLC04-reviewdoes).04 → 03iterate loop is not capped.🤖 Generated with Claude Code