cawdev-cli 1.0.11-beta → 1.1.0

package/README.md

@@ -10,4 +10,14 @@ https://github.com/4dali/cawdev-cli
 
 `jira/import.mjs` brings a Jira Cloud project's issues, epics, sprints and
 comments into a cawdev project, once and again without duplicates (R337). Run from a checkout; see
-"Leaving Jira" in GUIDE.md. Its tests: `node --test "tools/jira/*.test.mjs"`.
+"Leaving Jira" in GUIDE.md. `--team <team id>` (R489) names the team the sprints open in, when the project is
+shared with several writer teams. Its tests: `node --test "tools/jira/*.test.mjs"`.
+
+## The `Sprint:` line
+
+A card in a sprint carries one `Sprint:` line in `ROADMAP.md` and `ISSUES.md`
+(`lib/roadmap-format.mjs`): `Sprint: Core team · S7 Notifications` since sprints
+became a team's (R489). Files written before that, `Sprint: S7 Notifications`,
+still parse (with no team). `roadmap/import.mjs` sends the words
+(`Core team · S7`) for the first form and the number for the second, so a file
+naming a sprint the target does not have is refused with the API's own sentence.

package/lib/roadmap-format.mjs

@@ -332,14 +332,24 @@ export function parseRoadmap(text) {
         entry.origin = origin[1].trim();
         continue;
       }
-      const sprint = /^Sprint:\s*S(\d+)\s*(.*)$/.exec(line.trim());
+      const sprint = /^Sprint:\s*(?:(?!S\d+(?:\s|$))(.+?)\s*·\s*)?S(\d+)\s*(.*)$/.exec(line.trim());
       if (sprint) {
-        // R257: `Sprint: S1 Notifications` — the sprint's number and its name
-        // as the file says it. The same shape the API's `sprint` has, so a
-        // re-render from either is byte-identical; the importer sends only
-        // the number, since a sprint's name is the database's to say.
-        const number = Number(sprint[1]);
-        entry.sprint = { number, ref: `S${number}`, name: sprint[2].trim() };
+        // R257, R489: `Sprint: Core team · S1 Notifications` — a team's
+        // sprint, its number and its name as the file says it. A file written
+        // before sprints were teams' says `Sprint: S1 Notifications`; that
+        // still parses, with no team. The same shape the API's `sprint` has
+        // (`label`, `ref`, `number`, `name`), so a re-render from either is
+        // byte-identical; the importer sends the team's words and the number,
+        // since a sprint's name is the database's to say.
+        const number = Number(sprint[2]);
+        const team = sprint[1]?.trim() || null;
+        entry.sprint = {
+          team,
+          number,
+          ref: `S${number}`,
+          label: team ? `${team} · S${number}` : `S${number}`,
+          name: sprint[3].trim(),
+        };
         continue;
       }
       bodyLines.push(line);
