spec-to-plan: multi-plan bundles with frontmatter-typed Plan/Task#13
Merged
Conversation
Rework spec-to-plan from one flat plan/plan.md per project to multiple plan bundles under plan/<Plan-id>-<slug>/. Each bundle is a self-describing OKF unit: plan.md (type: Plan), tasks/Task-NNN-*.md (type: Task), index.md (type: index), log.md (type: log). - Add Step 0 (plan selection): continue an existing plan or start a new one; skip when the target plan is already fixed in context. - Task metadata is now the machine contract in frontmatter: relationships depends_on (DAG) / references (requirement ownership) / verifies (test traces), plus flat status/track/priority. Replaces prose status. - Steps 1-3 parameterized to the bundle path; tasks/README.md replaced by index.md; log.md records plan lifecycle. - Workflow parity: def.yaml target -> plan/<id>-<slug>/plan.md; template type implementation-plan -> Plan. Adopts the registered Plan/Task archetypes from spec-artifacts-process so bundles are quire-validatable and parseable for GitHub-issue sync. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cover the new multi-plan output: a scenario driving spec-to-plan to author a plan bundle (type: Plan plan.md + reserved index/log + >=3 type: Task files with relationships depends_on/references/verifies) and assert it via the artifacts (Plan>=1, Task>=3) + files + quire-validate checks. Adds the matching EV-027 row to spec/evals.md (TM-002). Closes the eval coverage gap for the multi-plan bundle shape; Step-0 multi-plan selection remains a follow-up scenario. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a dedicated user story for the multi-plan capability: a project holds several focused plans, each a self-describing bundle, and the planner can start a new plan or continue an existing one (Step 0 selection). Wire it into the eval matrix (TM-002 covers US-008) and retag EV-027 to US-008. Add EV-028: Step-0 multi-plan selection — seed an existing Plan-001 bundle, drive spec-to-plan to start a second independent Plan-002, assert >=2 Plan artifacts and a Plan-002 bundle, all validating. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The seeded Plan-001 fixture hardcoded mixed-case ids (Plan-001/Task-001), which the published spec-artifacts-process schema (uppercase-only id regex) rejects — so EV-028 failed quire validate on the FIXTURE, not the agent's output (the agent authored valid uppercase ids and a correct Plan-002 bundle; EV-027 passed the same way). Use uppercase PLAN-001/TASK-001 in the seed, valid under both the published schema and the loosened (mixed-case) schema from the schema PR, so the scenario no longer depends on that PR. Correct the now-inaccurate "requires mixed-case" comments on EV-027/EV-028. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add the common "spec changed, regenerate the plan" flow that was missing (EV-027 only creates, EV-028 only starts a second plan): - EV-029: seed a PLAN-001-core bundle covering FR-001, add FR-002 to the spec, drive spec-to-plan to UPDATE that plan in place (add a task, refresh index/log) without spawning a second plan. Validated via agent-pty (PASS): the agent added TASK-003/004 for FR-002, updated references/index/log, and left a single plan. - Harness: add `absentFiles` (globs that must match zero files) and an `artifacts` `max` bound so a scenario can assert exactly one Plan. - Skill: flesh out Step 0's thin "continue → appends/updates" into an "Updating an existing plan" section (diff coverage, add only missing tasks, preserve in-progress/done status, reconcile changed/removed requirements, refresh index+log, never spawn a second plan). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.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
1 participant
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.
Why
spec-to-planproduced one flatplan/plan.mdper project, and task metadata (deps/status/track) lived in prose — so nothing downstream could build the DAG or sync to GitHub issues.What
Rework to multiple plan bundles under
plan/<Plan-id>-<slug>/, each a self-describing OKF unit:plan.md(type: Plan),tasks/Task-NNN-*.md(type: Task),index.md(type: index),log.md(type: log).relationships:depends_on(DAG) /references(requirement ownership) /verifies(test traces), plus flatstatus/track/priority.def.yamltarget + templatetype: Plan).Depends on / pairs with
quire validate)Verification
make build+ 102 tests pass. A migrated electron-hello bundle passesquire validate --scope <proj> "plan/**/*.md", and the github-projects parser extracts the full DAG from it.Follow-ups in this PR
spec-to-planeval scenario + any single-plan user-story language.🤖 Generated with Claude Code