Release v1.0.0 — everything booping does became a playbook

[A]

Everything booping does became a playbook. /playbook is now the only skill the plugin ships — groom, develop, retro, learn, code-review, setup, migrate and playbook-authoring all run as playbooks, discovered beside the ones you write yourself. Runs carry their own state and resume across sessions, and retro and code review became tracks of their own.

This release is dogfooded: the repo's own Project Vault is checked in at vault/ — browse a finished plan, the targeted lessons the loop accumulated, or a retrospective to see what the artifacts actually look like. 1.0 works end to end but is beta-grade; expect rough edges, and if installation gives you trouble, run /playbook setup and talk the problem through with it.

⚠️ Breaking changes

• /chat and /help are gone — /playbook is the plugin's only skill.
• Your config.yaml needs re-nesting under a core namespace: a key one playbook owns at core.{name}_playbook, shared keys directly under core.
• Existing Project Vaults must migrate — a vault behind the shipped migrations blocks every render surface with a notice until you run /playbook migrate.
• Per-playbook _lessons/ directories and the lesson step: key no longer route lessons — legacy content surfaces a migration note instead.
• Playbook names must be unique across the core, global and project levels; a same-named playbook used to shadow silently, and now stops the run.
• In your own playbooks, agent: became detached: (a leftover agent: key stops the run), and the @head shorthand was dropped in favour of the git_commit macro.

Migration notes at the end.

Running the loop

• Runs resume where they stopped. Each run persists its status to its own artifact, so a later session picks it up from the state frontier rather than from the driving conversation. An active groom or develop run can also be cancelled from any point — a real terminal outcome with its own exit hooks, not an abandoned file.
• Retro is its own track. Develop closes a plan at done immediately instead of holding it open. Retro and learn advance a standalone retrospectives/{slug}.md, linked back from the plan's retro: key; retro queues every done plan not yet covered, mines session logs and the sprint diff for what actually happened, and takes your raw feedback before triaging by root cause.
• Code review is its own track, and re-review is first class. Every review persists as codereviews/{plan}/{timestamp}.md moving through in-agent-review → human-review → done, while the plan carries the full code_reviews: history and stays in the queue — so a plan can be reviewed, fixed, and reviewed again without leaving its track. You give the verdict; only approved fixes are applied.
• Groom asks less. It runs its steps in the driving session rather than one sub-agent per step, and stops at a single approval gate near the end instead of four confirm points. Codebase and web research still run as parallel detached passes, and a cross-review pass runs when you name a validator agent.
• A plan is a directory — plans/{slug}/ holds its index.md, briefing and web research together.
• Setup takes a repo from any state to a working project: machine config, scaffolded Project Vault, .booping marker, and a home-dir symlink for Obsidian. It skips phases already satisfied, so re-running it reports state instead of changing it, and seeds fresh vaults at the highest shipped migration id.
• sprints.md reports what a sprint cost — active time excluding every stretch the run spent waiting on you, alongside token totals and the models that ran.

Making it yours

• Lessons route by target. They live in two flat _lessons/ roots — the global level and your Project Vault — and each carries a targets: list naming exactly where it applies: {playbook}, {playbook}/{step}, agent:{id} or skill:{name}. An untargeted lesson injects nowhere. Shaping an agent for one project is now a lesson rather than a separate extension file.
• Three delegation levels, declared per step by detached: — inline (the runner performs it), assisted (the runner performs it but hands heavy reads to your configured research agent, resuming it across a loopback rather than respawning), and detached (its own sub-agent). core.research_agent points assisted reads wherever you like.
• Subgraphs. A graph: node can be a subgraph — its own dependencies, an inner graph of steps, an optional prose repeat:, one nesting level.
• Playbooks as templates. jinja: true renders preamble and step bodies against live project context. A step is a directory holding prompt.md, optionally per-model bodies (opus-5.md, fable-5.md) and its own eval suite. Bodies load one at a time, so a run's context grows with the graph it walks, not with every body the playbook contains.
• Config, queries and scaffolds. Settings layer across the core, global and project levels, later winning, and any key loads at any level without an unknown-key warning — review templates now layer the same way lessons already did. Vault frontmatter became queryable through config-declared query specs, with --where filters, sorting and projection. Config can also declare scaffold trees and argv macros that rendered bodies call through macro().
• Hooks got sharper. A frontmatter-update hook can write to any workdir-relative file with {instance} interpolation, not only the machine's own artifact; script hooks resolve from shared _scripts/ roots, playbook-local first, and take arguments, so one parameterised script replaces a family of near-duplicates.
• playbook-authoring ships in core — it drives a new playbook from brief and decomposition through manifest, then per step a spec, fixtures, prompt and eval suite driven to green.

Other changes

• The shared plan-lifecycle vocabulary is gone; each artifact moves only through its own playbook's states: machine.
• sprints.md is seeded once at setup as a live Obsidian Bases view and never regenerated; render-sprints was retired.
• Learn shows the full playbook table of contents and pins each lesson's exact targets: before writing.
• Develop's intake renamed awaiting-plan-review to awaiting-approval.
• Project resolution falls back to vault containment on a marker miss, so a workdir inside a vault assembles the same context as a repo workdir.
• The pre-1.0 migration set was collapsed into three: vault layout, tracks and lessons, session metrics.
• Testing infrastructure: hermetic renders, committed playbook report snapshots, mdcheck structural rules, parallel CI jobs.
• Internal rendering, transition-engine and CLI work behind all of the above.

Migration notes

1. Update the plugin, then open any project and run /playbook migrate. It surveys what is pending against your marker's watermark, applies each migration in id order on one up-front approval, and commits each to the vault separately. A failing migration halts and names the id, the failure, and a hand-applicable remedy.
2. Re-nest your config.yaml under core.
3. In your own playbooks, rename agent: to detached: and replace @head with the git_commit macro.
4. Rename any playbook whose name collides across levels — the listing flags the clash.
5. Move per-playbook lessons into a flat _lessons/ root and give each a targets: list.