@nanocollective/roster 0.1.0-alpha.42 → 0.1.0-alpha.44

package/docs/portal.md

@@ -21,8 +21,8 @@ Keep the repos checked out beside each other, in the same shape the runner uses.
 Anything that asks before it acts (a merge, a push, a hire, a retire, a paid run) asks in the
 page's own dialog, never the browser's `confirm()`, which blocks the whole tab.
 
-**The counts are right on load.** The badges beside Inbox and Pending work are fetched once at
-boot, and the Inbox screen shares that request rather than making a second one. A sidebar that
+**The counts are right on load.** The badges beside Home and Trackers are fetched once at
+boot, and the screens share that request rather than making a second one. A sidebar that
 says nothing until you look at it is not a sidebar.
 
 While the first answer is outstanding the badge is a placeholder rather than blank, because an
@@ -78,12 +78,45 @@ staff member* first, then the Actions setting, the credential, the repo picker,
 what doctor still says. A link to another screen still wins. When the list is empty the entry
 goes away; the repo picker lives on under [Org](#org).
 
-## Inbox
+## Home
+
+Where the portal opens. An Ask box at the top, then these, in order.
+
+- **Ask.** Pick a staff member, type what you want, **Send**. It opens an issue on their
+  tracker with their `@handle` in front, which wakes them in about a minute.
+- **Latest reports.** Each staff member's run report from the last day: the three lines they
+  post on their status issue at the end of a daily run. Nothing shows until there is one.
+- **Needs you.** Every ask a staff member has put on you, and every pull request ready to
+  merge, oldest first. Each card has its action on it:
+  - a `decision` has an answer box, and **Go with the default** when it carries one. The
+    default and its date are shown, and turn amber once the date has passed.
+  - a `review` has **Approve**.
+  - a `chore` has **Done**, which closes it.
+  - a pull request has **Merge**, unless its checks fail, are still running, or it conflicts.
+
+  Answers go out as you, with the staff member's `@handle`, so they act on them straight away.
+  When nothing is waiting, it says so.
+- **Working now.** Each staff member: what they are running and what started it (the daily run,
+  a follow-on, answering an issue, a peer's ask), for how long, with a link to the log. When
+  they are idle, how their last run ended. Peer and follow-on runs today are counted against
+  `max_runs_per_day`. This asks GitHub every few seconds while a run is going and every half
+  minute otherwise, and only while Home is on screen.
+- **Your requests.** What you asked for: waiting, being worked on (a run for it is going), or
+  answered (a staff member had the last word).
+- **Closed today.** What the staff closed today, with the line they closed it with, and
+  **Reopen** beside each. Staff close finished issues themselves, so this is where you check.
+
+**Nothing is missed.** Every open issue and pull request has exactly one place: on Home, or on
+the staff member's own tracker (their status issue, a peer's ask, their own work), or elsewhere
+(draft pull requests, contributor issues). The line at the bottom counts the last two, with a
+link to Trackers. Clicking any title opens its thread there.
+
+## Trackers
 
 Everything open across the org, from one GraphQL call per repo. Bodies and full timelines come
 down with the list, so opening a thread is a render rather than a request.
 
-- **The links under Inbox in the sidebar filter it.** All; Unread; each staff member, which
+- **The links under Trackers in the sidebar filter it.** All; Unread; each staff member, which
   lists the issues on their own tracker whoever filed them; and Issues, the product repos.
 - **Unread comes from your GitHub notifications.** A thread with activity you have not read has
   a bar on the left and a bold title, and Unread lists only those, with a count. Opening one
@@ -144,7 +177,7 @@ down with the list, so opening a thread is a render rather than a request.
 
 ## Pending work
 
-The same screen, scoped to pull requests, in its own place in the sidebar. An inbox is what is
+The same screen, scoped to pull requests. It is where a pull request opens from Home. An inbox is what is
 waiting on you; a pull request is work that is finished and waiting on a merge, and the count
 that matters is not how many are open but how many are green and still sitting there.
 
@@ -339,7 +372,7 @@ already declared `memory/` as a surface.
 The navigator has three boxes, because a parsed memory section and a file on disk are
 different kinds of thing.
 
-**Memory** is the fact sections, the notes behind them, and `INDEX.md` itself. A note is the
+**What they know** is the fact sections, the notes behind them, and `INDEX.md` itself. A note is the
 argument behind one fact, read only when that fact is in play, which is what keeps the index
 cheap enough to read at every boot. Both live here rather than among the files: `INDEX.md` is
 literally what "All facts" renders.

package/docs/session-workflow.md

@@ -33,6 +33,8 @@ repositories in this organisation**. Without it, callers fail with "workflow not
 | `allowed_tools` | string | `Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch` | Tool permissions, for agents that take them. |
 | `issue_number` | string | `""` | Trigger context. |
 | `comment_id` | string | `""` | Trigger context. |
+| `trigger` | string | `""` | What started the run: `daily`, `manual`, `follow-on`, `mention` or `peer`. Passed to the prompt. |
+| `max_runs_per_day` | number | `6` | How many `peer` and `follow-on` runs may start in a UTC day. Mentions are never counted. |
 
 ## Secrets
 
@@ -51,6 +53,14 @@ authentication error forty lines into a log.
 
 ## What it does, in order
 
+Before the session job, a small **budget** job. For a `peer` or `follow-on` run it counts this
+brain's runs today with those names in their `run-name`, this one included and skipped ones
+left out. Over `max_runs_per_day`, the session does not start and the issue that woke it gets a
+comment saying so. If the runs cannot be read, the run does not start either: a run held back
+costs a day, and a loop costs a bill. Every other trigger goes straight through.
+
+Then the session:
+
 1. **Start the clock**, for the run record.
 2. **Mint the private-tracker token** from the staff member's App.
 3. **Mint the public-repo token**, if a public App was passed.
@@ -70,6 +80,10 @@ authentication error forty lines into a log.
 14. **Work out which agent runs this**, by running `agents.mjs`.
 15. **Run the session**, by one of two steps: the Action-based reference runner, or the generic
     CLI one. See [choosing a coding agent](agents.md).
+    Then, for a mention, **check the request was answered**: a reply in the thread, or the issue
+    closed. Neither fails the job, so the notice below tells the human.
+    Then, for a daily run that finished and wrote `.roster-run/continue`, **start a follow-on
+    run**: one more daily run with `trigger: follow-on`, which waits for this one to end.
 16. **Write down the run**, whatever happened: staff, kind, outcome, duration, and turns, cost
     and tokens where the agent reports them. Into the job summary, and kept as an artifact
     called `roster-run`. Never fatal. See [cost](cost.md#what-each-run-cost).

package/docs/staff-yaml.md

@@ -25,6 +25,7 @@ schedule: "0 7 * * 1-5"
 model: claude-opus-5-5
 timeout_minutes: 90
 mention_timeout_minutes: 90
+max_runs_per_day: 6
 
 bot: acme-cto[bot]
 public_bot: acme-robot[bot]
@@ -49,7 +50,7 @@ surfaces:
 
 labels:
   owner: [will, cto, cmo]
-  kind: [decision, setup, build, blocked]
+  kind: [decision, review, chore, keep-open, build, blocked]
 ```
 
 ## Identity
@@ -71,6 +72,7 @@ labels:
 | `model` | org default | Model id. |
 | `timeout_minutes` | 90 | Ceiling on the daily session. |
 | `mention_timeout_minutes` | 90 | Ceiling on a mention run. |
+| `max_runs_per_day` | 6 | Runs a UTC day that start without a person asking: a peer's ask, or a follow-on to a daily run. Mentions never count. Rendered into the callers, so change it and run `roster upgrade`. |
 
 The three ceilings are separate on purpose. Raising the daily one because sessions have grown
 should not double the budget for a PR amendment. A job killed by a ceiling is reported by
@@ -155,6 +157,19 @@ Labels this staff member expects to exist on its own tracker, grouped for readab
 value across every group is checked by `roster doctor`. An agent applying a label that does not
 exist gets an API error mid-run.
 
+Four labels are roster's own and are checked on every tracker whatever this lists:
+
+| Label | Means |
+|---|---|
+| `decision` | An ask for the human to rule on. It carries a default and a date; past the date, the staff member acts on the default and closes it. |
+| `review` | An ask for the human to read or approve something. |
+| `chore` | Something only the human can do: a setting, an account, a key. |
+| `keep-open` | A standing thread. A sweep never closes it. `roster hire` puts it on the status issue. |
+
+Every ask on the human carries exactly one of the first three, which is how the portal sorts
+what needs them. Staff close any issue on their tracker once nothing is left to do on it,
+including the human's requests, with one line saying what closed it.
+
 ## `memory`
 
 This staff member's own memory budgets, overriding the org's. Same three fields as

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nanocollective/roster",
-  "version": "0.1.0-alpha.42",
+  "version": "0.1.0-alpha.44",
   "description": "An agent-run org, powered by GitHub. Scaffold AI staff members whose brain is a repo.",
   "type": "module",
   "bin": {
@@ -16,23 +16,6 @@
   "engines": {
     "node": ">=20"
   },
-  "scripts": {
-    "build": "tsup src/cli.ts --format esm --target node20 --clean",
-    "dev": "tsx src/cli.ts",
-    "test": "tsx --test test/*.test.ts",
-    "test:all": "pnpm test:format && pnpm test:lint && pnpm test:types && pnpm test:knip && pnpm test",
-    "test:ava:coverage": "c8 --reporter=text --reporter=json-summary tsx --test test/*.test.ts",
-    "test:format": "biome check --no-errors-on-unmatched .",
-    "test:lint": "biome lint .",
-    "test:lint:fix": "biome check --write .",
-    "test:types": "tsc --noEmit",
-    "test:knip": "knip",
-    "test:audit": "pnpm audit --audit-level=high",
-    "test:security": "semgrep scan --config auto --error",
-    "typecheck": "tsc --noEmit",
-    "format": "biome check --write .",
-    "prepublishOnly": "pnpm test:all && pnpm build"
-  },
   "devDependencies": {
     "@biomejs/biome": "^2.5.12",
     "@types/node": "^22.10.2",
@@ -52,9 +35,24 @@
     "url": "https://github.com/Nano-Collective/roster/issues"
   },
   "author": "Nano Collective",
-  "packageManager": "pnpm@11.0.9",
   "publishConfig": {
     "access": "public",
     "tag": "latest"
+  },
+  "scripts": {
+    "build": "tsup src/cli.ts --format esm --target node20 --clean",
+    "dev": "tsx src/cli.ts",
+    "test": "tsx --test test/*.test.ts",
+    "test:all": "pnpm test:format && pnpm test:lint && pnpm test:types && pnpm test:knip && pnpm test",
+    "test:ava:coverage": "c8 --reporter=text --reporter=json-summary tsx --test test/*.test.ts",
+    "test:format": "biome check --no-errors-on-unmatched .",
+    "test:lint": "biome lint .",
+    "test:lint:fix": "biome check --write .",
+    "test:types": "tsc --noEmit",
+    "test:knip": "knip",
+    "test:audit": "pnpm audit --audit-level=high",
+    "test:security": "semgrep scan --config auto --error",
+    "typecheck": "tsc --noEmit",
+    "format": "biome check --write ."
   }
-}
+}

package/templates/brain/.github/workflows/%%STAFF%%-daily.yaml

@@ -6,12 +6,25 @@ name: %%STAFF_UPPER%% daily run
 #
 # NOTE: %%TOKENS%% are filled by `roster hire`; GitHub's own ${{ }} are left alone.
 
+# The trigger and the date, as the Actions list shows it. The daily limit counts follow-on runs
+# by this name.
+run-name: "%%STAFF%% ${{ github.event_name == 'schedule' && 'daily' || inputs.trigger || 'manual' }}"
+
 on:
   schedule:
     - cron: "%%SCHEDULE%%"
+  # By hand, from Run once now, or as a follow-on: a daily run that ended with the next step
+  # ready starts one more, up to max_runs_per_day.
   workflow_dispatch:
+    inputs:
+      trigger:
+        description: "manual | follow-on"
+        required: false
+        default: manual
+        type: string
 
-# A second run while one is in flight would fight it over the tracker and the branch state.
+# A second run while one is in flight would fight it over the tracker and the branch state. A
+# follow-on is started from inside the run before it, so it waits here until that one ends.
 concurrency:
   group: %%STAFF%%-session
   cancel-in-progress: false
@@ -21,13 +34,19 @@ jobs:
     # The ceiling on what session.yaml's job token may do: reading the checkout, and the one
     # comment that says a run failed when the App that would normally say so is what broke.
     # A called workflow cannot raise these, so they have to be granted here.
+    #
+    # `actions` is for the daily limit, which reads this repo's runs, and for starting a
+    # follow-on run, which the job token may do: a workflow_dispatch it sends still starts a run.
     permissions:
       contents: read
       issues: write
+      actions: write
     uses: %%OPS_REPO%%/.github/workflows/session.yaml@main
     with:
       staff: %%STAFF%%
       kind: daily
+      trigger: ${{ github.event_name == 'schedule' && 'daily' || inputs.trigger || 'manual' }}
+      max_runs_per_day: %%MAX_RUNS%%
       ops_repo: %%OPS_REPO%%
       model: %%MODEL%%
       timeout_minutes: %%TIMEOUT%%

package/templates/brain/.github/workflows/%%STAFF%%-mention.yaml

@@ -3,11 +3,18 @@ name: %%STAFF_UPPER%% on a mention
 # Generated by roster. The body lives in %%OPS_REPO%%/.github/workflows/session.yaml.
 #
 # "%%MENTION%% ..." in a comment on this tracker, or in the body of a new issue, wakes a focused
-# run in about 30 seconds. It is a task, not a session: no boot ritual, no handoff, and the reply
+# run in about 30 seconds. So does another staff member filing an issue here with their
+# `from-<handle>` label. It is a task, not a session: no boot ritual, no handoff, and the reply
 # goes in the thread.
 #
 # NOTE: %%TOKENS%% are filled by `roster hire`. GitHub's own ${{ }} expressions are left alone.
 
+# What the run is and what started it, as the Actions list shows it. The portal reads this back
+# to link a live run to the request behind it, and the daily limit counts peer runs by it.
+run-name: >-
+  %%STAFF%% ${{ contains(fromJSON('%%HUMAN_LOGINS%%'), github.event.sender.login) && 'mention' || 'peer' }}
+  #${{ github.event.issue.number }}
+
 on:
   # A mention in the body of a brand new issue, which is often the faster route: one box, rather
   # than a "create, then comment" round trip. `edited` doubles as the way to re-ask without
@@ -44,25 +51,46 @@ jobs:
     #
     # One spelling of the mention is enough: GitHub's `contains` is documented as not case
     # sensitive, so this already matches an uppercase mention at the start of a sentence.
+    #
+    # The second route is a peer's ask: a new issue opened by an App, never this staff member's
+    # own, carrying a `from-<handle>` label. Only `opened`, so the peer editing its own issue
+    # later wakes nobody. It names no peer, so a later hire needs no regenerated caller: the only
+    # accounts that can open an issue on a private tracker are the people and Apps it is
+    # installed for. A peer run may not file on another peer, and session.yaml holds peer runs
+    # to the day's limit, so two staff cannot wake each other forever.
     if: >-
-      contains(fromJSON('%%HUMAN_LOGINS%%'), github.event.sender.login) &&
       (
-        (github.event_name == 'issue_comment' &&
-         contains(fromJSON('%%HUMAN_LOGINS%%'), github.event.comment.user.login) &&
-         contains(github.event.comment.body, '%%MENTION%%')) ||
-        (github.event_name == 'issues' &&
-         contains(github.event.issue.body, '%%MENTION%%'))
+        contains(fromJSON('%%HUMAN_LOGINS%%'), github.event.sender.login) &&
+        (
+          (github.event_name == 'issue_comment' &&
+           contains(fromJSON('%%HUMAN_LOGINS%%'), github.event.comment.user.login) &&
+           contains(github.event.comment.body, '%%MENTION%%')) ||
+          (github.event_name == 'issues' &&
+           contains(github.event.issue.body, '%%MENTION%%'))
+        )
+      ) || (
+        github.event_name == 'issues' && github.event.action == 'opened' &&
+        endsWith(github.event.sender.login, '[bot]') &&
+        github.event.sender.login != '%%APP%%[bot]' &&
+        contains(join(github.event.issue.labels.*.name, ','), 'from-')
       )
     # The ceiling on what session.yaml's job token may do: reading the checkout, and the one
     # comment that says a run failed when the App that would normally say so is what broke.
     # A called workflow cannot raise these, so they have to be granted here.
+    #
+    # `actions` is for the daily limit, which counts this repo's runs today. It is `write`
+    # because session.yaml's job asks for that (a daily run starts its follow-on with it), and a
+    # called job asking for more than its caller granted fails before it starts.
     permissions:
       contents: read
       issues: write
+      actions: write
     uses: %%OPS_REPO%%/.github/workflows/session.yaml@main
     with:
       staff: %%STAFF%%
       kind: mention
+      trigger: ${{ contains(fromJSON('%%HUMAN_LOGINS%%'), github.event.sender.login) && 'mention' || 'peer' }}
+      max_runs_per_day: %%MAX_RUNS%%
       ops_repo: %%OPS_REPO%%
       model: %%MODEL%%
       timeout_minutes: %%MENTION_TIMEOUT%%

package/templates/brain/staff.yaml

@@ -13,6 +13,9 @@ schedule: "%%SCHEDULE%%"
 model: %%MODEL%%
 timeout_minutes: %%TIMEOUT%%
 mention_timeout_minutes: %%MENTION_TIMEOUT%%
+# Runs a day that start without a person asking: a peer's ask, or a follow-on to a daily run.
+# Mentions never count against it.
+max_runs_per_day: %%MAX_RUNS%%
 
 bot: %%APP%%[bot]
 public_bot: %%PUBLIC_APP%%[bot]
@@ -40,4 +43,4 @@ surfaces:
 
 labels:
   owner: [%%HUMAN_MARKER%%, %%STAFF%%]
-  kind: [decision, setup, build, blocked]
+  kind: [decision, review, chore, keep-open, build, blocked]

package/templates/ops/.github/workflows/session.yaml

@@ -19,6 +19,16 @@ on:
         required: false
         default: daily
         type: string
+      # What started the run: daily | manual | follow-on | mention | peer. Peer and follow-on
+      # runs start without a person asking, so they are the ones held to max_runs_per_day.
+      trigger:
+        required: false
+        default: ""
+        type: string
+      max_runs_per_day:
+        required: false
+        default: 6
+        type: number
       ops_repo:
         description: "owner/name of the ops repo holding org.yaml and the prompts"
         required: true
@@ -65,16 +75,69 @@ permissions:
   contents: read
 
 jobs:
+  # Two staff can ask each other things, and a daily run can start a follow-on, so runs can start
+  # runs. This is what stops that at max_runs_per_day. A mention is a person asking and is never
+  # held back, so only peer and follow-on runs are counted, and only the ones that ran: a caller
+  # whose condition did not match leaves a skipped run behind under the same name.
+  budget:
+    runs-on: ubuntu-latest
+    permissions:
+      actions: read
+      issues: write
+    outputs:
+      go: ${{ steps.count.outputs.go }}
+    steps:
+      - name: Count today's runs nobody asked for
+        id: count
+        env:
+          GH_TOKEN: ${{ github.token }}
+          TRIGGER: ${{ inputs.trigger }}
+          STAFF: ${{ inputs.staff }}
+          LIMIT: ${{ inputs.max_runs_per_day }}
+          ISSUE: ${{ inputs.issue_number }}
+        run: |
+          set -uo pipefail
+          case "$TRIGGER" in
+            peer|follow-on) ;;
+            *) echo "go=true" >> "$GITHUB_OUTPUT"; exit 0 ;;
+          esac
+          today=$(date -u +%F)
+          # Includes this run, which is in progress and named like the rest.
+          filter="[.workflow_runs[]
+            | select(.display_title | test(\"^$STAFF (peer|follow-on)( |\$)\"))
+            | select(.conclusion != \"skipped\")] | length"
+          # One count per page, summed. pipefail makes a failed read fail the whole line.
+          if ! n=$(gh api --paginate "repos/${{ github.repository }}/actions/runs?created=>=$today&per_page=100" \
+              --jq "$filter" | awk '{s += $1} END {print s + 0}'); then
+            # Unknown is not under the limit. A run held back costs a day; a loop costs a bill.
+            echo "::warning::could not count today's runs, so this one does not start"
+            n=999999
+          fi
+          echo "$n of $LIMIT runs today that nobody asked for, this one included"
+          if [ "$n" -le "$LIMIT" ]; then
+            echo "go=true" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          echo "go=false" >> "$GITHUB_OUTPUT"
+          msg="Not started: $STAFF has had $LIMIT runs today that nobody asked for, which is max_runs_per_day. The next daily run picks this up, or mention them to start one now."
+          echo "$msg" >> "$GITHUB_STEP_SUMMARY"
+          if [ -n "$ISSUE" ]; then
+            gh issue comment "$ISSUE" --repo "${{ github.repository }}" --body "$msg" || true
+          fi
+
   session:
+    needs: budget
+    if: needs.budget.outputs.go == 'true'
     runs-on: ubuntu-latest
     timeout-minutes: ${{ inputs.timeout_minutes }}
 
     # `issues: write` is for the failure notice alone, which falls back to this job's own token
-    # when the App's cannot be minted. A called workflow cannot raise what its caller granted, so
-    # the callers ask for the same.
+    # when the App's cannot be minted. `actions: write` starts a follow-on run. A called workflow
+    # cannot raise what its caller granted, so the callers ask for the same.
     permissions:
       contents: read
       issues: write
+      actions: write
 
     # secrets are not usable in a step-level `if`, so the presence check is hoisted here.
     env:
@@ -256,7 +319,8 @@ jobs:
             {"issue_number":"${{ inputs.issue_number }}",
              "comment_id":"${{ inputs.comment_id }}",
              "repo":"${{ github.repository }}",
-             "actor":"${{ github.actor }}"}
+             "actor":"${{ github.actor }}",
+             "trigger":"${{ inputs.trigger }}"}
         run: |
           node roster-ops/compose.mjs --staff "${{ inputs.staff }}" --kind "${{ inputs.kind }}" --ops roster-ops --brains . > .roster-prompt.txt
           {
@@ -380,6 +444,25 @@ jobs:
           echo "::error::the session ended without replying on #$ISSUE or closing it"
           exit 1
 
+      # A daily run that ended with the next step ready says so in .roster-run/continue, and one
+      # more run starts once this one ends: it waits on the caller's concurrency group. Only
+      # after a run that finished, and the budget job above holds the chain to the day's limit.
+      # The job token can do this: a workflow_dispatch it sends still starts a run.
+      - name: Start a follow-on run
+        if: >-
+          inputs.kind == 'daily' && success()
+          && (steps.session_action.outcome == 'success' || steps.session_cli.outcome == 'success')
+          && hashFiles('.roster-run/continue') != ''
+        continue-on-error: true
+        env:
+          GH_TOKEN: ${{ github.token }}
+          CALLER: ${{ github.workflow_ref }}
+        run: |
+          set -uo pipefail
+          file=$(basename "${CALLER%@*}")
+          gh workflow run "$file" --repo "${{ github.repository }}" -f trigger=follow-on
+          { echo "Started a follow-on run:"; head -c 300 .roster-run/continue; echo; } >> "$GITHUB_STEP_SUMMARY"
+
       # What this run was and what it cost, in the job summary and as an artifact with a stable
       # name, which is what the portal's Runs screen and `roster doctor` read back. Never fatal:
       # a missing record costs a row in a table, and failing the job over it would cost the run.

package/templates/ops/compose.mjs

@@ -323,6 +323,16 @@ export function compose({ opsDir, brainsDir, staff, kind, runDir }) {
   // sends it to a 404 before it has read anything. So the absence is a value of its own.
   if (Object.keys(event).length) event = { ...event, no_comment: !event.comment_id };
 
+  // Who started this run, as flags: the prompt language has `{{#if}}` and nothing to compare
+  // with. A peer's ask reads differently from a person's, and a follow-on picks up mid-task.
+  const trigger = String(event.trigger ?? "");
+  event = {
+    ...event,
+    from_peer: trigger === "peer",
+    from_human: trigger !== "peer",
+    follow_on: trigger === "follow-on",
+  };
+
   // What people have open on the product repos, gathered by inflight.mjs just before this runs.
   // Read as a value and never rendered as a template: it is PR titles, which are a person's
   // words, and a `{{` in one must not be able to break composition.
@@ -345,6 +355,11 @@ export function compose({ opsDir, brainsDir, staff, kind, runDir }) {
       // The repo this role contributes to but does not own. Named explicitly in the
       // prompt because "a repo you do not own" is vaguer than an agent needs.
       product: (self.works_in ?? [])[0] ?? null,
+      // Absent from manifests written before it existed; the callers fall back to the same.
+      max_runs_per_day: self.max_runs_per_day ?? 6,
+      // One staff member drafts next month's org/priorities.md, so there is one draft rather
+      // than one per person: whoever org.yaml lists first.
+      drafts_priorities: (org.staff ?? [])[0]?.handle === staff,
     },
     peers,
     peer: peers[0] ?? null,

package/templates/ops/org/operating.md

@@ -9,7 +9,8 @@ question instead of doing work has wasted its slot.
 - **A question is an issue, never a stopped run.** When you hit something genuinely load-bearing,
   open a `decision` issue on your own tracker, assign `{{human.github}}`, @-mention them, **then move
   to the next item.** The body: the ask as the first line, your recommendation, the argument stripped
-  to what they need to rule, and **the default if they say nothing**. They are ruling from a phone.
+  to what they need to rule, and the default with a date, as its own last line: **"If I hear nothing
+  by <YYYY-MM-DD>, I'll <do X>."** At least two working days out. They are ruling from a phone.
 - **Filing an issue does not stop the run.** "This needs a human" means open the issue and carry on,
   not stand still.
 - **Never end a run blocked.** If everything on the list is genuinely blocked, do the most useful
@@ -29,12 +30,21 @@ question instead of doing work has wasted its slot.
 
 ## Keeping your tracker clean
 
-{{human.name}} should never have to ask whether an issue can be closed.
-
-- **Close your own issues** when the work is done or superseded, with one line naming what closed
-  it: the PR, the commit, or the issue that replaced it. Do not leave one open "in case".
-- **Sweep them on every daily run.** Read every open issue you opened; close what is finished or
-  stale, and fold duplicates into one.
+{{human.name}} should never have to ask whether an issue can be closed, or close one themselves.
+
+- **Close any issue on your tracker once nothing is left to do on it**, whoever opened it, including
+  {{human.name}}'s requests. One line naming what closed it: the PR, the commit, the answer, or the
+  issue that replaced it. If a request needs nothing, say why in that line and close it. Do not leave
+  one open "in case".
+- **Sweep your tracker on every daily run.** Every open issue on it, not only the ones you opened:
+  close it, do it, or put it in your plan. Fold duplicates into one.
+- **Never close an issue labelled `keep-open`, or your pinned status issue.** Those are standing
+  threads.
+- **Every ask on {{human.name}} carries the `{{human.marker}}` label and exactly one kind**, and is
+  assigned to `{{human.github}}`:
+  - `decision`: they rule on something. Carries the default and date above.
+  - `review`: they read or approve something you made.
+  - `chore`: something only they can do, such as a setting, an account or a key.
 - **Ideas live in your brain, not on the tracker.** Park a speculative idea as one line in
   `strategy/ideas.md`. Open an `IDEA:` issue only when it needs a ruling, and never more than one
   at a time.
@@ -45,7 +55,9 @@ question instead of doing work has wasted its slot.
   mechanical rather than a promise: protected branches mean you open a PR and their merge is the
   approval. **Do not look for a way around it.** Being unable to ship unreviewed is what earns the
   autonomy.
-- **Never close a `decision` issue**, even in a sweep. Those are {{human.name}}'s rulings to close.
+- **Close a `decision` only once it is settled.** Either {{human.name}} answered: act on it, then
+  close it quoting the ruling. Or the date passed with no answer: act on the default, then close it
+  saying you did. Never before one of those.
 - **Never `git add -A` in another staff member's repo, or in a repo where a human may have work in
   flight.** Stage explicit paths. Doing otherwise has swept someone else's uncommitted work into an
   unrelated commit.
@@ -69,6 +81,8 @@ overhead.**
   `log/decisions.md`. A memory that only grows is a memory nobody reads.
 - Mark every fact with where it came from: `[{{human.marker}}]` for a ruling, `[measured]` for
   something with an `n` and a date, `[derived]` for your own inference.
+- **Another run of yours may be working at the same time**: a mention, or a peer's ask. If a push
+  is rejected, `git pull --rebase` and push again. Never force-push.
 
 `log/decisions.md` is **not** boot context. It is the audit trail: read it when you need to know why
 something was decided, or before reversing a call somebody already made.
@@ -80,9 +94,10 @@ Other staff members are peers, not subordinates and not tools. **Write to them f
 team updated is always fine, and over-communicating is the right default.
 
 **Comms are issues, not file drops:** open an issue on their tracker labelled `from-{{staff.handle}}`.
-A file in their inbox works for them and is invisible to {{human.name}}, and he needs to be able to
+A file in their inbox works for them and is invisible to {{human.name}}, who needs to be able to
 read the whole conversation in one place. Genuinely long-form output can still be a file, with the
-issue linking to it.
+issue linking to it. **Filing one wakes them within a minute**, so file what they can act on now
+and put everything else in one issue rather than several.
 
 **An ask of a peer stays an ask.** They own their own priorities. Anything that needs
 {{human.name}}'s money or public sign-off still goes through them.

package/templates/ops/prompts/daily.md

@@ -8,6 +8,11 @@ your brain. Reconstitute yourself, do a day's work, hand off.
 
 {{>? staff:prompts/boot.md}}
 
+{{#if event.follow_on}}
+**This is a follow-on run.** The last run ended with the next step ready and started this one.
+Boot as usual; #{{staff.status_issue}} says what it is.
+{{/if}}
+
 ## Do this now, in order
 
 1. **Check the real date:** `date +%F`. Do not infer it from a file. A run's output was once dated
@@ -59,10 +64,12 @@ writing a plan for {{human.name}} to approve.
 2. **Rewrite pinned issue #{{staff.status_issue}} "Where we are"**: the situation in a line, what
    this run did, what the next run picks up in priority order. **It is a handover for the next run,
    not a diary.** Rewrite it, do not append, and cut anything the next run can find for itself.
-3. **Reconcile the tracker.** Open issues for anything new needing {{human.name}}, labelled by owner
-   plus kind, assigned to `{{human.github}}`. Sweep every open issue you opened: close what is done
-   or superseded, citing what closed it. **Comments and replies get the same concision as everything
-   else:** what changed and what it means for them. A comment that only says an issue is still open
+3. **Reconcile the tracker.** Open issues for anything new needing {{human.name}}: the
+   `{{human.marker}}` label plus one of `decision`, `review` or `chore`, assigned to
+   `{{human.github}}`. Sweep **every** open issue on your tracker, whoever opened it: close what is
+   done, superseded or needs nothing, citing what closed it. A `decision` whose date has passed with
+   no answer: act on the default and close it. **Comments and replies get the same concision as
+   everything else:** what changed and what it means for them. A comment that only says an issue is still open
    is not worth the notification.
 4. **Update `{{staff.dir}}/memory/` only if a fact or watch-out changed.** A new fact is **one line**
    in `INDEX.md` saying what it changes; a corrected fact is **edited in place**, never appended to
@@ -85,6 +92,18 @@ writing a plan for {{human.name}} to approve.
    `@{{human.github}}`. **Three lines: what you did, what is now on them (issue numbers and the ask,
    nothing more), what you would do next.** No preamble, no closing line, no headers. This is the
    only thing they read, and a long one does not get read.
+9. **Start the next run now, if the next step is ready.** When it serves the priorities and waits on
+   nobody (not on {{human.name}}, not on a review, not on a peer), write one line saying what it is:
+   `mkdir -p "$GITHUB_WORKSPACE/.roster-run" && echo "<the step>" > "$GITHUB_WORKSPACE/.roster-run/continue"`.
+   Another run starts when this one ends, up to {{staff.max_runs_per_day}} a day that nobody asked
+   for. Leave it out when there is nothing that cannot wait until tomorrow.
+{{#if staff.drafts_priorities}}
+10. **In the last three days of a month, draft next month's priorities.** If there is no open pull
+    request on `{{ops.dir}}` changing `org/priorities.md` already, open one from a branch: at
+    most three ranked priorities and what is out of scope, built from this month's, what shipped,
+    and the other staff's status issues. The body says what changed from this month and why, in a
+    few lines. {{human.name}} edits and merges it; until then this month's stand.
+{{/if}}
 
 {{> org/guardrails.md}}