@friedbotstudio/create-baseline 0.1.0

package/obj/template/.claude/agents/swarm-worker.md

@@ -0,0 +1,52 @@
+---
+name: swarm-worker
+description: Execute a single swarm task in an isolated git worktree. Receive a fully-specified recipe from the main context — a scenario recipe plus an implementation contract — then run `Skill(scenario)` followed by `Skill(implement)` and report JSON status. Make no design decisions and do not expand scope. Invoked exclusively by `/swarm-dispatch`; never elsewhere.
+tools: Read, Write, Edit, MultiEdit, Bash, Skill, Grep, Glob
+model: sonnet
+skills:
+  - scenario
+  - implement
+---
+
+You are a swarm worker. The main context has already decided what tests to write, what code to write, in which files. Your job is to execute that recipe — not to expand it, second-guess it, or design around it.
+
+This subagent operates under the **In-Session Constitution** (`CLAUDE.md`) and the **Genesis Prompt** (`docs/init/seed.md`). Article II of the constitution scopes your authority: *Decisions live in main context; subagents only execute pre-decided recipes.* You SHALL NOT exceed that scope.
+
+# Operating envelope
+
+Your worktree is **physically isolated** from the rest of the repo (Art. IV phase 6c, swarm worktree mode). Files you write are merged back to main only if they fall inside your declared `write_set`. Anything outside SHALL fail the merge audit and your task SHALL be marked failed. The orchestrator preserves the worktree on audit failure for inspection.
+
+# Inputs (provided by the caller)
+
+The caller's prompt SHALL contain two recipes and the swarm metadata. You SHALL execute against them verbatim — you SHALL NOT improvise, expand, or substitute.
+
+1. **Scenario recipe** — the list of failing tests to write. Each entry has `name`, `covers`, `assertion`, `fixtures`. The recipe also names an `out-of-scope` list and a `test target paths` field.
+2. **Implementation contract** — the failing test paths (after step 1 produces them), the `write_set` (exact source paths you may touch), the behavior contract (spec excerpts), and project conventions.
+3. **Swarm metadata** — `task_id`, `slug`, the AC list this task covers, the relevant spec excerpt.
+
+# Method (mandatory sequence)
+
+1. **Invoke `Skill(scenario)`** with the scenario recipe + test target paths + style anchors from the caller's prompt. Capture the test files written and the per-test verdict (`RED`, `PASS_UNEXPECTEDLY`, `ERROR`).
+2. **Halt condition.** If any test in step 1 returned `PASS_UNEXPECTEDLY` or `ERROR`, you SHALL stop. Set status to `failed` and put the test name + reason in `note`. SHALL NOT proceed to implementation.
+3. **Invoke `Skill(implement)`** with the failing test paths from step 1, the `write_set`, the behavior contract, and the project conventions — verbatim from the caller's prompt. The skill runs the RALPH loop (capped at 5) and returns `GREEN`, `RED`, or `BLOCKED`.
+4. **Report JSON** as your final output line — exactly this shape, nothing else after it:
+
+```json
+{"task_id": "<T-XXX>", "status": "done" | "failed", "files_touched": ["..."], "note": "<one short line>"}
+```
+
+- `status: "done"` SHALL be reported only if `Skill(implement)` returned `GREEN`.
+- `status: "failed"` SHALL be reported for `RED`, `BLOCKED`, scenario halts, or any other stop.
+- `files_touched` SHALL be the union of test files (from `scenario`) and source files (from `implement`) actually modified.
+- `note` SHALL be one short human-readable line explaining the outcome.
+
+# Constitutional constraints (binding — Art. II)
+
+- **You SHALL NOT pick scenarios.** The recipe is given. If it is incomplete or ambiguous, set `failed` with the gap named in `note`. SHALL NOT improvise scenarios.
+- **You SHALL NOT pick architecture.** The contract is given. If it conflicts with itself, set `failed` with the conflict named in `note`. SHALL NOT redesign.
+- **You SHALL NEVER write outside the `write_set`.** Even if you believe a fix requires it. If a write outside the set is genuinely necessary, set `failed` with the path in `note` — the orchestrator decides whether to re-plan.
+- **You SHALL NEVER invoke another subagent.** You are a leaf worker. The skills you use (`scenario`, `implement`, plus any project-specific skills the template was rendered with) run inside your own context.
+- **You SHALL NEVER run `git commit` or `git push`** (Art. VII). Merge is the orchestrator's responsibility via `swarm_merge.sh`.
+- **The final JSON line is the swarm protocol** and overrides any reporting habit. SHALL NOT wrap it in prose. SHALL NOT add commentary after it.
+
+If the caller's prompt does not provide both recipes, or the recipes contradict each other, you SHALL stop at step 1 and report `failed` with the gap named — do not attempt to fill in missing inputs from training data or context recall.

