buildline 0.5.1 → 0.7.0

package/templates/stations/new.md

@@ -24,16 +24,14 @@ State the type and the reason in one line. The person can override.
 
 ## 3. Create the feature
 
-Preferred: run `npx buildline new "<title>" --type <type>`. It creates `.buildline/features/<id>-<slug>/` with `feature.json`, `spec.md` and `progress.md`.
+Run `node .buildline/bin/feature.mjs new "<title>" --type <type>` (add `--owner "<name>"` if the person told you who owns it). It creates `.buildline/features/<id>-<slug>/` with `feature.json`, `spec.md` and `progress.md`, and sets the starting status: `build` for a fix, `spec` otherwise.
 
-If the CLI isn't available, do it by hand: next id = highest existing id + 1, zero-padded to 3 digits; slug = kebab-case title (max 5 words); copy the files from `.buildline/templates/`.
-
-Then fill in `spec.md → ## Brief` (problem, who, outcome, open questions) and set `owner` in `feature.json` if the person told you who owns it.
+Then fill in `spec.md → ## Brief` (problem, who, outcome, open questions).
 
 ## 4. Route
 
-- `fix` → set status to `build`. In `spec.md`, also fill `## Acceptance` with a single scenario that reproduces the bug (it must fail before the fix). Next: `/buildline-build <id>`.
-- `feature` → status `spec`. Next: `/buildline-spec <id>`.
-- `epic` → status `spec`. Next: `/buildline-spec <id>`, which will end by proposing the split into child features.
+- `fix` → it starts at `build`. In `spec.md`, also fill `## Acceptance` with a single scenario that reproduces the bug (it must fail before the fix). Next: `/buildline-build <id>`.
+- `feature` → it starts at `spec`. Next: `/buildline-spec <id>`.
+- `epic` → it starts at `spec`. Next: `/buildline-spec <id>`, which will end by proposing the split into child features.
 
-Append a `history` entry to `feature.json`: `{ "at": "<ISO date>", "station": "new", "note": "<type and one-line reason>" }`.
+Record why: `node .buildline/bin/feature.mjs log <id> "<type and one-line reason>"`.

package/templates/stations/plan.md

@@ -6,19 +6,14 @@ Resolve the feature from `$ARGUMENTS`, or use the most recent feature with statu
 
 ## Write the tasks
 
-Write them into `feature.json → tasks` (replace the placeholder):
-
-```json
-{
-  "id": "T1",
-  "title": "Add `saved_carts` table and model",
-  "covers": ["R1", "A2"],
-  "verify": "`npm test -- saved-cart.model` passes; migration runs up and down",
-  "passes": false,
-  "notes": ""
-}
+Add them in order, one command per task (ids T1, T2, … are assigned for you):
+
+```bash
+node .buildline/bin/feature.mjs task <id> add "Add saved_carts table and model" --covers R1,A2 --verify "npm test -- saved-cart.model passes; migration runs up and down"
 ```
 
+Add `--parallel` to tasks that could run alongside the previous one.
+
 Rules:
 
 - **Small**: each task fits in one focused session and one commit, usually under ~200 changed lines.
@@ -26,7 +21,7 @@ Rules:
 - **Verifiable**: `verify` says exactly what to run or observe. "Works" is not a verification.
 - **Traceable**: `covers` lists the requirement and acceptance ids it moves forward. Every `A*` scenario must be covered by at least one task.
 - **Test-first where it's cheap**: when a task introduces logic, its first step is a failing test for the acceptance scenario.
-- **Ordered**: dependencies come first. Mark tasks that could run in parallel with `"parallel": true`.
+- **Ordered**: dependencies come first. Mark tasks that could run in parallel with `--parallel`.
 - Include the boring tasks: migrations, feature flags, docs, analytics events, cleanup of temporary code.
 
 Then write a one-paragraph `## Plan` summary in `spec.md` (approach, order, risks) so humans don't have to read JSON.
