buildline 0.8.1 → 0.8.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "buildline",
-  "version": "0.8.1",
+  "version": "0.8.2",
   "description": "Install an AI software factory into any project. A spec-driven pipeline for Claude Code (and any AGENTS.md-compatible agent), for developers, designers and product managers.",
   "type": "module",
   "bin": {

package/src/install.js

@@ -125,6 +125,7 @@ export function buildEntries(root, config) {
     const subagentStation = Object.fromEntries(Object.entries(STATION_SUBAGENTS).map(([st, agent]) => [`${agent}.md`, st]));
     for (const f of fs.readdirSync(path.join(templatesDir, 'agents'))) {
       const m = subagentStation[f] ? modelFor(config, subagentStation[f]) : null;
+      // Subagents follow the session's model (`model: inherit`) unless buildline.json picks one for their station.
       const content = read(`agents/${f}`);
       add(`.claude/agents/${f}`, m?.cli === 'claude' && m.model ? content.replace(/^model: .*$/m, `model: ${m.model}`) : content);
     }

package/templates/AGENTS.block.md

@@ -47,4 +47,6 @@ A task only gets `"passes": true` after the gates pass **and** its own verificat
 7. **Ask, don't guess,** when the spec is ambiguous about user-facing behaviour.
 8. **Record state with the feature script.** `node .buildline/bin/feature.mjs move|task|log|block|approve …` stamps real times, keeps the history the team watches live, and refuses moves that skip a required approval. Never edit `feature.json` by hand.
 9. **Mark it blocked before you ask.** When you need an answer from a person, run `node .buildline/bin/feature.mjs block <id> "<the question>"`, then ask. When they answer, run `node .buildline/bin/feature.mjs unblock <id>` and carry on.
-10. **Respect model routing.** `models` in `buildline.json` can send a station to another tool (e.g. `"review": "codex"`). If a station is routed to a different CLI than the one you are, hand it off with `npx buildline step <station> <id> --headless` and summarise the result instead of doing it yourself.
+10. **Respect model routing.** `models` in `buildline.json` says who runs each station.
+    - **Another CLI** (e.g. `"review": "codex"`): hand it off with `npx buildline step <station> <id> --headless` and summarise the result instead of doing it yourself.
+    - **Another Claude model** (e.g. `"spec": "fable"`): the station's slash command switches model by itself when the person types it. You can't switch models, and opening the station yourself keeps yours. So when the next station runs on a different model than you, end with "Next: type `/buildline-<station> <id>`, it runs on <model>." Don't ask the person to switch models first; if they ask you to run it on that model, tell them to type that command. For stations that don't need the person (build, verify, review, and in the autopilot loop), you may instead run `npx buildline step <station> <id> --headless`, which runs it on its model, and summarise the result.

package/templates/agents/buildline-design-reviewer.md

@@ -2,7 +2,7 @@
 name: buildline-design-reviewer
 description: Reviews UX design notes, prototypes or implemented UI (via screenshots) against the project's design system, the spec's acceptance scenarios and accessibility basics. Use at the design and review stations for any user-facing change.
 tools: Read, Grep, Glob, Bash
-model: sonnet
+model: inherit
 ---
 
 You are a senior product designer reviewing a change for consistency, clarity and accessibility.

package/templates/agents/buildline-mapper.md

@@ -2,7 +2,7 @@
 name: buildline-mapper
 description: Maps an existing codebase (product purpose, architecture, conventions, design system, commands, hazards) into a compact summary for the factory's context files. Use during onboarding of an existing project or when the context files are stale.
 tools: Read, Grep, Glob, Bash
-model: sonnet
+model: inherit
 ---
 
 You are a staff engineer joining a new codebase. Produce the summary you'd want on your first day: dense, factual, with file paths as evidence. Read, don't modify anything.

package/templates/agents/buildline-reviewer.md

@@ -2,7 +2,7 @@
 name: buildline-reviewer
 description: Reviews a factory feature's diff against its spec and the project's principles for spec fit, correctness, security, maintainability and test quality. Use at the review station.
 tools: Read, Grep, Glob, Bash
-model: opus
+model: inherit
 ---
 
 You are a senior engineer doing a pre-merge review. Your goal is to find the problems that matter, not to show thoroughness.

package/templates/agents/buildline-spec-critic.md

@@ -2,7 +2,7 @@
 name: buildline-spec-critic
 description: Critiques a factory feature spec (spec.md) for untestable requirements, missing unhappy paths, contradictions and hidden scope. Use after writing or changing a spec, before design or planning.
 tools: Read, Grep, Glob
-model: sonnet
+model: inherit
 ---
 
 You are a sharp, constructive product reviewer. You review one `spec.md` from `.buildline/features/<id>-<slug>/`. Also read `.buildline/context/product.md` and `.buildline/principles.md` for context.

package/templates/agents/buildline-verifier.md

@@ -2,7 +2,7 @@
 name: buildline-verifier
 description: Independently verifies a factory feature against its acceptance scenarios by running gates, the app, tests and browser checks, then reports PASS/FAIL with evidence. Use at the verify station; never the same context that built the feature.
 tools: Read, Grep, Glob, Bash, Write
-model: sonnet
+model: inherit
 ---
 
 You are an independent QA engineer. You did not build this feature and you don't trust claims you haven't observed yourself.