End of Booping

Final public release. booping continues as a private project; this repository is published as is and is unlikely to receive further updates.

booping 2.0 turns the groom → develop → retro → learn loop into a managed system. A project-manager now sits on top of the loop: every session in a booping repo starts with it, and it carries your requests through the playbooks for you. Underneath, the old lessons grow into specs — values, rules, decisions and stories that steer every run — and runs can now go headless and autonomous, with a record of everything they decided on your behalf.

⚠️ Breaking changes

• Lessons are now rules. _lessons/ directories (project, global and playbook-local) are no longer read. Their replacement is the rule record in the specs tiers, with the same targets: and brief: semantics. Migration 004 (Lessons become rules) converts what you have.
• The vault moves. A project's spec records live at the vault root beside plans/ (migration 005 (Project specs to vault root)), and stories become feature-sized (migration 006 (Stories become feature-sized), which pins the old story schema for a project that still has old-shape stories instead of rewriting them).
• CLI verbs were renamed. If a playbook or hook of your own calls the CLI: scaffold → create, frontmatter-update and marker-set → set, config-get → config, playbook-state / playbook-transition → state / transition (which now take the file itself; --playbook narrows an ambiguous match). Hook verbs follow: set and script.
• core.sprint.max_milestones_per_agent is gone. Develop packs milestones into a worker's briefing by story points now, core.sprint.max_sp.
• New runtime dependency: mdcheck. Groom checks every milestone file with it — cargo install markdown-checker --version 0.1.2 --locked.

See Upgrading below.

The project-manager is the entry point

In a repo with booping, a SessionStart hook tells every session to start with /booping:playbook project-manager, and every interaction goes through it — specs work, plans, sprints, reviews, retros and plain questions alike. The manager does none of that work itself; it manages and orchestrates:

• It opens with the project's status and names what to act on: finished runs to acknowledge, items waiting on you, plans ready for development, sprints without a review.
• Everything that must outlive the session — work for later, a question waiting on you — becomes an open item (open-items/OI-NNNN.md) in your own words.
• It classifies each item and carries it along its route: a tiny fix straight to a worker in a batch, a plan through groom → develop → code review → merge, a question answered from the specs, a decision recorded.
• Supervised (the default) it stops for your plan approval and the merge, nothing else. Autonomous — when you tell it so — it settles every gate itself and logs each decision for you to review.

Specs: what the project knows, applied to every run

The specs are typed markdown records about why the project is the way it is: values, rules, ADRs, conflicts, stories, ideas, references and runbooks.

• Three tiers — the core rules shipped with booping, your global tier across all projects, and the project tier in the vault. Records are numbered and referenced by namespace (booping:rule/0003).
• Rules steer runs. An accepted rule with targets: — a playbook, one of its steps, an agent or a skill — is injected into exactly that surface as a ## Rules section. A lesson learned in a retro becomes a rule through learn, and from then on it reaches the step it is about.
• The specs playbook works the records with you: settles values, records decisions and ideas, reviews the set, syncs it with the code and works the open items.
• A specs site — booping specs site builds a static, searchable HTML site of the records with a review panel for comments; GitLab CI templates to publish it ship with the plugin.
• Stories are feature-sized: one story is one deliverable feature, with scenarios, edge cases, out-of-scope and criteria, and a priority.

Headless and autonomous runs

• booping run groom|develop|code-review launches a recorded run in the background. Each writes a run record (runs/{id}.md, running → finished or failed) and a log, and booping status runs shows them — including runs whose process died. booping run ack clears a handled one.
• An autonomous run never waits for you at a gate: every decision it takes in your place is one file under agent-decisions/, which the manager lists for your review before a merge.
• When you correct a run, your words are kept verbatim under corrections/, and retro picks them up.

Groom drafts in one pass

Groom now researches, then drafts the whole plan into one draft.md, cuts it into milestone files with booping plan split, and checks every milestone against its contract with mdcheck — fixing the draft until it is clean, at most three rounds. Develop packs consecutive milestones into one worker briefing up to a story-point budget.

Playbooks for authors

• Rules replace lessons everywhere a playbook used to read them; --no-rules opts a render out.
• Supervised and autonomous runs are formalised for every playbook: an autonomous run auto-confirms review gates and logs its decisions; a STOP notice and an always-asked question still stop.
• makemigration — a playbook for authoring a vault migration when a change reshapes what vaults hold; migrate applies them, automatically by default (core.auto_migrate).
• Standalone state machines (such as open items) live beside a playbook's run machine.

Other changes

• A new ADR scorer agent routes a draft ADR and scores its alternatives.
• The task-tracker CLI follows the renamed verbs.
• Docs site: new pages for the project-manager, the specs and the specs playbook; quick start and session start rewritten around the manager.
• The repository's own vault is converted to the specs format — the dogfooding behind all of the above.
• Benchmark tooling moved out of this repository.

Upgrading

1. Update the plugin to 2.0.0.
2. Install mdcheck: cargo install markdown-checker --version 0.1.2 --locked.
3. Run /playbook setup once per project: it now also sets up your global specs tier (namespace defaults to your user name) and the project tier at the vault root. Anything already in place is detected and skipped.
4. Run /playbook migrate in each project, or just start working: with core.auto_migrate at its default, the first render that finds the vault behind runs the pending migrations — 004 (Lessons become rules), 005 (Project specs to vault root), 006 (Stories become feature-sized) for a 1.1.x vault — and resumes. It asks before touching uncommitted work.
5. Update any playbook or hook of your own that calls the renamed CLI verbs, and set core.sprint.max_sp if you had customised max_milestones_per_agent.
6. Start a session and run /booping:playbook project-manager.