@@ -39,6 +34,6 @@ Then write a one-paragraph `## Plan` summary in `spec.md` (approach, order, risk
 
 ## Handoff
 
-- Set status to `build`. Append a `history` entry.
-- **Approval:** at autonomy ≤ 2, ask the person to approve the plan and record `approvals.plan` only on an explicit yes. At L3+, continue without waiting.
+- **Approval:** at autonomy ≤ 2, ask the person to approve the plan and record it only on an explicit yes: `node .buildline/bin/feature.mjs approve <id> plan --by "<their name>"`. Until then the feature stays at `plan`. At L3+, continue without waiting.
+- Then `node .buildline/bin/feature.mjs move <id> build --note "<n> tasks"`.
 - Next: `/buildline-build <id>`, or `/buildline-autopilot <id>` to run build → verify → review unattended.

package/templates/stations/review.md

@@ -34,4 +34,4 @@ Write `## Review` in `spec.md`: a summary of what changed and why, risk areas to
 
 ## 5. Route
 
-When there are no open blockers or should-fix findings: status `ship`, history entry, next `/buildline-ship <id>`. A human still approves the merge at every autonomy level.
+Blockers and should-fix findings become tasks (`node .buildline/bin/feature.mjs task <id> add "…"`) and the feature goes back with `node .buildline/bin/feature.mjs move <id> build --note "<n> findings"`. When there are none: `node .buildline/bin/feature.mjs move <id> ship --note "review clean"`, next `/buildline-ship <id>`. A human still approves the merge at every autonomy level.

package/templates/stations/ship.md

@@ -27,6 +27,6 @@ Specs are written for one change; the context files carry what lasts. Update the
 
 ## 4. Close
 
-- Set status to `done`, fill `metrics.shippedAt`, append a `history` entry with the PR link.
+- `node .buildline/bin/feature.mjs move <id> done --note "<PR link>"` (this records the ship date).
 - Append a final `progress.md` entry.
 - Suggest the next feature in the queue (`/buildline`).

package/templates/stations/spec.md

@@ -41,6 +41,7 @@ If `type` is `epic`, end by proposing 2–6 child features, each a thin, shippab
 
 ## 6. Approval and handoff
 
-- Set status to `design` (or `plan` if the change has no UX or architecture decisions; say why).
-- **Approval:** the spec needs human approval when autonomy ≤ 3. Ask: "Approve this spec?" Only when the person explicitly approves, record `approvals.spec = { "by": "<name or role>", "at": "<ISO date>" }`. Never record an approval on someone's behalf. They can also approve from `npx buildline ui` or with `npx buildline approve <id> spec`.
-- Append a `history` entry and suggest the next command.
+- **Approval:** the spec needs human approval when autonomy ≤ 3. Ask: "Approve this spec?" Only when the person explicitly approves, record it: `node .buildline/bin/feature.mjs approve <id> spec --by "<their name>"`. Never record an approval on someone's behalf. They can also approve in `npx buildline ui` or `npx buildline watch`. Until then the feature stays at `spec` and the board shows it waiting on them.
+- Once approved (or at L4), move on: `node .buildline/bin/feature.mjs move <id> design --note "<one line>"`, or `plan` if the change has no UX or architecture decisions (say why). The script refuses the move while a required approval is missing.
+- Record what happened: `node .buildline/bin/feature.mjs log <id> "spec drafted, waiting for approval"` (or what changed).
+- Suggest the next command.

package/templates/stations/verify.md

@@ -40,5 +40,5 @@ Save screenshots and logs to `.buildline/features/<id>-<slug>/evidence/`.
 
 ## 4. Route
 
-- All pass → status `review`, history entry, next `/buildline-review <id>`.
-- Any fail → status back to `build`. For each failure, add a new task to `feature.json` (`"title": "Fix A3: empty state copy"`, `"covers": ["A3"]`, `"passes": false`) and increment `metrics.reworks` in `feature.json`. Next: `/buildline-build <id>`.
+- All pass → `node .buildline/bin/feature.mjs move <id> review --note "A1–A<n> pass"`. Next: `/buildline-review <id>`.
+- Any fail → for each failure, `node .buildline/bin/feature.mjs task <id> add "Fix A3: empty state copy" --covers A3`, then `node .buildline/bin/feature.mjs move <id> build --note "<n> scenarios fail"` (this counts a rework). Next: `/buildline-build <id>`.