@warren-dean/code-kit 0.21.0 → 0.22.1

package/hooks/mod/view.mjs

@@ -256,7 +256,7 @@ export function lanesPane(
             : l.branch
               ? ` · ${l.branch}`
               : ''
-        }`
+        }${l.story.slice ? ` · slice ${l.story.slice}` : ''}`
       : l.name === LEAD
         ? 'the main session'
         : (l.agent ?? '');
@@ -728,13 +728,25 @@ export function bandLines({
   team = null,
   questions = [],
   brief = [],
-  denied = [],
   reports = [],
+  working = false,
+  task = null,
+  elsewhere = [],
 }) {
   const lines = [];
-  // MISSION-1: the goal, now, next and the agents at work, above what needs the person.
-  const mission = missionLines({ state, loop, leadBusy, live, nextStep, combined });
+  // MISSION-1: the goal, now, next and the agents at work, above what needs the person. SESS-3: a working
+  // session's band holds only its own: no mission, queue, reviews or team.
+  const mission = working ? [] : missionLines({ state, loop, leadBusy, live, nextStep, combined });
   lines.push(...mission);
+  // SESS-4: a working session's task, or that it records one before changing code.
+  if (working)
+    lines.push({
+      kind: 'task',
+      text: task
+        ? `your task: ${task.title}${task.paths?.length ? ` · leasing ${task.paths.join(', ')}` : ''}`
+        : 'a working session: record your task before changing code (code-kit task "…" --touches …)',
+      actions: [],
+    });
   if (notice)
     lines.push({ kind: 'notice', text: notice, actions: [{ id: 'dismiss', label: 'Dismiss' }] });
   if (!state || state.kind !== 'ok') return lines;
@@ -758,31 +770,15 @@ export function bandLines({
       ],
     });
   }
-  // PERM-1: Claude Code's own permission check refused a call only the person can let through.
-  if (denied.length) {
-    const [d] = denied;
-    lines.push({
-      kind: 'denied',
-      text: `${denied.length > 1 ? `${denied.length} calls refused by Claude Code: ` : 'Claude Code refused '}${d.who}'s ${d.what}`,
-      denial: d,
-      denials: denied,
-      actions: [
-        ...(d.command ? [{ id: 'runDenied', label: 'Put it in the prompt' }] : []),
-        { id: 'deniedDone', label: 'Done it' },
-        { id: 'deniedNo', label: 'Not now' },
-      ],
-    });
-  }
-  // LOOP-3: a lane stalled past its restarts waits for the person.
+  // OWN-2: a call Claude Code's own permission check refused is the Lanes pane's activity, not a
+  // decision: the agent finds another way, or the lead asks the person (`code-kit ask`).
+  // LOOP-3, WHO-4: a lane stalled past its restarts is the lead's to sort out; the person sees a note.
   for (const f of loop?.flagged ?? [])
     lines.push({
       kind: 'stalled',
-      text: `${f.lane} stalled ${f.count} times on ${f.story}`,
+      text: `${f.lane} stalled ${f.count} times on ${f.story}: the lead decides how it goes on`,
       stall: f,
-      actions: [
-        { id: 'lanes', label: 'Lanes' },
-        { id: 'resumeStall', label: 'Resume' },
-      ],
+      actions: [{ id: 'lanes', label: 'Lanes' }],
     });
   // LOOP-5: under autonomy propose, each step waits for Go.
   if (loop?.proposal?.first)
@@ -797,15 +793,20 @@ export function bandLines({
         { id: 'loopOff', label: 'Off' },
       ],
     });
+  else if (loop?.proposal?.repeated)
+    // LOOP-8, WHO-4: a step the lead was asked for three times and didn't take is a note, not a decision.
+    lines.push({
+      kind: 'stuck',
+      text: `${loop.proposal.label}: still next after ${loop.proposal.repeated} prompts to the lead`,
+      proposal: loop.proposal,
+      actions: [{ id: 'go', label: 'Ask again' }],
+    });
   else if (loop?.proposal)
     lines.push({
       kind: 'proposal',
-      // LOOP-8: a step the lead was asked for and didn't take waits for the person to ask again.
-      text: loop.proposal.repeated
-        ? `${loop.proposal.label}: still next after ${loop.proposal.repeated} prompts. Ask the lead again?`
-        : `${loop.proposal.label}?`,
+      text: `${loop.proposal.label}?`,
       proposal: loop.proposal,
-      actions: [{ id: 'go', label: loop.proposal.repeated ? 'Ask again' : 'Go' }],
+      actions: [{ id: 'go', label: 'Go' }],
     });
   // LOOP-11, LOOP-12: what the loop read in the lead's reply holds it until the person says.
   const waitingLine = waitingOf(loop?.waiting);