package/obj/template/.claude/bin/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for describing the origin of the Work and
+      reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Support. While redistributing the Work or
+      Derivative Works thereof, You may choose to offer, and charge a
+      fee for, acceptance of support, warranty, indemnity, or other
+      liability obligations and/or rights consistent with this License.
+      However, in accepting such obligations, You may act only on Your
+      own behalf and on Your sole responsibility, not on behalf of any
+      other Contributor, and only if You agree to indemnify, defend,
+      and hold each Contributor harmless for any liability incurred by,
+      or claims asserted against, such Contributor by reason of your
+      accepting any such warranty or support.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied. See the License for the specific language governing permissions
+   and limitations under the License.

package/obj/template/.claude/bin/NOTICE

@@ -0,0 +1,48 @@
+create-baseline — Claude Code baseline scaffolder
+Copyright 2026 Konark Bhardwaj
+
+This product includes software developed by The PlantUML Project
+(https://plantuml.com/).
+
+================================================================================
+PlantUML — deferred-fetch model
+================================================================================
+
+This baseline depends on PlantUML for diagram syntax validation
+(`plantuml_syntax_guard` hook) and rendering (`/spec-render` skill). The
+PlantUML jar itself is NOT bundled in this package; it is fetched at install
+time from the upstream GitHub release, with the bytes verified against a
+pinned sha256 before being written to disk.
+
+Upstream artifact:    plantuml-asl-1.2026.2.jar
+Upstream URL:         https://github.com/plantuml/plantuml/releases/download/v1.2026.2/plantuml-asl-1.2026.2.jar
+Pinned sha256:        c348f6a26d999f81fd05b5d49834bb70df9cf35fab0939c4edecb0909e64022b
+Pinned size:          19,395,808 bytes
+Local install path:   <target>/.claude/bin/plantuml.jar
+Upstream license:     Apache License, Version 2.0 (the `plantuml-asl-*.jar`
+                      build is the explicit Apache-only redistribution variant
+                      maintained by the PlantUML project for compatibility with
+                      Apache 2.0 redistribution requirements; see the LICENSE
+                      file in this directory for the full Apache 2.0 text).
+
+The fetcher (src/cli/plantuml.js) auto-detects an existing system `plantuml`
+binary on PATH and skips the download in that case. The flags `--no-plantuml`
+and `--require-plantuml` modify behavior: the former disables the fetch
+entirely, the latter promotes any fetch failure (network error or sha256
+mismatch) to exit code 4.
+
+================================================================================
+Why this NOTICE preserves the deferred-fetch framing
+================================================================================
+
+Apache 2.0 §4(d) requires that any pre-existing NOTICE file in the upstream
+distribution be preserved in derivative works. The `plantuml-asl-1.2026.2.jar`
+artifact carries Apache 2.0 licensing throughout; its META-INF may contain
+upstream attribution that should propagate forward when this baseline ships.
+This NOTICE file is the in-package record of that attribution, even though
+the jar itself is fetched rather than redistributed by this package.
+
+If you are auditing this package for compliance: the jar is the upstream
+artifact identified above, fetched verbatim from the upstream URL, byte-equal
+to the pinned sha256. This package redistributes the LICENSE and this NOTICE
+(both small text files) but not the jar.

package/obj/template/.claude/commands/approve-spec.md

@@ -0,0 +1,29 @@
+---
+description: Record human approval of a spec. The Spec Approval Guard hook blocks Claude from ever writing approval tokens; this command is the only sanctioned path. Must be user-invoked.
+argument-hint: "<slug | path-to-spec>"
+allowed-tools: Read, Bash(mkdir:*), Bash(date:*), Bash(basename:*), Bash(git:*), Write
+disable-model-invocation: true
+---
+
+The user has reviewed and approved the spec referenced by `$ARGUMENTS`. Record approval.
+
+How this works structurally: when the user typed `/approve-spec <arg>`, the `consent_gate_grant` UserPromptSubmit hook ran *before* this body was passed to Claude and wrote a short-lived consent marker at `.claude/state/.spec_approval_grant` whose slug is the bare slug derived from `<arg>`. The `spec_approval_guard` PreToolUse hook reads that marker on the approval-token Write and allows it when the marker is fresh and the approval filename's bare slug matches. Claude cannot forge the marker — that's what makes the gate structural.
+
+Steps:
+
+1. **Derive the bare slug** from `$ARGUMENTS`:
+   - `slug="${ARGUMENTS##*/}"` (strip any directory prefix)
+   - `slug="${slug%.md}"` (strip a trailing `.md`)
+   The same canonicalization runs inside `consent_gate_grant`, so the marker slug and the expected slug always agree.
+2. **Resolve the spec path**:
+   - If `$ARGUMENTS` contains a `/`, treat it as a path (absolute or relative to repo root).
+   - Otherwise the path is `docs/specs/<slug>.md`.
+   Verify the spec file exists at the resolved path. If not, stop and ask for the correct slug or path.
+3. **Write the approval token** to `.claude/state/spec_approvals/<slug>.approval` with:
+   - Line 1: `APPROVED`
+   - Line 2: epoch timestamp (`date +%s`)
+   - Line 3: absolute path to the spec file
+   - Line 4: git short SHA of the spec file at this moment (if in a git repo; use `git log -1 --format=%h -- "<resolved-path>"`, otherwise `N/A`)
+4. Confirm to the user: "Approved spec `<slug>`. Approval token written to `.claude/state/spec_approvals/<slug>.approval`. Downstream phases that depend on this spec may now proceed."
+
+Do NOT mark the spec itself as "Approved" inside the markdown — the Spec Approval Guard hook blocks that. The approval token is the authoritative record.

package/obj/template/.claude/commands/approve-swarm.md

@@ -0,0 +1,27 @@
+---
+description: Record human approval of a swarm plan. swarm-dispatch will not run until this approval token exists. Must be user-invoked — Claude cannot approve.
+argument-hint: "<slug — matches .claude/state/swarm/<slug>.json; .md is stripped if present>"
+allowed-tools: Read, Bash(mkdir:*), Bash(date:*), Bash(basename:*), Write
+disable-model-invocation: true
+---
+
+The user has reviewed the swarm plan referenced by `$ARGUMENTS` and approved it for dispatch.
+
+How this works structurally: when the user typed `/approve-swarm <slug>`, the `consent_gate_grant` UserPromptSubmit hook ran *before* this body was passed to Claude and wrote a short-lived consent marker at `.claude/state/.swarm_approval_grant` whose slug is the bare slug derived from `<arg>`. The `swarm_approval_guard` PreToolUse hook reads that marker on the approval-token Write and allows it when the marker is fresh and the approval filename's bare slug matches. Claude cannot forge the marker — that's what makes the gate structural.
+
+Steps:
+
+1. **Derive the bare slug** from `$ARGUMENTS` defensively (in case the user passed a path or a `.md`-suffixed name):
+   - `slug="${ARGUMENTS##*/}"` (strip any directory prefix)
+   - `slug="${slug%.md}"` (strip a trailing `.md`)
+   The same canonicalization runs inside `consent_gate_grant`.
+2. Verify the plan exists at `.claude/state/swarm/<slug>.json`. If not, stop and ask for the correct slug.
+3. Read the plan and confirm it has `status: "planned"` and a non-null `waves` array (i.e., the validator ran). If not, tell the user to re-run `/swarm-plan` first.
+4. Write `.claude/state/swarm_approvals/<slug>.approval` with:
+   - Line 1: `APPROVED`
+   - Line 2: epoch timestamp (`date +%s`)
+   - Line 3: plan path (`.claude/state/swarm/<slug>.json`)
+   - Line 4: task count + wave count from the plan (e.g., `tasks=7 waves=3`)
+5. Confirm to the user: "Swarm plan approved for `<slug>`. Run `/swarm-dispatch <slug>` to begin parallel execution. Tasks declared at plan time are the ONLY files each wave may write to — the boundary guard enforces this."
+
+Do NOT mark the plan file itself as approved in any status field — the approval token is the authoritative record (mirrors /approve-spec).

package/obj/template/.claude/commands/grant-commit.md

@@ -0,0 +1,19 @@
+---
+description: Grant consent for Claude to run `git commit`. Valid for 5 minutes. Required by the Git Commit Guard hook.
+argument-hint: "[optional note]"
+allowed-tools: Bash(mkdir:*), Bash(date:*), Bash(tee:*), Bash(git:*), Write
+disable-model-invocation: true
+---
+
+Write a consent token to `.claude/state/commit_consent` so the Git Commit Guard hook allows the next `git commit`. The token is the current UNIX epoch timestamp on line 1; any optional note goes on line 2.
+
+How this works structurally: when the user typed `/grant-commit`, the `consent_gate_grant` UserPromptSubmit hook ran *before* this body was passed to Claude and wrote a short-lived consent marker at `.claude/state/.commit_consent_grant`. The `git_commit_guard` PreToolUse hook (Write matcher) reads that marker and allows Claude to write the consent file because the marker is fresh. Claude cannot forge the marker — that's what makes the gate structural. The Bash-matcher leg of the same guard then enforces the consent token on the actual `git commit` invocation.
+
+Steps:
+
+1. **Git-repo precheck.** Run `git rev-parse --is-inside-work-tree 2>/dev/null`. If the exit status is non-zero, this project is not a git repository: refuse to write the consent token and tell the user "Not a git repository — `/grant-commit` is inapplicable. Per CLAUDE.md Article IV, gate C and `commit` are auto-excepted on non-git projects; the workflow ends after `/archive`. Persistence outside git is your responsibility." Stop here.
+2. Run `date +%s` to get the current epoch.
+3. Write the epoch (and the optional note `$ARGUMENTS` on line 2 if non-empty) to `.claude/state/commit_consent`, overwriting any prior token.
+4. Confirm to the user: "Commit consent granted at <epoch>, valid for 300s (until <HH:MM:SS local>). The next `git commit` will be allowed; forbidden flags (push, --amend, --no-verify, reset --hard, etc.) remain blocked regardless."
+
+Do not run `git commit` yourself in this command. The user asks explicitly when they want a commit; this command only opens the window.

package/obj/template/.claude/commands/init-project.md

@@ -0,0 +1,191 @@
+---
+description: Configure the baseline for this specific project. Invokes the `scout` skill, then `claude-automation-recommender`, populates `.claude/project.json`, pre-creates lazy directories, re-renders `swarm-worker.md` from its template with any stack-specific skills appended, appends a §16 addendum to `docs/init/seed.md`, runs `/audit-baseline`, and asks the user to restart Claude Code so changes take effect. Until this runs, the test/lint runner hooks emit guidance only.
+argument-hint: "[optional: stack hint, e.g. 'next.js + vitest' — usually unnecessary, auto-detected]"
+allowed-tools: Read, Write, Edit, Bash, Task, Skill, AskUserQuestion, Glob, Grep
+disable-model-invocation: true
+---
+
+# `/init-project` — bootstrap the baseline for THIS project
+
+User-only command. The 9-step protocol below mirrors `seed.md` §13. Each step is shown to the user; nothing happens silently.
+
+Skip steps already completed (e.g., re-runs after `configured: true`). Re-runs **replace** the §16 addendum wholesale; manual notes belong in a sibling section.
+
+Log every step transition to `.claude/state/init/<UTC-timestamp>.log` so partial failures and re-runs are debuggable.
+
+## Step 1 — Welcome
+
+- Print one line confirming you're at the repo root: `pwd`, then list `.mcp.json`, `CLAUDE.md`, `.claude/`.
+- Read `.claude/project.json → configured`. Tell the user one of:
+  - `configured: false` → "First run. The baseline is in project-agnostic mode. I'll scout your codebase, ask the recommender what to tailor, and propose a config."
+  - `configured: true` → "Re-running init. Will re-scout and replace §16 in seed.md. Continue? (otherwise abort.)"
+- If `$ARGUMENTS` was provided, note it ("user hint: `<...>`") and feed it into Step 3 as a stack-detection prior.
+
+## Step 2 — Pre-flight deps
+
+Verify the baseline's hard requirements + advisory ones:
+
+| Required | Check command | If missing |
+|---|---|---|
+| `bash` ≥ 4 | `bash --version` | Hard fail. The baseline cannot run. |
+| `python3` | `which python3` | Hard fail. Hooks won't parse JSON. |
+| `node` + `npx` | `which npx` | Hard fail. Both MCP servers need npx. |
+| `git` repo | `git rev-parse --is-inside-work-tree` | Soft warn. Swarm worktree mode falls back to shared. |
+| `plantuml` CLI | `which plantuml` | Soft warn. `plantuml_syntax_guard` runs in guide mode and `/spec-render` refuses without it. |
+
+For each soft warn, note it and proceed. For hard fails, stop here with the install command.
+
+## Step 3 — Codebase survey (whole-project, in main context)
+
+Survey the WHOLE project — not a task slice. Do this directly with Read/Grep/Glob/Bash; do not delegate to a subagent (the only baseline subagent, `swarm-worker`, exists strictly for `/swarm-dispatch` parallelism). Capture structured findings:
+
+- **Stack**: language(s), framework(s), package manager, runtime version targets.
+- **Test setup**: test framework, test glob conventions, current test scripts.
+- **Lint setup**: linter(s), formatter, type checker.
+- **Architecture signals**: monorepo? multiple deployable units? front-end + back-end split?
+- **External services referenced** (in code or config): databases, queues, third-party APIs, observability, project management tools.
+- **CI**: present? what runner?
+- **Conventions**: commit format, branch naming, code style notes from CLAUDE.md / CONTRIBUTING.md / README.
+
+Keep the survey under 400 lines. Include exact file paths for the strongest evidence of each finding.
+
+Save the survey to `.claude/state/init/<timestamp>.scout.md`.
+
+## Step 4 — Run the recommender (baseline-aware)
+
+Invoke the `claude-automation-recommender` skill via the Skill tool. **Always pass the survey from Step 3 as context** so recommendations are grounded in actual evidence.
+
+The recommender's SKILL.md instructs it to:
+- Treat baseline components as already-installed (16 hooks, 1 subagent, 35 skills, 4 commands, 3 MCPs).
+- Recommend additions only — never duplicate.
+- Never recommend new subagent types — decisions live in skills running in main context. The only subagent recommendation form is `additions.swarm_worker_skills` (stack-specific skills the `swarm-worker` should preload).
+- Output a JSON block alongside the narrative; the JSON shape is `{stack, project_json, additions, gaps}` where `additions` has `mcp_servers`, `skills`, `hooks`, `swarm_worker_skills` (no `subagents` field).
+
+Capture both the narrative and the JSON. Save the JSON to `.claude/state/init/<timestamp>.recommender.json`.
+
+## Step 5 — Aggregate + present
+
+Show the user one review surface before writing anything:
+
+1. **Detected stack** (from Step 3 + Step 4 JSON `stack` field). Confirm or correct.
+2. **`project.json` proposed values** (from JSON `project_json`, merged with baseline defaults):
+   - `test.cmd`, `lint.cmd`
+   - `tdd.source_globs`, `test_globs`, `exempt_globs`
+   - `destructive.hard_block_patterns` (baseline + extensions), `ask_patterns` (baseline + extensions)
+   - `swarm.isolation` (`worktree` if git, else `shared`)
+   - All other keys keep their baseline defaults.
+3. **Recommender additions** (from JSON `additions`): MCP servers, skills, hooks, and any `swarm_worker_skills` to preload — name + reason for each.
+4. **Gaps flagged** (from JSON `gaps`): things the baseline doesn't cover but might warrant a future spec.
+
+Use `AskUserQuestion` to confirm: "Apply these changes?" Options: `apply`, `apply with edits`, `cancel`.
+
+If `apply with edits`: take the user's adjustments inline, re-show the surface, ask again.
+
+## Step 6 — Apply
+
+Write to disk now. Do each sub-step in order; if any fails, stop and surface the error before continuing:
+
+1. **Pre-create lazy directories**:
+   ```bash
+   mkdir -p docs/{intake,brd,scout,research,specs,rca,security,archive}
+   mkdir -p .claude/state/{spec_approvals,swarm_approvals,swarm,harness,init}
+   ```
+2. **Add new MCP servers** (if any) → merge into `.mcp.json → mcpServers`.
+3. **Add new skills** (if any) → write `.claude/skills/<name>/SKILL.md`. Skills are landed *before* the swarm-worker re-render so any skill referenced by `additions.swarm_worker_skills` exists on disk when the worker file is written.
+4. **Re-render `swarm-worker`** with stack-specific skills:
+   - Read the template at `src/agents/swarm-worker.template.md`.
+   - Build the `SKILLS` value as a YAML list block. Always include `  - scenario` and `  - implement` (the worker's two mandatory skills). Append each skill in `additions.swarm_worker_skills` in dependency order (framework first, then testing/linting, then cross-cutting). Two-space indent, one skill per line.
+   - Substitute the four tokens — `{{NAME}}` → `swarm-worker`, `{{DESCRIPTION}}` → the canonical description (verbatim string below), `{{SKILLS}}` → the YAML list block, `{{ROLE_LINE}}` → the canonical first-paragraph role line. Substitution is literal string replacement.
+
+   **Canonical description (use verbatim for `{{DESCRIPTION}}`):**
+
+   > Execute a single swarm task in an isolated git worktree. Receive a fully-specified recipe from the main context — a scenario recipe plus an implementation contract — then run \`Skill(scenario)\` followed by \`Skill(implement)\` and report JSON status. Make no design decisions and do not expand scope. Invoked exclusively by \`/swarm-dispatch\`; never elsewhere.
+
+   **Canonical role line (use verbatim for `{{ROLE_LINE}}`):**
+
+   > You are a swarm worker. The main context has already decided what tests to write, what code to write, in which files. Your job is to execute that recipe — not to expand it, second-guess it, or design around it.
+   - Validate every skill named in `SKILLS` exists at `.claude/skills/<skill>/SKILL.md`. If any is missing, refuse the render and surface the gap.
+   - Write the rendered output to `.claude/agents/swarm-worker.md` (overwriting the baseline version with the stack-augmented one).
+
+   Recommender output **must not** propose new subagent types — only stack-skill additions for the existing `swarm-worker`. If you see a `subagents` field in the recommender JSON, ignore it and surface a warning that the schema is stale.
+5. **Add new hooks** (if any) → write `.claude/hooks/<name>.sh`, `chmod +x`, wire into `.claude/settings.json`. Must use bash + python3, no jq, follow §4.1 conventions.
+6. **Write `project.json`** with the agreed values, `configured: true`, **and a populated `additions` block**:
+   ```jsonc
+   "additions": {
+     "agents":              [],
+     "skills":              [<names of every entry in additions.skills[]>],
+     "hooks":               [<names of every entry in additions.hooks[]>],
+     "mcp_servers":         [<names of every entry in additions.mcp_servers[]>],
+     "swarm_worker_skills": [<names of every entry in additions.swarm_worker_skills[]>]
+   }
+   ```
+   `additions.agents` stays empty in this baseline — the recommender does not propose new subagents. The audit script reads this block and unions each set with the baseline `EXPECTED_*` set when checking names + counts. Names only — drop the `command`, `why`, etc. fields the recommender used; only the identifiers are needed for drift detection.
+
+## Step 7 — Update `seed.md` §16 addendum
+
+Append — or replace — the `## §16 — Project-specific configuration` section in `docs/init/seed.md`. Use the shape in seed.md §16:
+
+```markdown
+## §16 — Project-specific configuration
+
+Generated: <UTC timestamp>
+By: /init-project (run #<n>)
+
+### Detected stack
+- Language: ...
+- Framework: ...
+- Test runner / cmd: ...
+- Linter / cmd: ...
+- Package manager: ...
+
+### Recommender additions adopted
+| Kind | Name | Why |
+|---|---|---|
+...
+
+### Workflow tweaks
+- ...
+
+### Deviations from canonical seed
+- ...
+
+### Recommender output (verbatim JSON)
+```json
+<paste from Step 4>
+```
+```
+
+If §16 already exists, find its bounds (heading to next `## §` or EOF) and replace wholesale. Don't merge — re-runs are full replacements (seed §16 idempotency rules).
+
+## Step 8 — Drift self-check
+
+Invoke the `audit-baseline` skill via the Skill tool. It runs `audit.sh` and prints a pass/fail table of 60+ checks.
+
+- **PASS** → log it and proceed.
+- **FAIL** → STOP. Surface the failures. The most likely cause: Step 6 added a component that doesn't match seed §4 conventions (missing wiring in `settings.json`, or a new skill absent from the canonical name set). Tell the user what failed and offer to roll back Step 6.
+
+## Step 9 — Ready + restart
+
+Print a final summary:
+
+```
+✓ Baseline configured for <stack>
+  test.cmd:  <cmd>
+  lint.cmd:  <cmd>
+  swarm:     <isolation>
+  added:     <N MCPs, M subagents, K skills, J hooks>
+  audit:     PASS
+
+→ EXIT and restart Claude Code so new hooks, agents, skills, and MCP servers
+  load. After restart, run /triage "<your request>" to begin, or /harness
+  for the full pipeline.
+```
+
+**Tell the user to restart.** New MCP servers and hooks wired in `settings.json` only take effect on a fresh session. `/reload-plugins` covers some cases; restart is the safe default.
+
+## Constraints
+
+- **Steps 6 + 7 + 8 are atomic for the user.** If Step 8 fails, do not declare success at Step 9.
+- **Never write `configured: true` before Step 8 passes.** A FAIL at Step 8 means the project is in a broken state; leaving `configured: true` would lie to `setup_guard` and the welcome hook in CLAUDE.md.
+- **No silent decisions.** Every project-specific change appears in seed.md §16 so the next reader can see what diverged from baseline.
+- **Idempotent.** Re-running on the same project produces the same §16 (modulo timestamp + run number) and passes `/audit-baseline` cleanly.