@@ -619,7 +629,10 @@ function renderEntry(entry) {
     // API's `sprint` and the parser's are the same shape, which is what makes
     // render → parse → render a fixed point. State is not written — the file
     // says which sprint, the database says whether it is still open.
-    lines.push(`Sprint: ${entry.sprint.ref ?? `S${entry.sprint.number}`} ${entry.sprint.name}`.trimEnd());
+    // R489: the label (`Core team · S7`) is the only spelling that means
+    // anything outside the team; `ref` alone is the pre-teams file's.
+    const label = entry.sprint.label ?? entry.sprint.ref ?? `S${entry.sprint.number}`;
+    lines.push(`Sprint: ${label} ${entry.sprint.name ?? ''}`.trimEnd());
   }
 
   if (entry.body?.trim()) {

package/lib/stage-tools.mjs

@@ -75,6 +75,8 @@ export const CAWDEV_READS = new Set([
   'quality_get',
   'roadmap_statuses',
   'roadmap_list',
+  // R489. The project's sprints, read from the endpoint a card's picker uses.
+  'sprint_list',
   'roadmap_get',
   'issue_list',
   'changelog_list',

package/mcp/README.md

@@ -3,7 +3,9 @@
 Plain Node, zero dependencies, stdio JSON-RPC — `server.mjs`, plus the shared
 rule matcher in `tools/lib/tool-rules.mjs` that the runner uses too. It gives a coding
 agent a project's roadmap and changelog — the same verbs a person gets in the
-console, because the API was built to mirror these tools one-for-one.
+console, because the API was built to mirror these tools one-for-one. This README says
+**card** for the roadmap thing and **run** for the work on it, as the console does; the API and
+the tool names say *entry* (`roadmap_list`, `propose_entry`, `EntryRef`) and keep doing so.
 
 ## Setting it up in a repository
 
@@ -59,23 +61,23 @@ four being different from what you assumed.
 
 The sequence is fixed, and the second step is the one people skip:
 
-1. Branch off an up-to-date `main`, named after the entry — `r4-roadmap-entries`.
-2. **Move the entry to `CODING` naming the branch, before your first commit**
+1. Branch off an up-to-date `main`, named after the card — `r4-roadmap-entries`.
+2. **Move the card to `IN_DEVELOPMENT` naming the branch, before your first commit**
    (`roadmap_set_status`). Not after. The roadmap should be able to answer
    "what is being worked on right now" without asking anyone.
-3. Build to the entry's "Done when" list.
+3. Build to the card's "Done when" list.
 4. Finish with a PR. Never push to `main`. As your session ends the platform
    moves the *branch* on the development board, not the card: to `REVIEW` where
    the project runs `require_review` and somebody is going to read it, and to
    `DONE` where it does not — a finish nobody was asked about (R132), because
    there is no reviewer coming.
-5. When the PR merges, move the entry to `MERGED` naming it. The branch may then
-   be deleted — `CODING` is for work somebody is doing, not work that is done.
+5. When the PR merges, move the card to `MERGED` naming it. The branch may then
+   be deleted — `IN_DEVELOPMENT` is for work somebody is doing, not work that is done.
 
 ### What a status must carry
 
 `roadmap_statuses` will tell you, and it is worth reading rather than guessing:
-`CODING` needs a branch, `MERGED` needs the merge — a pull request, a merge
+`IN_DEVELOPMENT` needs a branch, `MERGED` needs the merge — a pull request, a merge
 commit, or a sha — `SHIPPED` needs a version that is a real git tag, and
 `DECLINED` needs a reason. `REVIEW` needs nothing, deliberately: the pull
 request it would otherwise carry belongs to the run, and a project that reviews
@@ -85,19 +87,29 @@ without opening pull requests has none to give it.
 when you name no status is the project's rule, per door, and the default for a
 card or issue an agent files is the backlog: waiting until a person or a sprint
 brings it in, in no sprint and on no board column. Its origin names your
-session and the card your run was on. A plan session's card lands where the console's
+session and the card your run was on. A plan run's card lands where the console's
 do (R380). Name a status (`CONSIDERING`, `NEW`) when
 you mean the pipeline. Giving a backlog card a sprint moves it to the first
 status of its kind; moving a card to `BACKLOG` takes it out of its sprint.
 
-**Any status may move to any other.** There is no transition diagram — an entry
+**Sprints are a team's** (R474, R489). The `sprint` of `roadmap_create`,
+`roadmap_update` and the filter of `roadmap_list` take an integer or a string:
+`7` or `"S7"` when the project's teams have one S7, `"Core team · S7"` (or
+`"Core team / S7"`) when two do — the API refuses an ambiguous `S7` naming both
+spellings, so read the sentence and send the long one — a sprint id, and `0` or
+`""` to take a card out. A completed sprint refuses a card that is not already
+in it, and only a person can reopen one; do not retry. `sprint_list` says which
+sprints there are. A card prints its sprint as `Core team · S7 Name (active)`.
+Opening, starting, completing and renaming a sprint stay a person's.
+
+**Any status may move to any other.** There is no transition diagram — a card
 really can go from `CONSIDERING` straight to `SHIPPED` if that is what happened.
 The rules are about what a status *carries*, not the path it took.
 
 ### The body is what we want; the plan is how; the comments are the argument
 
 `roadmap_get` gives you all three, and `task_current` gives you them for the
-entry you are working on.
+card you are working on.
 
 **The plan is the one to read before doing any of the work.** It was written by
 a plan phase and agreed by somebody, and it names the files — R124. If you are
@@ -110,8 +122,8 @@ either. The first is the platform's — it stores what a plan phase reports when
 the phase ends, so that a session which must not write is not handed a writer to
 do its own bookkeeping with. The second is refused outright: *an agent cannot
 start another agent*, which is `RunAccess.requireCanStart`'s rule and not an
-omission here. **Read the discussion before you propose anything about an
-entry.** It is where an objection was answered and where an obvious-looking
+omission here. **Read the discussion before you propose anything about a
+card.** It is where an objection was answered and where an obvious-looking
 approach was ruled out with a reason — and re-proposing what was talked out
 three months ago is precisely what it exists to stop.
 
@@ -123,7 +135,7 @@ that the next reader does not have to reconstruct it from the thread.
 A comment you write is attributed to your run as well as to the account that
 minted your token, so a person can tell an agent's reading from a colleague's.
 
-### Read what the earlier sessions did before repeating it
+### Read what the earlier runs did before repeating it
 
 `task_current` lists **every run this card has already had** — how each ended,
 on what branch, with what model, whether the work was pushed, and the commits it
@@ -133,21 +145,21 @@ to know what the first tried.
 
 No transcripts come with it, deliberately: the terminal log is on the run's own
 page in the console, and nine of them would fill the context this call exists to
-orient. If you need the detail, the discussion under the entry is where a
-previous session should have written down what it learned — and where yours
+orient. If you need the detail, the discussion under the card is where a
+previous run should have written down what it learned — and where yours
 should.
 
 ### There is no delete
 
 Not in these tools, not in the API. `roadmap_decline` with a reason is the only
-exit an entry has, and the reason is the point: it is what stops the same idea
+exit a card has, and the reason is the point: it is what stops the same idea
 being proposed again in six months. Same for changelog entries — correct the
 text, do not remove the record. Same for comments: nothing removes one, and the
 most you can do to your own is correct its wording.
 
 ### Ids are permanent, and a card is named by its ref
 
-An entry's number never changes and is never reused. Commit messages and code
+A card's number never changes and is never reused. Commit messages and code
 comments point at it. Since R221 a roadmap card and an issue each count on
 their own sequence, so `R91` and `i91` are two cards: wherever a tool takes
 `number`, `related`, `after` or `entryNumber`, pass the ref — `"i91"` for an
@@ -169,13 +181,14 @@ what you are allowed to do.
 |---|---|
 | `roadmap_where` | Which platform, which token, read from where, and who you are. Start here. |
 | `roadmap_statuses` | The eight statuses, what they mean, what each requires. |
-| `roadmap_list` | Entries, optionally by status. `brief` omits bodies — use it to survey. |
-| `roadmap_get` | One entry in full: its body, **the plan agreed for it**, and the discussion on it. |
-| `roadmap_create` | Create an entry; the platform allocates its permanent number. |
-| `roadmap_update` | Title, body, section, related ids, the cards it starts coding after (`after` — R181), when it is due and how big it is (`due` — R351: an ISO date, `""` clears; `estimate`: a positive number, `0` clears), the version it is meant for (`targetVersion` — R358, `""` clears; since R362 it must be one the project defined under Project settings → Versions, and any other name is refused), the versions an issue was found in (`affectedVersions` — R378, issues only: names the project defined or shipped in, `[]` clears), and who it is assigned to (`assignee` — R331: a username, `""` clears; `roadmap_list`/`issue_list` take `assignee` too, and `me` means the token's owner). |
-| `roadmap_comment` | Say something *beside* an entry rather than inside it. |
+| `roadmap_list` | Cards, optionally by status or `sprint` (any spelling below). `brief` omits bodies — use it to survey. |
+| `sprint_list` | The project's sprints with how far each has got (R489): `Core team · S7 Notifications — active — 4 of 9 landed`. ACTIVE and UPCOMING unless `state` says otherwise. A read: PLAN and VERIFY have it. |
+| `roadmap_get` | One card in full: its body, **the plan agreed for it**, and the discussion on it. |
+| `roadmap_create` | Create a card; the platform allocates its permanent number. |
+| `roadmap_update` | Title, body, section, sprint (R489: `7`, `S7`, `"Core team · S7"`, a sprint id; `0` or `""` takes the card out — see below), related ids, the cards it starts coding after (`after` — R181), when it is due and how big it is (`due` — R351: an ISO date, `""` clears; `estimate`: a positive number, `0` clears), the version it is meant for (`targetVersion` — R358, `""` clears; since R362 it must be one the project defined under Project settings → Versions, and any other name is refused), the versions an issue was found in (`affectedVersions` — R378, issues only: names the project defined or shipped in, `[]` clears), and who it is assigned to (`assignee` — R331: a username, `""` clears; `roadmap_list`/`issue_list` take `assignee` too, and `me` means the token's owner). |
+| `roadmap_comment` | Say something *beside* a card rather than inside it. |
 | `done_when_tick` | Tick (or untick) one numbered item of the card's Done-when checklist as built, with one line of evidence (R368). `task_current` lists the items. Defaults to the run's own card and refuses another; the reviewer's column is a person's and no token can set it. |
-| `roadmap_set_status` | Move an entry, carrying whatever the status requires. |
+| `roadmap_set_status` | Move a card, carrying whatever the status requires. |
 | `roadmap_decline` | Decline with a reason. The only exit. |
 | `backlog_file` | File **feedback**, not a card — something a person should decide about. A WRITER accepts it as a card or an issue, or refuses it (R199). Tagged `agent` as a source, plus any `tags` you pass — `customer` when you relay what a user said (R372). |
 | `changelog_list` | The changelog, grouped by release, newest first. |
@@ -192,8 +205,8 @@ token gets a refusal saying so.
 
 | Tool | What it does |
 |---|---|
-| `task_current` | The entry you are working on, its branch, everything already said and asked on this run, **and every earlier run on the same card**. **Call it first**, and again whenever you are unsure where you are. |
-| `report` | `progress` as often as useful; `done` when finished, naming the branch and any PR; `blocked` when a person must resolve something. `done` and `blocked` end the run; on a coding run `done` is refused until everything is committed and pushed (R345). |
+| `task_current` | The card you are working on, its branch, everything already said and asked on this run, **and every earlier run on the same card**. **Call it first**, and again whenever you are unsure where you are. |
+| `report` | `progress` as often as useful; `done` when finished, naming the branch and any PR; `blocked` when a person must resolve something. `done` and `blocked` end the run; on a review run the `done` body is filed as the branch's review (R529), so write it for the person reading the thread; on a coding run `done` is refused until everything is committed and pushed (R345). |
 | `ask_user` | Ask the person who started the run, and wait. Blocks up to ten minutes, then hands back a `question_id`. |
 | `await_answer` | Resume waiting for a question `ask_user` handed back. |
 | `ask_group` | Ask a **round** — up to twelve questions that belong together, under one title. Blocks until every one of them has been answered, then hands back a `group_id`. |
@@ -202,7 +215,7 @@ token gets a refusal saying so.
 | `approve` | **Not yours to call.** Claude Code calls it itself, as `--permission-prompt-tool`, when no rule covers a tool call. |
 
 **`ask_user` is for decisions that are genuinely theirs** — an architectural
-choice, a trade-off with no right answer, something the entry does not settle.
+choice, a trade-off with no right answer, something the card does not settle.
 Not for checking work you can check yourself. Every question stops the run and
 costs somebody's attention.
 
@@ -213,7 +226,7 @@ asked because the decision was not yours. Call `await_answer`, or `report`
 **`ask_group` is for when you have several questions at once** — R96. One
 question at a time is right for a decision you hit halfway through a piece of
 work; it is wrong when you are trying to understand something, because forty
-separate inbox items arriving over an afternoon is not a conversation, it is an
+separate Waiting on you items arriving over an afternoon is not a conversation, it is an
 interruption repeated forty times. A round arrives as one form under one title,
 the person answers it in one sitting, and you are woken once when all of it is
 answered.
@@ -259,9 +272,9 @@ Two smoke tests, both driving the server over real stdio.
 CAWDEV_URL=http://localhost:4200 CAWDEV_TOKEN=cawd_… node tools/mcp/smoke.mjs scratch-project
 ```
 
-**Name a scratch project.** The smoke test creates a roadmap entry and declines
-it, and entries cannot be deleted — so it refuses to guess which project you
-meant. It left two declined entries in cawdev's own roadmap before it did.
+**Name a scratch project.** The smoke test creates a roadmap card and declines
+it, and cards cannot be deleted — so it refuses to guess which project you
+meant. It left two declined cards in cawdev's own roadmap before it did.
 
 It drives the server the way a client does — spawn, write lines to stdin, read
 lines from stdout — rather than importing its functions, because the parts most

package/mcp/server.mjs

@@ -375,6 +375,41 @@ const TOOLS = [
     },
   },
 
+  {
+    name: 'sprint_list',
+    description:
+      'The sprints a project\'s cards can be filed into, with how far each has got — R489. Sprints ' +
+      'are a team\'s: written `S7` inside the team and `Core team · S7` outside it. Read this before ' +
+      'filing a card into one with roadmap_create / roadmap_update `sprint`. State narrows it ' +
+      '(ACTIVE, UPCOMING, COMPLETED; comma-separated); the default is ACTIVE and UPCOMING.',
+    inputSchema: {
+      type: 'object',
+      properties: {
+        ...PROJECT_ARGUMENT,
+        state: {
+          type: 'string',
+          description: 'ACTIVE, UPCOMING, COMPLETED — one or several, comma-separated. Default ACTIVE,UPCOMING.',
+        },
+      },
+    },
+    handler: async (config, args) => {
+      const slug = await resolveProject(config, args.project);
+      const state = args.state || 'ACTIVE,UPCOMING';
+      const sprints = await api(config, `/api/projects/${slug}/sprints?state=${encodeURIComponent(state)}`);
+      if (!sprints.length) return `${slug} has no sprints in ${state}.`;
+      return sprints
+        .map((sprint) => {
+          const counts = sprint.counts ?? {};
+          return (
+            `${sprint.label ?? sprint.ref}${sprint.name ? ` ${sprint.name}` : ''} — ` +
+            `${String(sprint.state).toLowerCase()} — ${counts.landed ?? 0} of ${counts.cards ?? 0} landed` +
+            (sprint.goal ? `\n    goal: ${sprint.goal}` : '')
+          );
+        })
+        .join('\n');
+    },
+  },
+
   {
     name: 'roadmap_statuses',
     description:
@@ -396,18 +431,17 @@ const TOOLS = [
   {
     name: 'roadmap_list',
     description:
-      'A project\'s roadmap entries, optionally filtered by status or by sprint. Use brief=true ' +
-      'to survey without pulling every entry\'s body into context.',
+      'A project\'s roadmap cards, optionally filtered by status or by sprint. Use brief=true ' +
+      'to survey without pulling every card\'s body into context.',
     inputSchema: {
       type: 'object',
       properties: {
         ...PROJECT_ARGUMENT,
         sprint: {
-          type: 'integer',
-          minimum: 1,
+          type: ['integer', 'string'],
           description:
-            'Only cards in this sprint, by number — 1 for S1. A number the project has no ' +
-            'sprint for is refused naming the ones it has.',
+            'Only cards in this sprint: `S7` (or 7), "Core team · S7" when two teams have an S7, or a ' +
+            'sprint id. A sprint the project has none for is refused naming the ones it has.',
         },
         status: {
           type: 'string',
@@ -439,7 +473,9 @@ const TOOLS = [
       if (args.status) query.set('status', args.status);
       // R257. The API refuses a number with no sprint behind it, naming the
       // sprints there are; that sentence is passed through as the tool error.
-      if (args.sprint) query.set('sprint', String(args.sprint));
+      if (args.sprint !== undefined && args.sprint !== '' && args.sprint !== 0) {
+        query.set('sprint', String(args.sprint));
+      }
       if (args.assignee) query.set('assignee', args.assignee);
       query.set('brief', String(brief));
 
@@ -454,7 +490,7 @@ const TOOLS = [
   {
     name: 'roadmap_get',
     description:
-      'One roadmap entry in full: its body, THE PLAN somebody agreed for it, and the ' +
+      'One roadmap card in full: its body, THE PLAN somebody agreed for it, and the ' +
       'discussion on it. Read the plan before doing any of the work — it is what was decided, ' +
       'and it names the files. Read the comments before proposing anything: they are where an ' +
       'objection was answered, and re-proposing what was talked out three months ago is the ' +
@@ -594,7 +630,7 @@ const TOOLS = [
   {
     name: 'roadmap_comment',
     description:
-      'Say something about an entry, beside the entry rather than inside it. Use it for the ' +
+      'Say something about a card, beside the card rather than inside it. Use it for the ' +
       'argument: an objection, a measurement, why an obvious approach was not taken. The body ' +
       'is where a settled conclusion is written down — edit that when the discussion reaches ' +
       'one. Comments cannot be deleted, by you or by anyone.',
@@ -680,12 +716,12 @@ const TOOLS = [
   {
     name: 'roadmap_create',
     description:
-      'Create a roadmap entry. The platform allocates its permanent number — written R91 on ' +
-      'a roadmap card and i91 on an issue, one sequence across both — and the ' +
+      'Create a roadmap card. The platform allocates its permanent number — written R91 on ' +
+      'a roadmap card and i91 on an issue, two sequences, one per kind — and the ' +
       'project decides where a card you file starts — the BACKLOG by default for a card an ' +
       'agent files, waiting until a person or a sprint brings it in — unless you say ' +
       'otherwise; a status that requires something must be given it. A card in the BACKLOG ' +
-      'holds no sprint: giving it one moves it to CONSIDERING. A plan session\'s card lands ' +
+      'holds no sprint: giving it one moves it to CONSIDERING. A plan run\'s card lands ' +
       'where the console\'s do (R380).',
     inputSchema: {
       type: 'object',
@@ -714,12 +750,12 @@ const TOOLS = [
         reason: { type: 'string' },
         section: { type: 'string', description: 'Which part of the roadmap, e.g. "Phase 2 — …".' },
         sprint: {
-          type: 'integer',
-          minimum: 0,
+          type: ['integer', 'string'],
           description:
-            'The sprint to file this card into, by number — 1 for S1. 0 takes it out of its ' +
-            'sprint; leave it out to leave it alone. A CLOSED sprint refuses a card that is ' +
-            'not already in it, and only a person can reopen one — do not retry.',
+            'The sprint to file this card into: `S7` (or 7) when the project\'s teams have one S7, ' +
+            '"Core team · S7" when two teams do, a sprint id, or 0 / "" to take it out of its sprint; ' +
+            'leave it out to leave it alone. A COMPLETED sprint refuses a card that is not already in it, ' +
+            'and only a person can reopen one — do not retry. Sprint_list shows what there is.',
         },
         related: {
           type: 'array',
@@ -929,7 +965,7 @@ const TOOLS = [
   {
     name: 'roadmap_update',
     description:
-      'Edit an entry\'s title, body, section, sprint, tags, parent, related refs or the cards it ' +
+      'Edit a card\'s title, body, section, sprint, tags, parent, related refs or the cards it ' +
       'starts after. Use roadmap_set_status to move it.',
     inputSchema: {
       type: 'object',
@@ -943,12 +979,12 @@ const TOOLS = [
         body: { type: 'string' },
         section: { type: 'string' },
         sprint: {
-          type: 'integer',
-          minimum: 0,
+          type: ['integer', 'string'],
           description:
-            'The sprint to file this card into, by number — 1 for S1. 0 takes it out of its ' +
-            'sprint; leave it out to leave it alone. A CLOSED sprint refuses a card that is ' +
-            'not already in it, and only a person can reopen one — do not retry.',
+            'The sprint to file this card into: `S7` (or 7) when the project\'s teams have one S7, ' +
+            '"Core team · S7" when two teams do, a sprint id, or 0 / "" to take it out of its sprint; ' +
+            'leave it out to leave it alone. A COMPLETED sprint refuses a card that is not already in it, ' +
+            'and only a person can reopen one — do not retry. Sprint_list shows what there is.',
         },
         related: {
           type: 'array',
@@ -1027,7 +1063,7 @@ const TOOLS = [
   {
     name: 'roadmap_set_status',
     description:
-      'Move an entry to a status. Any status may move to any other — the rules are about what ' +
+      'Move a card to a status. Any status may move to any other — the rules are about what ' +
       'a status must carry, not a permitted path. IN_DEVELOPMENT needs a branch, MERGED the ' +
       'merge — the PR, the merge commit or the sha — and SHIPPED a version. Move a card to ' +
       'MERGED when its pull request lands; the branch may then be deleted. ' +
@@ -1076,7 +1112,7 @@ const TOOLS = [
   {
     name: 'roadmap_decline',
     description:
-      'Decline an entry, with a reason. This is the only exit an entry has — there is no delete. ' +
+      'Decline a card, with a reason. This is the only exit a card has — there is no delete. ' +
       'The reason is the point: it stops the idea being proposed again.',
     inputSchema: {
       type: 'object',
@@ -1153,10 +1189,10 @@ const TOOLS = [
         entryNumber: {
           type: ['string', 'integer'],
           description:
-            'The roadmap card or issue this entry describes — R156 — by ref: R91, i91, or a '
+            'The roadmap card or issue this changelog entry describes — R156 — by ref: R91, i91, or a '
             + 'bare number for a roadmap card (R221). Set it. Until R156 the only link was the '
             + 'ref you type into the prose, which cannot be queried, so a release could not '
-            + 'tell whether a card already had an entry and would write a second one beside '
+            + 'tell whether a card already had a changelog entry and would write a second one beside '
             + 'the first. Put the ref in the text as well; that is what a reader sees.',
         },
       },
@@ -1189,8 +1225,8 @@ const TOOLS = [
         entryNumber: {
           type: ['string', 'integer'],
           description:
-            'The roadmap card or issue this entry describes — R156 — by ref (R91, i91; a bare '
-            + 'number is a roadmap card). Set it on an older entry that has never been linked; '
+            'The roadmap card or issue this changelog entry describes — R156 — by ref (R91, i91; a bare '
+            + 'number is a roadmap card). Set it on an older changelog entry that has never been linked; '
             + 'omitting it leaves whatever link is already there.',
         },
       },
@@ -1211,9 +1247,9 @@ const TOOLS = [
   {
     name: 'task_current',
     description:
-      'What you are working on: the roadmap entry, THE PLAN agreed for it, its branch, and ' +
+      'What you are working on: the roadmap card, THE PLAN agreed for it, its branch, and ' +
       'everything already said and asked on this run. Call it first, and again whenever you ' +
-      'are unsure where you are — a resumed or confused session re-orients from this alone.',
+      'are unsure where you are — a resumed or confused agent session re-orients from this alone.',
     inputSchema: { type: 'object', properties: {} },
     handler: async (config) => {
       const { runId, project } = await requireRun(config);
@@ -1435,20 +1471,20 @@ const TOOLS = [
   {
     name: 'propose_entry',
     description:
-      'Record something an audit found, or a card a scoping session cut, as a proposed entry. ' +
+      'Record something an audit found, or a card a scoping run cut, as a proposed card. ' +
       '`kind` is your opinion: "issue" ' +
       '(broken, unsafe, or loses data — with a severity) or "roadmap" (it should also do this, ' +
       'or do it better — no severity). A PERSON decides, and may file it the other way — you ' +
-      'are not creating an entry, you are suggesting it. Default "issue", so an audit written ' +
+      'are not creating a card, you are suggesting it. Default "issue", so an audit written ' +
       'before there was a choice files what it always did. Severity is "critical" (broken, ' +
       'unsafe, or loses data), "medium" (it will hurt, but not today) or "minor" (worth doing, ' +
-      'nobody is bleeding). `section` is where you think it belongs; a scoping session names ' +
+      'nobody is bleeding). `section` is where you think it belongs; a scoping run names ' +
       'ONE for every card of the idea. A roadmap card MUST say what it starts after — `after`: ' +
       '`[]` for a card that starts after none, `"#2"` for the second card you proposed in this ' +
       'run (the number this tool answered with), `"R12"` for a card already on the roadmap. ' +
       'You can only name what has already been proposed, so file in build order. Write each ' +
-      'one as an entry would be written, and say where in the code you saw it. Only an audit ' +
-      'or a scoping session may use this.',
+      'one as a card would be written, and say where in the code you saw it. Only an audit ' +
+      'or a scoping run may use this.',
     inputSchema: {
       type: 'object',
       properties: {
@@ -1473,7 +1509,7 @@ const TOOLS = [
           type: 'string',
           description:
             'The roadmap section this belongs under, in your opinion. Optional. The person ' +
-            'accepting sees it as the default and may file it elsewhere. A scoping session ' +
+            'accepting sees it as the default and may file it elsewhere. A scoping run ' +
             'uses the same section on every card it cuts from one idea.',
         },
         after: {
@@ -1485,7 +1521,7 @@ const TOOLS = [
             'card you proposed in THIS run, by the number this tool answered with; it must ' +
             'already have been proposed, so propose what a card depends on before the card. ' +
             '`"R12"` or `"i7"` names a card already on the roadmap. A person adds the cards ' +
-            'in this order, and a coding session on one waits until what it starts after has ' +
+            'in this order, and a coding run on one waits until what it starts after has ' +
             'landed.',
         },
       },
@@ -1565,7 +1601,7 @@ const TOOLS = [
     name: 'ask_group',
     description:
       'Ask a ROUND of questions at once, and wait for all of them. Use it when you have several ' +
-      'things to settle that belong together — they arrive in the person\'s inbox under one ' +
+      'things to settle that belong together — they arrive in the person\'s Waiting on you page under one ' +
       'title, on one form, instead of interrupting them once per question. At most 12 in a ' +
       'round; ask the rest in the next one. Blocks for up to ten minutes; if the round is ' +
       'unfinished by then it returns a group_id for await_group.',
@@ -1575,7 +1611,7 @@ const TOOLS = [
         title: {
           type: 'string',
           description:
-            'What this round is called in their inbox. A CTO Interview uses "CTO Interview".',
+            'What this round is called in Waiting on you. A CTO Interview uses "CTO Interview".',
         },
         intro: {
           type: 'string',
@@ -1705,7 +1741,7 @@ const TOOLS = [
     name: 'await_answer',
     description:
       'Resume waiting for a question ask_user handed back. Between the two you experience one ' +
-      'natural blocking ask; the person experiences an inbox item.',
+      'natural blocking ask; the person experiences a Waiting on you item.',
     inputSchema: {
       type: 'object',
       properties: { question_id: { type: 'string' } },
@@ -2065,11 +2101,23 @@ function approvalTimeoutSeconds() {
 // The same goes for comments — nothing here removes one, and nothing there
 // does either.
 //
-// Nor is there a sprint_open, sprint_close or sprint_rename — R257. Opening,
-// closing and renaming a sprint are a person's acts on the page, and the API
-// says so structurally (POST/PATCH /sprints take a session, not a token). An
-// agent's whole reach here is reading a card's sprint and filing a card into
-// one with roadmap_create / roadmap_update `sprint`.
+// Nor is there a sprint_open, sprint_start, sprint_complete or sprint_rename —
+// R257, and a team's since R474. Opening, starting, completing and renaming a
+// sprint are a person's acts on the page, and the API says so structurally
+// (the /api/teams/{id}/sprints writes take a session, not a token). An
+// agent's whole reach here is reading the sprints (sprint_list) and a card's
+// sprint, and filing a card into one with roadmap_create / roadmap_update
+// `sprint`.
+
+/**
+ * R489. A card's sprint as a line: `Core team · S7 Name (active)`. The label
+ * is the server's one spelling; `S7` alone means nothing outside its team.
+ */
+function sprintLine(sprint) {
+  const label = sprint.label ?? sprint.ref ?? `S${sprint.number}`;
+  const state = String(sprint.state ?? '').toLowerCase();
+  return `${label}${sprint.name ? ` ${sprint.name}` : ''}${state ? ` (${state})` : ''}`;
+}
 
 function pick(source, keys) {
   const out = {};
@@ -2361,7 +2409,7 @@ function formatEntry(entry, { brief, comments, plan }) {
   // depend on which tool printed the card; a closed sprint says so.
   if (entry.sprint) {
     lines.push(
-      `  sprint: ${entry.sprint.ref} ${entry.sprint.name}${entry.sprint.state === 'CLOSED' ? ' (closed)' : ''}`,
+      `  sprint: ${sprintLine(entry.sprint)}`,
     );
   }
   if (entry.related?.length) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cawdev-cli",
-  "version": "1.0.11-beta",
+  "version": "1.1.0",
   "description": "cawdev's terminal client and runner daemon — zero dependencies, on purpose",
   "type": "module",
   "bin": {

package/runner/README.md

@@ -158,8 +158,9 @@ served like any added project, and the rest of the console's setup walk —
 rules, members, the CTO Interview — is linked at
 `<url>/projects/<slug>/setup`.
 
-**What takes effect when** (R294). Three settings a running daemon takes
-without a restart — `agentCommands`, `grantable`, `acceptsRulesFromConsole`,
+**What takes effect when** (R294). Four settings a running daemon takes
+without a restart — `agentCommands`, `grantable`, `acceptsRulesFromConsole`
+and `autoWorkspaces`,
 the `HOT_SWAPPABLE` list in `tools/lib/runner-config.mjs`, spelled once —
 because the daemon reads them fresh on every use. Everything else in the file
 (`projects` and their workspaces, `url`, `name`, the token, `browser`, the
@@ -197,7 +198,7 @@ and its copy all work exactly as they always have, and scrolling up reaches the
 start of the session. The only thing pinned is the footer at the bottom, and it
 never scrolls away: which cawdev, who you are signed in as, this machine's
 runner, the per-project session counts against their checkouts and the machine's
-total against `maxSessions` — plus the run you are watching and the keys that
+total — plus the run you are watching and the keys that
 work right now. Anything *stopping* a session sits above all of that, because it
 is the only thing in there waiting on a person.
 
@@ -283,7 +284,7 @@ the shape of the decision, and the whole value of asking a person is that they
 can say the thing that was not on the list — so getting there costs one key, and
 `esc` from it comes back to the list rather than abandoning the answer. A chosen
 option and a typed sentence resolve the same question the same way, through the
-same endpoint the inbox and the run page post to: one record, the same
+same endpoint the Waiting on you page and the run page post to: one record, the same
 `answeredBy`, and the badge clears at once.
 
 A permission request is the same widget — R60's lengths of yes as rows, with the
@@ -694,7 +695,7 @@ it ends.
 A bare path means one workspace, which is what every config meant before this
 existed — nothing changes for a machine that serves one checkout per project.
 
-How many coding runs go at once is `min(workspaces, maxSessions)`. A run that
+How many coding runs go at once is the number of workspaces. A run that
 waits now says **"no free workspace in cawdev (2 here, all busy)"** instead of
 "that project already has a run here", which was a proxy for it.
 
@@ -717,18 +718,16 @@ says about knowing it.
 
 **This number caps coding and nothing else** (R70). `ASK`, `ROADMAP`, `AUDIT`
 and `SCOPE` runs take no workspace, so a project whose checkouts are all busy
-still starts a question, an entry-writing session, an audit and a scoping
-session at once. `INTERVIEW`, `MERGE`
+still starts a question, a card-writing run, an audit and a scoping
+run at once. `INTERVIEW`, `MERGE`
 and `RELEASE` do take one — each commits something — and count against this
 number; what each may *write* in it is far narrower than a coding run's and is
 decided by the profile, not by the prompt: an interview writes `docs/brief/`,
 a merge writes the files git put conflict markers in, and a release (R187)
 writes exactly the version files the platform names on the claim, with `git`,
 `gh pr create`, `gh pr view` and `node` for the exports — no build tools, no
-permission prompt, no `gh pr merge`. What holds the rest back
-is `maxSessions`, which counts every profile — **"at 4 sessions on this machine
-(every profile counts)"** is the other thing a waiting run can say, and the log
-always says which of the two it was.
+permission prompt, no `gh pr merge`. What holds a coding run back
+is a free workspace, and the log says so (R109 removed `maxSessions`).
 
 **One thing this gate cannot express, and does not try to.** It serialises on a
 checkout, so two runs on *the same branch* in two checkouts are, to this daemon,
@@ -797,8 +796,8 @@ whether the browser is allowed. Those five answer nearly every "why did that
 not happen", and they used to be spread across a config file and a shrug.
 
 Attaching adds a second bar row: the URL, each project as **coding sessions over
-checkouts** (`cawdev 1/2`), and the machine's total against `maxSessions`.
-Both gates, on screen, counting what each actually bounds — a question is in the
+checkouts** (`cawdev 1/2`), and the machine's total.
+The gate, on screen, counting what it actually bounds — a question is in the
 total on the right and not in any project's figure, because it took no checkout.
 A run that is waiting is explained by the bar
 above it rather than by reading the source. A narrow terminal drops projects
@@ -849,11 +848,11 @@ than twenty-six. A machine that wants it unattended puts that string in its own
 ### What a person can ask of a checkout
 
 R57. The daemon polls `workspace-requests/claim` every few seconds and does one
-of **ten** things to a checkout it serves. It said six for two entries, and
+of **eleven** things to a checkout it serves. It said six for two entries, and
 `HANDOFF` had been missing from the list since R148 — a table that quietly does
 not describe one of the things a person can ask for is worse than no table. So
 count the rows below against that number before you trust either. `CUT_BRANCH`
-is the ninth, R260's; `OPEN_PR` the tenth, R261's.
+is the ninth, R260's; `OPEN_PR` the tenth, R261's, `CREATE_BRANCH` the eleventh, R379's.
 
 | | |
 |---|---|
@@ -867,6 +866,7 @@ is the ninth, R260's; `OPEN_PR` the tenth, R261's.
 | `TAG` | R156's release: `git ls-remote --tags origin refs/tags/<version>` for the version in `message`. **The remote, not this clone** — a local tag nobody pushed is exactly the state a release is trying to rule out, and `git tag --list` cannot tell the two apart. A read; it fetches nothing and moves no ref. The sha is reported on the result's first line, the way `MERGE` reports its URL, because the platform will not confirm a release on `ok: true` alone. **A tag that is not there yet is `ok: false` with a sentence, and that is a normal answer** — the release procedure pushes the tag last, so the first check correctly finds nothing. Addressed to a **release** rather than to a directory alone, which is why it is asked for from the roadmap board and refused on this channel. |
 | `CUT_BRANCH` | R260's sprint branch: `git push origin origin/<default>:refs/heads/<name>` for the branch in `message`, after a fetch — so the sprint's cards are cut from what everyone else has, not from whatever this checkout was left on. The second kind after `MERGE` whose effect is **not** in the checkout: the push names two refs and this clone's HEAD is not one of them, so any live checkout of the project will do and nothing local moves. **A branch already on origin is `ok: true`** ("already on origin at <sha>") — the sprint wanted one to exist, and one does. The sha is reported on the result's first line, the way `TAG` reports its. Addressed to a **sprint** and asked for from the sprint page by an OWNER, for `MERGE`'s reason — it reaches the remote — and refused on this channel. A `MERGE` of a card's pull request into a sprint branch still runs `--squash --delete-branch`: the card's branch goes, the sprint's stays. Landing the sprint branch itself is `OPEN_PR` then `MERGE` below. |
 | `OPEN_PR` | R261's sprint merge, first half: `gh pr create --head <branch> --base <base> --title <title>` for the branch in `message` — the sprint's — to `baseBranch ?? defaultBranch`, titled as the claim's `title` (*S1 Notifications*). **An existing pull request is `ok: true` with its URL** — the same `gh pr view` lookup the `auto_pr` rule makes, and the reason the platform can ask this every time: it holds no git-host credential and cannot know whether one exists. The URL is reported on the result's first line, and the platform queues the `MERGE` to this same checkout when it reads one. Nothing is pushed: the branch is on origin already, cut there by `CUT_BRANCH` and merged into by every card. Addressed to a **work item** — the sprint's — and asked for by Merge on the development board or *Merge sprint* on the sprint page, by an OWNER; refused on this channel for `MERGE`'s reason. |
+| `CREATE_BRANCH` | R379's New branch from the console: pushes `origin/<fromBranch>` to `refs/heads/<name>` for the name in `message`. Unlike `CUT_BRANCH` a name already on origin is a **refusal**, because the person asked for a new branch and the existing one may be somebody else's work. Touches no working tree; a daemon that knows the kind says `createBranch: true` in its hello. |
 
 **A `MERGE` that fails also says which KIND of failure it was** — R155, in one
 of five words beside `gh`'s own unchanged text:
@@ -1257,12 +1257,9 @@ rest queue.
 
 **Questions are not serialised.** An `ASK` run prepares nothing and writes
 nothing, so it runs alongside whatever else is going on — you can ask about a
-project while an agent is working in it. `maxSessions` (4 by default) bounds how
-many agent processes this machine will host at once, and it is the **only**
-thing bounding a question, a roadmap session or an audit (R70). It counts runs
-this daemon has claimed, not children it has spawned: a claim takes a second or
-two to become a process, and counting processes let one pass of the loop claim
-the whole queue.
+project while an agent is working in it. Nothing bounds a question, a roadmap session or an audit but the platform's
+own queue: `maxSessions` was removed in R109, and the workspace gate above is
+the only one.
 
 ## If the daemon dies mid-run
 
@@ -1391,7 +1388,7 @@ permission stops forever.
 
 - `--permission-mode acceptEdits` lets it write files.
 - `--allowedTools mcp__cawdev__…` lets it use the cawdev tools. **Without this
-  the entire loop is unreachable** — no reading the task, no moving the entry,
+  the entire loop is unreachable** — no reading the task, no moving the card,
   no reporting, no asking. A real session found this by being denied
   `task_current` and stopping rather than guessing, which was the right call
   and a good sign for the prompt.
@@ -1417,7 +1414,7 @@ never asks you anything — an unlisted tool is refused, not raised (i138).
 
 **Anything else stops and asks you** (R51). Rather than being denied in
 silence, a session that needs `mvn` or `npm` posts a request that appears in
-your inbox and on the run, and waits for an answer. Allow it once, or allow it
+your Waiting on you page and on the run, and waits for an answer. Allow it once, or allow it
 always here — which writes a rule on the project that every runner serving it
 inherits.
 
@@ -1548,8 +1545,8 @@ after `--mcp-config` fails with `ENAMETOOLONG`, which names neither the flag nor
 the prompt.
 
 The prompt deliberately teaches the **method**, not the task. The task is in the
-roadmap entry, which the agent reads for itself with `task_current` — putting it
-in the prompt too would be a second copy that can disagree with the entry.
+roadmap card, which the agent reads for itself with `task_current` — putting it
+in the prompt too would be a second copy that can disagree with the card.
 
 ### Codex CLI
 

package/runner/runner.mjs

@@ -189,6 +189,7 @@ const DEFAULTS = {
     'mcp__cawdev__quality_get',
     'mcp__cawdev__roadmap_statuses',
     'mcp__cawdev__roadmap_list',
+    'mcp__cawdev__sprint_list',
     'mcp__cawdev__roadmap_get',
     // The MCP server has served this since R37, its README documents it, and
     // the REVIEW prompt below TELLS a session to file its findings with it —
@@ -9643,6 +9644,17 @@ async function main() {
   // right way.
   quiet = attaching;
 
+  // A SIGHUP that arrives while booting — `cawdev config` run a moment after
+  // the daemon started — is held, not fatal: Node's default for an unhandled
+  // SIGHUP is to exit, and the real handler is only installed once
+  // `rereadConfig` exists, well after the first lines are logged. It is
+  // applied as soon as that handler is in place.
+  let hupWhileBooting = false;
+  const holdHup = () => {
+    hupWhileBooting = true;
+  };
+  process.on('SIGHUP', holdHup);
+
   const config = await readConfig();
   // The checkouts made on demand by an earlier run of this daemon, found
   // again by their name — nothing about them is in the config.
@@ -9869,7 +9881,11 @@ async function main() {
     // event type it does not know.
     control?.publish({ type: 'runner', runner: advertised });
   };
+  process.off('SIGHUP', holdHup);
   process.on('SIGHUP', () => rereadConfig('SIGHUP'));
+  if (hupWhileBooting) {
+    void rereadConfig('SIGHUP (sent while booting)');
+  }
 
   // The heartbeat's half of R294: the file's mtime, read once per beat, and a
   // re-read when it moved. `stat` and nothing more when it did not, which is

package/runner/split.mjs

@@ -963,7 +963,7 @@ export function cardLines(card, ink, url = null) {
   field('status', [card.statusDisplay ?? card.status, kind].filter(Boolean).join(' · '));
   field('section', card.section);
   field('tags', card.tags?.length ? card.tags.join(', ') : null);
-  field('sprint', card.sprint ? `${card.sprint.ref ?? card.sprint.number} ${card.sprint.name ?? ''}`.trim() : null);
+  field('sprint', card.sprint ? `${card.sprint.label ?? card.sprint.ref ?? card.sprint.number} ${card.sprint.name ?? ''}`.trim() : null);
   const item = card.workItem;
   field('branch', card.branch ?? item?.branch);
   field('work', item ? [item.statusDisplay ?? item.status, item.runnerName && `on ${item.runnerName}`]