@@ -833,7 +834,7 @@ export function bandLines({
       actions: [{ id: 'openDecision', label: 'Answer…' }],
     });
   // ASK-4: the brief's open questions, the person's to answer.
-  if (brief.length)
+  if (brief.length && !working)
     lines.push({
       kind: 'brief',
       text: `${plural(brief.length, 'open question', 'open questions')} in your brief: ${brief[0].question}`,
@@ -848,7 +849,7 @@ export function bandLines({
   const inReview = loopOff
     ? state.lanes.filter((l) => l.state === 'in review').map((l) => l.story)
     : [];
-  if (inReview.length) {
+  if (inReview.length && !working) {
     const [story] = inReview;
     const ids = inReview.map((s) => s.id).join(', ');
     lines.push(
@@ -891,7 +892,7 @@ export function bandLines({
   const autonomous = (check?.harness?.autonomy ?? 'autonomous') === 'autonomous';
   // SETUP-2: with no rules on the base yet, the lead puts them there first and then merges.
   const leadMerges = autonomous && (check?.delegatesMerge || check?.firstMerge);
-  if (next && !leadMerges)
+  if (next && !leadMerges && !working)
     lines.push({
       kind: 'queue',
       text: `${next.branch} is next to merge`,
@@ -899,9 +900,9 @@ export function bandLines({
       actions: [{ id: 'mergeQueue', label: 'Merge' }],
     });
   // TEAM-7, TEAM-9: what of the team needs this person.
-  lines.push(...teamLines(team, check?.lanes ?? {}));
+  if (!working) lines.push(...teamLines(team, check?.lanes ?? {}));
   // REPORT-3: a bug report for code-kit an agent drafted, for the person to read and send, or not.
-  if (reports.length)
+  if (reports.length && !working)
     lines.push({
       kind: 'report',
       text: `${reports.length > 1 ? `${reports.length} bug reports for code-kit to send: ` : 'A bug report for code-kit to send: '}${reports[0].title}`,
@@ -922,11 +923,14 @@ export function bandLines({
   // With the mission rows drawn, the loop's state and its Pause or Resume are on the `now` row.
   else if (mission.length) {
     // nothing more
-  } else if (loop?.state === 'elsewhere')
-    // LOOP-10: another session in this project runs the loop; this one never prompts its lead.
+  } else if (loop?.state === 'elsewhere' || loop?.state === 'unled')
+    // SESS-2: another session leads the project, or none does; this one never prompts its lead.
     lines.push({
       kind: 'loop',
-      text: 'the loop runs in another session',
+      text:
+        loop.state === 'elsewhere'
+          ? 'the lead is in another session'
+          : 'no session leads the project: the loop waits for one',
       actions: [{ id: 'leadHere', label: 'Lead from here' }],
     });
   else if (loop?.state === 'paused')
@@ -937,6 +941,13 @@ export function bandLines({
       text: `loop on${loop.last ? ` · last: ${loop.last}` : ''}`,
       actions: [{ id: 'pause', label: 'Pause' }],
     });
+  // OWN-1: another session's decisions are answered there: here, only how many.
+  for (const e of elsewhere)
+    lines.push({
+      kind: 'elsewhere',
+      text: `${plural(e.count, 'decision', 'decisions')} in session ${e.member}, answered there`,
+      actions: [],
+    });
   // BAND-4: a digit for every action, in the order they're drawn.
   let digit = 0;
   for (const line of lines)
@@ -969,9 +980,10 @@ export function waitingOf(waiting) {
       waiting,
       actions: [{ id: 'carryOn', label: 'Carry on' }],
     };
+  // WHO-4: a step the lead said it couldn't take is a note: the loop asks again once the project moves.
   if (waiting.kind === 'blocked')
     return {
-      kind: 'waiting',
+      kind: 'stuck',
       text: `${waiting.label}: the lead didn't take it${waiting.reason ? `: ${waiting.reason}` : ''}`,
       waiting,
       actions: [{ id: 'askAgain', label: 'Ask again' }],
@@ -1006,8 +1018,8 @@ export function band(lines, { Box, Text, Button }, onAction) {
     facts: 'yellow',
     question: 'cyan',
     brief: 'cyan',
-    denied: 'red',
     report: 'magenta',
+    stuck: 'yellow',
   };
   const LIVE = { quiet: 'yellow', stalled: 'red' };
   const LABEL = 8;
@@ -1516,7 +1528,17 @@ const CHOICES = {
   'compact.milestone': ['ask', 'auto', 'off'],
 };
 const shown = (v) =>
-  v === null || v === '' ? "the session's" : v === true ? 'on' : v === false ? 'off' : String(v);
+  v === null || v === ''
+    ? "the session's"
+    : v === true
+      ? 'on'
+      : v === false
+        ? 'off'
+        : v === 'lead'
+          ? 'the lead'
+          : v === 'person'
+            ? 'you'
+            : String(v);
 
 /**
  * The Settings view: each setting from `code-kit settings --json` with a control, and, once one is
@@ -1524,7 +1546,8 @@ const shown = (v) =>
  */
 export function settingsView(rows, pending, { Box, Text, Select, Input, Button }, handlers) {
   const control = (r) => {
-    const listed = CHOICES[r.key] ?? (typeof r.default === 'boolean' ? [true, false] : null);
+    const listed =
+      r.choices ?? CHOICES[r.key] ?? (typeof r.default === 'boolean' ? [true, false] : null);
     // A value the list doesn't name (a model given by its id) is still shown, as the one chosen.
     const choices =
       listed && !listed.map(String).includes(String(r.value ?? '')) ? [...listed, r.value] : listed;
@@ -1544,7 +1567,7 @@ export function settingsView(rows, pending, { Box, Text, Select, Input, Button }
       onSubmit: (v) => handlers.onChoose(r.key, v.trim()),
     });
   };
-  const rowsView = rows.map((r) =>
+  const rowView = (r) =>
     Box({
       key: `setting-${r.key}`,
       flexDirection: 'column',
@@ -1553,7 +1576,15 @@ export function settingsView(rows, pending, { Box, Text, Select, Input, Button }
           flexDirection: 'row',
           columnGap: 2,
           children: [
-            Box({ width: 28, children: [Text({ bold: true, children: [r.key] })] }),
+            Box({
+              width: 34,
+              children: [
+                Text({
+                  bold: true,
+                  children: [r.section === 'Approvals' ? r.key.replace(/^approvals\./, '') : r.key],
+                }),
+              ],
+            }),
             control(r),
             ...(r.value !== r.default
               ? [Text({ dimColor: true, children: [`default ${shown(r.default)}`] })]
@@ -1570,8 +1601,26 @@ export function settingsView(rows, pending, { Box, Text, Select, Input, Button }
         }),
         Text({ dimColor: true, children: [`  ${r.about}`] }),
       ],
-    }),
-  );
+    });
+  // WHO-3: the harness, then who decides each approval.
+  const section = (name) => rows.filter((r) => (r.section ?? 'Harness') === name);
+  const approvals = section('Approvals');
+  const rowsView = [
+    ...section('Harness').map(rowView),
+    ...(approvals.length
+      ? [
+          Text({ key: 'approvals-heading', bold: true, color: 'cyan', children: ['APPROVALS'] }),
+          Text({
+            key: 'approvals-about',
+            dimColor: true,
+            children: [
+              "Who decides what a lane can't do on its own. The lead decides what's technical; you keep product, design, CI and the kit.",
+            ],
+          }),
+          ...approvals.map(rowView),
+        ]
+      : []),
+  ];
   const confirm = pending
     ? [
         Box({
@@ -1627,7 +1676,9 @@ export function settingsView(rows, pending, { Box, Text, Select, Input, Button }
       Box({ flexDirection: 'column', children: rowsView }),
       Text({
         dimColor: true,
-        children: ['Lanes, paths, layers and protected paths change through /code-kit:init.'],
+        children: [
+          'Lanes, paths, layers and which paths are protected change through /code-kit:init.',
+        ],
       }),
     ],
   });

package/hooks/post-edit-check.mjs

@@ -10,6 +10,7 @@ import { block, start } from './lib/hook.mjs';
 import { brokenLayerRule, layerProblems } from './lib/layers.mjs';
 import { noteFor } from './lib/standards.mjs';
 import { projectWorktrees, relativeTo, worktreeRoot } from './lib/rules.mjs';
+import { noteWrite } from './lib/sessions.mjs';
 
 const { input, project, config, error } = start();
 const target = input.tool_input?.file_path;
@@ -20,6 +21,8 @@ const root = found && projectWorktrees(project).includes(found) ? found : null;
 if (!root) process.exit(0); // another repository, or Claude's memory: not this project's code
 const rel = relativeTo(root, target);
 if (!existsSync(join(root, rel))) process.exit(0);
+// SESS-5: in the checkout every session shares, which session wrote the file, for a blocked git to name.
+if (root === projectWorktrees(project)[0]) noteWrite(project, input.session_id, rel);
 
 // Violations recorded in the baseline (brownfield code as it was adopted) don't block; new ones do.
 const layers = layerProblems(rel, readFileSync(join(root, rel), 'utf8'), config);

package/hooks/session.mjs

@@ -0,0 +1,24 @@
+#!/usr/bin/env node
+// SessionStart and SessionEnd (docs/specs/23-the-team.md): a session starting is recorded as a member
+// of the team, the lead session when no other live session leads (SESS-2); as it ends, it leads nothing
+// more, and the lanes its agents had claimed are free again (SCHED-1). Its task stays, stale (SESS-4).
+import { readFileSync } from 'node:fs';
+import { loadConfig } from './lib/config.mjs';
+import { releaseSession } from './lib/laneclaims.mjs';
+import { endSession, startSession } from './lib/sessions.mjs';
+import { projectDir } from './lib/rules.mjs';
+
+let input = {};
+try {
+  input = JSON.parse(readFileSync(0, 'utf8') || '{}');
+} catch {
+  // no input: nothing to do
+}
+const project = projectDir();
+const { config } = loadConfig(project);
+const session = input.session_id ?? null;
+if (config && session && process.argv[2] === 'start') startSession(project, session);
+if (config && session && process.argv[2] === 'end') {
+  endSession(project, session);
+  releaseSession(project, session);
+}

package/hooks/stop-check.mjs

@@ -11,10 +11,22 @@ import { brokenLayerRule, layerProblems } from './lib/layers.mjs';
 import { noteFor } from './lib/standards.mjs';
 import { actorFor, actorRoot, currentBranch, reportPath } from './lib/rules.mjs';
 import { storyOfBranch } from './lib/teamfacts.mjs';
+import { releaseLane } from './lib/laneclaims.mjs';
 import { auditProblems, changedFiles } from './lane-audit.mjs';
 
 const { input, project, config, error } = start();
 
+// SCHED-1: a lane agent whose finish goes through frees its lane for the next story. A refused finish
+// (exit 2) keeps it: the agent carries on.
+const finishingLane =
+  input.agent_id && config
+    ? Object.entries(config.lanes).find(([, l]) => l.agent === input.agent_type)?.[0]
+    : null;
+if (finishingLane)
+  process.on('exit', (code) => {
+    if (code === 0) releaseLane(project, finishingLane, { session: input.session_id ?? null });
+  });
+
 // Stop hooks share one `stop_hook_active` flag, so another plugin's block would make this check skip
 // itself. Instead this hook remembers its own last block per session and agent. The same problem
 // reported MAX_REPEATS times in a row means no progress: say so and let the finish through rather than

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@warren-dean/code-kit",
-  "version": "0.21.0",
+  "version": "0.22.1",
   "description": "Keeps AI coding agents inside your project's rules: lanes, layer rules, protected paths and proof before finish, enforced by Claude Code hooks and in CI",
   "license": "MIT",
   "author": "Warren Langeveldt",

package/skills/decide/SKILL.md

@@ -5,7 +5,7 @@ description: The lead decides what a lane asked for and couldn't do itself (a ne
 
 # Decide a lane's request
 
-The person sets the guardrails: the specs, the architecture (contracts, layers, the rules in `.claude/code-kit.json`), the screens' visual design, CI, weakened tests, and product questions the spec doesn't answer. Inside them, you run the team. A lane that needs something it can't do itself asks you, and you decide on the merits. Passing a request to the person because you could is not deciding: they'd approve it by default, and the check would be gone.
+The person is the product owner and sets the guardrails: the specs, the screens' visual design, CI and the pipelines, the kit (the rules in `.claude/code-kit.json`), and product questions the spec doesn't answer, plus anything with production, cost or strategy implications. Everything technical is yours by default: contracts, migrations, packages, merges into the base, and a weakened test on a lane's branch once you've reviewed it (`code-kit approve tests --lane <lane> --delegated --story ST-n --reason "…"`); on your own branch a weakened test is the person's. Inside them, you run the team. A lane that needs something it can't do itself asks you, and you decide on the merits. Passing a request to the person because you could is not deciding: they'd approve it by default, and the check would be gone.
 
 The CLI is `node "${CLAUDE_PLUGIN_ROOT}/bin/code-kit.mjs"`.
 

package/skills/dispatch/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dispatch
-description: Hand stories from the plan to their lane agents, as many at once as can safely run in parallel. Picks the ready stories, checks each is buildable, briefs each lane agent with its story, requirements and acceptance criteria, and starts it on its own branch and worktree. Use when the lead is ready to start building, asks what to work on next, or runs /code-kit:dispatch [story IDs, a milestone, or "next"].
+description: Hand stories from the plan to their lane agents, one per lane, every free lane at once. Picks the ready stories, checks each is buildable, briefs each lane agent with its story, requirements and acceptance criteria, and starts it on its own branch and worktree. Use when the lead is ready to start building, asks what to work on next, or runs /code-kit:dispatch [story IDs, a milestone, or "next"].
 ---
 
 # Dispatch stories to lanes
@@ -34,7 +34,7 @@ Then check:
 - **No open question blocks it.** If a spec's open questions touch a cited requirement, don't dispatch the story; list the question for the person.
 - **The contracts exist.** If the story needs an API schema, event or database contract that isn't written yet, that's the lead's work first. Write it (the lead owns contracts), commit it on the lead's branch, then dispatch. A lane never invents a contract.
 - **The lane is right.** Run `who` on the paths the story will touch. If they belong to two lanes, split the story or sequence it; don't hand one lane another's files.
-- **Nothing overlaps.** At most one story per lane at a time, unless two stories touch disjoint folders. Two lanes may run in parallel; that's the point of lanes.
+- **One story per lane.** A lane runs one story at a time across the whole project, every session included: two agents in one lane build on the same files in their worktrees and conflict at merge. Different lanes run in parallel; that's what the plan's dependencies are for. `code-kit next` offers at most one story for each free lane, the open slice's first (`**Slice:**`), and starting a second agent for a lane that's running one is refused, naming the story and the session that has it. `code-kit lanes` lists what each lane is running. If a lane's agent stopped without finishing (it was stopped, or its session ended), `code-kit lanes release <lane>` frees the lane for its next story.
 
 Commit everything the lanes need first. Each lane branches from the lead's branch as committed, so uncommitted work isn't there.
 

package/skills/init/SKILL.md

@@ -74,7 +74,7 @@ Write `.claude/code-kit.draft.json`. Follow `${CLAUDE_PLUGIN_ROOT}/README.md`
 - **`postEdit`:** the project's existing per-file linters and formatters, with `{file}`.
 - **`checks`:** the typecheck, test, architecture and database commands, each scoped by `files`. Only include commands that pass on the current code, or ones the person chose to keep.
 - **`harness.autonomy`:** ask the person how hands-off they want the build. With the code-kit mod (Claude Code 2.1.287 or later), once the plan has stories, a lead loop can keep the work moving between their prompts: it prompts the lead to dispatch ready stories, review finished ones and merge them where merges are delegated. Offer the three choices in plain words: `autonomous` (it keeps going on its own; they can pause it from the band), `propose` (each step waits in the band for their Go), or `off`. Put their answer in the draft as `"harness": { "autonomy": "…" }`. If they'd rather decide later, leave it out: the loop then asks them in the band before its first step. With `autonomous`, the lead owns delivery, so also draft `"merge": true` in `approvals.delegate`: the lead merges a reviewed branch once every check passes.
-- **`approvals.delegate`, who decides what (HELM-1):** the person sets the guardrails and decides what crosses them; the lead decides everything inside them, so lanes ask the lead, never the person. Draft `"dependencies": {}` (the lead approves a package only when the story's requirements need it and it fits the spec, the principles and the architecture; npm packages must also pass the default registry limits on licence, popularity and age) and `"protected"` listing every protected approval except those guarding the specs, contracts and the architecture's rules, the screens' designs (`design`), and CI. Show the person the split in two lines, what they keep and what the lead decides, and ask if they want to keep anything else. `tests` (weakening a test) is always theirs.
+- **`approvals.delegate`, who decides what (HELM-1, WHO-1):** the person is the product owner; the lead decides everything technical, so lanes ask the lead, never the person. With no `approvals.delegate`, that's the default: the lead approves new packages (only when the story's requirements need them and they fit the spec, the principles and the architecture; npm packages must also pass the registry limits on licence, popularity and age), every protected change except the specs (`spec`), the screens' designs (`design`), CI (`ci`) and the kit, merges into the base, and weakened tests on a lane's branch after its review. Show the person the split in two lines, what they keep and what the lead decides, and ask if they want to keep anything else. Only if they do, draft `approvals.delegate` with exactly what the lead keeps (`{ "protected": [...], "merge": true, "tests": true, "dependencies": {} }`, leaving out what they keep), or `false` to keep everything. They can change it later in the Settings tab's Approvals section.
 - **`harness.agents.lanes.model`:** ask which model the lane agents run on. Each lane agent builds one story inside its own paths, with its requirements and acceptance criteria in its brief, and the hooks, `verify` and the lead's review catch what it gets wrong, so Sonnet usually does the work well for much less than the session's model; recommend `sonnet`, and say the lead, the reviewer and the security reviewer keep the session's model. The mod sets it as each lane agent starts; a lane's agent file with its own `model:` keeps that. Put their answer in `harness` as `"agents": { "lanes": { "model": "sonnet" } }`, or leave it out for the session's model.
 - **`harness.report.on`:** ask whether agents may draft bug reports for code-kit itself when code-kit gets in their way (a refusal that shouldn't have happened, a crash). Each report holds only code-kit's own facts (its version, the rule, what it said, the command), never the project's code, paths or data, and waits in their Decisions tab: they read it and send it to code-kit's public GitHub under their own account, or discard it. Off unless they say yes; put `"report": { "on": true }` in `harness` if they do.
 - **`docs.standards`:** `docs/standards.md` unless the project keeps its standards elsewhere (see Standards, below).

package/skills/lead/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: lead
+description: Make this Claude Code session the project's lead session, where code-kit's loop runs and the plan's stories are dispatched from, when several sessions work one project. Says which session leads now and what moving the lead does, then gives the person the command that moves it. Use when the person says this session should lead, asks which session leads, or runs /code-kit:lead.
+---
+
+# Lead from this session
+
+Several Claude Code sessions can work one project at once. One is the lead session: code-kit's loop runs there, and the plan's stories are dispatched from it. The others are working sessions: they stay quiet (no loop prompts, no other session's decisions), and each records its ad hoc task, with the paths it leases, before it changes code.
+
+The CLI is `node "${CLAUDE_PLUGIN_ROOT}/bin/code-kit.mjs"`, run from the project root.
+
+1. See who leads now:
+
+   ```bash
+   node "${CLAUDE_PLUGIN_ROOT}/bin/code-kit.mjs" who
+   node "${CLAUDE_PLUGIN_ROOT}/bin/code-kit.mjs" sessions
+   ```
+
+2. If this session already leads, say so and stop.
+3. Otherwise, tell the person what moving the lead does: this session starts running the loop and dispatching the plan's stories, and the session that led becomes a working session, which stops prompting its lead. Choosing the lead is theirs, so give them the command to run themselves (the hooks refuse it from an agent), or point them to **Lead from here** in the code-kit band:
+
+   ```text
+   ! node "${CLAUDE_PLUGIN_ROOT}/bin/code-kit.mjs" sessions lead
+   ```
+
+4. Once they have, run `who` again and confirm this session leads.
+
+A working session doesn't need this to work: it records its task (`code-kit task "<what>" --touches "<globs>"`), works in a worktree of its own, and `code-kit task done` when it's finished.

package/skills/next/SKILL.md

@@ -46,7 +46,7 @@ Run the named skill with the Skill tool: `code-kit:<step>`, with `args` (and the
 - **`update`:** run `code-kit:init`. `why` names what the setup is missing (the design gate, design stories, a QA lane, a security reviewer); init adds those, shows the person the difference, and sets `"setup": 3`. Until then no new story starts; work already started goes on to review and merge.
 - **`instructions`:** there's no skill to run. With `args` `write`, run `code-kit instructions --write`. With `merge`, some files were written before code-kit marked its part: run `code-kit instructions` to list them, replace each old part with what `code-kit instructions show lead` (CLAUDE.md) or `show lane <lane>` (that lane's agent file) prints, keep every line the project wrote itself outside the markers, then run `--write` for the rest. Commit it on a branch and merge it like your own stories.
 - **`lead`:** there's no skill to run. Build each story yourself, on the branch `lead/st-<n>`: spec-check it first if it cites requirements, do the work, commit, then run `code-kit:review` on the branch like any other. A spike's result goes in the docs it names.
-- **`wait`:** say which stories are being built and on which branches, then stop. When a lane agent finishes, its notification arrives in this session; run this skill again then. If a story has been in progress with no agent running (the session ended, or the agent stopped without committing), dispatch it again.
+- **`wait`:** say which stories are being built and on which branches, and which ready stories wait for their lane (a lane runs one story at a time), then stop. When a lane agent finishes, its notification arrives in this session; run this skill again then. If a story has been in progress with no agent running (the session ended, or the agent stopped without committing), dispatch it again.
 - **`done`:** give the `status` summary in a few lines, then offer to run spec-design for the next milestone or feature.
 
 ## 3. Keep going until the person is needed

package/skills/spec-design/SKILL.md

@@ -114,7 +114,8 @@ These are what `/code-kit:init` turns into enforced rules, so be concrete.
   - no lane for security: it owns no paths. init adds a read-only security reviewer that checks every story touching the threat models' sensitive parts, so security requirements are delivered by the lanes whose code they constrain;
   - milestones, each a usable increment;
   - stories, each small enough for one lane to finish on one branch. Each story is a `### ST-<n> Title` heading with `**Lane:**`, `**Requirements:**` (the IDs it delivers, or `none` for a spike or a foundation that delivers none), `**Depends on:**` and `**Status:** todo` lines, and for a story that fixes a bug, `**Fixes:**` with what was broken. `code-kit status` and the dispatch skill read them. A story that needs two lanes is two stories, with a dependency between them;
-  - sequencing: contracts and shared foundations first, as the lead's own stories (`**Lane:** lead`, built by the lead rather than dispatched), then work that can run in parallel;
+  - sequencing: contracts and shared foundations first, as the lead's own stories (`**Lane:** lead`, built by the lead rather than dispatched), then work that can run in parallel. A lane runs one story at a time, so parallel work is stories in different lanes;
+  - **slices**: group the stories that together make one feature someone could see working (a vertical slice across lanes, such as "Book a class") with a `**Slice:** <name>` line on each, in plan order, contract story first. A free lane builds the open slice's stories before the next slice's (`harness.slices.open`, 1 by default), so the feature in progress finishes and merges before the next one spreads across the lanes;
   - **a test story per journey**: for each main user journey, a story in the `qa` lane citing the journey's requirements and depending on the screen and service stories it goes through, so the journey is proven end to end as soon as its parts are built;
   - **design before code**: when there are screens, a design story for each area's screens (`**Lane:** design`, citing the requirements its screens serve), early in the plan, and every story that builds those screens depends on it. The lead designs them with the person (`/code-kit:design`), and no screen is built until its design is approved.
 

package/skills/team-init/SKILL.md

@@ -48,7 +48,7 @@ Each is optional; ask, and do only what they want:
 
 - **CODEOWNERS** (TEAM-11): `team codeowners --write` writes `.github/CODEOWNERS` from the config, so GitHub asks the tech lead and lane owners to review. Then they require code owners' review in a ruleset on the protected branch.
 - **A Project board** (TEAM-12): with a GitHub Project's owner and number, add `"board": { "owner": "<user or organisation>", "number": <n> }` to `team` in the config; the mod then mirrors the plan onto it.
-- **A hosted team provider, only when the config already names one:** hosted providers are in preview, so never offer or suggest one. When `team.provider` is `{ "<name>": "<https address>" }` (set by hand), connect this machine: run `team provider status`; if it isn't signed in, run `team provider signin` in the background, give the person the code and the GitHub address it prints, and wait (they enter the code in their browser; never ask for a password or token); then `team provider connect`, which checks the provider can see the repository and adds its MCP server to `.mcp.json`. Commit `.mcp.json` with the config.
+- **A hosted team provider, only when the config already names one:** hosted providers are in preview, so never offer or suggest one. When `team.provider` is `{ "<name>": "<https address>" }` (set by hand), connect this machine: run `team provider status`; if it isn't signed in, run `team provider signin` in the background, give the person the code and the GitHub address it prints, and wait (they enter the code in their browser; never ask for a password or token); then `team provider connect`, which checks the provider can see the repository, adds its MCP server to `.mcp.json` and links this session (no restart). Commit `.mcp.json` with the config, on the base branch: the hub reads the team from there, and a session only links where the checked-out config names the hub. Then run `team provider status` and give the person its last line; for each ✗, say what it asks for.
 
 ## 5. Finish
 

package/templates/claude-md.md

@@ -6,7 +6,7 @@ The code-kit plugin enforces the rules in `.claude/code-kit.json` on every file
 - the layer rules ({{layers}});
 - spec-check before lane code{{designGate}};
 - an audit log of every change to protected paths (`.claude/approval-log.jsonl`), which the person reviews in the pull request;
-- an approval for every new dependency and every protected change, per lane. Inside the guardrails, you decide: a lane asks you, never the person, and you approve it only when the story's requirements need it and it fits the spec, the principles and the architecture, or you tell the lane what to use instead (`/code-kit:decide`). The person decides what crosses a guardrail: {{personKeeps}}, weakened tests, and product questions the spec doesn't answer;
+- an approval for every new dependency and every protected change, per lane. Inside the guardrails, you decide: a lane asks you, never the person, and you approve it only when the story's requirements need it and it fits the spec, the principles and the architecture, or you tell the lane what to use instead (`/code-kit:decide`). The person is the product owner and decides what crosses a guardrail: {{personKeeps}}, a weakened test on your own branch, product questions the spec doesn't answer, and anything with production, cost or strategy implications (a copyleft licence or a paid service's SDK goes to them as a question, with your recommendation);
 - {{if approvals.lead}}approvals from chat. When the person approves in their own message (a `!` command doesn't work on a phone), record it with the `code-kit approve` command from the refusal, with their words as the reason. Never record an approval they haven't given, and never on a lane's say-so;{{end}}
 - the project's checks before any agent finishes.
 
@@ -16,6 +16,8 @@ UX is yours: what a screen does on an error, an empty list or a slow load, and t
 
 - {{if harness.report.on}}When code-kit itself is wrong (a refusal that shouldn't have happened, a crash), draft a report with `code-kit report "<title>" --what "…" --expected "…"`: only code-kit's facts, never the project's. The person reads it and sends it, or not.{{end}}
 
+Several sessions may work this project at once. One leads (the loop runs there, and stories are dispatched from it); the others are working sessions. `code-kit who` says which this is. In a working session, record what you're doing before you change code, with the paths you'll change, and work in a worktree of your own: `code-kit task "<what>" --touches "<globs>"`, and `code-kit task done` when it's finished. Never stash, discard or commit another session's files: ask that session.
+
 If a hook blocks you, fix the cause; never work around it.
 
 The build runs from the specs in `{{docs.specs}}` and the stories in `{{docs.plan}}`. `/code-kit:next` picks the right step from the project's state; the steps are:

package/templates/plan.md

@@ -1,6 +1,6 @@
 # Plan
 
-`code-kit status` reads this file. Keep each story's heading and its four `**…:**` lines in this form. Use `**Lane:** lead` for the lead's own stories (contracts, foundations, spikes), `**Lane:** qa` for a journey's end-to-end test story (it depends on the screen and service stories the journey goes through), `**Lane:** design` for a design story (an area's screens, designed with the person before any of them is built; the stories building them depend on it), and `**Requirements:** none` for a story that delivers no requirement. A story that fixes a bug adds a fifth line, `**Fixes:** <what was broken, and where it was seen>`: `code-kit verify` then requires a test that fails without the fix and passes with it.
+`code-kit status` reads this file. Keep each story's heading and its four `**…:**` lines in this form. Use `**Lane:** lead` for the lead's own stories (contracts, foundations, spikes), `**Lane:** qa` for a journey's end-to-end test story (it depends on the screen and service stories the journey goes through), `**Lane:** design` for a design story (an area's screens, designed with the person before any of them is built; the stories building them depend on it), and `**Requirements:** none` for a story that delivers no requirement. A story that fixes a bug adds a fifth line, `**Fixes:** <what was broken, and where it was seen>`: `code-kit verify` then requires a test that fails without the fix and passes with it. A story that belongs to a slice (a feature that can be shown working, built across lanes) adds `**Slice:** <name>`: a lane takes the open slice's stories first.
 
 ## Lanes
 
@@ -17,6 +17,7 @@
 **Lane:** {{lane}}
 **Requirements:** {{AREA-1, AREA-2}}
 **Depends on:** {{ST-n, or none}}
+**Slice:** {{the feature it's part of, or leave the line out}}
 **Status:** todo
 
 {{What gets built, in two or three sentences. The acceptance criteria are the cited requirements'.}}