From 957a208a4088d87fd9b8487120230a2e5a3e9050 Mon Sep 17 00:00:00 2001
From: Suleiman Shahbari <suleiman@averotech.com>
Date: Sun, 13 Sep 2026 22:12:55 +0300
Subject: [PATCH 1/5] The daemon reads no queue: it starts /work-queue when the
 agent-data branch moves

The drain half of Auto PM goes. The daemon no longer reads the agent
queue, claims tickets for a run, pins an entry into the prompt, or
deletes the entry at settle. It watches the head of the agent-data
branch instead: a commit no daemon wrote starts one agent told
/work-queue, the routine skill this package now ships and links into
every checkout. The agent composes the tickets and queue skills itself.
Its own commits move the branch again, so the daemon fires again as the
run ends; a run that finds nothing queued moves nothing, and the chain
stops. Then the rotation gets its turn. One heartbeat a day is the belt.

Every commit the daemon writes on its own (a run's record, a routine
lock, a plan claim) goes through one funnel that signs it with a
`Daemon: <host>` trailer, so a record never starts the next run and two
daemons sharing a branch never fire at each other.

Gone with it: the drain preset and its recognition, todo-loop.ts and the
merge gate that read the session's TODO file, the ticket start option,
the ticket event and the card's ticket field, the (fix #N) title, the
PATH entries and the three skill links in every checkout, AGENT_ID as an
import from the tickets skill, and the tickets and queue sync calls,
replaced by one pull of agent-data. The Overview's implementing lane
goes with the ticket field; the dashboard half brings it back from the
claim.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DAh91ACHayiEsgT1k2i8Nf
---
 .../dashboard/components/DashboardPage.tsx    |    2 +-
 .../dashboard/components/HotTickets.test.tsx  |   59 +-
 .../dashboard/components/HotTickets.tsx       |   33 +-
 .../dashboard/components/RoutineWork.test.tsx |   62 +-
 .../dashboard/components/RoutineWork.tsx      |   57 +-
 .../dashboard/components/TicketsPage.test.tsx |    7 +-
 .../dashboard/components/TicketsPage.tsx      |    4 +-
 .../components/TicketsPanel.test.tsx          |    9 +-
 .../dashboard/components/TicketsPanel.tsx     |    9 +-
 packages/framework/package.json               |    3 +-
 .../framework/prompts/presets/drain_queue.md  |    1 -
 packages/framework/skills/work-queue/SKILL.md |    7 +
 packages/framework/src/agent-id.ts            |    7 +
 packages/framework/src/agent-telemetry.ts     |    2 +-
 packages/framework/src/agent.test.ts          |   73 +-
 packages/framework/src/agent.ts               |   36 +-
 packages/framework/src/auto-pm.test.ts        | 1262 ++++++++---------
 packages/framework/src/auto-pm.ts             |  668 ++++-----
 packages/framework/src/await-gate.ts          |    7 +-
 packages/framework/src/cli.test.ts            |   17 +-
 packages/framework/src/cli.ts                 |   67 +-
 packages/framework/src/client.ts              |    9 +-
 packages/framework/src/daemon-runtime.test.ts |   27 +-
 packages/framework/src/daemon-runtime.ts      |   62 +-
 .../framework/src/daemon-services.test.ts     |  249 ++--
 packages/framework/src/daemon-services.ts     |  139 +-
 .../framework/src/daemon-workspace.test.ts    |   38 +-
 packages/framework/src/daemon-writes.test.ts  |   74 +
 packages/framework/src/daemon-writes.ts       |   55 +
 packages/framework/src/daemon.test.ts         |    7 +
 packages/framework/src/daemon.ts              |    7 +-
 .../src/dashboard-rpc/control.test.ts         |   54 -
 .../framework/src/dashboard-rpc/control.ts    |   15 +-
 .../framework/src/dashboard-rpc/quota.test.ts |    4 +-
 packages/framework/src/dashboard-rpc/quota.ts |   12 +-
 .../src/dashboard/agent-handoff.test.ts       |   11 +-
 .../framework/src/dashboard/agent-handoff.ts  |   18 +-
 .../framework/src/dashboard/overview.test.ts  |   54 -
 packages/framework/src/dashboard/overview.ts  |   48 +-
 packages/framework/src/dashboard/queue.ts     |    2 +-
 packages/framework/src/dashboard/types.ts     |   14 +-
 .../e2e/story-projects-and-settings.test.ts   |    4 +-
 .../src/e2e/story-tickets-and-queue.test.ts   |   38 +-
 packages/framework/src/events.test.ts         |    4 -
 packages/framework/src/events.ts              |   16 +-
 packages/framework/src/preset-catalog.test.ts |    8 +-
 packages/framework/src/preset-catalog.ts      |   25 +-
 packages/framework/src/registry.ts            |    2 +-
 .../framework/src/store/agent-store.test.ts   |   10 -
 packages/framework/src/store/agent-store.ts   |   11 -
 .../framework/src/store/run-record.test.ts    |    3 +-
 packages/framework/src/store/run-record.ts    |    8 +-
 packages/framework/src/system-prompt.ts       |    2 +-
 packages/framework/src/terminal.ts            |    4 -
 packages/framework/src/todo-loop.test.ts      |  350 -----
 packages/framework/src/todo-loop.ts           |  233 ---
 packages/framework/src/turn-gate.ts           |    4 +-
 packages/skill-branches/src/checkout.ts       |    5 +-
 packages/skill-branches/src/skill-links.ts    |    9 +-
 59 files changed, 1414 insertions(+), 2613 deletions(-)
 delete mode 100644 packages/framework/prompts/presets/drain_queue.md
 create mode 100644 packages/framework/skills/work-queue/SKILL.md
 create mode 100644 packages/framework/src/daemon-writes.test.ts
 create mode 100644 packages/framework/src/daemon-writes.ts
 delete mode 100644 packages/framework/src/todo-loop.test.ts
 delete mode 100644 packages/framework/src/todo-loop.ts

diff --git a/packages/framework/dashboard/components/DashboardPage.tsx b/packages/framework/dashboard/components/DashboardPage.tsx
index acf0b9f3d..f86625b11 100644
--- a/packages/framework/dashboard/components/DashboardPage.tsx
+++ b/packages/framework/dashboard/components/DashboardPage.tsx
@@ -79,7 +79,7 @@ export function DashboardPage({
             that fires one now. */}
         <RoutineWork onAgentStarted={onAgentStarted} onSelectProject={onSelectProject} />
 
-        <HotTickets onSelectProject={onSelectProject} onSelectAgent={onSelectAgent} />
+        <HotTickets onSelectProject={onSelectProject} />
       </div>
     </ScrollArea>
   )
diff --git a/packages/framework/dashboard/components/HotTickets.test.tsx b/packages/framework/dashboard/components/HotTickets.test.tsx
index 499cbd262..9cc3d16a4 100644
--- a/packages/framework/dashboard/components/HotTickets.test.tsx
+++ b/packages/framework/dashboard/components/HotTickets.test.tsx
@@ -26,7 +26,7 @@ const ht = (file: string, projectName: string, bucket: HotBucket, over: Record<s
 describe('HotTickets (#1112)', () => {
   test('with no hot tickets it names the empty lanes rather than claiming no tickets exist', async () => {
     onHotTickets.mockResolvedValue([])
-    render(<HotTickets onSelectProject={() => {}} onSelectAgent={vi.fn()} />)
+    render(<HotTickets onSelectProject={() => {}} />)
     await waitFor(() => expect(screen.getByText('Nothing in progress, queued, or high priority.')).toBeTruthy())
   })
 
@@ -37,7 +37,7 @@ describe('HotTickets (#1112)', () => {
       ht('c.md', 'alpha', 'ai-queue'),
     ])
     let picked: string | null = null
-    render(<HotTickets onSelectProject={id => (picked = id)} onSelectAgent={vi.fn()} />)
+    render(<HotTickets onSelectProject={id => (picked = id)} />)
     await waitFor(() => expect(screen.getByText('a')).toBeTruthy())
     expect(screen.getByText('In progress')).toBeTruthy()
     expect(screen.getByText('AI Queue')).toBeTruthy()
@@ -45,56 +45,12 @@ describe('HotTickets (#1112)', () => {
     fireEvent.click(screen.getByText('b'))
     expect(picked).toBe('beta')
   })
-
-  test('a ticket a run is implementing right now says so, over its plan/spike (#1117)', async () => {
-    onHotTickets.mockResolvedValue([
-      { ...ht('a.md', 'alpha', 'in-progress', { planned: true }), agentId: 'run-7' },
-      ht('b.md', 'alpha', 'in-progress', { planned: true }),
-    ])
-    render(<HotTickets onSelectProject={() => {}} onSelectAgent={vi.fn()} />)
-    await waitFor(() => expect(screen.getByText('a')).toBeTruthy())
-    // Live work outranks the mark older work left behind, so the same lane can say which is which.
-    expect(screen.getByText('implementing')).toBeTruthy()
-    expect(screen.getByText('planned')).toBeTruthy()
-  })
-
-  test('a ticket being implemented with no plan or spike still gets a tag (#1117)', async () => {
-    // The gap the agent link opens up: in-progress used to imply planned-or-spiked, so a bare
-    // implementing ticket would have shown an unexplained row.
-    onHotTickets.mockResolvedValue([{ ...ht('a.md', 'alpha', 'in-progress'), agentId: 'run-7' }])
-    render(<HotTickets onSelectProject={() => {}} onSelectAgent={vi.fn()} />)
-    await waitFor(() => expect(screen.getByText('implementing')).toBeTruthy())
-  })
-})
-
-describe('a hot ticket that names a run opens that run', () => {
-  test('an implemented ticket goes to its session, not its project home', async () => {
-    // The in-progress lane exists because an agent said it is implementing this ticket (#1117), so
-    // the session it names is what the row is reporting on.
-    onHotTickets.mockResolvedValue([{ ...ht('a.md', 'alpha', 'in-progress'), agentId: 'run-9' }])
-    const onSelectAgent = vi.fn()
-    const onSelectProject = vi.fn()
-    render(<HotTickets onSelectProject={onSelectProject} onSelectAgent={onSelectAgent} />)
-    fireEvent.click(await screen.findByText('a'))
-    expect(onSelectAgent).toHaveBeenCalledWith('alpha', 'run-9')
-    expect(onSelectProject).not.toHaveBeenCalled()
-  })
-
-  test('a ticket with no run still goes to its project', async () => {
-    onHotTickets.mockResolvedValue([ht('b.md', 'beta', 'ai-queue')])
-    const onSelectAgent = vi.fn()
-    const onSelectProject = vi.fn()
-    render(<HotTickets onSelectProject={onSelectProject} onSelectAgent={onSelectAgent} />)
-    fireEvent.click(await screen.findByText('b'))
-    expect(onSelectProject).toHaveBeenCalledWith('beta')
-    expect(onSelectAgent).not.toHaveBeenCalled()
-  })
 })
 
 describe('a hot ticket with no run prefills the launcher it lands on', () => {
   test('the click carries the ticket over as a composer draft', async () => {
     onHotTickets.mockResolvedValue([ht('b.md', 'beta', 'ai-queue')])
-    render(<HotTickets onSelectProject={vi.fn()} onSelectAgent={vi.fn()} />)
+    render(<HotTickets onSelectProject={vi.fn()} />)
     fireEvent.click(await screen.findByText('b'))
     // Without this the row was a dead end: the launcher came up empty and the one fact the row
     // carried — which ticket — was dropped. Composer takes this at mount (#1066).
@@ -105,13 +61,4 @@ describe('a hot ticket with no run prefills the launcher it lands on', () => {
     // The title is prose the agent would have to search for; the file is the ticket's identity.
     expect(workOnTicketDraft('add-oauth.md')).toContain('tickets/add-oauth.md')
   })
-
-  test('a ticket that opens a live session leaves no draft behind', async () => {
-    onHotTickets.mockResolvedValue([{ ...ht('a.md', 'alpha', 'in-progress'), agentId: 'run-9' }])
-    render(<HotTickets onSelectProject={vi.fn()} onSelectAgent={vi.fn()} />)
-    fireEvent.click(await screen.findByText('a'))
-    // That click goes to a session, not a launcher, so a draft stashed here would surface later
-    // on the next unrelated visit to one.
-    expect(takePendingDraft()).toBeNull()
-  })
 })
diff --git a/packages/framework/dashboard/components/HotTickets.tsx b/packages/framework/dashboard/components/HotTickets.tsx
index 18cc35564..5ff7807bc 100644
--- a/packages/framework/dashboard/components/HotTickets.tsx
+++ b/packages/framework/dashboard/components/HotTickets.tsx
@@ -52,14 +52,7 @@ const LEFT_LANES: LaneDef[] = [
 ]
 const RIGHT_LANES: LaneDef[] = [{ key: 'high-priority', label: 'High priority', dot: 'bg-info' }]
 
-export function HotTickets({
-  onSelectProject,
-  onSelectAgent,
-}: {
-  onSelectProject: (id: string) => void
-  /** A ticket an agent is implementing knows which run (#1117), so its row opens that session. */
-  onSelectAgent: (id: string, agentId: string) => void
-}) {
+export function HotTickets({ onSelectProject }: { onSelectProject: (id: string) => void }) {
   const { value: tickets } = usePolled<HotTicket[]>(onHotTickets, EMPTY, 10_000, [])
 
   const renderLane = (lane: LaneDef) => (
@@ -68,7 +61,6 @@ export function HotTickets({
       lane={lane}
       tickets={tickets.filter(t => t.bucket === lane.key)}
       onSelectProject={onSelectProject}
-      onSelectAgent={onSelectAgent}
     />
   )
 
@@ -100,12 +92,10 @@ function Lane({
   lane,
   tickets,
   onSelectProject,
-  onSelectAgent,
 }: {
   lane: LaneDef
   tickets: HotTicket[]
   onSelectProject: (id: string) => void
-  onSelectAgent: (id: string, agentId: string) => void
 }) {
   const empty = tickets.length === 0
   return (
@@ -128,9 +118,8 @@ function Lane({
                   render={
                     <button
                       type="button"
-                      // A ticket being implemented names its agent, and that session is what the row is
-                      // reporting; one with no agent yet opens its project's launcher, asking for it.
-                      onClick={() => (t.agentId ? onSelectAgent(t.projectId, t.agentId) : openTicket(t, onSelectProject))}
+                      // The row opens its project's launcher with the ticket drafted in, asking for it.
+                      onClick={() => openTicket(t, onSelectProject)}
                       className="flex w-full items-center gap-2 rounded-md px-2 py-1.5 text-left hover:bg-accent focus-visible:bg-accent focus-visible:outline-none"
                     />
                   }
@@ -149,21 +138,9 @@ function Lane({
   )
 }
 
-// The one fact that earns the lane: an agent implementing it right now, else the plan that made it
-// in-progress, else the priority that put it in the high-priority lane. AI-Queue rows carry
-// nothing extra — the lane already says it.
-//
-// `implementing` is coloured rather than muted like the others (#1117), because it is the only tag
-// that describes something happening as you read it: `planned` is a mark work left behind, and a
-// lane holding both should not read as though they were the same claim.
+// The one fact that earns the lane: the plan that made it in-progress, else the priority that put
+// it in the high-priority lane. AI-Queue rows carry nothing extra — the lane already says it.
 function TicketTag({ ticket: t }: { ticket: HotTicket }) {
-  if (t.agentId) {
-    return (
-      <span className="shrink-0 rounded border border-primary/40 px-1 text-[10px] uppercase tracking-wide text-primary">
-        implementing
-      </span>
-    )
-  }
   const tag =
     t.bucket === 'in-progress'
       ? t.ticket.planned
diff --git a/packages/framework/dashboard/components/RoutineWork.test.tsx b/packages/framework/dashboard/components/RoutineWork.test.tsx
index 4c50c5f83..23282e780 100644
--- a/packages/framework/dashboard/components/RoutineWork.test.tsx
+++ b/packages/framework/dashboard/components/RoutineWork.test.tsx
@@ -4,7 +4,7 @@ import { cleanup, fireEvent, render, screen, waitFor } from '@testing-library/re
 import type { AutoPmJob, AutoPmReport, Preferences, ProjectSummary } from '../../src/index.js'
 import {
   AUTO_PM_ROUTINES,
-  AUTO_PM_DRAIN_JOB,
+  AUTO_PM_WORK_JOB,
   AUTO_PM_MAINTENANCE_JOB,
   DEFAULT_AUTO_PM_CONCURRENCY,
 } from '../../src/client.js'
@@ -80,8 +80,8 @@ describe('RoutineWork (#1159)', () => {
     }
   })
 
-  // The drain leads the list, and since #1204 its Run now goes to the sweep, so the plain-start
-  // tests click the first *rotation* row instead.
+  // The queued work leads the list, and its Run now goes to the sweep, so the plain-start tests
+  // click the first *rotation* row instead.
   const ROTATION_JOB = AUTO_PM_ROUTINES[1]!
 
   test('Run now starts the routine prompt verbatim and selects the run it started (#1191)', async () => {
@@ -141,14 +141,14 @@ describe('RoutineWork (#1159)', () => {
     expect((await hoverTooltip(await runNowOf(ROTATION_JOB))).textContent).toContain('Claude web')
   })
 
-  test("the drain's Run now reports the sweep it fires, not these settings (#1506)", async () => {
+  test("the queued work's Run now reports the sweep it fires, not these settings (#1506)", async () => {
     prefs = { model: 'opus', autoPmConcurrency: 3 }
     renderCard()
-    const hint = await hoverTooltip(await runNowOf(AUTO_PM_DRAIN_JOB))
+    const hint = await hoverTooltip(await runNowOf(AUTO_PM_WORK_JOB))
     // The sweep visits every project and resolves each one's own committed settings on top of
     // these, so the model and place the other rows promise would both be a guess here.
     expect(hint.textContent).toContain("Each project's own settings decide the model and where it runs.")
-    expect(hint.textContent).toMatch(/Sweeps every project the daemon watches, up to 3 agents each, unattended/)
+    expect(hint.textContent).toMatch(/Starts one agent in every project the daemon watches, unattended/)
     expect(hint.textContent).not.toContain('Opus')
   })
 
@@ -169,7 +169,7 @@ describe('RoutineWork (#1159)', () => {
     renderCard()
     fireEvent.click(await runNowOf(PLAN_JOB))
     await waitFor(() => expect(sendAutoPmSweep).toHaveBeenCalled())
-    // Narrowed to planning, and scoped to the project the picker shows: the drain's Run now
+    // Narrowed to planning, and scoped to the project the picker shows: the queued work's Run now
     // deliberately sends no id because it sweeps every project, and this one is not that.
     expect(sendAutoPmSweep).toHaveBeenCalledWith({ only: 'plan', projectId: 'p1' })
     // The fan-out is the sweep's whole point here: a plain start is the pre-#1204 behaviour and
@@ -182,8 +182,8 @@ describe('RoutineWork (#1159)', () => {
     renderCard()
     const hint = await hoverTooltip(await runNowOf(PLAN_JOB))
     expect(hint.textContent).toMatch(/Starts up to 3 agents in gemstack, one per open ticket, unattended/)
-    // Not the drain's line: this one stays in the picked project and does resolve these settings.
-    expect(hint.textContent).not.toContain('Sweeps every project')
+    // Not the queued work's line: this one stays in the picked project and does resolve these settings.
+    expect(hint.textContent).not.toContain('every project the daemon watches')
     expect(hint.textContent).toContain('Claude Code · Opus · This machine')
   })
 
@@ -265,12 +265,12 @@ describe('RoutineWork (#1159)', () => {
     expect((screen.getByLabelText('Run in') as HTMLSelectElement).value).toBe('p1')
   })
 
-  test("the drain's menu item says it is one agent, not the fan-out its Run now fires (#1507)", async () => {
+  test("the queued work's menu item says it is one agent in one project, not every project (#1507)", async () => {
     renderCard()
-    await openRunMenu(AUTO_PM_DRAIN_JOB)
-    // The launcher can only ever send one agent, so this row's two halves really do different
-    // jobs — and the row says so rather than letting them look alike.
-    expect(await screen.findByText(/one agent, not the fan-out/)).toBeTruthy()
+    await openRunMenu(AUTO_PM_WORK_JOB)
+    // The launcher can only ever send one agent to one project, so this row's two halves really
+    // do different jobs — and the row says so rather than letting them look alike.
+    expect(await screen.findByText(/one agent in this project, not every project/)).toBeTruthy()
   })
 
   test('a routine whose Run now is a plain start promises the settings, not a caveat (#1507)', async () => {
@@ -291,23 +291,23 @@ describe('RoutineWork (#1159)', () => {
     await waitFor(() => expect(selected).toEqual(['p1']))
   })
 
-  test("the drain's Run now fires a drain-only sweep, the only thing that can fan out (#1204)", async () => {
-    // Rom's demo click: "Spin up agents working on the AI queue" must spin up to the concurrency,
-    // one agent per entry. A plain start could only ever be one agent on the first entry.
+  test("the queued work's Run now fires the sweep, narrowed to the queued work (#1204/#1774)", async () => {
+    // The click starts an agent on the queue in every project the daemon watches, with the
+    // sweep's own gates; a plain start could only ever be one agent in the picked project.
     sendAutoPmSweep.mockResolvedValue({ ok: true })
     const started: unknown[][] = []
     renderCard({ onAgentStarted: (...args) => started.push(args) })
     await waitFor(() => expect(screen.getAllByText('Run now').length).toBeGreaterThan(0))
     fireEvent.click(screen.getAllByText('Run now')[0]!)
-    // No project id on purpose: the drain sweeps every project the daemon watches, which is what
-    // its own tooltip promises — unlike the planning routine's click, which stays in the picked one.
-    await waitFor(() => expect(sendAutoPmSweep).toHaveBeenCalledWith({ only: 'drain' }))
+    // No project id on purpose: the queued work visits every project the daemon watches, which is
+    // what its own tooltip promises — unlike the planning routine's click, which stays in the picked one.
+    await waitFor(() => expect(sendAutoPmSweep).toHaveBeenCalledWith({ only: 'work' }))
     expect(start).not.toHaveBeenCalled()
     // No navigation: the batch lands in the Agents card, not one session's page.
     expect(started).toHaveLength(0)
   })
 
-  test("the drain's Run now on a host with no sweep says so instead of failing silently (#1204)", async () => {
+  test("the queued work's Run now on a host with no sweep says so instead of failing silently (#1204)", async () => {
     sendAutoPmSweep.mockResolvedValue({ ok: false })
     renderCard()
     await waitFor(() => expect(screen.getAllByText('Run now').length).toBeGreaterThan(0))
@@ -372,17 +372,17 @@ describe('RoutineWork (#1159)', () => {
     await waitFor(() => expect(screen.getAllByText('Run now').length).toBe(AUTO_PM_ROUTINES.length))
     // Nothing saved means nothing opted out: the schedule is whole until it is edited.
     for (const job of AUTO_PM_ROUTINES) expect(routineBox(job).getAttribute('aria-checked')).toBe('true')
-    fireEvent.click(screen.getByText(routineName(AUTO_PM_DRAIN_JOB)))
-    expect(updatePreferences).toHaveBeenCalledWith({ autoPmOptOut: [AUTO_PM_DRAIN_JOB.name] })
+    fireEvent.click(screen.getByText(routineName(AUTO_PM_WORK_JOB)))
+    expect(updatePreferences).toHaveBeenCalledWith({ autoPmOptOut: [AUTO_PM_WORK_JOB.name] })
   })
 
   test('an opted-out routine shows unticked, and re-ticking it drops only it (#1209)', async () => {
     const other = AUTO_PM_ROUTINES[1]!.name
-    prefs = { autoPmOptOut: [AUTO_PM_DRAIN_JOB.name, other] }
+    prefs = { autoPmOptOut: [AUTO_PM_WORK_JOB.name, other] }
     renderCard()
     await waitFor(() => expect(screen.getAllByText('Run now').length).toBe(AUTO_PM_ROUTINES.length))
-    expect(routineBox(AUTO_PM_DRAIN_JOB).getAttribute('aria-checked')).toBe('false')
-    fireEvent.click(screen.getByText(routineName(AUTO_PM_DRAIN_JOB)))
+    expect(routineBox(AUTO_PM_WORK_JOB).getAttribute('aria-checked')).toBe('false')
+    fireEvent.click(screen.getByText(routineName(AUTO_PM_WORK_JOB)))
     // The other opt-out survives: the row writes the whole set, so it must not clear its siblings.
     expect(updatePreferences).toHaveBeenCalledWith({ autoPmOptOut: [other] })
   })
@@ -467,26 +467,26 @@ describe('RoutineWork (#1159)', () => {
     sendAutoPmSweep.mockResolvedValue({
       ok: true,
       outcomes: [
-        { projectId: 'p1', path: '/home/me/alpha', started: true, message: 'started a drain' },
+        { projectId: 'p1', path: '/home/me/alpha', started: true, message: 'Work the queue' },
         { projectId: 'p2', path: '/home/me/beta', started: false, message: 'a run is already active' },
       ],
     })
     renderCard()
     fireEvent.click(await screen.findByText('Trigger routine now'))
-    await waitFor(() => expect(screen.getByRole('status').textContent).toMatch(/alpha: started a drain/))
+    await waitFor(() => expect(screen.getByRole('status').textContent).toMatch(/alpha: Work the queue/))
     expect(screen.getByRole('status').textContent).toMatch(/beta: a run is already active/)
   })
 
-  test("the drain's Run now reports its sweep's outcome the same way (#1433)", async () => {
+  test("the queued work's Run now reports its sweep's outcome the same way (#1433)", async () => {
     sendAutoPmSweep.mockResolvedValue({
       ok: true,
-      outcomes: [{ projectId: 'p1', path: '/home/me/repo', started: false, message: 'the queue is empty, so there is nothing to drain' }],
+      outcomes: [{ projectId: 'p1', path: '/home/me/repo', started: false, message: 'the routine that works the queue is switched off' }],
     })
     renderCard()
     await waitFor(() => expect(screen.getAllByText('Run now').length).toBeGreaterThan(0))
     fireEvent.click(screen.getAllByText('Run now')[0]!)
     await waitFor(() =>
-      expect(screen.getByRole('status').textContent).toBe('the queue is empty, so there is nothing to drain'),
+      expect(screen.getByRole('status').textContent).toBe('the routine that works the queue is switched off'),
     )
   })
 
diff --git a/packages/framework/dashboard/components/RoutineWork.tsx b/packages/framework/dashboard/components/RoutineWork.tsx
index b2fbc3e93..0067a024b 100644
--- a/packages/framework/dashboard/components/RoutineWork.tsx
+++ b/packages/framework/dashboard/components/RoutineWork.tsx
@@ -19,8 +19,8 @@ import { Checkbox } from './ui/checkbox.js'
 import { Tooltip, TooltipTrigger, TooltipContent } from './ui/tooltip.js'
 import { StartAgentButton } from './StartAgentButton.js'
 
-// The Overview's "Routine work" card (#1159): the jobs the idle sweep fires on a schedule, each with
-// a Run now button that starts it against a project immediately.
+// The Overview's "Routine work" card (#1159): the jobs the daemon fires on its own, each with a
+// Run now button that starts it against a project immediately.
 //
 // The list is `AUTO_PM_ROUTINES` itself, straight off the browser-safe client entry, so what is on
 // screen is what the daemon runs rather than a second copy of it: no read of its own, and no way
@@ -43,19 +43,20 @@ const NO_PROJECTS: ProjectSummary[] = []
 /**
  * The sweep a routine's Run now asks for, when it is a sweep rather than a plain start — or
  * nothing, for the routine a plain start serves exactly. Decided by what the job declares about
- * itself (it drains, fans out, or holds a lock), never by its name, so a renamed routine keeps
- * its path.
+ * itself (it works the queue, fans out, or holds a lock), never by its name, so a renamed routine
+ * keeps its path.
  *
- * The two that fan out (#1204) go because only the sweep can: it claims the work before each
- * agent starts — a queue entry for a drain, a ticket lock for planning — and a plain start could
- * only ever be one agent. A routine that holds a lock (#1643/#1659) goes for the same claim: the
- * sweep takes `routines/<name>.lock.md` before the start, and a plain start would run unguarded.
+ * The queued work (#1774) goes through the sweep because the sweep is what fires it: one agent
+ * per project, with the sweep's own gates. Planning (#1204) goes because only the sweep can claim
+ * a ticket before each agent starts, and a plain start could only ever be one agent. A routine
+ * that holds a lock (#1643/#1659) goes for the same claim: the sweep takes
+ * `routines/<name>.lock.md` before the start, and a plain start would run unguarded.
  *
- * The drain visits every project, which is what its tooltip says and why it sends no id. The
- * rest are the picked project's own work, so they carry one.
+ * The queued work visits every project, which is what its tooltip says and why it sends no id.
+ * The rest are the picked project's own work, so they carry one.
  */
 function narrowedSweep(job: AutoPmJob, projectId: string): { only: AutoPmOnly; projectId?: string } | undefined {
-  if (job.drains) return { only: 'drain' }
+  if (job.works) return { only: 'work' }
   if (job.fansOut) return { only: 'plan', projectId }
   if (job.lock !== undefined) return { only: { lock: job.lock }, projectId }
   return undefined
@@ -247,34 +248,34 @@ export function RoutineWork({
                     onStart={() => void runNow(job)}
                     onConfigure={() => projectId && onSelectProject(projectId)}
                     prompt={job.prompt}
-                    /* A fan-out routine's Run now is a sweep, and the launcher can only ever send
-                       one agent — so this row's secondary action really is a different job, and
-                       says so rather than looking like the same one. Both fan-out routines
-                       (#1204), not just the drain: the same sentence is true the moment a Run now
-                       stops being one start. */
+                    /* A routine whose Run now is a sweep over every project, or a fan-out, is
+                       not one agent — so this row's secondary action really is a different job,
+                       and says so rather than looking like the same one. */
                     configureDescription={
-                      job.drains || job.fansOut
-                        ? 'Opens the launcher with this prompt — one agent, not the fan-out.'
-                        : 'Opens the launcher with this prompt, so you can set the model and where it runs.'
+                      job.works
+                        ? 'Opens the launcher with this prompt — one agent in this project, not every project.'
+                        : job.fansOut
+                          ? 'Opens the launcher with this prompt — one agent, not the fan-out.'
+                          : 'Opens the launcher with this prompt, so you can set the model and where it runs.'
                     }
                     tooltipClassName="max-w-[22rem] space-y-1"
                     tooltip={
                       <>
                         {job.tooltip && <span className="block">{job.tooltip}</span>}
-                        {/* The drain row's Run now is the sweep, so neither half of the settings
-                            line would be true of it: the sweep resolves each project's own
-                            `the-framework.yml` on top of these preferences, and it visits every
-                            project rather than the one picked above. It says that instead. */}
+                        {/* The queued-work row's Run now is the sweep, so neither half of the
+                            settings line would be true of it: the sweep resolves each project's
+                            own `the-framework.yml` on top of these preferences, and it visits
+                            every project rather than the one picked above. It says that instead. */}
                         <span className="block text-muted-foreground">
-                          {job.drains ? "Each project's own settings decide the model and where it runs." : settings}
+                          {job.works ? "Each project's own settings decide the model and where it runs." : settings}
                         </span>
                         {/* Three cases, because the click does three different things (#1204).
                             A routine that fans out spends what the setting allows rather than one
                             agent, so a tooltip that exists to say what a click costs has to say
                             so — and "one per ticket" is why several here is not redundant work. */}
                         <span className="block text-muted-foreground">
-                          {job.drains
-                            ? `Sweeps every project the daemon watches, up to ${concurrency} ${concurrency === 1 ? 'agent' : 'agents'} each, unattended.`
+                          {job.works
+                            ? 'Starts one agent in every project the daemon watches, unattended.'
                             : job.fansOut
                               ? `Starts up to ${concurrency} ${concurrency === 1 ? 'agent' : 'agents'}${projectName ? ` in ${projectName}` : ''}, one per open ticket, unattended.`
                               : `Starts one agent${projectName ? ` in ${projectName}` : ''}, unattended — nothing is asked mid-run.`}
@@ -330,8 +331,8 @@ export function RoutineWork({
                 </Tooltip>
               </div>
               {/* The concurrency setting (#1204). Beside the switch it qualifies, and worded as
-                  what it does rather than as a number: only draining fans out, because that is the
-                  routine that takes work off the queue one entry at a time. */}
+                  what it does rather than as a number: the queued work runs one agent per move of
+                  the branch, and the cap is how many of them may overlap. */}
               <div className="mt-2 flex items-center justify-between gap-2">
                 <Tooltip>
                   <TooltipTrigger
diff --git a/packages/framework/dashboard/components/TicketsPage.test.tsx b/packages/framework/dashboard/components/TicketsPage.test.tsx
index 129b061a1..14ddc34e1 100644
--- a/packages/framework/dashboard/components/TicketsPage.test.tsx
+++ b/packages/framework/dashboard/components/TicketsPage.test.tsx
@@ -255,7 +255,7 @@ describe('TicketsPage grouping (#1144)', () => {
     expect(onOpenTicket).toHaveBeenCalledWith('p2', 'b.md')
   })
 
-  test("a flat row's start button spins up an agent in that row's own project (#1117)", async () => {
+  test("a flat row's start button spins up an agent in that row's own project (#1144)", async () => {
     onAllTickets.mockResolvedValue([
       { projectId: 'p2', projectName: 'Beta', tickets: [ticket({ file: 'b.md', title: 'Beta ticket' })] },
     ])
@@ -267,10 +267,7 @@ describe('TicketsPage grouping (#1144)', () => {
     fireEvent.click(await screen.findByRole('button', { name: /start work on beta ticket/i }))
     // The row's own project, not a panel-bound one — the flat list carries one per row.
     await waitFor(() =>
-      expect(sendStart).toHaveBeenCalledWith('p2', expect.stringContaining('tickets/b.md'), 'prompt', {
-        unattended: true,
-        ticket: 'tickets/b.md',
-      }),
+      expect(sendStart).toHaveBeenCalledWith('p2', expect.stringContaining('tickets/b.md'), 'prompt', { unattended: true }),
     )
     await waitFor(() => expect(onAgentStarted).toHaveBeenCalledWith('p2', expect.any(String), 'r9'))
   })
diff --git a/packages/framework/dashboard/components/TicketsPage.tsx b/packages/framework/dashboard/components/TicketsPage.tsx
index fa0398f3d..1ed5c3ef9 100644
--- a/packages/framework/dashboard/components/TicketsPage.tsx
+++ b/packages/framework/dashboard/components/TicketsPage.tsx
@@ -100,11 +100,11 @@ export function TicketsPage({
     const outcome = await run(() => sendStart(projectId, prompt, 'prompt'), 'The planning agent could not be started.')
     if (outcome.ok) onAgentStarted?.(projectId, prompt, outcome.value.agentId)
   }
-  // Unattended with the ticket named on the options, exactly as the panel's own start column does.
+  // Unattended, exactly as the panel's own start column does.
   const startWork = async (projectId: string, file: string) => {
     const prompt = workOnTicketPrompt(file)
     const outcome = await run(
-      () => sendStart(projectId, prompt, 'prompt', { unattended: true, ticket: `tickets/${file}` }),
+      () => sendStart(projectId, prompt, 'prompt', { unattended: true }),
       'The work agent could not be started.',
     )
     if (outcome.ok) onAgentStarted?.(projectId, prompt, outcome.value.agentId)
diff --git a/packages/framework/dashboard/components/TicketsPanel.test.tsx b/packages/framework/dashboard/components/TicketsPanel.test.tsx
index 5af04a805..bb72dcd95 100644
--- a/packages/framework/dashboard/components/TicketsPanel.test.tsx
+++ b/packages/framework/dashboard/components/TicketsPanel.test.tsx
@@ -69,7 +69,7 @@ describe('TicketsPanel (#697/#1144)', () => {
     await waitFor(() => expect(onAgentStarted).toHaveBeenCalledWith(expect.any(String), 'r3'))
   })
 
-  test('the start column spins up an agent working on the ticket, unattended and with the ticket named (#1117/#1279)', async () => {
+  test('the start column spins up an agent working on the ticket, unattended (#1279)', async () => {
     sendStart.mockResolvedValue({ ok: true, agentId: 'r4' })
     const onAgentStarted = vi.fn()
     const onOpen = vi.fn()
@@ -81,10 +81,9 @@ describe('TicketsPanel (#697/#1144)', () => {
     expect(sendStart.mock.calls[0]?.[2]).toBe('prompt')
     expect(sendStart.mock.calls[0]?.[1]).toBe(workOnTicketPrompt('2026-07-20_do-the-thing.md'))
     expect(sendStart.mock.calls[0]?.[1]).toBe('Work on tickets/2026-07-20_do-the-thing.md. Do not start any other ticket.')
-    // Unattended like the AI Queue card's play button (#1279), with the ticket on the options so
-    // the agent's meta names what it implements (#1117) — the prompt is not the drain preset, so
-    // the daemon would not infer it.
-    expect(sendStart.mock.calls[0]?.[3]).toEqual({ unattended: true, ticket: 'tickets/2026-07-20_do-the-thing.md' })
+    // Unattended like the AI Queue card's play button (#1279). The prompt names the ticket; the
+    // framework records nothing else about it (#1774).
+    expect(sendStart.mock.calls[0]?.[3]).toEqual({ unattended: true })
     await waitFor(() => expect(onAgentStarted).toHaveBeenCalledWith(expect.any(String), 'r4'))
     // A sibling of the row's open button, like the plan cell: starting must not also navigate.
     expect(onOpen).not.toHaveBeenCalled()
diff --git a/packages/framework/dashboard/components/TicketsPanel.tsx b/packages/framework/dashboard/components/TicketsPanel.tsx
index 90307ff05..dbec6fd9b 100644
--- a/packages/framework/dashboard/components/TicketsPanel.tsx
+++ b/packages/framework/dashboard/components/TicketsPanel.tsx
@@ -354,12 +354,11 @@ export function TicketsPanel({
   // on, so the session stays a conversation you land in and steer rather than one that settles and
   // hands itself off. The reader reviews the result through the plan column's link.
   const startPlan = (file: string) => startSession(planTicketPrompt(file), 'The planning agent could not be started.')
-  // The start column (#855's play button, on the backlog): one agent on this one ticket is the
-  // same work the drain sweep starts, so it runs the same way — unattended (#1279), ending at
-  // settle with its armed handoff. `ticket` rides on the options so the agent's meta names what it
-  // implements (#1117) — the prompt is not the drain preset, so the daemon would not infer it.
+  // The start column (#855's play button, on the backlog): one agent on this one ticket, run the
+  // way the daemon runs the queued work — unattended (#1279), ending at settle with its armed
+  // handoff.
   const startWork = (file: string) =>
-    startSession(workOnTicketPrompt(file), 'The work agent could not be started.', { unattended: true, ticket: `tickets/${file}` })
+    startSession(workOnTicketPrompt(file), 'The work agent could not be started.', { unattended: true })
 
   if (tickets.length === 0 && hiddenByFilter > 0) {
     // Filtered to nothing, not genuinely empty (#1144/#1230): offering an import here would ask
diff --git a/packages/framework/package.json b/packages/framework/package.json
index 720cc1e9e..61320d813 100644
--- a/packages/framework/package.json
+++ b/packages/framework/package.json
@@ -27,7 +27,8 @@
     "node": ">=22.12.0"
   },
   "files": [
-    "dist"
+    "dist",
+    "skills"
   ],
   "bin": {
     "the-framework": "dist/bin.js"
diff --git a/packages/framework/prompts/presets/drain_queue.md b/packages/framework/prompts/presets/drain_queue.md
deleted file mode 100644
index 3c45510d1..000000000
--- a/packages/framework/prompts/presets/drain_queue.md
+++ /dev/null
@@ -1 +0,0 @@
-Use the `queue` skill: run `queue` and work on the FIRST open entry only. When the work is done and published, run `queue done "<the entry>"`. Do not start any other entry.
diff --git a/packages/framework/skills/work-queue/SKILL.md b/packages/framework/skills/work-queue/SKILL.md
new file mode 100644
index 000000000..3ef564e60
--- /dev/null
+++ b/packages/framework/skills/work-queue/SKILL.md
@@ -0,0 +1,7 @@
+---
+name: work-queue
+description: Work one queued task off the project's agent queue, unattended.
+disable-model-invocation: true
+---
+
+Get tickets to work on. Nobody will answer you: never ask, decide yourself. Take one queued task only. Commit your work on your branch and do not push; the run that started you publishes your branch when you stop. For you, committed counts as published: once the work is committed, close its ticket and mark the queue entry done. Before you stop, release any claim you still hold unless you closed the ticket. If nothing is queued, say so and stop.
diff --git a/packages/framework/src/agent-id.ts b/packages/framework/src/agent-id.ts
index f62ad4c11..6c23d86d0 100644
--- a/packages/framework/src/agent-id.ts
+++ b/packages/framework/src/agent-id.ts
@@ -19,3 +19,10 @@ export function startedAtFromAgentId(id: string): string | undefined {
   const match = /^(\d{4}-\d{2}-\d{2}T\d{2})-(\d{2})-(\d{2})-(\d{3})Z$/.exec(id)
   return match ? `${match[1]}:${match[2]}:${match[3]}.${match[4]}Z` : undefined
 }
+
+/**
+ * The environment variable a spawned agent reads its own id from. The daemon sets it on every
+ * agent it starts; a command the agent runs that needs to say who it is (a claim on a ticket) reads
+ * it, so a claim names the agent for its whole life rather than a branch that gets renamed.
+ */
+export const AGENT_ID_ENV = 'AGENT_ID'
diff --git a/packages/framework/src/agent-telemetry.ts b/packages/framework/src/agent-telemetry.ts
index 943393360..c24eded8a 100644
--- a/packages/framework/src/agent-telemetry.ts
+++ b/packages/framework/src/agent-telemetry.ts
@@ -7,7 +7,7 @@ import { UsageMeter } from './usage.js'
 // (`prompt-run.ts`) differ in what they *do* with the agent, but the accounting around
 // it is the same: name the session, follow the driver's event stream, total the usage,
 // and stop the agent when it has spent too much (#322) or the account's quota ran out
-// (#529). This lived twice, byte-identical, which is how the backlog loop ended up
+// (#529). This lived twice, byte-identical, which is how the build path ended up
 // without a copy of the sibling turn-signal parsing at all (#563).
 
 /** Inputs to {@link emitSessionStart}. */
diff --git a/packages/framework/src/agent.test.ts b/packages/framework/src/agent.test.ts
index 951b49731..2ae6ccf97 100644
--- a/packages/framework/src/agent.test.ts
+++ b/packages/framework/src/agent.test.ts
@@ -592,58 +592,7 @@ test('requestChoices resolves to the recommended option if the run aborts while
   assert.equal(picked, 'b') // fell back to the recommended option, not a hang
 })
 
-test('a fake run skips the backlog loop by default; the demo stays deterministic (#323)', async () => {
-  const events: FrameworkEvent[] = []
-  const result = await runAgent({
-    prompt: FAKE_INTENT,
-    driver: fakeDriver(),
-    cwd: '/tmp/ws',
-    onEvent: e => events.push(e),
-  })
-  assert.equal(result.todo, undefined)
-  assert.equal(events.some(e => e.kind === 'log' && /Queue/.test(e.message)), false)
-})
-
-test('runAgent runs the backlog loop after the build when opted in (#323)', async () => {
-  const { mkdtemp, realpath, rm, writeFile } = await import('node:fs/promises')
-  const { tmpdir } = await import('node:os')
-  const { join } = await import('node:path')
-  const { nodeGitRunner, withFileBranch, DATA_BRANCH } = await import('@gemstack/agent-data')
-  // The queue lives on the `agent-data` branch (#1582/#1748), so the fixture is a real repo.
-  const git = nodeGitRunner()
-  const cwd = await realpath(await mkdtemp(join(tmpdir(), 'framework-run-todo-')))
-  await git(['init', '-b', 'main'], cwd)
-  await git(['config', 'user.email', 't@t'], cwd)
-  await git(['config', 'user.name', 't'], cwd)
-  await writeFile(join(cwd, 'README.md'), '# t\n')
-  await git(['add', '-A'], cwd)
-  await git(['commit', '-m', 'init'], cwd)
-  await withFileBranch(cwd, DATA_BRANCH, 'seed', async (dir: string) => {
-    await writeFile(join(dir, 'TODO_AGENTS.md'), '- [ ] leftover task\n', 'utf8')
-  })
-  try {
-    const events: FrameworkEvent[] = []
-    // The fake script only answers; the loop's own removal (#1582) drains the entry —
-    // proving the wiring runs post-build with the agent's own session.
-    const result = await runAgent({
-      prompt: FAKE_INTENT,
-      driver: fakeDriver(),
-      cwd,
-      todoLoop: true,
-      onEvent: e => events.push(e),
-    })
-    assert.deepEqual(result.todo, { completed: 1, reason: 'empty' })
-    assert.ok(events.some(e => e.kind === 'log' && /Queue: 1 open item\(s\)/.test(e.message)))
-    // The loop runs before the agent's end event.
-    const endIndex = events.findIndex(e => e.kind === 'end')
-    const doneIndex = events.findIndex(e => e.kind === 'log' && /Queue done/.test(e.message))
-    assert.ok(doneIndex !== -1 && doneIndex < endIndex)
-  } finally {
-    await rm(cwd, { recursive: true, force: true })
-  }
-})
-
-// The await rounds shared by the direct prompt path and the backlog loop (#569). Both used
+// The await rounds shared by the direct prompt path and the build path (#569). Both used
 // to carry their own copy, which is how the turn-signal emission missed one of them (#563).
 
 /** A gate the fake agent can emit, in the wire shape `parseAwaitGate` reads. */
@@ -821,14 +770,11 @@ test('a hand-off run ends at the hand-off: no review passes, no backlog gate (#1
     const events: FrameworkEvent[] = []
     const asked: ChoiceRequest[] = []
     const { driver, prompts } = handsOffDriver()
-    const { todo } = await runAgent({
+    await runAgent({
       prompt: FAKE_INTENT,
       driver,
       location: 'web',
       cwd,
-      // Explicit, so this proves the hand-off outranks an opt-in rather than merely
-      // sharing a default with it.
-      todoLoop: true,
       requestChoice: async req => {
         asked.push(req)
         return { picked: req.options[0]!.id, by: 'user' }
@@ -839,9 +785,8 @@ test('a hand-off run ends at the hand-off: no review passes, no backlog gate (#1
     // The build prompt was the whole agent: no phase followed it, so nothing read the
     // hand-off note as a reply.
     assert.equal(prompts().length, 1)
-    // The backlog is still there and still unasked about: this machine has no standing to
-    // ask which item to start next when the work is somewhere it cannot see.
-    assert.equal(todo, undefined)
+    // Nothing was asked: this machine has no standing to ask anything when the work is
+    // somewhere it cannot see.
     assert.deepEqual(asked, [])
     assert.ok(!events.some(e => e.kind === 'choice'))
     assert.match(await readFile(join(cwd, 'TODO_AGENTS.md'), 'utf8'), /leftover task/)
@@ -956,22 +901,20 @@ test('a build opens with the intent itself, rendered through the user-prompt slo
   await writeFile(join(cwd, 'src/index.ts'), 'export {}')
   try {
     const { driver, prompts } = realNamedDriver([{ text: 'added the feature' }])
-    await runAgent({ prompt: 'add a search box', driver, cwd, todoLoop: false })
+    await runAgent({ prompt: 'add a search box', driver, cwd })
     assert.equal(prompts[0], 'add a search box')
   } finally {
     await rm(cwd, { recursive: true, force: true })
   }
 })
 
-test('a prompt session runs its text without build framing, and works no backlog (#353)', async () => {
+test('a prompt session runs its text without build framing (#353)', async () => {
   const cwd = await mkdtemp(join(tmpdir(), 'fw-promptkind-'))
-  await writeFile(join(cwd, 'TODO_AGENTS.md'), '- [ ] leftover task\n')
   try {
     const { driver, prompts } = realNamedDriver([{ text: 'reviewed it' }])
-    const { todo } = await runAgent({ prompt: 'review the auth flow', kind: 'prompt', driver, cwd, vanilla: true })
-    assert.equal(prompts.length, 1, 'one prompt, and no backlog turns after it')
+    await runAgent({ prompt: 'review the auth flow', kind: 'prompt', driver, cwd, vanilla: true })
+    assert.equal(prompts.length, 1, 'one prompt, and nothing after it')
     assert.equal(prompts[0], 'review the auth flow')
-    assert.equal(todo, undefined)
   } finally {
     await rm(cwd, { recursive: true, force: true })
   }
diff --git a/packages/framework/src/agent.ts b/packages/framework/src/agent.ts
index 56ff1ad50..24cc1fc4a 100644
--- a/packages/framework/src/agent.ts
+++ b/packages/framework/src/agent.ts
@@ -3,7 +3,6 @@ import { composeAgentSystem, renderSystemPrompt, type TfContext } from './system
 import { createAgentControls, emitSessionStart, endStopDetail } from './agent-telemetry.js'
 import { createTurnSignalEmitter } from './turn-gate.js'
 import { runAwaitRounds } from './await-gate.js'
-import { runTodoLoop, type TodoLoopResult } from './todo-loop.js'
 import { type ChoicePick, type ChoiceRequest, type FrameworkEvent } from './events.js'
 import type { AgentMessages } from './agent-messages.js'
 import { isHandsOff, type AgentLocation } from './agent-location.js'
@@ -32,7 +31,7 @@ export interface RunAgentOptions {
    * around; for `prompt`, the text sent as-is (modulo the system template's user slot).
    */
   prompt: string
-  /** Which opening prompt this session gets, and whether the backlog loop follows. Default `build`. */
+  /** Which opening prompt this session gets, and whether live chat follows. Default `build`. */
   kind?: AgentKind
   /**
    * Where this session's turns execute (#1050/#610). Default `local`. Only `web` hands the work
@@ -77,19 +76,12 @@ export interface RunAgentOptions {
    * without pausing. The CLI wires this to the dashboard's Accept button.
    */
   requestChoice?: (req: ChoiceRequest) => Promise<ChoicePick>
-  /**
-   * Work the agent's own `TODO_AGENTS.md` backlog after the opening exchange settles (#323), one
-   * gated entry per turn until it is empty. Default: on for a `build` session with a real driver,
-   * off otherwise (a `prompt` session is one prompt by definition, and the fake driver's scripted
-   * demo writes no backlog and must stay deterministic). Set explicitly to force either way.
-   */
-  todoLoop?: boolean
   /**
    * Continue a stopped session's conversation (#720/#1467): the captured agent session id to
    * `--resume`. When set, {@link prompt} is sent verbatim as a continuation message rather than
    * composed — the resumed transcript already carries the framing, which is exactly why #782
    * refused to bolt a resumed session onto a fresh build. Everything around the turn still runs:
-   * the gates, the backlog loop, live chat — the flow resumes, not just the conversation.
+   * the gates, live chat — the flow resumes, not just the conversation.
    */
   resumeSessionId?: string
   /**
@@ -115,8 +107,6 @@ export interface RunAgentResult {
   text: string
   /** Every event emitted, in order. */
   events: FrameworkEvent[]
-  /** How the backlog loop (#323) ended, when it ran. */
-  todo?: TodoLoopResult
 }
 
 /**
@@ -224,24 +214,8 @@ export async function runAgent(opts: RunAgentOptions): Promise<RunAgentResult> {
       throw agentSignal.reason instanceof Error ? agentSignal.reason : new Error('[framework] run stopped')
     }
 
-    // The backlog loop (#323): with the opening work settled, consume the agent's own TODO
-    // backlog one gated entry per turn until it is empty. The session signal (a Stop, an answer marked stop)
-    // #322) and the item cap bound it for unattended sessions.
-    let todo: TodoLoopResult | undefined
-    if (kind === 'build' && !handsOff && (opts.todoLoop ?? opts.driver.id !== 'fake')) {
-      todo = await runTodoLoop({
-        session,
-        cwd: opts.cwd,
-        emit,
-        requestChoice: opts.requestChoice,
-        signal: agentSignal,
-      })
-      // A plan declined mid-backlog with a stop-marked answer ends the session, the same as #217.
-      if (todo.sessionStopped) answerController.abort(new Error('[framework] stopped by your answer'))
-    }
-
-    // Live chat (#714) for a build, once its backlog is worked: a prompt session already took it
-    // inside the rounds above, where there is nothing to come between.
+    // Live chat (#714) for a build, once its opening work settles: a prompt session already took
+    // it inside the rounds above, where there is nothing to come between.
     if (opts.messages && kind === 'build' && !handsOff && !agentSignal.aborted) {
       const chat = await runChatAfterBacklog(session, opts, emit, emitTurnSignals, agentSignal)
       text = chat.text
@@ -262,7 +236,7 @@ export async function runAgent(opts: RunAgentOptions): Promise<RunAgentResult> {
       emit({ kind: 'log', message: 'Handed off: the rest of this session happens in its own session, which opens its own pull request.' })
     }
     emit({ kind: 'end', ok: true })
-    return { text, events, ...(todo ? { todo } : {}) }
+    return { text, events }
   } catch (err) {
     const { stopped, detail } = endStopDetail({ err, ...(opts.signal ? { signal: opts.signal } : {}), answerController })
     emit({ kind: 'end', ok: false, ...(stopped ? { stopped: true } : {}), detail })
diff --git a/packages/framework/src/auto-pm.test.ts b/packages/framework/src/auto-pm.test.ts
index dfa42de12..a744d487a 100644
--- a/packages/framework/src/auto-pm.test.ts
+++ b/packages/framework/src/auto-pm.test.ts
@@ -1,15 +1,17 @@
 import { strict as assert } from 'node:assert'
 import { test } from 'node:test'
+import { readFileSync } from 'node:fs'
+import { fileURLToPath } from 'node:url'
 import {
   autoPmDecision,
   quotaHeadroom,
   startAutoPm,
-  pinnedDrainJob,
   pinnedPlanJob,
   AUTO_PM_JOBS,
-  AUTO_PM_DRAIN_JOB,
+  AUTO_PM_WORK_JOB,
   AUTO_PM_MAINTENANCE_JOB,
   AUTO_PM_ROUTINES,
+  WORK_QUEUE_SKILL_NAME,
   type AutoPmDeps,
   type AutoPmJob,
   type AutoPmLoop,
@@ -34,10 +36,10 @@ function status(weekPercent: number): QuotaBoundaryStatus {
 }
 
 /** The happy inputs, so each test names only the condition it is about. */
-const IDLE = { enabled: true, backlogEmpty: true, activeAgents: 0, quota: status(1) } as const
+const IDLE = { enabled: true, activeAgents: 0, quota: status(1) } as const
 
-test('autoPmDecision starts when the queue is dry and the budget is barely touched (#685)', () => {
-  assert.deepEqual(autoPmDecision(IDLE), { start: true, mode: 'pm' })
+test('autoPmDecision starts when the budget is barely touched (#685)', () => {
+  assert.deepEqual(autoPmDecision(IDLE), { start: true })
 })
 
 test('autoPmDecision does nothing while the preference is off (#685)', () => {
@@ -55,7 +57,7 @@ test('autoPmDecision leaves a project at its concurrency cap alone (#685/#1204)'
 
 test('autoPmDecision tops a project up to its concurrency (#1204)', () => {
   // The point of the setting: one agent going is no longer a reason to stand down.
-  assert.deepEqual(autoPmDecision({ ...IDLE, activeAgents: 1, concurrency: 2 }), { start: true, mode: 'pm' })
+  assert.deepEqual(autoPmDecision({ ...IDLE, activeAgents: 1, concurrency: 2 }), { start: true })
   // At the cap it refuses, and the refusal names the cap so a raised setting does not read as a bug.
   const capped = autoPmDecision({ ...IDLE, activeAgents: 2, concurrency: 2 })
   assert.equal(capped.start, false)
@@ -71,31 +73,17 @@ test('autoPmDecision defaults to the shipped concurrency, and floors it at one (
   assert.equal(autoPmDecision({ ...IDLE, activeAgents: 1, concurrency: 0 }).start, false)
 })
 
-test('autoPmDecision drains the queue before filling it again (#855)', () => {
-  // It used to refuse here, on the reasoning that the backlog loop would drain it. That loop
-  // only runs inside an agent a human started, so unattended nothing ever emptied the queue.
-  assert.deepEqual(autoPmDecision({ ...IDLE, backlogEmpty: false }), { start: true, mode: 'drain' })
-})
-
-test('autoPmDecision refuses when the queue cannot be read at all (#855)', () => {
-  // Empty and non-empty both start something now, so "could not tell" has to be its own answer
-  // rather than falling back to either.
-  const decision = autoPmDecision({ ...IDLE, backlogEmpty: undefined })
-  assert.equal(decision.start, false)
-  assert.match(decision.start === false ? decision.reason : '', /queue could not be read/)
-})
-
 test('autoPmDecision holds off during the cooldown after a start (#685)', () => {
   const decision = autoPmDecision({ ...IDLE, sinceLastStartMs: 60_000 })
   assert.equal(decision.start, false)
   const later = autoPmDecision({ ...IDLE, sinceLastStartMs: 60 * 60_000 })
-  assert.deepEqual(later, { start: true, mode: 'pm' })
+  assert.deepEqual(later, { start: true })
 })
 
 test('autoPmDecision lets an asked-for pass through the cooldown (#1642)', () => {
-  // The cooldown paces the unattended sweep; a click is a person asking, so it does not apply.
+  // The cooldown paces the unattended rotation; a click is a person asking, so it does not apply.
   const decision = autoPmDecision({ ...IDLE, sinceLastStartMs: 60_000, onDemand: true })
-  assert.deepEqual(decision, { start: true, mode: 'pm' })
+  assert.deepEqual(decision, { start: true })
   // The concurrency cap is not waived with it: that is what stops a second click doubling up.
   const capped = autoPmDecision({ ...IDLE, sinceLastStartMs: 60_000, onDemand: true, activeAgents: 1, concurrency: 1 })
   assert.equal(capped.start, false)
@@ -146,7 +134,7 @@ test('a restarted daemon is no longer blind (#848/#879)', () => {
   // nothing to diff it against, and honestly reported 0 consumed while the account sat at 95%
   // of its week. The boundary reads the account's own absolute figure, which owes nothing to
   // how long this process has been up, so the restart is simply not a case any more.
-  const decision = autoPmDecision({ enabled: true, backlogEmpty: true, activeAgents: 0, quota: status(95) })
+  const decision = autoPmDecision({ enabled: true, activeAgents: 0, quota: status(95) })
   assert.equal(decision.start, false)
 })
 
@@ -155,9 +143,38 @@ const JOBS: readonly AutoPmJob[] = [
   { name: 'second', prompt: 'do the second thing', describe: 'doing the second thing' },
 ]
 
+/**
+ * A fake `agent-data` branch (#1774): a list of commits, each written by an agent or a person
+ * (a move) or by a daemon (not one). What the loop reads of it is the head and how many moves
+ * lie between two heads — the two things the daemon reads off the real branch with git.
+ */
+function fakeBranch() {
+  const commits: { sha: string; foreign: boolean }[] = [{ sha: 'h0', foreign: true }]
+  const at = (sha: string) => commits.findIndex(c => c.sha === sha)
+  return {
+    get head(): string {
+      return commits[commits.length - 1]!.sha
+    },
+    /** Someone queued an entry, an agent claimed or closed a ticket. */
+    move(): string {
+      commits.push({ sha: `h${commits.length}`, foreign: true })
+      return this.head
+    },
+    /** The daemon recorded a run, took a lock, minted a claim. */
+    record(): string {
+      commits.push({ sha: `h${commits.length}`, foreign: false })
+      return this.head
+    },
+    foreignBetween(from: string, to: string): number {
+      return commits.slice(at(from) + 1, at(to) + 1).filter(c => c.foreign).length
+    },
+  }
+}
+
 /** A loop wired to one idle project, with every reading overridable per test. */
 function harness(overrides: Partial<AutoPmDeps> = {}) {
   const project: AutoPmProject = { id: 'p1', path: '/repo' }
+  const branch = fakeBranch()
   const started: string[] = []
   const ran: string[] = []
   const logs: string[] = []
@@ -165,7 +182,8 @@ function harness(overrides: Partial<AutoPmDeps> = {}) {
     projects: async () => [project],
     jobs: JOBS,
     enabled: async () => true,
-    queue: async () => [],
+    dataHead: async () => branch.head,
+    foreignCommits: async (_p, from, to) => branch.foreignBetween(from, to),
     // Pinned at one so every test written before #1204 keeps asserting against the behaviour it
     // was written for; the fan-out tests set it explicitly.
     concurrency: async () => 1,
@@ -176,19 +194,22 @@ function harness(overrides: Partial<AutoPmDeps> = {}) {
       ran.push(job.name)
       return `run-${ran.length}`
     },
-    promote: async () => ({ settled: true, promoted: false }),
+    settled: async () => ({ settled: true }),
     log: message => logs.push(message),
     now: () => T0,
     ...overrides,
   }
-  return { loop: startAutoPm(deps), started, ran, logs }
+  return { loop: startAutoPm(deps), branch, started, ran, logs }
 }
 
-test('startAutoPm starts a run for an idle project (#685)', async () => {
-  const { loop, started } = harness()
+test('startAutoPm gives the rotation its start-up turn on an idle project (#685/#1774)', async () => {
+  // The first look remembers where the branch stands; the rotation's turn is what a daemon
+  // started with the setting already on has always taken.
+  const { loop, started, ran } = harness()
   await loop.tick()
   loop.stop()
   assert.deepEqual(started, ['p1'])
+  assert.deepEqual(ran, ['first'])
 })
 
 test('startAutoPm starts nothing while the preference is off (#685)', async () => {
@@ -218,7 +239,7 @@ test('on demand skips the master switch and the cooldown: every other stand-down
 })
 
 test('a Run now right after a run starts anyway: the cooldown is for work nobody asked for (#1642)', async () => {
-  // Same two ticks as the #685 double-up test above, the second one a click. The sweep's own
+  // Same two ticks as the #685 double-up test below, the second one a click. The sweep's own
   // cooldown held the button for half an hour after any run, and the card said so in small
   // text under the fold — a button that did nothing, to anyone who clicked and looked away.
   const { loop, started } = harness()
@@ -228,8 +249,8 @@ test('a Run now right after a run starts anyway: the cooldown is for work nobody
   assert.deepEqual(started, ['p1', 'p1'])
 })
 
-test('startAutoPm does not start a second run for the same project (#685)', async () => {
-  // The cooldown is what stops a tick that lands before the spawn registers from doubling up.
+test('startAutoPm does not start a second rotation run for the same project (#685)', async () => {
+  // The cooldown is what paces the rotation on an idle project.
   const { loop, started } = harness()
   await loop.tick()
   await loop.tick()
@@ -252,14 +273,6 @@ test('startAutoPm re-arms when the start was refused (#685)', async () => {
   assert.equal(attempts, 2)
 })
 
-test('startAutoPm survives a project whose backlog cannot be read (#685)', async () => {
-  // An unreadable queue is not an empty one: it must not trigger an agent, nor throw the sweep.
-  const { loop, started } = harness({ queue: async () => Promise.reject(new Error('nope')) })
-  await loop.tick()
-  loop.stop()
-  assert.deepEqual(started, [])
-})
-
 test('AUTO_PM_JOBS imports, triages, then plans (#773/#891/#892/#1334)', () => {
   // Importing leads: it is the only job that can add a ticket none of the others have seen, so a
   // rotation without it eventually triages and plans a set that nothing ever refills (#1334).
@@ -275,7 +288,7 @@ test('AUTO_PM_JOBS imports, triages, then plans (#773/#891/#892/#1334)', () => {
 
 test('the rotation is the schedule the triage presets asked for (#891/#892)', () => {
   // #891/#892 both say "with a cron job regularly firing this preset". The rotation already
-  // fires on every idle tick where the queue is dry, so no separate scheduler exists — unlike
+  // fires after every run that found nothing queued, so no separate scheduler exists — unlike
   // the maintenance sweep (#882), which needs a calendar key because it would never come due.
   const names = AUTO_PM_JOBS.map(j => j.name)
   assert.ok(names.includes('triage-quick'), 'quick triage must be in the rotation')
@@ -288,7 +301,8 @@ test('the rotation is the schedule the triage presets asked for (#891/#892)', ()
 })
 
 test('startAutoPm walks the job cycle across idle moments (#773)', async () => {
-  // The cooldown normally spaces these out; zero it so one test can see the whole rotation.
+  // The cooldown normally spaces these out; zero it so one test can see the whole rotation. Each
+  // run settles without moving the branch, which is what hands the rotation its next turn.
   const { loop, ran } = harness({ cooldownMs: 0 })
   await loop.tick()
   await loop.tick()
@@ -316,32 +330,13 @@ test('startAutoPm retries the same job when the start was refused (#773)', async
   assert.deepEqual(ran, ['first'])
 })
 
-test('a promoted queue ends the tick, so the sweep re-reads it next time (#852)', async () => {
-  // The agent's queue lands in the checkout only now, so the emptiness check below it is stale.
-  // Deciding on that read is what made auto PM re-derive the same entries every cooldown.
-  const promoted: string[] = []
-  const { loop, ran } = harness({
-    cooldownMs: 0,
-    promote: async (_p, { agentId }) => {
-      promoted.push(agentId)
-      return { settled: true, promoted: true }
-    },
-  })
-  await loop.tick() // starts run-1
-  await loop.tick() // lands run-1's queue and stops there
-  assert.deepEqual(promoted, ['run-1'])
-  assert.deepEqual(ran, ['first'])
-})
-
-test('a finished run that wrote no queue stops being retried (#852)', async () => {
-  // Settled without promoting: nothing landed, but the agent is over, so the sweep carries on
-  // rather than asking about it forever.
+test('a finished run is asked about exactly once (#852)', async () => {
   const asked: string[] = []
   const { loop, ran } = harness({
     cooldownMs: 0,
-    promote: async (_p, { agentId }) => {
+    settled: async (_p, { agentId }) => {
       asked.push(agentId)
-      return { settled: true, promoted: false }
+      return { settled: true }
     },
   })
   await loop.tick()
@@ -354,74 +349,221 @@ test('a finished run that wrote no queue stops being retried (#852)', async () =
   assert.deepEqual(ran, ['first', 'second', 'first'])
 })
 
-test('a run still going is left pending, and the sweep starts nothing new (#852)', async () => {
-  const { loop, ran } = harness({ cooldownMs: 0, promote: async () => ({ settled: false, promoted: false }) })
+test('a run still going is left pending, and the rotation waits for it (#852/#1774)', async () => {
+  const { loop, ran } = harness({ cooldownMs: 0, settled: async () => ({ settled: false }) })
   await loop.tick() // starts run-1
-  await loop.tick() // run-1 unsettled, nothing landed -> falls through to the decision
+  await loop.tick() // run-1 unsettled: its ending is what earns the next turn, so nothing starts
+  await loop.tick()
   loop.stop()
-  // The second tick reaches the decision and starts the next job: the cooldown is what normally
-  // spaces these, and it is zeroed here. What matters is run-1 is still tracked, not dropped.
-  assert.ok(ran.length >= 1)
+  assert.deepEqual(ran, ['first'])
+  assert.equal(loop.report().outcomes[0]?.message, 'nothing moved on the agent-data branch since the last run')
 })
 
-test('startAutoPm drains a standing queue, then goes back to filling it (#855)', async () => {
-  // The deadlock this fixes: a PM job filled the queue, nothing unattended drained it, and every
-  // later tick refused because it was no longer empty. The cycle has to come back round.
-  let open = 1
-  const ran: string[] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => Array.from({ length: open }, (_, i) => `entry ${i + 1}`),
-    // A drain agent works one entry off; a PM agent puts one there.
-    start: async (_project, job) => {
-      ran.push(job.name)
-      open += job.name === AUTO_PM_DRAIN_JOB.name ? -1 : 1
-      return `run-${ran.length}`
-    },
-  })
-  await loop.tick() // an entry is standing -> work it off
-  await loop.tick() // dry now -> refill
-  await loop.tick() // standing again -> work it off
+// #1774: the trigger. The daemon reads no queue; it reads the head of the `agent-data` branch and
+// starts the queued work when the branch moved by a commit no daemon wrote.
+
+test('the first look remembers the head and starts nothing on the queued work (#1774)', async () => {
+  // A daemon that just started knows nothing about what moved while it was down; the heartbeat
+  // is the belt for that. With no rotation wired, the first look starts nothing at all.
+  const { loop, ran } = harness({ jobs: [] })
+  await loop.tick()
   loop.stop()
-  assert.deepEqual(ran, [AUTO_PM_DRAIN_JOB.name, 'first', AUTO_PM_DRAIN_JOB.name])
+  assert.deepEqual(ran, [])
+  assert.equal(loop.report().outcomes[0]?.message, 'there is no job to run')
 })
 
-test('draining does not advance the PM rotation (#855)', async () => {
-  // The rotation is about what to make when there is nothing to do. A queue worked off over
-  // several ticks must not push it forward once per entry and skip a job.
-  let open = 2
-  const ran: string[] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => Array.from({ length: open }, (_, i) => `entry ${i + 1}`),
-    start: async (_project, job) => {
+test('a commit no daemon wrote starts the queued work, once (#1774)', async () => {
+  const { loop, branch, ran } = harness({ jobs: [] })
+  await loop.tick()
+  branch.move()
+  await loop.tick()
+  assert.deepEqual(ran, [AUTO_PM_WORK_JOB.name])
+  // The move is spent: the next look, with the run settled and nothing new, starts nothing.
+  await loop.tick()
+  loop.stop()
+  assert.deepEqual(ran, [AUTO_PM_WORK_JOB.name])
+})
+
+test("a commit the daemon wrote is not a move: a run's record must not start the next run (#1774)", async () => {
+  const { loop, branch, ran } = harness({ jobs: [] })
+  await loop.tick()
+  branch.record()
+  await loop.tick()
+  branch.record()
+  await loop.tick()
+  loop.stop()
+  assert.deepEqual(ran, [])
+})
+
+test('the chain: the run\'s own commits start the next run as it ends, and an empty run stops it (#1774)', async () => {
+  // Three queued tasks, one agent at a time. Each run claims and closes a ticket — commits no
+  // daemon wrote — so the branch has moved by the time the run ends, and the daemon fires again.
+  // The fourth run finds nothing and writes nothing, and the chain ends there.
+  let running: string[] = []
+  let ended = new Set<string>()
+  const { loop, branch, ran } = harness({
+    jobs: [],
+    activeAgents: () => running,
+    settled: async (_p, { agentId }) => ({ settled: ended.has(agentId) }),
+    start: async (_p, job) => {
       ran.push(job.name)
-      open += job.name === AUTO_PM_DRAIN_JOB.name ? -1 : 1
+      running = [`run-${ran.length} (pid 1)`]
       return `run-${ran.length}`
     },
   })
+  await loop.tick() // remembers the head
+  branch.move() // someone queued three tasks
+  await loop.tick() // run-1 starts
+  assert.equal(ran.length, 1)
+  branch.move() // run-1 claims its ticket
+  await loop.tick() // the cap holds: one at a time
+  assert.equal(ran.length, 1)
+  assert.match(loop.report().outcomes[0]?.message ?? '', /already going/)
+  branch.move() // run-1 closes the ticket and marks the entry done
+  running = []
+  ended = new Set(['run-1'])
+  await loop.tick() // run-1 settled, the branch moved meanwhile: run-2 starts
+  assert.equal(ran.length, 2)
+  branch.move()
+  running = []
+  ended = new Set(['run-1', 'run-2'])
+  await loop.tick() // run-3
+  assert.equal(ran.length, 3)
+  branch.move()
+  running = []
+  ended = new Set(['run-1', 'run-2', 'run-3'])
+  await loop.tick() // run-4: finds nothing queued
+  assert.equal(ran.length, 4)
+  running = []
+  ended = new Set(['run-1', 'run-2', 'run-3', 'run-4'])
+  await loop.tick() // run-4 settled and nothing moved: the chain stops
+  await loop.tick()
+  loop.stop()
+  assert.equal(ran.length, 4)
+  assert.equal(loop.report().outcomes[0]?.message, 'there is no job to run')
+})
+
+test('after a run that moved nothing the rotation gets the turn; a move takes it back (#1774)', async () => {
+  const { loop, branch, ran } = harness({ cooldownMs: 0 })
+  await loop.tick() // the start-up turn: 'first'
+  await loop.tick() // 'first' settled without a move: the queue wants refilling, 'second'
+  branch.move() // 'second' queued something
+  await loop.tick() // the queued work
+  await loop.tick() // it settled without a move: the rotation resumes where it left off
+  loop.stop()
+  assert.deepEqual(ran, ['first', 'second', AUTO_PM_WORK_JOB.name, 'first'])
+})
+
+test('a move is not paced by the cooldown; the rotation is (#1774)', async () => {
+  let now = T0
+  const { loop, branch, ran } = harness({ now: () => now, concurrency: async () => 2 })
+  await loop.tick() // the rotation's start-up turn arms the cooldown
+  now += 60_000
+  branch.move()
+  await loop.tick() // a minute later: the queued work starts regardless
+  assert.deepEqual(ran, ['first', AUTO_PM_WORK_JOB.name])
+  now += 60_000
+  await loop.tick() // both settled without a move: the rotation is owed a turn, and waits
+  assert.deepEqual(ran, ['first', AUTO_PM_WORK_JOB.name])
+  assert.equal(loop.report().outcomes[0]?.message, 'a run was started for this project a moment ago')
+  now += 31 * 60_000
+  await loop.tick()
+  loop.stop()
+  assert.deepEqual(ran, ['first', AUTO_PM_WORK_JOB.name, 'second'])
+})
+
+test('the heartbeat starts the queued work once a day when nothing moved (#1774)', async () => {
+  let now = T0
+  const { loop, ran } = harness({ jobs: [], heartbeatMs: 1_000, now: () => now })
+  await loop.tick()
+  now += 500
+  await loop.tick()
+  assert.deepEqual(ran, [])
+  now += 500
   await loop.tick()
+  assert.deepEqual(ran, [AUTO_PM_WORK_JOB.name])
+  now += 500
   await loop.tick()
-  await loop.tick() // dry -> the rotation resumes at its first job, not its second
   loop.stop()
-  assert.deepEqual(ran, [AUTO_PM_DRAIN_JOB.name, AUTO_PM_DRAIN_JOB.name, 'first'])
+  assert.deepEqual(ran, [AUTO_PM_WORK_JOB.name], 'the next heartbeat is a day after the last start')
 })
 
-test('an unreadable queue starts nothing at all (#855)', async () => {
-  const ran: string[] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => {
-      throw new Error('no such file')
-    },
-    start: async (_project, job) => {
-      ran.push(job.name)
-      return 'run-1'
-    },
-  })
+test("the queued work's Run now starts an agent without a move, or says why not (#1204/#1774)", async () => {
+  const { loop, ran } = harness({ jobs: [] })
+  await loop.tick()
+  await loop.tick({ onDemand: true, only: 'work' })
+  assert.deepEqual(ran, [AUTO_PM_WORK_JOB.name])
+
+  const off = harness({ jobs: [], optedOut: async () => [AUTO_PM_WORK_JOB.name] })
+  await off.loop.tick({ onDemand: true, only: 'work' })
+  off.loop.stop()
+  loop.stop()
+  assert.deepEqual(off.ran, [])
+  assert.equal(off.loop.report().outcomes[0]?.message, 'the routine that works the queue is switched off')
+})
+
+test('a plain Run now starts the queued work when the branch moved, else the rotation (#1210/#1774)', async () => {
+  const { loop, branch, ran } = harness({ cooldownMs: 0 })
+  await loop.tick()
+  branch.move()
+  await loop.tick({ onDemand: true })
+  await loop.tick({ onDemand: true })
+  loop.stop()
+  assert.deepEqual(ran, ['first', AUTO_PM_WORK_JOB.name, 'second'])
+})
+
+test('a move while the queued-work routine is switched off is the rotation\'s turn (#1209/#1432/#1774)', async () => {
+  // #1209 means "do not work the queue", and the rotation does not work it: triage and planning
+  // put entries on it. Standing down would make every inventing routine unreachable.
+  const { loop, branch, ran, logs } = harness({ cooldownMs: 0, optedOut: async () => [AUTO_PM_WORK_JOB.name] })
+  await loop.tick()
+  branch.move()
+  await loop.tick()
+  loop.stop()
+  assert.deepEqual(ran, ['first', 'second'])
+  assert.ok(!logs.some(line => line.includes(AUTO_PM_WORK_JOB.prompt)), 'and nothing worked the queue')
+})
+
+test('a branch that cannot be read stands the project down (#1774)', async () => {
+  const { loop, ran } = harness({ dataHead: async () => undefined })
   await loop.tick()
   loop.stop()
   assert.deepEqual(ran, [])
+  assert.match(loop.report().outcomes[0]?.message ?? '', /agent-data branch could not be read/)
+})
+
+test('a stand-down is logged when it is news, not once a minute (#1774)', async () => {
+  const { loop, logs } = harness({ jobs: [] })
+  await loop.tick()
+  await loop.tick()
+  await loop.tick()
+  loop.stop()
+  assert.deepEqual(logs, ['[framework] auto PM: standing down for /repo — there is no job to run'])
+  // The report says it every time: the panel reads the last sweep, not the log.
+  assert.equal(loop.report().outcomes[0]?.message, 'there is no job to run')
+})
+
+test('AUTO_PM_WORK_JOB fires the routine skill by its slash command, and lands its own PRs (#1216/#1774)', () => {
+  // The prompt is the skill's name as a slash command; the agent's harness expands it. The skill
+  // file ships with this package, and only a person or the daemon may invoke it.
+  assert.equal(AUTO_PM_WORK_JOB.prompt, `/${WORK_QUEUE_SKILL_NAME}`)
+  assert.equal(AUTO_PM_WORK_JOB.works, true)
+  const skill = readFileSync(fileURLToPath(new URL(`../skills/${WORK_QUEUE_SKILL_NAME}/SKILL.md`, import.meta.url)), 'utf8')
+  assert.match(skill, new RegExp(`^---\\nname: ${WORK_QUEUE_SKILL_NAME}\\n`))
+  assert.match(skill, /\ndisable-model-invocation: true\n/)
+  // What the agent is told: one task, commit but do not push, committed counts as published,
+  // release what it holds, say so and stop when nothing is queued.
+  assert.match(skill, /Take one queued task only/)
+  assert.match(skill, /do not push/)
+  assert.match(skill, /committed counts as published/)
+  assert.match(skill, /If nothing is queued, say so and stop/)
+  // The queued work implements entries whose triage a human could have vetoed, so its review
+  // happened before the agent. Every other job writes tickets/plans and has nothing to merge.
+  assert.equal(AUTO_PM_WORK_JOB.autoMerge, true)
+  for (const job of [...AUTO_PM_JOBS, AUTO_PM_MAINTENANCE_JOB]) {
+    assert.equal(job.autoMerge, undefined, `${job.name} must not auto-merge`)
+    assert.notEqual(job.works, true, `${job.name} must not claim to work the queue`)
+  }
 })
 
 test('AUTO_PM_MAINTENANCE_JOB fires the [Maintenance] preset over the whole codebase (#882)', () => {
@@ -480,17 +622,19 @@ test('a sweep is stamped only when the run actually started (#882)', async () =>
   assert.deepEqual(stamped, [])
 })
 
-test('a queue with work in it is drained rather than swept (#882)', async () => {
-  // A repo with entries waiting has plenty to do; sweeping would only pile more on.
-  const { loop, ran } = harness({ cooldownMs: 0, queue: async () => ['entry a'], maintenanceDue: async () => true })
+test('a branch that moved is worked rather than swept (#882/#1774)', async () => {
+  // A project with queued work has plenty to do; sweeping would only pile more on.
+  const { loop, branch, ran } = harness({ cooldownMs: 0, maintenanceDue: async () => true, settled: async () => ({ settled: false }) })
+  await loop.tick() // the start-up turn goes to the due sweep
+  branch.move()
   await loop.tick()
   loop.stop()
-  assert.deepEqual(ran, [AUTO_PM_DRAIN_JOB.name])
+  assert.deepEqual(ran, [AUTO_PM_MAINTENANCE_JOB.name, AUTO_PM_WORK_JOB.name])
 })
 
 test('a sweep stopped mid-flight starts nothing (#983)', async () => {
   // stop() used to only clear the timer, so a tick already inside its per-project loop kept
-  // awaiting (git calls, the queue read) and then spawned an agent anyway. By then the daemon has
+  // awaiting (git calls, the branch read) and then spawned an agent anyway. By then the daemon has
   // quiesced and cleared its live-agent map, so that agent is tracked by nobody: an orphan holding a
   // worktree, and quota spent on an agent nobody will ever see.
   const both: AutoPmProject[] = [
@@ -501,9 +645,9 @@ test('a sweep stopped mid-flight starts nothing (#983)', async () => {
   const h = harness({
     projects: async () => both,
     // The daemon shutting down while the sweep sits between its readings and the spawn.
-    queue: async () => {
+    quota: async () => {
       loop.stop()
-      return []
+      return status(1)
     },
   })
   loop = h.loop
@@ -584,14 +728,6 @@ test('an out-of-band tick does not skew the next sweep (#1161)', async () => {
   assert.equal(loop.report().nextSweepAt, T0 + 60_000)
 })
 
-test('only the draining job says it works the queue rather than filling it (#1117)', () => {
-  // The marker is what tells the daemon which start can name a ticket. A rotation job that claimed
-  // it would name the entry it is about to *write*, which is not what it is doing.
-  assert.equal(AUTO_PM_DRAIN_JOB.drains, true)
-  for (const job of AUTO_PM_JOBS) assert.notEqual(job.drains, true, `${job.name} must not claim to drain`)
-  assert.notEqual(AUTO_PM_MAINTENANCE_JOB.drains, true)
-})
-
 /** The catalog key whose preset a routine fires, found by that preset's run-kind name. */
 function presetKey(name: string): PresetKey {
   const key = (Object.keys(presets) as PresetKey[]).find(k => presets[k].name === name)
@@ -602,17 +738,20 @@ function presetKey(name: string): PresetKey {
 test('AUTO_PM_ROUTINES is every job the sweep can fire, once each (#1159)', () => {
   // The dashboard lists this rather than a copy of it, so a job added to the rotation reaches the
   // screen without anyone remembering to put it there too.
-  const expected = [AUTO_PM_DRAIN_JOB, ...AUTO_PM_JOBS, AUTO_PM_MAINTENANCE_JOB]
+  const expected = [AUTO_PM_WORK_JOB, ...AUTO_PM_JOBS, AUTO_PM_MAINTENANCE_JOB]
   assert.deepEqual(AUTO_PM_ROUTINES.map(j => j.name), expected.map(j => j.name))
   assert.equal(new Set(AUTO_PM_ROUTINES.map(j => j.name)).size, AUTO_PM_ROUTINES.length)
-  // Draining leads: it is what the sweep does whenever there is queued work, and the only routine
-  // that turns a queue entry into commits.
-  assert.equal(AUTO_PM_ROUTINES[0]?.name, AUTO_PM_DRAIN_JOB.name)
+  // The queued work leads: it is what the sweep does whenever the branch moved, and the only
+  // routine that turns a queue entry into commits.
+  assert.equal(AUTO_PM_ROUTINES[0]?.name, AUTO_PM_WORK_JOB.name)
 })
 
-test('every routine carries its preset label and a rendered prompt, so a list of them is runnable (#1159)', () => {
-  for (const job of AUTO_PM_ROUTINES) {
+test('every routine carries a label and a prompt, so a list of them is runnable (#1159)', () => {
+  for (const job of [...AUTO_PM_JOBS, AUTO_PM_MAINTENANCE_JOB]) {
     assert.equal(job.label, presets[presetKey(job.name)].label, `${job.name} must be labelled by its preset`)
+  }
+  for (const job of AUTO_PM_ROUTINES) {
+    assert.ok(job.label, `${job.name} must carry a label`)
     assert.ok(job.prompt.trim().length > 0, `${job.name} must carry a prompt`)
     // The prompt travels to the browser and is started verbatim, so nothing may be left unrendered.
     assert.doesNotMatch(job.prompt, /\$\{\{/, `${job.name} must ship a rendered prompt`)
@@ -623,7 +762,7 @@ test('only the maintenance sweep describes itself; the rest are just their label
   // "Maintenance" names the preset rather than the work, so its row and log line keep the
   // sentence; the other routines' labels already say what they do.
   assert.equal(AUTO_PM_MAINTENANCE_JOB.describe, 'sweeping the codebase for maintenance work')
-  for (const job of [AUTO_PM_DRAIN_JOB, ...AUTO_PM_JOBS]) {
+  for (const job of [AUTO_PM_WORK_JOB, ...AUTO_PM_JOBS]) {
     assert.equal(job.describe, undefined, `${job.name} must not say its label twice`)
   }
 })
@@ -638,54 +777,21 @@ test('a routine the user unticked is left out of the rotation (#1209)', async ()
   assert.deepEqual(ran, ['second', 'second'])
 })
 
-test('an unticked drain routine falls through to the rotation rather than standing down (#1432)', async () => {
-  // #1209 means "do not *work* the queue", and the rotation does not work it: triage and planning
-  // put entries *on* it. Standing down here read that switch as "do nothing at all", which made
-  // every inventing routine unreachable for as long as the queue had anything on it — and since
-  // the queue is auto-populated, that is most of the time.
-  const { loop, ran, logs } = harness({
-    cooldownMs: 0,
-    queue: async () => ['entry a'],
-    optedOut: async () => [AUTO_PM_DRAIN_JOB.name],
-  })
-  await loop.tick()
-  await loop.tick()
-  loop.stop()
-  // The rotation ran, and advanced — a fall-through tick is a rotation turn like any other.
-  assert.deepEqual(ran, ['first', 'second'])
-  assert.ok(!logs.some(line => line.includes('draining')), 'and nothing worked the queue')
-})
-
-test('a drain-only sweep still stands down when the drain routine is off (#1204/#1432)', async () => {
-  // The fall-through above is for the scheduled sweep. This click asked for the queue by name, so
-  // borrowing it for a rotation job is exactly what drain-only exists to prevent.
-  const { loop, ran, logs } = harness({
-    cooldownMs: 0,
-    queue: async () => ['entry a'],
-    optedOut: async () => [AUTO_PM_DRAIN_JOB.name],
-  })
-  await loop.tick({ onDemand: true, only: 'drain' })
-  loop.stop()
-  assert.deepEqual(ran, [])
-  assert.equal(loop.report().outcomes[0]?.message, 'the queue has work waiting and its routine is switched off')
-  assert.ok(logs.some(line => line.includes('its routine is switched off')))
-})
-
-test('the maintenance sweep stays out while entries are waiting, fall-through or not (#882/#1432)', async () => {
-  // The fall-through makes the tick a rotation turn, but the sweep asks a different question —
-  // is the queue empty — and the answer is still no.
-  const stamped: string[] = []
-  const { loop, ran } = harness({
+test('the maintenance sweep stays out while the branch has moved, work routine on or off (#882/#1432/#1774)', async () => {
+  let due = true
+  const { loop, branch, ran } = harness({
     cooldownMs: 0,
-    queue: async () => ['entry a'],
-    optedOut: async () => [AUTO_PM_DRAIN_JOB.name],
-    maintenanceDue: async () => true,
-    recordMaintenance: async project => void stamped.push(project.id),
+    optedOut: async () => [AUTO_PM_WORK_JOB.name],
+    maintenanceDue: async () => due,
+    recordMaintenance: async () => {
+      due = false
+    },
   })
-  await loop.tick()
+  await loop.tick() // the start-up turn: a due sweep
+  branch.move()
+  await loop.tick() // a move with the work routine off is the rotation's turn
   loop.stop()
-  assert.deepEqual(stamped, [])
-  assert.deepEqual(ran, ['first'])
+  assert.deepEqual(ran, [AUTO_PM_MAINTENANCE_JOB.name, 'first'])
 })
 
 test('an unticked maintenance routine leaves its calendar alone (#1209)', async () => {
@@ -730,34 +836,6 @@ test('an unreadable opt-out list means none, never all (#1209)', async () => {
   assert.deepEqual(ran, ['first'])
 })
 
-// #1204: the routine keeps several agents going at once. Only draining fans out — it is the one
-// routine that takes work *off* the queue, one entry per agent, so a batch of them does disjoint
-// work and lands disjoint edits.
-
-test('a standing queue fans out to the concurrency in one tick, one entry per agent (#1204)', async () => {
-  // The demo the issue asks for: one sweep, several sessions, each on its own entry. Fanning out
-  // over successive ticks instead would take a cooldown per agent.
-  const prompts: string[] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    concurrency: async () => 3,
-    queue: async () => ['entry a', 'entry b', 'entry c', 'entry d'],
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick()
-  loop.stop()
-  assert.equal(prompts.length, 3, 'the batch stops at the concurrency, not at the queue length')
-  // Pinned, and pinned to *different* entries: unpinned they would all fork the same checkout and
-  // read the same first entry.
-  assert.match(prompts[0]!, /entry a/)
-  assert.match(prompts[1]!, /entry b/)
-  assert.match(prompts[2]!, /entry c/)
-  assert.equal(new Set(prompts).size, 3)
-})
-
 // #1646: the live-agent reading names what it counted. The one time it came out one too high, the
 // Agents panel showed nothing running and the number could not be questioned — the run holding the
 // slot was a process that had outlived its finished run, visible only to the daemon's own table.
@@ -774,484 +852,143 @@ test('a cap stand-down names the runs holding the slots (#1646)', () => {
   assert.equal(unnamed.start === false ? unnamed.reason : '', '1 run is already going')
 })
 
+// #1327: [Plan tickets] fans out — the one rotation job that writes per-ticket sibling files
+// rather than the shared queue document, so agents pinned one ticket each do disjoint work. The
+// PENDING locks are what make the batch safe beyond this process's memory, so no locks means no
+// fan-out.
+
+const PLAN_JOB: AutoPmJob = { name: 'plan', prompt: 'Plan every ticket that has no plan yet.', fansOut: true }
+
+test('a fansOut job fans out to the concurrency, one locked ticket per agent (#1327)', async () => {
+  const prompts: string[] = []
+  const lockCalls: PlanAssignment[][] = []
+  const { loop } = harness({
+    jobs: [PLAN_JOB],
+    cooldownMs: 0,
+    concurrency: async () => 3,
+    planCandidates: async () => ['a.md', 'b.md', 'c.md', 'd.md'],
+    lockPlans: async (_p, assignments) => {
+      lockCalls.push([...assignments])
+      return assignments
+    },
+    start: async (_p, job) => {
+      prompts.push(job.prompt)
+      return `run-${prompts.length}`
+    },
+  })
+  await loop.tick()
+  loop.stop()
+  assert.equal(prompts.length, 3, 'the batch stops at the concurrency, not at the candidate count')
+  // Pinned to *different* tickets, in the candidates' own most-important-first order.
+  assert.match(prompts[0]!, /tickets\/a\.md/)
+  assert.match(prompts[1]!, /tickets\/b\.md/)
+  assert.match(prompts[2]!, /tickets\/c\.md/)
+  // The whole batch was locked in one call, before any agent started, and each agent's prompt
+  // names the id its own lock carries.
+  assert.equal(lockCalls.length, 1)
+  assert.equal(lockCalls[0]!.length, 3)
+  assert.equal(new Set(lockCalls[0]!.map(a => a.agentId)).size, 3)
+  // The ids are minted a millisecond apart from the sweep's clock (#1748), so a batch stays distinct.
+  assert.match(lockCalls[0]![0]!.agentId, /^2026-07-20T12-00-00-000Z$/)
+  assert.match(prompts[0]!, /`tickets show a\.md` names you as its holder/)
+})
+
 test('a fan-out that came out short says what it was short by, by name (#1646)', async () => {
   // Three allowed, one slot held by a run the sweep did not start: two go out, and the card says
   // alongside whom, so a held slot nobody can see on the dashboard is named rather than silent.
   const { loop, ran } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
     concurrency: async () => 3,
     activeAgents: () => ['2026-08-22T22-06-41-065Z (pid 4242)'],
-    queue: async () => ['entry a', 'entry b', 'entry c'],
+    planCandidates: async () => ['a.md', 'b.md', 'c.md'],
+    lockPlans: async (_p, assignments) => assignments,
   })
   await loop.tick()
   loop.stop()
   assert.equal(ran.length, 2, 'the batch is the cap minus the held slot')
   assert.equal(
     loop.report().outcomes[0]?.message,
-    'started 2 agents alongside 1 already going (2026-08-22T22-06-41-065Z (pid 4242)): ' +
-      'draining the queue entry "entry a"; draining the queue entry "entry b"',
+    'started 2 agents alongside 1 already going (2026-08-22T22-06-41-065Z (pid 4242)): planning "a.md"; planning "b.md"',
   )
 })
 
-test('an entry a live run was pinned to is not handed out twice (#1204)', async () => {
-  // The assignment outlives the tick that made it: the first agent is still working entry a when
-  // the next sweep comes round, and its queue has not landed yet, so the checkout still shows the
-  // entry open. Handing it out again is exactly the duplicate work pinning exists to prevent.
-  const prompts: string[] = []
-  const { loop } = harness({
+test('an unreadable concurrency falls back to the default rather than to one (#1204)', async () => {
+  // Same polarity as the opt-out list: one bad read must not quietly shrink the routine.
+  const { loop, started } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
-    concurrency: async () => 1,
-    queue: async () => ['entry a', 'entry b'],
-    promote: async () => ({ settled: false, promoted: false }), // still in flight
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
+    concurrency: async () => Promise.reject(new Error('no registry')),
+    planCandidates: async () => ['a.md', 'b.md', 'c.md'],
+    lockPlans: async (_p, assignments) => assignments,
   })
   await loop.tick()
-  await loop.tick()
   loop.stop()
-  assert.equal(prompts.length, 2)
-  assert.match(prompts[0]!, /entry a/)
-  assert.match(prompts[1]!, /entry b/)
+  assert.equal(started.length, DEFAULT_AUTO_PM_CONCURRENCY)
 })
 
-test('a queue whose every entry is already being worked stands the sweep down (#1204)', async () => {
-  // With nothing left to assign, the sweep says so rather than starting an agent with no entry to
-  // pin it to — which is what would send a second agent at work already in flight.
-  const { loop, started } = harness({
+test('a refusal ends the batch, so the refused work is retried rather than skipped (#1204)', async () => {
+  // Whatever refused this start is not going to take the next one a moment later.
+  let attempts = 0
+  const { loop } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
     concurrency: async () => 4,
-    queue: async () => ['entry a'],
-    promote: async () => ({ settled: false, promoted: false }),
+    planCandidates: async () => ['a.md', 'b.md', 'c.md', 'd.md'],
+    lockPlans: async (_p, assignments) => assignments,
+    start: async () => {
+      attempts++
+      return attempts === 1 ? 'run-1' : undefined
+    },
   })
   await loop.tick()
-  await loop.tick()
   loop.stop()
-  assert.equal(started.length, 1)
-  assert.equal(loop.report().outcomes[0]?.message, 'every open queue entry is already being worked on')
+  assert.equal(attempts, 2, 'one start took, the second was refused, and the batch stopped there')
 })
 
-test('live runs count against the concurrency, so the sweep tops up rather than doubling (#1204)', async () => {
-  // Two already going under a cap of three leaves room for exactly one more.
-  const { loop, started } = harness({
+// #1204: Run now on the planning routine reaches the same fan-out the daemon uses. It used to be
+// a plain single start, so the concurrency setting was the one thing that click ignored.
+
+test("a plan-only sweep fans out the planning routine, one locked ticket per agent (#1204)", async () => {
+  const prompts: string[] = []
+  const { loop } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
     concurrency: async () => 3,
-    activeAgents: () => ['run-a (pid 111)', 'run-b (pid 222)'],
-    queue: async () => ['entry a', 'entry b', 'entry c'],
+    planCandidates: async () => ['a.md', 'b.md', 'c.md'],
+    lockPlans: async (_p, assignments) => assignments,
+    start: async (_p, job) => {
+      prompts.push(job.prompt)
+      return `run-${prompts.length}`
+    },
   })
-  await loop.tick()
+  await loop.tick({ onDemand: true, only: 'plan', projectId: 'p1' })
   loop.stop()
-  assert.equal(started.length, 1)
+  assert.equal(prompts.length, 3, 'the click spends the concurrency, not one agent')
+  assert.match(prompts[0]!, /tickets\/a\.md/)
+  assert.match(prompts[2]!, /tickets\/c\.md/)
 })
 
-// #1420: a drain's claim on what it *implements* is a pushed `.lock.md`, like planning's — the
-// in-memory pin above only guards this daemon's own fan-out, and two daemons on different
-// machines could book the implementation of the same ticket. Only entries that link back to a
-// ticket have anything on disk to lock; self-contained TODOs keep the queue as their
-// coordination point.
-
-test('a drain batch locks its ticket-linked entries, and each prompt carries its own claim (#1420)', async () => {
+test("a plan-only sweep plans instead of working the queue, however much the branch moved (#1204/#1774)", async () => {
   const prompts: string[] = []
-  const lockCalls: PlanAssignment[][] = []
-  const { loop } = harness({
+  const { loop, branch, ran } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
     concurrency: async () => 2,
-    queue: async () => ['[Fix a](tickets/2026-07-25_a.md)', '[Fix b](tickets/2026-07-25_b.md)'],
-    lockDrains: async (_p, assignments) => {
-      lockCalls.push([...assignments])
-      return assignments
-    },
+    planCandidates: async () => ['a.md'],
+    lockPlans: async (_p, assignments) => assignments,
     start: async (_p, job) => {
       prompts.push(job.prompt)
       return `run-${prompts.length}`
     },
   })
   await loop.tick()
-  loop.stop()
-  // The whole batch was locked in one call, before any agent started, and each agent's prompt
-  // names the id its own lock carries.
-  assert.equal(lockCalls.length, 1)
-  assert.deepEqual(lockCalls[0]!.map(a => a.ticket), ['2026-07-25_a.md', '2026-07-25_b.md'])
-  assert.equal(prompts.length, 2)
-  assert.match(prompts[0]!, /tickets\/2026-07-25_a\.md`, is already claimed for you/)
-  assert.match(prompts[1]!, /tickets\/2026-07-25_b\.md`, is already claimed for you/)
-  // The ids are minted a millisecond apart from the sweep's clock (#1748), so a batch stays distinct.
-  assert.equal(new Set(lockCalls[0]!.map(a => a.agentId)).size, 2)
-  assert.match(lockCalls[0]![0]!.agentId, /^2026-07-20T12-00-00-000Z$/)
-})
-
-test('a ticketless entry drains without a claim, and is not offered to the lock (#1420)', async () => {
-  const prompts: string[] = []
-  const lockCalls: PlanAssignment[][] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    concurrency: async () => 2,
-    queue: async () => ['just a self-contained TODO', '[Fix b](tickets/2026-07-25_b.md)'],
-    lockDrains: async (_p, assignments) => {
-      lockCalls.push([...assignments])
-      return assignments
-    },
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick()
-  loop.stop()
-  assert.deepEqual(lockCalls[0]!.map(a => a.ticket), ['2026-07-25_b.md'])
-  assert.equal(prompts.length, 2)
-  assert.ok(!/claimed for you/.test(prompts[0]!), 'the ticketless entry carries no claim')
-  assert.match(prompts[1]!, /claimed for you/)
-})
-
-test('an entry whose ticket claim was lost is dropped from the batch, not the batch (#1420)', async () => {
-  // Another machine's sweep won the race for a.md's lock: its agent will land the check-off in
-  // its own PR, so this batch simply does not start one — the next tick reconsiders.
-  const prompts: string[] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    concurrency: async () => 2,
-    queue: async () => ['[Fix a](tickets/2026-07-25_a.md)', '[Fix b](tickets/2026-07-25_b.md)'],
-    lockDrains: async (_p, assignments) => assignments.filter(a => a.ticket !== '2026-07-25_a.md'),
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick()
-  loop.stop()
-  assert.equal(prompts.length, 1)
-  assert.match(prompts[0]!, /Fix b/)
-})
-
-test('a batch that lost every claim stands the sweep down with the reason (#1420)', async () => {
-  const { loop, started } = harness({
-    cooldownMs: 0,
-    queue: async () => ['[Fix a](tickets/2026-07-25_a.md)'],
-    lockDrains: async () => [],
-  })
-  await loop.tick()
-  loop.stop()
-  assert.equal(started.length, 0)
-  assert.equal(
-    loop.report().outcomes[0]?.message,
-    'every entry in this batch links a ticket another agent already claimed',
-  )
-})
-
-test('without the lock seam a ticket-linked entry drains exactly as before (#1420)', async () => {
-  const prompts: string[] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => ['[Fix a](tickets/2026-07-25_a.md)'],
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick()
-  loop.stop()
-  assert.equal(prompts.length, 1)
-  assert.ok(!/CLAIMED/.test(prompts[0]!))
-})
-
-test('pinnedDrainJob with a claim appends the same contract the pinned plan prompt carries (#1420)', () => {
-  const job: AutoPmJob = { name: 'drain', prompt: 'Work the queue.', drains: true }
-  const pinned = pinnedDrainJob(job, '[Fix x](tickets/2026-07-25_x.md)', {
-    ticket: '2026-07-25_x.md',
-    agentId: 'drain-7-0',
-  })
-  assert.match(pinned.prompt, /`tickets\/2026-07-25_x\.md`, is already claimed for you/)
-  assert.match(pinned.prompt, /`tickets show 2026-07-25_x\.md` names you as its holder/)
-  // Closing the ticket through the skill retires it with its siblings, the claim included: nothing
-  // else lifts a lock since #1420 dropped the timer.
-  assert.match(pinned.prompt, /run `tickets close 2026-07-25_x\.md`/)
-  assert.match(pinned.prompt, /claimed by someone else, it is not yours/)
-  // And without a claim, the prompt is exactly the pre-#1420 pin.
-  assert.ok(!/claimed for you/.test(pinnedDrainJob(job, 'entry a').prompt))
-})
-
-// #1583: the one claim the sweep can *know* is dead. A drain that settles with `no-commits` never
-// opens the PR whose merge deletes its `.lock.md`, so without this the queue livelocks on the dead
-// claim — the next sweep re-offers the entry, drain-mode locking skips the locked ticket, and the
-// batch empties, forever, until a human clicks Release.
-
-test('a claim whose run settled with nothing to hand off is released (#1583)', async () => {
-  const released: PlanAssignment[] = []
-  const lockCalls: PlanAssignment[][] = []
-  let queued = ['[Fix a](tickets/2026-07-25_a.md)']
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => queued,
-    lockDrains: async (_p, assignments) => {
-      lockCalls.push([...assignments])
-      return assignments
-    },
-    promote: async () => ({ settled: true, promoted: false, handoffSkip: 'no-commits' }),
-    releaseLock: async (_p, claim) => {
-      released.push(claim)
-      return true
-    },
-  })
-  await loop.tick() // mints the claim and starts the drain
-  queued = []
-  await loop.tick() // the run has settled `no-commits`: the exact minted claim is freed
-  loop.stop()
-  assert.deepEqual(released, [lockCalls[0]![0]])
-})
-
-test('a sweep that catches the end-before-handoff gap holds the claim and still releases (#1583)', async () => {
-  // `end` lands before the handoff event, so a sweep can observe a finished run whose ending is
-  // not written yet. Settling there would drop the claim with the ending unread — the release
-  // would be missed for good — so the agent is held pending until the epilogue reports.
-  const released: PlanAssignment[] = []
-  let ending: { handoffPending?: boolean; handoffSkip?: 'no-commits' } = { handoffPending: true }
-  let queued = ['[Fix a](tickets/2026-07-25_a.md)']
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => queued,
-    lockDrains: async (_p, assignments) => assignments,
-    promote: async () => ({ settled: true, promoted: false, ...ending }),
-    releaseLock: async (_p, claim) => {
-      released.push(claim)
-      return true
-    },
-  })
-  await loop.tick() // starts the drain
-  queued = []
-  await loop.tick() // mid-epilogue: held, not settled, nothing released
-  assert.deepEqual(released, [])
-  ending = { handoffSkip: 'no-commits' }
-  await loop.tick() // the ending has landed: the claim is freed
-  loop.stop()
-  assert.equal(released.length, 1)
-})
-
-test('the mid-epilogue hold is bounded, so a run that dies there cannot pin its entry forever (#1583)', async () => {
-  const released: PlanAssignment[] = []
-  const promoted: string[] = []
-  let queued = ['[Fix a](tickets/2026-07-25_a.md)']
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => queued,
-    lockDrains: async (_p, assignments) => assignments,
-    promote: async (_p, { agentId }) => {
-      promoted.push(agentId)
-      return { settled: true, promoted: false, handoffPending: true }
-    },
-    releaseLock: async (_p, claim) => {
-      released.push(claim)
-      return true
-    },
-  })
-  await loop.tick()
-  queued = []
-  for (let i = 0; i < 5; i++) await loop.tick()
-  loop.stop()
-  // Two held sweeps, then the third settles it unread — the pre-#1583 behavior — rather than
-  // asking forever about a run that will never answer. (Later ticks promote only the rotation
-  // agents the emptied queue lets through, never this one again.)
-  assert.equal(promoted.filter(id => id === 'run-1').length, 3)
-  assert.deepEqual(released, [])
-})
-
-test('an entry whose drain ended with nothing to hand off is not drained again (#1583)', async () => {
-  // Releasing the claim re-opens the work, and a job that deterministically ends commitless
-  // would respawn every cooldown forever, burning a quota run per cycle. One attempt per daemon
-  // lifetime; the stand-down says why the entry sits.
-  const prompts: string[] = []
-  const released: PlanAssignment[] = []
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => ['[Fix a](tickets/2026-07-25_a.md)'],
-    lockDrains: async (_p, assignments) => assignments,
-    promote: async () => ({ settled: true, promoted: false, handoffSkip: 'no-commits' }),
-    releaseLock: async (_p, claim) => {
-      released.push(claim)
-      return true
-    },
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick() // spawns the drain
-  await loop.tick() // settles no-commits: the claim is released and the entry remembered
-  await loop.tick() // the entry is still open, and deliberately not offered again
-  loop.stop()
-  assert.equal(prompts.length, 1)
-  assert.equal(released.length, 1)
-  assert.match(loop.report().outcomes[0]?.message ?? '', /drained once with nothing to hand off/)
-})
-
-test('claims of a batch the start loop never reached are released, not stranded (#1583)', async () => {
-  // The batch's locks are committed and pushed before the first spawn; a refused start breaks
-  // the loop, and the never-started items' claims have no run that could ever settle them free.
-  const released: PlanAssignment[] = []
-  const lockCalls: PlanAssignment[][] = []
-  let starts = 0
-  const { loop } = harness({
-    cooldownMs: 0,
-    concurrency: async () => 2,
-    queue: async () => ['[Fix a](tickets/2026-07-25_a.md)', '[Fix b](tickets/2026-07-25_b.md)'],
-    lockDrains: async (_p, assignments) => {
-      lockCalls.push([...assignments])
-      return assignments
-    },
-    start: async () => (++starts === 1 ? 'run-1' : undefined), // the second spawn is refused
-    releaseLock: async (_p, claim) => {
-      released.push(claim)
-      return true
-    },
-  })
-  await loop.tick()
-  loop.stop()
-  assert.equal(released.length, 1)
-  assert.equal(released[0]!.ticket, lockCalls[0]![1]!.ticket)
-})
-
-test('a release that could not land is retried next sweep, bounded (#1583)', async () => {
-  const attempts: PlanAssignment[] = []
-  let queued = ['[Fix a](tickets/2026-07-25_a.md)']
-  const { loop } = harness({
-    cooldownMs: 0,
-    queue: async () => queued,
-    lockDrains: async (_p, assignments) => assignments,
-    promote: async () => ({ settled: true, promoted: false, handoffSkip: 'no-commits' }),
-    releaseLock: async (_p, claim) => {
-      attempts.push(claim)
-      return attempts.length >= 2 // the first try hits a transient failure, the retry lands
-    },
-  })
-  await loop.tick()
-  queued = []
-  await loop.tick() // the release fails to commit: the agent is held for a retry
-  await loop.tick() // the retry lands
-  await loop.tick() // dealt with: no further attempts
-  loop.stop()
-  assert.equal(attempts.length, 2)
-})
-
-test('every other ending leaves the lock to its own lifecycle (#1583)', async () => {
-  // A run that published (or whose handoff skipped because its PR already exists) has a PR whose
-  // merge deletes the lock; freeing it here would re-open the double-work window the claim closes.
-  for (const outcome of [
-    { settled: true, promoted: true },
-    { settled: true, promoted: false, handoffSkip: 'already-open' as const },
-  ]) {
-    const released: PlanAssignment[] = []
-    let queued = ['[Fix a](tickets/2026-07-25_a.md)']
-    const { loop } = harness({
-      cooldownMs: 0,
-      queue: async () => queued,
-      lockDrains: async (_p, assignments) => assignments,
-      promote: async () => outcome,
-      releaseLock: async (_p, claim) => {
-      released.push(claim)
-      return true
-    },
-    })
-    await loop.tick()
-    queued = []
-    await loop.tick()
-    loop.stop()
-    assert.deepEqual(released, [])
-  }
-})
-
-// #1327: [Plan tickets] fans out too — the one rotation job that writes per-ticket sibling files
-// rather than the shared queue document, so agents pinned one ticket each do disjoint work. The
-// PENDING locks are what make the batch safe beyond this process's memory, so no locks means no
-// fan-out.
-
-const PLAN_JOB: AutoPmJob = { name: 'plan', prompt: 'Plan every ticket that has no plan yet.', fansOut: true }
-
-test('a fansOut job fans out to the concurrency, one locked ticket per agent (#1327)', async () => {
-  const prompts: string[] = []
-  const lockCalls: PlanAssignment[][] = []
-  const { loop } = harness({
-    jobs: [PLAN_JOB],
-    cooldownMs: 0,
-    concurrency: async () => 3,
-    planCandidates: async () => ['a.md', 'b.md', 'c.md', 'd.md'],
-    lockPlans: async (_p, assignments) => {
-      lockCalls.push([...assignments])
-      return assignments
-    },
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick()
-  loop.stop()
-  assert.equal(prompts.length, 3, 'the batch stops at the concurrency, not at the candidate count')
-  // Pinned to *different* tickets, in the candidates' own most-important-first order.
-  assert.match(prompts[0]!, /tickets\/a\.md/)
-  assert.match(prompts[1]!, /tickets\/b\.md/)
-  assert.match(prompts[2]!, /tickets\/c\.md/)
-  // The whole batch was locked in one call, before any agent started, and each agent's prompt
-  // names the id its own lock carries.
-  assert.equal(lockCalls.length, 1)
-  assert.equal(lockCalls[0]!.length, 3)
-  assert.equal(new Set(lockCalls[0]!.map(a => a.agentId)).size, 3)
-  assert.match(prompts[0]!, /`tickets show a\.md` names you as its holder/)
-})
-
-// #1204: Run now on the planning routine reaches the same fan-out the daemon uses. It used to be
-// a plain single start, so the concurrency setting was the one thing that click ignored.
-
-test("a plan-only sweep fans out the planning routine, one locked ticket per agent (#1204)", async () => {
-  const prompts: string[] = []
-  const { loop } = harness({
-    jobs: [PLAN_JOB],
-    cooldownMs: 0,
-    concurrency: async () => 3,
-    planCandidates: async () => ['a.md', 'b.md', 'c.md'],
-    lockPlans: async (_p, assignments) => assignments,
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick({ onDemand: true, only: 'plan', projectId: 'p1' })
-  loop.stop()
-  assert.equal(prompts.length, 3, 'the click spends the concurrency, not one agent')
-  assert.match(prompts[0]!, /tickets\/a\.md/)
-  assert.match(prompts[2]!, /tickets\/c\.md/)
-})
-
-test("a plan-only sweep plans instead of draining, however full the queue is (#1204)", async () => {
-  // The queue-picked mode would send this tick to the drain. The click named the planning
-  // routine, so the queue is not its business.
-  //
-  // Asserted on the prompts rather than the job name: the name stays `plan` even when the tick
-  // falls through to the drain's fan-out, because it is the *batch* that differs — entries off
-  // the queue instead of tickets. The name alone passes either way, which is no guard at all.
-  const prompts: string[] = []
-  const { loop, ran } = harness({
-    jobs: [PLAN_JOB],
-    cooldownMs: 0,
-    concurrency: async () => 2,
-    queue: async () => ['work one', 'work two'],
-    drainJob: { name: 'drain', prompt: 'Work the queue.', drains: true },
-    planCandidates: async () => ['a.md'],
-    lockPlans: async (_p, assignments) => assignments,
-    start: async (_p, job) => {
-      prompts.push(job.prompt)
-      return `run-${prompts.length}`
-    },
-  })
-  await loop.tick({ onDemand: true, only: 'plan', projectId: 'p1' })
+  branch.move()
+  await loop.tick({ onDemand: true, only: 'plan', projectId: 'p1' })
   loop.stop()
   assert.deepEqual(ran, [])
-  assert.equal(prompts.length, 1, 'one open ticket is one agent, not one per queue entry')
-  assert.match(prompts[0]!, /tickets\/a\.md/)
-  assert.ok(
-    !prompts.some(prompt => prompt.includes('work one')),
-    'no agent was handed a queue entry: the click asked for planning, not draining',
-  )
+  assert.equal(prompts.filter(p => p !== AUTO_PM_WORK_JOB.prompt).length, prompts.length, 'no agent was sent to the queue: the click asked for planning')
+  assert.match(prompts[prompts.length - 1]!, /tickets\/a\.md/)
 })
 
 test("a plan-only sweep stands down when the planning routine is switched off (#1204)", async () => {
@@ -1374,22 +1111,23 @@ test('without the lock seam the job stays one per tick however high the concurre
 
 test('a ticket a live plan run is pinned to is not offered again (#1327)', async () => {
   // The lock files also guard this on disk, but the in-memory pin answers first and without
-  // re-reading anything — same as a drain's entry.
+  // re-reading anything. A second agent goes out on a click: the rotation itself waits for the
+  // first to end.
   const prompts: string[] = []
   const { loop } = harness({
     jobs: [PLAN_JOB],
     cooldownMs: 0,
-    concurrency: async () => 1,
+    concurrency: async () => 2,
     planCandidates: async () => ['a.md', 'b.md'],
-    lockPlans: async (_p, assignments) => assignments,
-    promote: async () => ({ settled: false, promoted: false }), // still in flight
+    lockPlans: async (_p, assignments) => assignments.slice(0, 1),
+    settled: async () => ({ settled: false }), // still in flight
     start: async (_p, job) => {
       prompts.push(job.prompt)
       return `run-${prompts.length}`
     },
   })
   await loop.tick()
-  await loop.tick()
+  await loop.tick({ onDemand: true, only: 'plan', projectId: 'p1' })
   loop.stop()
   assert.equal(prompts.length, 2)
   assert.match(prompts[0]!, /tickets\/a\.md/)
@@ -1434,65 +1172,193 @@ test('the catalog job that fans out is [Plan tickets], and only it (#1327)', ()
 
 test('the rotation stays one run per tick however high the concurrency (#1204)', async () => {
   // Deliberate: every rotation job rewrites the whole queue file from the same fork point, so two
-  // at once would have the later promotion revert the earlier one's entries. Only draining, which
-  // takes one named entry off, is safe to run several of at a time.
-  const { loop, ran } = harness({ cooldownMs: 0, concurrency: async () => 5, queue: async () => [] })
+  // at once would have the later promotion revert the earlier one's entries. Only planning, which
+  // writes one ticket's own files, is safe to run several of at a time.
+  const { loop, ran } = harness({ cooldownMs: 0, concurrency: async () => 5 })
   await loop.tick()
   loop.stop()
   assert.deepEqual(ran, ['first'])
 })
 
-test('an unreadable concurrency falls back to the default rather than to one (#1204)', async () => {
-  // Same polarity as the opt-out list: one bad read must not quietly shrink the routine.
-  const { loop, started } = harness({
+// #1583: the one claim the sweep can *know* is dead. A plan agent that settles with `no-commits`
+// never opens the PR whose merge deletes its `.lock.md`, so without this the planning livelocks on
+// the dead claim — the next sweep re-offers the ticket, the lock skips it, and the batch empties,
+// forever, until a human clicks Release.
+
+test('a claim whose run settled with nothing to hand off is released (#1583)', async () => {
+  const released: PlanAssignment[] = []
+  const lockCalls: PlanAssignment[][] = []
+  const { loop } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
-    concurrency: async () => Promise.reject(new Error('no registry')),
-    queue: async () => ['entry a', 'entry b', 'entry c'],
+    planCandidates: async () => ['a.md'],
+    lockPlans: async (_p, assignments) => {
+      lockCalls.push([...assignments])
+      return assignments
+    },
+    settled: async () => ({ settled: true, handoffSkip: 'no-commits' }),
+    releaseLock: async (_p, claim) => {
+      released.push(claim)
+      return true
+    },
   })
-  await loop.tick()
+  await loop.tick() // mints the claim and starts the plan agent
+  await loop.tick() // the run has settled `no-commits`: the exact minted claim is freed
   loop.stop()
-  assert.equal(started.length, DEFAULT_AUTO_PM_CONCURRENCY)
+  assert.deepEqual(released, [lockCalls[0]![0]])
 })
 
-test('a refusal ends the batch, so the refused work is retried rather than skipped (#1204)', async () => {
-  // Whatever refused this start is not going to take the next one a moment later.
-  let attempts = 0
+test('a sweep that catches the end-before-handoff gap holds the claim and still releases (#1583)', async () => {
+  // `end` lands before the handoff event, so a sweep can observe a finished run whose ending is
+  // not written yet. Settling there would drop the claim with the ending unread — the release
+  // would be missed for good — so the agent is held pending until the epilogue reports.
+  const released: PlanAssignment[] = []
+  let ending: { handoffPending?: boolean; handoffSkip?: 'no-commits' } = { handoffPending: true }
   const { loop } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
-    concurrency: async () => 4,
-    queue: async () => ['entry a', 'entry b', 'entry c', 'entry d'],
-    start: async () => {
-      attempts++
-      return attempts === 1 ? 'run-1' : undefined
+    planCandidates: async () => ['a.md'],
+    lockPlans: async (_p, assignments) => assignments,
+    settled: async () => ({ settled: true, ...ending }),
+    releaseLock: async (_p, claim) => {
+      released.push(claim)
+      return true
+    },
+  })
+  await loop.tick() // starts the plan agent
+  await loop.tick() // mid-epilogue: held, not settled, nothing released
+  assert.deepEqual(released, [])
+  ending = { handoffSkip: 'no-commits' }
+  await loop.tick() // the ending has landed: the claim is freed
+  loop.stop()
+  assert.equal(released.length, 1)
+})
+
+test('the mid-epilogue hold is bounded, so a run that dies there cannot hold its claim forever (#1583)', async () => {
+  const released: PlanAssignment[] = []
+  const asked: string[] = []
+  const { loop } = harness({
+    jobs: [PLAN_JOB],
+    cooldownMs: 0,
+    planCandidates: async () => ['a.md'],
+    lockPlans: async (_p, assignments) => assignments,
+    settled: async (_p, { agentId }) => {
+      asked.push(agentId)
+      return { settled: true, handoffPending: true }
+    },
+    releaseLock: async (_p, claim) => {
+      released.push(claim)
+      return true
     },
   })
   await loop.tick()
+  for (let i = 0; i < 5; i++) await loop.tick()
   loop.stop()
-  assert.equal(attempts, 2, 'one start took, the second was refused, and the batch stopped there')
+  // Two held sweeps, then the third settles it unread — the pre-#1583 behavior — rather than
+  // asking forever about a run that will never answer.
+  assert.equal(asked.filter(id => id === 'run-1').length, 3)
+  assert.deepEqual(released, [])
 })
 
-test('a drain-only sweep works the queue and never borrows the tick for the rotation (#1204)', async () => {
-  // The drain row's Run now: with entries waiting it fans out like any drain sweep...
+test('a ticket whose plan agent ended with nothing to hand off is not planned again (#1583)', async () => {
+  // Releasing the claim re-opens the work, and a job that deterministically ends commitless
+  // would respawn every cooldown forever, burning a quota run per cycle. One attempt per daemon
+  // lifetime.
   const prompts: string[] = []
+  const released: PlanAssignment[] = []
   const { loop } = harness({
+    jobs: [PLAN_JOB],
     cooldownMs: 0,
-    concurrency: async () => 2,
-    queue: async () => ['entry a', 'entry b'],
+    planCandidates: async () => ['a.md'],
+    lockPlans: async (_p, assignments) => assignments,
+    settled: async () => ({ settled: true, handoffSkip: 'no-commits' }),
+    releaseLock: async (_p, claim) => {
+      released.push(claim)
+      return true
+    },
     start: async (_p, job) => {
       prompts.push(job.prompt)
       return `run-${prompts.length}`
     },
   })
-  await loop.tick({ onDemand: true, only: 'drain' })
+  await loop.tick() // spawns the plan agent
+  await loop.tick() // settles no-commits: the claim is released and the ticket remembered
+  await loop.tick() // the ticket is still open, and deliberately not offered again
   loop.stop()
-  assert.equal(prompts.length, 2)
+  assert.equal(prompts.length, 1)
+  assert.equal(released.length, 1)
+  assert.match(loop.report().outcomes[0]?.message ?? '', /already has a plan, or an agent on the way to one/)
+})
+
+test('claims of a batch the start loop never reached are released, not stranded (#1583)', async () => {
+  // The batch's locks are committed and pushed before the first spawn; a refused start breaks
+  // the loop, and the never-started items' claims have no run that could ever settle them free.
+  const released: PlanAssignment[] = []
+  const lockCalls: PlanAssignment[][] = []
+  let starts = 0
+  const { loop } = harness({
+    jobs: [PLAN_JOB],
+    cooldownMs: 0,
+    concurrency: async () => 2,
+    planCandidates: async () => ['a.md', 'b.md'],
+    lockPlans: async (_p, assignments) => {
+      lockCalls.push([...assignments])
+      return assignments
+    },
+    start: async () => (++starts === 1 ? 'run-1' : undefined), // the second spawn is refused
+    releaseLock: async (_p, claim) => {
+      released.push(claim)
+      return true
+    },
+  })
+  await loop.tick()
+  loop.stop()
+  assert.equal(released.length, 1)
+  assert.equal(released[0]!.ticket, lockCalls[0]![1]!.ticket)
+})
+
+test('a release that could not land is retried next sweep, bounded (#1583)', async () => {
+  const attempts: PlanAssignment[] = []
+  const { loop } = harness({
+    jobs: [PLAN_JOB],
+    cooldownMs: 0,
+    planCandidates: async () => ['a.md'],
+    lockPlans: async (_p, assignments) => assignments,
+    settled: async () => ({ settled: true, handoffSkip: 'no-commits' }),
+    releaseLock: async (_p, claim) => {
+      attempts.push(claim)
+      return attempts.length >= 2 // the first try hits a transient failure, the retry lands
+    },
+  })
+  await loop.tick()
+  await loop.tick() // the release fails to commit: the agent is held for a retry
+  await loop.tick() // the retry lands
+  await loop.tick() // dealt with: no further attempts
+  loop.stop()
+  assert.equal(attempts.length, 2)
+})
 
-  // ...and with an empty queue it says so instead of starting a rotation job.
-  const { loop: empty, started } = harness({ cooldownMs: 0, queue: async () => [] })
-  await empty.tick({ onDemand: true, only: 'drain' })
-  empty.stop()
-  assert.equal(started.length, 0)
-  assert.equal(empty.report().outcomes[0]?.message, 'the queue is empty, so there is nothing to drain')
+test('every other ending leaves the lock to its own lifecycle (#1583)', async () => {
+  // A run that published (or whose handoff skipped because its PR already exists) has a PR whose
+  // merge deletes the lock; freeing it here would re-open the double-work window the claim closes.
+  for (const outcome of [{ settled: true }, { settled: true, handoffSkip: 'already-open' as const }]) {
+    const released: PlanAssignment[] = []
+    const { loop } = harness({
+      jobs: [PLAN_JOB],
+      cooldownMs: 0,
+      planCandidates: async () => ['a.md'],
+      lockPlans: async (_p, assignments) => assignments,
+      settled: async () => outcome,
+      releaseLock: async (_p, claim) => {
+        released.push(claim)
+        return true
+      },
+    })
+    await loop.tick()
+    await loop.tick()
+    loop.stop()
+    assert.deepEqual(released, [])
+  }
 })
 
 // #1659: the routine lock. A triage rewrites the shared queue and may take hours, so the sweep
@@ -1535,20 +1401,19 @@ test('a locked job takes its lock before it starts, and releases it when the run
       lock.order.push(`start:${job.name}`)
       return 'run-1'
     },
-    promote: async () => ({ settled, promoted: false }),
+    settled: async () => ({ settled }),
   })
   await loop.tick()
   assert.deepEqual(lock.order, ['lock:triage-quick', 'start:triage-quick'])
-  // Still running: the lock stands, and the next sweep stands down on it rather than starting another.
+  // Still running: the lock stands, and the rotation waits for the run rather than starting another.
   await loop.tick()
-  assert.deepEqual(lock.order, ['lock:triage-quick', 'start:triage-quick', 'lock:triage-quick'])
-  assert.equal(loop.report().outcomes[0]?.message, 'triage-quick is already running on laptop (since T0)')
+  assert.deepEqual(lock.order, ['lock:triage-quick', 'start:triage-quick'])
   settled = true
   await loop.tick()
   loop.stop()
   // Released on the ending itself — no `no-commits` condition, no PR: a triage never opens one —
   // and the same sweep may take it again.
-  assert.deepEqual(lock.order.slice(3), ['release:triage-quick', 'lock:triage-quick', 'start:triage-quick'])
+  assert.deepEqual(lock.order.slice(2), ['release:triage-quick', 'lock:triage-quick', 'start:triage-quick'])
 })
 
 test('a held lock stands the job down naming its holder, with no agent started (#1659)', async () => {
@@ -1587,7 +1452,7 @@ test('a refused start gives the lock back, and a failed release is retried next
     cooldownMs: 0,
     lockRoutine: lock.lockRoutine,
     releaseRoutine: async (project, name) => (ok ? lock.releaseRoutine!(project, name) : false),
-    promote: async () => ({ settled: true, promoted: false }),
+    settled: async () => ({ settled: true }),
   })
   await flaky.loop.tick()
   await flaky.loop.tick()
@@ -1678,34 +1543,19 @@ test('a switched-off locked routine stands the click down, and so does every oth
   assert.deepEqual(capped.ran, [], 'a live agent at the cap holds the click like it holds the sweep')
 })
 
-test('a sweep narrowed to a locked job never falls through to the drain or another rotation job (#1643)', async () => {
-  // The queue is full, so the queue-picked mode would drain; the rotation is on another job's
-  // turn, so the index would fire that one. The click named the locked routine and gets it alone
-  // — and the scheduled tick after it still gets the rotation job it was owed.
+test('a sweep narrowed to a locked job never falls through to the queued work or another rotation job (#1643/#1774)', async () => {
+  // The branch has moved, so the scheduled sweep would work the queue; the rotation is on
+  // another job's turn, so the index would fire that one. The click named the locked routine and
+  // gets it alone — and the scheduled tick after it still gets the queued work it was owed.
   const other: AutoPmJob = { name: 'update', prompt: 'Update.' }
-  let entries = ['work one']
-  const { loop, ran } = harness({
-    jobs: [other, LOCKED_JOB],
-    cooldownMs: 0,
-    queue: async () => entries,
-    drainJob: { name: 'drain', prompt: 'Work the queue.', drains: true },
-  })
+  const { loop, branch, ran } = harness({ jobs: [other, LOCKED_JOB], cooldownMs: 0 })
+  await loop.tick()
+  branch.move()
   await loop.tick({ onDemand: true, only: { lock: 'triage-quick' }, projectId: 'p1' })
-  assert.deepEqual(ran, ['triage-quick'], 'neither the full queue nor the rotation index took the click')
-  entries = []
+  assert.deepEqual(ran, ['update', 'triage-quick'], 'neither the moved branch nor the rotation index took the click')
   await loop.tick()
   loop.stop()
-  assert.deepEqual(ran, ['triage-quick', 'update'], 'the scheduled tick still gets the rotation job it was owed')
-})
-
-test('only the drain job lands its own PRs (#1216)', () => {
-  // The drain implements queue entries whose triage a human could have vetoed, so its review
-  // happened before the agent. Every other job writes tickets/plans and has nothing to merge —
-  // an autoMerge there would be an agent landing unreviewed work.
-  assert.equal(AUTO_PM_DRAIN_JOB.autoMerge, true)
-  for (const job of [...AUTO_PM_JOBS, AUTO_PM_MAINTENANCE_JOB]) {
-    assert.equal(job.autoMerge, undefined, `${job.name} must not auto-merge`)
-  }
+  assert.deepEqual(ran, ['update', 'triage-quick', AUTO_PM_WORK_JOB.name], 'the scheduled tick still gets the move it was owed')
 })
 
 test('the triage jobs hold a lock named after them, and their prompts no longer abort on a branch (#1659)', () => {
diff --git a/packages/framework/src/auto-pm.ts b/packages/framework/src/auto-pm.ts
index ecbc07862..f1ade45d1 100644
--- a/packages/framework/src/auto-pm.ts
+++ b/packages/framework/src/auto-pm.ts
@@ -2,15 +2,21 @@ import type { QuotaBoundaryStatus } from './quota-boundary.js'
 import type { AutoHandoffSkip } from './events.js'
 import { presets } from './preset-catalog.js'
 import { DEFAULT_AUTO_PM_CONCURRENCY } from './preference-defaults.js'
-import { TICKETS_DIR, ticketFromQueueEntry } from '@gemstack/skill-tickets/names'
 import { agentIdFromStartedAt } from './agent-id.js'
 
 /**
  * Auto PM (#685): spend leftover subscription quota on product management instead of
  * letting it expire. While the account is still under its quota boundary (#879) and nobody
- * is at the keyboard, the daemon runs the cycle by itself: it works the agent queue down entry by entry (#855),
- * and once that is empty it refills it — triaging tickets, then spiking and planning
- * the ones that have neither yet.
+ * is at the keyboard, the daemon runs the cycle by itself: it starts an agent on the queued work
+ * whenever the `agent-data` branch moved (#1774), and once a run finds nothing queued it refills
+ * the queue — triaging tickets, then spiking and planning the ones that have neither yet.
+ *
+ * The daemon reads no queue and names no skill (#1774). It watches one thing, the head of the
+ * `agent-data` branch, and reacts to the commits it did not write itself: someone queued an entry,
+ * an agent claimed or closed a ticket. The agent started for that reads the skills in its checkout
+ * and takes one queued task; its own commits move the branch again, so the daemon fires again as
+ * the run ends, and the chain drains the queue by itself. A run that finds nothing writes nothing,
+ * and the chain stops. One heartbeat a day is the belt.
  *
  * The whole feature is one policy question ("is now a good time to spend tokens on our
  * own roadmap?"), so that question lives here as a pure function and the daemon only
@@ -18,26 +24,27 @@ import { agentIdFromStartedAt } from './agent-id.js'
  * and #879 defines the boundary this reads.
  */
 
-/** How often the daemon re-asks {@link autoPmDecision}. */
-export const DEFAULT_AUTO_PM_INTERVAL_MS = 10 * 60 * 1000
+/** How often the daemon looks at the branch and re-asks {@link autoPmDecision}: right after each data pull. */
+export const DEFAULT_AUTO_PM_INTERVAL_MS = 60 * 1000
 
 /**
- * How long a project is left alone after an auto agent is started for it. A spawned agent
- * takes a moment to appear in the daemon's live-run map, and without this the next tick
- * would see "nothing running, queue still empty" and start a second one.
+ * How long a project is left alone after the rotation starts an agent for it. The rotation
+ * invents work on an idle project, and this is what paces it. A move of the branch is never
+ * paced: someone, or an agent, asked for that run.
  */
 const DEFAULT_AUTO_PM_COOLDOWN_MS = 30 * 60 * 1000
 
+/**
+ * The belt (#1774): a run on the queued work once a day even when nothing moved, so a branch the
+ * daemon missed a move on — a range git could not walk, a restart between a push and the look —
+ * is looked at by an agent within a day.
+ */
+export const DEFAULT_AUTO_PM_HEARTBEAT_MS = 24 * 60 * 60 * 1000
+
 /** What the policy was told about one project at one moment. */
 export interface AutoPmInputs {
   /** The `autoPm` preference. Off = the feature does nothing at all. */
   enabled: boolean
-  /**
-   * Whether the project's agent queue (`TODO_AGENTS.md`) has no open entry left, or `undefined`
-   * when it could not be read. Unreadable is not empty and not full: it fails closed, because
-   * since #855 both answers now *start* something and only "we could not tell" does not.
-   */
-  backlogEmpty: boolean | undefined
   /** Live agents on this project, measured against {@link AutoPmInputs.concurrency}. */
   activeAgents: number
   /**
@@ -54,7 +61,10 @@ export interface AutoPmInputs {
   concurrency?: number
   /** Where the account stands against its quota boundary, or `undefined` when it could not be read. */
   quota: QuotaBoundaryStatus | undefined
-  /** Milliseconds since this project was last auto-started, or `undefined` if it never was. */
+  /**
+   * Milliseconds since the rotation last started an agent for this project, or `undefined` when
+   * the cooldown does not apply: the rotation never did, or this start is for a move of the branch.
+   */
   sinceLastStartMs?: number
   /** Override {@link DEFAULT_AUTO_PM_COOLDOWN_MS}. */
   cooldownMs?: number
@@ -69,17 +79,11 @@ export interface AutoPmInputs {
 /** Why the sweep is not starting anything. Logged, so it reads as a sentence. */
 export type AutoPmRefusal = { start: false; reason: string }
 
-/**
- * Which half of the cycle a start belongs to (#855). `drain` works an entry the queue already
- * holds; `pm` puts new work in it. The queue decides: standing work is spent before more is made.
- */
-export type AutoPmMode = 'drain' | 'pm'
-
 /** Whether the budget allows spending unasked at all, before asking what to spend it on. */
 export type QuotaDecision = { start: true } | AutoPmRefusal
 
-/** Start (and at what), or the reason not to. */
-export type AutoPmDecision = { start: true; mode: AutoPmMode } | AutoPmRefusal
+/** Start, or the reason not to. */
+export type AutoPmDecision = { start: true } | AutoPmRefusal
 
 /**
  * Whether the budget allows spending unasked.
@@ -120,7 +124,7 @@ export function quotaHeadroom(quota: QuotaBoundaryStatus | undefined): QuotaDeci
 }
 
 /**
- * Whether to start a PM agent for one project right now. Every condition is a reason to
+ * Whether to start an agent for one project right now. Every condition is a reason to
  * *not* spend the user's quota, checked cheapest first so the common "someone is working"
  * case never reaches the meter.
  */
@@ -141,23 +145,15 @@ export function autoPmDecision(input: AutoPmInputs): AutoPmDecision {
   if (!input.onDemand && input.sinceLastStartMs !== undefined && input.sinceLastStartMs < cooldownMs) {
     return { start: false, reason: 'a run was started for this project a moment ago' }
   }
-  if (input.backlogEmpty === undefined) {
-    return { start: false, reason: 'the agent queue could not be read, so there is no way to tell what to do' }
-  }
-  const headroom = quotaHeadroom(input.quota)
-  if (!headroom.start) return headroom
-  // The queue picks the job, and a non-empty one wins (#855). It used to be a refusal, on the
-  // reasoning that the backlog loop would drain it — but that loop only exists inside an agent a
-  // human started, so unattended the queue filled once and nothing ever emptied it again.
-  return { start: true, mode: input.backlogEmpty ? 'pm' : 'drain' }
+  return quotaHeadroom(input.quota)
 }
 
 /**
  * One thing auto PM knows how to do while the machine is idle (#773).
  *
  * The jobs form a cycle, and the order matters: triage turns tickets into queued work, [Plan
- * tickets] turns the rest into plans. Once a job queues something the sweep switches to draining it
- * (#855), and the rotation resumes where it left off once the queue is empty again.
+ * tickets] turns the rest into plans. Once a job queues something the branch moves and the queued
+ * work is started (#1774); the rotation resumes where it left off once a run finds nothing queued.
  */
 export interface AutoPmJob {
   /** Stable id: the rotation and the opt-out list (#1209) key on it. */
@@ -186,50 +182,43 @@ export interface AutoPmJob {
    */
   tooltip?: string | undefined
   /**
-   * This job works an entry already on the queue, rather than putting entries on it (#1117).
-   *
-   * Only the draining job has a specific piece of work it is about to pick up, so only it can be
-   * told which ticket that is. Declared here rather than matched on {@link AutoPmJob.name} at the
-   * call site, so the job says what it does and a rename cannot quietly unhook it.
-   */
-  drains?: boolean
-  /**
-   * The one queue entry a {@link AutoPmJob.drains} job is pinned to (#1204). Set only on the
-   * per-start variants {@link pinnedDrainJob} builds: the catalog's own drain job carries none,
-   * since which entry is next is known only at the moment the sweep starts one.
+   * This job works the queued work rather than making more of it (#1774): the daemon fires it
+   * when the `agent-data` branch moved, and a Run now on its row is that same fire, asked for.
+   * Declared here rather than matched on {@link AutoPmJob.name} at the call site, so the job says
+   * what it does and a rename cannot quietly unhook it.
    */
-  entry?: string
+  works?: boolean
   /**
    * The routine lock this job holds while it runs (#1659), as `routines/<lock>.lock.md` on the
    * agent-data branch: the triage routines rewrite the shared queue and may take hours, so no two may
    * run at once, on any machine. The sweep mints it before the start and releases it when the
-   * run ends. Declared as data on the job, like {@link AutoPmJob.drains}, so the sweep never
+   * run ends. Declared as data on the job, like {@link AutoPmJob.works}, so the sweep never
    * matches on {@link AutoPmJob.name} at the call site.
    */
   lock?: string
   /**
-   * Merge this job's PR once its agent opens it (#1216). Set on the drain job: what it implements
-   * has already been triaged as consensual, quick-win work a human could have vetoed on the
-   * queue, so its PR is the one kind whose review happened before the agent. Declared as data on
-   * the job for the same no-name-matching reason as {@link AutoPmJob.drains}.
+   * Merge this job's PR once its agent opens it (#1216). Set on the job that works the queue: what
+   * it implements has already been triaged as consensual, quick-win work a human could have vetoed
+   * on the queue, so its PR is the one kind whose review happened before the agent. Declared as
+   * data on the job for the same no-name-matching reason as {@link AutoPmJob.works}.
    */
   autoMerge?: boolean
   /**
    * This rotation job may fan out to several agents pinned one ticket each (#1327). Only
    * [Plan tickets] declares it: unlike the other rotation jobs it writes per-ticket sibling files
    * rather than rewriting the shared queue document, so concurrent copies do disjoint work and
-   * land disjoint edits — the exact property that already lets draining fan out. Declared as data
-   * on the job for the same no-name-matching reason as {@link AutoPmJob.drains}.
+   * land disjoint edits. Declared as data on the job for the same no-name-matching reason as
+   * {@link AutoPmJob.works}.
    */
   fansOut?: boolean
   /**
    * The one ticket a fanned-out job is pinned to (#1327), as its filename inside `tickets/`. Set
-   * only on the per-start variants {@link pinnedPlanJob} builds, like {@link AutoPmJob.entry} is
-   * for drains: which tickets are open is known only at the moment the sweep locks them.
+   * only on the per-start variants {@link pinnedPlanJob} builds: which tickets are open is known
+   * only at the moment the sweep locks them.
    */
   ticket?: string
   /**
-   * The `.lock.md` claim the sweep minted for this start (#1420/#1583), on both pinned variants.
+   * The `.lock.md` claim the sweep minted for this start (#1420/#1583), on the pinned variants.
    * What lets the sweep free the claim itself when the agent settles with nothing to hand off:
    * the agent's PR is what normally deletes the lock, and an agent that never made a commit is
    * never opening one.
@@ -258,49 +247,6 @@ function mintAgentIds(now: number, count: number): string[] {
   return Array.from({ length: count }, (_, i) => agentIdFromStartedAt(new Date(now + i).toISOString()))
 }
 
-/**
- * A drain job pinned to one named queue entry (#1204).
- *
- * With a single agent the stock prompt ("the FIRST open entry") is exact. With several going at
- * once it is a collision: every drain forks the same checkout, so every one of them reads the same
- * first entry and implements it as many times over. Naming the entry is what makes a batch of
- * drains work on disjoint things.
- *
- * The prompt also tells the agent to stop when the entry is gone: the
- * assignment is a snapshot, and a human may retire the entry between the sweep's read and the
- * run's own.
- *
- * When the entry links back to a ticket the sweep has claimed (#1420), the agent is also told
- * which claim is its own — the same contract {@link pinnedPlanJob} carries, because the same
- * gap exists: without the lock the claim on the *implementation* lived only in this daemon's
- * memory, so another machine's sweep could book the same ticket. Ticket, plan and lock live on
- * the `agent-data` branch (#1582/#1748), so the agent closes the ticket there once its work is published — nothing
- * else releases a lock since #1420 dropped the timer. The queue entry itself is NOT the agent's
- * to touch: the daemon checks it off at settle, once the run's ending reports the work landed.
- */
-export function pinnedDrainJob(job: AutoPmJob, entry: string, assignment?: PlanAssignment): AutoPmJob {
-  const stem = assignment?.ticket.replace(/\.md$/, '')
-  return {
-    ...job,
-    entry,
-    ...(assignment ? { claim: assignment } : {}),
-    prompt: [
-      'Work on this one open entry of the agent queue only (use the `tickets` skill):',
-      '',
-      `- ${entry}`,
-      '',
-      'Do not start any other entry, and do not take the entry off the queue — the framework does once your work lands. If the entry is no longer on the queue, stop and do nothing.',
-      ...(assignment
-        ? [
-            '',
-            `The entry's ticket, \`${TICKETS_DIR}/${stem}.md\`, is already claimed for you: \`tickets show ${stem}.md\` names you as its holder. Once your work is published, run \`tickets close ${stem}.md\` — closed tickets leave the branch, and the claim goes with the ticket. If the ticket is not claimed, or claimed by someone else, it is not yours — stop and do nothing.`,
-          ]
-        : []),
-    ].join('\n'),
-    describe: `draining the queue entry "${entryPreview(entry)}"`,
-  }
-}
-
 /** An entry as a log line can carry it: one line, bounded. */
 function entryPreview(entry: string): string {
   const flat = entry.replace(/\s+/g, ' ').trim()
@@ -311,10 +257,10 @@ function entryPreview(entry: string): string {
  * A fan-out job pinned to one locked ticket (#1327).
  *
  * The stock prompt covers every ticket that has no plan or claim yet, and with a batch going out
- * that instruction is the same collision {@link pinnedDrainJob} exists for: every agent forks the
- * same checkout and would pick the same most-important ticket. The pin is *appended* to the stock
- * prompt rather than spliced into it, so the verdict rules the preset carries keep riding along
- * verbatim and a rewritten preset (the maintainer owns its wording) cannot silently lose the pin.
+ * that instruction is a collision: every agent forks the same checkout and would pick the same
+ * most-important ticket. The pin is *appended* to the stock prompt rather than spliced into it,
+ * so the verdict rules the preset carries keep riding along verbatim and a rewritten preset (the
+ * maintainer owns its wording) cannot silently lose the pin.
  *
  * The agent is also told which claim is its own: its ticket's `.lock.md` already exists with the
  * `CLAIMED:` line the daemon pushed (#1420), and finding anything else there means the
@@ -353,8 +299,8 @@ export function pinnedPlanJob(job: AutoPmJob, assignment: PlanAssignment): AutoP
  * nothing changed since the last one is a no-op rather than a re-import.
  *
  * This rotation is what #891/#892 mean by "with a cron job regularly firing this preset". No
- * separate scheduler is involved and none is needed: the rotation already fires on every idle tick
- * where the queue is dry, which is exactly when the queue wants refilling. That is the opposite of
+ * separate scheduler is involved and none is needed: the rotation fires after every run that found
+ * nothing queued, which is exactly when the queue wants refilling. That is the opposite of
  * the maintenance sweep (#882), which is paced by a calendar because it looks at static history and
  * would otherwise never come due — hence its own {@link AUTO_PM_MAINTENANCE_JOB} outside the cycle.
  *
@@ -398,16 +344,24 @@ export const AUTO_PM_JOBS: readonly AutoPmJob[] = [
 ]
 
 /**
- * The job for a queue that is not empty (#855): work its first entry off. Outside the rotation
- * on purpose — the rotation is about what to *make* when there is nothing to do, and this is
- * the thing to do.
+ * The routine skill the daemon fires on the queued work (#1774): `skills/work-queue/SKILL.md` in
+ * this package, linked into every checkout the daemon makes, marked so that only a person or the
+ * daemon invokes it. Its prompt is the slash command; the agent's harness expands it.
+ */
+export const WORK_QUEUE_SKILL_NAME = 'work-queue'
+
+/**
+ * The job for the queued work (#1774): one agent, told nothing but `/work-queue`, takes one
+ * queued task off the queue by composing the skills in its checkout. Outside the rotation on
+ * purpose — the rotation is about what to *make* when there is nothing to do, and this is the
+ * thing to do. Its label and tooltip are written here: the routine is a skill file, not a preset.
  */
-export const AUTO_PM_DRAIN_JOB: AutoPmJob = {
-  name: presets.drainQueue.name,
-  prompt: presets.drainQueue.render(),
-  label: presets.drainQueue.label,
-  tooltip: presets.drainQueue.tooltip,
-  drains: true,
+export const AUTO_PM_WORK_JOB: AutoPmJob = {
+  name: WORK_QUEUE_SKILL_NAME,
+  prompt: `/${WORK_QUEUE_SKILL_NAME}`,
+  label: 'Work the queue',
+  tooltip: 'Work one queued task off the agent queue, unattended.',
+  works: true,
   autoMerge: true,
 }
 
@@ -415,11 +369,11 @@ export const AUTO_PM_DRAIN_JOB: AutoPmJob = {
  * The periodic codebase-wide sweep (#882): fire the [Maintenance] preset (#881) so a repo that
  * adopted The Framework late gets its pre-existing history looked at.
  *
- * Outside the rotation, like {@link AUTO_PM_DRAIN_JOB} and for the same kind of reason: the
- * rotation is "what to make next" and cycles every idle tick, while this is paced by a calendar
- * and must not advance or be advanced by the cycle. It takes precedence over the rotation when
- * due, because the entries it queues are what the rotation would otherwise be inventing work
- * instead of.
+ * Outside the rotation, like {@link AUTO_PM_WORK_JOB} and for the same kind of reason: the
+ * rotation is "what to make next" and cycles on every run that found nothing queued, while this is
+ * paced by a calendar and must not advance or be advanced by the cycle. It takes precedence over
+ * the rotation when due, because the entries it queues are what the rotation would otherwise be
+ * inventing work instead of.
  *
  * The prompt renders at module load with no session, so `tf.params.what` falls back to its
  * default of the entire codebase, which is exactly this job's scope.
@@ -437,12 +391,12 @@ export const AUTO_PM_MAINTENANCE_JOB: AutoPmJob = {
  *
  * Derived from the three constants above rather than written out again, so the list the dashboard
  * shows and the jobs the daemon actually runs cannot drift. The order is the sweep's own precedence
- * (#855/#882 read the other way round): draining comes first because it is what happens whenever
- * there is queued work, the rotation is what happens when there is not, and the calendar-paced
- * maintenance sweep is the exception outside both.
+ * (#855/#882 read the other way round): the queued work comes first because it is what happens
+ * whenever the branch moved, the rotation is what happens when a run found nothing, and the
+ * calendar-paced maintenance sweep is the exception outside both.
  */
 export const AUTO_PM_ROUTINES: readonly AutoPmJob[] = [
-  AUTO_PM_DRAIN_JOB,
+  AUTO_PM_WORK_JOB,
   ...AUTO_PM_JOBS,
   AUTO_PM_MAINTENANCE_JOB,
 ]
@@ -451,20 +405,16 @@ export const AUTO_PM_ROUTINES: readonly AutoPmJob[] = [
 const doing = (job: AutoPmJob) => job.describe ?? job.label ?? job.name
 
 /**
- * What became of one attempt to land an agent's queue (#852). The two flags are separate on purpose:
- * a finished agent that wrote no queue is `settled` without being `promoted`, and must stop being
- * retried; a still-running one is neither, and is tried again next tick.
+ * What became of one look at an agent this loop started. A finished agent is `settled` and stops
+ * being asked about; a still-running one is not, and is asked again next tick.
  */
-export interface PromoteOutcome {
-  /** Stop tracking this agent: it is finished, whether or not it left anything behind. */
+export interface SettleOutcome {
+  /** Stop tracking this agent: it is finished. */
   settled: boolean
-  /** The checkout's queue actually changed. */
-  promoted: boolean
   /**
-   * Why the settled run's handoff skipped, when its record says so (#1583). Rides on this outcome
-   * because the promotion already read the run's record, and the sweep needs exactly one fact
-   * from it: a run that ended `no-commits` will never open the PR that lifts the `.lock.md` it
-   * was started under, so the sweep releases that claim itself.
+   * Why the settled run's handoff skipped, when its record says so (#1583). The sweep needs
+   * exactly one fact from the record: a run that ended `no-commits` will never open the PR that
+   * lifts the `.lock.md` it was started under, so the sweep releases that claim itself.
    */
   handoffSkip?: AutoHandoffSkip
   /**
@@ -480,7 +430,7 @@ export interface PromoteOutcome {
 export interface AutoPmProject {
   /** Registry id, as `start` and the live-agent lookup take it. */
   id: string
-  /** Absolute repo path, for reading its queue. */
+  /** Absolute repo path, for reading its branch. */
   path: string
 }
 
@@ -497,12 +447,18 @@ export interface AutoPmDeps {
    */
   optedOut?(): Promise<readonly string[]>
   /**
-   * The open entries of a project's agent queue, in file order. Empty = the queue has run dry, and
-   * a rejection = it could not be read, which fails closed exactly as the old boolean did (#855).
-   * The entries themselves rather than just emptiness, because a batch of drains is pinned one
-   * entry each (#1204) and the assignment has to come from the read the decision was made on.
+   * The local head of the project's `agent-data` branch (#1774), or `undefined` when the branch
+   * does not exist yet. Read after the daemon's data pull, so it says what other machines and the
+   * agents pushed.
+   */
+  dataHead(project: AutoPmProject): Promise<string | undefined>
+  /**
+   * How many commits between two heads of the branch were written by something other than a
+   * daemon (#1774): a person queuing an entry, an agent claiming or closing a ticket. The daemon's
+   * own writes — a run's record, a routine lock, a claim — carry a trailer and are not counted,
+   * or every record would start the next run.
    */
-  queue(project: AutoPmProject): Promise<readonly string[]>
+  foreignCommits(project: AutoPmProject, from: string, to: string): Promise<number>
   /**
    * The agents live on a project, one label each (#1646) — the run's id and pid, as the daemon
    * holds them. Their number is what the cap is measured against; their names are what the
@@ -526,10 +482,10 @@ export interface AutoPmDeps {
    * projects on two models can stand at two different places against the same reading.
    */
   quota(project: AutoPmProject): Promise<QuotaBoundaryStatus | undefined>
-  /** The jobs to rotate through, in cycle order. Used only while the queue is empty. */
+  /** The jobs to rotate through, in cycle order. Used once a run found nothing queued. */
   jobs: readonly AutoPmJob[]
-  /** The job for a queue with open entries (#855); {@link AUTO_PM_DRAIN_JOB} by default. */
-  drainJob?: AutoPmJob
+  /** The job for the queued work (#1774); {@link AUTO_PM_WORK_JOB} by default. */
+  workJob?: AutoPmJob
   /**
    * Whether a project is due its periodic codebase sweep (#882). Injected rather than computed
    * here because the schedule lives in a file in the project checkout, and this module is pure
@@ -541,7 +497,7 @@ export interface AutoPmDeps {
   recordMaintenance?(project: AutoPmProject): Promise<void>
   /** The job fired when {@link AutoPmDeps.maintenanceDue} says yes; {@link AUTO_PM_MAINTENANCE_JOB} by default. */
   maintenanceJob?: AutoPmJob
-  /** Start the PM agent. Resolves the agent's id, or undefined when the daemon refused. */
+  /** Start the agent. Resolves the agent's id, or undefined when the daemon refused. */
   start(project: AutoPmProject, job: AutoPmJob): Promise<string | undefined>
   /**
    * Take a job's {@link AutoPmJob.lock} before its run starts (#1659): `routines/<lock>.lock.md`
@@ -563,11 +519,11 @@ export interface AutoPmDeps {
    */
   releaseDeadLocks?(project: AutoPmProject): Promise<unknown>
   /**
-   * Settle a finished agent's queue entry (#852/#1582): the daemon retires the entry it pinned to
-   * the run once the run's ending says the work was published. Called before the sweep decides
-   * anything, so an entry whose run just landed stops reading as open work to start over again.
+   * Whether an agent this loop started has finished (#852/#1583), and how its handoff ended.
+   * Asked before the sweep decides anything, so a run that just ended is closed out first: its
+   * routine lock released, a claim it abandoned freed, the rotation's turn earned.
    */
-  promote(project: AutoPmProject, agent: { agentId: string; entry?: string }): Promise<PromoteOutcome>
+  settled(project: AutoPmProject, agent: { agentId: string }): Promise<SettleOutcome>
   /**
    * The tickets open for planning (#1327): no plan or `.lock.md` claim yet (#1420) — most
    * important first, as filenames inside `tickets/`. Asked only when the tick lands on a
@@ -589,26 +545,12 @@ export interface AutoPmDeps {
     project: AutoPmProject,
     assignments: readonly PlanAssignment[],
   ): Promise<readonly PlanAssignment[]>
-  /**
-   * Claim the tickets a drain batch is about to implement (#1420), the same way
-   * {@link AutoPmDeps.lockPlans} claims them for planning — one pushed `.lock.md` per ticket —
-   * but skipping only on an existing lock: a `.plan.md` is the drain's input, not a competing
-   * claim. Asked only for the entries that link back to a ticket; a self-contained TODO has
-   * nothing on disk to lock and keeps the queue document as its coordination point. Resolves the
-   * subset actually locked — an entry whose ticket was claimed elsewhere is dropped from the
-   * batch, and the next tick reconsiders it. Absent, drains run exactly as before this seam:
-   * the in-memory pin still guards this daemon's own fan-out.
-   */
-  lockDrains?(
-    project: AutoPmProject,
-    assignments: readonly PlanAssignment[],
-  ): Promise<readonly PlanAssignment[]>
   /**
    * Free a claim this loop minted whose agent settled with nothing to hand off (#1583): the
    * lock's normal release is the agent's own PR deleting it, and a run whose handoff skipped as
-   * `no-commits` is never opening one — without this the queue livelocks on the dead claim until
-   * a human clicks Release. Keyed off the run's recorded ending, never a timer (#1420). Only the
-   * exact minted claim is freed — the callee leaves a lock naming anyone else alone.
+   * `no-commits` is never opening one — without this the planning livelocks on the dead claim
+   * until a human clicks Release. Keyed off the run's recorded ending, never a timer (#1420).
+   * Only the exact minted claim is freed — the callee leaves a lock naming anyone else alone.
    *
    * Resolves `true` when the claim is dealt with (freed, already gone, or someone else's), and
    * `false` when the release could not land — a transient `index.lock`, say — so the loop holds
@@ -622,6 +564,8 @@ export interface AutoPmDeps {
   intervalMs?: number
   /** Override the per-project cooldown. */
   cooldownMs?: number
+  /** Override {@link DEFAULT_AUTO_PM_HEARTBEAT_MS}. */
+  heartbeatMs?: number
   /** Clock, injectable for tests. */
   now?: () => number
 }
@@ -672,26 +616,28 @@ export interface AutoPmLoop {
    * `onDemand` marks a sweep a person explicitly asked for (#1210's trigger button). The `autoPm`
    * preference is consent to spend quota *unasked*, and a click is asking — so an on-demand sweep
    * runs with the preference off. It skips the cooldown for the same reason (#1642): the cooldown
-   * paces the unattended sweep, and for half an hour after any run it made Run now a button that
-   * could start nothing. Every other reason to stand down (live agents, the quota boundary,
-   * unticked routines) still holds.
+   * paces the unattended rotation, and for half an hour after any run it made Run now a button
+   * that could start nothing. Every other reason to stand down (live agents, the quota boundary,
+   * unticked routines) still holds. A plain on-demand sweep starts the queued work when the branch
+   * moved, else the rotation's next job: the click is the ask, so it does not wait for a run to
+   * have found nothing.
    *
-   * `only` narrows the sweep to one routine's work (#1204), for a Run now that fans out:
+   * `only` narrows the sweep to one routine's work (#1204), for a Run now on a routine's row:
    *
-   * - `'drain'` — the drain row's Run now means "spin agents up on the queue", so a tick that
-   *   would fall through to a rotation job (the queue is empty) says so instead of borrowing the
-   *   click for work nobody asked for.
-   * - `'plan'` — the same for the one rotation job that fans out ({@link AutoPmJob.fansOut}).
-   *   Its Run now used to be a plain single start, so the concurrency setting was the one thing
-   *   that click ignored; narrowing here reaches the same claim-then-start path the rotation
-   *   takes, locks included.
+   * - `'work'` — the queued-work row's Run now means "start an agent on the queue now", whether
+   *   or not the daemon saw the branch move; a tick that has nothing queued spends one run finding
+   *   that out, which is what the click asked for.
+   * - `'plan'` — the one rotation job that fans out ({@link AutoPmJob.fansOut}). Its Run now
+   *   used to be a plain single start, so the concurrency setting was the one thing that click
+   *   ignored; narrowing here reaches the same claim-then-start path the rotation takes, locks
+   *   included.
    * - `{ lock }` — the rotation job holding that lock ({@link AutoPmJob.lock}), for a triage's Run
    *   now (#1643/#1659). One agent, like the rotation's own firing, but through the sweep so the
    *   lock is taken before the start — a plain start would run unguarded.
    *
    * `projectId` scopes the sweep to one project, which is what a Run now fired from a card with a
    * project picked means. Absent, every project the daemon watches is visited, which is what the
-   * drain row's Run now says it does.
+   * queued-work row's Run now says it does.
    */
   tick(opts?: { onDemand?: boolean; only?: AutoPmOnly; projectId?: string }): Promise<void>
   /** What the last sweep decided, for the dashboard to show (#1161). */
@@ -700,21 +646,21 @@ export interface AutoPmLoop {
 }
 
 /**
- * Which routine's work a narrowed sweep is for (#1204/#1643). `'drain'` and `'plan'` are the
- * fan-out kinds: a drain takes one entry *off* the queue and a pinned plan agent writes one
- * ticket's own sibling files, so several agents do disjoint work. `{ lock }` names a rotation
- * job by the lock it holds ({@link AutoPmJob.lock}): one agent is all it can use, and the lock
- * that guards it is the sweep's to take (#1659) — a Run now that started it outside the sweep
- * would run unguarded. Keyed on the lock rather than the job's name for the same
+ * Which routine's work a narrowed sweep is for (#1204/#1643). `'work'` is the queued work
+ * (#1774) and `'plan'` the fan-out that writes one ticket's own sibling files per agent. `{ lock }`
+ * names a rotation job by the lock it holds ({@link AutoPmJob.lock}): one agent is all it can
+ * use, and the lock that guards it is the sweep's to take (#1659) — a Run now that started it
+ * outside the sweep would run unguarded. Keyed on the lock rather than the job's name for the same
  * no-name-matching reason the job carries the property at all: the card sends whatever the job
  * it renders declares. A rotation job that neither fans out nor holds a lock has nothing to
  * narrow to — a plain start is exactly what it is.
  */
-export type AutoPmOnly = 'drain' | 'plan' | { lock: string }
+export type AutoPmOnly = 'work' | 'plan' | { lock: string }
 
 /**
- * Start the auto-PM sweep (#685): every {@link DEFAULT_AUTO_PM_INTERVAL_MS}, ask
- * {@link autoPmDecision} for each project and start an agent for the ones that say yes.
+ * Start the auto-PM sweep (#685): every {@link DEFAULT_AUTO_PM_INTERVAL_MS}, look at each
+ * project's `agent-data` branch, ask {@link autoPmDecision}, and start an agent for the projects
+ * that say yes.
  *
  * Ticks never overlap — a sweep reads a live-agent map that its own `start` calls mutate,
  * so a second sweep running over the first would decide against a stale picture.
@@ -725,31 +671,49 @@ export type AutoPmOnly = 'drain' | 'plan' | { lock: string }
 export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
   const now = deps.now ?? (() => Date.now())
   const intervalMs = deps.intervalMs ?? DEFAULT_AUTO_PM_INTERVAL_MS
+  const heartbeatMs = deps.heartbeatMs ?? DEFAULT_AUTO_PM_HEARTBEAT_MS
   const startedAt = now()
   // What the last sweep decided, for `report()`. Undefined only in the moment before the
   // start-up sweep below lands.
   let lastSweep: { enabled: boolean; sweptAt: number; outcomes: AutoPmOutcome[] } | undefined
+  // When the rotation last started an agent per project: what the cooldown is measured from.
   const lastStart = new Map<string, number>()
-  // Runs this loop started whose queue has not reached the checkout yet, oldest first. A drain
-  // remembers the entry it was pinned to (#1204), and a fanned-out plan agent its ticket (#1327), so
-  // while either is still in flight a later tick does not hand the same work to a second agent.
-  // The claim rides along (#1583) so a run that settles with nothing to hand off gets the lock
-  // minted for it released rather than stranded; `waits` counts the sweeps spent holding a
-  // finished run whose epilogue has not reported yet, so the hold is bounded.
-  type PendingAgent = { agentId: string; entry?: string; ticket?: string; claim?: PlanAssignment; lock?: string; waits?: number }
+  // The head of each project's `agent-data` branch as this loop last saw it (#1774). Seeded on the
+  // first look and never fired on: a daemon that just started knows nothing about what moved
+  // while it was down, and the heartbeat is the belt for that.
+  const seen = new Map<string, string>()
+  // Projects whose branch moved by a commit no daemon wrote since the last start on the queued
+  // work. Consumed by that start, and by nothing else: a rotation start leaves it standing.
+  const moved = new Set<string>()
+  // Projects owed a rotation turn (#1774): the last run this loop started there ended without
+  // moving the branch — it found nothing queued — so the queue wants refilling. Also every project
+  // on its first look, which is the rotation's start-up turn a daemon has always taken.
+  const rotationDue = new Set<string>()
+  // When the queued work was last started per project, for the daily heartbeat. Seeded at the
+  // first look, so the first heartbeat is a day after the daemon started.
+  const lastWork = new Map<string, number>()
+  // Runs this loop started that have not settled yet, oldest first. A fanned-out plan agent
+  // remembers its ticket (#1327), so while it is still in flight a later tick does not hand the
+  // same ticket to a second agent; the claim rides along (#1583) so a run that settles with
+  // nothing to hand off gets the lock minted for it released rather than stranded; `waits` counts
+  // the sweeps spent holding a finished run whose epilogue has not reported yet, so the hold is
+  // bounded.
+  type PendingAgent = { agentId: string; ticket?: string; claim?: PlanAssignment; lock?: string; waits?: number }
   const pending = new Map<string, PendingAgent[]>()
-  // Work this loop already spawned an agent for that ended with nothing to hand off (#1583): the
-  // drain's entry, or the plan agent's ticket. Releasing such a claim re-opens the work, and a
-  // job that deterministically ends commitless would otherwise respawn every cooldown, forever,
-  // burning a quota run per cycle. One attempt per daemon lifetime: a restart forgets the set,
-  // which allows one more try rather than forbidding the work for good — a human retires or
-  // fixes the entry in between.
+  // Tickets whose plan agent ended with nothing to hand off (#1583). Releasing such a claim
+  // re-opens the work, and a job that deterministically ends commitless would otherwise respawn
+  // every cooldown, forever, burning a quota run per cycle. One attempt per daemon lifetime: a
+  // restart forgets the set, which allows one more try rather than forbidding the work for good —
+  // a human retires or fixes the ticket in between.
   const endedDry = new Map<string, Set<string>>()
   // Where each project is in the job cycle. Per project, not global: two repos idle at once
   // should each work through the rotation, not take alternate halves of it.
   const nextJob = new Map<string, number>()
   // Projects this loop has swept at least once, for the one-time boot release above.
   const swept = new Set<string>()
+  // The last sentence said per project, so a stand-down that holds for a day is logged once, not
+  // once a minute: the loop looks every minute now (#1774), and the log is a person's to read.
+  const lastSaid = new Map<string, string>()
   let sweeping = false
   let stopped = false
 
@@ -758,9 +722,18 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
     sweeping = true
     let enabled = false
     const outcomes: AutoPmOutcome[] = []
-    // Every branch that logs also records, so the panel says exactly what the log says.
-    const note = (project: AutoPmProject, started: boolean, message: string) =>
+    // Every branch that logs also records, so the panel says exactly what the log says. A start
+    // is always logged; a stand-down only when it is news.
+    const note = (project: AutoPmProject, started: boolean, message: string) => {
       outcomes.push({ projectId: project.id, path: project.path, started, message })
+      if (started) {
+        lastSaid.delete(project.id)
+        return
+      }
+      if (lastSaid.get(project.id) === message) return
+      lastSaid.set(project.id, message)
+      deps.log(`[framework] auto PM: standing down for ${project.path} — ${message}`)
+    }
     try {
       // The preference is the cheapest gate and the one the user flips most, so it is read
       // once per sweep rather than per project. An on-demand sweep outranks it — the click is
@@ -796,15 +769,31 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
           swept.add(project.id)
           await deps.releaseDeadLocks?.(project).catch(() => undefined)
         }
-        // Settle the runs a previous sweep started before judging the queue: a finished drain's
-        // entry is taken off the queue here, and a claim its agent abandoned is freed.
+        // The one reading this loop acts on (#1774): the branch's head, against the head it last
+        // saw. The first look only remembers it — and owes the rotation its start-up turn, which
+        // a daemon has always taken. A later look that finds a commit no daemon wrote is a move.
+        const head = await deps.dataHead(project).catch(() => undefined)
+        if (head === undefined) {
+          note(project, false, 'the agent-data branch could not be read, so there is no way to tell whether anything moved')
+          continue
+        }
+        const was = seen.get(project.id)
+        if (was === undefined) {
+          seen.set(project.id, head)
+          rotationDue.add(project.id)
+          lastWork.set(project.id, now())
+        } else if (head !== was) {
+          seen.set(project.id, head)
+          if ((await deps.foreignCommits(project, was, head).catch(() => 0)) > 0) moved.add(project.id)
+        }
+        // Close out the runs a previous sweep started before deciding: a finished routine's lock
+        // is released, a claim its agent abandoned is freed, and a run that ended without moving
+        // the branch earns the rotation its turn.
         const outstanding = pending.get(project.id) ?? []
         if (outstanding.length) {
           const stillPending: PendingAgent[] = []
-          let landed = 0
           for (const agent of outstanding) {
-            const outcome = await deps.promote(project, agent).catch((): PromoteOutcome => ({ settled: false, promoted: false }))
-            if (outcome.promoted) landed++
+            const outcome = await deps.settled(project, agent).catch((): SettleOutcome => ({ settled: false }))
             if (!outcome.settled) {
               stillPending.push(agent)
               continue
@@ -812,11 +801,9 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
             // The run ended cleanly but its epilogue has not reported yet — `end` lands before
             // the handoff event does — and the ending is the one fact the release keys off, so a
             // claim-carrying agent caught in that gap is held a couple more sweeps rather than
-            // settled blind. Bounded, so a process that died mid-epilogue cannot pin its queue
-            // entry forever; past the bound it settles unread, which is the pre-#1583 behavior.
-            // Held for the entry's check-off too (#1582): retiring a drained entry keys off the
-            // same reported ending the claim release does.
-            if ((agent.claim || agent.entry !== undefined) && outcome.handoffPending && (agent.waits ?? 0) < 2) {
+            // settled blind. Bounded, so a process that died mid-epilogue cannot hold its claim
+            // forever; past the bound it settles unread, which is the pre-#1583 behavior.
+            if (agent.claim && outcome.handoffPending && (agent.waits ?? 0) < 2) {
               stillPending.push({ ...agent, waits: (agent.waits ?? 0) + 1 })
               continue
             }
@@ -828,7 +815,7 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
               // Remembered before the release, not after: respawning the same work is the hazard
               // whether or not the release lands.
               const dry = endedDry.get(project.id) ?? new Set()
-              dry.add(agent.entry ?? agent.claim.ticket)
+              dry.add(agent.claim.ticket)
               endedDry.set(project.id, dry)
               const ok = await deps.releaseLock(project, agent.claim).catch(() => false)
               if (!ok && (agent.waits ?? 0) < 2) {
@@ -845,61 +832,24 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
           }
           if (stillPending.length) pending.set(project.id, stillPending)
           else pending.delete(project.id)
-          if (landed) {
-            // The queue the decision below reads was just filled, so that read is stale. Leave it
-            // to the next tick, and let the backlog loop have the work in the meantime.
-            deps.log(`[framework] auto PM: landed the queue from ${landed} run(s) in ${project.path}`)
-            note(project, false, `landed the queue from ${landed} finished run${landed === 1 ? '' : 's'}`)
-            continue
-          }
+          // The chain's end (#1774): every run this loop started has ended, and none of them
+          // moved the branch — the last one found nothing queued. The queue wants refilling, so
+          // the rotation gets the next turn. While a run is still going its commits may yet
+          // arrive, so the judgement waits for it.
+          if (!stillPending.length && !moved.has(project.id)) rotationDue.add(project.id)
         }
-        const entries = await deps.queue(project).catch(() => undefined)
         // Per project, because the model the work would run on is (#1619). It costs no reading:
         // the meter is polled elsewhere and this only measures the last one against the boundary.
         const quota = await deps.quota(project).catch(() => undefined)
         const running = deps.activeAgents(project)
         const activeAgents = running.length
-        const since = lastStart.get(project.id)
-        const decision = autoPmDecision({
-          enabled: true,
-          backlogEmpty: entries === undefined ? undefined : entries.length === 0,
-          activeAgents,
-          running,
-          concurrency,
-          quota,
-          ...(since !== undefined ? { sinceLastStartMs: now() - since } : {}),
-          ...(deps.cooldownMs !== undefined ? { cooldownMs: deps.cooldownMs } : {}),
-          ...(opts?.onDemand ? { onDemand: true } : {}),
-        })
-        if (!decision.start) {
-          // Logged, so a wedged sweep is distinguishable from a healthy idle one (#855).
-          deps.log(`[framework] auto PM: standing down for ${project.path} — ${decision.reason}`)
-          note(project, false, decision.reason)
-          continue
-        }
-        const drainJob = wanted(deps.drainJob ?? AUTO_PM_DRAIN_JOB)
-        // A drain-only sweep (#1204) works the queue or says why not — it never borrows the
-        // click for a rotation job the user did not ask for. Logged like every other stand-down
-        // (#855/#1433): these two used to be the only silent ones.
-        if (opts?.only === 'drain') {
-          if (decision.mode !== 'drain') {
-            deps.log(`[framework] auto PM: standing down for ${project.path} — the queue is empty, so there is nothing to drain`)
-            note(project, false, 'the queue is empty, so there is nothing to drain')
-            continue
-          }
-          if (!drainJob) {
-            deps.log(`[framework] auto PM: standing down for ${project.path} — the queue has work waiting and its routine is switched off`)
-            note(project, false, 'the queue has work waiting and its routine is switched off')
-            continue
-          }
-        }
+        const workJob = wanted(deps.workJob ?? AUTO_PM_WORK_JOB)
         // The planning routine this click asked for, read off the *enabled* rotation so an
         // unticked box stands the click down instead of firing a routine the card shows as off.
         // `fansOut` rather than a name, for the same no-name-matching reason the job carries the
         // property at all.
         const planJob = opts?.only === 'plan' ? rotation.find(item => item.fansOut) : undefined
         if (opts?.only === 'plan' && !planJob) {
-          deps.log(`[framework] auto PM: standing down for ${project.path} — the planning routine is switched off`)
           note(project, false, 'the planning routine is switched off')
           continue
         }
@@ -912,52 +862,71 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
         const lockedJob = lock === undefined ? undefined : rotation.find(item => item.lock === lock)
         if (lock !== undefined && !lockedJob) {
           const off = deps.jobs.find(item => item.lock === lock)
-          const reason = off ? `${off.label ?? off.name} is switched off` : `no routine holds the ${lock} lock`
-          deps.log(`[framework] auto PM: standing down for ${project.path} — ${reason}`)
-          note(project, false, reason)
+          note(project, false, off ? `${off.label ?? off.name} is switched off` : `no routine holds the ${lock} lock`)
+          continue
+        }
+        // The queued-work row's Run now (#1204/#1774): the click asks for an agent on the queue,
+        // and gets that or the reason not.
+        if (opts?.only === 'work' && !workJob) {
+          note(project, false, 'the routine that works the queue is switched off')
           continue
         }
         // The one routine the click named, when it named one: it takes the tick outright below.
-        const named = planJob ?? lockedJob
+        const named = planJob ?? lockedJob ?? (opts?.only === 'work' ? workJob : undefined)
         /**
-         * What this tick does, which is the queue-picked mode (#855) unless the draining routine
-         * is switched off — then the rotation gets the tick instead of the sweep standing down.
-         *
-         * #1209 means "do not *work* the queue", and the rotation does not work it: triage and
-         * planning put entries *on* it. Standing down here read that switch as "do nothing at
-         * all", which made every inventing routine unreachable for as long as the queue had
-         * anything on it — and since the queue is auto-populated, that is most of the time. The
-         * only way to reach `Spike & plan` was to empty the queue by hand (#1432).
-         *
-         * A drain-only sweep never gets here: it has already stood down above, because the click
-         * that fires it asked for the queue specifically.
+         * What this tick does (#1774). The queued work, when the branch moved by a commit no
+         * daemon wrote, or when the daily heartbeat is due; else the rotation, when a run found
+         * nothing queued (or on the first look, or on a click); else nothing. With the queued-work
+         * routine switched off, a move is the rotation's turn instead: #1209 means "do not work
+         * the queue", and the rotation does not work it — triage and planning put entries on it.
+         * Standing down there would make every inventing routine unreachable for as long as the
+         * queue had anything on it (#1432).
          */
-        // A click that named a routine is never a drain, however full the queue is: the queue-picked
-        // mode would otherwise send it to work entries instead of the routine it asked for.
-        const mode: 'pm' | 'drain' = named ? 'pm' : decision.mode === 'drain' && !drainJob ? 'pm' : decision.mode
+        const heartbeat = now() - (lastWork.get(project.id) ?? now()) >= heartbeatMs
+        const asked = moved.has(project.id) || heartbeat
+        if (asked && !workJob) rotationDue.add(project.id)
+        const work = named === undefined && asked && workJob !== undefined
+        if (!named && !work && !rotationDue.has(project.id) && !opts?.onDemand) {
+          note(project, false, 'nothing moved on the agent-data branch since the last run')
+          continue
+        }
+        // The rotation is paced by the cooldown; a move of the branch and a click are asks, and
+        // the queued work is never paced (#1774): the daemon fires again as the run ends.
+        const since = lastStart.get(project.id)
+        const decision = autoPmDecision({
+          enabled: true,
+          activeAgents,
+          running,
+          concurrency,
+          quota,
+          ...(!work && !named && since !== undefined ? { sinceLastStartMs: now() - since } : {}),
+          ...(deps.cooldownMs !== undefined ? { cooldownMs: deps.cooldownMs } : {}),
+          ...(opts?.onDemand ? { onDemand: true } : {}),
+        })
+        if (!decision.start) {
+          note(project, false, decision.reason)
+          continue
+        }
         const index = nextJob.get(project.id) ?? 0
         // A due codebase sweep (#882) outranks the rotation: the rotation invents work, and the
-        // sweep is a standing instruction to go find some. Only ever while the queue is empty --
-        // a repo with entries waiting has plenty to do, and the sweep would only add more.
+        // sweep is a standing instruction to go find some. Only ever on a rotation turn -- a
+        // project whose branch moved has plenty to do, and the sweep would only add more.
         //
         // Asked before the schedule is read, so a switched-off sweep costs no disk read and,
         // more importantly, leaves its calendar untouched: it must come due normally once it is
         // switched back on, rather than having been silently ticked past while it was off.
-        // `decision.mode`, not the effective `mode` above: the question here is whether the queue
-        // is genuinely empty, and a tick that fell through to the rotation because draining is
-        // switched off still has entries waiting — exactly the case this sweep stays out of.
         const maintenanceJob = wanted(deps.maintenanceJob ?? AUTO_PM_MAINTENANCE_JOB)
         // Never on a click that named a routine: that click takes the tick outright below, so the
         // sweep does not run — and a schedule stamped for a sweep that never ran postpones the
         // real one a whole interval. Asked first, so such a click also costs no schedule read.
         const sweep =
           !named &&
-          decision.mode === 'pm' &&
+          !work &&
           maintenanceJob !== undefined &&
           (await deps.maintenanceDue?.(project).catch(() => false)) === true
         // The routine a click named outranks both the calendar and the rotation index: it asked for
         // that one, so neither a due codebase sweep nor whose turn it is may take its tick.
-        const job = named ?? (sweep ? maintenanceJob : mode === 'drain' ? drainJob : rotation[index % rotation.length])
+        const job = named ?? (work ? workJob : sweep ? maintenanceJob : rotation[index % rotation.length])
         if (!job) {
           // Told apart on purpose: a rotation emptied by the checkboxes is a setting the user can
           // see and undo, and reads nothing like a daemon wired without jobs at all.
@@ -968,90 +937,29 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
           )
           continue
         }
-        // What to start this tick (#1204/#1327). Draining fans out, and so does a rotation job
-        // that declares {@link AutoPmJob.fansOut} — the property both share is what each agent
-        // does to shared files: a drain takes one entry *off* the queue, a pinned plan agent writes
-        // one ticket's *own* sibling files, so several agents do disjoint work and land disjoint
-        // edits. Every other rotation job rewrites the whole queue document from the same fork
-        // point, so two at once would revert each other's promotion; those stay one per tick.
+        // What to start this tick. The queued work is one agent per move (#1774): the agent's own
+        // claim moves the branch again, and a cap with room starts the next one alongside it. A
+        // rotation job that declares {@link AutoPmJob.fansOut} fans out (#1327): a pinned plan
+        // agent writes one ticket's *own* sibling files, so several agents do disjoint work and
+        // land disjoint edits. Every other rotation job rewrites the whole queue document from
+        // the same fork point, so two at once would revert each other's promotion; those stay one
+        // per tick.
         const batch: AutoPmJob[] = [job]
-        if (mode === 'drain') {
-          // An entry an agent still in flight was pinned to is not offered again.
-          const assigned = new Set(
-            (pending.get(project.id) ?? []).flatMap(agent => (agent.entry !== undefined ? [agent.entry] : [])),
-          )
-          // An entry someone else already worked is not on the queue to begin with (E2): the
-          // check-off travels in that agent's own PR, and the merge is what takes it off. A third
-          // claim used to be re-derived here — from agent metas, their PRs, and the queue diffs of
-          // open PRs on other machines — which is a guess assembled at read time rather than a
-          // claim anyone wrote down.
-          // An entry whose agent already ended with nothing to hand off (#1583) is not offered
-          // again either: its released claim would just mint the same commitless run every
-          // cooldown. A human retires or reshapes the entry; a daemon restart allows one retry.
-          const dry = endedDry.get(project.id)
-          const open = (entries ?? []).filter(entry => !assigned.has(entry) && !dry?.has(entry))
-          if (!open.length) {
-            note(
-              project,
-              false,
-              (entries ?? []).some(entry => dry?.has(entry))
-                ? 'every open queue entry is being worked on, or already drained once with nothing to hand off'
-                : 'every open queue entry is already being worked on',
-            )
-            continue
-          }
-          const picks = open.slice(0, concurrency - activeAgents)
-          // The cross-machine claim on what a drain *implements* (#1420): an entry that links
-          // back to a ticket (#1164) gets its `.lock.md` before its agent starts, the same
-          // pushed claim planning already makes — without it the booking lived only in this
-          // daemon's `pending` map, and another machine's sweep could implement the same ticket.
-          // A ticketless entry has nothing on disk to lock and proceeds as before. Ids are minted
-          // here, before the claim (#1748): the lock names the agent that is about to start.
-          const ids = mintAgentIds(now(), picks.length)
-          const linked = new Map(
-            picks.flatMap((entry, i) => {
-              const ticket = ticketFromQueueEntry(entry)
-              return ticket ? [[entry, { ticket: ticket.slice(TICKETS_DIR.length + 1), agentId: ids[i]! }] as const] : []
-            }),
-          )
-          // Matched back by agent id, not ticket: two entries linking the same ticket race for
-          // one lock, and only the assignment whose id the lock actually names may carry it.
-          const locked = new Set(
-            deps.lockDrains && linked.size
-              ? (await deps.lockDrains(project, [...linked.values()]).catch(() => [])).map(a => a.agentId)
-              : [],
-          )
-          batch.length = 0
-          batch.push(
-            ...picks.flatMap(entry => {
-              const assignment = linked.get(entry)
-              // No seam wired means no claim to carry: the entry drains exactly as before #1420.
-              if (!assignment || !deps.lockDrains) return [pinnedDrainJob(job, entry)]
-              // A lost race costs this batch the entry, not the batch: the claim that won it is
-              // pushed, so the check-off will arrive in that agent's own PR.
-              return locked.has(assignment.agentId) ? [pinnedDrainJob(job, entry, assignment)] : []
-            }),
-          )
-          if (!batch.length) {
-            note(project, false, 'every entry in this batch links a ticket another agent already claimed')
-            continue
-          }
-        } else if (job.fansOut && deps.planCandidates && deps.lockPlans) {
+        if (!job.works && job.fansOut && deps.planCandidates && deps.lockPlans) {
           // The fan-out for a rotation job that writes per-ticket files (#1327). Both seams or
           // neither: candidates without locks would fan out unguarded, which is exactly the
           // double-work the locks exist to prevent — so a loop wired without them keeps the
           // stock single agent already in the batch.
           //
-          // A ticket an agent still in flight was pinned to is not offered again, same as a drain's
-          // entry. The durable half is the lock files themselves: unlike drain entries, the claim
-          // is on disk and pushed, so no #1253-style meta lookup is needed here.
+          // A ticket an agent still in flight was pinned to is not offered again. The durable
+          // half is the lock files themselves: the claim is on disk and pushed, so no meta lookup
+          // is needed here.
           const pinned = new Set(
             (pending.get(project.id) ?? []).flatMap(agent => (agent.ticket !== undefined ? [agent.ticket] : [])),
           )
           const candidates = ((await deps.planCandidates(project).catch(() => [])) ?? []).filter(
-            // A ticket whose plan agent already ended with nothing to hand off (#1583) is skipped
-            // for the same reason a drained-dry entry is: its released claim respawns the same
-            // commitless run forever.
+            // A ticket whose plan agent already ended with nothing to hand off (#1583) is skipped:
+            // its released claim respawns the same commitless run forever.
             ticket => !pinned.has(ticket) && !endedDry.get(project.id)?.has(ticket),
           )
           if (!candidates.length) {
@@ -1080,9 +988,11 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
         // missing from the live-agent map the daemon has by then cleared, so nothing suspends or
         // terminates it (#983). Break, not continue: stopping is a verdict on the whole sweep.
         if (stopped) break
-        // Armed before the first spawn and once for the whole batch: starting is slow, and a tick
-        // that overlapped the spawns would otherwise see too few live agents and top up past the cap.
-        lastStart.set(project.id, now())
+        // The rotation's cooldown is armed before the first spawn and once for the whole batch:
+        // starting is slow, and a tick that overlapped the spawns would otherwise see too few live
+        // agents and top up past the cap. The queued work arms nothing: its next start needs a
+        // move of the branch, which is a better guard than a clock.
+        if (!job.works) lastStart.set(project.id, now())
         const started: AutoPmJob[] = []
         let standDown: string | undefined
         for (const item of batch) {
@@ -1094,7 +1004,6 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
           if (item.lock && deps.lockRoutine) {
             const taken = await deps.lockRoutine(project, item.lock).catch((): { ok: false; reason: string } => ({ ok: false, reason: 'the routine lock could not be taken' }))
             if (!taken.ok) {
-              deps.log(`[framework] auto PM: standing down for ${project.path} — ${taken.reason}`)
               standDown = taken.reason
               break
             }
@@ -1110,12 +1019,11 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
             break
           }
           started.push(item)
-          // Held until a later tick settles it: the entry it drains stays pinned meanwhile.
+          // Held until a later tick settles it: the ticket it plans stays pinned meanwhile.
           pending.set(project.id, [
             ...(pending.get(project.id) ?? []),
             {
               agentId,
-              ...(item.entry !== undefined ? { entry: item.entry } : {}),
               ...(item.ticket !== undefined ? { ticket: item.ticket } : {}),
               ...(item.claim !== undefined ? { claim: item.claim } : {}),
               ...(item.lock !== undefined ? { lock: item.lock } : {}),
@@ -1125,24 +1033,34 @@ export function startAutoPm(deps: AutoPmDeps): AutoPmLoop {
         // A claim whose agent never started is dead on arrival (#1583): the batch's locks were
         // committed and pushed before the first spawn, so a refused start — or a stop mid-batch —
         // would strand the claims of every item the loop never reached, with no run that could
-        // ever settle them free. Released here, not left for the promote loop: these never enter
+        // ever settle them free. Released here, not left for the settle loop: these never enter
         // `pending`.
         for (const item of batch) {
           if (item.claim && !started.includes(item)) await deps.releaseLock?.(project, item.claim).catch(() => false)
         }
         if (started.length) {
-          // Advanced only on a start that took, so a refused job is retried rather than skipped.
-          // Draining does not advance it: it is not part of the cycle, and a queue worked off
-          // over several ticks must not skip the rotation forward once per entry.
-          //
-          // A sweep does not advance it either, and stamps its own schedule instead: it is paced
-          // by the calendar, not the cycle, so borrowing this tick must not cost the rotation its
-          // turn. Stamped after the start took for the same reason the rotation is -- a sweep the
-          // daemon refused should be retried next tick, not postponed a whole interval.
-          // A click that named a routine does not advance it either, for the reason a sweep does
-          // not: it borrows the tick for that routine, so the rotation keeps the turn it was on.
-          if (sweep) await deps.recordMaintenance?.(project).catch(() => {})
-          else if (mode === 'pm' && !named) nextJob.set(project.id, index + 1)
+          if (job.works) {
+            // The move is spent (#1774): the next start on the queued work needs the branch to
+            // move again — which the agent's own commits do, as the run ends. The rotation's turn
+            // is spent too: whether the queue wants refilling is for this run to find out.
+            moved.delete(project.id)
+            rotationDue.delete(project.id)
+            lastWork.set(project.id, now())
+          } else {
+            // Advanced only on a start that took, so a refused job is retried rather than skipped.
+            //
+            // A sweep does not advance it, and stamps its own schedule instead: it is paced
+            // by the calendar, not the cycle, so borrowing this tick must not cost the rotation its
+            // turn. Stamped after the start took for the same reason the rotation is -- a sweep the
+            // daemon refused should be retried next tick, not postponed a whole interval.
+            // A click that named a routine does not advance it either, for the reason a sweep does
+            // not: it borrows the tick for that routine, so the rotation keeps the turn it was on.
+            if (sweep) await deps.recordMaintenance?.(project).catch(() => {})
+            else if (!named) nextJob.set(project.id, index + 1)
+            // The turn the rotation was owed is taken; the next is earned by a run that finds
+            // nothing queued, never by a rotation run's own ending.
+            rotationDue.delete(project.id)
+          }
           // One line per project however many agents went out, and a single start keeps the old
           // wording exactly.
           const described = started.map(item => doing(item)).join('; ')
diff --git a/packages/framework/src/await-gate.ts b/packages/framework/src/await-gate.ts
index e18391047..231d18f03 100644
--- a/packages/framework/src/await-gate.ts
+++ b/packages/framework/src/await-gate.ts
@@ -5,8 +5,7 @@ import type { ChatMessage, AgentMessages } from './agent-messages.js'
 
 // The shared await/choice/chat machinery (#304/#337/#339/#714), lifted out of the agent
 // lifecycle so the build path (run.ts), the direct prompt path (prompt-run.ts), and the
-// backlog loop (todo-loop.ts) can all reach it without importing the orchestrator — which is
-// what removed the agent <-> todo-loop cycle. run.ts composes these primitives into a lifecycle;
+// build path can all reach it without importing the orchestrator. run.ts composes these primitives into a lifecycle;
 // it does not own them.
 
 /** What a resolved gate yields. */
@@ -22,7 +21,7 @@ export interface GateAnswer {
  * prompt: emits the `choice`, parks for the pick (or the headless/abort fallback), and maps the
  * picked id(s) back to label(s). Round 0 keeps a stable gate id; later rounds get a unique one so
  * a dashboard never confuses a re-ask with the answer it just resolved. Shared by the build's
- * `agentAwaitGate`, the direct prompt path, and the backlog loop (#323).
+ * `agentAwaitGate` and the direct prompt path.
  *
  * One path, where there were four. A gate that takes several picks answers with the labels it got
  * (or `(none)`); every other gate answers with the one label picked. What used to distinguish an
@@ -208,7 +207,7 @@ export async function runChatPhase(session: DriverSession, messages: AgentMessag
  * messages (#714) rather than finishing.
  *
  * Every turn here is a turn like any other, so each one's signals are emitted. That is the
- * point of sharing this: the direct prompt path and the backlog loop each had their own copy
+ * point of sharing this: the direct prompt path and the build path each had their own copy
  * of these rounds, and the emission had to be added to each by hand (#563).
  */
 export async function runAwaitRounds(opts: AwaitRoundsOptions): Promise<AwaitRoundsResult> {
diff --git a/packages/framework/src/cli.test.ts b/packages/framework/src/cli.test.ts
index 37df0821b..af8a7c8f7 100644
--- a/packages/framework/src/cli.test.ts
+++ b/packages/framework/src/cli.test.ts
@@ -114,9 +114,8 @@ test('the session spec is what carries a session, and it round-trips through age
   assert.equal(o.research, false)
 })
 
-test('the backlog loop runs unless the spec says otherwise (#323)', () => {
-  assert.equal(opts().todoLoop, true)
-  // Unattended (#846): off unless asked, so an ordinary agent still parks its gates for the human.
+test('unattended is off unless the spec asks for it (#846)', () => {
+  // Off unless asked, so an ordinary agent still parks its gates for the human.
   assert.equal(opts().unattended, undefined)
   assert.equal(opts({ options: { unattended: true } }).unattended, true)
 })
@@ -224,15 +223,11 @@ test('runOnBeforeMergeable materializes the presets so the queued filePaths reso
   assert.ok(fs.files.has(join('/work/app', '.the-framework/presets/security_audit.md')))
 })
 
-test('the ticket a session implements is re-checked, since it comes off a file an agent wrote (#1117)', () => {
-  assert.equal(opts({ options: { ticket: 'tickets/2026-07-25_login.md' } }).ticket, 'tickets/2026-07-25_login.md')
-  assert.equal(opts().ticket, undefined) // nothing said = no particular ticket
-  for (const bad of ['tickets/../etc/passwd', '/etc/passwd', 'TODO_AGENTS.md', '']) {
-    assert.equal(opts({ options: { ticket: bad } }).ticket, undefined, `expected ${bad} to be dropped`)
-  }
-  // A planning agent says so (#1327): it is what keeps its PR title from inheriting the ticket's
-  // issue as `(fix #42)` and closing it with the work still undone.
+test('a planning agent says so (#1327)', () => {
+  // What keeps a closing phrase in its pull request from closing the ticket's issue with the work
+  // still undone.
   assert.equal(opts({ options: { planAgent: true } }).planAgent, true)
+  assert.equal(opts().planAgent, undefined)
 })
 
 test('transparent is unset by default (#625)', () => {
diff --git a/packages/framework/src/cli.ts b/packages/framework/src/cli.ts
index 9b90fc32e..6dffff29f 100644
--- a/packages/framework/src/cli.ts
+++ b/packages/framework/src/cli.ts
@@ -28,11 +28,9 @@ import {
   type AgentKind,
 } from './agent.js'
 import { FAKE_INTENT, fakeDriver } from './fake-script.js'
-import { isTicketPath, ticketIssueRef } from '@gemstack/skill-tickets'
 import { isHandsOff, isAgentLocation, type AgentLocation } from './agent-location.js'
 import { handoffStages, isHandoffLevel, type HandoffLevel } from './handoff-level.js'
 import { readAgentSpec, removeAgentSpec, writeAgentSpec, type AgentSpec } from './agent-spec.js'
-import { agentTodoPending } from './todo-loop.js'
 import { loadFrameworkConfig, type FrameworkFileConfig } from './config.js'
 import {
   describeResolvedConfig,
@@ -44,7 +42,7 @@ import {
 import { loadUserSystemPrompt, SYSTEM_PROMPT_FILE } from './system-prompt-file.js'
 import { checkForUpdate, formatUpdateStatus, nodeVersionFetcher, type VersionFetcher } from './update-check.js'
 import { AgentStore, nodeStoreFs, type StoreFs } from './store/index.js'
-import { nodeGitRunner, readBranchFile, DATA_BRANCH } from '@gemstack/agent-data'
+import { nodeGitRunner } from '@gemstack/agent-data'
 import { currentBranch, agentBranchName, sessionNameOf } from '@gemstack/skill-branches'
 import { materializePresets } from './presets.js'
 import { isLoopbackHost, registerHomeProject, runDaemon, DEFAULT_DAEMON_HOST, DEFAULT_DAEMON_PORT } from './daemon.js'
@@ -199,9 +197,7 @@ export interface AgentOptions {
   model?: string | undefined
   /** Continue a finished agent's agent session (#720) — the prompt resumes that conversation (full prior context). Set by the dashboard when you message an agent that has ended. */
   resumeSession?: string | undefined
-  /** The `tickets/<file>.md` this agent is implementing (#1117). Set by the daemon when it starts a drain agent, from the ticket its queue entry links to; recorded on the agent's meta. */
-  ticket?: string | undefined
-  /** The {@link ticket} is being planned, not implemented (#1327), so the PR title must not inherit its issue as `(fix #42)` (#1334) — the plan's merge would close the issue with the work still undone. */
+  /** This agent plans a ticket rather than implementing it (#1327), so its pull request must not close the ticket's issue (#1334) — the plan's merge would close the issue with the work still undone. */
   planAgent?: boolean
   /** No human is watching (#846), so choice gates take the recommended option. */
   unattended?: boolean
@@ -227,7 +223,6 @@ export interface AgentOptions {
    * to `pr` — which is what makes the handoff zero-config.
    */
   handoff?: HandoffLevel | undefined
-  todoLoop: boolean
   /** Whether the session records itself to `.the-framework/`. Always true outside tests. */
   persist: boolean
   /** {@link AgentSpec.kind} `research`: run the Research preset as a direct prompt (#331). */
@@ -311,7 +306,6 @@ const SESSION_DEFAULTS = {
   onBeforeMergeable: false,
   browser: false,
   persist: true,
-  todoLoop: true,
 } as const
 
 /**
@@ -339,9 +333,6 @@ export function agentOptions(spec: AgentSpec, env: NodeJS.ProcessEnv = process.e
     ...(isAgentLocation(o.target) ? { target: o.target } : {}),
     ...(o.model?.trim() ? { model: o.model.trim() } : {}),
     ...(o.resumeSession?.trim() ? { resumeSession: o.resumeSession.trim() } : {}),
-    // The ticket comes off a queue file an agent writes, so it is re-checked here rather than
-    // trusted: a path that is not a ticket never reaches the agent (#1117).
-    ...(o.ticket && isTicketPath(o.ticket) ? { ticket: o.ticket } : {}),
     ...(o.planAgent ? { planAgent: true } : {}),
     ...(o.unattended ? { unattended: true } : {}),
     ...(defined(o.vanilla) ? { vanilla: o.vanilla } : {}),
@@ -649,7 +640,7 @@ export function createAgentJournal(deps: {
     // The agent names its branch in its own shell (#1725), invisibly to this process until it
     // looks: at the end of every turn, read the branch again so the dashboard's label follows the
     // name without waiting for the agent to end. Every path — a build, its await rounds, the chat,
-    // the backlog loop — ends its turns with the driver's result.
+    // the build path — ends its turns with the driver's result.
     if (event.kind === 'driver' && event.event.type === 'result') void observeBranch()
   }
 
@@ -853,7 +844,7 @@ async function driveAgent(opts: AgentOptions, io: CliIO): Promise<number> {
 
   // Continuing a build agent (#1467): the composer's Resume always arrives as a `prompt` start,
   // but the reopened meta remembers the flow the first leg ran. When it was a build agent and the
-  // conversation is resumable, re-enter the build flow (synthesize framing, backlog loop, the
+  // conversation is resumable, re-enter the build flow (synthesize framing, the
   // build ending) with the message sent verbatim — not the bare prompt ending that used to
   // downgrade a resumed build agent. Runs from before the meta recorded a kind stay on the prompt
   // path, exactly as they did.
@@ -906,14 +897,8 @@ async function driveAgent(opts: AgentOptions, io: CliIO): Promise<number> {
           armedHandoff = 'merge'
           mergeAuthorized = true
           announceHandoff?.()
-          // A session parked on the backlog offer (#323) is waiting to know whether to take more
-          // work. Merge answers that: wrap up now. Other gates keep waiting — they are questions
-          // about the work itself, which merging does not answer.
-          for (const [id, resolve] of pendingChoices) {
-            if (!/^todo-next(-\d+)?$/.test(id)) continue
-            pendingChoices.delete(id)
-            resolve({ picked: 'stop', by: 'user' })
-          }
+          // Parked gates keep waiting: they are questions about the work itself, which merging
+          // does not answer.
           return
         }
         const resolve = pendingChoices.get(entry.id)
@@ -989,10 +974,6 @@ async function driveAgent(opts: AgentOptions, io: CliIO): Promise<number> {
   // run that is set to merge. Derived from the rung, so the three can never contradict it.
   announceHandoff = () => onEvent({ kind: 'handoff-armed', ...handoffStages(armedHandoff) })
   announceHandoff()
-  // The ticket this agent implements (#1117), if the daemon named one. Once, at start: it is a fact
-  // about why the agent exists, not a state that changes, and folding it to meta is what lets the
-  // Overview mark that ticket as being implemented right now.
-  if (opts.ticket && isTicketPath(opts.ticket)) onEvent({ kind: 'ticket', path: opts.ticket })
   // The branch this agent actually starts on (#1277): recorded, not guessed, so surfaces reading
   // the meta mid-run resolve the same name teardown will later confirm.
   await journal.observeBranch()
@@ -1035,45 +1016,31 @@ async function driveAgent(opts: AgentOptions, io: CliIO): Promise<number> {
 
     // The merge half is authorized, not just configured (#1363; rule settled on #1390): the
     // agent's setReadyForMerge() — the same signal maybeFireOnBeforeMergeable requires above —
-    // is what says the work may land unattended, plus the session's own TODO file having no
-    // open entries. Never the global TODO_AGENTS.md: the queue is decoupled from sessions.
-    // Withheld is not skipped — push and PR go ahead, and with `armed.merge` off the PR opens
-    // as a draft for a human. Said on the handoff event (#835), or "auto-merge was on and
-    // nothing merged" has no answer.
+    // is what says the work may land unattended. Withheld is not skipped — push and PR go ahead,
+    // and with `armed.merge` off the PR opens as a draft for a human. Said on the handoff event
+    // (#835), or "auto-merge was on and nothing merged" has no answer.
     // A human's Merge action (#1391) bypasses the gate: the authorization the gate exists to
     // collect has been given directly, by someone who outranks the signal.
     let mergeGate: MergeWithheldReason | undefined
     if (armed.merge && !mergeAuthorized) {
-      const ready = journal.sawReadyForMerge()
-      mergeGate = withheldMerge({
-        readyForMerge: ready,
-        agentTodoOpen: ready && (await agentTodoPending(cwd, journal.sessionName())),
-      })
+      mergeGate = withheldMerge({ readyForMerge: journal.sawReadyForMerge() })
       if (mergeGate) armed.merge = false
     }
 
     // The branch as it is now, not as it was named at start: the agent renames it (#1725), and
     // the rename is exactly what the PR should be opened against. Read once for the whole
-    // epilogue, before the merge gate above asked for the session name.
+    // epilogue.
     const branch = journal.branch()
     if (!branch) return skip('branch-gone')
-    // The ticket's GitHub issue rides the PR title as `(fix #42)` (#1334): the squash-merge
-    // subject inherits the title, so the merge closes the issue — without it, an auto-merged
-    // quick-win leaves its ticket open. Not on a plan agent (#1327): its PR lands the plan, not
-    // the work, so the merge must not close the issue. Best-effort: a ticket that cannot be
-    // read fixes nothing. Read off the `agent-data` branch (#1582) — the worktree holds no tickets.
-    const fixes = opts.ticket && isTicketPath(opts.ticket) && !opts.planAgent
-      ? ticketIssueRef((await readBranchFile(cwd, DATA_BRANCH, opts.ticket).catch(() => undefined)) ?? '')
-      : undefined
     // The agent's own description of the work (#1567), when it wrote one: this is what an
     // `open-pr` block is for — the agent describes the change and the framework opens the PR,
-    // so it has no reason to run `gh pr create` itself and lose the title convention, the
-    // ticket's issue reference, and the recorded number along the way.
+    // so it has no reason to run `gh pr create` itself and lose the title convention and the
+    // recorded number along the way. The ticket's issue is the agent's to name (#1774): the
+    // framework no longer knows which ticket a run implements.
     //
     // A plan agent's description is defused first: its PR lands the plan, not the work, so a
     // closing phrase in it would close the ticket's issue on merge — which is exactly what
-    // happened on #1560. The same reasoning already keeps `(fix #N)` off a plan agent's title
-    // just above; the description is the other half of the same rule.
+    // happened on #1560.
     const written = journal.pullRequest()
     // Both halves are defused, not just the body: since #1618 the title is the agent's prose too,
     // and a closing phrase there would ride the squash-merge subject straight into the issue.
@@ -1084,7 +1051,6 @@ async function driveAgent(opts: AgentOptions, io: CliIO): Promise<number> {
       id: opts.agentId ?? '',
       branch,
       ...(intent ? { intent } : {}),
-      ...(fixes ? { fixes } : {}),
       ...(prTitle ? { prTitle } : {}),
       ...(description ? { description } : {}),
     }
@@ -1295,7 +1261,6 @@ async function driveAgent(opts: AgentOptions, io: CliIO): Promise<number> {
     // Resume the stopped leg's conversation (#720/#1467); the prompt above is the continuation
     // message, which `runAgent` then sends verbatim.
     ...(opts.resumeSession ? { resumeSessionId: opts.resumeSession } : {}),
-    ...(opts.todoLoop && !transparent ? {} : { todoLoop: false }),
   }
 
   return settleAgent(epilogue(label), async () => {
@@ -1442,7 +1407,7 @@ export type PromptRunner = (prompt: string, cwd: string, binPath: string) => Pro
 /**
  * Fire the built-in on-before-mergeable (#326) prompt after an agent signalled setReadyForMerge(): one
  * `framework prompt` child on the same workspace that appends the quality follow-ups to the
- * session's TODO file, for the backlog loop (#323/#538) to pick up.
+ * session's TODO file (#323/#538).
  *
  * It used to run maintainability, readability and security-audit inline instead, as three
  * child runs back to back (#556). Queueing is both what the doc says and the cheaper thing:
diff --git a/packages/framework/src/client.ts b/packages/framework/src/client.ts
index 6d0c75e18..4004ecd9e 100644
--- a/packages/framework/src/client.ts
+++ b/packages/framework/src/client.ts
@@ -41,10 +41,11 @@ export { presets, LAUNCHER_PRESETS, type PresetKey } from './preset-catalog.js'
 // the server's queue write, so the plan column's start, the queued entry, and the dedupe that
 // recognizes a queued copy all carry the exact same sentence (#1187).
 export { planTicketPrompt } from './tickets.js'
-// The routines the idle sweep fires (#1159), so the dashboard can list them and run one on demand.
-// The jobs are built from the presets above and carry their prompt verbatim, so this needs no
-// backend of its own, and the list on screen is the list the daemon runs rather than a copy of it.
-export { AUTO_PM_ROUTINES, AUTO_PM_JOBS, AUTO_PM_DRAIN_JOB, AUTO_PM_MAINTENANCE_JOB, type AutoPmJob } from './auto-pm.js'
+// The routines the daemon fires (#1159), so the dashboard can list them and run one on demand.
+// The jobs carry their prompt verbatim — the presets above, or the routine skill's slash command
+// (#1774) — so this needs no backend of its own, and the list on screen is the list the daemon
+// runs rather than a copy of it.
+export { AUTO_PM_ROUTINES, AUTO_PM_JOBS, AUTO_PM_WORK_JOB, AUTO_PM_MAINTENANCE_JOB, type AutoPmJob } from './auto-pm.js'
 // The identity + diff both notifier paths run, and the preference defaults both sides read (#627).
 // Pure, so the dashboard shares them rather than keeping copies that drift silently.
 export { interventionKey, activityKey } from './dashboard/keys.js'
diff --git a/packages/framework/src/daemon-runtime.test.ts b/packages/framework/src/daemon-runtime.test.ts
index 96e9f6bf6..192e521bb 100644
--- a/packages/framework/src/daemon-runtime.test.ts
+++ b/packages/framework/src/daemon-runtime.test.ts
@@ -1,8 +1,13 @@
 import { strict as assert } from 'node:assert'
 import { test } from 'node:test'
 import { spawn } from 'node:child_process'
-import { terminate, waitOutFinishedLeg, waitOutSlots, type FinishedLegState } from './daemon-runtime.js'
+import { readFileSync } from 'node:fs'
+import { join } from 'node:path'
+import { childEnv, ROUTINE_SKILLS, terminate, waitOutFinishedLeg, waitOutSlots, type FinishedLegState } from './daemon-runtime.js'
 import { isPidAlive } from './store/index.js'
+import { AGENT_ID_ENV } from './agent-id.js'
+import { WORK_QUEUE_SKILL_NAME } from './auto-pm.js'
+import { DAEMON_URL_ENV } from './dashboard/web-start-endpoints.js'
 
 const sleep = (ms: number): Promise<void> => new Promise(resolve => setTimeout(resolve, ms))
 
@@ -219,3 +224,23 @@ test('terminate reaps the whole process group of an agent that ignores SIGTERM,
     }
   }
 })
+
+// What a spawned agent is handed (#1774): its own id, and nothing on its PATH. The skills'
+// commands resolve from the project's own dependencies, as each skill's SKILL.md says.
+
+test('a spawned agent gets its id as AGENT_ID and no PATH entries of the daemon (#1774)', () => {
+  const base = { PATH: '/usr/bin:/bin', HOME: '/home/me' }
+  const env = childEnv('http://127.0.0.1:4200', '2026-09-13T10-00-00-000Z', base)
+  assert.equal(env['PATH'], '/usr/bin:/bin', 'the PATH is the daemon\'s own, untouched')
+  assert.equal(env[AGENT_ID_ENV], '2026-09-13T10-00-00-000Z')
+  assert.equal(env[DAEMON_URL_ENV], 'http://127.0.0.1:4200')
+  // No id: the fallback agent in the project checkout is nobody in particular.
+  assert.equal(childEnv(undefined, undefined, base)[AGENT_ID_ENV], undefined)
+})
+
+test('the routine skill the daemon links into every checkout is the work-queue skill file (#1774)', () => {
+  assert.deepEqual(ROUTINE_SKILLS.map(s => s.name), [WORK_QUEUE_SKILL_NAME])
+  const skill = readFileSync(join(ROUTINE_SKILLS[0]!.dir, 'SKILL.md'), 'utf8')
+  assert.match(skill, /^---\nname: work-queue\n/, 'the front matter names the skill the daemon fires')
+  assert.match(skill, /\ndisable-model-invocation: true\n/, 'only a person or the daemon invokes it')
+})
diff --git a/packages/framework/src/daemon-runtime.ts b/packages/framework/src/daemon-runtime.ts
index b7d0ad2df..87743c952 100644
--- a/packages/framework/src/daemon-runtime.ts
+++ b/packages/framework/src/daemon-runtime.ts
@@ -1,13 +1,15 @@
 import { spawn, type ChildProcess } from 'node:child_process'
 import { closeSync, mkdirSync, openSync } from 'node:fs'
-import { basename, delimiter, dirname, join, resolve } from 'node:path'
+import { basename, dirname, join, resolve } from 'node:path'
+import { fileURLToPath } from 'node:url'
 import { appendFile, mkdir, readFile, rm, stat, writeFile } from 'node:fs/promises'
 import { agentIdFromStartedAt, startedAtFromAgentId, readWorktreeAgent, restoreArchivedAgent, listAgents, findAgent, archivedAgentPaths, readLiveMetas, readLiveMeta, resolveAgentEventsPath, EVENTS_FILE, META_FILE, isPidAlive, toRunCard, diaryOf, fromDiaryLine, type AgentMeta } from './store/index.js'
 import { isGitRepo, nodeGitRunner, isGitTimeout } from '@gemstack/agent-data'
-import { createCheckout, attachCheckout, agentBranchName, worktreePath, worktreeBranch, removeWorktree, pruneWorktrees, agentIdFromWorktreeDir, CLI_BIN_DIR as BRANCHES_BIN_DIR } from '@gemstack/skill-branches'
-import { isTicketPath, CLI_BIN_DIR as TICKETS_BIN_DIR, SKILL_DIR as TICKETS_SKILL_DIR, SKILL_NAME as TICKETS_SKILL_NAME, AGENT_ID_ENV } from '@gemstack/skill-tickets'
-import { CLI_BIN_DIR as QUEUE_BIN_DIR, SKILL_DIR as QUEUE_SKILL_DIR, SKILL_NAME as QUEUE_SKILL_NAME } from '@gemstack/skill-queue'
-import { CLI_BIN_DIR as LOGS_BIN_DIR, SKILL_DIR as LOGS_SKILL_DIR, SKILL_NAME as LOGS_SKILL_NAME, writeRun, type AnyDiaryLine } from '@gemstack/skill-logs'
+import { createCheckout, attachCheckout, agentBranchName, worktreePath, worktreeBranch, removeWorktree, pruneWorktrees, agentIdFromWorktreeDir, type SkillLink } from '@gemstack/skill-branches'
+import { writeRun, type AnyDiaryLine } from '@gemstack/skill-logs'
+import { AGENT_ID_ENV } from './agent-id.js'
+import { WORK_QUEUE_SKILL_NAME } from './auto-pm.js'
+import { daemonFunnel } from './daemon-writes.js'
 import { THE_FRAMEWORK_DIR } from './framework-dir.js'
 import type { FrameworkEvent } from './events.js'
 import { removeAgentSpec, writeAgentSpec } from './agent-spec.js'
@@ -107,29 +109,31 @@ function spawnDetached(binPath: string, specPath: string, stderrFile?: string, e
 }
 
 /**
- * A spawned run's environment: ours, with the `branches`, `tickets`, `queue` and `logs` commands on
- * its PATH (#1725/#1748/#1769) — the agent names its session, checks its tree, reads and changes
- * the tickets and the queue, and reads past runs through the same packages the daemon does — its
- * id as `AGENT_ID`, so a claim it makes names the agent and not its branch, plus the daemon's URL
- * when it has one (#1328).
+ * A spawned run's environment: ours, with the agent's id as `AGENT_ID`, so a claim it makes names
+ * the agent and not its branch, plus the daemon's URL when it has one (#1328). Nothing is put on
+ * its PATH (#1774): a skill's command resolves from the project's own dependencies, `npx tickets`,
+ * as the skill's `SKILL.md` says.
  */
-function childEnv(daemonUrl: string | undefined, agentId: string | undefined, base: NodeJS.ProcessEnv = process.env): NodeJS.ProcessEnv {
-  const env: NodeJS.ProcessEnv = { ...base, PATH: [BRANCHES_BIN_DIR, TICKETS_BIN_DIR, QUEUE_BIN_DIR, LOGS_BIN_DIR, base['PATH']].filter(Boolean).join(delimiter) }
+export function childEnv(daemonUrl: string | undefined, agentId: string | undefined, base: NodeJS.ProcessEnv = process.env): NodeJS.ProcessEnv {
+  const env: NodeJS.ProcessEnv = { ...base }
   if (agentId) env[AGENT_ID_ENV] = agentId
   return daemonUrl ? { ...env, [DAEMON_URL_ENV]: daemonUrl } : env
 }
 
 /**
- * TEMPORARY (#1748): the `tickets`, `queue` and `logs` skills linked into every checkout beside the
- * `branches` skill, through the branches package's caller-given list. Gone when use-npm-skills
- * commits the skills into the repository, where a checkout carries them as tracked files.
+ * The routine skills the daemon fires (#1774), linked into every checkout it makes beside the
+ * `branches` skill, through the branches package's caller-given list: `skills/work-queue/SKILL.md`
+ * ships with this package, and the daemon starts the queued work with `/work-queue`. The skills
+ * an agent composes — tickets, queue, logs — are the project's own tracked files, not the daemon's
+ * to link.
  */
-const CHECKOUT_SKILLS = [
-  { name: TICKETS_SKILL_NAME, dir: TICKETS_SKILL_DIR },
-  { name: QUEUE_SKILL_NAME, dir: QUEUE_SKILL_DIR },
-  { name: LOGS_SKILL_NAME, dir: LOGS_SKILL_DIR },
+export const ROUTINE_SKILLS: readonly SkillLink[] = [
+  { name: WORK_QUEUE_SKILL_NAME, dir: fileURLToPath(new URL(`../skills/${WORK_QUEUE_SKILL_NAME}/`, import.meta.url)) },
 ]
 
+/** The daemon's signed write funnel to the data branch (`daemon-writes.ts`): the run's record is its own commit. */
+const funnel = daemonFunnel()
+
 /** Where a spawned agent's stderr lands (#1261), so a child that dies at boot leaves a trace. */
 export function agentStderrPath(cwd: string): string {
   return join(cwd, THE_FRAMEWORK_DIR, 'stderr.log')
@@ -495,7 +499,7 @@ export function createProjectRuntime({ cwd, env, binPath, retryDelayMs, driverPr
           // says which name it got; re-attaching by the birth branch would continue the agent on a
           // branch without its previous commits.
           const branch = agentBranchFor(archived ?? { id: agentId })
-          await attachCheckout(projectCwd, { agentId, branch, skills: CHECKOUT_SKILLS })
+          await attachCheckout(projectCwd, { agentId, branch, skills: ROUTINE_SKILLS })
         }
         await restoreArchivedAgent(projectCwd, path, agentId).catch(() => false)
         return { cwd: path, agentId }
@@ -555,9 +559,9 @@ export function createProjectRuntime({ cwd, env, binPath, retryDelayMs, driverPr
     agentId: string,
   ): Promise<{ ok: true; workspace: { cwd: string; agentId?: string } } | { ok: false; error: string }> => {
     try {
-      // The package's one sequence (#1725): the worktree, the parent's dependencies linked in,
-      // the branches view (#1580) told now rather than at the next tick.
-      const worktree = await createCheckout(projectCwd, { agentId, skills: CHECKOUT_SKILLS })
+      // The package's one sequence (#1725): the worktree, the parent's dependencies linked in, the
+      // routine skill linked in, the branches view (#1580) told now rather than at the next tick.
+      const worktree = await createCheckout(projectCwd, { agentId, skills: ROUTINE_SKILLS })
       return { ok: true, workspace: { cwd: worktree.path, agentId } }
     } catch (err) {
       if (await isGitRepo(projectCwd)) {
@@ -597,13 +601,15 @@ export function createProjectRuntime({ cwd, env, binPath, retryDelayMs, driverPr
         // the enclosing repo's branch, and the archive would record the user's `main` as the run's.
         const branch = await worktreeBranch(worktree)
         // Recorded as the `logs` skill's run on the data branch (#1179/#1582/#1769), under the
-        // identity this repo commits as, through the branch's write funnel: the record is committed
-        // and pushed the moment it lands — durable without a human, and never a commit on main.
-        // The card is the skill's shape with the rest of the meta under `caller`; the diary is the
-        // event log with the four kinds the skill knows mapped onto its lines.
+        // identity this repo commits as, through the daemon's signed write funnel: the record is
+        // committed and pushed the moment it lands — durable without a human, and never a commit
+        // on main — and its commit carries the daemon's trailer, so the sweep that watches the
+        // branch does not read the record as work (#1774). The card is the skill's shape with the
+        // rest of the meta under `caller`; the diary is the event log with the four kinds the
+        // skill knows mapped onto its lines.
         const run = await readWorktreeAgent(worktree, undefined, branch)
         if (run) {
-          const archived = await writeRun(projectCwd, toRunCard(run.meta), diaryOf(run.events))
+          const archived = await writeRun(projectCwd, toRunCard(run.meta), diaryOf(run.events), { funnel })
           if (!archived.ok && !archived.committed)
             console.log(`[framework] could not archive session ${basename(worktree)}: ${archived.error}`)
         }
diff --git a/packages/framework/src/daemon-services.test.ts b/packages/framework/src/daemon-services.test.ts
index 47377c271..1c46fd32f 100644
--- a/packages/framework/src/daemon-services.test.ts
+++ b/packages/framework/src/daemon-services.test.ts
@@ -1,40 +1,30 @@
 import { strict as assert } from 'node:assert'
 import { test } from 'node:test'
-import { mkdtemp, rm, writeFile, mkdir, readFile } from 'node:fs/promises'
+import { mkdtemp, rm, writeFile, mkdir } from 'node:fs/promises'
 import { tmpdir } from 'node:os'
 import { join } from 'node:path'
 import { execFile } from 'node:child_process'
 import { promisify } from 'node:util'
 import { startBackgroundServices, syncProjectData } from './daemon-services.js'
 import { projectErrorStore } from './project-errors.js'
-import { fileBranchPath, withFileBranch, DATA_BRANCH } from '@gemstack/agent-data'
+import { withFileBranch, DATA_BRANCH } from '@gemstack/agent-data'
 import { pollerQuotaSource, type QuotaSource } from './dashboard/quota.js'
 import { QuotaPoller } from './quota-poller.js'
+import { AUTO_PM_JOBS, AUTO_PM_MAINTENANCE_JOB, AUTO_PM_WORK_JOB } from './auto-pm.js'
+import { daemonFunnel } from './daemon-writes.js'
 import type { DriverQuotaWindow } from 'agent-driver'
 import type { StartAgentOptions, StartAgentResult } from './dashboard/types.js'
 
 /**
- * The concurrent-agents setting, end to end (#1204).
+ * The daemon half of #1774, end to end with the daemon's own spawn stubbed.
  *
- * `auto-pm.test.ts` covers the policy with every reading injected, which is the half that was
- * already known good. What was unverified is the wiring either side of it: that the number the
- * dashboard writes into the registry is the number `startBackgroundServices` hands the sweep, and
- * that a real checkout with a real `TODO_AGENTS.md` fans out to that many starts, one pinned entry
- * each. Both halves are real here — the registry is read off disk by `readPreferences`, the queue
- * off disk by `findTodoBacklog` — and only the daemon's own spawn is stubbed, because the assertion
- * is about how many agents are asked for and with what, not about the child processes.
+ * `auto-pm.test.ts` covers the policy with every reading injected. What was unverified is the
+ * wiring either side of it: that the two git reads the sweep is handed see a real `agent-data`
+ * branch move, that a commit written through the daemon's own funnel does not count as one, and
+ * that what the sweep starts is one agent told `/work-queue` and nothing else. Real git and a real
+ * registry; only the child process is stubbed, because the assertion is about what is asked for.
  */
 
-/** Six open entries, distinguishable, in the format the sweep's reader actually parses. */
-const QUEUE_ENTRIES = [
-  '[Entry one](tickets/2026-07-01_one.md) — the first thing',
-  '[Entry two](tickets/2026-07-01_two.md) — the second thing',
-  '[Entry three](tickets/2026-07-01_three.md) — the third thing',
-  '[Entry four](tickets/2026-07-01_four.md) — the fourth thing',
-  '[Entry five](tickets/2026-07-01_five.md) — the fifth thing',
-  '[Entry six](tickets/2026-07-01_six.md) — the sixth thing',
-]
-
 const git = promisify(execFile)
 
 /**
@@ -56,29 +46,24 @@ function weekResetText(): string {
   return `${month} ${resets.getUTCDate()} at 7am (UTC)`
 }
 
+/** Every routine but the queued work, so a test about the trigger sees only that one start. */
+const ROTATION_OFF = [...AUTO_PM_JOBS, AUTO_PM_MAINTENANCE_JOB].map(job => job.name)
+
 /** A registry + checkout wired to `startBackgroundServices`, with every start recorded. */
 async function services(preferences: Record<string, unknown>, quota?: QuotaSource) {
-  const config = await mkdtemp(join(tmpdir(), 'framework-concurrency-cfg-'))
-  const project = await mkdtemp(join(tmpdir(), 'framework-concurrency-proj-'))
-  // A real git checkout whose tickets and queue live on the data branch (#1582), because the
-  // drain claims each entry's ticket with a committed `.lock.md` before its agent starts (#1420)
-  // — in a bare directory that cycle would fail and the whole batch would be dropped.
+  const config = await mkdtemp(join(tmpdir(), 'framework-daemon-half-cfg-'))
+  const project = await mkdtemp(join(tmpdir(), 'framework-daemon-half-proj-'))
+  // A real git checkout with the data branch already born (#1582): the sweep's first look
+  // remembers its head, and the tests move it from there.
   await git('git', ['init', '-q', '-b', 'main'], { cwd: project })
   await git('git', ['config', 'user.email', 'test@example.com'], { cwd: project })
   await git('git', ['config', 'user.name', 'Test'], { cwd: project })
   await git('git', ['config', 'commit.gpgsign', 'false'], { cwd: project })
   const seeded = await withFileBranch(project, DATA_BRANCH, 'seed', async dir => {
     await mkdir(join(dir, 'tickets'), { recursive: true })
-    for (const entry of QUEUE_ENTRIES) {
-      const ticket = /\((tickets\/[^)]+)\)/.exec(entry)![1]!
-      await writeFile(join(dir, ticket), `# ${ticket}\n`)
-    }
-    await writeFile(
-      join(dir, 'TODO_AGENTS.md'),
-      ['# TODO_AGENTS', '', '## Priority 9', '', ...QUEUE_ENTRIES.map(entry => `- ${entry}`), ''].join('\n'),
-    )
+    await writeFile(join(dir, 'TODO_AGENTS.md'), '')
   })
-  assert.ok(seeded.ok, 'the fixture queue must land on the data branch')
+  assert.ok(seeded.ok, 'the data branch must exist before the daemon looks')
   await writeFile(
     join(config, 'the-framework.json'),
     JSON.stringify({
@@ -105,13 +90,20 @@ async function services(preferences: Record<string, unknown>, quota?: QuotaSourc
     projectErrors: projectErrorStore(),
     log: () => {},
   })
+  /** Someone queued an entry: a plain write through the skills' own funnel. */
+  const queue = async (entry: string) => {
+    const wrote = await withFileBranch(project, DATA_BRANCH, `queue add: ${entry}`, async dir => {
+      await writeFile(join(dir, 'TODO_AGENTS.md'), `- ${entry}\n`)
+    })
+    assert.ok(wrote.ok, 'the fixture entry must land on the data branch')
+  }
   const stop = async () => {
     // Awaited: the sweep in flight is what the cleanup below would otherwise delete out from under.
     await started.quiesce()
     await rm(config, { recursive: true, force: true })
     await rm(project, { recursive: true, force: true })
   }
-  return { starts, stop, services: started, projectDir: project }
+  return { starts, stop, services: started, projectDir: project, queue }
 }
 
 /** Poll until `check` holds or the deadline passes; the sweep is fired and not awaited. */
@@ -120,144 +112,71 @@ async function settle(check: () => boolean, ms = 5000): Promise<void> {
   while (!check() && Date.now() < deadline) await new Promise(resolve => setTimeout(resolve, 10))
 }
 
-test('the concurrency setting on disk is the number of agents the routine spins up (#1204)', async () => {
-  // Four, so a pass cannot be the shipped default of two or a hardwired one.
-  const { starts, stop, services: running, projectDir } = await services({ autoPm: true, autoPmConcurrency: 4 })
+test('a commit on the data branch that no daemon wrote starts one agent on the queued work (#1774)', async () => {
+  const { starts, stop, services: running, queue } = await services({ autoPm: true, autoPmConcurrency: 4, autoPmOptOut: ROTATION_OFF })
   try {
-    // No wake call: the daemon sweeps once on start-up, which is the path a machine booted with
-    // the setting already on actually takes.
-    await settle(() => starts.length >= 4)
-    assert.equal(starts.length, 4, 'the batch is the setting, not the default and not the queue length')
-    // One entry each, in queue order: this is what makes four agents do disjoint work rather than
-    // four copies of the first entry. The prompt is where the pin lives (E2) — it used to also
-    // ride the agent's meta, so a third claim mechanism could be re-derived from it later.
-    for (const [index, start] of starts.entries()) {
-      assert.match(start.prompt, /Work on this one open entry of the agent queue only/)
-      assert.ok(start.prompt.includes(QUEUE_ENTRIES[index]!), `the prompt pins ${QUEUE_ENTRIES[index]}`)
-      // Nobody is at the keyboard, so a gate must auto-answer rather than park (#846/#1279).
-      assert.equal(start.options.unattended, true)
-      // The drain job lands its own PRs (#1216): the job's flag rides the start as the ladder's
-      // top rung, so it reaches the agent already meaning "push, open, merge".
-      assert.equal(start.options.handoff, 'merge')
-      // A drain implements its ticket, so its PR title may close the issue — planAgent is only
-      // for the fanned-out planners (#1327), whose merge must not.
-      assert.equal(start.options.planAgent, undefined)
-      assert.equal(start.projectId, 'proj-1')
-    }
-    // The ticket the entry links to rides along, so the four agents land in four lanes (#1117).
-    assert.deepEqual(
-      starts.map(s => s.options.ticket),
-      ['tickets/2026-07-01_one.md', 'tickets/2026-07-01_two.md', 'tickets/2026-07-01_three.md', 'tickets/2026-07-01_four.md'],
-    )
-    // And the dashboard is told the batch went out, rather than only the first of it (#1161).
+    // The start-up look remembers the head and starts nothing: the daemon knows nothing about
+    // what moved while it was down.
+    await settle(() => running.autoPmReport().outcomes.length > 0)
+    assert.equal(starts.length, 0, 'the first look starts nothing on the queued work')
+    await queue('[Entry one](tickets/2026-07-01_one.md)')
+    await running.wakeAutoPm()
+    assert.equal(starts.length, 1, 'one agent per move, however high the concurrency: the next needs the branch to move again')
+    const [start] = starts
+    // The agent is told the routine skill and nothing else: no entry, no ticket, no skill name.
+    assert.equal(start!.prompt, AUTO_PM_WORK_JOB.prompt)
+    assert.equal(start!.prompt, '/work-queue')
+    // Nobody is at the keyboard, so a gate must auto-answer rather than park (#846/#1279).
+    assert.equal(start!.options.unattended, true)
+    // The queued work lands its own PRs (#1216): the job's flag rides the start as the ladder's
+    // top rung, so it reaches the agent already meaning "push, open, merge".
+    assert.equal(start!.options.handoff, 'merge')
+    assert.equal(start!.options.planAgent, undefined)
+    assert.equal(start!.options.agentId, undefined, 'the daemon minted no claim, so the run picks its own id')
+    assert.equal(start!.projectId, 'proj-1')
+    // And the dashboard is told what went out (#1161).
     const outcome = running.autoPmReport().outcomes[0]
     assert.equal(outcome?.started, true)
-    assert.match(outcome?.message ?? '', /started 4 agents/)
-    // The claim the sweep committed ahead of each agent (#1420/#1748): the ticket's lock is on
-    // the `agent-data` branch and names the id the agent is started with, so the lock and the run are one.
-    const lock = await readFile(join(fileBranchPath(projectDir, DATA_BRANCH), 'tickets/2026-07-01_one.lock.md'), 'utf8')
-    assert.match(lock, /^CLAIMED: \d{4}-\d{2}-\d{2}T/, "the first entry's ticket carries a claim naming an agent id")
-    assert.equal(starts[0]!.options.agentId, lock.slice('CLAIMED: '.length).trim(), 'and the agent is started with that id')
+    assert.equal(outcome?.message, AUTO_PM_WORK_JOB.label)
+    // The move is spent: the next look, with nothing new on the branch, starts nothing.
+    await running.wakeAutoPm()
+    assert.equal(starts.length, 1)
   } finally {
     await stop()
   }
 })
 
-test("the drain row's Run now fans out to the setting with auto-run off (#1204/#1210)", async () => {
-  const { starts, stop, services: running } = await services({ autoPm: false, autoPmConcurrency: 3 })
+test("a commit the daemon wrote itself is not a move: its run records must not start the next run (#1774)", async () => {
+  const { starts, stop, services: running, projectDir } = await services({ autoPm: true, autoPmOptOut: ROTATION_OFF })
   try {
-    // The start-up sweep reads the switch and stands down; the click is what asks.
-    await settle(() => starts.length > 0, 300)
-    assert.equal(starts.length, 0, 'auto-run off means the schedule starts nothing by itself')
-    // Exactly what the card's Run now sends for the draining routine, through the same
-    // `wakeAutoPm` seam the RPC calls.
-    running.wakeAutoPm({ onDemand: true, only: 'drain' })
-    await settle(() => starts.length >= 3)
-    assert.equal(starts.length, 3, 'the click spins the setting up, not one agent')
-    for (const [index, start] of starts.entries()) {
-      assert.ok(start.prompt.includes(QUEUE_ENTRIES[index]!), `the prompt pins ${QUEUE_ENTRIES[index]}`)
-    }
-  } finally {
-    await stop()
-  }
-})
-
-/** An archived meta in the transient `.the-framework/agents/`, where the promote poll reads it. */
-async function archiveMeta(projectDir: string, meta: { id: string } & Record<string, unknown>): Promise<void> {
-  const dir = join(projectDir, '.the-framework', 'agents')
-  await mkdir(dir, { recursive: true })
-  await writeFile(join(dir, `${meta.id}.json`), JSON.stringify({ startedAt: '2026-08-19T00:00:00.000Z', updatedAt: '2026-08-19T00:01:00.000Z', ...meta }))
-}
-
-test('a drained entry is taken off the queue once its run reports the work published (#1582/#1748)', async () => {
-  // The whole retire loop, with only the agent stubbed: the sweep pins the entry, the run's
-  // archived record reports the hand-off, and the daemon — the queue's one local writer — lands
-  // the removal as a commit on the `agent-data` branch. The agent never touches the queue.
-  const { starts, stop, services: running, projectDir } = await services({ autoPm: false, autoPmConcurrency: 1 })
-  try {
-    running.wakeAutoPm({ onDemand: true, only: 'drain' })
-    await settle(() => starts.length >= 1)
-    assert.ok(starts[0]!.prompt.includes(QUEUE_ENTRIES[0]!), 'the first entry is the pinned one')
-    // The run settles `done` and its epilogue reported the push/PR: the one ending that retires.
-    await archiveMeta(projectDir, { id: 'run-1', status: 'done', handoffReport: 'done' })
-    running.wakeAutoPm({ onDemand: true, only: 'drain' })
-    // Waited for on the branch, not the checkout file: the funnel writes the file first and
-    // commits a beat later, and only the commit is the retirement every machine pulls.
-    const deadline = Date.now() + 5000
-    let subjects = ''
-    while (Date.now() < deadline) {
-      subjects = await git('git', ['log', '--format=%s', `refs/heads/${DATA_BRANCH}`], { cwd: projectDir }).then(r => r.stdout, () => '')
-      if (subjects.includes('queue done: ')) break
-      await new Promise(resolve => setTimeout(resolve, 25))
-    }
-    assert.ok(subjects.includes(`queue done: ${QUEUE_ENTRIES[0]!}`), 'the removal is a commit on the `agent-data` branch')
-    const queue = await readFile(join(fileBranchPath(projectDir, DATA_BRANCH), 'TODO_AGENTS.md'), 'utf8')
-    assert.ok(!queue.includes(QUEUE_ENTRIES[0]!), 'the drained entry is deleted — done means deleted, not checked off')
-    // The fixture seeds bare bullets, and untouched ones must stay exactly as written.
-    assert.ok(queue.includes(`- ${QUEUE_ENTRIES[1]!}`), 'the untouched entries stay open')
-  } finally {
-    await stop()
-  }
-})
-
-test('a run whose hand-off failed leaves its entry open: unpublished work is not retired (#1582)', async () => {
-  // The negative half of the gate above, seen live in the PR smoke: the push or PR did not land
-  // (`handoffReport: 'failed'`), so the daemon settles the run without checking anything off —
-  // the entry stays open for the next drain rather than vanishing with the work unpublished.
-  const { starts, stop, services: running, projectDir } = await services({ autoPm: false, autoPmConcurrency: 1 })
-  try {
-    running.wakeAutoPm({ onDemand: true, only: 'drain' })
-    await settle(() => starts.length >= 1)
-    await archiveMeta(projectDir, { id: 'run-1', status: 'done', handoffReport: 'failed' })
-    running.wakeAutoPm({ onDemand: true, only: 'drain' })
-    // No positive signal marks "the promote settled without retiring", so give the tick a
-    // moment and then require the queue untouched — the check-off in the sibling test lands
-    // well inside this window when the gate passes.
-    await settle(() => false, 1500)
-    const queue = await readFile(join(fileBranchPath(projectDir, DATA_BRANCH), 'TODO_AGENTS.md'), 'utf8')
-    assert.ok(queue.includes(`- ${QUEUE_ENTRIES[0]!}`), "the failed run's entry stays open")
+    await settle(() => running.autoPmReport().outcomes.length > 0)
+    // The daemon's funnel, as the teardown's record write uses it: signed with the trailer.
+    const recorded = await daemonFunnel()(projectDir, 'logs: record run 2026-09-13T10-00-00-000Z', async dir => {
+      await mkdir(join(dir, 'agents', 'test'), { recursive: true })
+      await writeFile(join(dir, 'agents', 'test', '2026-09-13T10-00-00-000Z.json'), '{}\n')
+    })
+    assert.ok(recorded.ok)
+    await running.wakeAutoPm()
+    assert.equal(starts.length, 0)
+    // The rotation's start-up turn is still owed and has nothing to fire, which is what the
+    // report says; the record moved nothing.
+    assert.equal(running.autoPmReport().outcomes[0]?.message, 'every routine that makes new work is switched off')
   } finally {
     await stop()
   }
 })
 
-test('a drain claims an entry whose ticket file is gone, recreating tickets/ on the way (#1582)', async () => {
-  // The live-smoke regression: retiring the last ticket removes `tickets/` itself (git keeps no
-  // empty dirs), while the queue entry linking it stays open — a failed publish leaves exactly
-  // this state. The next drain must still claim and start, not stand the batch down with
-  // "another agent already claimed".
-  const { starts, stop, services: running, projectDir } = await services({ autoPm: false, autoPmConcurrency: 1 })
+test("the queued-work row's Run now starts one agent with auto-run off, and no move (#1204/#1210/#1774)", async () => {
+  const { starts, stop, services: running } = await services({ autoPm: false, autoPmConcurrency: 3 })
   try {
-    const cleared = await withFileBranch(projectDir, DATA_BRANCH, 'retire every ticket', async dir => {
-      await rm(join(dir, 'tickets'), { recursive: true, force: true })
-    })
-    assert.ok(cleared.ok, 'the fixture must drop tickets/ from the data branch')
-    running.wakeAutoPm({ onDemand: true, only: 'drain' })
-    await settle(() => starts.length >= 1)
-    assert.equal(starts.length, 1, 'the batch starts instead of standing down')
-    assert.ok(starts[0]!.prompt.includes(QUEUE_ENTRIES[0]!), 'the first entry is the pinned one')
-    const lock = await readFile(join(fileBranchPath(projectDir, DATA_BRANCH), 'tickets/2026-07-01_one.lock.md'), 'utf8')
-    assert.match(lock, /^CLAIMED: \d{4}-/, 'the claim landed in a recreated tickets/')
+    // The start-up sweep reads the switch and stands down; the click is what asks.
+    await settle(() => starts.length > 0, 300)
+    assert.equal(starts.length, 0, 'auto-run off means the schedule starts nothing by itself')
+    // Exactly what the card's Run now sends for the queued work, through the same `wakeAutoPm`
+    // seam the RPC calls.
+    await running.wakeAutoPm({ onDemand: true, only: 'work' })
+    assert.equal(starts.length, 1, 'the click is one agent on the queue, whatever the branch did')
+    assert.equal(starts[0]!.prompt, AUTO_PM_WORK_JOB.prompt)
   } finally {
     await stop()
   }
@@ -305,11 +224,11 @@ test("unattended work stands down when the model it would run on has spent its o
     { label: 'Current week (all models)', kind: 'week', percentUsed: 30, resetsAtText: weekResetText() },
     { label: 'Current week (Fable)', kind: 'week-model', percentUsed: 100, resetsAtText: weekResetText() },
   ])
-  const { starts, stop, services: running } = await services({ autoPm: true, autoPmConcurrency: 4, model: 'claude-fable-5' }, quota)
+  const { starts, stop, services: running, queue } = await services({ autoPm: true, model: 'claude-fable-5', autoPmOptOut: ROTATION_OFF }, quota)
   try {
-    // Waited on the sweep's own report rather than a bare delay: the assertion is that the pass ran
-    // and decided not to start, which a timeout could not tell from a pass that had not run yet.
     await settle(() => running.autoPmReport().outcomes.length > 0)
+    await queue('[Entry one](tickets/2026-07-01_one.md)')
+    await running.wakeAutoPm()
     assert.equal(starts.length, 0, 'a spent model week starts nothing, however much of the account week is left')
     // And it says which window stopped it: "the quota" alone would send someone to a panel that
     // is showing 30% and looking fine.
@@ -328,10 +247,12 @@ test('the same spent model week does not stop work on a model that has its own a
     { label: 'Current week (all models)', kind: 'week', percentUsed: 30, resetsAtText: weekResetText() },
     { label: 'Current week (Fable)', kind: 'week-model', percentUsed: 100, resetsAtText: weekResetText() },
   ])
-  const { starts, stop } = await services({ autoPm: true, autoPmConcurrency: 2, model: 'claude-opus-5' }, quota)
+  const { starts, stop, services: running, queue } = await services({ autoPm: true, model: 'claude-opus-5', autoPmOptOut: ROTATION_OFF }, quota)
   try {
-    await settle(() => starts.length >= 2)
-    assert.equal(starts.length, 2, 'the batch goes out as usual')
+    await settle(() => running.autoPmReport().outcomes.length > 0)
+    await queue('[Entry one](tickets/2026-07-01_one.md)')
+    await running.wakeAutoPm()
+    assert.equal(starts.length, 1, 'the run goes out as usual')
     assert.equal(starts[0]!.options.model, 'claude-opus-5', 'and on the model the gate was measured for')
   } finally {
     await stop()
diff --git a/packages/framework/src/daemon-services.ts b/packages/framework/src/daemon-services.ts
index 9bcf2c285..3edcbe9ef 100644
--- a/packages/framework/src/daemon-services.ts
+++ b/packages/framework/src/daemon-services.ts
@@ -16,16 +16,17 @@ import { startDaemonTick, DAEMON_TICK_MS } from './daemon-tick.js'
 import { ciFixPrompt, startCiWatch } from './ci-watch.js'
 import { acquireRoutineLock, releaseDeadRoutineLocks, releaseRoutineLock } from './routine-locks.js'
 import { maintenanceDue, readMaintenanceState, mergeMaintenanceState } from './maintenance.js'
-import { claimTickets, readTickets, releaseTicket, syncTickets, TICKETS_DIR, ticketFromQueueEntry, ticketsDir } from '@gemstack/skill-tickets'
-import { queueDone, readQueueEntries, syncQueue } from '@gemstack/skill-queue'
-import { nextQueuedTicket } from './todo-loop.js'
+import { claimTickets, readTickets, releaseTicket, TICKETS_DIR, ticketsDir } from '@gemstack/skill-tickets'
+import { DATA_BRANCH, pullFileBranch } from '@gemstack/agent-data'
+import { daemonFunnel, dataHead, foreignCommits } from './daemon-writes.js'
 import type { ProjectErrors } from './project-errors.js'
 import { readFile, writeFile } from 'node:fs/promises'
 import { startMergedWorktreeSweep, type MergedSweepOptions } from './merged-worktrees.js'
 import { reconcileBranchLinks } from '@gemstack/skill-branches'
 import { startProjectPass } from './project-pass.js'
 import { startCloudScratchSweep } from './cloud-scratch-refs.js'
-import { startCloudWorkAdoption } from './cloud-work.js'
+import { adoptCloudWork, startCloudWorkAdoption } from './cloud-work.js'
+import { patchRun } from '@gemstack/skill-logs'
 import { resolveAgentPr } from './dashboard/agent-handoff.js'
 import { sendChoice, sendMessage, sendStop } from './dashboard-rpc/control.js'
 import type { ProjectSummary } from './dashboard/projects.js'
@@ -49,7 +50,14 @@ import type { StartAgentOptions, StartAgentResult } from './dashboard/types.js'
  * wants between turns and `daemon-tick.ts` fires them.
  */
 
-/** Ticks between auto-PM sweeps, and between worktree sweeps: both are ten-minute jobs. */
+/** Ticks between worktree sweeps, branch-link passes and cloud work adoption: ten-minute jobs. */
+const TEN_MINUTES_EVERY = Math.round((10 * 60 * 1000) / DAEMON_TICK_MS)
+
+/**
+ * Ticks between auto-PM looks (#1774): one a minute, right behind the data pull, since what it
+ * looks at is the head that pull just brought in. A look costs one `git rev-parse`; a run only
+ * ever starts when the branch moved.
+ */
 const AUTO_PM_EVERY = Math.round(DEFAULT_AUTO_PM_INTERVAL_MS / DAEMON_TICK_MS)
 
 /**
@@ -117,15 +125,14 @@ export interface BackgroundServiceDeps {
 
 /**
  * One project's data-sync turn (#1599): converge the `agent-data` branch — the skills' branch,
- * which also carries the `logs` skill's runs and the routine locks — with origin (the `tickets`
- * skill's checkout, root link and pull, then the `queue` skill's seed and pull), and set or clear
- * the project's `data-sync` error by the outcome. The clear is unconditional on success, so the
- * error lives exactly as long as the condition — the next tick after the user fixes the remote,
- * it is gone.
+ * which carries the tickets, the queue, the `logs` skill's runs and the routine locks — with
+ * origin through the shared branch library, one pull, and set or clear the project's `data-sync`
+ * error by the outcome. The clear is unconditional on success, so the error lives exactly as long
+ * as the condition — the next tick after the user fixes the remote, it is gone. The daemon knows
+ * nothing of what is on the branch (#1774): a skill's own setup makes its files.
  */
 export async function syncProjectData(path: string, errors: ProjectErrors, log: (message: string) => void): Promise<void> {
-  const tickets = await syncTickets(path, { log })
-  const result = tickets.ok ? await syncQueue(path, { log }) : tickets
+  const result = await pullFileBranch(path, DATA_BRANCH, { log })
   if (result.ok) errors.clear(path, 'data-sync')
   else {
     log(`[framework] data sync: ${result.error}`)
@@ -198,12 +205,16 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
   const quotaFor = async (projectId: string) =>
     deps.quota.boundaryFor((await resolveProjectAgentOptions(projectId, env)).model)
 
-  // Auto PM (#685/#773): while the queue is dry and there is quota to spare, triage and
-  // plan tickets rather than let the day's allowance expire unused.
+  // Auto PM (#685/#773/#1774): while the `agent-data` branch moves and there is quota to spare,
+  // start an agent on the queued work; once a run finds nothing queued, triage and plan tickets
+  // rather than let the day's allowance expire unused.
+  // Every write the daemon makes on its own goes through one funnel that signs the commit
+  // (`daemon-writes.ts`), so the sweep's trigger can tell them from everyone else's.
+  const funnel = daemonFunnel()
   // The sweep's assignments name agent ids; the skill's claims name holders — the same string,
   // read back into the sweep's shape.
-  const claim = async (path: string, assignments: readonly PlanAssignment[], phase: 'plan' | 'drain'): Promise<PlanAssignment[]> => {
-    const locked = await claimTickets(path, assignments.map(a => ({ ticket: a.ticket, holder: a.agentId })), phase, { log })
+  const claim = async (path: string, assignments: readonly PlanAssignment[]): Promise<PlanAssignment[]> => {
+    const locked = await claimTickets(path, assignments.map(a => ({ ticket: a.ticket, holder: a.agentId })), 'plan', { log, funnel })
     return locked.map(c => ({ ticket: c.ticket, agentId: c.holder }))
   }
   const autoPm = startAutoPm({
@@ -213,9 +224,11 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
     // Which routines the user unticked (#1209). Global rather than per project, like the master
     // switch it sits under: the rotation is one schedule for the machine, not one per repo.
     optedOut: async () => (await prefs()).autoPmOptOut ?? [],
-    // The queue's open entries rather than a bare emptiness bit: a batch of concurrent drains is
-    // pinned one entry each (#1204), so the sweep needs the entries the decision was made on.
-    queue: project => readQueueEntries(project.path),
+    // The one thing the sweep reads (#1774): the branch's head, and how many of the commits since
+    // its last look were written by something other than a daemon. Both are git reads on the
+    // project's repository; the daemon holds no copy of the queue and names no skill.
+    dataHead: project => dataHead(project.path),
+    foreignCommits: (project, from, to) => foreignCommits(project.path, from, to),
     // One label per held slot (#1646): the run's id and its pid, so the sweep's stand-down and
     // fan-out lines name what they were measured against instead of a bare number.
     activeAgents: project => deps.activeAgentSlots(project.id).map(describeSlot),
@@ -234,22 +247,23 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
     // The routine lock (#1659): a pushed `routines/<name>.lock.md`, minted before the triage
     // starts and dropped by this daemon when its run ends. On boot, the locks a previous daemon
     // on this machine left go too, unless a run of this machine's started since is still going.
-    lockRoutine: (project, name) => acquireRoutineLock(project.path, name, { log }),
+    lockRoutine: (project, name) => acquireRoutineLock(project.path, name, { log, funnel }),
     releaseRoutine: async (project, name) => {
-      const ok = await releaseRoutineLock(project.path, name, { log })
+      const ok = await releaseRoutineLock(project.path, name, { log, funnel })
       if (ok) log(`[framework] auto PM: released the ${name} lock — its run ended`)
       else log(`[framework] auto PM: the release of the ${name} lock could not be committed; it will be retried`)
       return ok
     },
     releaseDeadLocks: async project => {
       const running = (await listAgents(project.path).catch(() => [])).filter(a => a.status === 'running' && a.host === hostname())
-      const released = await releaseDeadRoutineLocks(project.path, since => running.some(a => a.startedAt >= since), { log })
+      const released = await releaseDeadRoutineLocks(project.path, since => running.some(a => a.startedAt >= since), { log, funnel })
       for (const name of released) log(`[framework] auto PM: released the ${name} lock a previous daemon left behind`)
     },
     // The tickets a [Plan tickets] fan-out may claim (#1327/#1420): unplanned and not claimed
     // by a `.lock.md` — most important first. No stale-lock sweep runs here: #1420
     // removed the timer, so a lock stands until the agent's PR deletes it or a human releases
-    // it from the dashboard.
+    // it from the dashboard. The plan fan-out is the one place the daemon still reads and claims
+    // tickets (#1774); its own design is a follow-up.
     planCandidates: async project => {
       const rank = (priority?: string) => {
         const n = Number(priority)
@@ -263,14 +277,11 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
     // The daemon writes and pushes the locks, never the agent (#1327/#1320): an agent only
     // pushes at the end of its session onto its own branch, and a claim that stayed local would
     // not reach the machines it exists for.
-    lockPlans: (project, assignments) => claim(project.path, assignments, 'plan'),
-    // The same claim for what a drain is about to *implement* (#1420): drain mode skips only on
-    // an existing lock, because the plan it would also find is the drain's input, not a rival.
-    lockDrains: (project, assignments) => claim(project.path, assignments, 'drain'),
+    lockPlans: (project, assignments) => claim(project.path, assignments),
     // The one dead claim the daemon can *know* is dead (#1583): the run it minted the lock for
     // settled with nothing to hand off, so the PR that would delete the lock is never coming.
     releaseLock: async (project, claim) => {
-      const result = await releaseTicket(project.path, claim.ticket, { heldBy: claim.agentId }, { log })
+      const result = await releaseTicket(project.path, claim.ticket, { heldBy: claim.agentId }, { log, funnel })
       if (result === 'released')
         log(`[framework] auto PM: released the lock on ${claim.ticket} — its agent ended with nothing to hand off`)
       if (result === 'error')
@@ -278,68 +289,36 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
       return result !== 'error'
     },
     start: async (project, job) => {
-      // A draining agent works one open queue entry, and since #1164 that entry links back to the
-      // ticket it was queued from — so this is the one moment the framework knows what an agent is
-      // about to implement, and can say so on the agent's meta (#1117). A sweep-built drain names its
-      // own pinned entry (#1204), so the drain-lane (#1117) keeps working with several drains in flight;
-      // the first-open-entry read is the fallback for a drain job wired without one. Every other
-      // job puts work on the queue rather than taking it off, so there is nothing to name.
-      const ticket = job.drains
-        ? job.entry !== undefined
-          ? ticketFromQueueEntry(job.entry)
-          : await nextQueuedTicket(project.path).catch(() => undefined)
-        : // A fanned-out plan agent is pinned to one ticket too (#1327), so its meta names it the
-          // same way a pinned drain's does.
-          job.ticket !== undefined
-          ? `${TICKETS_DIR}/${job.ticket}`
-          : undefined
-      // The ticket is the durable claim: the pushed drain lock above (#1420) outlives this
-      // process. An entry with no ticket has only the sweep's in-memory pin — auto-pm.SPEC.md
-      // owns the hand-off window that leaves open.
       const result = await startUnattended(project.id, job.prompt, {
         // The claim the sweep minted names this id (#1748): the agent is born with it, so the
         // lock and the run are one and `tickets show` names the agent that holds the ticket.
         ...(job.claim ? { agentId: job.claim.agentId } : {}),
-        ...(ticket ? { ticket } : {}),
         // A fanned-out plan agent plans its ticket rather than implementing it (#1327), so its PR
-        // title must not inherit the issue as `(fix #42)` — the plan's merge would close the
-        // issue with the work still undone (#1334).
-        ...(ticket && !job.drains ? { planAgent: true } : {}),
-        // The job says its PRs may land themselves (#1216): the drain implements work whose
-        // review already happened on the queue. Rides to the agent as the ladder's top rung.
+        // description must not close the ticket's issue — the plan's merge would close the issue
+        // with the work still undone (#1334).
+        ...(job.ticket !== undefined ? { planAgent: true } : {}),
+        // The job says its PRs may land themselves (#1216): the queued work implements entries
+        // whose review already happened on the queue. Rides to the agent as the ladder's top rung.
         ...(job.autoMerge ? { handoff: 'merge' as const } : {}),
       })
       return result.ok ? result.agentId : undefined
     },
-    // The daemon retires a drained entry itself (#1582): the queue has one local writer, so the
-    // entry is deleted in one write to the `agent-data` branch at settle — done means deleted — not
-    // an agent edit promoted off a branch. It waits for the run's epilogue — the report is what
-    // says the work was published — and a run that published nothing leaves its entry open (its
-    // claim is freed below).
-    promote: async (project, { agentId, entry }) => {
+    // Whether a run the sweep started has ended (#852/#1583), off the run's own record. The
+    // daemon touches no queue at the run's end (#1774): the agent marked its own entry done, and
+    // the record the daemon writes is the run's, not the queue's.
+    settled: async (project, { agentId }) => {
       const agent = (await listAgents(project.path).catch(() => [])).find(r => r.id === agentId)
       // Unknown or still going: not settled, so it is tried again next tick.
-      if (!agent || agent.status === 'running') return { settled: false, promoted: false }
+      if (!agent || agent.status === 'running') return { settled: false }
       // The run's own recorded ending rides along (#1583): a settled run whose handoff skipped
       // as `no-commits` is the one case the sweep may free the lock it minted. A clean end whose
       // handoff has not reported yet is said too — only a `done` run gets the epilogue, so only
       // there does an absent report mean "still publishing" rather than "never will".
-      const flags = {
+      return {
+        settled: true,
         ...(agent.handoffSkip !== undefined ? { handoffSkip: agent.handoffSkip } : {}),
         ...(agent.status === 'done' && agent.handoffReport === undefined ? { handoffPending: true } : {}),
       }
-      // Published: the epilogue reported a hand-off, or skipped because the PR was already open
-      // (a resumed run whose earlier leg published). Anything else left the work unlanded.
-      const published =
-        agent.status === 'done' && (agent.handoffReport === 'done' || agent.handoffSkip === 'already-open')
-      if (entry === undefined || !published) return { settled: true, promoted: false, ...flags }
-      const result = await queueDone(project.path, entry, { log })
-      if (!result.ok) {
-        // Not settled: the write is retried next tick, and the entry stays held meanwhile.
-        log(`[framework] auto PM: the drained entry could not be taken off the queue (${agentId})`)
-        return { settled: false, promoted: false, ...flags }
-      }
-      return { settled: true, promoted: result.changed, ...flags }
     },
     log,
   })
@@ -406,7 +385,8 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
   // the `claude/*` head descending from its hand-off anchor, record the branch and PR on the
   // run's archive, and open the armed draft PR the session never did. Daemon-side by necessity:
   // the branch does not exist yet when the wrapper ends — the cloud VM is still provisioning.
-  const cloudWork = startCloudWorkAdoption({ projects, log })
+  // Its patch of a run's card is the daemon's own commit, signed as such (`daemon-writes.ts`).
+  const cloudWork = startCloudWorkAdoption({ projects, log, adopt: cwd => adoptCloudWork(cwd, { patch: (root, id, patch) => patchRun(root, id, patch, { funnel }) }) })
 
   // `resolve` matters: projectId hashes the path string, and `--cwd` reaches us verbatim, so a
   // relative path would hash to an id no project lookup can resolve. Same derivation the runtime uses.
@@ -504,14 +484,14 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
     jobs: [
       // Ten minutes. Its start-up turn is the point: the case it exists for is a machine that was
       // off (or a daemon that was down) while a session's push could not land.
-      { name: 'worktree sweep', every: AUTO_PM_EVERY, run: () => mergedWorktrees.tick() },
+      { name: 'worktree sweep', every: TEN_MINUTES_EVERY, run: () => mergedWorktrees.tick() },
       // After the worktree sweep, so links to checkouts the sweep just reclaimed drop in the same
       // turn. A rename settles within a tick; a fresh worktree gets its link at allocation.
-      { name: 'branch links', every: AUTO_PM_EVERY, run: () => branchLinks.tick() },
+      { name: 'branch links', every: TEN_MINUTES_EVERY, run: () => branchLinks.tick() },
       // The eager data pull (#1582): converge every project's data checkout on what other
       // machines and cloud sessions pushed, and carry out anything a failed cycle left local.
       // Its start-up turn is also what creates the checkout on a fresh clone. Before auto PM in
-      // the list, so a sweep the same tick reads the queue the pull just brought in. A project
+      // the list, so a look the same tick sees the head the pull just brought in. A project
       // that cannot converge is recorded as such for the dashboard (#1599).
       {
         name: 'data sync',
@@ -526,8 +506,9 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
       // The watched things change slowly and a poll costs a read per project. Their first turn is
       // the baseline seed, which must happen at start-up or the whole open backlog reads as new.
       { name: 'Discord watchers', every: 2, run: async () => { for (const w of discordWatchers) await w.poll() } },
-      // Ten minutes. Its start-up turn matters too: a daemon started with the setting already on
-      // would otherwise sit idle with quota going spare (#1161).
+      // One minute, behind the pull (#1774). Its start-up turn matters too: it remembers where
+      // the branch stands, and takes the rotation's first turn for a daemon started with the
+      // setting already on, which would otherwise sit idle with quota going spare (#1161).
       { name: 'auto PM', every: AUTO_PM_EVERY, run: () => autoPm.tick() },
       // Hourly. Its start-up turn is what starts a `cloud-*` ref's one-day clock (#1547): the
       // sweep ages those refs from when it first saw them, so the sooner it looks, the sooner
@@ -535,7 +516,7 @@ export function startBackgroundServices(deps: BackgroundServiceDeps): Background
       { name: 'cloud scratch sweep', every: CLOUD_SCRATCH_EVERY, run: () => cloudScratch.tick() },
       // Ten minutes: the cloud session it waits on lives minutes-to-hours itself, and the pass
       // costs an `ls-remote` per project only while a settled web run is actually waiting.
-      { name: 'cloud work adoption', every: AUTO_PM_EVERY, run: () => cloudWork.tick() },
+      { name: 'cloud work adoption', every: TEN_MINUTES_EVERY, run: () => cloudWork.tick() },
     ],
   })
 
diff --git a/packages/framework/src/daemon-workspace.test.ts b/packages/framework/src/daemon-workspace.test.ts
index 9d4e3c44d..67507ba2e 100644
--- a/packages/framework/src/daemon-workspace.test.ts
+++ b/packages/framework/src/daemon-workspace.test.ts
@@ -1,10 +1,10 @@
 import test from 'node:test'
 import assert from 'node:assert/strict'
 import { mkdtemp, mkdir, writeFile, readdir, readFile, readlink, rm, stat, realpath } from 'node:fs/promises'
-import { join, delimiter, resolve } from 'node:path'
+import { join, resolve } from 'node:path'
 import { execFile } from 'node:child_process'
 import { tmpdir } from 'node:os'
-import { createProjectRuntime, cleanupTimedOutWorktree, markFailedStart, agentStderrPath, isTransientAgentFailure, lastAgentFailureDetail, MAX_TRANSIENT_RETRIES } from './daemon-runtime.js'
+import { createProjectRuntime, cleanupTimedOutWorktree, markFailedStart, agentStderrPath, isTransientAgentFailure, lastAgentFailureDetail, MAX_TRANSIENT_RETRIES, ROUTINE_SKILLS } from './daemon-runtime.js'
 import type { PreflightResult } from './preflight.js'
 
 /**
@@ -15,10 +15,7 @@ import type { PreflightResult } from './preflight.js'
 const agentReady = (): Promise<PreflightResult> => Promise.resolve({ ok: true, checks: [] })
 import { EVENTS_FILE, META_FILE, startedAtFromAgentId, type AgentMeta } from './store/index.js'
 import { BRANCHES_DIR, nodeGitRunner, GitTimeoutError } from '@gemstack/agent-data'
-import { worktreePath, agentBranchName, CLI_BIN_DIR, HARNESS_SKILL_DIRS, SKILL_DIR as BRANCHES_SKILL_DIR } from '@gemstack/skill-branches'
-import { CLI_BIN_DIR as TICKETS_BIN_DIR, SKILL_DIR as TICKETS_SKILL_DIR } from '@gemstack/skill-tickets'
-import { CLI_BIN_DIR as QUEUE_BIN_DIR, SKILL_DIR as QUEUE_SKILL_DIR } from '@gemstack/skill-queue'
-import { CLI_BIN_DIR as LOGS_BIN_DIR, SKILL_DIR as LOGS_SKILL_DIR } from '@gemstack/skill-logs'
+import { worktreePath, agentBranchName, HARNESS_SKILL_DIRS, SKILL_DIR as BRANCHES_SKILL_DIR } from '@gemstack/skill-branches'
 import { THE_FRAMEWORK_DIR } from './framework-dir.js'
 import { addProject, projectId } from './registry.js'
 import type { AgentSpec } from './agent-spec.js'
@@ -646,7 +643,7 @@ async function writePathStub(dir: string, log: string): Promise<string> {
   return stub
 }
 
-test('a spawned agent finds the `branches` command on its PATH (#1725)', async () => {
+test("a spawned agent gets the daemon's PATH untouched, and its checkout links the branches and work-queue skills (#1725/#1774)", async () => {
   const cwd = await realpath(await mkdtemp(join(tmpdir(), 'framework-agent-path-')))
   try {
     const git = nodeGitRunner()
@@ -665,24 +662,19 @@ test('a spawned agent finds the `branches` command on its PATH (#1725)', async (
       await new Promise(r => setTimeout(r, 20))
       recorded = await readFile(log, 'utf8').catch(() => '')
     }
-    const path = recorded.trim()
-    assert.deepEqual(path.split(delimiter).slice(0, 4), [CLI_BIN_DIR, TICKETS_BIN_DIR, QUEUE_BIN_DIR, LOGS_BIN_DIR], 'the packages\' bin dirs come first: branches, tickets, queue, logs (#1748/#1769)')
-    assert.equal(path.split(delimiter).slice(4).join(delimiter), process.env['PATH'], "after the daemon's own")
-    // By name, the way the agent's shell resolves it, against the project the daemon started it in.
-    const listed = await new Promise<string>((resolvePromise, rejectPromise) =>
-      execFile('branches', ['list'], { cwd, env: { ...process.env, PATH: path } }, (err, stdout) => (err ? rejectPromise(err) : resolvePromise(stdout))),
-    )
-    assert.deepEqual(
-      (JSON.parse(listed) as { agentId: string }[]).map(row => row.agentId),
-      [result.agentId],
-      'and it reports the checkout the daemon allocated',
-    )
-    // The four skills are in the checkout too, where each harness looks for them (#1739/#1748/#1769).
+    // The daemon puts nothing on the agent's PATH (#1774): a skill's command resolves from the
+    // project's own dependencies, `npx tickets`, as its SKILL.md says.
+    assert.equal(recorded.trim(), process.env['PATH'], "the agent's PATH is the daemon's own")
+    // Two skills are linked into the checkout, where each harness looks for them: the branches
+    // package's own (#1739), and the routine skill the daemon fires (#1774). The skills an agent
+    // composes — tickets, queue, logs — are the project's tracked files, not links.
+    const checkout = worktreePath(cwd, result.agentId!)
     for (const harnessDir of HARNESS_SKILL_DIRS) {
-      for (const [name, dir] of [['branches', BRANCHES_SKILL_DIR], ['tickets', TICKETS_SKILL_DIR], ['queue', QUEUE_SKILL_DIR], ['logs', LOGS_SKILL_DIR]] as const) {
-        const target = await readlink(join(worktreePath(cwd, result.agentId!), harnessDir, name))
-        assert.equal(await realpath(resolve(join(worktreePath(cwd, result.agentId!), harnessDir), target)), await realpath(dir), `${harnessDir}/${name} links the package holding its SKILL.md`)
+      for (const [name, dir] of [['branches', BRANCHES_SKILL_DIR], ...ROUTINE_SKILLS.map(s => [s.name, s.dir] as const)] as const) {
+        const target = await readlink(join(checkout, harnessDir, name))
+        assert.equal(await realpath(resolve(join(checkout, harnessDir), target)), await realpath(dir), `${harnessDir}/${name} links the directory holding its SKILL.md`)
       }
+      assert.deepEqual((await readdir(join(checkout, harnessDir))).sort(), ['branches', 'work-queue'], `${harnessDir} holds exactly those two links`)
     }
     await runtime.dispose()
   } finally {
diff --git a/packages/framework/src/daemon-writes.test.ts b/packages/framework/src/daemon-writes.test.ts
new file mode 100644
index 000000000..412995acf
--- /dev/null
+++ b/packages/framework/src/daemon-writes.test.ts
@@ -0,0 +1,74 @@
+import { strict as assert } from 'node:assert'
+import { test } from 'node:test'
+import { mkdtemp, rm, writeFile } from 'node:fs/promises'
+import { tmpdir } from 'node:os'
+import { join } from 'node:path'
+import { execFile } from 'node:child_process'
+import { promisify } from 'node:util'
+import { DATA_BRANCH, withFileBranch } from '@gemstack/agent-data'
+import { DAEMON_TRAILER, daemonFunnel, dataHead, foreignCommits } from './daemon-writes.js'
+
+const git = promisify(execFile)
+
+// The mark that keeps the daemon from reacting to itself (#1774): every automatic write is a
+// commit signed `Daemon: <host>`, and the trigger counts only the commits without it. Real git,
+// because what is asserted is what git prints for a trailer.
+
+async function repo(): Promise<string> {
+  const dir = await mkdtemp(join(tmpdir(), 'framework-daemon-writes-'))
+  await git('git', ['init', '-q', '-b', 'main'], { cwd: dir })
+  await git('git', ['config', 'user.email', 'test@example.com'], { cwd: dir })
+  await git('git', ['config', 'user.name', 'Test'], { cwd: dir })
+  await git('git', ['config', 'commit.gpgsign', 'false'], { cwd: dir })
+  return dir
+}
+
+test('a repository with no data branch yet has no head to read', async () => {
+  const dir = await repo()
+  try {
+    assert.equal(await dataHead(dir), undefined)
+  } finally {
+    await rm(dir, { recursive: true, force: true })
+  }
+})
+
+test("the daemon's funnel signs its commits, and only unsigned commits count as moves (#1774)", async () => {
+  const dir = await repo()
+  try {
+    // Someone queued work: a plain write through the skills' own funnel, no trailer.
+    const seeded = await withFileBranch(dir, DATA_BRANCH, 'queue add: fix the login page', async d => writeFile(join(d, 'TODO_AGENTS.md'), '- fix the login page\n'))
+    assert.ok(seeded.ok)
+    const before = await dataHead(dir)
+    assert.ok(before, 'the branch exists once written')
+    // The daemon recorded a run: signed.
+    const recorded = await daemonFunnel('build-box')(dir, 'logs: record run 2026-09-13T10-00-00-000Z', async d => writeFile(join(d, 'agents.json'), '{}\n'))
+    assert.ok(recorded.ok)
+    const afterRecord = await dataHead(dir)
+    assert.notEqual(afterRecord, before, 'the record is a commit')
+    const message = (await git('git', ['log', '-1', '--format=%B', `refs/heads/${DATA_BRANCH}`], { cwd: dir })).stdout
+    assert.match(message, /^logs: record run 2026-09-13T10-00-00-000Z\n\nDaemon: build-box\n/, 'the trailer is the last line, after a blank one')
+    assert.equal(await foreignCommits(dir, before!, afterRecord!), 0, "the daemon's own commit is not a move")
+    // Then an agent closed its ticket: unsigned.
+    const closed = await withFileBranch(dir, DATA_BRANCH, 'tickets close: login', async d => writeFile(join(d, 'TODO_AGENTS.md'), ''))
+    assert.ok(closed.ok)
+    const afterClose = await dataHead(dir)
+    assert.equal(await foreignCommits(dir, before!, afterClose!), 1, 'one of the two commits since is a move')
+    assert.equal(await foreignCommits(dir, afterRecord!, afterClose!), 1)
+    // A message whose body mentions the key in prose is not a trailer.
+    const prose = await withFileBranch(dir, DATA_BRANCH, `queue add: mention the ${DAEMON_TRAILER} in a sentence`, async d => writeFile(join(d, 'TODO_AGENTS.md'), '- x\n'))
+    assert.ok(prose.ok)
+    assert.equal(await foreignCommits(dir, afterClose!, (await dataHead(dir))!), 1)
+  } finally {
+    await rm(dir, { recursive: true, force: true })
+  }
+})
+
+test('a range git cannot walk counts as no move: the heartbeat is the belt for it', async () => {
+  const dir = await repo()
+  try {
+    await withFileBranch(dir, DATA_BRANCH, 'seed', async d => writeFile(join(d, 'a'), 'a'))
+    assert.equal(await foreignCommits(dir, 'deadbeefdeadbeefdeadbeefdeadbeefdeadbeef', (await dataHead(dir))!), 0)
+  } finally {
+    await rm(dir, { recursive: true, force: true })
+  }
+})
diff --git a/packages/framework/src/daemon-writes.ts b/packages/framework/src/daemon-writes.ts
new file mode 100644
index 000000000..105e3d735
--- /dev/null
+++ b/packages/framework/src/daemon-writes.ts
@@ -0,0 +1,55 @@
+import { hostname } from 'node:os'
+import { DATA_BRANCH, nodeGitRunner, withFileBranch, type CommitMessage, type FileBranchWrite, type GitRunner } from '@gemstack/agent-data'
+
+/**
+ * The daemon's own writes to the `agent-data` branch, told apart from everyone else's.
+ *
+ * The daemon starts a run when the branch moved by a commit it did not write itself: someone
+ * queued work, an agent claimed or closed a ticket. Its own commits — a run's record at teardown, a
+ * routine lock, a claim minted for a plan agent — must not count, or every record it writes would
+ * start the next run, forever. And the branch is shared: another machine's daemon writes records
+ * too, and two daemons reading each other's records as work would fire empty runs at each other
+ * without end. So every automatic write goes through {@link daemonFunnel}, which signs the commit
+ * with a git trailer naming the machine, and the trigger counts only the commits that carry none.
+ *
+ * A write a person makes from the dashboard (queue an entry, release a claim) takes the skills'
+ * plain funnel and carries no trailer: a person asking for work is exactly what should start a run.
+ */
+
+/** The trailer key on every commit a daemon writes on its own: `Daemon: <machine name>`. */
+export const DAEMON_TRAILER = 'Daemon'
+
+/** A write funnel to the data branch, the shape every skill library accepts. */
+export type DataFunnel = (root: string, message: CommitMessage, op: (dir: string) => Promise<void>) => Promise<FileBranchWrite>
+
+/**
+ * The persistent checkout's write cycle on the `agent-data` branch, every commit signed
+ * `Daemon: <host>` as its last line. One per daemon; `host` is a test seam.
+ */
+export function daemonFunnel(host: string = hostname()): DataFunnel {
+  return (root, message, op) =>
+    withFileBranch(root, DATA_BRANCH, () => `${typeof message === 'function' ? message() : message}\n\n${DAEMON_TRAILER}: ${host}`, op)
+}
+
+/** The local head of the `agent-data` branch, or `undefined` when the repo has no such branch yet. */
+export async function dataHead(repo: string, git: GitRunner = nodeGitRunner()): Promise<string | undefined> {
+  return git(['rev-parse', '--verify', '--quiet', `refs/heads/${DATA_BRANCH}`], repo).then(
+    out => out.trim() || undefined,
+    () => undefined,
+  )
+}
+
+/**
+ * How many commits `from..to` on the branch were written by something other than a daemon: the
+ * ones with no `Daemon:` trailer. A range git cannot walk (a `from` rebased away) counts as none;
+ * the daily heartbeat is the belt for that.
+ */
+export async function foreignCommits(repo: string, from: string, to: string, git: GitRunner = nodeGitRunner()): Promise<number> {
+  const out = await git(['log', `--format=%H%x1f%(trailers:key=${DAEMON_TRAILER},valueonly)`, `${from}..${to}`], repo).catch(() => '')
+  let foreign = 0
+  for (const line of out.split('\n')) {
+    const at = line.indexOf('\x1f')
+    if (at !== -1 && line.slice(at + 1).trim() === '') foreign++
+  }
+  return foreign
+}
diff --git a/packages/framework/src/daemon.test.ts b/packages/framework/src/daemon.test.ts
index c1e17e50c..ade9aebf3 100644
--- a/packages/framework/src/daemon.test.ts
+++ b/packages/framework/src/daemon.test.ts
@@ -362,6 +362,13 @@ fs.appendFileSync(${JSON.stringify(join(cwd, 'started.log'))}, agentId + '\\n')
     // while the worktree still exists (#799) — otherwise the handoff has nothing to read.
     const doneMeta = await archivedMeta(doneId)
     assert.equal(doneMeta?.branch, `agent-${doneId}`, "the finished run's branch is recorded")
+    // The record is the daemon's own commit on the data branch, signed with its trailer, so the
+    // sweep that watches the branch for work does not read the record as a move (#1774).
+    assert.match(
+      await git(['log', '-1', '--format=%B', 'refs/heads/agent-data'], cwd),
+      /^logs: record run \S+\n\nDaemon: \S+\n/,
+      "the record's commit message ends in the daemon's trailer",
+    )
     assert.match(
       await git(['log', '--format=%s', `refs/remotes/origin/agent-${doneId}`], cwd),
       /\S/,
diff --git a/packages/framework/src/daemon.ts b/packages/framework/src/daemon.ts
index 2cdb18dbb..8a1cad9d1 100644
--- a/packages/framework/src/daemon.ts
+++ b/packages/framework/src/daemon.ts
@@ -7,6 +7,7 @@ import { startDashboard, type Dashboard, type StartAgentOptions } from './dashbo
 import { createProjectRuntime, type ProjectRuntimeOptions } from './daemon-runtime.js'
 import { defaultQuotaSource } from './dashboard/quota.js'
 import { startBackgroundServices, type BackgroundServices } from './daemon-services.js'
+import { daemonFunnel } from './daemon-writes.js'
 import { projectErrorStore } from './project-errors.js'
 import { resolveDashboardBundle } from './dashboard/bundle.js'
 import { isActivated } from './project.js'
@@ -155,9 +156,11 @@ export async function runDaemon(cwd: string, opts: RunDaemonOptions = {}): Promi
 
   // Crash recovery (#642): a fresh daemon drives no in-flight run, so any run a dead
   // process left marked `running` is orphaned — it would show as active forever with a
-  // no-op Stop. Reconcile them to `stopped` across every registered project at boot.
+  // no-op Stop. Reconcile them to `stopped` across every registered project at boot. The
+  // records it writes are the daemon's own commits, signed as such (`daemon-writes.ts`).
+  const funnel = daemonFunnel()
   for (const record of await listProjects(undefined, env).catch(() => [])) {
-    const fixed = await reconcileOrphanedAgents(record.path).catch(() => 0)
+    const fixed = await reconcileOrphanedAgents(record.path, undefined, undefined, funnel).catch(() => 0)
     if (fixed > 0) console.log(`[framework] reconciled ${fixed} orphaned agent(s) in ${basename(record.path)}`)
   }
   // Browsers those agents left behind (#1719): a Chrome whose agent died by SIGKILL runs on
diff --git a/packages/framework/src/dashboard-rpc/control.test.ts b/packages/framework/src/dashboard-rpc/control.test.ts
index cd15791a3..31fb96d11 100644
--- a/packages/framework/src/dashboard-rpc/control.test.ts
+++ b/packages/framework/src/dashboard-rpc/control.test.ts
@@ -43,60 +43,6 @@ async function registerProject(cwd: string, over: Parameters<typeof provideTestC
   return projectId(resolve(cwd))
 }
 
-// An agent started from the dashboard has to name the ticket it is about to implement, the same way
-// the sweep's own drain does (#1117). The daemon reads that off the `drains` flag on its job; a
-// click arrives with nothing but prompt text, so the resolution happens here.
-
-/** The options `startAgent` was handed, plus a workspace with one queued ticket to resolve against. */
-async function harness(): Promise<{ cwd: string; id: string; started: () => StartAgentOptions | undefined }> {
-  const cwd = await dataRepo({
-    'TODO_AGENTS.md': ['## Priority 9', '', '- [ ] [Add a login page](tickets/2026-07-25_login.md)', ''].join('\n'),
-  })
-  let seen: StartAgentOptions | undefined
-  const id = await registerProject(cwd, {
-    startAgent: async (_text: string, _kind: string, options: StartAgentOptions) => {
-      seen = options
-      return { ok: true, agentId: 'r1' }
-    },
-  })
-  return { cwd, id, started: () => seen }
-}
-
-test('a drain started from the dashboard carries the ticket it is about to work (#1117)', async () => {
-  const { cwd, id, started } = await harness()
-  try {
-    const result = await sendStart(id, presets.drainQueue.render())
-    assert.equal(result.ok, true)
-    // Without this the agent implemented the ticket and the Overview's in-progress lane stayed empty,
-    // because only the daemon's own drain was tagging what it took off the queue.
-    assert.equal(started()?.ticket, 'tickets/2026-07-25_login.md')
-  } finally {
-    await rm(cwd, { recursive: true, force: true })
-  }
-})
-
-test('any other prompt starts without a ticket, however busy the queue is (#1117)', async () => {
-  const { cwd, id, started } = await harness()
-  try {
-    await sendStart(id, 'Have a look at the login page')
-    // Naming the queue's next entry here would show a ticket as being implemented on the strength
-    // of an agent that never touched it.
-    assert.equal(started()?.ticket, undefined)
-  } finally {
-    await rm(cwd, { recursive: true, force: true })
-  }
-})
-
-test('a ticket named by the caller is not replaced by the guess (#1117)', async () => {
-  const { cwd, id, started } = await harness()
-  try {
-    await sendStart(id, presets.drainQueue.render(), 'build', { ticket: 'tickets/2026-07-20_chosen.md' })
-    assert.equal(started()?.ticket, 'tickets/2026-07-20_chosen.md')
-  } finally {
-    await rm(cwd, { recursive: true, force: true })
-  }
-})
-
 // The manual `.lock.md` release (#1420): the only way a claim lifts besides the agent's own PR
 // deleting it, so the RPC has to hold the same line the file readers do about what a ticket
 // filename is, and actually land the release as a commit.
diff --git a/packages/framework/src/dashboard-rpc/control.ts b/packages/framework/src/dashboard-rpc/control.ts
index da4838c6a..255766b7e 100644
--- a/packages/framework/src/dashboard-rpc/control.ts
+++ b/packages/framework/src/dashboard-rpc/control.ts
@@ -4,7 +4,6 @@ import { openInApp, type OpenTarget, type OpenResult } from '../dashboard/open-i
 import { contextBridgeBrowser, contextPreferences, contextStartAgent, resolveProjectPath, resolveAgentPath } from './context.js'
 import type { BridgeBrowserAction } from '../bridge-browser.js'
 import { relayOr } from './relay-agent.js'
-import { ticketForPrompt } from '../todo-loop.js'
 import { planTicketPrompt } from '../tickets.js'
 import { isTicketFile, queuePriorityForTicket, releaseTicket, TICKETS_DIR } from '@gemstack/skill-tickets'
 import { QUEUE_FILE, queueAdd } from '@gemstack/skill-queue'
@@ -190,19 +189,7 @@ export async function sendStart(
   const startAgent = contextStartAgent()
   const text = prompt.trim()
   if (!text && kind !== 'research') return { ok: false, error: 'a non-empty prompt is required' }
-  // A drain fired by hand is the same work the sweep does, so it says the same thing about itself
-  // (#1117). Resolved here rather than sent by the caller: the value lands on the agent's meta and is
-  // rendered, so it is read off the queue on this side instead of trusted from a browser. An
-  // explicit ticket on the options wins, since a caller that names one knows better than a guess.
-  const ticket = options.ticket ?? (await ticketForStart(projectId, text))
-  return startAgent(text, kind, ticket ? { ...options, ticket } : options, projectId)
-}
-
-/** The queue entry a hand-fired drain is about to work, or undefined for any other prompt (#1117). */
-async function ticketForStart(projectId: string, prompt: string): Promise<string | undefined> {
-  const cwd = await resolveProjectPath(projectId)
-  if (!cwd) return undefined
-  return ticketForPrompt(prompt, cwd).catch(() => undefined)
+  return startAgent(text, kind, options, projectId)
 }
 
 /**
diff --git a/packages/framework/src/dashboard-rpc/quota.test.ts b/packages/framework/src/dashboard-rpc/quota.test.ts
index 36aaacf29..dfea66ab4 100644
--- a/packages/framework/src/dashboard-rpc/quota.test.ts
+++ b/packages/framework/src/dashboard-rpc/quota.test.ts
@@ -73,14 +73,14 @@ test('the narrowing travels to the loop untouched (#1204)', async () => {
     },
     autoPm: () => ({ nextSweepAt: 0, outcomes: [] }),
   })
-  await sendAutoPmSweep({ only: 'drain' })
+  await sendAutoPmSweep({ only: 'work' })
   await sendAutoPmSweep({ only: 'plan', projectId: 'p1' })
   await sendAutoPmSweep({ only: { lock: 'triage-quick' }, projectId: 'p1' })
   await sendAutoPmSweep()
   // Passed through rather than rebuilt: a wrapper that reconstructed the object is how a new
   // narrowing silently stops reaching the loop.
   assert.deepEqual(seen, [
-    { only: 'drain' },
+    { only: 'work' },
     { only: 'plan', projectId: 'p1' },
     { only: { lock: 'triage-quick' }, projectId: 'p1' },
     undefined,
diff --git a/packages/framework/src/dashboard-rpc/quota.ts b/packages/framework/src/dashboard-rpc/quota.ts
index 41afd4ef2..152596a73 100644
--- a/packages/framework/src/dashboard-rpc/quota.ts
+++ b/packages/framework/src/dashboard-rpc/quota.ts
@@ -49,13 +49,11 @@ export async function onAutoPm(): Promise<AutoPmReport | undefined> {
  * off the loop's own report once the tick resolves, so the card can say them without a poll
  * having to race the sweep. `false` means the sweep itself failed.
  *
- * `only` narrows the sweep to one routine's work (#1204), which is what a Run now that fans out
- * means: `'drain'` spins agents up on the queue's entries, `'plan'` on the open tickets. Either
- * way the fan-out is the sweep's — a plain start could only ever be one agent — and having
- * nothing to work is reported rather than borrowed for a rotation job. `{ pinned }` is the
- * routine pinned to that branch (#1643): one agent, but the sweep releases a stale copy of the
- * branch before starting it, which a plain start never did. `projectId` scopes it to the project
- * the card has picked.
+ * `only` narrows the sweep to one routine's work (#1204): `'work'` starts an agent on the queued
+ * work in every project (#1774), `'plan'` fans out on the open tickets — the sweep's to do, since a
+ * plain start could only ever be one agent and would take no claim. `{ lock }` is the routine
+ * holding that lock (#1643/#1659): one agent, but the sweep takes the lock before starting it,
+ * which a plain start never did. `projectId` scopes it to the project the card has picked.
  */
 export async function sendAutoPmSweep(opts?: { only?: AutoPmOnly; projectId?: string }): Promise<{ ok: boolean; outcomes?: AutoPmOutcome[] }> {
   const sweep = contextAutoPmSweep()
diff --git a/packages/framework/src/dashboard/agent-handoff.test.ts b/packages/framework/src/dashboard/agent-handoff.test.ts
index 500f1702b..09352cd8f 100644
--- a/packages/framework/src/dashboard/agent-handoff.test.ts
+++ b/packages/framework/src/dashboard/agent-handoff.test.ts
@@ -766,16 +766,13 @@ test('a different PR on the branch is not this run’s answer (E6)', async () =>
   assert.equal(found.value?.number, 42, 'the recorded number wins over whatever is on the branch now')
 })
 
-test('withheldMerge authorizes only a declared-done session with an empty session TODO (#1363)', () => {
+test('withheldMerge authorizes only a declared-done session (#1363)', () => {
   // The rule settled on #1390: config arms the merge, the agent authorizes it. No signal means
   // no merge, whatever else is true — this is what row 3 of the live matrix proved was missing
   // (the daemon merged 3s after the PR opened, with setReadyForMerge never called).
-  assert.equal(withheldMerge({ readyForMerge: false, agentTodoOpen: false }), 'not-ready-for-merge')
-  assert.equal(withheldMerge({ readyForMerge: false, agentTodoOpen: true }), 'not-ready-for-merge')
-  // The temporary safety belt: the agent said done but its own session file says otherwise.
-  assert.equal(withheldMerge({ readyForMerge: true, agentTodoOpen: true }), 'session-todo-open')
-  // Declared done, nothing pending in this session: the merge may run.
-  assert.equal(withheldMerge({ readyForMerge: true, agentTodoOpen: false }), undefined)
+  assert.equal(withheldMerge({ readyForMerge: false }), 'not-ready-for-merge')
+  // Declared done: the merge may run. The agent's word is enough (#1774).
+  assert.equal(withheldMerge({ readyForMerge: true }), undefined)
 })
 
 test("a run implementing a ticket carries its issue as `(fix #42)` in the PR title (#1334)", async () => {
diff --git a/packages/framework/src/dashboard/agent-handoff.ts b/packages/framework/src/dashboard/agent-handoff.ts
index 818a8e9cb..4f0eaedb9 100644
--- a/packages/framework/src/dashboard/agent-handoff.ts
+++ b/packages/framework/src/dashboard/agent-handoff.ts
@@ -532,19 +532,13 @@ const ARMED_HANDOFF: HandoffIntent = { push: true, pr: true }
  * Whether an armed merge may actually run (#1363), and if not, why.
  *
  * The rule settled on #1390: config *arms* the merge, the agent *authorizes* it. Landing on the
- * default branch unattended takes (a) the agent having declared the session done via
- * setReadyForMerge() — the same signal the on-before-mergeable step requires — and (b) the
- * framework not already knowing of work pending in this session (its own TODO file; never the
- * global queue, which is decoupled from sessions). A withheld merge is not a failed handoff:
- * push and PR go ahead, the PR just opens as a draft for a human.
- *
- * (b) is a temporary safety belt: the agent's word should ultimately be enough. Deleting it means
- * deleting `agentTodoOpen` here and `agentTodoPending` in todo-loop.ts.
+ * default branch unattended takes the agent having declared the session done via
+ * setReadyForMerge() — the same signal the on-before-mergeable step requires. The agent's word is
+ * enough (#1774): the belt that read the session's own TODO file beside it is gone. A withheld
+ * merge is not a failed handoff: push and PR go ahead, the PR just opens as a draft for a human.
  */
-export function withheldMerge(deps: { readyForMerge: boolean; agentTodoOpen: boolean }): MergeWithheldReason | undefined {
-  if (!deps.readyForMerge) return 'not-ready-for-merge'
-  if (deps.agentTodoOpen) return 'session-todo-open'
-  return undefined
+export function withheldMerge(deps: { readyForMerge: boolean }): MergeWithheldReason | undefined {
+  return deps.readyForMerge ? undefined : 'not-ready-for-merge'
 }
 
 /**
diff --git a/packages/framework/src/dashboard/overview.test.ts b/packages/framework/src/dashboard/overview.test.ts
index a5e5ff826..5ea5260ed 100644
--- a/packages/framework/src/dashboard/overview.test.ts
+++ b/packages/framework/src/dashboard/overview.test.ts
@@ -197,60 +197,6 @@ test('buildHotTickets tolerates a project whose tickets cannot be read', async (
   assert.deepEqual(hot.map(h => h.ticket.file), ['x.md'])
 })
 
-/** A live agent meta carrying the ticket it is implementing (#1117). */
-const runOn = (id: string, ticket: string, status: AgentMeta['status'] = 'running') =>
-  ({ version: 1, status, id, startedAt: 't', updatedAt: 't', ticket, cwd: '/w' }) as never
-
-test('ticketBucket: a run implementing it is in-progress, whatever the plan says (#1117)', () => {
-  // The whole point of the link: a ticket nobody has planned yet, being coded right now, would
-  // otherwise fall through to a non-shown lane on the strength of a plan file alone.
-  assert.equal(ticketBucket(ticket('a'), { implementing: true }), 'in-progress')
-  assert.equal(ticketBucket(ticket('b', { priority: '8' }), { implementing: true }), 'in-progress')
-  // Absent evidence, the inference (#1112) is untouched.
-  assert.equal(ticketBucket(ticket('c', { planned: true }), { implementing: false }), 'in-progress')
-  assert.equal(ticketBucket(ticket('d'), { implementing: false }), null)
-})
-
-test('buildHotTickets marks the ticket a live run is implementing, with its run id (#1117)', async () => {
-  const hot = await buildHotTickets([project('alpha', '/a')], {
-    tickets: async () => [ticket('2026-07-25_login.md'), ticket('2026-07-26_other.md')],
-    liveAgents: async () => [runOn('run-7', 'tickets/2026-07-25_login.md')],
-    queue: async () => [],
-  })
-  const login = hot.find(h => h.ticket.file === '2026-07-25_login.md')
-  assert.equal(login?.bucket, 'in-progress', 'the ticket being coded is in progress')
-  assert.equal(login?.agentId, 'run-7', 'and carries the run, so the card can link into it')
-  // The ticket nobody is on and nothing queues is in no lane, so it drops off the card (#1139).
-  const other = hot.find(h => h.ticket.file === '2026-07-26_other.md')
-  assert.equal(other, undefined)
-})
-
-test('buildHotTickets ignores a finished run and another project\'s ticket (#1117)', async () => {
-  // An agent that has ended is not implementing anything, however recently it stopped — so x.md carries
-  // no agentId and sits in the AI Queue by its link alone.
-  const finished = await buildHotTickets([project('alpha', '/a')], {
-    tickets: async () => [ticket('x.md')],
-    liveAgents: async () => [runOn('run-7', 'tickets/x.md', 'done')],
-    queue: async () => [{ projectId: 'alpha', projectName: 'alpha', open: 1, total: 1, items: [{ text: '[x](tickets/x.md)', done: false }] }],
-  })
-  assert.equal(finished[0]?.agentId, undefined)
-  assert.equal(finished[0]?.bucket, 'ai-queue')
-
-  // A ticket path is only unique inside its own repo, so beta's run must not light up alpha's
-  // identically-named ticket. alpha's x.md is in no lane (no run, no queue link, no priority), so
-  // only beta's implementing copy survives.
-  const twoProjects = await buildHotTickets([project('alpha', '/a'), project('beta', '/b')], {
-    tickets: async () => [ticket('x.md')],
-    liveAgents: async cwd => (cwd === '/b' ? [runOn('run-9', 'tickets/x.md')] : []),
-    queue: async () => [],
-  })
-  assert.deepEqual(
-    twoProjects.map(h => ({ p: h.projectName, agent: h.agentId })),
-    [{ p: 'beta', agent: 'run-9' }],
-    'only beta reads as implementing; alpha\'s same-named ticket is in no lane and drops off',
-  )
-})
-
 test('buildOverview lists a web run whose cloud side is still at work, and says where it is (#1668)', async () => {
   const now = Date.parse('2026-08-23T20:00:00Z')
   const at = (hoursAgo: number) => new Date(now - hoursAgo * 60 * 60 * 1000).toISOString()
diff --git a/packages/framework/src/dashboard/overview.ts b/packages/framework/src/dashboard/overview.ts
index 2a6207b36..0d819d8d5 100644
--- a/packages/framework/src/dashboard/overview.ts
+++ b/packages/framework/src/dashboard/overview.ts
@@ -138,14 +138,6 @@ export interface HotTicket {
   projectName: string
   bucket: HotBucket
   ticket: WorkspaceTicket
-  /**
-   * An agent is implementing this ticket right now (#1117): its id, for the card to link into.
-   *
-   * The difference between "someone planned this at some point" and "this is being coded as you
-   * look at it", which the plan/spike proxy could not tell apart. Only set for a ticket a live agent
-   * actually recorded (`AgentMeta.ticket`), so absent still means the lane was inferred.
-   */
-  agentId?: string
 }
 
 /** Where the ticket format's 10-0 scale starts reading as high. */
@@ -165,23 +157,18 @@ function isHighPriority(priority: string): boolean {
 
 /**
  * A ticket's lane (#1139), or null when it is in none of the three the card shows:
- * - in-progress: an agent is implementing it right now (#1117), or failing that the agent has
- *   planned it, so work is under way in the older, inferred sense.
+ * - in-progress: an agent has planned it, so work is under way in the inferred sense. Which
+ *   ticket an agent is implementing right now is the ticket's own claim to say (#1774); the
+ *   framework no longer records it on the run.
  * - ai-queue: it sits in the AI Queue — an open `TODO_AGENTS.md` entry links to it — so the
  *   framework will pick it up on its own.
  * - high-priority: none of the above, but flagged high priority; what a human would likely queue next.
  *
  * Precedence follows that order: work already under way outranks a queued ticket, which outranks a
  * bare priority flag. Everything else is dropped — the card is a shortlist, not the whole backlog.
- *
- * `implementing` is the only hard evidence and exists for a drain agent only, so the plan proxy
- * still carries every ticket someone is working by hand.
  */
-export function ticketBucket(
-  ticket: WorkspaceTicket,
-  opts: { implementing?: boolean; queued?: boolean } = {},
-): HotBucket | null {
-  if (opts.implementing || ticket.planned) return 'in-progress'
+export function ticketBucket(ticket: WorkspaceTicket, opts: { queued?: boolean } = {}): HotBucket | null {
+  if (ticket.planned) return 'in-progress'
   if (opts.queued) return 'ai-queue'
   if (ticket.priority && isHighPriority(ticket.priority)) return 'high-priority'
   return null
@@ -209,22 +196,19 @@ const HOT_TICKETS_LIMIT = 60
 /** Injectable readers so {@link buildHotTickets} is unit-testable off disk. */
 export interface HotTicketsDeps {
   tickets?: (cwd: string) => Promise<WorkspaceTicket[]>
-  /** The project's live agents, read for the ticket each one recorded (#1117). */
-  liveAgents?: (cwd: string) => Promise<LiveAgent[]>
   /** The cross-project TODO queue, for the AI-Queue lane (#1139). Defaults to {@link collectQueue}. */
   queue?: (projects: ProjectSummary[]) => Promise<ProjectQueue[]>
 }
 
 /**
  * Every project's tickets pooled and bucketed for the Overview's "hot tickets" card (#1139): what is
- * being worked on (implementing/planned), what sits in the AI Queue (an open `TODO_AGENTS.md`
- * entry links to it), and what is merely flagged high priority. Ordered lane-first (in-progress,
+ * being worked on (planned), what sits in the AI Queue (an open `TODO_AGENTS.md` entry links to
+ * it), and what is merely flagged high priority. Ordered lane-first (in-progress,
  * ai-queue, high-priority), file order within a lane; a ticket in none of the three is dropped.
  * Forgiving — a project whose tickets cannot be read simply contributes nothing.
  */
 export async function buildHotTickets(projects: ProjectSummary[], deps: HotTicketsDeps = {}): Promise<HotTicket[]> {
   const readT = deps.tickets ?? readTickets
-  const readAgents = deps.liveAgents ?? readLiveMetas
   // The AI Queue: which tickets an open TODO_AGENTS.md entry links to, per project (#1139).
   const queues = await (deps.queue ?? (p => collectQueue(p)))(projects)
   const queuedByProject = new Map<string, Set<string>>()
@@ -239,26 +223,12 @@ export async function buildHotTickets(projects: ProjectSummary[], deps: HotTicke
   }
   const all: HotTicket[] = []
   for (const project of projects) {
-    // Which of this project's tickets are being implemented right now, by agent id (#1117). Built
-    // per project because a ticket path is only unique within its own repo.
-    const implementing = new Map<string, string>()
-    for (const meta of await readAgents(project.path).catch(() => [])) {
-      if (meta.status !== 'running' || !meta.ticket) continue
-      implementing.set(meta.ticket, meta.id)
-    }
     const queued = queuedByProject.get(project.id) ?? new Set<string>()
     for (const ticket of await readT(project.path).catch(() => [])) {
-      const agentId = implementing.get(`${TICKETS_DIR}/${ticket.file}`)
-      const bucket = ticketBucket(ticket, { implementing: agentId !== undefined, queued: queued.has(ticket.file) })
+      const bucket = ticketBucket(ticket, { queued: queued.has(ticket.file) })
       // A ticket in none of the three shown lanes is left off the card entirely.
       if (!bucket) continue
-      all.push({
-        projectId: project.id,
-        projectName: project.name,
-        bucket,
-        ticket,
-        ...(agentId ? { agentId } : {}),
-      })
+      all.push({ projectId: project.id, projectName: project.name, bucket, ticket })
     }
   }
   const lane: Record<HotBucket, number> = { 'in-progress': 0, 'ai-queue': 1, 'high-priority': 2 }
diff --git a/packages/framework/src/dashboard/queue.ts b/packages/framework/src/dashboard/queue.ts
index 369b00b9c..9e363bd5b 100644
--- a/packages/framework/src/dashboard/queue.ts
+++ b/packages/framework/src/dashboard/queue.ts
@@ -25,7 +25,7 @@ export interface ProjectQueue {
 }
 
 // A markdown list item (`-`, `*`, or `1.`), any leading indent. Deliberately the same rule the
-// drain reads the queue by — the `queue` skill's own parser, which `todo-loop.ts` calls — because
+// agents read the queue by — the `queue` skill's own parser — because
 // the queue's readers must agree on what an entry is, or the card says "Nothing queued" while the
 // sweep drains the same file (#1296).
 const LIST_ITEM = /^\s*(?:[-*]|\d+\.)\s+(.*\S)\s*$/
diff --git a/packages/framework/src/dashboard/types.ts b/packages/framework/src/dashboard/types.ts
index 7aa10c1b3..dfcb5748f 100644
--- a/packages/framework/src/dashboard/types.ts
+++ b/packages/framework/src/dashboard/types.ts
@@ -89,16 +89,10 @@ export interface StartAgentOptions {
    */
   agentId?: string
   /**
-   * The `tickets/<file>.md` this agent implements (#1117). Set by the daemon
-   * when it starts a drain agent and the queue entry it will work links back to a ticket, so the
-   * Overview can show that ticket as being implemented rather than guessing from its plan.
-   */
-  ticket?: string
-  /**
-   * This agent plans its {@link ticket} rather than implementing it. Set by
-   * the daemon on a fanned-out [Plan tickets] run (#1327), whose PR lands only the plan: the
-   * ticket still rides for the agent's meta, but the PR title must not inherit the issue as
-   * `(fix #42)` (#1334) — a plan's merge would close the issue with the work still undone.
+   * This agent plans a ticket rather than implementing it. Set by the daemon on a fanned-out
+   * [Plan tickets] run (#1327), whose PR lands only the plan: a closing phrase in its title or
+   * description must not close the ticket's issue (#1334) — a plan's merge would close the issue
+   * with the work still undone.
    */
   planAgent?: boolean
   /** Resume a finished agent's conversation (#720): its captured agent session id. The agent's prompt continues that session (full prior context) instead of starting fresh. Sent with `kind: 'prompt'` when you message an agent that has ended. */
diff --git a/packages/framework/src/e2e/story-projects-and-settings.test.ts b/packages/framework/src/e2e/story-projects-and-settings.test.ts
index b6d4e50c4..a7b4372d9 100644
--- a/packages/framework/src/e2e/story-projects-and-settings.test.ts
+++ b/packages/framework/src/e2e/story-projects-and-settings.test.ts
@@ -130,8 +130,8 @@ test('the usage panel reads the daemon quota source, and the sweep button fires
       nextSweepAt: 789,
       outcomes: [{ projectId: 'p', path: '/p', started: false, message: 'the queue is empty' }],
     }
-    const swept = await rpc(sendAutoPmSweep)({ only: 'drain' })
-    assert.deepEqual(world.autoPm.sweeps, [{ only: 'drain' }])
+    const swept = await rpc(sendAutoPmSweep)({ only: 'work' })
+    assert.deepEqual(world.autoPm.sweeps, [{ only: 'work' }])
     assert.equal(swept.ok, true)
     assert.equal(swept.outcomes?.[0]?.message, 'the queue is empty')
   } finally {
diff --git a/packages/framework/src/e2e/story-tickets-and-queue.test.ts b/packages/framework/src/e2e/story-tickets-and-queue.test.ts
index 654ed4d5b..167b9bacc 100644
--- a/packages/framework/src/e2e/story-tickets-and-queue.test.ts
+++ b/packages/framework/src/e2e/story-tickets-and-queue.test.ts
@@ -1,6 +1,6 @@
 import { strict as assert } from 'node:assert'
 import { test } from 'node:test'
-import { makeWorld, waitFor, withFakeAwait } from './harness.js'
+import { makeWorld } from './harness.js'
 import {
   onTickets,
   onTicket,
@@ -9,12 +9,12 @@ import {
   onQueue,
   onAgents,
 } from '../dashboard-rpc/reads.js'
-import { sendChoice, sendQueueTicket } from '../dashboard-rpc/control.js'
-import { presets } from '../preset-catalog.js'
+import { sendQueueTicket } from '../dashboard-rpc/control.js'
 
 // The roadmap stories (README.md): tickets are proposals, the flat TODO queue holds confirmed
-// work, and a drain agent claims the queue's next entry — the propose -> decide -> work loop the
-// Tickets and Queue pages drive.
+// work — the propose -> decide half of the loop the Tickets and Queue pages drive. Working the
+// queue is the daemon's (#1774): it starts an agent when the branch moves, and that agent reads
+// the skills itself.
 
 const TICKET_FILE = '2026-08-01_login-page.md'
 const TICKET = [
@@ -60,7 +60,7 @@ test('browse the ticket backlog: list, detail, and the cross-project pages (#697
   }
 })
 
-test('queue a ticket, then a drain run claims it and the boards show it in progress (#1164/#1117)', async () => {
+test('queue a ticket, and the boards show it queued (#1164)', async () => {
   const world = await makeWorld()
   const rpc = world.rpc
   try {
@@ -82,33 +82,12 @@ test('queue a ticket, then a drain run claims it and the boards show it in progr
     // The queued ticket shows on the hot-tickets rail.
     const hotQueued = await rpc(onHotTickets)()
     assert.ok(hotQueued.some(h => h.projectId === project.id && h.ticket.file === TICKET_FILE))
-
-    // A hand-fired drain resolves the queue's next entry to its ticket (#1117) — the agent's meta
-    // names it while the agent is live, which is what flips the boards to "implementing".
-    const agentId = await withFakeAwait('choices', () => world.startAgent(project, presets.drainQueue.render()))
-    const tail = await world.tailAgent(project, agentId)
-    const gate = await waitFor(() => tail.events.find(e => e.kind === 'choice'), 'the drain run to park')
-
-    const sent = (await world.spawnedSpecs())[0]!
-    assert.equal(sent.options.ticket, `tickets/${TICKET_FILE}`, 'the drain child carries its ticket')
-
-    const running = await waitFor(async () => {
-      const agent = (await rpc(onAgents)(project.id)).find(r => r.id === agentId)
-      return agent?.ticket ? agent : undefined
-    }, 'the run meta to name the claimed ticket')
-    assert.equal(running.ticket, `tickets/${TICKET_FILE}`)
-    const hot = await rpc(onHotTickets)()
-    const implementing = hot.find(h => h.ticket.file === TICKET_FILE && h.agentId === agentId)
-    assert.ok(implementing, 'the hot rail links the ticket to the run implementing it')
-
-    if (gate.kind === 'choice') await rpc(sendChoice)(project.id, gate.id, gate.recommended!, 'user', agentId)
-    await world.waitAgent(project, agentId, 'done')
   } finally {
     await world.close()
   }
 })
 
-test('any other prompt claims nothing: the queue is only worked by a drain (#1117)', async () => {
+test('a prompt that is not about the queue leaves the queue alone', async () => {
   const world = await makeWorld()
   const rpc = world.rpc
   try {
@@ -120,8 +99,7 @@ test('any other prompt claims nothing: the queue is only worked by a drain (#111
 
     const agentId = await world.startAgent(project, 'Look into the flaky CI job')
     await world.waitAgent(project, agentId, 'done')
-    const agent = (await rpc(onAgents)(project.id)).find(r => r.id === agentId)
-    assert.equal(agent?.ticket, undefined, 'an unrelated prompt must not wear the queued ticket')
+    assert.ok((await rpc(onAgents)(project.id)).some(r => r.id === agentId), 'the run is on the list')
     // The queue entry is still open: nothing consumed it.
     const projectQueue = (await rpc(onQueue)()).find(q => q.projectId === project.id)
     assert.equal(projectQueue?.open, 1)
diff --git a/packages/framework/src/events.test.ts b/packages/framework/src/events.test.ts
index cd64dde0f..4c73de782 100644
--- a/packages/framework/src/events.test.ts
+++ b/packages/framework/src/events.test.ts
@@ -182,10 +182,6 @@ test('formatFrameworkEvent gives the merge half of a handoff its own line, withh
     formatFrameworkEvent({ kind: 'handoff', outcome: 'done', pushed: true, merge: { outcome: 'withheld', reason: 'not-ready-for-merge' } })!,
     /~ merge withheld: the session never signalled ready-for-merge/,
   )
-  assert.match(
-    formatFrameworkEvent({ kind: 'handoff', outcome: 'skipped', reason: 'already-open', merge: { outcome: 'withheld', reason: 'session-todo-open' } })!,
-    /~ merge withheld: the session's own TODO file still has open entries/,
-  )
   // No merge half: the line stays exactly what it was.
   assert.equal(formatFrameworkEvent({ kind: 'handoff', outcome: 'done', pushed: true }), '✓ branch pushed')
   // A landed PR is not "the branch already has a pull request" (#1512): the reader was told their
diff --git a/packages/framework/src/events.ts b/packages/framework/src/events.ts
index 1858f556c..ce3f42e07 100644
--- a/packages/framework/src/events.ts
+++ b/packages/framework/src/events.ts
@@ -95,9 +95,7 @@ export type AutoHandoffSkip =
  */
 export type MergeWithheldReason =
   /** The agent never called setReadyForMerge(): the work was never declared done. */
-  | 'not-ready-for-merge'
-  /** The session's own `TODO_<SESSION_NAME>.agent.md` still has open entries. */
-  | 'session-todo-open'
+  'not-ready-for-merge'
 
 /**
  * How the merge half of a handoff went (#1216), when the agent was armed for it. Lives here beside
@@ -242,20 +240,10 @@ export type FrameworkEvent =
    * the conservative display. It has no checkbox and never changes mid-run, so re-emits repeat it.
    */
   | { kind: 'handoff-armed'; push: boolean; pr: boolean; merge?: boolean }
-  /**
-   * The ticket this agent was started to implement (#1117), as a repo-relative `tickets/<file>.md`.
-   *
-   * Emitted once at start, and only when the framework itself chose the ticket — today that is the
-   * [Drain queue] run, whose queue entry links back to the ticket it was queued from (#1164). An
-   * event rather than a start argument for the usual reason: only an event reaches the agent's meta,
-   * and the meta is what a dashboard tab opened mid-run reads. Absent means nobody knows what this
-   * run is implementing, which is every hand-written prompt.
-   */
-  | { kind: 'ticket'; path: string }
   /**
    * The pull request this session's work is on (E6), the moment one is opened for it.
    *
-   * An event for the same reason `ticket` and `branch` are: only an event reaches the agent's meta,
+   * An event for the same reason `branch` is: only an event reaches the agent's meta,
    * and the meta is what every later surface reads. Before this, each of them re-resolved the PR
    * live from the branch — trying the recorded branch, then the session-name branch, then the
    * run-id branch, and filtering the results by whether the PR predated the session — which is a
diff --git a/packages/framework/src/preset-catalog.test.ts b/packages/framework/src/preset-catalog.test.ts
index 266f8d24c..fff9d92c4 100644
--- a/packages/framework/src/preset-catalog.test.ts
+++ b/packages/framework/src/preset-catalog.test.ts
@@ -25,7 +25,6 @@ const PARAMLESS = [
   presets.suggestNewTickets,
   presets.suggestNewFeatures,
   presets.suggestTicketsToWorkOn,
-  presets.drainQueue,
   presets.triageQuick,
   presets.triageConsensual,
   presets.updateTickets,
@@ -37,7 +36,7 @@ test('every preset keeps its exact run-kind name', () => {
   assert.deepEqual(
     Object.values(presets).map(p => p.name).sort(),
     [
-      'drain-queue', 'maintainability', 'maintenance', 'market-research',
+      'maintainability', 'maintenance', 'market-research',
       'plan-tickets', 'readability', 'research', 'security-audit',
       'suggest-new-features', 'suggest-new-tickets', 'suggest-tickets-to-work-on',
       'triage-consensual', 'triage-quick', 'update-tickets', 'ux',
@@ -45,10 +44,9 @@ test('every preset keeps its exact run-kind name', () => {
   )
 })
 
-test('the launcher offers every preset except the daemon-only one', () => {
+test('the launcher offers every preset', () => {
   const offered = LAUNCHER_PRESETS.map(p => p.name)
-  assert.equal(offered.includes('drain-queue'), false, 'drain-queue is fired by the daemon only')
-  assert.equal(offered.length, Object.keys(presets).length - 1)
+  assert.equal(offered.length, Object.keys(presets).length)
   for (const preset of LAUNCHER_PRESETS) assert.ok(preset.label, `${preset.name} needs a label`)
 })
 
diff --git a/packages/framework/src/preset-catalog.ts b/packages/framework/src/preset-catalog.ts
index 973d0bb31..5e7c2dd5b 100644
--- a/packages/framework/src/preset-catalog.ts
+++ b/packages/framework/src/preset-catalog.ts
@@ -1,6 +1,5 @@
 import { definePreset, type PresetDef } from './preset-prompt.js'
 import {
-  PRESETS_DRAIN_QUEUE,
   PRESETS_MAINTAINABILITY,
   PRESETS_MAINTENANCE,
   PRESETS_MARKET_RESEARCH,
@@ -117,9 +116,6 @@ export const presets = {
    */
   suggestTicketsToWorkOn: definePreset({ name: 'suggest-tickets-to-work-on', template: PRESETS_SUGGEST_TICKETS_TO_WORK_ON, label: 'Suggest tickets to work on', tooltip: 'Add tickets to queue (TODO_AGENTS.md)' }),
 
-  /** [Drain queue] (#855): work the entries already on `TODO_AGENTS.md`. */
-  drainQueue: definePreset({ name: 'drain-queue', template: PRESETS_DRAIN_QUEUE, label: 'Spin up agents working on the AI queue', tooltip: 'Work the entries already on the queue (TODO_AGENTS.md)' }),
-
   /**
    * [Do quick-win work] (#891) and [Do consensual work] (#892): read `tickets/*.md`, pick the ones
    * matching one filter, and append them to `TODO_AGENTS.md` — how the queue refills itself from
@@ -144,29 +140,12 @@ export const presets = {
 /** The presets by key, e.g. `planTickets`. */
 export type PresetKey = keyof typeof presets
 
-/**
- * Whether a prompt is the one that takes work OFF the queue (#1117).
- *
- * The daemon knows a drain by the `drains` flag on its job; an agent started by hand arrives as bare
- * prompt text with no such marking, so the text is all there is to recognise it by. Compared
- * against the rendered preset rather than against a copy of its words, so rewording the preset
- * cannot leave this behind — that drift would show up only as a lane on the Overview quietly
- * staying empty, which is the kind of bug nobody reports.
- *
- * Deliberately exact: a prompt that merely mentions the queue is not a drain, and mistaking one
- * for the other would name a ticket as being implemented by an agent doing something else entirely.
- */
-export function drainsQueue(prompt: string): boolean {
-  return prompt.trim() === presets.drainQueue.render().trim()
-}
-
 /**
  * The presets the launcher offers, in the order it shows them.
  *
  * One list rather than a `launcher: true` flag on each row: membership and order are the same
- * decision, and a flag would have stated half of it while the order lived somewhere else. It is
- * also the answer to "which presets are user-facing" — `drainQueue` is absent because only the
- * daemon fires it, which previously had nothing marking it internal.
+ * decision, and a flag would have stated half of it while the order lived somewhere else. Every
+ * preset is on it: the routine only the daemon fires is a skill file now (#1774), not a preset.
  */
 export const LAUNCHER_PRESETS: readonly PresetDef[] = [
   presets.research,
diff --git a/packages/framework/src/registry.ts b/packages/framework/src/registry.ts
index a961db095..408d63c13 100644
--- a/packages/framework/src/registry.ts
+++ b/packages/framework/src/registry.ts
@@ -132,7 +132,7 @@ export interface Preferences {
    * Opted *out* rather than opted in, so the list only ever names exceptions: a routine added in a
    * later version is on for everyone, instead of silently never running for whoever saved the
    * setting before it shipped. It names routines rather than indexing them for the same reason
-   * {@link AutoPmJob.drains} is a flag — a reorder must not move which one is switched off.
+   * {@link AutoPmJob.works} is a flag — a reorder must not move which one is switched off.
    */
   autoPmOptOut?: string[]
   /**
diff --git a/packages/framework/src/store/agent-store.test.ts b/packages/framework/src/store/agent-store.test.ts
index 48ded7c07..86775c631 100644
--- a/packages/framework/src/store/agent-store.test.ts
+++ b/packages/framework/src/store/agent-store.test.ts
@@ -270,16 +270,6 @@ test('applyEventToMeta records the branch as observed, and ready-for-merge besid
   assert.equal(ready.branch, 'agent-add-comments') // ready doesn't clobber the branch
 })
 
-test('applyEventToMeta records the ticket a run is implementing (#1117)', () => {
-  assert.equal(BASE.ticket, undefined, 'a run nobody linked to a ticket says nothing')
-  const on = applyEventToMeta(BASE, { kind: 'ticket', path: 'tickets/2026-07-25_login.md' }, AT)
-  assert.equal(on.ticket, 'tickets/2026-07-25_login.md')
-  // It is a fact about why the agent exists, so it outlives the work: a reader looking at a finished
-  // run still gets to see which ticket it was.
-  const ended = applyEventToMeta(on, { kind: 'end', ok: true }, AT)
-  assert.equal(ended.ticket, 'tickets/2026-07-25_login.md')
-})
-
 test('applyEventToMeta tracks the pending choice gate a run is parked on (#636)', () => {
   assert.equal(BASE.pendingChoice, undefined)
   const asked = applyEventToMeta(BASE, { kind: 'choice', id: 'g1', title: 'Cache the auth store?', options: [{ id: 'y', label: 'Yes' }] }, AT)
diff --git a/packages/framework/src/store/agent-store.ts b/packages/framework/src/store/agent-store.ts
index 50eff2039..3b77247ac 100644
--- a/packages/framework/src/store/agent-store.ts
+++ b/packages/framework/src/store/agent-store.ts
@@ -94,14 +94,6 @@ export interface AgentMeta {
    * and on web runs whose pre-hand-off push failed.
    */
   cloudAnchor?: string
-  /**
-   * The ticket this agent is implementing (#1117), repo-relative (`tickets/<file>.md`).
-   *
-   * Set only when the framework picked the ticket itself, so the Overview can show a ticket that is
-   * being coded right now as `implementing` instead of inferring it from the plan/spike it left
-   * behind. Absent on every agent nobody linked to a ticket.
-   */
-  ticket?: string
   /**
    * The pull request this session's work is on (E6), recorded when one is opened rather than
    * re-derived from branch names and timestamps by every surface that wants it.
@@ -336,9 +328,6 @@ export function applyEventToMeta(meta: AgentMeta, event: FrameworkEvent, at: str
       else delete next.handoffSkip
       if (event.outcome !== 'failed' && event.merge) next.mergeOutcome = event.merge.outcome
       break
-    case 'ticket':
-      next.ticket = event.path
-      break
     case 'pull-request':
       next.pr = { number: event.number, url: event.url }
       break
diff --git a/packages/framework/src/store/run-record.test.ts b/packages/framework/src/store/run-record.test.ts
index 814cd8102..fafa28f67 100644
--- a/packages/framework/src/store/run-record.test.ts
+++ b/packages/framework/src/store/run-record.test.ts
@@ -23,11 +23,10 @@ test('the meta round-trips through the skill\'s card: eleven fields on top, the
     readyForMerge: true,
     mergeOutcome: 'auto-armed',
     pr: { number: 1765, url: 'https://x/pull/1765' },
-    ticket: 'tickets/2026-09-01_a.md',
     cost: 0.62,
   }
   const card = toRunCard(meta)
-  assert.deepEqual(Object.keys(card), ['id', 'startedAt', 'status', 'endedAt', 'intent', 'driver', 'model', 'branch', 'pr', 'ticket', 'cost', 'caller'])
+  assert.deepEqual(Object.keys(card), ['id', 'startedAt', 'status', 'endedAt', 'intent', 'driver', 'model', 'branch', 'pr', 'cost', 'caller'])
   assert.deepEqual(card.caller, { updatedAt: meta.updatedAt, pid: 923, host: 'laptop', kind: 'prompt', handoff: meta.handoff, workspace: '/w', readyForMerge: true, mergeOutcome: 'auto-armed' })
   assert.deepEqual(fromRunCard(card), meta)
   // The framework's last-updated time is its own, so even a bare meta carries a caller; a card
diff --git a/packages/framework/src/store/run-record.ts b/packages/framework/src/store/run-record.ts
index 4bb116cfd..5fd132fce 100644
--- a/packages/framework/src/store/run-record.ts
+++ b/packages/framework/src/store/run-record.ts
@@ -5,8 +5,9 @@ import type { AgentMeta } from './agent-store.js'
 
 /**
  * The framework's run, in the `logs` skill's two shapes (#1769). The skill owns what a run's card
- * says to an agent — eleven plain fields — and four kinds of diary line; everything else the
- * framework records is its own. So the card carries the framework's remaining meta under the one
+ * says to an agent — eleven plain fields, of which the framework fills ten: which ticket a run
+ * worked is the agent's own doing now, not the framework's to know (#1774) — and four kinds of
+ * diary line; everything else the framework records is its own. So the card carries the framework's remaining meta under the one
  * key the skill stores and never reads, `caller`, and the diary carries the framework's other
  * events as they are, among the four the skill knows. This module is the whole mapping, both
  * ways: the daemon writes through it at teardown, and every reader of an archived run — the run
@@ -15,7 +16,7 @@ import type { AgentMeta } from './agent-store.js'
 
 /** The framework's meta as the skill's card: the skill's fields on top, the rest under `caller`. */
 export function toRunCard(meta: AgentMeta): RunCard {
-  const { id, startedAt, endedAt, status, intent, driver, model, branch, pr, ticket, cost, ...caller } = meta
+  const { id, startedAt, endedAt, status, intent, driver, model, branch, pr, cost, ...caller } = meta
   const card: RunCard = { id, startedAt, status }
   if (endedAt !== undefined) card.endedAt = endedAt
   if (intent !== undefined) card.intent = intent
@@ -23,7 +24,6 @@ export function toRunCard(meta: AgentMeta): RunCard {
   if (model !== undefined) card.model = model
   if (branch !== undefined) card.branch = branch
   if (pr !== undefined) card.pr = pr
-  if (ticket !== undefined) card.ticket = ticket
   if (cost !== undefined) card.cost = cost
   if (Object.keys(caller).length > 0) card.caller = caller
   return card
diff --git a/packages/framework/src/system-prompt.ts b/packages/framework/src/system-prompt.ts
index a06a680fe..134389745 100644
--- a/packages/framework/src/system-prompt.ts
+++ b/packages/framework/src/system-prompt.ts
@@ -12,7 +12,7 @@ import { AWAIT_PROTOCOL, BROWSER_PROTOCOL, HANDS_OFF_PROTOCOL, SIGNAL_PROTOCOL }
  * anti-lazy-pill (#297/#301) it grew out of: the prompt is analyzed first — an
  * ambiguous one becomes a ranked `showChoices()` list, a
  * large scope becomes a PLAN file to approve, a very large one also spins off a TODO
- * backlog (consumed by the backlog loop, #323), the work moves onto its own
+ * backlog (#323), the work moves onto its own
  * `agent-<session>` branch before the first change, and the alternatives flow
  * rates problem "variability" before code is written.
  *
diff --git a/packages/framework/src/terminal.ts b/packages/framework/src/terminal.ts
index aa4307780..890882fd1 100644
--- a/packages/framework/src/terminal.ts
+++ b/packages/framework/src/terminal.ts
@@ -33,8 +33,6 @@ export function formatFrameworkEvent(event: FrameworkEvent): string {
       return `  pull request written${event.title ? `: ${event.title}` : ''}`
     case 'settled':
       return `◆ done for now — waiting for your next message`
-    case 'ticket':
-      return `  implementing ${event.path}`
     case 'branch':
       return `  branch: ${event.branch}`
     case 'cloud-anchor':
@@ -124,8 +122,6 @@ export function mergeWithheldWhy(reason: MergeWithheldReason): string {
   switch (reason) {
     case 'not-ready-for-merge':
       return 'the session never signalled ready-for-merge'
-    case 'session-todo-open':
-      return "the session's own TODO file still has open entries"
   }
 }
 
diff --git a/packages/framework/src/todo-loop.test.ts b/packages/framework/src/todo-loop.test.ts
deleted file mode 100644
index 5f46e9522..000000000
--- a/packages/framework/src/todo-loop.test.ts
+++ /dev/null
@@ -1,350 +0,0 @@
-import { strict as assert } from 'node:assert'
-import { test } from 'node:test'
-import { mkdir, mkdtemp, readFile, realpath, rename, rm, writeFile } from 'node:fs/promises'
-import { tmpdir } from 'node:os'
-import { join } from 'node:path'
-import { FakeDriver } from 'agent-driver'
-import type { ChoicePick, ChoiceRequest, FrameworkEvent } from './events.js'
-import { nextQueuedTicket, runTodoLoop, agentTodoPending, ticketForPrompt } from './todo-loop.js'
-import { drainsQueue, presets } from './preset-catalog.js'
-import { AUTO_PM_DRAIN_JOB, AUTO_PM_JOBS } from './auto-pm.js'
-import { fileBranchPath, nodeGitRunner, withFileBranch, DATA_BRANCH } from '@gemstack/agent-data'
-
-const git = nodeGitRunner()
-const RETRIED_RM = { recursive: true, force: true, maxRetries: 10 } as const
-
-async function tmpWorkspace(): Promise<string> {
-  return mkdtemp(join(tmpdir(), 'framework-todo-'))
-}
-
-/** A real repo: the queue lives on the `agent-data` branch (#1582/#1748), so the reads need actual git. */
-async function repoWorkspace(): Promise<string> {
-  const repo = await realpath(await mkdtemp(join(tmpdir(), 'framework-todo-repo-')))
-  await git(['init', '-b', 'main'], repo)
-  await git(['config', 'user.email', 't@t'], repo)
-  await git(['config', 'user.name', 't'], repo)
-  await writeFile(join(repo, 'README.md'), '# t\n')
-  await git(['add', '-A'], repo)
-  await git(['commit', '-m', 'init'], repo)
-  return repo
-}
-
-/** Put the queue on the `agent-data` branch, committed, the way every real writer does. */
-async function seedQueue(repo: string, md: string): Promise<void> {
-  const result = await withFileBranch(repo, DATA_BRANCH, 'seed', async dir => {
-    await writeFile(join(dir, 'TODO_AGENTS.md'), md, 'utf8')
-  })
-  assert.ok(result.ok, 'seeding the queue must land')
-}
-
-/** The queue as committed on the `agent-data` branch. */
-async function queueOnBranch(repo: string): Promise<string> {
-  return git(['show', `${DATA_BRANCH}:TODO_AGENTS.md`], repo)
-}
-
-test('runTodoLoop works the backlog to empty, one entry per turn, checking each off itself (#323/#1582)', async () => {
-  const repo = await repoWorkspace()
-  await seedQueue(repo, '- [ ] first task\n- [ ] second task\n')
-  try {
-    const events: FrameworkEvent[] = []
-    const prompts: string[] = []
-    // The fake driver only answers; the removal is the framework's own write.
-    const driver = new FakeDriver({
-      respond: (prompt, i) => {
-        prompts.push(prompt)
-        return `completed item ${i + 1}`
-      },
-    })
-    const session = await driver.start({ cwd: repo })
-    const result = await runTodoLoop({ session, cwd: repo, emit: e => events.push(e) })
-
-    assert.deepEqual(result, { completed: 2, reason: 'empty' })
-    assert.equal(prompts.length, 2)
-    assert.match(prompts[0]!, /first task/)
-    assert.match(prompts[0]!, /takes this entry off the queue/)
-    assert.match(prompts[1]!, /second task/)
-    assert.equal(await queueOnBranch(repo), '')
-    // Narrated: the opening count, each item, and the completion line.
-    assert.ok(events.some(e => e.kind === 'log' && /2 open item\(s\)/.test(e.message)))
-    assert.ok(events.some(e => e.kind === 'log' && /Queue item 1: first task/.test(e.message)))
-    assert.ok(events.some(e => e.kind === 'log' && /Queue item 2: second task/.test(e.message)))
-    assert.ok(events.some(e => e.kind === 'log' && /Queue done/.test(e.message)))
-    // Headless: no per-item gate events.
-    assert.equal(events.some(e => e.kind === 'choice'), false)
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('runTodoLoop returns empty without a backlog and emits nothing', async () => {
-  const cwd = await tmpWorkspace()
-  try {
-    const events: FrameworkEvent[] = []
-    const session = await new FakeDriver({ turns: [{ text: 'never prompted' }] }).start({ cwd })
-    const result = await runTodoLoop({ session, cwd, emit: e => events.push(e) })
-    assert.deepEqual(result, { completed: 0, reason: 'empty' })
-    assert.deepEqual(events, [])
-  } finally {
-    await rm(cwd, RETRIED_RM)
-  }
-})
-
-test('an interactive loop gates before each entry; picking stop ends it (#323)', async () => {
-  const repo = await repoWorkspace()
-  await seedQueue(repo, '- [ ] task a\n- [ ] task b\n')
-  try {
-    const events: FrameworkEvent[] = []
-    const gates: ChoiceRequest[] = []
-    // Accept the first gate, stop at the second.
-    const requestChoice = (req: ChoiceRequest): Promise<ChoicePick> => {
-      gates.push(req)
-      return Promise.resolve({ picked: gates.length === 1 ? 'proceed' : 'stop', by: 'user' })
-    }
-    const session = await new FakeDriver({ respond: () => 'did task a' }).start({ cwd: repo })
-    const result = await runTodoLoop({ session, cwd: repo, emit: e => events.push(e), requestChoice })
-
-    assert.deepEqual(result, { completed: 1, reason: 'stopped' })
-    assert.equal(gates.length, 2)
-    assert.equal(gates[0]!.id, 'todo-next')
-    assert.equal(gates[1]!.id, 'todo-next-1')
-    assert.match(gates[0]!.options[0]!.label, /Work on: task a/)
-    assert.equal(gates[0]!.recommended, 'proceed')
-    assert.equal(await queueOnBranch(repo), '- [ ] task b\n')
-    assert.ok(events.some(e => e.kind === 'log' && /stopped by you/.test(e.message)))
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('a removal that cannot land stops the loop instead of re-working the entry (#1582)', async () => {
-  const repo = await repoWorkspace()
-  await seedQueue(repo, '- [ ] stubborn task\n- [ ] never reached\n')
-  try {
-    // Break the branch's checkout: the branch still reads (git show), but the write funnel cannot
-    // have its worktree, so every removal fails.
-    await git(['worktree', 'remove', '--force', fileBranchPath(repo, DATA_BRANCH)], repo)
-    await writeFile(fileBranchPath(repo, DATA_BRANCH), 'not a directory\n')
-    const events: FrameworkEvent[] = []
-    const session = await new FakeDriver({ respond: () => 'worked it' }).start({ cwd: repo })
-    const result = await runTodoLoop({ session, cwd: repo, emit: e => events.push(e) })
-    assert.deepEqual(result, { completed: 1, reason: 'stalled' })
-    assert.ok(events.some(e => e.kind === 'log' && /could not be taken off the queue/.test(e.message)))
-    // The queue is untouched: better an open entry than a lost removal.
-    assert.equal(await queueOnBranch(repo), '- [ ] stubborn task\n- [ ] never reached\n')
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('runTodoLoop honors the item cap and reports what is left', async () => {
-  const repo = await repoWorkspace()
-  await seedQueue(repo, '- [ ] a\n- [ ] b\n- [ ] c\n')
-  try {
-    const events: FrameworkEvent[] = []
-    const session = await new FakeDriver({ respond: (_p, i) => `turn ${i + 1}` }).start({ cwd: repo })
-    const result = await runTodoLoop({ session, cwd: repo, emit: e => events.push(e), maxItems: 2 })
-    assert.deepEqual(result, { completed: 2, reason: 'max-items' })
-    assert.ok(events.some(e => e.kind === 'log' && /2-item cap.*1 item\(s\) left/.test(e.message)))
-    assert.equal(await queueOnBranch(repo), '- [ ] c\n')
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('an item turn that stops to ask is gated and resumed like any await gate (#337)', async () => {
-  const repo = await repoWorkspace()
-  await seedQueue(repo, '- [ ] pick a database\n')
-  const gateTurn = [
-    'Which database?',
-    '```await-choices',
-    JSON.stringify({ title: 'Which database?', options: [{ label: 'SQLite' }, { label: 'Postgres' }], recommended: 'SQLite' }),
-    '```',
-  ].join('\n')
-  try {
-    const events: FrameworkEvent[] = []
-    const prompts: string[] = []
-    const session = await new FakeDriver({
-      respond: (prompt, i) => {
-        prompts.push(prompt)
-        if (i === 0) return gateTurn // the item turn stops to ask
-        return 'picked and done'
-      },
-    }).start({ cwd: repo })
-    const requestChoice = (req: ChoiceRequest): Promise<ChoicePick> =>
-      Promise.resolve({ picked: req.id.startsWith('todo-next') ? 'proceed' : 'opt:1', by: 'user' })
-    const result = await runTodoLoop({ session, cwd: repo, emit: e => events.push(e), requestChoice })
-
-    assert.deepEqual(result, { completed: 1, reason: 'empty' })
-    assert.equal(prompts.length, 2)
-    assert.match(prompts[1]!, /The user chose: Postgres/)
-    const ids = events.filter(e => e.kind === 'choice').map(e => (e as { id: string }).id)
-    assert.deepEqual(ids, ['todo-next', 'await-choices'])
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('an aborted signal ends the loop before starting another entry', async () => {
-  const cwd = await tmpWorkspace()
-  try {
-    const controller = new AbortController()
-    controller.abort()
-    const session = await new FakeDriver({ respond: () => 'never' }).start({ cwd })
-    const result = await runTodoLoop({ session, cwd, emit: () => {}, signal: controller.signal })
-    // Aborted before item 1: nothing worked, reported as a clean stop.
-    assert.deepEqual(result, { completed: 0, reason: 'stopped' })
-  } finally {
-    await rm(cwd, RETRIED_RM)
-  }
-})
-
-test('a backlog turn emits its signals: views, errors, ready-for-merge', async () => {
-  const repo = await repoWorkspace()
-  await seedQueue(repo, '- [ ] tidy the login redirect\n')
-  try {
-    const events: FrameworkEvent[] = []
-    // The protocols are unconditional, so the agent is told it can signal on ANY turn,
-    // a backlog turn included. Everything it emits has to reach the agent stream.
-    const driver = new FakeDriver({
-      respond: () =>
-        [
-          'Done.',
-          '```show-markdown',
-          '# What I changed',
-          'Rewrote the redirect guard.',
-          '```',
-          '```error',
-          'the redirect test fixture is missing',
-          '',
-          'ran `ls test/fixtures`: No such file or directory',
-          '```',
-          '```ready-for-merge',
-          '```',
-        ].join('\n'),
-    })
-    const session = await driver.start({ cwd: repo })
-    await runTodoLoop({ session, cwd: repo, emit: e => events.push(e) })
-
-    const view = events.find(e => e.kind === 'view')
-    assert.equal(view?.title, 'What I changed')
-    assert.deepEqual(
-      events.filter(e => e.kind === 'error'),
-      [
-        {
-          kind: 'error',
-          headline: 'the redirect test fixture is missing',
-          detail: 'ran `ls test/fixtures`: No such file or directory',
-        },
-      ],
-    )
-    assert.equal(events.filter(e => e.kind === 'ready-for-merge').length, 1)
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('ready-for-merge is emitted once across a multi-item backlog', async () => {
-  const repo = await repoWorkspace()
-  await seedQueue(repo, '- [ ] first task\n- [ ] second task\n')
-  try {
-    const events: FrameworkEvent[] = []
-    // Both items signal ready-for-merge; the loop's one emitter dedupes them.
-    const session = await new FakeDriver({ respond: () => 'Done.\n```ready-for-merge\n```' }).start({ cwd: repo })
-    const result = await runTodoLoop({ session, cwd: repo, emit: e => events.push(e) })
-
-    assert.equal(result.completed, 2)
-    assert.equal(events.filter(e => e.kind === 'ready-for-merge').length, 1)
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('nextQueuedTicket names the ticket the next drain run will pick up (#1117)', async () => {
-  const repo = await repoWorkspace()
-  try {
-    // Nothing queued at all: nothing to name.
-    assert.equal(await nextQueuedTicket(repo), undefined)
-
-    // The drain preset works "the FIRST open entry only", so that is the entry this reads --
-    // priority order is already the file order the queue is written in (#1164).
-    await seedQueue(
-      repo,
-      [
-        '## Priority 9',
-        '',
-        '- [x] [Already done](tickets/2026-07-01_done.md)',
-        '- [ ] [Add a login page](tickets/2026-07-25_login.md)',
-        '',
-        '## Priority 5',
-        '',
-        '- [ ] [Later](tickets/2026-07-26_later.md)',
-        '',
-      ].join('\n'),
-    )
-    assert.equal(await nextQueuedTicket(repo), 'tickets/2026-07-25_login.md')
-
-    // A queue whose first open entry is plain text: a drain agent there implements no ticket, and
-    // saying "the one below it" would label the wrong ticket as being worked.
-    await seedQueue(repo, '- [ ] tidy the README\n- [ ] [Login](tickets/2026-07-25_login.md)\n')
-    assert.equal(await nextQueuedTicket(repo), undefined)
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('ticketForPrompt names a ticket for a hand-fired drain, and for nothing else (#1117)', async () => {
-  const repo = await repoWorkspace()
-  try {
-    await seedQueue(repo, ['## Priority 9', '', '- [ ] [Add a login page](tickets/2026-07-25_login.md)', ''].join('\n'))
-
-    // The drain preset, whatever its current wording: the sweep's own prompt, arriving by hand.
-    assert.equal(await ticketForPrompt(presets.drainQueue.render(), repo), 'tickets/2026-07-25_login.md')
-    // Leading/trailing whitespace is what a textarea adds, not a different instruction.
-    assert.equal(await ticketForPrompt(`\n${presets.drainQueue.render()}  `, repo), 'tickets/2026-07-25_login.md')
-
-    // Every other prompt implements whatever it likes; naming the queue's next entry for it would
-    // put a ticket in the in-progress lane on the strength of an unrelated agent.
-    assert.equal(await ticketForPrompt('Work on the queue please', repo), undefined)
-    assert.equal(await ticketForPrompt(presets.planTickets.render(), repo), undefined)
-    assert.equal(await ticketForPrompt('', repo), undefined)
-
-    // A read that throws is a lane label, not an agent: it must never take the start down with it.
-    const boom = async () => {
-      throw new Error('unreadable queue')
-    }
-    assert.equal(await ticketForPrompt(presets.drainQueue.render(), repo, boom), undefined)
-  } finally {
-    await rm(repo, RETRIED_RM)
-  }
-})
-
-test('the drain the sweep fires and the drain a click fires are the same drain (#1117)', () => {
-  // The daemon recognises its drain by the `drains` flag on the job; a click has only the text.
-  // If those two ever name different prompts, a hand-fired drain silently stops tagging tickets,
-  // which shows up as an empty lane rather than as an error.
-  assert.equal(AUTO_PM_DRAIN_JOB.drains, true)
-  assert.equal(drainsQueue(AUTO_PM_DRAIN_JOB.prompt), true)
-  // And nothing that merely puts work ON the queue counts as taking it off.
-  for (const job of AUTO_PM_JOBS) assert.equal(drainsQueue(job.prompt), false, `${job.name} is not a drain`)
-})
-
-test('agentTodoPending reads only the session-named TODO file (#1363)', async () => {
-  const cwd = await tmpWorkspace()
-  try {
-    // No file: no pendingness known. The global queue must not count — it is decoupled from
-    // sessions (#1390), and counting it would mean auto-merge never fires while any backlog exists.
-    assert.equal(await agentTodoPending(cwd, 'fix-login'), false)
-
-    // The session's own file with an open entry withholds; all-checked releases.
-    await writeFile(join(cwd, 'TODO_fix-login.agent.md'), '- [x] done part\n- [ ] open part\n')
-    assert.equal(await agentTodoPending(cwd, 'fix-login'), true)
-    await writeFile(join(cwd, 'TODO_fix-login.agent.md'), '- [x] done part\n- [x] open part\n')
-    assert.equal(await agentTodoPending(cwd, 'fix-login'), false)
-
-    // No session name, or one that cannot name a file, knows of nothing pending.
-    assert.equal(await agentTodoPending(cwd, undefined), false)
-    assert.equal(await agentTodoPending(cwd, '../escape'), false)
-  } finally {
-    await rm(cwd, RETRIED_RM)
-  }
-})
diff --git a/packages/framework/src/todo-loop.ts b/packages/framework/src/todo-loop.ts
deleted file mode 100644
index 28c1be167..000000000
--- a/packages/framework/src/todo-loop.ts
+++ /dev/null
@@ -1,233 +0,0 @@
-import { readFile } from 'node:fs/promises'
-import { join } from 'node:path'
-import type { DriverSession } from 'agent-driver'
-import { parseQueueEntries, queueDone, readQueueEntries } from '@gemstack/skill-queue'
-import { ticketFromQueueEntry } from '@gemstack/skill-tickets'
-import type { ChoicePick, ChoiceRequest, FrameworkEvent } from './events.js'
-import { requestChoices, runAwaitRounds } from './await-gate.js'
-import { drainsQueue } from './preset-catalog.js'
-import { createTurnSignalEmitter } from './turn-gate.js'
-
-/**
- * The backlog loop (#323): once the main work settles, consume the agent queue one entry per
- * turn until it is empty. The agent writes the queue itself (a very large scope, the Maintenance
- * follow-ups, or the [Research] preset's deep-dive picks all add entries); the framework only
- * drives: read the queue, gate ("start the next item?") when someone can answer, prompt the agent
- * to complete exactly one entry, take it off the queue, repeat. Termination is Rom's call on the
- * issue: stop when the queue is empty. The dashboard's autopilot auto-accepts the per-item gate,
- * so `[x] autopilot` consumes the whole queue unattended; autopilot off pauses before each entry.
- *
- * The queue is the `queue` skill's (#1748): it lives on the `agent-data` branch, read and changed
- * through the skill's library — the framework holds no copy and edits no file of its own. Which
- * ticket an entry links to is the `tickets` skill's rule.
- */
-
-/**
- * Does this session's own backlog still have open work (#1363)?
- *
- * Reads only `TODO_<SESSION_NAME>.agent.md` — the file the [Research] preset (and a very-large
- * scope) has the agent keep for its own session. Never the global queue: the queue is decoupled
- * from sessions (#1390), and withholding a merge on it would mean auto-merge never fires while
- * the project has any backlog at all. `false` on a missing or unreadable file, and on a session
- * name that could not name a file — no pendingness known is not pendingness.
- *
- * TEMPORARY SAFETY BELT, built to be deleted (#1390): the agent's setReadyForMerge() is the
- * authorization, and this only catches the agent declaring done while its own session file says
- * otherwise. When the agent's word is deemed enough, delete this function and its single call
- * site in `maybeAutoHandoff`.
- */
-export async function agentTodoPending(cwd: string, sessionName: string | undefined): Promise<boolean> {
-  // The prompt asks for [a-z0-9-]+; anything wider (a path separator above all) names no file.
-  if (!sessionName || !/^[A-Za-z0-9._-]+$/.test(sessionName)) return false
-  const md = await readFile(join(cwd, `TODO_${sessionName}.agent.md`), 'utf8').catch(() => undefined)
-  return md !== undefined && parseQueueEntries(md).length > 0
-}
-
-/**
- * The ticket the next drain agent will pick up, or `undefined` when there is none (#1117).
- *
- * "Next" is the first open entry of the queue, because that is what the [Drain queue] preset
- * says to work ("the FIRST open entry only") and the queue reads in file order. Read from the
- * same copy the sweep already consults when it decides whether there is anything to drain, so
- * the entry this names is the entry that decision was made on.
- *
- * A best guess by construction: the agent reads the queue a moment later, and an entry taken off
- * in between would move it on. Being wrong here costs a mislabelled lane on the Overview and
- * nothing else — no run is started or steered by this.
- */
-export async function nextQueuedTicket(cwd: string): Promise<string | undefined> {
-  const first = (await readQueueEntries(cwd))[0]
-  return first ? ticketFromQueueEntry(first) : undefined
-}
-
-/**
- * The ticket an agent started by hand is about to implement, when that agent is a drain (#1117).
- *
- * The daemon already does this for the sweep's own drain, off the `drains` flag on the job. An agent
- * fired from the dashboard reaches the same start with none of that context, so a hand-fired drain
- * showed up working on nothing: the agent implemented the ticket, and the lane it belonged in stayed
- * empty. Same read as the sweep's, so both agree on which entry is next.
- *
- * Undefined for anything that is not a drain, and for a drain over an empty queue. The `read` seam
- * is for tests; production always takes the default.
- */
-export async function ticketForPrompt(
-  prompt: string,
-  cwd: string,
-  read: (cwd: string) => Promise<string | undefined> = nextQueuedTicket,
-): Promise<string | undefined> {
-  if (!drainsQueue(prompt)) return undefined
-  return read(cwd).catch(() => undefined)
-}
-
-/** Why the loop ended. */
-export type TodoLoopReason =
-  /** The queue is empty (or was never written) — the success case. */
-  | 'empty'
-  /** The user picked "stop" at a per-item gate. */
-  | 'stopped'
-  /** Two removals in a row could not be written to the `agent-data` branch. */
-  | 'stalled'
-  /** The item cap was reached with entries still open. */
-  | 'max-items'
-
-/** What {@link runTodoLoop} resolves with. */
-export interface TodoLoopResult {
-  /** Queue entries worked (turns taken), regardless of outcome. */
-  completed: number
-  /** Why the loop ended. */
-  reason: TodoLoopReason
-  /**
-   * An answer marked `stop` (#358) inside an item's turn — a plan the user declined — ends the
-   * whole session, not just the loop. Distinct from the benign `reason: 'stopped'` per-item gate,
-   * which only stops draining the queue. The caller aborts the session on this.
-   */
-  sessionStopped?: boolean
-}
-
-/** Options for {@link runTodoLoop}. */
-export interface TodoLoopOptions {
-  /** The live driver session the agent already owns. */
-  session: DriverSession
-  /** The agent's checkout; the queue is read from the repository it belongs to. */
-  cwd: string
-  /** Emit the loop's events onto the agent stream. */
-  emit: (event: FrameworkEvent) => void
-  /**
-   * The interactive gate handler (#304). When wired, the loop pauses before each
-   * entry ("start the next item?") — the dashboard's autopilot auto-accepts, so
-   * autopilot off means a human gate per item (#323). Headless runs don't pause.
-   */
-  requestChoice?: ((req: ChoiceRequest) => Promise<ChoicePick>) | undefined
-  /** The agent signal; aborting (the Stop button, an answer marked stop) ends the loop. */
-  signal?: AbortSignal | undefined
-  /** Hard cap on entries worked in one agent. Default {@link DEFAULT_MAX_TODO_ITEMS}. */
-  maxItems?: number | undefined
-}
-
-/** The default per-agent cap on queue entries, so one agent cannot work the queue forever. */
-const DEFAULT_MAX_TODO_ITEMS = 25
-
-/** How many consecutive failed removals before the loop stops rather than spins. */
-const MAX_STALLS = 2
-
-/**
- * Drive the queue to empty: read the next open entry (fresh off the `agent-data` branch), gate, prompt
- * the agent to complete exactly that entry, take it off the queue, and repeat. The removal is the
- * framework's, not the agent's (#1582): the queue lives on a branch the agent's checkout does not
- * hold, and the one writer model keeps every edit going through the same funnel. Caps make it
- * safe to leave unattended (#322's concern): the agent's budget/abort signal ends any turn, a
- * hard item cap bounds the agent, and two removals in a row failing to land stop the loop
- * instead of re-working the same entry. A queue turn is a turn like any other: await gates
- * (`showChoices()` / `showMultiSelect()`) and the signals (`showMarkdown()`, `setReadyForMerge()`,
- * `open-pr`) are honored here too.
- */
-export async function runTodoLoop(opts: TodoLoopOptions): Promise<TodoLoopResult> {
-  const { session, cwd, emit } = opts
-  const maxItems = opts.maxItems ?? DEFAULT_MAX_TODO_ITEMS
-  // One emitter for the whole queue, so ready-for-merge fires once across every item
-  // and a pull-request description only re-emits when it changes.
-  const gateDeps = {
-    requestChoice: opts.requestChoice,
-    emit,
-    signal: opts.signal,
-    emitTurnSignals: createTurnSignalEmitter(emit),
-  }
-
-  let completed = 0
-
-  // The queue emptied: announce it if we did any work, and report a clean finish.
-  // Both the mid-loop find and the post-loop re-check funnel through here.
-  const finishEmpty = (): TodoLoopResult => {
-    if (completed > 0) emit({ kind: 'log', message: `Queue done: empty after ${completed} item(s).` })
-    return { completed, reason: 'empty' }
-  }
-
-  for (let item = 0; item < maxItems; item++) {
-    if (opts.signal?.aborted) break
-    const entries = await readQueueEntries(cwd, { fresh: true })
-    if (!entries.length) return finishEmpty()
-    const next = entries[0]!
-    const preview = next.length > 100 ? `${next.slice(0, 100)}…` : next
-
-    if (item === 0) emit({ kind: 'log', message: `Queue: ${entries.length} open item(s).` })
-
-    // The per-item gate (#323): pause before starting a new entry when someone
-    // can answer. Interactive-only, like the plan-approval gate — a headless agent
-    // emits no gate and just proceeds (autopilot semantics, budget-capped).
-    if (opts.requestChoice) {
-      const picked = await requestChoices({
-        id: item === 0 ? 'todo-next' : `todo-next-${item}`,
-        title: `Start the next queue item? (${entries.length} open)`,
-        options: [
-          { id: 'proceed', label: `Work on: ${preview}` },
-          { id: 'stop', label: 'Stop the queue loop' },
-        ],
-        recommended: 'proceed',
-        requestChoice: opts.requestChoice,
-        emit,
-        ...(opts.signal ? { signal: opts.signal } : {}),
-      })
-      if (picked === 'stop') {
-        emit({ kind: 'log', message: `Queue loop stopped by you (${entries.length} item(s) left).` })
-        return { completed, reason: 'stopped' }
-      }
-    }
-
-    emit({ kind: 'log', message: `Queue item ${completed + 1}: ${preview}` })
-    // Complete exactly this entry, honoring await gates. The queue is not the agent's to touch
-    // (#1582): it lives on the `agent-data` branch, and the removal below is the framework's.
-    const prompt = `Work on exactly this task from the project's agent queue, and nothing else:\n\n${next}\n\nComplete it fully and verify your work. Do not start any other task; the framework takes this entry off the queue when the turn ends.`
-    const rounds = await runAwaitRounds({ session, prompt, ...gateDeps })
-    completed++
-    // A plan the user declined with a stop-marked answer (#358) ends the whole session, not just
-    // this loop — so the session does not go on to publish work that was just rejected. The caller
-    // aborts on `sessionStopped`; `reason` stays descriptive of the loop itself.
-    if (rounds.stopped) {
-      emit({ kind: 'log', message: `Session stopped by your answer (${entries.length} item(s) left).` })
-      return { completed, reason: 'stopped', sessionStopped: true }
-    }
-
-    // Take the entry off the queue. A no-op when someone else already removed it meanwhile — the
-    // write re-reads the fresh queue either way. Retried inline rather than across rounds: a
-    // removal that never lands would re-serve the same entry, and re-doing finished work is worse
-    // than stopping with the queue intact.
-    let landed = false
-    for (let tries = 0; tries < MAX_STALLS && !landed; tries++) {
-      landed = (await queueDone(cwd, next)).ok
-    }
-    if (!landed) {
-      emit({ kind: 'log', message: `Queue loop stopped: "${preview}" could not be taken off the queue after ${MAX_STALLS} attempt(s).` })
-      return { completed, reason: 'stalled' }
-    }
-  }
-
-  // Aborted mid-loop (the Stop button, an answer marked stop): the agent is ending anyway,
-  // so report a clean stop without extra narration.
-  if (opts.signal?.aborted) return { completed, reason: 'stopped' }
-
-  const remaining = await readQueueEntries(cwd)
-  if (!remaining.length) return finishEmpty()
-  emit({ kind: 'log', message: `Queue loop stopped at the ${maxItems}-item cap; ${remaining.length} item(s) left.` })
-  return { completed, reason: 'max-items' }
-}
diff --git a/packages/framework/src/turn-gate.ts b/packages/framework/src/turn-gate.ts
index 26f0cd2c5..4baac37ca 100644
--- a/packages/framework/src/turn-gate.ts
+++ b/packages/framework/src/turn-gate.ts
@@ -89,13 +89,13 @@ export interface ParsedAwaitGate {
 /**
  * How many times the agent may stop to ask, and be resumed, before an agent stops honoring
  * gates and just finishes. A property of the await protocol, so every path that runs gates
- * shares it: a build, a direct prompt, and the backlog loop each used to declare their own.
+ * shares it: a build and a direct prompt each used to declare their own.
  */
 export const MAX_AWAIT_ROUNDS = 5
 
 /**
  * The prompt that resumes the agent after the user answers a gate. One wording for
- * every path that runs gates (a direct prompt, the backlog loop, a build): the agent
+ * every path that runs gates (a direct prompt, a build): the agent
  * already knows what it is working on from the session, so the clause that used to
  * vary per caller ("Continue" / "Continue the backlog entry" / "Continue building X")
  * carried no distinct meaning to it. One constant so a reword lands everywhere at once
diff --git a/packages/skill-branches/src/checkout.ts b/packages/skill-branches/src/checkout.ts
index 7ea35761d..4e5d1fd0a 100644
--- a/packages/skill-branches/src/checkout.ts
+++ b/packages/skill-branches/src/checkout.ts
@@ -12,10 +12,7 @@ import { linkSkill, type SkillLink } from './skill-links.js'
  * daemon allocating a run, the command line).
  */
 
-/**
- * Other skills to link into the checkout beside this package's own. TEMPORARY (#1748): see
- * `SkillLink` — gone once skills are committed into the repository.
- */
+/** Other skills to link into the checkout beside this package's own: see `SkillLink`. */
 export interface CheckoutSkills {
   skills?: readonly SkillLink[]
 }
diff --git a/packages/skill-branches/src/skill-links.ts b/packages/skill-branches/src/skill-links.ts
index 11a22a9ec..ed8d8c28d 100644
--- a/packages/skill-branches/src/skill-links.ts
+++ b/packages/skill-branches/src/skill-links.ts
@@ -29,10 +29,9 @@ export const SKILL_DIR = join(dirname(fileURLToPath(import.meta.url)), '..')
  * A skill to link into a checkout: its name (the directory a harness lists it under) and the
  * directory holding its `SKILL.md`.
  *
- * TEMPORARY (#1748): a caller names the *other* skills it wants in a checkout — the `tickets`
- * skill, today — because nothing else puts a skill there yet. Dies when the skills are committed
- * into the repository by use-npm-skills: a tracked `.claude/skills/<name>` is in every worktree by
- * itself, and this package goes back to linking only its own.
+ * A caller names the skills it ships itself and wants in every checkout it makes — the daemon's
+ * routine skills, which live with the daemon and not in the repository. A skill a project uses
+ * is the project's own tracked `.claude/skills/<name>`, in every worktree by itself.
  */
 export interface SkillLink {
   name: string
@@ -44,7 +43,7 @@ export const OWN_SKILL: SkillLink = { name: SKILL_NAME, dir: SKILL_DIR }
 
 /**
  * Link the skill into `checkout` for every harness — this package's own, plus whatever `skills`
- * the caller names (temporary, see {@link SkillLink}) — and hide the links from the project's git
+ * the caller names (see {@link SkillLink}) — and hide the links from the project's git
  * through the repository's exclude file: a symlink at the checkout root would otherwise ride any
  * sweeping `git add -A` onto the agent's branch. Best-effort: an entry already at a link's path is
  * left alone, and a link that cannot be made is a worse run, not a failed one.

From d7f69a3daa2cb69e9e087374c4d8f5b6742f8bd0 Mon Sep 17 00:00:00 2001
From: Suleiman Shahbari <suleiman@averotech.com>
Date: Sun, 13 Sep 2026 22:12:55 +0300
Subject: [PATCH 2/5] LOGIC.md beside every file the daemon half touched

The sweep's logic rewritten around the branch head, the chain and the
heartbeat; the daemon's signed writes and the routine skill get their
own; the drain, the backlog loop, the ticket lane and the (fix #N)
title leave every file that described them.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DAh91ACHayiEsgT1k2i8Nf
---
 .../dashboard/components/AiQueue.LOGIC.md     |  10 +-
 .../components/DashboardPage.LOGIC.md         |   2 +-
 .../dashboard/components/HotTickets.LOGIC.md  |  17 +-
 .../components/HotTickets.test.LOGIC.md       |   6 +-
 .../dashboard/components/Quota.LOGIC.md       |   2 +-
 .../dashboard/components/RoutineWork.LOGIC.md |  26 +--
 .../components/RoutineWork.test.LOGIC.md      |   4 +-
 .../components/SettingsPage.LOGIC.md          |   2 +-
 .../dashboard/components/TicketsPage.LOGIC.md |   4 +-
 .../components/TicketsPage.test.LOGIC.md      |   2 +-
 .../components/TicketsPanel.LOGIC.md          |   8 +-
 .../components/TicketsPanel.test.LOGIC.md     |   2 +-
 .../dashboard/lib/preferences.LOGIC.md        |   2 +-
 .../framework/dashboard/lib/quota.LOGIC.md    |   2 +-
 .../framework/dashboard/rpc/quota.LOGIC.md    |   6 +-
 .../on_before_mergeable_prompt.LOGIC.md       |   2 +-
 packages/framework/prompts/presets/LOGIC.md   |   9 +-
 .../prompts/presets/drain_queue.LOGIC.md      |  21 --
 .../prompts/presets/maintenance.LOGIC.md      |   2 +-
 .../prompts/presets/plan_tickets.LOGIC.md     |   2 +-
 .../presets/triage_consensual.LOGIC.md        |   2 +-
 .../prompts/presets/triage_quick.LOGIC.md     |   2 +-
 .../prompts/presets/update_tickets.LOGIC.md   |   2 +-
 packages/framework/skills/LOGIC.md            |   3 +
 .../skills/work-queue/SKILL.LOGIC.md          |  16 ++
 packages/framework/src/LOGIC.md               |   4 +-
 packages/framework/src/agent-locks.LOGIC.md   |   2 +-
 packages/framework/src/agent.LOGIC.md         |  43 +---
 packages/framework/src/agent.test.LOGIC.md    |   5 +-
 packages/framework/src/auto-pm.LOGIC.md       | 220 ++++++++++--------
 packages/framework/src/auto-pm.test.LOGIC.md  | 117 ++++------
 packages/framework/src/await-gate.LOGIC.md    |   3 +-
 packages/framework/src/cli.LOGIC.md           |  24 +-
 packages/framework/src/cli.test.LOGIC.md      |   2 +-
 packages/framework/src/client.LOGIC.md        |   8 +-
 packages/framework/src/cloud-work.LOGIC.md    |   2 +-
 .../framework/src/daemon-runtime.LOGIC.md     |  16 +-
 .../src/daemon-runtime.test.LOGIC.md          |   1 +
 .../framework/src/daemon-services.LOGIC.md    |  54 ++---
 .../src/daemon-services.test.LOGIC.md         |  13 +-
 .../src/daemon-workspace.test.LOGIC.md        |   2 +-
 packages/framework/src/daemon-writes.LOGIC.md |  43 ++++
 .../framework/src/daemon-writes.test.LOGIC.md |   5 +
 packages/framework/src/daemon.LOGIC.md        |   6 +-
 packages/framework/src/daemon.test.LOGIC.md   |   1 +
 .../src/dashboard-rpc/context.LOGIC.md        |   2 +-
 .../src/dashboard-rpc/control.LOGIC.md        |  12 +-
 .../src/dashboard-rpc/control.test.LOGIC.md   |   1 -
 .../src/dashboard-rpc/events.LOGIC.md         |   2 +-
 .../src/dashboard-rpc/preferences.LOGIC.md    |   2 +-
 .../src/dashboard-rpc/quota.LOGIC.md          |  12 +-
 .../src/dashboard-rpc/quota.test.LOGIC.md     |   6 +-
 .../src/dashboard-rpc/reads.LOGIC.md          |   4 +-
 .../src/dashboard/agent-handoff.LOGIC.md      |   6 +-
 .../src/dashboard/agent-handoff.test.LOGIC.md |   4 +-
 .../framework/src/dashboard/docs.LOGIC.md     |   2 +-
 packages/framework/src/dashboard/gh.LOGIC.md  |   2 +-
 .../src/dashboard/git-status.LOGIC.md         |   2 +-
 .../framework/src/dashboard/overview.LOGIC.md |   8 +-
 .../src/dashboard/overview.test.LOGIC.md      |   4 +-
 .../framework/src/dashboard/queue.LOGIC.md    |   4 +-
 .../framework/src/dashboard/quota.LOGIC.md    |   2 +-
 .../src/dashboard/rpc-serve.LOGIC.md          |   2 +-
 .../framework/src/dashboard/server.LOGIC.md   |   2 +-
 .../framework/src/dashboard/tickets.LOGIC.md  |   2 +-
 .../framework/src/dashboard/types.LOGIC.md    |   2 +-
 packages/framework/src/e2e/LOGIC.md           |   6 +-
 packages/framework/src/e2e/harness.LOGIC.md   |   2 +-
 .../e2e/story-tickets-and-queue.test.LOGIC.md |   6 +-
 packages/framework/src/events.LOGIC.md        |  11 +-
 packages/framework/src/events.test.LOGIC.md   |   2 +-
 packages/framework/src/maintenance.LOGIC.md   |   4 +-
 .../src/preference-defaults.LOGIC.md          |   2 +-
 .../framework/src/preset-catalog.LOGIC.md     |  22 +-
 .../src/preset-catalog.test.LOGIC.md          |   4 +-
 packages/framework/src/presets.LOGIC.md       |   4 +-
 .../framework/src/quota-boundary.LOGIC.md     |   2 +-
 packages/framework/src/registry.LOGIC.md      |   8 +-
 packages/framework/src/routine-locks.LOGIC.md |   4 +-
 packages/framework/src/store/LOGIC.md         |   2 +-
 .../src/store/agent-checkout.LOGIC.md         |   2 +-
 .../framework/src/store/agent-store.LOGIC.md  |   9 +-
 .../framework/src/store/run-record.LOGIC.md   |   6 +-
 packages/framework/src/terminal.LOGIC.md      |   7 +-
 packages/framework/src/tickets.LOGIC.md       |   4 +-
 .../framework/src/todo-loop.BUG-ANALYSIS.md   |   1 -
 packages/framework/src/todo-loop.LOGIC.md     | 150 ------------
 .../src/todo-loop.test.BUG-ANALYSIS.md        |   1 -
 .../framework/src/todo-loop.test.LOGIC.md     |  14 --
 packages/framework/src/turn-gate.LOGIC.md     |   2 +-
 packages/framework/src/worktrees.LOGIC.md     |   4 +-
 91 files changed, 462 insertions(+), 627 deletions(-)
 delete mode 100644 packages/framework/prompts/presets/drain_queue.LOGIC.md
 create mode 100644 packages/framework/skills/LOGIC.md
 create mode 100644 packages/framework/skills/work-queue/SKILL.LOGIC.md
 create mode 100644 packages/framework/src/daemon-writes.LOGIC.md
 create mode 100644 packages/framework/src/daemon-writes.test.LOGIC.md
 delete mode 100644 packages/framework/src/todo-loop.BUG-ANALYSIS.md
 delete mode 100644 packages/framework/src/todo-loop.LOGIC.md
 delete mode 100644 packages/framework/src/todo-loop.test.BUG-ANALYSIS.md
 delete mode 100644 packages/framework/src/todo-loop.test.LOGIC.md

diff --git a/packages/framework/dashboard/components/AiQueue.LOGIC.md b/packages/framework/dashboard/components/AiQueue.LOGIC.md
index 2d8689178..3a278738f 100644
--- a/packages/framework/dashboard/components/AiQueue.LOGIC.md
+++ b/packages/framework/dashboard/components/AiQueue.LOGIC.md
@@ -4,7 +4,7 @@ The Overview's [1] "AI Queue" card: every project's open queue entries [2], grou
 
 **User story**: the user opens the Overview, reads under "AI Queue" what the agents will pick up next in each project, clicks a ticket's title to read it, presses play on one entry to have it worked now, or sets "3" and presses the fan-out button to start three agents on a project's top three entries.
 
-**Business logic story**: the daemon's drain [6] half of Auto PM [7] starts an agent on the agent queue's first open entry on its own clock; this card is the same work started on the user's click, so an agent started here runs exactly the way a drained one does.
+**Business logic story**: the queued work [6] half of Auto PM [7] starts an agent on the agent queue when the `agent-data` branch moves; this card starts an agent on one named entry on the user's click, and it runs the way the daemon's agent does: unattended.
 
 ## Glossary
 
@@ -13,8 +13,8 @@ The Overview's [1] "AI Queue" card: every project's open queue entries [2], grou
 [3] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [4] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
 [5] launcher: project home is a project's own page with the launcher (the Start form) and its composer (the prompt editor, also used for live chat).
-[6] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
-[7] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[6] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
+[7] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [8] prompt agent: a prompt agent runs one prompt and stops there.
 [9] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [10] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs`.
@@ -56,7 +56,7 @@ Each row prints the entry's title rather than its source: the text of a link at
 
 #### Context
 
-**User story**: the user presses play on "Improve tooltip…" and watches one agent [3] implement that entry, as the drain [6] sweep would have, but now.
+**User story**: the user presses play on "Improve tooltip…" and watches one agent [3] implement that entry, now.
 
 #### Business logic
 
@@ -66,7 +66,7 @@ The play button, named "Spin up an agent working on this entry", starts a prompt
 
 #### Context
 
-**Problem**: several agents told "work the first open entry" would all implement the same one; a batch must pin each agent to its own entry, the way the daemon's drain [6] batch does.
+**Problem**: several agents told "work the first open entry" would all implement the same one; a batch must pin each agent to its own entry, the way the daemon's plan fan-out does.
 
 #### Business logic
 
diff --git a/packages/framework/dashboard/components/DashboardPage.LOGIC.md b/packages/framework/dashboard/components/DashboardPage.LOGIC.md
index bd3441743..5f58325a7 100644
--- a/packages/framework/dashboard/components/DashboardPage.LOGIC.md
+++ b/packages/framework/dashboard/components/DashboardPage.LOGIC.md
@@ -10,7 +10,7 @@ The Overview [1], the dashboard's landing page shown while no project is selecte
 [2] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [3] intervention: something that needs a human — an open question, a pull request to review, unpushed commits — one of the two notification feeds.
 [4] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
-[5] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[5] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [6] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent.
 [7] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
 
diff --git a/packages/framework/dashboard/components/HotTickets.LOGIC.md b/packages/framework/dashboard/components/HotTickets.LOGIC.md
index 450c20162..eb39dbd47 100644
--- a/packages/framework/dashboard/components/HotTickets.LOGIC.md
+++ b/packages/framework/dashboard/components/HotTickets.LOGIC.md
@@ -1,8 +1,8 @@
-The Overview's [1] "Hot tickets" card: a cross-project shortlist of tickets in three lanes — "In progress", "AI Queue" and "High priority" — re-read every 10 seconds, where selecting a ticket opens the agent [2] implementing it, or its project's launcher [3] with the composer [4] prefilled to work on that ticket. Which tickets qualify and which lane each sits in is the daemon's decision (the lane rules in `src/dashboard/overview.ts`); the card shows every ticket it is given, never a "+N more".
+The Overview's [1] "Hot tickets" card: a cross-project shortlist of tickets in three lanes — "In progress", "AI Queue" and "High priority" — re-read every 10 seconds, where selecting a ticket opens its project's launcher [3] with the composer [4] prefilled to work on that ticket. Which tickets qualify and which lane each sits in is the daemon's decision (the lane rules in `src/dashboard/overview.ts`); the card shows every ticket it is given, never a "+N more".
 
 ## Context
 
-**User story**: from the Overview [1] the user sees at a glance, across every project, which tickets an agent [2] is implementing or has planned, which sit on the agent queue [5] for the daemon to pick up on its own, and which are flagged high priority; one click takes them to the agent working a ticket, or to a launcher [3] ready to start an agent on it.
+**User story**: from the Overview [1] the user sees at a glance, across every project, which tickets an agent [2] has planned, which sit on the agent queue [5] for the daemon to pick up on its own, and which are flagged high priority; one click takes them to a launcher [3] ready to start an agent on it.
 
 ## Glossary
 
@@ -12,13 +12,12 @@ The Overview's [1] "Hot tickets" card: a cross-project shortlist of tickets in t
 [4] composer: the prompt editor on a project's own page, also used for live chat.
 [5] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
 [6] preset: a canned prompt the user launches from the dashboard.
-[7] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
 
 ## Business logic — TL;DR
 
 - **Three lanes in two columns** - "In progress" and "AI Queue" stack on the left, "High priority" stands alone on the right; each lane's header carries a colored dot, its label and its count, and an empty lane dims to its header.
-- **Every ticket, with its one tag** - a row shows the ticket's title, at most one tag ("implementing" in the accent color, else "planned", else the priority value) and its project's name; the tooltip shows the ticket's summary.
-- **Selecting a ticket** - a ticket an agent is implementing opens that agent; any other ticket opens its project's launcher with the composer prefilled "Work on tickets/<file>. Do not start any other ticket."
+- **Every ticket, with its one tag** - a row shows the ticket's title, at most one tag ("planned", else the priority value) and its project's name; the tooltip shows the ticket's summary.
+- **Selecting a ticket** - opens its project's launcher with the composer prefilled "Work on tickets/<file>. Do not start any other ticket."
 - **Empty says what is empty** - with no hot ticket at all the card reads "Nothing in progress, queued, or high priority." rather than claiming there are no tickets.
 
 ## Business logic
@@ -37,21 +36,21 @@ The card is titled "Hot tickets" with a flame icon. The tickets are re-read from
 
 #### Context
 
-**Problem**: a lane that holds both a ticket being coded as the user reads and a ticket someone planned at some point must say which is which; "planned" is a mark work left behind, "implementing" describes something happening now.
+**Problem**: a row must say why it is in its lane, with one word.
 
 #### Business logic
 
-A row is a button showing the ticket's title, truncated with an ellipsis, then at most one tag, then the project's name at the right. The tag is the one fact that earns the ticket its lane: "implementing", outlined in the accent color, when an agent [2] is implementing the ticket right now; otherwise, in the "In progress" lane, "planned" when the ticket has a plan; otherwise, in the "High priority" lane, the ticket's priority value; an "AI Queue" row carries no tag, because the lane already says it. Only "implementing" is colored; the other tags are muted. Hovering a row shows the ticket's summary, or its title when it has no summary.
+A row is a button showing the ticket's title, truncated with an ellipsis, then at most one tag, then the project's name at the right. The tag is the one fact that earns the ticket its lane: in the "In progress" lane, "planned" when the ticket has a plan; otherwise, in the "High priority" lane, the ticket's priority value; an "AI Queue" row carries no tag, because the lane already says it. Only "implementing" is colored; the other tags are muted. Hovering a row shows the ticket's summary, or its title when it has no summary.
 
 ### Selecting a ticket
 
 #### Context
 
-**Problem**: a ticket nobody is implementing has no agent [2] to jump to; landing on its project's launcher [3] with an empty composer [4] and the ticket forgotten would make the row a dead end.
+**Problem**: landing on the ticket's project launcher [3] with an empty composer [4] and the ticket forgotten would make the row a dead end.
 
 #### Business logic
 
-A ticket an agent is implementing opens that agent's page: the daemon knows which agent recorded the ticket, and that agent is what the row reports on. Any other ticket opens its project's launcher and hands the composer the draft "Work on tickets/<file>. Do not start any other ticket." — plain text the user reads and edits before sending, so there is no second, hidden version of the ask; it names the ticket's file, the ticket's identity, rather than its title, which is prose the agent would have to search for. Its wording is the drain [7] preset's [6], narrowed to the one ticket. The draft is stashed for the launcher to take once on arrival (the hand-over rules in `lib/draft-handoff.ts`); opening an agent leaves no draft behind, so nothing surfaces later on an unrelated visit to a launcher.
+Selecting a ticket opens its project's launcher and hands the composer the draft "Work on tickets/<file>. Do not start any other ticket." — plain text the user reads and edits before sending, so there is no second, hidden version of the ask; it names the ticket's file, the ticket's identity, rather than its title, which is prose the agent would have to search for. Its wording is the drain [7] preset's [6], narrowed to the one ticket. The draft is stashed for the launcher to take once on arrival (the hand-over rules in `lib/draft-handoff.ts`); opening an agent leaves no draft behind, so nothing surfaces later on an unrelated visit to a launcher.
 
 ### Empty says what is empty
 
diff --git a/packages/framework/dashboard/components/HotTickets.test.LOGIC.md b/packages/framework/dashboard/components/HotTickets.test.LOGIC.md
index 793c16701..ab8703834 100644
--- a/packages/framework/dashboard/components/HotTickets.test.LOGIC.md
+++ b/packages/framework/dashboard/components/HotTickets.test.LOGIC.md
@@ -1,10 +1,8 @@
 What the tests cover, for the Overview's [1] "Hot tickets" card:
 
 - **The empty card names its lanes** - with nothing hot it reads "Nothing in progress, queued, or high priority." rather than claiming no tickets exist.
-- **Three lanes, and a click into the project** - tickets are grouped under "In progress", "AI Queue" and "High priority", and selecting a ticket no agent [2] is implementing opens its project.
-- **The implementing tag outranks the plan** - a ticket an agent is implementing right now reads "implementing" while a planned ticket beside it reads "planned"; a ticket being implemented with no plan at all still gets the "implementing" tag.
-- **A ticket with an agent opens that agent** - selecting a ticket an agent is implementing opens that agent's page and not the project home; a ticket with no agent opens its project and no agent.
-- **The launcher is prefilled** - selecting a ticket with no agent leaves the draft "Work on tickets/<file>. Do not start any other ticket." for the launcher [3] to take; the draft names the ticket's file, not its title; selecting a ticket that opens an agent leaves no draft behind.
+- **Three lanes, and a click into the project** - tickets are grouped under "In progress", "AI Queue" and "High priority", and selecting a ticket opens its project.
+- **The launcher is prefilled** - selecting a ticket leaves the draft "Work on tickets/<file>. Do not start any other ticket." for the launcher [3] to take; the draft names the ticket's file, not its title.
 
 ## Glossary
 
diff --git a/packages/framework/dashboard/components/Quota.LOGIC.md b/packages/framework/dashboard/components/Quota.LOGIC.md
index 85af5b96f..59c9f783c 100644
--- a/packages/framework/dashboard/components/Quota.LOGIC.md
+++ b/packages/framework/dashboard/components/Quota.LOGIC.md
@@ -13,7 +13,7 @@ The "Usage" panel: the account's quota [1] week drawn as one week-long track —
 [3] spend offset: the user's adjustment of the quota boundary, in percentage points of the week.
 [4] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [5] coding agent: the CLI doing the actual work: Claude Code or Codex.
-[6] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[6] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [7] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
 [8] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
 [9] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
diff --git a/packages/framework/dashboard/components/RoutineWork.LOGIC.md b/packages/framework/dashboard/components/RoutineWork.LOGIC.md
index 42618801b..10c5cb5de 100644
--- a/packages/framework/dashboard/components/RoutineWork.LOGIC.md
+++ b/packages/framework/dashboard/components/RoutineWork.LOGIC.md
@@ -4,20 +4,20 @@ The Overview's "Routine work" card: the routines [1] Auto PM [2] fires on its sc
 
 **User story**: from the Overview [4] the user sees which routines the daemon will run on its own, switches single routines out of the schedule, runs one right now in the project of their choice, reads what it is about to spend before pressing, and reads why the last sweep started nothing.
 
-**Business logic story**: Auto PM has two halves, the drain [5] that spends existing work on the agent queue [6] and the rotation of routines that refills it; this card is the one surface that lists both. "Run now" on an ordinary routine takes the same path the launcher on a project home [7] takes, so the work starts now rather than the sweep being asked to come round sooner. A routine the sweep has to prepare (claim a queue entry, lock tickets, hold a routine lock [8]) is instead asked of the sweep, narrowed to that one routine.
+**Business logic story**: Auto PM has two halves, the queued work [5] that spends existing work on the agent queue [6] and the rotation of routines that refills it; this card is the one surface that lists both. "Run now" on an ordinary routine takes the same path the launcher on a project home [7] takes, so the work starts now rather than the sweep being asked to come round sooner. A routine the sweep has to prepare (lock tickets, hold a routine lock [8]), and the queued work, which the sweep fires, are instead asked of the sweep, narrowed to that one routine.
 
 ## Glossary
 
-[1] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
-[2] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[1] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[2] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [3] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
 [4] the Overview: the dashboard's cross-project page at `/`.
-[5] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[5] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [6] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [7] project home: a project's own page with the launcher (the Start form) and its composer (the prompt editor, also used for live chat).
 [8] routine lock: a file on the `agent-data` branch (`routines/<name>.lock.md`) a daemon takes before running a routine so the routine runs once across machines.
 [9] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
-[10] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
+[10] fan-out: starting several agents at once, one per ticket to plan.
 [11] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
 [12] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [13] prompt agent: an agent that runs one prompt and stops there (as opposed to a build agent, which works the agent queue after its opening exchange).
@@ -34,9 +34,9 @@ The Overview's "Routine work" card: the routines [1] Auto PM [2] fires on its sc
 - **A remembered project to run in** - with several projects a "Run in" list picks the project, remembered as a preference across navigations, reloads and tabs; a pick naming a removed project falls back to the first project.
 - **Each routine's place in the schedule** - the checkbox on a row switches that one routine out of or back into the schedule; what is recorded is the opt-out, so a routine added later is on for everyone.
 - **"Run now" as a plain start** - "Update from GitHub" and "Maintenance" start one unattended prompt agent in the picked project on the user's own settings, and the dashboard goes to that agent.
-- **"Run now" as a narrowed sweep** - the drain, "Plan tickets (aka spike)" and the two triage routines ask the sweep for that one routine's work, because only the sweep can claim, fan out or lock; the answer lands on the card and nobody is navigated away.
+- **"Run now" as a narrowed sweep** - the queued work, "Plan tickets (aka spike)" and the two triage routines ask the sweep for that one routine's work, because only the sweep can visit every project, claim, fan out or lock; the answer lands on the card and nobody is navigated away.
 - **What a click will spend, said before it is spent** - hovering "Run now" tells what the routine does, which coding agent, model and location the start reads from the preferences, and how many unattended agents it starts where.
-- **"Configure first, then run"** - the chevron beside "Run now" opens the picked project's launcher with the routine's prompt so model and location can be set first; for a fanning-out routine it warns that the launcher sends one agent, not the fan-out.
+- **"Configure first, then run"** - the chevron beside "Run now" opens the picked project's launcher with the routine's prompt so model and location can be set first; for the queued work it warns that the launcher sends one agent in this project, not every project, and for the planning routine that it sends one agent, not the fan-out.
 - **The schedule's master switch and its countdown** - the foot's checkbox is the same "Auto PM" preference the Settings page offers, labeled "Auto-runs in N min" while the schedule is on and the daemon has reported a next sweep, "Auto-run" otherwise; with every routine unticked it warns that the schedule has nothing to run.
 - **Sweeping on demand** - "Trigger routine now" runs one sweep immediately, even while auto-run is off, and the card then says what the sweep decided per project, or that this dashboard is not running the sweep.
 - **Concurrent agents** - a whole number of at least 1 (2 by default) saying how many agents the routine may keep going at once on queued work, with a line explaining what that means.
@@ -54,7 +54,7 @@ The Overview's "Routine work" card: the routines [1] Auto PM [2] fires on its sc
 
 The card is titled "Routine work". With no project registered it holds only the line "Add a project to run a routine." Otherwise it lists every routine [1] the sweep [3] can fire, in the sweep's own order of precedence (the rules in `src/auto-pm.ts`):
 
-1. "Spin up agents working on the AI queue" — the drain [5], which works entries already on the agent queue [6]; its pull request is merged once opened.
+1. "Work the queue" — the queued work [5], one agent told `/work-queue`; its pull request is merged once opened.
 2. "Update from GitHub" — brings the project's tickets up to date with its GitHub issues.
 3. "Add quick-win work to AI Queue" — the quick triage; holds the routine lock [8] `triage-quick` while it runs.
 4. "Add consensual work to AI Queue" — the consensual triage; holds the routine lock `triage-consensual`.
@@ -97,11 +97,11 @@ For "Update from GitHub" and "Maintenance", "Run now" starts one prompt agent [1
 
 #### Context
 
-**Problem**: a plain start can only ever be one agent [9], and it runs unguarded. The drain [5] and "Plan tickets (aka spike)" fan out [10], and only the sweep [3] can claim the work before each agent starts: a queue entry per drain, a ticket lock per plan. The two triage routines rewrite the shared agent queue [6] and may take hours, so they hold a routine lock [8] the sweep mints before the start. Which path a routine takes is decided by what the routine declares about itself, never by its name, so a renamed routine keeps its path.
+**Problem**: a plain start can only ever be one agent [9] in one project, and it runs unguarded. The queued work [5] visits every project; "Plan tickets (aka spike)" fans out [10], and only the sweep [3] can claim a ticket before each agent starts. The two triage routines rewrite the shared agent queue [6] and may take hours, so they hold a routine lock [8] the sweep mints before the start. Which path a routine takes is decided by what the routine declares about itself, never by its name, so a renamed routine keeps its path.
 
 #### Business logic
 
-For the drain, "Plan tickets (aka spike)", "Add quick-win work to AI Queue" and "Add consensual work to AI Queue", "Run now" asks the daemon to sweep now, narrowed to that one routine's work: the drain's sweep names no project because the drain visits every project the daemon watches; the other three are scoped to the picked project. Narrowing to the clicked routine means "nothing to do" is reported on the card rather than the click quietly borrowing a different routine's work. While the sweep runs, that row's button reads "Starting…". The user is not navigated anywhere: the agents land in the Overview's Agents card, where a batch is watchable. When the sweep is done the card shows its answer under the foot (see "Sweeping on demand" for the wording); when the daemon serving this dashboard runs no sweep, it shows "This dashboard is not running the sweep, so there is nothing to trigger here."
+For the queued work, "Plan tickets (aka spike)", "Add quick-win work to AI Queue" and "Add consensual work to AI Queue", "Run now" asks the daemon to sweep now, narrowed to that one routine's work: the queued work's sweep names no project because it visits every project the daemon watches; the other three are scoped to the picked project. Narrowing to the clicked routine means "nothing to do" is reported on the card rather than the click quietly borrowing a different routine's work. While the sweep runs, that row's button reads "Starting…". The user is not navigated anywhere: the agents land in the Overview's Agents card, where a batch is watchable. When the sweep is done the card shows its answer under the foot (see "Sweeping on demand" for the wording); when the daemon serving this dashboard runs no sweep, it shows "This dashboard is not running the sweep, so there is nothing to trigger here."
 
 ### What a click will spend, said before it is spent
 
@@ -114,8 +114,8 @@ For the drain, "Plan tickets (aka spike)", "Add quick-win work to AI Queue" and
 Hovering a routine's "Run now" shows up to three lines:
 
 1. The preset's [17] own one-line description, the same sentence the launcher shows for that preset: "Work the entries already on the queue (TODO_AGENTS.md)", "Bring `tickets/` up to date with the GitHub issues. An empty `tickets/` gets a full first import.", "Add `tickets/*.md` to queue (TODO_AGENTS.md), only quick-win and consensual tickets", "Add `tickets/*.md` to queue (TODO_AGENTS.md), only significant (no quick-wins) and consensual tickets", "Turn `tickets/*.md` into costed plans (`tickets/*.plan.md`)", "Queue maintainability + security work per codebase subset (TODO_AGENTS.md)".
-2. The settings the start reads, rendered from the very preferences the start uses: which coding agent [15], which model and which location [16], as one line such as "Claude Code · Opus · This machine"; a model that is not pinned, or is pinned for the other coding agent, reads "the CLI's own default" (the rule in `lib/agent-settings.ts`). For the drain [5] this line is instead "Each project's own settings decide the model and where it runs.", because the sweep resolves each project's own `the-framework.yml` and visits every project rather than the picked one.
-3. What the click spends: for the drain, "Sweeps every project the daemon watches, up to N agents each, unattended." ("agent" when N is 1); for a routine that fans out [10], "Starts up to N agents in <project>, one per open ticket, unattended."; for every other routine, "Starts one agent in <project>, unattended — nothing is asked mid-run." N is the "Concurrent agents" setting and <project> the picked project's name.
+2. The settings the start reads, rendered from the very preferences the start uses: which coding agent [15], which model and which location [16], as one line such as "Claude Code · Opus · This machine"; a model that is not pinned, or is pinned for the other coding agent, reads "the CLI's own default" (the rule in `lib/agent-settings.ts`). For the queued work [5] this line is instead "Each project's own settings decide the model and where it runs.", because the sweep resolves each project's own `the-framework.yml` and visits every project rather than the picked one.
+3. What the click spends: for the queued work, "Starts one agent in every project the daemon watches, unattended."; for a routine that fans out [10], "Starts up to N agents in <project>, one per open ticket, unattended."; for every other routine, "Starts one agent in <project>, unattended — nothing is asked mid-run." N is the "Concurrent agents" setting and <project> the picked project's name.
 
 ### "Configure first, then run"
 
@@ -159,7 +159,7 @@ The same line reports a narrowed sweep fired by a row's "Run now".
 
 #### Context
 
-**Business logic story**: only the drain [5] fans out [10], because it takes work off the agent queue [6] one entry at a time, so several agents [9] at once do disjoint work; a routine that invents work rewrites the queue and stays one agent per sweep whatever this says (the rules in `src/auto-pm.ts`).
+**Business logic story**: the queued work [5] runs one agent per move of the `agent-data` branch and the cap is how many of them may overlap; planning fans out [10] to it; a routine that rewrites the queue stays one agent per sweep whatever this says (the rules in `src/auto-pm.ts`).
 
 #### Business logic
 
diff --git a/packages/framework/dashboard/components/RoutineWork.test.LOGIC.md b/packages/framework/dashboard/components/RoutineWork.test.LOGIC.md
index 436c0ac2d..03779dd79 100644
--- a/packages/framework/dashboard/components/RoutineWork.test.LOGIC.md
+++ b/packages/framework/dashboard/components/RoutineWork.test.LOGIC.md
@@ -2,9 +2,9 @@ What the tests cover, for the Overview's "Routine work" card with one or more re
 
 - **The routine list** - every routine the sweep can fire is listed by its preset label, in the daemon's own order; only a routine that describes itself ("Maintenance") gets a second line under its name; with no project registered the card says "Add a project to run a routine." and offers no "Run now".
 - **"Run now" as a plain start** - an ordinary routine starts its prompt verbatim as an unattended prompt agent in the picked project, and the dashboard is handed the new agent's id so it lands on that agent; a start that reports no agent id still hands the project over; a failed start neither navigates nor leaves the button on "Starting…", and its reason ("already active") is shown as an alert; a start already in flight disables every "Run now".
-- **"Run now" as a narrowed sweep** - the drain asks for a drain-only sweep with no project (it visits every project) and navigates nowhere; the planning routine asks for a plan-only sweep scoped to the picked project; a routine that holds a lock asks for the sweep by its declared lock, scoped to the picked project; none of these is a plain start; a host that runs no sweep is told "not running the sweep … nothing to trigger" instead of failing silently; the drain's sweep outcome is reported on the card.
+- **"Run now" as a narrowed sweep** - the queued work asks for a sweep narrowed to the queued work with no project (it visits every project) and navigates nowhere; the planning routine asks for a plan-only sweep scoped to the picked project; a routine that holds a lock asks for the sweep by its declared lock, scoped to the picked project; none of these is a plain start; a host that runs no sweep is told "not running the sweep … nothing to trigger" instead of failing silently; the drain's sweep outcome is reported on the card.
 - **What a click will spend** - hovering "Run now" shows the preset's own sentence, the settings the start would use ("Claude Code · Opus · This machine"), and "Starts one agent in <project>, unattended"; no pinned model, or a model pinned for the other driver, reads "the CLI's own default" and never the list's first entry; the location comes from the preference ("Claude web"); the drain's hover says "Each project's own settings decide the model and where it runs." and "Sweeps every project the daemon watches, up to N agents each"; the planning routine's says "Starts up to N agents in <project>, one per open ticket" with the settings line; a concurrency of one reads "up to 1 agent".
-- **"Configure first, then run"** - the chevron's entry hands the routine's prompt to the launcher of the picked project (the remembered one, not the first) through the draft stash, starting nothing; the drain's and the planning routine's entry warn "one agent, not the fan-out" while an ordinary routine's promises "set the model and where it runs"; the entry stays live while a start is in flight.
+- **"Configure first, then run"** - the chevron's entry hands the routine's prompt to the launcher of the picked project (the remembered one, not the first) through the draft stash, starting nothing; the queued work's entry warns "one agent in this project, not every project", the planning routine's "one agent, not the fan-out", while an ordinary routine's promises "set the model and where it runs"; the entry stays live while a start is in flight.
 - **The remembered project** - with several projects a "Run in" list appears, reads the saved pick, and writes a new pick as the preference; a saved pick naming an unregistered project falls back to the first; one project needs no list; "Run now" honors the pick.
 - **The master switch** - with auto-run on and a reported sweep the box says "Auto-runs in 2 hr"; with auto-run off, or before the daemon has reported, it says "Auto-run"; ticking it writes the one global Auto PM preference and hovering it reads "Automatically run the ticked routines on a regular schedule."; there is one checkbox per routine plus the master.
 - **Per-routine opt-outs** - every routine starts ticked; unticking one records only that routine; an opted-out routine shows unticked and re-ticking it drops only it, keeping its siblings' opt-outs; "Run now" fires a routine even when it is unticked; auto-run on with every routine unticked shows "Every routine is unticked …", and one routine back on removes the warning.
diff --git a/packages/framework/dashboard/components/SettingsPage.LOGIC.md b/packages/framework/dashboard/components/SettingsPage.LOGIC.md
index dfc53306e..eaee45153 100644
--- a/packages/framework/dashboard/components/SettingsPage.LOGIC.md
+++ b/packages/framework/dashboard/components/SettingsPage.LOGIC.md
@@ -24,7 +24,7 @@ The Settings page: every preference [1] the user can set, on one page, each chan
 [14] ready for merge: the signal an agent emits when it believes its work is complete: it flips the agent's badge from building to ready and authorizes the handoff.
 [15] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it). "Handoff level" is a rung of that ladder.
 [16] intervention: something that needs a human — an open question, a pull request to review, unpushed commits — one of the two notification feeds. The other is activity: an agent started or finished.
-[17] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[17] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [18] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
 [19] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [20] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
diff --git a/packages/framework/dashboard/components/TicketsPage.LOGIC.md b/packages/framework/dashboard/components/TicketsPage.LOGIC.md
index b4224f8d0..d3423e91a 100644
--- a/packages/framework/dashboard/components/TicketsPage.LOGIC.md
+++ b/packages/framework/dashboard/components/TicketsPage.LOGIC.md
@@ -14,7 +14,7 @@ Shows every registered project's tickets on one page, the dashboard's Tickets vi
 [4] claim: a ticket's lock file naming the holder working it, so two agents never work the same ticket.
 [5] holder: who a claim names: the agent's id when the daemon started the agent, else the branch the `tickets` command ran on.
 [6] plan: a ticket's `.plan.md`: effort and uncertainty ratings and how to implement it.
-[7] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[7] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [8] the Overview: the dashboard's cross-project page at `/`.
 [9] prompt agent: an agent that runs one prompt and stops there.
 [10] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles. The opposite is attended.
@@ -152,7 +152,7 @@ After success the button reads "Plans queued" with a check mark and is disabled
 What a row shows, including its plan column, its start controls and how a claim [4] names its holder [5], is described in `TicketsPanel.tsx`. This page wires the row's actions, in flat mode directly and in grouped mode through each project's panel, always against the row's own project:
 - Opening a row opens the ticket's own page; the plan column's link opens the ticket's plan view. Both are addressed by project and ticket file.
 - "Start a plan" from a row starts an attended prompt agent [9] on the ticket's project with the prompt `Create tickets/<stem>.plan.md`. When the agent could not be started, the daemon's reason, or "The planning agent could not be started." when it gives none, appears above the filter bar.
-- "Start work" from a row starts a prompt agent on the ticket's project, unattended [10], with the ticket named on the agent as `tickets/<file>` so the daemon claims the ticket for it; the prompt's wording is in `TicketsPanel.tsx`. Failure shows the daemon's reason or "The work agent could not be started.".
+- "Start work" from a row starts a prompt agent on the ticket's project, unattended [10]; the prompt's wording is in `TicketsPanel.tsx`. Failure shows the daemon's reason or "The work agent could not be started.".
 - Every "Configure first, then run" on this page selects the row's own project, landing on that project's launcher.
 - On a claimed row, the holder's name links to the holding agent's page in the ticket's project, when the holder is one of that project's agents.
 
diff --git a/packages/framework/dashboard/components/TicketsPage.test.LOGIC.md b/packages/framework/dashboard/components/TicketsPage.test.LOGIC.md
index 75e3490b4..4cca667f5 100644
--- a/packages/framework/dashboard/components/TicketsPage.test.LOGIC.md
+++ b/packages/framework/dashboard/components/TicketsPage.test.LOGIC.md
@@ -10,7 +10,7 @@ What the tests cover:
 - **Click-to-filter from a row** - a row's topic badge adds that topic to the filter (`?topics=dx`); a badge whose topic is capitalized filters by its lowercase form (`UX` writes `?topics=ux`) and keeps its own row shown; a row's claim marker narrows to claimed tickets (`?stage=claimed`).
 - **Filtered down to nothing** - a project whose tickets are all hidden reads "2 tickets hidden by the current filters" and offers "Clear filters" there and then, and does not offer "Update from GitHub", because those tickets exist and are merely hidden; clearing empties the address's query string and brings the rows back.
 - **The flat cross-project list** - `group=none` renders one list ordered across projects (a priority 9 ticket of one project above a priority 2 ticket of another), each row carrying its own project's name, and no per-project "Update from GitHub" bar.
-- **Starting from a flat row** - "Start work on …" starts a prompt agent in that row's own project, unattended, with the ticket named as `tickets/<file>` and that file named in the prompt, then reports the started agent under that same project.
+- **Starting from a flat row** - "Start work on …" starts a prompt agent in that row's own project, unattended, with the ticket's file named in the prompt, then reports the started agent under that same project.
 - **"Configure first, then run" from a flat row** - lands on that row's own project's launcher, not on the first project listed, starts no agent, and leaves the row's work prompt waiting as a draft for the composer.
 - **Queueing the shown tickets** - "Add all 2 tickets shown below to the AI queue" adds one entry per shown ticket to that ticket's own project's agent queue, the ticket's title as the entry, the ticket named so the entry links back, and the ticket's priority carried when it has one; no agent is started; the button then reads "Queued" and is disabled, and arms again the moment the shown set changes, counting the new set ("Add the ticket shown below to the AI queue").
 - **Never queued twice** - a ticket an open queue entry already links to is skipped, even when the entry carries an agent's own note after the link; an entry that is checked off does not count as queued, so its ticket is added.
diff --git a/packages/framework/dashboard/components/TicketsPanel.LOGIC.md b/packages/framework/dashboard/components/TicketsPanel.LOGIC.md
index d0cc0feb7..34451ae89 100644
--- a/packages/framework/dashboard/components/TicketsPanel.LOGIC.md
+++ b/packages/framework/dashboard/components/TicketsPanel.LOGIC.md
@@ -14,7 +14,7 @@ Lists one project's tickets as one-liner rows — priority, topics, who holds th
 [4] holder: who a claim names: the agent's id when the daemon started the agent, else the branch the `tickets` command ran on.
 [5] session name: the name an agent gives its own work; its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 [6] prompt agent: an agent that runs one prompt and stops there.
-[7] drain: starting an agent on the agent queue's first open entry.
+[7] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [8] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles. The opposite is attended.
 [9] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: keep the work in its checkout, push its branch, also open a pull request, also merge it.
 [10] launcher: the Start form on a project's own page.
@@ -89,13 +89,13 @@ The two states are told apart by color and weight, not by the icon alone, so the
 
 **User story**: the user reading the backlog wants the ticket worked now, without queueing it and without opening it first.
 
-**Problem**: an agent [1] given a ticket to work could wander into other tickets, and the daemon must know which ticket the agent is implementing in order to record it and to claim [3] it for the agent.
+**Problem**: an agent [1] given a ticket to work could wander into other tickets.
 
 #### Business logic
 
-The start column is a play button labeled "Start work on <title>", with the tooltip "Spin up an agent working on this ticket". It starts a prompt agent [6] on this project with the prompt "Work on tickets/<file>. Do not start any other ticket." — the drain [7] preset's wording narrowed to this one ticket — and names the ticket to the daemon as `tickets/<file>`, since the prompt is not the drain preset's and the daemon would not otherwise know which ticket is being implemented.
+The start column is a play button labeled "Start work on <title>", with the tooltip "Spin up an agent working on this ticket". It starts a prompt agent [6] on this project with the prompt "Work on tickets/<file>. Do not start any other ticket." — and nothing else: the agent claims the ticket itself through the `tickets` skill.
 
-That agent runs unattended [8]: one agent on one ticket is the same work the daemon's own drain starts, so it runs the same way, ending when its work settles and firing the handoff [9] it was armed with. A refusal reads "The work agent could not be started.".
+That agent runs unattended [8]: one agent on one ticket is run the way the daemon runs the queued work [7], ending when its work settles and firing the handoff [9] it was armed with. A refusal reads "The work agent could not be started.".
 
 When a start succeeds, the surrounding page is told what was asked and which agent was started, so it can take the user to the agent instead of leaving them on rows that have not changed yet.
 
diff --git a/packages/framework/dashboard/components/TicketsPanel.test.LOGIC.md b/packages/framework/dashboard/components/TicketsPanel.test.LOGIC.md
index 3566262de..a81131141 100644
--- a/packages/framework/dashboard/components/TicketsPanel.test.LOGIC.md
+++ b/packages/framework/dashboard/components/TicketsPanel.test.LOGIC.md
@@ -6,7 +6,7 @@ What the tests cover:
 - **Opening a ticket** - clicking the title hands back the ticket's file name, the same name the ticket's own address uses.
 - **The plan column when a plan exists** - a "View the plan for <title>" button opens that ticket's plan; there is no "planned" badge, the column says it; and no configure chevron, because reading a plan starts nothing.
 - **The plan column when none exists** - "Create a plan for <title>" starts an agent with exactly the shared plan ask, "Create tickets/<stem>.plan.md", attended, and reports the started agent so the user can be taken to it.
-- **The start column** - "Start work on <title>" starts an agent with exactly "Work on tickets/<file>. Do not start any other ticket.", unattended and with the ticket named as `tickets/<file>` so the daemon knows what is being implemented, and reports the started agent; starting does not also open the ticket.
+- **The start column** - "Start work on <title>" starts an agent with exactly "Work on tickets/<file>. Do not start any other ticket.", unattended, and reports the started agent; starting does not also open the ticket.
 - **Every control is beside the row, not inside it** - starting, selecting, clicking a topic and following the GitHub link never open the ticket; the GitHub link points at the issue's own address and shows its label.
 - **Selection** - a row carries a "Select <title>" tick box only where the surrounding page acts on a selection, shows what the page says it is, and toggles by file name without opening the ticket.
 - **Click-to-filter** - a topic badge hands its topic back, and the claim marker asks for the list to be narrowed to claimed tickets.
diff --git a/packages/framework/dashboard/lib/preferences.LOGIC.md b/packages/framework/dashboard/lib/preferences.LOGIC.md
index 0b7cce5c5..1e7bce042 100644
--- a/packages/framework/dashboard/lib/preferences.LOGIC.md
+++ b/packages/framework/dashboard/lib/preferences.LOGIC.md
@@ -13,7 +13,7 @@ Holds the browser's view of the user's preferences [1]: loads them from the daem
 [3] Settings: the settings page.
 [4] launcher: the Start form on a project's own page.
 [5] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it).
-[6] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[6] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [7] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [8] transparent: an agent started with nothing of The Framework's — the raw coding agent.
 [9] vanilla: an agent started without the built-in system prompt but with the signal protocols kept.
diff --git a/packages/framework/dashboard/lib/quota.LOGIC.md b/packages/framework/dashboard/lib/quota.LOGIC.md
index fb88e0d9d..261971145 100644
--- a/packages/framework/dashboard/lib/quota.LOGIC.md
+++ b/packages/framework/dashboard/lib/quota.LOGIC.md
@@ -4,7 +4,7 @@ Feeds the usage panel: the account's quota [1] reading with where it stands agai
 
 [1] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [2] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
-[3] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[3] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [4] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
 
 ## Business logic — TL;DR
diff --git a/packages/framework/dashboard/rpc/quota.LOGIC.md b/packages/framework/dashboard/rpc/quota.LOGIC.md
index 8a387a483..1cfabf562 100644
--- a/packages/framework/dashboard/rpc/quota.LOGIC.md
+++ b/packages/framework/dashboard/rpc/quota.LOGIC.md
@@ -4,12 +4,12 @@ The browser's typed stubs behind the usage panel: where the account's quota [1]
 
 [1] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [2] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
-[3] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[3] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [4] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
 [5] coding agent: the CLI doing the actual work: Claude Code or Codex.
 [6] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
-[7] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
-[8] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[7] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[8] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [9] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
 [10] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 
diff --git a/packages/framework/prompts/on_before_mergeable_prompt.LOGIC.md b/packages/framework/prompts/on_before_mergeable_prompt.LOGIC.md
index 7eb37c2cb..23fa61e55 100644
--- a/packages/framework/prompts/on_before_mergeable_prompt.LOGIC.md
+++ b/packages/framework/prompts/on_before_mergeable_prompt.LOGIC.md
@@ -15,7 +15,7 @@ The text is a template: `${{ tf.session_name }}` is the finished agent's session
 [3] vanilla: an agent started without the built-in system prompt but with the signal protocols kept.
 [4] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [5] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
-[6] drain: starting an agent on the agent queue's first open entry; the half of Auto PM that spends existing work.
+[6] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [7] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local`, `push`, `pr` (the default), `merge`.
 [8] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 [9] skill: one of the four capabilities an agent is taught (`branches`, `tickets`, `queue`, `logs`), each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
diff --git a/packages/framework/prompts/presets/LOGIC.md b/packages/framework/prompts/presets/LOGIC.md
index 14e44c09c..9620bf7ae 100644
--- a/packages/framework/prompts/presets/LOGIC.md
+++ b/packages/framework/prompts/presets/LOGIC.md
@@ -1,8 +1,8 @@
-The fifteen presets: the canned prompts behind the launcher's buttons and the daemon's routines [2], one markdown file each. Five of them are quality passes over a target the user names; one sweeps the code and queues quality work; four are product management, proposing or picking tickets; four are the routines that keep the tickets and the agent queue [4] fresh; and one is the prompt of a drain [5] agent [1], which only the daemon fires. The table in `src/preset-catalog.ts` says which button or routine each backs, in which order the launcher shows them, and appends the queue-only rule of `../triage_scope.md` to the two triage presets.
+The fourteen presets: the canned prompts behind the launcher's buttons and the daemon's rotation routines [2], one markdown file each. Five of them are quality passes over a target the user names; one sweeps the code and queues quality work; four are product management, proposing or picking tickets; four are the routines that keep the tickets and the agent queue [4] fresh. The routine that works the queue is not a preset: it is the skill file `../skills/work-queue/SKILL.md`, which only the daemon fires. The table in `src/preset-catalog.ts` says which button or routine each backs, in which order the launcher shows them, and appends the queue-only rule of `../triage_scope.md` to the two triage presets.
 
 ## Context
 
-**User story**: a project's launcher offers, in this order, "Research", "Readability", "Maintainability", "Security audit", "UX (auto)", "Suggest new tickets", "Suggest new features", "Suggest tickets to work on", "Plan tickets (aka spike)", "Market research", "Update from GitHub", "Maintenance", "Add quick-win work to AI Queue" and "Add consensual work to AI Queue"; the first five take an optional target, the rest need nothing typed. With Auto PM [3] on, the daemon fires "Update from GitHub", the two triages and "Plan tickets (aka spike)" in that rotation, "Maintenance" on its own calendar, and the drain whenever the queue has an entry. The user's own saved prompts, the custom presets, are kept in the registry, not here.
+**User story**: a project's launcher offers, in this order, "Research", "Readability", "Maintainability", "Security audit", "UX (auto)", "Suggest new tickets", "Suggest new features", "Suggest tickets to work on", "Plan tickets (aka spike)", "Market research", "Update from GitHub", "Maintenance", "Add quick-win work to AI Queue" and "Add consensual work to AI Queue"; the first five take an optional target, the rest need nothing typed. With Auto PM [3] on, the daemon fires "Update from GitHub", the two triages and "Plan tickets (aka spike)" in that rotation, "Maintenance" on its own calendar, and the queued work [5] whenever the `agent-data` branch moved. The user's own saved prompts, the custom presets, are kept in the registry, not here.
 
 **Business logic story**: the five targeted presets take one parameter, `${{ tf.params.what }}`, filled by the rule in `src/preset-prompt.ts`: the user's text, trimmed, or when blank the session name of the agent the preset was launched from, or "entire codebase" when there is none, which is what a routine gets. The other presets scope themselves to the project's tickets, plans or queue and render verbatim. Six presets are also written to a project's `.the-framework/presets/<stem>.md`, namely `maintainability`, `readability`, `security_audit`, `research`, `ux` and `maintenance`, so that a queue entry can name one for a later agent to open and run. Two presets end in a gate [6], "Research" and "Suggest tickets to work on", and are therefore never fired unattended [7]; "UX (auto)" and "Suggest new features" are unattended by design; "Update from GitHub" always starts an agent of its own.
 
@@ -10,9 +10,9 @@ The fifteen presets: the canned prompts behind the launcher's buttons and the da
 
 [1] agent: the unit of work: one task worked by a coding agent under The Framework's control, in its own checkout, on its own branch, streaming events, handed off when it ends.
 [2] routine: a preset the daemon fires on its own on a schedule (update tickets, triage quick, triage consensual, plan tickets, maintenance), each switchable off and runnable on demand.
-[3] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[3] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [4] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
-[5] drain: starting an agent on the agent queue's first open entry; the half of Auto PM that spends existing work.
+[5] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [6] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent.
 [7] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [8] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
@@ -33,4 +33,3 @@ The fifteen presets: the canned prompts behind the launcher's buttons and the da
 - **Add quick-win work to AI Queue** (`triage_quick.md`) - queue the tickets whose plan shows a quick win with no uncertainty, cheapest first, and nothing else; the second routine.
 - **Add consensual work to AI Queue** (`triage_consensual.md`) - queue the significant tickets with no open question and no variability at their own priority, and nothing else; the third routine.
 - **Plan tickets (aka spike)** (`plan_tickets.md`) - queue a plan for the 10 most important unplanned, unclaimed tickets; as the last routine it fans out [8] into one agent per claimed ticket that writes the plan itself.
-- **Draining the agent queue** (`drain_queue.md`) - work the first open entry of the agent queue [4] and only it, marking it done once published; fired by the daemon, never a launcher button, and recognized as a drain [5] by its exact text.
diff --git a/packages/framework/prompts/presets/drain_queue.LOGIC.md b/packages/framework/prompts/presets/drain_queue.LOGIC.md
deleted file mode 100644
index e780259c3..000000000
--- a/packages/framework/prompts/presets/drain_queue.LOGIC.md
+++ /dev/null
@@ -1,21 +0,0 @@
-The "Spin up agents working on the AI queue" preset, the one preset no launcher button offers: the prompt of a drain [3] agent [1], fired by the daemon's Auto PM [4] whenever the agent queue [2] is not empty, and by the user's "Run now" on the drain row of the Overview. Its tooltip reads "Work the entries already on the queue (TODO_AGENTS.md)". The agent uses the `queue` skill [5]: it runs `queue`, works on the first open entry only, runs `queue done "<the entry>"` once the work is done and published, and does not start any other entry. It takes no parameter.
-
-## Context
-
-**User story**: with Auto PM switched on, the user's queue empties itself one entry per agent, top-down, each entry ending as a pull request; the Overview shows which ticket is being implemented right now, which it can only do because it recognizes a drain agent by its prompt.
-
-**Business logic story**: an agent started by hand arrives as bare prompt text with nothing marking it as a drain, so The Framework recognizes a drain by the prompt being exactly this preset's text, whitespace aside (the rule in `src/preset-catalog.ts`): a prompt that merely mentions the queue is not a drain, and mistaking one for a drain would name a ticket as being implemented by an agent doing something else entirely. Several drain agents may run at once, each on its own first open entry, since claiming an entry is what keeps two agents off the same one.
-
-## Glossary
-
-[1] agent: the unit of work: one task worked by a coding agent under The Framework's control, in its own checkout, on its own branch, streaming events, handed off when it ends.
-[2] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
-[3] drain: starting an agent on the agent queue's first open entry; the half of Auto PM that spends existing work.
-[4] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
-[5] skill: one of the four capabilities an agent is taught (`branches`, `tickets`, `queue`, `logs`), each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
-
-## Business logic — TL;DR
-
-- **The first open entry, and only it** - the agent runs `queue` and works on the first open entry, never another one.
-- **Done means published** - only when the work is done and published does the agent run `queue done "<the entry>"`, which is what takes the entry off the queue.
-- **One entry per agent** - the agent does not start any other entry; the next entry is the next agent's.
diff --git a/packages/framework/prompts/presets/maintenance.LOGIC.md b/packages/framework/prompts/presets/maintenance.LOGIC.md
index ccc3a20e6..0f5a7fa8d 100644
--- a/packages/framework/prompts/presets/maintenance.LOGIC.md
+++ b/packages/framework/prompts/presets/maintenance.LOGIC.md
@@ -11,7 +11,7 @@ The "Maintenance" preset, both a launcher button and a routine [3]: the agent [1
 [1] agent: the unit of work: one task worked by a coding agent under The Framework's control, in its own checkout, on its own branch, streaming events, handed off when it ends.
 [2] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [3] routine: a preset the daemon fires on its own on a schedule, each switchable off and runnable on demand.
-[4] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[4] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [5] skill: one of the four capabilities an agent is taught (`branches`, `tickets`, `queue`, `logs`), each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
 
 ## Business logic — TL;DR
diff --git a/packages/framework/prompts/presets/plan_tickets.LOGIC.md b/packages/framework/prompts/presets/plan_tickets.LOGIC.md
index 8800fd7f4..662ea05a9 100644
--- a/packages/framework/prompts/presets/plan_tickets.LOGIC.md
+++ b/packages/framework/prompts/presets/plan_tickets.LOGIC.md
@@ -14,7 +14,7 @@ The "Plan tickets (aka spike)" preset, both a launcher button and a routine [3]:
 [4] plan: a ticket's `.plan.md`: effort and uncertainty ratings and how to implement it.
 [5] claim: a ticket's lock file naming the holder working it, so two agents never work the same ticket.
 [6] skill: one of the four capabilities an agent is taught (`branches`, `tickets`, `queue`, `logs`), each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
-[7] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[7] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [8] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
 
 ## Business logic — TL;DR
diff --git a/packages/framework/prompts/presets/triage_consensual.LOGIC.md b/packages/framework/prompts/presets/triage_consensual.LOGIC.md
index 393a00716..6fee12cc1 100644
--- a/packages/framework/prompts/presets/triage_consensual.LOGIC.md
+++ b/packages/framework/prompts/presets/triage_consensual.LOGIC.md
@@ -12,7 +12,7 @@ The "Add consensual work to AI Queue" preset, both a launcher button and a routi
 [2] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [3] plan: a ticket's `.plan.md`: effort and uncertainty ratings and how to implement it.
 [4] routine: a preset the daemon fires on its own on a schedule, each switchable off and runnable on demand.
-[5] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[5] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [6] routine lock: a file on the `agent-data` branch (`routines/<name>.lock.md`) a daemon takes before running a routine so the routine runs once across machines.
 [7] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 [8] skill: one of the four capabilities an agent is taught (`branches`, `tickets`, `queue`, `logs`), each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
diff --git a/packages/framework/prompts/presets/triage_quick.LOGIC.md b/packages/framework/prompts/presets/triage_quick.LOGIC.md
index 6ff8d8051..96e391d1f 100644
--- a/packages/framework/prompts/presets/triage_quick.LOGIC.md
+++ b/packages/framework/prompts/presets/triage_quick.LOGIC.md
@@ -12,7 +12,7 @@ The "Add quick-win work to AI Queue" preset, both a launcher button and a routin
 [2] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [3] plan: a ticket's `.plan.md`: effort and uncertainty ratings and how to implement it.
 [4] routine: a preset the daemon fires on its own on a schedule, each switchable off and runnable on demand.
-[5] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[5] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [6] routine lock: a file on the `agent-data` branch (`routines/<name>.lock.md`) a daemon takes before running a routine so the routine runs once across machines.
 [7] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 [8] skill: one of the four capabilities an agent is taught (`branches`, `tickets`, `queue`, `logs`), each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
diff --git a/packages/framework/prompts/presets/update_tickets.LOGIC.md b/packages/framework/prompts/presets/update_tickets.LOGIC.md
index 26c05b351..7fa63eb99 100644
--- a/packages/framework/prompts/presets/update_tickets.LOGIC.md
+++ b/packages/framework/prompts/presets/update_tickets.LOGIC.md
@@ -14,7 +14,7 @@ The "Update from GitHub" preset, both a launcher button and a routine [3]: the o
 [2] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [3] routine: a preset the daemon fires on its own on a schedule, each switchable off and runnable on demand.
 [4] skill: one of the four capabilities an agent is taught (`branches`, `tickets`, `queue`, `logs`), each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
-[5] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[5] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [6] plan: a ticket's `.plan.md`: effort and uncertainty ratings and how to implement it.
 [7] claim: a ticket's lock file naming the holder working it, so two agents never work the same ticket.
 
diff --git a/packages/framework/skills/LOGIC.md b/packages/framework/skills/LOGIC.md
new file mode 100644
index 000000000..d6832bf89
--- /dev/null
+++ b/packages/framework/skills/LOGIC.md
@@ -0,0 +1,3 @@
+The routine skills The Framework ships: skill files the daemon fires, one directory each, linked into every checkout the daemon makes where the coding agent's harness looks for skills (`.claude/skills/<name>`, `.agents/skills/<name>`). Each is marked so that only a person or the daemon invokes it, and its body is the job's prompt: the daemon starts the agent with the skill's slash command and the harness expands it.
+
+- **Working the queue** (`work-queue/`) - one queued task off the agent queue, unattended; the routine the daemon fires when the `agent-data` branch moved (the rules in `../src/auto-pm.ts`).
diff --git a/packages/framework/skills/work-queue/SKILL.LOGIC.md b/packages/framework/skills/work-queue/SKILL.LOGIC.md
new file mode 100644
index 000000000..df01f42ad
--- /dev/null
+++ b/packages/framework/skills/work-queue/SKILL.LOGIC.md
@@ -0,0 +1,16 @@
+The `work-queue` routine skill: the prompt of the agent the daemon starts on the queued work, as a skill file the coding agent's harness expands from `/work-queue`. Marked so that only a person or the daemon invokes it; the agent never chooses it by itself.
+
+## Context
+
+**User story**: the daemon starts an agent with `/work-queue`. The agent reads the skills in its checkout, takes one queued task, works it in its own branch, commits, closes the task's ticket, marks the queue entry done, and stops; the run that started it publishes the branch. An agent that finds nothing queued says so and stops.
+
+**Business logic story**: the skill names no skill and no command. The agent composes the `tickets` and `queue` skills tracked in the project on its own; what this file carries is the rules of the job, which an unattended agent cannot infer from the skills alone.
+
+## Business logic — TL;DR
+
+- **Nobody answers** - the agent never asks and decides by itself.
+- **One task** - it takes one queued task and no other.
+- **Commit, do not push** - it commits on its own branch and leaves publishing to the run that started it.
+- **Committed counts as published** - once the work is committed it closes the task's ticket and marks the queue entry done, so a ticket whose skill says "close once published" is closed rather than left open.
+- **Release before stopping** - any claim it still holds is released unless it closed the ticket.
+- **Nothing queued** - it says so and stops.
diff --git a/packages/framework/src/LOGIC.md b/packages/framework/src/LOGIC.md
index 60c039e24..df1ac16e7 100644
--- a/packages/framework/src/LOGIC.md
+++ b/packages/framework/src/LOGIC.md
@@ -27,14 +27,14 @@ Everything of The Framework that runs in Node: the `the-framework` command, the
 ## Business logic — TL;DR
 
 - **The command and the two processes it starts** (`bin.ts`, `cli.ts`, `cli-exec.ts`, `agent-spec.ts`, `index.ts`, `client.ts`) - four options and no verbs: the bare command serves the dashboard, and one private option runs a single agent [2] from the spec file the daemon [1] wrote for it, which is why an agent's configuration is never a command line. `client.ts` is the one entry the browser may import at run time.
-- **The life of an agent** (`agent.ts`, `await-gate.ts`, `turn-gate.ts`, `todo-loop.ts`, `agent-messages.ts`, `agent-telemetry.ts`, `gate-keepalive.ts`, `agent-id.ts`, `agent-view.ts`, `usage.ts`) - frame the coding agent [7], send the opening prompt, read the turn's final message for everything The Framework learns, honor each gate [9], work the agent queue, take the user's messages, and end with a verdict.
+- **The life of an agent** (`agent.ts`, `await-gate.ts`, `turn-gate.ts`, `agent-messages.ts`, `agent-telemetry.ts`, `gate-keepalive.ts`, `agent-id.ts`, `agent-view.ts`, `usage.ts`) - frame the coding agent [7], send the opening prompt, read the turn's final message for everything The Framework learns, honor each gate [9], take the user's messages, and end with a verdict.
 - **What an agent is told** (`system-prompt.ts`, `system-prompt-file.ts`, `prompt-template.ts`, `preset-catalog.ts`, `preset-prompt.ts`, `presets.ts`, `preset-registry.ts`, `project-presets.ts`, `tickets.ts`) - the built-in system prompt, the project's own `SYSTEM.md`, the protocols and the preset [14] catalog composed into one system channel, with the user's text rendered into its own slot.
 - **The driver seam** (`driver-cli.ts`, `driver-names.ts`, `target-driver.ts`, `agent-location.ts`, `fake-script.ts`) - which coding agent [7] does the work and where it runs are two separate choices; together they pick one driver [8] implementation, and `web` is the one location [13] whose work leaves this machine.
 - **Files are the seam** (`events.ts`, `event-stream.ts`, `control.ts`, `jsonl-tail.ts`, `framework-dir.ts`, `node-fs.ts`, `error-message.ts`, `request-path.ts`, `runtime-keys.ts`, `session-link.ts`, `format-bytes.ts`, `terminal.ts`) - one vocabulary of events an agent appends to its own file and everything else projects, one file steering flows back through, and the small shared rules for reading, naming and rendering them.
 - **The daemon** (`daemon.ts`, `daemon-runtime.ts`, `daemon-services.ts`, `daemon-tick.ts`, `loopback-host.ts`) - one foreground process that serves the dashboard, gives each agent a checkout [5] and a process, and runs every background job on one clock.
 - **Projects on this machine** (`registry.ts`, `project.ts`, `install.ts`, `layout.ts`, `framework-gitignore.ts`, `project-errors.ts`, `project-pass.ts`, `pick-directory.ts`, `config.ts`, `config-layers.ts`, `preference-defaults.ts`, `agent-options.ts`) - the one user file listing the projects and the preferences, what activating a repository does to it, the per-repository defaults that travel with the code, and the order in which the layers of a decision are resolved.
 - **Checkouts and what may be removed** (`worktrees.ts`, `merged-worktrees.ts`, `agent-locks.ts`) - one checkout [5] per agent under `.branches/`, and one rule for reclaiming it: only what is already on the remote may go.
-- **Spending** (`quota-boundary.ts`, `quota-poller.ts`, `auto-pm.ts`, `maintenance.ts`, `routine-locks.ts`, `handoff-level.ts`, `on-before-mergeable-prompt.ts`) - the share of the quota [6] week that may be spent by now, what the daemon starts under it, the routines [15] it rotates through, the lock that keeps a routine to one machine, and the ladder a finished agent publishes itself by.
+- **Spending** (`quota-boundary.ts`, `quota-poller.ts`, `auto-pm.ts`, `daemon-writes.ts`, `maintenance.ts`, `routine-locks.ts`, `handoff-level.ts`, `on-before-mergeable-prompt.ts`) - the share of the quota [6] week that may be spent by now, what the daemon starts under it when the `agent-data` branch moves, the trailer that tells the daemon's own commits from a move, the routines [15] it rotates through, the lock that keeps a routine to one machine, and the ladder a finished agent publishes itself by.
 - **Getting the work out** (`ci-watch.ts`, `closing-keywords.ts`, `update-check.ts`) - the pull requests The Framework opened are merged once their checks pass and fixed by an agent when they go red, and closing keywords in an agent's text are defused so a pull request closes only what it should.
 - **Work that runs somewhere else** (`cloud-work.ts`, `cloud-run-state.ts`, `cloud-scratch-refs.ts`, `bridge-browser.ts`) - a Claude Code cloud session is recognized by the commit its branch descends from, its state is worded the same way on every surface, and the daemon can run its own browser so the bridge works with no Chrome of the user's open.
 - **The agent's browser** (`browser.ts`, `browser-stream.ts`) - a real Chrome an agent can drive, whose page the dashboard shows live and hands to the user at a login wall.
diff --git a/packages/framework/src/agent-locks.LOGIC.md b/packages/framework/src/agent-locks.LOGIC.md
index c08ce745f..7dead0d77 100644
--- a/packages/framework/src/agent-locks.LOGIC.md
+++ b/packages/framework/src/agent-locks.LOGIC.md
@@ -12,7 +12,7 @@ Serializes everything that changes one agent [1]'s checkout [2] inside the daemo
 [2] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [3] sweep: a background job the daemon runs on its clock.
 [4] reclaim: removing a finished agent's checkout once its work is on the remote.
-[5] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[5] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [6] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [7] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
 
diff --git a/packages/framework/src/agent.LOGIC.md b/packages/framework/src/agent.LOGIC.md
index 8ec526750..e287655ba 100644
--- a/packages/framework/src/agent.LOGIC.md
+++ b/packages/framework/src/agent.LOGIC.md
@@ -1,4 +1,4 @@
-Runs one agent [1] from its first prompt to its end event: frames the coding agent [2], opens one driver session [3] for the whole agent, sends the opening prompt, honors every gate [4] the coding agent stops at, works the agent queue [5] when the agent is a build agent [6], takes the user's live chat [7], and ends, while streaming every step onto the one event stream [8] every surface is a projection of. A hands-off [9] agent is the exception to the middle of that story: its opening turn [10] is the whole agent.
+Runs one agent [1] from its first prompt to its end event: frames the coding agent [2], opens one driver session [3] for the whole agent, sends the opening prompt, honors every gate [4] the coding agent stops at, and then, when the agent is a build agent [6], takes the user's live chat [7], and ends, while streaming every step onto the one event stream [8] every surface is a projection of. A hands-off [9] agent is the exception to the middle of that story: its opening turn [10] is the whole agent.
 
 ## Context
 
@@ -15,7 +15,7 @@ Runs one agent [1] from its first prompt to its end event: frames the coding age
 [3] driver session: the coding agent's own conversation for one agent, which the driver can resume by its session id.
 [4] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent. When nobody can answer, the recommended option is taken.
 [5] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
-[6] build agent / prompt agent: the two kinds of agent: a build works the agent queue after its opening exchange; a prompt agent runs one prompt and stops there.
+[6] build agent / prompt agent: the two kinds of agent: a build is framed by The Framework's build prompt and takes live chat after its opening exchange; a prompt agent runs one prompt and stops there.
 [7] live chat: the user's own messages to a running agent, each continuing the same driver session. One of them is a message.
 [8] event stream: everything an agent does, one event per line appended to `.the-framework/events.jsonl` in its checkout; every surface (dashboard, terminal, archive, run) is a projection of it.
 [9] hands-off: said of an agent whose work leaves this machine, so its first prompt is the whole agent: an agent whose location is `web`.
@@ -36,7 +36,6 @@ Runs one agent [1] from its first prompt to its end event: frames the coding age
 [24] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
 [25] await limit: the cap on consecutive gates within one exchange; an agent still asking past it finishes with its latest turn.
 [26] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles. The opposite is attended.
-[27] backlog loop: after a build agent's opening work settles, the loop that works the agent queue one entry per turn until it is empty.
 [28] settled: said of an agent whose work has stopped and which is waiting for the user: it is alive, takes messages, and does nothing until told.
 [29] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 [30] view: a markdown document an agent pushes to the dashboard's right rail while it works.
@@ -49,12 +48,11 @@ Runs one agent [1] from its first prompt to its end event: frames the coding age
 - **One driver session for the whole agent** - every prompt of the agent goes into one driver session; a continuation resumes the stopped leg's conversation instead of starting a new one; the session is disposed however the agent ends.
 - **The opening prompt** - the user's text rendered through the built-in system prompt's user-prompt slot, or verbatim for a continuation, a vanilla or a transparent agent.
 - **The opening exchange** - the opening turn plus every gate it leads to, up to the await limit of five; nobody to answer means the recommended option; a pick marked stop ends the agent.
-- **A stop is honored before any phase counts as a success** - after the opening exchange, and again after the backlog and chat, a stopped agent ends as stopped, never as done.
-- **The backlog loop, and when it is skipped** - only a build agent that is not hands-off works the agent queue, and only when the loop is enabled, which it is by default for every driver but the fake demo one; a pick marked stop inside an entry ends the whole agent.
-- **Live chat, and where it happens** - a prompt agent takes chat inside its opening exchange, a build agent after its backlog; by default the agent drains what has arrived and ends on an idle queue, and only a stay-open agent parks for the next message.
-- **A hands-off agent ends at its first turn** - no backlog loop and no chat after it, an explicit "Handed off" line before the end, and the land-everything instruction in its system channel.
+- **A stop is honored before any phase counts as a success** - after the opening exchange, and again after the chat, a stopped agent ends as stopped, never as done.
+- **Live chat, and where it happens** - a prompt agent takes chat inside its opening exchange, a build agent after its opening work; by default the agent drains what has arrived and ends on an idle queue, and only a stay-open agent parks for the next message.
+- **A hands-off agent ends at its first turn** - no chat after it, an explicit "Handed off" line before the end, and the land-everything instruction in its system channel.
 - **Every turn's signals are read** - each final message is parsed for views, reported errors, the ready-for-merge signal and the pull request text, with one deduplication span across the opening exchange and chat.
-- **How the agent ends** - done with its final text and the backlog result; stopped when the user's Stop or a stop pick ended it, with "stopped by your answer" as the detail for a pick; failed on any other error; the error is passed on to the agent's process either way.
+- **How the agent ends** - done with its final text; stopped when the user's Stop or a stop pick ended it, with "stopped by your answer" as the detail for a pick; failed on any other error; the error is passed on to the agent's process either way.
 
 ## Business logic
 
@@ -96,7 +94,7 @@ Hands-off is decided here from the agent's location [22]: only `web` is hands-of
 
 The driver starts one driver session [3] bound to the agent's checkout [18], with the composed system channel, the chosen model, and the agent's stop signal. Every prompt of the agent goes into that session: the opening prompt, every gate [4] continuation, every queue entry, every chat message.
 
-A continuation names the driver session id of a stopped leg. The driver then resumes that conversation, so the coding agent [2] answers with its full prior context, and everything around the turn still runs: the gates, the backlog loop [27], live chat [7]. The flow resumes, not just the conversation.
+A continuation names the driver session id of a stopped leg. The driver then resumes that conversation, so the coding agent [2] answers with its full prior context, and everything around the turn still runs: the gates, live chat [7]. The flow resumes, not just the conversation.
 
 The driver session is disposed when the agent ends, whichever way it ends.
 
@@ -128,27 +126,11 @@ The opening prompt is sent as one turn [10]. When the turn's final message ends
 
 #### Context
 
-**Problem**: the user's Stop and a pick marked stop trip the same stop signal between turns, but the exchange, the backlog loop and the chat do not observe that signal themselves. Without a check, a stopped agent would settle as done, and a done agent authorizes the handoff [15] of the very work the user declined.
+**Problem**: the user's Stop and a pick marked stop trip the same stop signal between turns, but the exchange and the chat do not observe that signal themselves. Without a check, a stopped agent would settle as done, and a done agent authorizes the handoff [15] of the very work the user declined.
 
 #### Business logic
 
-The agent checks its stop signal twice: right after the opening exchange, and again after the backlog loop [27] and the live chat [7], before the success path. When the signal is tripped, the agent ends as stopped (see "How the agent ends") and no later phase runs. The two sources of the signal are the user's Stop [24], which the agent's process raises from the Stop button, Ctrl-C or the control file [14], and a pick marked stop from any phase.
-
-### The backlog loop, and when it is skipped
-
-#### Context
-
-**User story**: a build agent whose opening work has settled goes on to work the agent queue [5] one entry per turn until the queue is empty, asking "Start the next queue item?" before each entry when someone can answer.
-
-#### Business logic
-
-The backlog loop [27] runs only when all three hold:
-
-- the agent is a build agent [6] (a prompt agent is one prompt by definition);
-- the agent is not hands-off [9];
-- the loop is enabled: explicitly by the agent's process, or by default when the driver [17] is not the fake demo driver, whose scripted demo writes no queue and must stay deterministic. The agent's process turns the loop off for a transparent [21] agent.
-
-The loop's own rules (the per-entry gate, the entry cap, the removal of each worked entry from the `agent-data` branch) are `todo-loop.ts`'s. Two of its outcomes matter here: a pick [23] marked stop [24] inside an entry's turn ends the whole agent through the stop signal, while the per-entry "Stop the queue loop" pick only ends the loop, after which the agent goes on to chat and to its end. The loop's result (entries worked, why it ended) is handed back with the agent's result.
+The agent checks its stop signal twice: right after the opening exchange, and again after the live chat [7], before the success path. When the signal is tripped, the agent ends as stopped (see "How the agent ends") and no later phase runs. The two sources of the signal are the user's Stop [24], which the agent's process raises from the Stop button, Ctrl-C or the control file [14], and a pick marked stop from any phase.
 
 ### Live chat, and where it happens
 
@@ -160,7 +142,7 @@ The loop's own rules (the per-entry gate, the entry cap, the removal of each wor
 
 #### Business logic
 
-Where chat runs depends on the kind of agent: a prompt agent [6] takes it inside the opening exchange, right after its gates, because nothing comes between; a build agent takes it after the backlog loop [27], and only if the agent has not been stopped by then. A hands-off [9] agent is wired like a prompt agent: its message source is drained inside the opening exchange.
+Where chat runs depends on the kind of agent: a prompt agent [6] takes it inside the opening exchange, right after its gates, because nothing comes between; a build agent takes it after its opening work, and only if the agent has not been stopped by then. A hands-off [9] agent is wired like a prompt agent: its message source is drained inside the opening exchange.
 
 Each message is sent as a turn [10] resuming the same driver session [3], and the gates [4] that turn ends on are honored like the opening exchange's, with the same await limit. How chat ends:
 
@@ -182,8 +164,7 @@ For an agent whose location [22] is `web`:
 
 - the system channel carries the land-everything instruction ("This session runs detached — land everything"), and nothing else about its gates changes: a cloud session's gates are the same as a local agent's;
 - the opening exchange runs as for any agent;
-- the backlog loop [27] is skipped even when it was explicitly enabled, and the agent queue [5] is left untouched and unasked about;
-- the chat after the backlog is skipped;
+- the chat after the opening exchange is skipped;
 - before the end event the log says "Handed off: the rest of this session happens in its own session, which opens its own pull request.", so a finished hands-off agent does not read as one that gave up after a turn;
 - the agent then ends as done; the agent's process words its own success line as handed off, since this machine built nothing it saw.
 
@@ -205,7 +186,7 @@ Every turn's final message is read for the turn signals [16] (the parsing rules
 
 #### Business logic
 
-- Done: once every phase has run and the stop signal is clear, the end event says the agent finished well, and the agent hands back its final text, every event in order, and the backlog loop's result when the loop ran.
+- Done: once every phase has run and the stop signal is clear, the end event says the agent finished well, and the agent hands back its final text and every event in order.
 - Stopped: when the agent's turn loop threw and either the user's Stop [24] signal is tripped or a pick [23] marked stop tripped the agent's own stop, the end event says the agent did not finish and was stopped. Its detail is "stopped by your answer" for a stop pick, else the message of the error the abort raised.
 - Failed: any other error ends the agent with an end event that says it did not finish, with the error's message as the detail.
 - In the stopped and failed cases the error is passed on to the agent's process, whose epilogue decides what the handoff does with a stopped agent.
diff --git a/packages/framework/src/agent.test.LOGIC.md b/packages/framework/src/agent.test.LOGIC.md
index 7929d64cf..7973b5c22 100644
--- a/packages/framework/src/agent.test.LOGIC.md
+++ b/packages/framework/src/agent.test.LOGIC.md
@@ -10,8 +10,7 @@ What the tests cover, across the agent lifecycle in `agent.ts` and the gate mech
 - **A declined plan stops the agent** - picking an option marked stop ends the agent cleanly: the coding agent is never told the answer, the log says "Stopped at your answer: Decline", and the end is a stop with the detail "stopped by your answer", not a failure; an option not marked stop is an ordinary answer whatever its label, so "Decline" without the mark is passed on and the agent ends done; a stop-marked pick during the live chat after a build stops the agent there too, so the declined work is never published.
 - **Nobody to ask** - with no one wired to answer, the agent takes the recommended option, continues from it, and the resolution says the pick was automatic.
 - **The coding agent is a black box** - with no gate, the opening prompt is the only prompt the coding agent ever sees: no review pass follows the build.
-- **The backlog loop** - an agent on the fake driver skips the backlog loop by default and logs nothing about the queue; when opted in, the loop runs after the build inside the agent's own driver session against the agent queue on the `agent-data` branch: its one entry is worked and removed ("Queue: 1 open item(s)", then "Queue done" before the end event), and the result says one entry completed and the loop ended because the queue was empty.
-- **The exchange shared by the opening turn and the backlog loop** - a gate is resolved, the coding agent is re-prompted with the one shared continuation wording built from the gate's title and the picked label, "Continuing with your choice: Option B" is logged, and every turn, the gate turn included, goes through the turn-signal reader; a stop-marked answer stops instead of re-prompting, logs the stop message, and is not reported as exhausted; the approving half of the same gate continues ("chose: Approve"); an agent that asks forever is cut off at the await limit and reported exhausted, having been prompted once for the opener and once per round; when live chat follows an opening exchange that hit the limit, the result is not reported exhausted; a stay-open agent announces settled each time it parks, once after the opening turn settles and once after each chat turn.
-- **A hands-off agent** - ends at its first turn even with the backlog loop explicitly enabled: one prompt, no gate asked, the agent queue left untouched and unasked about, and a "Handed off:" log line before the end; its system channel says "This session runs detached — land everything" and never "decide alone", while a local agent's does not mention running detached; it does not stay open for messages and ends even with its message source left open.
+- **The exchange shared by the opening turn and the build path** - a gate is resolved, the coding agent is re-prompted with the one shared continuation wording built from the gate's title and the picked label, "Continuing with your choice: Option B" is logged, and every turn, the gate turn included, goes through the turn-signal reader; a stop-marked answer stops instead of re-prompting, logs the stop message, and is not reported as exhausted; the approving half of the same gate continues ("chose: Approve"); an agent that asks forever is cut off at the await limit and reported exhausted, having been prompted once for the opener and once per round; when live chat follows an opening exchange that hit the limit, the result is not reported exhausted; a stay-open agent announces settled each time it parks, once after the opening turn settles and once after each chat turn.
+- **A hands-off agent** - ends at its first turn: one prompt, no gate asked, the agent queue left untouched, and a "Handed off:" log line before the end; its system channel says "This session runs detached — land everything" and never "decide alone", while a local agent's does not mention running detached; it does not stay open for messages and ends even with its message source left open.
 - **A continuation** - resumes the stopped leg's driver session by its id, sends the continuation message verbatim with no framing, announces it as the intent, and still runs as a build.
 - **The opening prompt and the two kinds of agent** - a build's first prompt is the user's text itself, with no wrapper around it; a prompt agent runs its text as its one prompt without build framing and works no backlog, even when the agent queue holds an entry.
diff --git a/packages/framework/src/auto-pm.LOGIC.md b/packages/framework/src/auto-pm.LOGIC.md
index a7ad7cf13..323fbf3eb 100644
--- a/packages/framework/src/auto-pm.LOGIC.md
+++ b/packages/framework/src/auto-pm.LOGIC.md
@@ -1,55 +1,102 @@
-Decides, once per sweep [1] and per project, whether the daemon may spend the account's quota [2] on work nobody asked for, and on what. Auto PM [3] either drains [4] the agent queue [5] by starting one agent [6] per open queue entry, or, when the queue is empty, refills it by firing the next routine [7] of a fixed rotation. Every reason not to start is a sentence the daemon logs and the dashboard shows, and every routine the sweep fires is built from a preset, so the routines the dashboard lists and the work the daemon actually starts cannot drift apart.
+Decides, once per look [1] and per project, whether the daemon may spend the account's quota [2] on work nobody asked for, and on what. Auto PM [3] either starts an agent [6] on the queued work [4] because the `agent-data` branch [11] moved, or, once a run found nothing queued, refills the agent queue [5] by firing the next routine [7] of a fixed rotation. The daemon reads no queue and names no skill: it reads the head of the branch, and it starts the queued work with one slash command, `/work-queue`, the routine skill [22] shipped with The Framework. Every reason not to start is a sentence the daemon logs and the dashboard shows.
 
 ## Context
 
-**User story**: the user switches Auto PM [3] on in the dashboard's Settings and walks away. While the account is under its quota boundary [8] and the project has room for another agent [6], the daemon works the agent queue [5] down, one entry per agent, and once the queue runs dry it brings tickets across from GitHub, triages them onto the queue, and plans the rest, so the leftover quota week is spent on the roadmap instead of expiring. The user clicks "Run now" on a routine's [7] row to fire that routine at once, and reads on the dashboard what the last sweep [1] decided for each project and why.
+**User story**: the user switches Auto PM [3] on in the dashboard's Settings and walks away. Someone queues three tasks, on this machine or another. Within a minute the daemon starts an agent [6] on the queue; the agent takes one task, commits, closes its ticket and marks the entry done; those commits move the branch, so as the run ends the daemon starts the next; the fourth run finds nothing queued, says so, and the chain stops. Then the daemon brings tickets across from GitHub, triages them onto the queue, and plans the rest, so the leftover quota week is spent on the roadmap instead of expiring. The user clicks "Run now" on a routine's [7] row to fire that routine at once, and reads on the dashboard what the last look [1] decided for each project and why.
 
-**Business logic story**: the sweep is pure policy. The daemon supplies the readings (the preferences, the queue, the agents live on a project, the quota [2], the ticket files) and performs the effects (starting agents, writing claims [9] and routine locks [10] on the `agent-data` branch [11], retiring a finished agent's queue entry); the rules about when and what live here, and the wiring in `daemon-services.ts`. The sweep's declared cadence is 10 minutes, taken as turns of the daemon's single clock (`daemon-tick.ts`); the first sweep after start-up is the daemon's to fire. Two sweeps never overlap: a sweep asked for while one is running does nothing, because a sweep reads a picture of the live agents that its own starts change. Nothing of the sweep outlives the daemon: closing the daemon with Ctrl-C ends it, and it cannot be restarted from outside the process.
+**Business logic story**: the sweep is pure policy. The daemon supplies the readings (the preferences, the head of the branch and how many commits since the last look nobody's daemon wrote, the agents live on a project, the quota [2], the ticket files a plan fan-out may claim) and performs the effects (starting agents, writing claims [9] and routine locks [10] on the `agent-data` branch [11]); the rules about when and what live here, and the wiring in `daemon-services.ts`. The look runs once a minute, right behind the daemon's pull of the branch, as turns of the daemon's single clock (`daemon-tick.ts`); the first look after start-up is the daemon's to fire. Two looks never overlap: a look asked for while one is running does nothing, because a look reads a picture of the live agents that its own starts change. Nothing of the sweep outlives the daemon: closing the daemon with Ctrl-C ends it, and it cannot be restarted from outside the process.
 
 ## Glossary
 
-[1] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
+[1] look: one turn of Auto PM on the daemon's clock: read the branch, close out finished runs, decide, start or stand down. The dashboard and the log call it a sweep.
 [2] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
-[3] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
-[4] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
-[5] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
+[3] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
+[4] the queued work: the routine that spends existing work: one agent started with `/work-queue`, which takes one task off the agent queue by composing the skills in its checkout.
+[5] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry. The daemon never reads it.
 [6] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
-[7] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[7] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand. The queued work is a skill file; the rest are presets.
 [8] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
 [9] claim: a ticket's lock file naming the holder working it, so two agents never work the same ticket.
 [10] routine lock: a file on the `agent-data` branch (`routines/<name>.lock.md`) a daemon takes before running a routine so the routine runs once across machines.
 [11] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [12] spend offset: the user's adjustment of the quota boundary, in percentage points of the week.
 [13] coding agent: the CLI doing the actual work: Claude Code or Codex.
-[14] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
-[15] backlog loop: after a build agent's opening work settles, the loop that works the agent queue one entry per turn until it is empty.
+[14] fan-out: starting several agents at once, one per ticket to plan.
+[15] a move: a commit on the `agent-data` branch that no daemon wrote — a person queuing an entry, an agent claiming, closing or marking done. A daemon's own commits carry a trailer (`daemon-writes.ts`) and are not moves.
 [16] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [17] gate: a question with options at which an agent stops and waits for an answer. When nobody can answer, the recommended option is taken.
 [18] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it).
 [19] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [20] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
 [21] holder: who a claim names: the agent's id when the daemon started the agent, else the branch the `tickets` command ran on.
+[22] routine skill: a skill file (`SKILL.md`) marked so that only a person or the daemon invokes it, whose body is the job's prompt; the daemon starts the agent with the skill's slash command and the coding agent's harness expands it.
+[23] the heartbeat: one run on the queued work a day when nothing moved, the belt for a move the daemon missed.
+[24] the chain: the queued work firing again as its run ends, because the run's own commits moved the branch; it ends with a run that moves nothing.
 
 ## Business logic — TL;DR
 
+- **What the daemon reads** - the head of each project's `agent-data` branch [11], once a minute, and how many commits since the last look were written by something other than a daemon; nothing else about the branch, and no queue.
+- **A move starts the queued work** - a commit no daemon wrote [15] starts one agent with `/work-queue`; a daemon's own commits — run records, routine locks, claims — never do, so a run's record cannot start the next run, and two daemons sharing a branch never fire at each other.
+- **The chain** - the agent's claim, close and done are commits, so the branch has moved again by the time the run ends, and the daemon fires again; a run that found nothing queued writes nothing, and the chain stops.
+- **After an empty run, the rotation** - every run this loop started has ended and none moved the branch: the queue wants refilling, so the next routine [7] of the rotation gets the turn; a rotation run that moved nothing hands the turn on, at the cooldown's pace.
+- **The first look remembers, and owes the rotation its start-up turn** - a daemon that just started knows nothing about what moved while it was down; it remembers the head, starts nothing on the queued work, and takes the rotation's turn as a daemon always has.
+- **The heartbeat** - once a day with nothing moved, the queued work runs anyway [23].
 - **When unattended work may start** - per project, every condition is a reason not to spend, checked cheapest first, and the first one that holds stands the project down with a sentence.
 - **The quota boundary fails closed** - an unreadable quota refuses, and a quota window at or past the boundary refuses with the window and the exact line named.
 - **The concurrency cap names its slots** - a project keeps at most the configured number of agents going (2 by default, never below 1), and the refusal lists what holds each slot.
-- **The cooldown, and the click that bypasses it** - a project is left alone for 30 minutes after the sweep starts something on it, except when a person clicked "Run now".
-- **Drain or product management: the queue decides** - a queue with open entries is worked before anything new is made; only an empty queue reaches the rotation.
+- **The cooldown paces the rotation only** - a project is left alone for 30 minutes after the rotation starts something on it; a move [15] and a click are never paced.
 - **The routine rotation and its order** - update tickets, triage the quick wins, triage the consensual work, plan tickets, in that order, per project, minus what is switched off, advancing only on a start that took.
-- **The maintenance sweep is paced by the calendar** - when due it outranks the rotation, but only on a genuinely empty queue, and it stamps its own schedule instead of moving the rotation.
-- **Closing out what an earlier sweep started** - before judging a queue, finished agents have their entry retired, a claim they abandoned freed, and their routine lock released, each with bounded retries.
-- **Draining fans out, one agent per entry** - as many agents as the cap has room for, each pinned to its own open entry, with the entry's ticket claimed first when the entry links one.
+- **The maintenance sweep is paced by the calendar** - when due it outranks the rotation, but only on a rotation turn, and it stamps its own schedule instead of moving the rotation.
+- **Closing out what an earlier look started** - before deciding, finished agents have their routine lock released and a claim they abandoned freed, each with bounded retries; a run still going holds the rotation's turn.
 - **Planning fans out, one agent per ticket** - the one rotation routine that fans out: each agent is pinned to one claimed ticket, and a batch that could claim nothing falls back to a single unpinned agent.
 - **Triage takes a routine lock** - the two triage routines are taken as `routines/<name>.lock.md` before they start, so they run once across machines, and stand down when the lock is alive.
-- **Starting the batch, and stopping** - the first refused start ends the batch, claims of agents that never started are released, and a stopped daemon spawns nothing more.
-- **"Run now": a sweep a person asked for** - runs with the preference off and without the cooldown, scoped to one project or one routine, and never borrows the click for other work.
-- **What the last sweep reports** - the dashboard shows whether the preference was on, when the sweep ran, when the next is due, and one sentence per project, the same sentence the daemon logged.
-- **The routines are built from the presets** - name, prompt, label and tooltip come off the preset; what a routine does (drains, fans out, takes a lock, auto-merges) is declared on the routine, never matched by name.
+- **Starting, and stopping** - the first refused start ends the batch, claims of agents that never started are released, and a stopped daemon spawns nothing more.
+- **"Run now": a look a person asked for** - runs with the preference off and without the cooldown, scoped to one project or one routine; the queued work's row starts an agent on the queue whether or not the branch moved.
+- **What the last look reports** - the dashboard shows whether the preference was on, when the look ran, when the next is due, and one sentence per project; the log gets a stand-down only when it is news.
+- **The routines** - the queued work is the routine skill `work-queue`; the rest are built from the presets: name, prompt, label and tooltip come off the preset; what a routine does (works the queue, fans out, takes a lock, auto-merges) is declared on the routine, never matched by name.
 
 ## Business logic
 
+### What the daemon reads
+
+#### Context
+
+**Problem**: the daemon used to read the agent queue [5] through the queue skill's library, claim tickets through the tickets skill's, and tell each agent which entry to work. That made the daemon depend on both skills and their file formats. A daemon that knows no skill can only watch the one thing every skill writes: the `agent-data` branch [11].
+
+#### Business logic
+
+On every look [1], for every project, the daemon reads the local head of the project's `agent-data` branch, after its own pull of that branch has run (the pull is `daemon-services.ts`'s). A project whose branch cannot be read stands down with "the agent-data branch could not be read, so there is no way to tell whether anything moved". When the head differs from the head remembered at the last look, the daemon counts the commits between the two that carry no `Daemon:` trailer (the counting is `daemon-writes.ts`'s); one or more is a move [15]. The new head is remembered either way. A move stays remembered until the queued work [4] is started for it, however many looks pass; a rotation start does not spend it.
+
+### A move starts the queued work
+
+#### Context
+
+See `## Context`.
+
+#### Business logic
+
+A project whose branch moved [15] starts one agent [6] told `/work-queue`, the routine skill [22] shipped in this package and linked into every checkout the daemon makes (`daemon-runtime.ts`), unattended [16], with its handoff [18] at `merge`, since what it implements has already been triaged onto the queue where a human could have vetoed it. One agent per move, however high the concurrency cap: the next start needs the branch to move again, which the agent's own commits do. The start spends the move and the rotation's turn alike: whether the queue wants refilling is for this run to find out. A commit the daemon wrote itself is not a move: the run's record the daemon writes at teardown, a routine lock [10] it takes or drops, a claim [9] it mints for a plan agent all carry the trailer, on this machine and on every other machine running the daemon, so a record never starts the next run and two daemons on one branch never fire empty runs at each other's records. A person's writes from the dashboard — queue an entry, release a claim — carry no trailer and are moves: a person asking for work is exactly what should start a run.
+
+### The chain, and after an empty run the rotation
+
+#### Context
+
+**Problem**: three tasks queued at once must all be worked without the daemon reading the queue to see that more remain; and the rotation that invents work must not run while queued work is still being worked, nor stop forever once it has.
+
+#### Business logic
+
+Every run this loop started is closed out at the next look [1] (see "Closing out what an earlier look started"). When every run of this loop on the project has ended and the branch did not move [15] meanwhile, the last run found nothing queued: the project is owed a rotation turn. While any run of this loop is still going, no turn is owed: its commits may yet arrive. A move takes precedence over an owed turn: the queued work [4] runs first, and its run decides again. So the chain [24] runs as long as each run moves the branch, the rotation resumes once a run does not, and a rotation run that moved nothing hands the turn to the next routine [7] — the idle cycle a daemon has always run, at the cooldown's pace. A move while the queued-work routine is switched off is a rotation turn instead: switching it off means "do not work the queue", and the rotation does not work it; triage and planning put entries on it, and standing down there would make every inventing routine unreachable for as long as the queue had anything on it.
+
+### The first look, and the heartbeat
+
+#### Context
+
+**Problem**: a daemon that just started has no head to compare against, and firing a run per project on every restart would spend a run finding an empty queue each time; but a move the daemon never saw — a restart between a push and the look, a range git could not walk — must not be lost for good.
+
+#### Business logic
+
+The first look at a project remembers the branch's head and starts nothing on the queued work [4]. It does take the rotation's turn, as a daemon started with the setting already on has always done at start-up rather than sitting idle with quota to spare. The heartbeat [23]: when a day has passed since the queued work was last started on a project — counted from the first look, so the first heartbeat is a day after the daemon started — the queued work runs as if the branch had moved.
+
 ### When unattended work may start
 
 #### Context
@@ -58,30 +105,29 @@ See `## Context`.
 
 #### Business logic
 
-A sweep [1] first reads the Auto PM [3] preference once, so the toggle takes effect without a restart. Off, or unreadable, ends the sweep before any project is visited, unless the sweep is a "Run now". Then it reads the projects; a list that could not be read is empty and ends the sweep. It re-reads, once per sweep, the routines [7] the user switched off and the concurrency setting, so a change mid-schedule holds for the projects still to come.
+A look [1] first reads the Auto PM [3] preference once, so the toggle takes effect without a restart. Off, or unreadable, ends the look before any project is visited, unless the look is a "Run now". Then it reads the projects; a list that could not be read is empty and ends the look. It re-reads, once per look, the routines [7] the user switched off and the concurrency setting, so a change mid-schedule holds for the projects still to come.
 
-For each project, the conditions are checked in this order, cheapest first, and the first that holds stands the project down with its sentence:
+For each project, once the branch has been read and the finished runs closed out, the look decides what the turn is for: the queued work [4] when the branch moved [15] or the heartbeat [23] is due; else the rotation when a turn is owed, or on a plain "Run now"; else nothing, recorded as "nothing moved on the agent-data branch since the last run". Then the conditions are checked in this order, cheapest first, and the first that holds stands the project down with its sentence:
 
 - Auto PM is off: "auto PM is off".
-- The project already has as many agents [6] live as the concurrency cap allows: the refusal described under "The concurrency cap names its slots".
-- The sweep started something on this project less than the cooldown ago: "a run was started for this project a moment ago". A "Run now" skips this condition.
-- The agent queue [5] could not be read: "the agent queue could not be read, so there is no way to tell what to do". An unreadable queue is neither empty nor full: both of those answers start something, so only "could not tell" starts nothing.
+- The project already has as many agents [6] live as the concurrency cap allows: the refusal described under "The concurrency cap names its slots". A move stays remembered, so the queued work starts once a slot frees.
+- The turn is the rotation's and the rotation started something on this project less than the cooldown ago: "a run was started for this project a moment ago". A "Run now" skips this condition, and so does the queued work.
 - The quota [2] could not be read, or a quota window is at or past the boundary: the refusals described under "The quota boundary fails closed".
 
-Otherwise the project may start, in the mode the queue picks (see "Drain or product management: the queue decides"). A stand-down is logged as "auto PM: standing down for <project path> — <reason>" and recorded for the dashboard with the same reason.
+A stand-down is recorded for the dashboard with its reason, and logged as "auto PM: standing down for <project path> — <reason>" only when the reason differs from the last one said for that project, so a stand-down that holds for a day is one line rather than a line a minute; a start is always logged.
 
 ### The quota boundary fails closed
 
 #### Context
 
-**Problem**: the quota boundary [8] is the share of the quota week elapsed so far, rising continuously with the clock, moved by the user's spend offset [12]. Work the user asks for may cross it and borrow against the days still to come; work nobody asked for is exactly what the line exists to stop. Quietly burning a subscription on unasked work is a worse failure than skipping a sweep [1], so, unlike the per-agent guard that never stops the user's own work when the quota [2] cannot be read, this check refuses. The reading is the account's own week as the coding agent [13] reports it, absolute and complete, so a daemon that just restarted is not blind to what the account already spent. How a reading is measured against the boundary lives in `quota-boundary.ts`.
+**Problem**: the quota boundary [8] is the share of the quota week elapsed so far, rising continuously with the clock, moved by the user's spend offset [12]. Work the user asks for may cross it and borrow against the days still to come; work nobody asked for is exactly what the line exists to stop. Quietly burning a subscription on unasked work is a worse failure than skipping a look [1], so, unlike the per-agent guard that never stops the user's own work when the quota [2] cannot be read, this check refuses. The reading is the account's own week as the coding agent [13] reports it, absolute and complete, so a daemon that just restarted is not blind to what the account already spent. How a reading is measured against the boundary lives in `quota-boundary.ts`.
 
 #### Business logic
 
 - No reading at all: "the quota could not be read, so there is no way to tell what is spare".
-- The reading is asked per project rather than once per sweep: the model a project's work would run on is a project-level setting, and the model's own weekly window binds alongside the account's, so two projects on two models can stand at two different places against the same reading.
+- The reading is asked per project rather than once per look: the model a project's work would run on is a project-level setting, and the model's own weekly window binds alongside the account's, so two projects on two models can stand at two different places against the same reading.
 - When a window is at or past the limit in force, the refusal names the window and the line it stopped at: "<window label> is <used>% used, at or past day <day> of the week's <boundary>%" when the spend offset is zero, and "<window label> is <used>% used, at or past day <day> of your <limit>% limit (<offset> on the week's <boundary>%)" otherwise. Percentages are whole numbers; the offset carries its sign and one decimal, since a dragged slider stores whole numbers but the default half-day cushion is 100/14. Naming the line is what keeps a user whose slider is moved from hunting for a bug that is a setting.
-- Otherwise there is headroom and the sweep goes on.
+- Otherwise there is headroom and the look goes on.
 
 ### The concurrency cap names its slots
 
@@ -91,49 +137,36 @@ Otherwise the project may start, in the mode the queue picks (see "Drain or prod
 
 #### Business logic
 
-- The cap is the concurrency setting, re-read every sweep [1]. Unset or unreadable means 2, never 1: the absence of the setting has never meant "less". Fractions are rounded down, and the result is never below 1, since zero agents is what switching Auto PM [3] off is for.
+- The cap is the concurrency setting, re-read every look [1]. Unset or unreadable means 2, never 1: the absence of the setting has never meant "less". Fractions are rounded down, and the result is never below 1, since zero agents is what switching Auto PM [3] off is for.
 - Every agent [6] live on the project counts against it, whoever started it.
 - At the cap, the refusal is "<n> run is already going" or "<n> runs are already going", followed by the labels of the live agents in parentheses, each label being the agent's id and process id as the daemon holds them; when the cap is above 1 the sentence continues ", and the routine keeps at most <cap> at once". At a cap of 1 the wording stops after the names.
-- The cap holds for a "Run now" too: it is what keeps a second click from doubling up, since a start registers before the sweep moves on.
-- A batch is sized to the room left: the cap minus the agents live on the project.
+- The cap holds for a "Run now" too: it is what keeps a second click from doubling up, since a start registers before the look moves on.
+- A plan batch is sized to the room left: the cap minus the agents live on the project. The queued work [4] is one agent per move [15]; with room under the cap, the next move — the first agent's own claim — starts one more alongside it.
 
-### The cooldown, and the click that bypasses it
+### The cooldown paces the rotation only
 
 #### Context
 
-**Problem**: a spawned agent [6] takes a moment to appear among the daemon's live agents; without a pause, the next sweep [1] would see "nothing running, queue still empty" and start a second one.
+**Problem**: the rotation invents work on an idle project, and without a pause it would fire a routine [7] every look [1]. A move [15] of the branch is different: someone, or an agent, asked for that run, and the daemon firing again as a run ends is the chain [24] itself.
 
 #### Business logic
 
-- A project is left alone for 30 minutes after this sweep started something on it: "a run was started for this project a moment ago". Only the sweep's own starts arm it; an agent the user started counts toward the cap instead.
-- The cooldown is armed before the first spawn of a batch and once for the whole batch: starting is slow, and a sweep overlapping the spawns would otherwise see too few live agents and top up past the cap. When the batch started nothing, the cooldown is given back, so a project is not stranded for half an hour by a start that spent nothing.
+- A project is left alone for 30 minutes after the rotation started something on it: "a run was started for this project a moment ago". Only the rotation's own starts arm it; an agent the user started counts toward the cap instead, and a start on the queued work [4] arms nothing, since its next start needs the branch to move again, which is a better guard than a clock.
+- The cooldown is armed before the first spawn of a batch and once for the whole batch: starting is slow, and a look overlapping the spawns would otherwise see too few live agents and top up past the cap. When the batch started nothing, the cooldown is given back, so a project is not stranded for half an hour by a start that spent nothing.
 - A "Run now" ignores the cooldown: the cooldown paces work nobody asked for, and a click is asking. Every other reason to stand down still holds.
 
-### Drain or product management: the queue decides
-
-#### Context
-
-**Problem**: the backlog loop [15] that works the agent queue [5] exists only inside an agent [6] a human started. Unattended [16], a queue that only ever got filled would never empty, so a non-empty queue is not a reason to stand down: it is the thing to do, and standing work is spent before more is made.
-
-#### Business logic
-
-- A queue with open entries puts the sweep [1] in drain [4] mode: agents are started on its entries, through the drain routine.
-- An empty queue puts it in product management mode: the routine [7] whose turn it is fires, or the maintenance sweep when due.
-- When the drain routine is switched off while the queue has work, the sweep does not stand down: the rotation gets the turn instead. Switching the drain off means "do not work the queue", and the rotation does not work it; triage and planning put entries on it. Standing down here would make every routine that invents work unreachable for as long as the queue had anything on it, which, with a queue that fills itself, is most of the time. A drain-only "Run now" is the exception: it has already stood down by then, because the click asked for the queue specifically.
-- The maintenance sweep never fires while the queue has entries, including when the turn fell through to the rotation because the drain routine is off.
-
 ### The routine rotation and its order
 
 #### Context
 
-**Problem**: the rotation is a cycle whose order matters. Importing leads because it is the only routine [7] that can add a ticket none of the others has seen; without it a rotation that triages and plans a set nothing refills eventually has nothing to do, and a new GitHub issue would wait for a human to press a button. Triage turns tickets into queued work. Planning is the most expensive turn and the one whose output the earlier routines consume, so it runs last. No separate scheduler exists or is needed: the rotation fires on every sweep [1] where the queue is dry, which is exactly when the queue wants refilling.
+**Problem**: the rotation is a cycle whose order matters. Importing leads because it is the only routine [7] that can add a ticket none of the others has seen; without it a rotation that triages and plans a set nothing refills eventually has nothing to do, and a new GitHub issue would wait for a human to press a button. Triage turns tickets into queued work. Planning is the most expensive turn and the one whose output the earlier routines consume, so it runs last. No separate scheduler exists or is needed: the rotation fires after every run that found nothing queued, which is exactly when the queue wants refilling.
 
 #### Business logic
 
 - The order: "Update from GitHub" (`update-tickets`), "Add quick-win work to AI Queue" (`triage-quick`), "Add consensual work to AI Queue" (`triage-consensual`), "Plan tickets (aka spike)" (`plan-tickets`). Importing is safe to repeat: the preset resumes from where the last import stopped and reconciles, so a firing with nothing changed is a no-op rather than a re-import.
 - The position in the cycle is kept per project, so two projects idle at once each work through the whole rotation rather than taking alternate halves of it. Nothing of it survives the daemon.
-- The routines the user switched off are removed from the cycle before the position is applied, so with two of four off the remaining two alternate instead of every other turn landing on a routine that cannot run. The switched-off list is re-read every sweep, and a list that cannot be read means none is off: a preference that cannot be read must not silently switch the whole rotation off.
-- The position advances only when a start took, so a refused start is retried rather than skipped, and only for a rotation routine fired by the rotation itself: a drain, the maintenance sweep and a routine a click named all leave it where it is. A planning turn that finds nothing left to plan also advances it, because that is the routine's work being done rather than refused, unless a click named the routine.
+- The routines the user switched off are removed from the cycle before the position is applied, so with two of four off the remaining two alternate instead of every other turn landing on a routine that cannot run. The switched-off list is re-read every look [1], and a list that cannot be read means none is off: a preference that cannot be read must not silently switch the whole rotation off.
+- The position advances only when a start took, so a refused start is retried rather than skipped, and only for a rotation routine fired by the rotation itself: the queued work [4], the maintenance sweep and a routine a click named all leave it where it is. A planning turn that finds nothing left to plan also advances it, because that is the routine's work being done rather than refused, unless a click named the routine.
 - When every routine that makes new work is switched off, the project stands down with "every routine that makes new work is switched off"; a daemon wired with no routines at all says "there is no job to run". The two are told apart on purpose: the first is a setting the user can see and undo.
 - No routine may end at a gate [17]: the "Suggest tickets to work on" preset, which stops to ask, is deliberately not a routine, since firing it unattended [16] would park an agent [6] against a human who will never answer, and no routine's prompt may contain a gate.
 
@@ -141,59 +174,42 @@ Otherwise the project may start, in the mode the queue picks (see "Drain or prod
 
 #### Context
 
-**Problem**: the "Maintenance" preset looks at the codebase's standing history rather than at new tickets, so a rotation that cycles every idle sweep [1] is the wrong pacing for it. It is paced by a calendar kept in the project's checkout (the schedule lives in `maintenance.ts`), so a project that adopted The Framework late gets its pre-existing history looked at, an interval at a time.
+**Problem**: the "Maintenance" preset looks at the codebase's standing history rather than at new tickets, so a rotation that cycles after every empty run is the wrong pacing for it. It is paced by a calendar kept in the project's checkout (the schedule lives in `maintenance.ts`), so a project that adopted The Framework late gets its pre-existing history looked at, an interval at a time.
 
 #### Business logic
 
-- When due, the maintenance sweep outranks the rotation: the entries it queues are what the rotation would otherwise be inventing work instead of. It fires only while the agent queue [5] is genuinely empty, never on a "Run now" that named a routine [7], and never while the maintenance routine is switched off.
+- When due, the maintenance sweep outranks the rotation: the entries it queues are what the rotation would otherwise be inventing work instead of. It fires only on a rotation turn — never on a move [15], which has plenty to do — never on a "Run now" that named a routine [7], and never while the maintenance routine is switched off.
 - The switch is checked before the schedule is read, so a switched-off maintenance sweep costs no disk read and leaves its calendar untouched: it comes due normally once switched back on, rather than having been silently ticked past while off. A schedule that cannot be read means "not due", so the rotation keeps running rather than sweeping on every turn.
-- Its firing does not advance the rotation. Instead the project is stamped as swept once the start took, so the next maintenance sweep is an interval away; a start the daemon refused is retried on the next sweep rather than postponed a whole interval.
+- Its firing does not advance the rotation. Instead the project is stamped as swept once the start took, so the next maintenance sweep is an interval away; a start the daemon refused is retried on the next look [1] rather than postponed a whole interval.
 - Its prompt covers the entire codebase, and its start is reported as "sweeping the codebase for maintenance work".
 
-### Closing out what an earlier sweep started
+### Closing out what an earlier look started
 
 #### Context
 
-**Problem**: a drained queue entry stays on the agent queue [5] until the daemon retires it, and a claim [9] minted for an agent [6] is normally lifted by that agent's own pull request. An agent that ended with no commits never opens one, so its claim would stand until a human clicks "Release", and the queue would livelock on the dead claim, respawning the same work every cooldown. The sweep [1] is the one place that knows both which agents it started and how they ended, so it frees exactly the claims it minted, keyed off the recorded ending and never off a timer.
+**Problem**: a claim [9] minted for a plan agent [6] is normally lifted by that agent's own pull request. An agent that ended with no commits never opens one, so its claim would stand until a human clicks "Release", and the planning would livelock on the dead claim, respawning the same work every cooldown. The look [1] is the one place that knows both which agents it started and how they ended, so it frees exactly the claims it minted, keyed off the recorded ending and never off a timer. And whether the queue wants refilling is known only once every run this loop started has ended.
 
 #### Business logic
 
-Before judging a project's queue, every agent this sweep started on it and has not yet been closed out is looked at. The daemon reads the agent's status and recorded ending and retires the entry the agent was pinned to once the ending says the work was published (`daemon-services.ts`); the sweep decides what to do with the answer:
+Before deciding, every agent this loop started on the project and has not yet been closed out is looked at. The daemon reads the agent's status and recorded ending (`daemon-services.ts`); the look decides what to do with the answer:
 
-- Still running: kept for the next sweep.
-- Ended cleanly, but its handoff [18] has not reported yet: an agent carrying a claim or pinned to an entry is held for at most two more sweeps rather than closed out blind, since the ending is the one fact the release and the entry's retirement key off. Past that bound it is closed out unread, so a process that died mid-handoff cannot pin its entry forever.
-- Ended with nothing to hand off, carrying a claim minted here: the claim is freed by the sweep itself, and only the exact minted claim; a lock naming anyone else is left alone. The entry, or the planned ticket, is remembered as having ended dry before the release is attempted, and is not offered again for the rest of the daemon's life: a task that deterministically ends without commits would otherwise burn a quota [2] run every cooldown, forever. A daemon restart forgets the set and allows one more try, on the assumption that a human retired or reshaped the entry in between. A release that could not land, a transient git lock for instance, is retried on the next sweep, at most twice.
+- Still running: kept for the next look, and the rotation's turn waits.
+- Ended cleanly, but its handoff [18] has not reported yet: an agent carrying a claim is held for at most two more looks rather than closed out blind, since the ending is the one fact the release keys off. Past that bound it is closed out unread, so a process that died mid-handoff cannot hold its claim forever.
+- Ended with nothing to hand off, carrying a claim minted here: the claim is freed by the look itself, and only the exact minted claim; a lock naming anyone else is left alone. The ticket is remembered as having ended dry before the release is attempted, and is not offered again for the rest of the daemon's life: a task that deterministically ends without commits would otherwise burn a quota [2] run every cooldown, forever. A daemon restart forgets the set and allows one more try, on the assumption that a human retired or reshaped the ticket in between. A release that could not land, a transient git lock for instance, is retried on the next look, at most twice.
 - Held a routine lock [10]: the lock is released whatever the ending, since no pull request of the agent's ever will; a release that could not land is retried, at most twice.
-- When closing out retired one or more entries, the queue this sweep would read is stale, so the project is left to the next sweep with "landed the queue from <n> finished run(s)", logged as "auto PM: landed the queue from <n> run(s) in <project path>".
-- On a project's first sweep after the daemon started, the routine locks a previous daemon on this machine left behind whose agents are gone are released once, since nothing else would ever release them.
-
-### Draining fans out, one agent per entry
-
-#### Context
-
-**Problem**: with a single agent [6], "work the first open entry" is exact. With several going at once it is a collision: every agent forks the same checkout [19], reads the same first entry, and implements it as many times over. Naming the entry per agent is what makes a batch work on disjoint things, and a claim [9] on the entry's ticket, pushed to the `agent-data` branch [11], is what keeps another machine's sweep [1] from implementing the same ticket; without it the booking lived only in this daemon's memory.
-
-#### Business logic
-
-- The entries on offer are the open entries, in queue order, minus those pinned to agents still in flight and minus those that already ended dry. None left stands the project down with "every open queue entry is already being worked on", or, when at least one open entry ended dry, "every open queue entry is being worked on, or already drained once with nothing to hand off". An entry someone else already worked is not on the queue to begin with: its check-off travels in that agent's own pull request and the merge takes it off.
-- The batch is the first entries on offer, as many as the cap has room for.
-- Each agent's agent id [20] is minted by the sweep before any claim, from the sweep's clock and a millisecond apart, so the claim names the agent that is about to start and the agent starts with that same id: the claim and the agent are one.
-- An entry that links back to a ticket, as a markdown link into `tickets/`, has its ticket claimed before its agent starts, the same pushed `.lock.md` planning makes, but skipping only on an existing claim: a plan is the drain's input, not a competing claim. The claims are matched back by agent id, since two entries linking the same ticket race for one claim and only the one whose id the claim names may carry it. An entry whose ticket was claimed elsewhere is dropped from this batch and reconsidered next sweep; a batch that lost every entry this way stands down with "every entry in this batch links a ticket another agent already claimed". An entry that links no ticket has nothing on disk to claim and proceeds with the queue document as its only coordination point.
-- The agent's prompt names its one entry: "Work on this one open entry of the agent queue only (use the `tickets` skill):", the entry, then "Do not start any other entry, and do not take the entry off the queue — the framework does once your work lands. If the entry is no longer on the queue, stop and do nothing." With a claim, it adds that the ticket "is already claimed for you", that `tickets show <ticket>` names the agent as its holder [21], that once the work is published the agent runs `tickets close <ticket>` (closed tickets leave the branch and the claim goes with the ticket), and that a ticket not claimed or claimed by someone else "is not yours — stop and do nothing". The assignment is a snapshot: a human may retire the entry between the sweep's read and the agent's own.
-- The queue entry is never the agent's to check off: the daemon retires it once the agent's ending reports the work landed.
-- A drain agent's pull request is merged once the agent opens it: what it implements was triaged as consensual, quick-win work a human could have vetoed on the queue, so its review happened before the agent.
-- The start is reported as 'draining the queue entry "<entry>"', the entry flattened to one line and cut at 80 characters with an ellipsis.
+- Once none is left pending and the branch did not move [15] since the last start, the project is owed a rotation turn (see "The chain, and after an empty run the rotation").
+- On a project's first look after the daemon started, the routine locks a previous daemon on this machine left behind whose agents are gone are released once, since nothing else would ever release them.
 
 ### Planning fans out, one agent per ticket
 
 #### Context
 
-**Problem**: the stock planning prompt covers every ticket that has no plan or claim [9] yet, and with a batch going out that instruction is the same collision draining has: every agent [6] forks the same checkout [19] and picks the same most-important ticket. Planning is the one rotation routine [7] that may fan out [14], because it writes each ticket's own sibling files rather than rewriting the shared queue document, so concurrent copies do disjoint work and land disjoint edits. Every other rotation routine rewrites the whole queue from the same fork point, and two at once would revert each other's edits, so those stay one agent per sweep [1].
+**Problem**: the stock planning prompt covers every ticket that has no plan or claim [9] yet, and with a batch going out that instruction is a collision: every agent [6] forks the same checkout [19] and picks the same most-important ticket. Planning is the one rotation routine [7] that may fan out [14], because it writes each ticket's own sibling files rather than rewriting the shared queue document, so concurrent copies do disjoint work and land disjoint edits. Every other rotation routine rewrites the whole queue from the same fork point, and two at once would revert each other's edits, so those stay one agent per look [1]. This is the one place the daemon still reads and claims tickets; its own design is a follow-up.
 
 #### Business logic
 
 - The candidates are the tickets with neither a plan nor a claim, most important first (the daemon reads them off the `agent-data` branch [11]), minus the tickets pinned to planning agents still in flight and minus those whose planning agent already ended dry. A list that cannot be read means no candidates.
-- No candidates stands the project down with "every open ticket already has a plan, or an agent on the way to one", and the rotation advances: nothing left to plan is the routine's work being done, not a refusal, so the next sweep tries the next routine instead of re-asking forever. A "Run now" that named the routine advances nothing.
+- No candidates stands the project down with "every open ticket already has a plan, or an agent on the way to one", and the rotation advances: nothing left to plan is the routine's work being done, not a refusal, so the next turn tries the next routine instead of re-asking forever. A "Run now" that named the routine advances nothing.
 - The batch is the first candidates, as many as the cap has room for. Agent ids [20] are minted first, from the clock; then the claims are written as one batch and pushed, one `.lock.md` per ticket reading `CLAIMED: <agent id>`, so agents forked from any checkout, and cloud sessions in particular, find the file and skip the ticket. Only the tickets actually claimed get an agent: a ticket lost to a race costs one agent of the batch, not the batch. When nothing could be claimed, or the daemon has no way to claim, one unpinned stock agent runs, which is safe without a claim.
 - The pin is appended to the stock prompt rather than spliced into it, so the verdict rules the preset carries ride along verbatim and a rewritten preset cannot silently lose the pin: "You are one agent of a concurrent batch, so the scope above narrows: plan exactly one ticket, `tickets/<file>`, and no other." Then the claim contract: the ticket "is already claimed for you", `tickets show <file>` names the agent as its holder [21], the agent writes the plan with `tickets put <stem>.plan.md` and lifts its claim with `tickets release <file>`, because the plan is a write to the `agent-data` branch and not a pull request; a ticket not claimed, claimed by someone else, or already planned "is not yours — stop and do nothing". Nothing else releases the claim: a forgotten one stands until a human clicks it away.
 - The start is reported as 'planning "<ticket file>"'.
@@ -207,12 +223,12 @@ Before judging a project's queue, every agent this sweep started on it and has n
 #### Business logic
 
 - "Add quick-win work to AI Queue" holds `routines/triage-quick.lock.md` and "Add consensual work to AI Queue" holds `routines/triage-consensual.lock.md`, each a routine lock [10] on the `agent-data` branch, written and pushed before the agent [6] starts so every machine sharing the branch sees the routine as taken.
-- A lock that is alive, held by another machine's triage or by this one's still going, or that could not be written, stands the routine down with the lock's own reason and no agent started; when the taking itself fails, the reason is "the routine lock could not be taken". The rotation stays on that routine, so the next sweep [1] tries it again.
-- The lock is released when the agent ends, whatever the ending, with the bounded retries described under "Closing out what an earlier sweep started", and released at once when the daemon refused the start, since no agent will ever release it.
-- Locks a previous daemon on this machine left behind are released on a project's first sweep.
+- A lock that is alive, held by another machine's triage or by this one's still going, or that could not be written, stands the routine down with the lock's own reason and no agent started; when the taking itself fails, the reason is "the routine lock could not be taken". The rotation stays on that routine, so the next turn tries it again.
+- The lock is released when the agent ends, whatever the ending, with the bounded retries described under "Closing out what an earlier look started", and released at once when the daemon refused the start, since no agent will ever release it.
+- Locks a previous daemon on this machine left behind are released on a project's first look [1].
 - A daemon wired without the locking seam starts the routine unguarded.
 
-### Starting the batch, and stopping
+### Starting, and stopping
 
 #### Context
 
@@ -220,42 +236,43 @@ Before judging a project's queue, every agent this sweep started on it and has n
 
 #### Business logic
 
-- Stopping the sweep [1] is a verdict on the whole sweep: it is re-checked after every wait and before every spawn, and a stop mid-batch spawns none of the rest.
+- Stopping the sweep is a verdict on the whole look [1]: it is re-checked after every wait and before every spawn, and a stop mid-batch spawns none of the rest.
 - Each start is logged as "auto PM: <what it does> in <project path>", where "what it does" is the routine's description line when it has one, else its label, else its name.
 - The first start the daemon refuses ends the batch: whatever refused it is not going to take the next one a moment later, and a refused routine must be retried rather than skipped. It is logged as "auto PM: could not start a run in <project path>", and a routine lock [10] taken for it goes back at once.
 - After the batch, the claim of every item that never started is released: those never enter the closing-out step, so nothing else would free them.
 - When nothing started, the cooldown is given back and the project is recorded as "the daemon could not start a run", or as the lock's reason when a lock stood the routine down.
 - When something started, the project is recorded with what: a single start keeps its own sentence; several read "started <n> agents: <sentence>; <sentence>; …". Either is followed by " alongside <m> already going (<labels>)" when agents were already live, so a batch that came out short of the cap says what it was short by.
 
-### "Run now": a sweep a person asked for
+### "Run now": a look a person asked for
 
 #### Context
 
-**User story**: the user clicks "Run now" on a routine's [7] row, or on the drain [4] row, in the dashboard, with or without a project picked, and the sweep [1] runs for that at once. The same wake happens when the user switches Auto PM [3] on, so the box just ticked does not wait a whole interval to do anything.
+**User story**: the user clicks "Run now" on a routine's [7] row, or on the queued work's row, in the dashboard, with or without a project picked, and the look [1] runs for that at once. The same wake happens when the user switches Auto PM [3] on, so the box just ticked does not wait for the next look to do anything.
 
 #### Business logic
 
 - The Auto PM preference is consent to spend quota [2] unasked, and a click is asking: a "Run now" runs with the preference off. The preference is still read, so the report says where the box stood.
 - It skips the cooldown. The concurrency cap, the quota boundary [8] and the switched-off routines all still hold.
-- With a project picked, only that project is visited; a project id that matches nothing stands the sweep down rather than silently widening it to every project. Without one, every project the daemon watches is visited, which is what the drain row's button says it does.
-- A drain-only "Run now" works the queue or says why not: "the queue is empty, so there is nothing to drain", or "the queue has work waiting and its routine is switched off". It never borrows the click for a rotation routine the user did not ask for.
-- A planning "Run now" fires the fan-out [14] routine of the enabled rotation, through the same claim-then-start path the rotation takes, cap included; with it switched off the sweep stands down with "the planning routine is switched off".
+- With a project picked, only that project is visited; a project id that matches nothing stands the look down rather than silently widening it to every project. Without one, every project the daemon watches is visited, which is what the queued work's row says it does.
+- A plain "Run now" starts the queued work [4] when the branch moved [15], else the rotation's next routine: the click is the ask, so it does not wait for a run to have found nothing.
+- The queued work's "Run now" starts one agent on the queue in each project visited, whether or not the branch moved — a run that finds nothing queued spends one run finding that out, which is what the click asked for — or says why not: "the routine that works the queue is switched off".
+- A planning "Run now" fires the fan-out [14] routine of the enabled rotation, through the same claim-then-start path the rotation takes, cap included; with it switched off the look stands down with "the planning routine is switched off".
 - A triage "Run now" names the routine by the lock it holds, so the lock is taken before the start; a plain start outside the sweep would run unguarded. A lock no enabled routine holds is told apart: "<label> is switched off" when the routine exists but is unticked, and "no routine holds the <lock> lock" when nothing holds it, which is a dashboard older than its daemon.
-- A click that named a routine takes the turn outright: it is never a drain however full the queue is, never the maintenance sweep, and it moves neither the rotation's position nor the maintenance calendar, since it did not come from the cycle.
+- A click that named a routine takes the turn outright: it is never the queued work however much the branch moved, never the maintenance sweep, and it moves neither the rotation's position nor the maintenance calendar, since it did not come from the cycle.
 
-### What the last sweep reports
+### What the last look reports
 
 #### Context
 
-**Problem**: every decision is logged, but the log is the daemon's terminal and the toggle lives in a browser; from the dashboard a wedged sweep [1] and a healthy idle one would look identical.
+**Problem**: every decision is logged, but the log is the daemon's terminal and the toggle lives in a browser; from the dashboard a wedged look [1] and a healthy idle one would look identical. And with a look every minute, a log line per look would drown the daemon's output.
 
 #### Business logic
 
-- The dashboard is told whether the preference was on at the last sweep, when that sweep finished, when the next is due, and one line per project visited, in sweep order: the project's path, whether an agent [6] was started, and the sentence, which is exactly the sentence the daemon logged.
-- The next sweep's time is counted from the moment the sweep loop started, in whole intervals, so a "Run now" does not shift the schedule.
-- The last sweep is recorded even when it ended early, so "switched off" and "on, and standing down for a reason" are distinguishable. Before the first sweep, the report carries only the next due time and no outcomes.
+- The dashboard is told whether the preference was on at the last look, when that look finished, when the next is due, and one line per project visited, in look order: the project's path, whether an agent [6] was started, and the sentence. A start's sentence is exactly the sentence the daemon logged; a stand-down's is logged only the first time it is said for the project, until the sentence changes.
+- The next look's time is counted from the moment the loop started, in whole intervals of one minute, so a "Run now" does not shift the schedule.
+- The last look is recorded even when it ended early, so "switched off" and "on, and standing down for a reason" are distinguishable. Before the first look, the report carries only the next due time and no outcomes.
 
-### The routines are built from the presets
+### The routines
 
 #### Context
 
@@ -263,7 +280,8 @@ Before judging a project's queue, every agent this sweep started on it and has n
 
 #### Business logic
 
-- Each routine carries the preset's stable name, which is what the rotation's position and the switched-off list key on; the prompt rendered from the preset; and the preset's label and one-line tooltip, read off the preset so a relabeled preset relabels its routine and the sentence the launcher shows for a preset is the sentence the routines list shows for its routine.
+- The queued work [4] is the routine skill [22] `work-queue`: its name is the skill's, its prompt is the slash command `/work-queue`, its label "Work the queue" and its tooltip "Work one queued task off the agent queue, unattended." are written here, and it is declared as working the queue and as auto-merging its pull request. The skill file itself is `skills/work-queue/SKILL.md` in this package.
+- Each preset-backed routine carries the preset's stable name, which is what the rotation's position and the switched-off list key on; the prompt rendered from the preset; and the preset's label and one-line tooltip, read off the preset so a relabeled preset relabels its routine and the sentence the launcher shows for a preset and the sentence the routines list shows for its routine are the same sentence.
 - Only the maintenance routine carries a separate description line, "sweeping the codebase for maintenance work", because "Maintenance" names its preset rather than the work; the other routines' labels read as what they do, so their rows stay one line and their log lines say the label itself.
-- The drain [4] routine is the "Spin up agents working on the AI queue" preset (`drain-queue`), declared as draining and as auto-merging its pull request. The planning routine is declared as fanning out [14]; the triage routines each declare their routine lock [10].
-- The routines list, in the order a surface shows them, is derived from the same routines the daemon runs: the drain first, because it is what happens whenever there is queued work; the four rotation routines next, because they are what happens when there is not; the maintenance sweep last, as the calendar-paced exception outside both.
+- The planning routine is declared as fanning out [14]; the triage routines each declare their routine lock [10].
+- The routines list, in the order a surface shows them, is derived from the same routines the daemon runs: the queued work first, because it is what happens whenever the branch moved; the four rotation routines next, because they are what happens when a run found nothing; the maintenance sweep last, as the calendar-paced exception outside both.
diff --git a/packages/framework/src/auto-pm.test.LOGIC.md b/packages/framework/src/auto-pm.test.LOGIC.md
index 6637d9f7e..d4d85d87d 100644
--- a/packages/framework/src/auto-pm.test.LOGIC.md
+++ b/packages/framework/src/auto-pm.test.LOGIC.md
@@ -1,94 +1,71 @@
-What the tests cover, for the Auto PM sweep's policy and loop:
+What the tests cover, for the Auto PM sweep's policy and loop. The loop is driven against a fake `agent-data` branch whose commits are either moves (a person's or an agent's) or a daemon's, and a fake start that records what was started.
 
 **Whether a start is allowed**
 
-- **The happy case** - a dry agent queue and a barely touched quota week start an agent in product management mode.
+- **The happy case** - a barely touched quota week allows a start.
 - **The preference** - with Auto PM off nothing starts, from the decision and from the loop alike.
 - **The concurrency cap** - a project at its cap is left alone with a reason that says "already going"; below the cap it is topped up rather than refused; at a cap above one the refusal names the cap ("at most 2 at once"); an unset cap means the shipped default of 2, and a cap of zero is floored at one so a hand-edited nought cannot wedge the sweep.
-- **Drain before refill** - a queue with open entries starts a drain rather than refusing; a queue that cannot be read refuses with "queue could not be read" instead of counting as empty or as full.
 - **The cooldown** - a start one minute ago holds the project off, an hour ago does not; a "Run now" passes through the cooldown but still stops at the cap.
 
 **The quota boundary**
 
-- **Fails closed** - a quota that cannot be read refuses to start ("could not be read"), the opposite of the per-agent guard that never stops the user's own work.
-- **Under and at the line** - under the boundary the start is allowed; at the boundary exactly, not only past it, it stands down.
-- **Naming where it stands** - the refusal names the window and the line ("99% used, at or past day 3 of the week's 32%"), and with the default half-day spend offset the limit reads to one decimal ("your 39% limit (+7.1 on the week's 32%)"), never fifteen digits.
-- **A restarted daemon is not blind** - the reading is the account's absolute week, so a daemon that just started still stands down on a week at 95%.
-
-**The sweep loop**
-
-- **One start per idle project** - an idle project gets an agent; a second sweep inside the cooldown starts nothing more; a refused start gives the cooldown back so the next sweep tries again.
-- **"Run now"** - an on-demand sweep runs with the preference off and the report still says the box was off; it skips the cooldown, so a click right after a start starts again; every other stand-down, the cap included, still holds.
-- **Unreadable readings** - a queue that cannot be read starts nothing and does not break the sweep; an unreadable switched-off list means no routine is off; an unreadable concurrency falls back to the default of 2, never to one.
-- **Stopping** - a daemon stopping while a sweep sits between its readings and the spawn starts nothing, on any project of that sweep; a stopped sweep never runs again.
-
-**The routine rotation**
-
-- **Its order** - update tickets, triage the quick wins, triage the consensual work, then plan; both triage routines are in it; the gated "Suggest tickets to work on" preset is not, and no routine's prompt contains a gate.
-- **Walking the cycle** - successive idle sweeps fire the routines in turn and wrap around; a refused start retries the same routine instead of skipping it; a routine the user unticked is filtered out so the remaining ones alternate every turn; with every routine off nothing starts and the reason is "every routine that makes new work is switched off".
-- **One agent per turn** - a rotation routine starts one agent however high the concurrency.
-- **Nothing left to plan** - a planning turn with no candidate advances the rotation, reports "already has a plan", and the next sweep fires the next routine.
-
-**Drain and refill**
-
-- **The cycle comes back round** - a standing entry is drained, an empty queue is refilled, a new entry is drained again; draining never advances the rotation, so a queue worked off over several sweeps resumes the rotation where it was.
-- **Closing out finished agents** - an agent whose queue landed ends that sweep so the next one re-reads the queue; a finished agent that wrote nothing is asked about exactly once and then dropped; an agent still going stays tracked.
-- **A switched-off drain routine** - the scheduled sweep falls through to the rotation and works nothing off the queue; a drain-only "Run now" stands down instead with "the queue has work waiting and its routine is switched off".
+- **Unreadable refuses** - no quota reading at all refuses with "could not be read".
+- **Under, at and past the line** - under the boundary starts; at 99% used with a third of the week gone the refusal names the window, the day and the line ("99% used, at or past day 3 of the week's 32%"); meeting the boundary exactly refuses too; a fractional spend offset is said to one decimal ("+7.1"), never as fifteen digits.
+- **A restarted daemon is not blind** - the reading is the account's absolute figure, so a fresh daemon refuses at 95% used.
+
+**The trigger and the chain**
+
+- **The first look** - remembers the head and starts nothing on the queued work; with no rotation wired it says "there is no job to run"; with one, the rotation gets its start-up turn.
+- **A move starts the queued work once** - a commit no daemon wrote starts one `/work-queue` agent; the next look, with the run settled and nothing new, starts nothing.
+- **A daemon's commit is not a move** - commits carrying the daemon's trailer start nothing, however many.
+- **The chain** - three tasks under a cap of one: the first run's claim moves the branch but the cap holds; the run ends having closed its ticket, and the next run starts; and so on for three; the fourth finds nothing, moves nothing, and once it settles the chain stops.
+- **After an empty run the rotation** - a run that settles without a move hands the turn to the rotation; a move takes it back; a rotation run that moved nothing hands the turn to the next routine.
+- **Only the rotation is paced** - a move starts the queued work a minute after a rotation start; the rotation's next turn waits out the cooldown.
+- **The heartbeat** - with nothing moved, the queued work starts once the heartbeat interval has passed since it last started, and not before the next one.
+- **The queued work's "Run now"** - starts an agent on the queue without a move; with the routine switched off it says "the routine that works the queue is switched off".
+- **A plain "Run now"** - starts the queued work when the branch moved, else the rotation's next routine.
+- **The routine off, a move** - is the rotation's turn, and nothing works the queue.
+- **An unreadable branch** - stands the project down naming the branch.
+- **The log says a stand-down once** - the same stand-down over three looks is one log line; the report carries it every time.
+- **The queued-work routine** - its prompt is the slash command of the `work-queue` skill file, which names itself, is invocable only by a person or the daemon, and tells the agent one task, commit without pushing, committed counts as published, say so and stop; it is the only routine that works the queue and the only one that auto-merges.
+
+**The rotation**
+
+- **The order** - update tickets, triage quick, triage consensual, plan tickets; the gated "Suggest tickets to work on" is never in it and no routine's prompt contains a gate.
+- **Walking the cycle** - with the cooldown zeroed, successive empty runs walk first, second, first; a refused start retries the same routine rather than skipping it.
+- **A finished run is asked about once** - each run this loop started is settled exactly once; a run still going holds the rotation's turn and the sweep reports "nothing moved".
+- **Switched-off routines** - an unticked routine is filtered out of the cycle so the rest alternate; unticking every routine starts nothing and says "every routine that makes new work is switched off"; an unreadable opt-out list means none is off.
 
 **The maintenance sweep**
 
-- **Its prompt** - the maintenance routine fires the "Maintenance" preset over the entire codebase, fully rendered.
-- **Its precedence** - a project that is due is swept before the rotation gets a turn; one that is not due, or whose schedule cannot be read, keeps doing the rotation; a queue with work is drained rather than swept, also when the drain routine is off and the turn fell through to the rotation.
-- **Its calendar** - a sweep does not cost the rotation its turn; the project is stamped only when the start took; a switched-off maintenance routine leaves its calendar untouched.
-
-**The report**
+- **The job** - fires the [Maintenance] preset over the entire codebase, fully rendered.
+- **Its precedence** - a project that is due is swept before the rotation gets a turn; one that is not due, or whose schedule cannot be read, keeps doing the rotation; a move is worked, never swept; with the queued-work routine off, a move is a rotation turn and the sweep is not due again.
+- **Its calendar** - the sweep does not advance the rotation; it is stamped only when the start took; an unticked maintenance routine leaves its calendar alone.
 
-- **What it says** - after a sweep: whether the preference was on, when it ran, and per project the path, whether an agent started and the sentence ("doing the first thing"); a stand-down carries its reason; a sweep with the preference off reports it off with no per-project line.
-- **The next sweep** - before the first sweep the report carries no sweep time and no preference, only the next due time one interval after the loop started; an out-of-band sweep does not shift it.
+**Stopping and reporting**
 
-**The catalog of routines**
+- **A stop mid-sweep** - a sweep stopped between its readings and the spawn starts nothing, on any project; a stopped sweep does not tick again.
+- **The report** - names what was started, carries the reason for a stand-down ("already going"), says when the preference was off with no outcomes, offers a next sweep before the first has run, and is not skewed by an out-of-band tick.
+- **The routines list** - the queued work, the four rotation routines and maintenance, once each, the queued work first; every routine carries a label and a fully rendered prompt; only "Maintenance" describes itself.
 
-- **What each routine declares** - only the drain routine says it drains; only the drain routine auto-merges its pull request; only "Plan tickets" fans out; the two triage routines hold a routine lock named after them and their prompts no longer abort on an existing branch.
-- **The routines list** - it is the drain, the four rotation routines and maintenance, once each, drain first; every routine carries its preset's label and a fully rendered prompt; only maintenance carries a description line ("sweeping the codebase for maintenance work"), the others are their label.
+**Naming what holds a slot**
 
-**Draining fans out**
+- **The cap's wording** - names each run holding a slot ("2 runs are already going (run-a (pid 111), run-b (pid 222)), and the routine keeps at most 2 at once"); at a cap of one the old wording stands.
+- **A short fan-out** - a plan batch that came out short says alongside whom ("started 2 agents alongside 1 already going (…): planning "a.md"; planning "b.md"").
 
-- **One entry per agent** - a standing queue fans out to the cap in one sweep, each agent pinned to a different entry in queue order, and stops at the cap rather than at the queue's length.
-- **Slots are named** - at the cap the reason is exactly "2 runs are already going (run-a (pid 111), run-b (pid 222)), and the routine keeps at most 2 at once", and with nothing to name and a cap of one, "1 run is already going"; a batch that came out short reports "started 2 agents alongside 1 already going (<label>): draining the queue entry "entry a"; draining the queue entry "entry b"".
-- **No double hand-out** - an entry pinned to an agent still in flight is not handed out again; a queue whose every entry is being worked stands down with "every open queue entry is already being worked on"; agents already live count against the cap so the sweep tops up rather than doubles; the first refused start ends the batch so the refused work is retried.
-- **Drain-only "Run now"** - with entries waiting it fans out like any drain; with an empty queue it says "the queue is empty, so there is nothing to drain" instead of firing a rotation routine.
-
-**Claims on drained tickets**
+**Planning fans out**
 
-- **Claimed before the start** - a batch's ticket-linked entries are claimed in one call before any agent starts, each prompt names the ticket "already claimed for you", and the agent ids are minted a millisecond apart from the sweep's clock so a batch stays distinct.
-- **Ticketless entries** - an entry with no ticket link is not offered to the claim and drains without one; without the claim seam a ticket-linked entry drains exactly as before, with no claim in its prompt.
-- **A lost race** - an entry whose ticket was claimed elsewhere is dropped from the batch, not the batch; a batch that lost every claim stands down with "every entry in this batch links a ticket another agent already claimed".
-- **The pinned drain prompt** - with a claim it says the ticket is claimed for the agent, that `tickets show` names it as holder, that it must run `tickets close` once published, and that a ticket claimed by someone else "is not yours"; without a claim the prompt is the plain pin.
+- **One locked ticket per agent** - up to the concurrency, in most-important-first order, locked in one batch before any start, each agent's prompt naming the ticket claimed for it; only the tickets the lock actually claimed go out; nothing claimed falls back to one unpinned agent; without the lock seam the job stays one per tick; a ticket a live plan run is pinned to is not offered again; nothing left to plan advances the rotation; an unreadable concurrency falls back to the default; a refused start ends the batch.
+- **The pinned plan prompt** - appended to the preset's text, so its rules ride along verbatim: one ticket, `tickets show` names the holder, `tickets put` the plan, `tickets release` the claim.
+- **Only "Plan tickets" fans out** - among the catalog's rotation routines; every other routine stays one run per tick however high the cap.
+- **Plan "Run now"** - fans out to the concurrency in the picked project only, never works the queue however much the branch moved, stands down when planning is switched off, and costs neither the maintenance sweep nor the rotation its turn.
 
 **Dead claims**
 
-- **Freed on a commitless ending** - the exact claim minted for an agent that ended with nothing to hand off is released; a sweep that catches the gap between the agent's end and its handoff report holds the claim and releases it once the ending lands; the hold is bounded to two sweeps, after which the agent is closed out unread.
-- **Not drained again** - an entry whose drain ended dry is not offered again for the daemon's lifetime, and the stand-down says "drained once with nothing to hand off".
-- **Never-started items** - the claims of a batch's items the start loop never reached are released rather than stranded.
-- **Retried releases** - a release that could not land is retried on the next sweep, once more, and then left.
-- **Every other ending** - an agent that published, or whose handoff skipped because its pull request already exists, keeps its claim for its own pull request to lift.
-
-**Planning fans out**
-
-- **One claimed ticket per agent** - the planning routine fans out to the cap, one agent per candidate in most-important-first order, the whole batch claimed in one call before any start, each prompt naming the holder; only the tickets actually claimed go out; a claim that took nothing falls back to one unpinned agent with the stock prompt; without the claim seam the routine stays one agent per sweep however high the cap.
-- **No double hand-out** - a ticket pinned to a planning agent still in flight is not offered again.
-- **The pinned plan prompt** - the pin is appended after the stock prompt, names "exactly one ticket", says `tickets show` names the agent as holder, and tells it to write the plan with `tickets put` and lift the claim with `tickets release`.
-- **Plan-only "Run now"** - it spends the whole cap rather than one agent; it plans instead of draining however full the queue is; it stands down with "the planning routine is switched off" when the routine is unticked; it visits only the project the card picked; it costs neither the maintenance sweep nor the rotation its turn.
+- **Released when the run ended dry** - a claim whose run settled with nothing to hand off is released, exactly the minted claim; the end-before-handoff gap holds the claim for at most two more sweeps, then settles unread; a ticket whose plan agent ended dry is not planned again for the daemon's lifetime; claims of a batch the start loop never reached are released; a release that could not land is retried once; a run that published, or whose pull request was already open, leaves its lock alone.
 
 **Routine locks**
 
-- **Taken and released** - a locked routine takes its lock before the start; while its agent runs the next sweep stands down with the lock's own sentence naming the holder ("triage-quick is already running on laptop (since T0)"); when the agent ends the lock is released, whatever the ending, and the routine may run again in the same sweep.
-- **A held lock** - a lock another machine holds stands the routine down naming that holder, with no agent started.
-- **Given back and retried** - a refused start gives the lock back at once; a release that could not land keeps the lock standing and is retried on the next sweep.
-- **Unlocked routines and unwired loops** - a routine without a lock never asks for one; a loop wired without the locking seam starts a locked routine unguarded; a previous daemon's dead locks are released on a project's first sweep only.
-
-**"Run now" on a locked routine**
-
-- **Lock, then one agent** - the click takes the lock and starts exactly one agent, whatever turn the rotation is on and however much room the cap has.
-- **Told apart** - a switched-off locked routine stands the click down with "<label> is switched off"; a lock nothing holds with "no routine holds the <lock> lock"; the cap holds the click as it holds the sweep.
-- **Never borrowed** - a full queue does not turn the click into a drain and the rotation's turn does not take it; the scheduled sweep after it still gets the rotation routine it was owed.
+- **Taken before, released after** - a locked routine takes its lock before it starts and releases it when the run ends, whatever the ending, and may be taken again at once; a held lock stands the routine down naming its holder with no agent started; a refused start gives the lock back; a failed release is retried next sweep and the routine waits meanwhile; an unlocked routine never asks, and a loop wired without the seam starts unguarded; a previous daemon's dead locks are released on the project's first sweep only.
+- **A locked routine's "Run now"** - takes the lock then starts exactly one agent; a switched-off locked routine stands the click down by its label, an unknown lock says "no routine holds the <lock> lock", and a live agent at the cap holds the click; a click never falls through to the queued work or another rotation routine, and the next scheduled sweep still gets the move it was owed.
+- **Which routines lock** - the two triage routines, each by its own name, and their prompts carry no branch abort.
diff --git a/packages/framework/src/await-gate.LOGIC.md b/packages/framework/src/await-gate.LOGIC.md
index 357ee4df1..40e9c0d37 100644
--- a/packages/framework/src/await-gate.LOGIC.md
+++ b/packages/framework/src/await-gate.LOGIC.md
@@ -4,7 +4,7 @@ Runs the exchange in which an agent [1] stops to ask: a turn [2] whose final mes
 
 **User story**: an agent working the user's task reaches a decision it will not take alone and asks, with options; the dashboard shows the question as a card with the recommended option pre-selected. The user picks, and the agent continues with that decision. The user may pick an option the agent marked as a stop, which ends the agent at that turn. When the user is not there, the recommended option is taken and the agent goes on. Once the agent's work has settled, the user writes to it from the composer and each message continues the same conversation.
 
-**Business logic story**: one loop serves every path that runs gates: the opening exchange of a build agent [8] and of a prompt agent [8], each live-chat message, and the backlog loop [9]. The paths differ only in how a turn is continued. The syntax of a gate in a final message and the wording of the continuation are fixed in `turn-gate.ts`; the queue of live-chat messages in `agent-messages.ts`.
+**Business logic story**: one loop serves every path that runs gates: the opening exchange of a build agent [8] and of a prompt agent [8], each live-chat message.
 
 ## Glossary
 
@@ -16,7 +16,6 @@ Runs the exchange in which an agent [1] stops to ask: a turn [2] whose final mes
 [6] live chat: the user's own messages to a running agent, each continuing the same driver session. One of them is a message.
 [7] driver session: the coding agent's own conversation for one agent, which the driver can resume by its session id.
 [8] build agent / prompt agent: the two kinds of agent: a build works the agent queue after its opening exchange; a prompt agent runs one prompt and stops there.
-[9] backlog loop: after a build agent's opening work settles, the loop that works the agent queue one entry per turn until it is empty.
 [10] event stream: everything an agent does, one event per line appended to `.the-framework/events.jsonl` in its checkout; every surface (dashboard, terminal, archive, run) is a projection of it.
 [11] turn signals: what The Framework reads off a turn's final message: the ready-for-merge signal, the pull request title and body, markdown views, reported errors, and the gate it stops at.
 [12] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
diff --git a/packages/framework/src/cli.LOGIC.md b/packages/framework/src/cli.LOGIC.md
index 80b4e3d83..0d505261b 100644
--- a/packages/framework/src/cli.LOGIC.md
+++ b/packages/framework/src/cli.LOGIC.md
@@ -21,7 +21,7 @@ Implements the `the-framework` command: four options and no verbs, where the bar
 [9] location: where an agent's turns run: `local` (this machine), `actions` (a GitHub Actions runner), or `web` (a Claude Code cloud session).
 [10] on-before-mergeable follow-up: the built-in prompt `prompts/on_before_mergeable_prompt.md`, run as a separate prompt agent on the finished agent's checkout once the agent has signaled ready for merge: it queues quality follow-ups for the work on the agent queue and folds what the work taught into the project's knowledge documents.
 [11] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it). "Handoff level" is a rung of that ladder.
-[12] backlog loop: after a build agent's opening work settles, the loop that works the agent queue one entry per turn until it is empty.
+[12] the queued work: the routine the daemon starts on the agent queue when the `agent-data` branch moves; its agent reads the queue itself.
 [13] coding agent: the CLI doing the actual work: Claude Code or Codex.
 [14] daemon token: the shared secret that authenticates a dashboard exposed to the network: generated once for a daemon bound to a non-loopback address, kept in `~/.the-framework.json`, carried by the URL the terminal prints, and required on every request.
 [15] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
@@ -41,7 +41,7 @@ Implements the `the-framework` command: four options and no verbs, where the bar
 [29] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
 [30] settled: said of an agent whose work has stopped and which is waiting for the user: it is alive, takes messages, and does nothing until told.
 [31] ready for merge: the signal an agent emits when it believes its work is complete: it flips the agent's badge from building to ready and authorizes the handoff.
-[32] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
+[32] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command run as `npx <skill>`, and an API the product calls.
 [33] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 [34] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 [35] the bridge: the daemon's bridge endpoints plus the Chrome extension: carries the question a cloud session is parked on into the dashboard, and types the pick back into the session.
@@ -70,14 +70,14 @@ Implements the `the-framework` command: four options and no verbs, where the bar
 - **Ctrl+C and SIGTERM** - the first signal stops the agent through its driver so no coding agent is orphaned; the second force-quits with exit code 130.
 - **The journal** - every event goes to the terminal and the store, and the journal remembers what the epilogue needs: the ready-for-merge signal, the pull request text the agent wrote, the branch, and whether the agent was stopped.
 - **The branch is observed, never assumed** - the checkout's branch is read at start, after every turn and before the epilogue; only a change is recorded, and the session name is read off it.
-- **What the agent's record learns at start** - the armed handoff as three stages, the ticket the agent implements, and the branch it starts on are emitted before the first turn.
+- **What the agent's record learns at start** - the armed handoff as three stages and the branch it starts on are emitted before the first turn.
 - **The browser** - a local Claude Code agent asked for a browser gets one Chrome shared with the dashboard's preview, and every other agent is told why it gets none.
 - **The driver for the location** - an `actions` agent needs a GitHub origin remote and a user token; a `web` agent is handed to the bridge through the daemon that spawned it; a fake agent gets the offline driver.
 - **Giving up before a driver exists** - a configuration fault after the store opened is recorded as a failed end, every handle is released, and the exit code is 2.
-- **The flow the agent opens with** - research renders the Research preset around the text, a prompt agent runs its text verbatim, a build agent frames it and works the backlog; transparent forces the prompt path and no backlog loop.
+- **The flow the agent opens with** - research renders the Research preset around the text, a prompt agent runs its text verbatim, a build agent frames it; transparent forces the prompt path.
 - **How the agent ends** - a success line, then the branch read, the follow-up, the handoff and the archive, exit 0; a stop prints "■ Stopped." and exits 0; a failure prints why and exits 1; the handles are released either way.
 - **The on-before-mergeable follow-up** - after a ready-for-merge signal, one vanilla prompt agent is spawned on the same checkout to queue the quality follow-ups, never from a test entry and never recursively, and every reason for skipping it is an event.
-- **The handoff** - at the armed level, only what the agent committed is published, a merge is withheld without the agent's authorization or with open entries in its own TODO file, a plan agent's pull request text is defused, and every outcome is an event and a terminal line.
+- **The handoff** - at the armed level, only what the agent committed is published, a merge is withheld without the agent's authorization, a plan agent's pull request text is defused, and every outcome is an event and a terminal line.
 
 ## Business logic
 
@@ -139,7 +139,7 @@ After the running lines the terminal prints "Type a prompt on the dashboard to s
 
 #### Business logic
 
-`--agent <path>` reads and consumes the spec; a path that cannot be read as a spec ends the process with "could not read the session spec (<reason>)." and exit code 2. The agent [1]'s options are read off the spec with these defaults: driver [8] `claude`, no in-context directories, the on-before-mergeable follow-up [10] off, no browser, the backlog loop [12] on, persistence on. From the spec itself: the prompt becomes the agent's intent; the kind is build, prompt or research; the checkout [15] to run in; the agent id [16] when the daemon minted one; whether this process continues an existing agent; the driver, kept only when it names a known driver; the location [9], kept only when it is one of the three; the model and the driver session [17] id to resume, trimmed and kept only when non-blank; the ticket [18] the agent implements, kept only when it is a ticket path, because it comes off the agent queue [19], a file an agent wrote, and is re-checked rather than trusted; whether the agent is a plan agent [20]; whether it is unattended [21]; vanilla [22] and transparent [23] as three-state values, where absent means "the spec said nothing" and the repo file [3] decides; the handoff [11] level, kept only when it names a rung; and the follow-up and browser switches. Setting `FRAMEWORK_FAKE=1` in the environment makes the agent a fake one, run by the offline demo driver of `fake-script.ts`, whatever the spec says; a fake agent with no prompt runs the demo's own intent.
+`--agent <path>` reads and consumes the spec; a path that cannot be read as a spec ends the process with "could not read the session spec (<reason>)." and exit code 2. The agent [1]'s options are read off the spec with these defaults: driver [8] `claude`, no in-context directories, the on-before-mergeable follow-up [10] off, no browser, persistence on. From the spec itself: the prompt becomes the agent's intent; the kind is build, prompt or research; the checkout [15] to run in; the agent id [16] when the daemon minted one; whether this process continues an existing agent; the driver, kept only when it names a known driver; the location [9], kept only when it is one of the three; the model and the driver session [17] id to resume, trimmed and kept only when non-blank; the ticket [18] the agent implements, kept only when it is a ticket path, because it comes off the agent queue [19], a file an agent wrote, and is re-checked rather than trusted; whether the agent is a plan agent [20]; whether it is unattended [21]; vanilla [22] and transparent [23] as three-state values, where absent means "the spec said nothing" and the repo file [3] decides; the handoff [11] level, kept only when it names a rung; and the follow-up and browser switches. Setting `FRAMEWORK_FAKE=1` in the environment makes the agent a fake one, run by the offline demo driver of `fake-script.ts`, whatever the spec says; a fake agent with no prompt runs the demo's own intent.
 
 ### What is refused before anything is spent
 
@@ -220,7 +220,7 @@ An agent is steerable when it has an agent id [16] and persistence is on, which
 - A stop entry aborts the agent.
 - A message entry queues the text for live chat [7].
 - A handoff entry moves the armed handoff level to the level given and re-announces the armed state as an event, so the agent's record stays true for a tab opened mid-way. The checkboxes are pre-commitments: they may move the level at any moment up to the end of the agent.
-- A merge entry arms the full ladder, records that a human authorized the merge, announces the armed state, and answers any parked gate that is the backlog loop [12]'s offer of more work with a stop pick [28] by the user, so the agent wraps up now. Other parked gates keep waiting: they are questions about the work itself, which merging does not answer. The agent still ends at its own natural end; the merge fires there.
+- A merge entry arms the full ladder, records that a human authorized the merge, and announces the armed state. Parked gates keep waiting: they are questions about the work itself, which merging does not answer. The agent still ends at its own natural end; the merge fires there.
 - A pick entry answers the parked gate with that id, recording who picked.
 
 When the control file cannot be reset or tailed, "control channel unavailable (<reason>); daemon steering disabled" is printed and the agent runs unsteered.
@@ -279,11 +279,11 @@ The checkout [15]'s current branch is read at start, at the end of every turn [2
 
 #### Context
 
-**Problem**: the control file [5] carries instructions, but only an event reaches the agent's record, and the record is the only thing a dashboard tab opened mid-way can read the checkboxes, the ticket and the branch back from.
+**Problem**: the control file [5] carries instructions, but only an event reaches the agent's record, and the record is the only thing a dashboard tab opened mid-way can read the checkboxes and the branch back from.
 
 #### Business logic
 
-Before the first turn [26], three facts are emitted: the armed handoff [11], spelled out as its three stages (push, pull request, merge) derived from the rung so no two surfaces can disagree; the ticket [18] the agent implements, once, because it is a fact about why the agent exists and it lets the Overview mark that ticket as being worked; and the branch the agent actually starts on, read rather than guessed.
+Before the first turn [26], two facts are emitted: the armed handoff [11], spelled out as its three stages (push, pull request, merge) derived from the rung so no two surfaces can disagree; and the branch the agent actually starts on, read rather than guessed. Which ticket the agent works is the agent's own doing, not The Framework's to know.
 
 ### The browser
 
@@ -328,7 +328,7 @@ A configuration fault found after the store opened but before a driver [8] exist
 
 #### Business logic
 
-A research agent's opening prompt is the Research preset rendered around the text given; a prompt agent [24] runs its text verbatim, since it may already be an edited preset that must not be re-rendered; a build agent [24] is framed by `agent.ts` and works the backlog loop [12] afterwards. A transparent [23] agent takes the prompt path whatever its kind, and its backlog loop is off; a build continuation stays a build. The agent [1] also receives: the location [9]; whether The Framework owns the checkout [15], true for an agent with an agent id [16] that runs locally, the one case where the daemon's PATH with the `branches` command is present; the driver session [17] id to resume, when continuing; the model when one was chosen; `SYSTEM.md` from the checkout as the project's own instructions; whether the built-in system prompt [27] is left out, which vanilla [22] and transparent both do; whether a browser is really attached; the in-context directories; and the session link to show in the dashboard, which is Claude Code's generic entry point, shown as "Open Claude Code", for a live Claude Code agent and nothing for a Codex or a fake agent, because Codex keeps its sessions locally with nothing equivalent to open.
+A research agent's opening prompt is the Research preset rendered around the text given; a prompt agent [24] runs its text verbatim, since it may already be an edited preset that must not be re-rendered; a build agent [24] is framed by `agent.ts`. A transparent [23] agent takes the prompt path whatever its kind; a build continuation stays a build. The agent [1] also receives: the location [9]; whether The Framework owns the checkout [15], true for an agent with an agent id [16] that runs locally, the one case where the daemon's PATH with the `branches` command is present; the driver session [17] id to resume, when continuing; the model when one was chosen; `SYSTEM.md` from the checkout as the project's own instructions; whether the built-in system prompt [27] is left out, which vanilla [22] and transparent both do; whether a browser is really attached; the in-context directories; and the session link to show in the dashboard, which is Claude Code's generic entry point, shown as "Open Claude Code", for a live Claude Code agent and nothing for a Codex or a fake agent, because Codex keeps its sessions locally with nothing equivalent to open.
 
 ### How the agent ends
 
@@ -362,8 +362,8 @@ The follow-up [10] runs only when the option was on. When it was, every reason f
 
 The handoff [11] runs at the armed level: the resolved configuration's level, moved since by handoff and merge entries on the control file [5]. Nothing is published, and the skip is an event with its reason, when the level does not include a push, when the agent was stopped [29], or when the agent is fake. The Framework commits nothing on the agent's behalf: what is published is what the agent committed, and uncommitted work stays in the checkout [15].
 
-An armed merge must also be authorized. Unless a human pressed Merge, the merge is withheld when the agent never signaled ready for merge [31], or when the agent's own TODO file, `TODO_<session name>.agent.md` in the checkout, still has open entries (the read is `todo-loop.ts`'s); the agent queue [19] never withholds a merge, because it is decoupled from agents. A withheld merge is not a skipped handoff: the push and the pull request go ahead, the pull request opens as a draft for a human, and the event carries the reason, which the terminal words as "the session never signalled ready-for-merge" or "the session's own TODO file still has open entries".
+An armed merge must also be authorized. Unless a human pressed Merge, the merge is withheld when the agent never signaled ready for merge [31]; the agent's word is enough, and no file of the agent's is read beside it. A withheld merge is not a skipped handoff: the push and the pull request go ahead, the pull request opens as a draft for a human, and the event carries the reason, which the terminal words as "the session never signalled ready-for-merge".
 
-The branch published is the branch as observed now, after any rename by the agent; a checkout on no branch skips with the reason `branch-gone`. The pull request text is what the agent wrote in its final message, when it did: its title and description, so the agent has no reason to open a pull request itself. When the agent implements a ticket [18] that tracks a GitHub issue, the issue reference rides the title as "(fix #N)", read off the ticket on the `agent-data` branch [38], so the squash-merge subject closes the issue; not on a plan agent [20], whose merge must not close it. For a plan agent both the title and the description are also defused (`closing-keywords.ts`), so no closing phrase in its prose closes the issue either. The push, the pull request and the merge themselves, and the further reasons to skip (no commits, no remote, a pull request already open, work already landed, branch already pushed), are `dashboard/agent-handoff.ts`'s; a pull request opens as a draft unless the merge is armed and authorized.
+The branch published is the branch as observed now, after any rename by the agent; a checkout on no branch skips with the reason `branch-gone`. The pull request text is what the agent wrote in its final message, when it did: its title and description, so the agent has no reason to open a pull request itself. Which ticket [18] the agent implemented, and so which GitHub issue its title should close, is the agent's own to say in its title; The Framework reads no ticket for it. For a plan agent both the title and the description are also defused (`closing-keywords.ts`), so no closing phrase in its prose closes the issue either. The push, the pull request and the merge themselves, and the further reasons to skip (no commits, no remote, a pull request already open, work already landed, branch already pushed), are `dashboard/agent-handoff.ts`'s; a pull request opens as a draft unless the merge is armed and authorized.
 
 Every outcome is emitted as a handoff event, and a pull request that was opened is recorded as its own event with its number and URL, so every later surface reads the number off the agent. The terminal says "◆ Opened <url>", "◆ Pushed <branch>.", or "✗ could not open the PR: <error>" / "✗ could not push the branch: <error>". The merge half rides on the outcome rather than failing it: "◆ Auto-merge armed: the PR lands when its checks pass." when GitHub's own auto-merge took it, "◆ Merge on green: the daemon merges the PR when its checks pass." when the CI watch [39] took it, "◆ Merged the PR." when it was merged directly, "◆ Merge withheld: <reason>." as above, or "✗ could not merge the PR: <error>", after which the pull request still exists for a human to merge by hand.
diff --git a/packages/framework/src/cli.test.LOGIC.md b/packages/framework/src/cli.test.LOGIC.md
index fd705d227..1ab0b3ad2 100644
--- a/packages/framework/src/cli.test.LOGIC.md
+++ b/packages/framework/src/cli.test.LOGIC.md
@@ -2,7 +2,7 @@ What the tests cover, mostly by running whole agents offline through the fake dr
 
 - **Four options and no verbs** - `--help`, `-v`, `--port` (with `0` accepted), `--host` and `--agent` parse; an unknown option and a bare word are usage errors ("unknown option", "unknown command"); a non-numeric, negative or missing `--port` value, and a missing `--host` or `--agent` value, are errors naming the option; every retired settings flag (`--scope`, `--max-passes`, `--max-cost`, `--permission-mode`, `--driver`, `--run-on`, `--autopilot`) and every retired verb or flag (`--daemon`, `--daemon-serve`, `stop`, `doctor`, `maintain`, `worktrees`, `prompt hi`) exits with code 2; `--help` prints the usage and exits 0; a bogus option exits 2; `--version` prints exactly the package's version and exits 0.
 - **The version** - the reported version is the package's real one, never the `unknown` placeholder for a failed read.
-- **Reading an agent's options off its spec** - the prompt, checkout, agent id, continuation flag and kind (research, verbatim prompt, build) round-trip; the backlog loop is on and unattended is off unless the spec says otherwise; in-context directories travel as a list; the on-before-mergeable follow-up and the browser are opt-in; the handoff level is unset unless given, a valid rung is kept and a made-up one dropped; a driver session id to resume is trimmed and a blank one dropped; the ticket is kept only when it is a ticket path, so a traversal, an absolute path, the agent queue's file name and an empty value are dropped; a plan agent is recorded as such; vanilla and transparent stay unset until named, and both can be set; persistence is on; the driver defaults to `claude` and an unknown name is ignored rather than trusted; the location is absent by default and `local` or `actions` is kept.
+- **Reading an agent's options off its spec** - the prompt, checkout, agent id, continuation flag and kind (research, verbatim prompt, build) round-trip; unattended is off unless the spec says otherwise, and a planning agent says so; in-context directories travel as a list; the on-before-mergeable follow-up and the browser are opt-in; the handoff level is unset unless given, a valid rung is kept and a made-up one dropped; a driver session id to resume is trimmed and a blank one dropped; the ticket is kept only when it is a ticket path, so a traversal, an absolute path, the agent queue's file name and an empty value are dropped; a plan agent is recorded as such; vanilla and transparent stay unset until named, and both can be set; persistence is on; the driver defaults to `claude` and an unknown name is ignored rather than trusted; the location is absent by default and `local` or `actions` is kept.
 - **Configuration layers** - the handoff resolves to `pr` when nobody set it; the repo file can move it and is named as its source; the spec's value beats the file's and is named as the source; vanilla and transparent are off when nothing set them, on when either layer sets them, and an explicit `false` in the spec turns off what the file switched on while `true` in the spec beats a file that says off; a layer that set nothing is absent from the sources.
 - **The on-before-mergeable follow-up** - the child agent's spec is a prompt kind carrying no on-before-mergeable option (the recursion guard) and goes vanilla when asked; the follow-up is one child run whose fully rendered prompt asks for queue entries applying the maintainability and security-audit presets to "changes introduced by <session name>" rather than running the presets; a child that fails is reported ("did not complete") and never thrown; the presets are materialized under the checkout so the queued paths resolve; the outcome is "queued" or "incomplete"; a declined follow-up (a fake agent never signals ready for merge) lands as a skipped outcome with its reason in the archived events, not on the terminal; an agent that never asked for the follow-up emits no such event.
 - **What is refused** - an empty prompt exits 2 with "no prompt to run"; a checkout whose recorded layout differs from this build's is refused with exit code 1 before anything is written; an unreadable spec exits 2 with "could not read the session spec"; a driver session id to resume on a build exits 2 with "only applies to a prompt session", while the same id on the prompt path is accepted; no preflight runs in the agent process, so it succeeds whatever coding agent is installed.
diff --git a/packages/framework/src/client.LOGIC.md b/packages/framework/src/client.LOGIC.md
index b1e64937b..d7bed5bf5 100644
--- a/packages/framework/src/client.LOGIC.md
+++ b/packages/framework/src/client.LOGIC.md
@@ -9,13 +9,13 @@ Names the one set of rules the dashboard [1] runs in the browser: every decision
 ## Glossary
 
 [1] the dashboard: the browser app the daemon serves — the product's only user interface.
-[2] preset: a canned prompt the user launches from the dashboard (research, readability, maintainability, security audit, UX, maintenance, market research, update tickets, plan tickets, suggest new tickets, suggest new features, suggest tickets to work on, drain queue, triage quick, triage consensual).
+[2] preset: a canned prompt the user launches from the dashboard (research, readability, maintainability, security audit, UX, maintenance, market research, update tickets, plan tickets, suggest new tickets, suggest new features, suggest tickets to work on, triage quick, triage consensual).
 [3] the built-in system prompt: the standing instructions every agent starts with; `SYSTEM.md` is the project's own instructions added on top.
 [4] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it).
 [5] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. A web agent is one whose location is `web`.
 [6] launcher: the Start form on a project's own page.
-[7] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
-[8] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[7] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[8] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [9] event: everything an agent does, one event per line appended to its event stream; every surface is a projection of it.
 [10] pick: the answer to a gate: the option or options chosen, by the user or automatically.
 [11] driver session: the coding agent's own conversation for one agent, which the driver can resume by its session id.
@@ -29,7 +29,7 @@ Names the one set of rules the dashboard [1] runs in the browser: every decision
 
 - **Nothing server-only may be reached** - no rule shared here, and nothing any of them reaches in turn, may use a capability that exists only outside a browser; a rule with a server half keeps that half in a separate module, the way reading the project's own `SYSTEM.md` from disk is kept apart from composing the prompt text.
 - **What an agent will be told** - the presets [2] and their prompts, the ask that plans one ticket, and the composition and rendering of the built-in system prompt [3], so the launcher [6] can prefill and show the user the exact text an agent [5] will receive instead of describing it.
-- **What the daemon does on its own** - the routines [7] Auto PM [8] fires, and its drain and maintenance work, so the list the user sees and can run on demand is the list the daemon runs, not a copy of it.
+- **What the daemon does on its own** - the routines [7] Auto PM [8] fires, the queued work and the maintenance sweep among them, so the list the user sees and can run on demand is the list the daemon runs, not a copy of it.
 - **How an agent's activity reads** - an agent [5]'s events [9] rendered as terminal text, which options a pick [10] chose, the driver session [11] behind the agent, the agent's progress, the errors it reported, and where its handoff [4] stands.
 - **What an agent will be started with** - the mapping from the user's preferences to an agent [5]'s options and its handoff [4] rung, how `the-framework.yml` at a project's root, the per-repo defaults that travel with the code, reads as preferences, and the handoff ladder itself with the conversions between the checkbox row and a rung, so an impossible combination resolves on the screen that collected it.
 - **The defaults and limits the user adjusts** - the notification defaults, whether a notification method and category is on, the default and maximum spend offset [12], and how many agents Auto PM [8] runs at once.
diff --git a/packages/framework/src/cloud-work.LOGIC.md b/packages/framework/src/cloud-work.LOGIC.md
index 48a0c986f..b0fae4d80 100644
--- a/packages/framework/src/cloud-work.LOGIC.md
+++ b/packages/framework/src/cloud-work.LOGIC.md
@@ -13,7 +13,7 @@ Cloud work adoption [1]: the sweep [2] that, once per tick [3] of the daemon's c
 [3] tick: one beat of the daemon's single background clock; each sweep says how many ticks it waits between turns.
 [4] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 [5] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. A web agent is one whose location is `web`.
-[6] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[6] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [7] cloud anchor: an empty commit a web agent pushes before its task leaves this machine, unique to the agent: the branch the cloud session later pushes descends from it, which is how the daemon recognises that branch as the agent's.
 [8] CI watch: the sweep that merges the pull requests The Framework opened once their checks pass, and starts a fix agent when a check goes red.
 [9] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
diff --git a/packages/framework/src/daemon-runtime.LOGIC.md b/packages/framework/src/daemon-runtime.LOGIC.md
index a0d4b077b..2fada9eba 100644
--- a/packages/framework/src/daemon-runtime.LOGIC.md
+++ b/packages/framework/src/daemon-runtime.LOGIC.md
@@ -12,13 +12,13 @@ What the daemon does for a project: starting an agent [1] (the project it is for
 [2] preflight: the check that the chosen driver's coding agent can start an agent, run before a checkout is spent.
 [3] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch. The user's own working copy is "the project's checkout" or "the user's checkout".
 [4] agent spec: the one JSON file the daemon hands a spawned agent process with its whole configuration.
-[5] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[5] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [6] reclaim: removing a finished agent's checkout once its work is on the remote.
 [7] relay: running an agent on a device: the local daemon forwards the start, streams the events back and forwards steering, so the agent renders like a local one.
 [8] device: another machine's daemon the user saved by URL and token, to run agents on it from this dashboard.
 [9] event stream: everything an agent does, one event per line appended to `.the-framework/events.jsonl` in its checkout; every surface (dashboard, terminal, archive, run) is a projection of it.
 [10] control file: `.the-framework/control.jsonl`: the file the daemon appends steering to (stops, picks, chat messages) and the agent's process tails.
-[11] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads (its `SKILL.md`, linked into the checkout where the coding agent's harness looks for skills), a command on the agent's PATH, and an API the product calls.
+[11] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads (its `SKILL.md`, a tracked file of the project where the coding agent's harness looks for skills), a command run as `npx <skill>`, and an API the product calls.
 [12] driver: a coding agent wrapped as a black box. The user's driver choice is `claude` or `codex`.
 [13] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [14] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
@@ -42,9 +42,9 @@ What the daemon does for a project: starting an agent [1] (the project it is for
 - **The device side of a relay** - a daemon that relayed an agent here may read, steer and hand off that agent against this daemon's home project only, through a fixed list of actions that never includes starting, previewing or deleting.
 - **Preflight before a checkout is spent** - an agent whose turns run on this machine starts only if its driver's [12] coding agent is installed and logged in; a pass is trusted for 30 seconds, a failure never.
 - **A continuation reopens the agent's own checkout** - Resume starts from the project's own options, waits out the previous leg's exit, reuses or re-attaches the agent's checkout on its recorded branch, and restores its history so it stays one agent.
-- **Every agent gets its own checkout and branch** - a checkout under `.branches/` on branch `agent-<agent id>` with the four skills [11] linked in; a directory that is not a repository gets no checkout and runs in the project's checkout one agent at a time; a repository whose checkout cannot be created refuses the start rather than borrowing the user's checkout.
+- **Every agent gets its own checkout and branch** - a checkout under `.branches/` on branch `agent-<agent id>` with the `branches` skill [11] and the routine skill `work-queue` linked in; a directory that is not a repository gets no checkout and runs in the project's checkout one agent at a time; a repository whose checkout cannot be created refuses the start rather than borrowing the user's checkout.
 - **One agent per checkout** - a second start aimed at a checkout whose agent is alive or mid-spawn is refused as busy.
-- **The agent spec, the spawned process and its environment** - the process is handed one spec [4] with its prompt verbatim, runs detached with its stderr in its checkout, sees the skills' commands on its PATH, its id as `AGENT_ID` and the daemon's address, and is refused and undone if the daemon began closing meanwhile.
+- **The agent spec, the spawned process and its environment** - the process is handed one spec [4] with its prompt verbatim, runs detached with its stderr in its checkout, sees nothing added to its PATH, its id as `AGENT_ID` and the daemon's address, and is refused and undone if the daemon began closing meanwhile.
 - **When the process ends** - the spec is removed, the slot freed, and for an agent with its own checkout a chain runs: a failed-start marker if it never reported anything, the teardown, then the transient-death retry.
 - **Teardown: record the run, then reclaim the checkout** - the agent's branch is read while the checkout exists, its run [5] written to the `agent-data` branch [13], and the checkout removed only once its work is on the remote, whatever state the agent ended in.
 - **One more try after a transient death** - a local agent that failed by its own report on a transport error is continued unattended [14] after 15 seconds, at most twice.
@@ -110,7 +110,7 @@ A continuation start carries only its seed: the agent to continue and, when it h
 
 Before the preflight [2], the previous leg is waited out for up to 15 seconds when its slot is still held: a leg that positively reports itself running is a genuine collision and is not waited for, so the busy refusal stands; a leg that reports itself ended, or whose state cannot be read at that instant, is waited for until its slot clears and its queued teardown finishes. A state that cannot be read is asked again rather than taken as running, because the agent's status file is rewritten in place and a single torn read says nothing about the leg.
 
-After the preflight, the agent's checkout is reused when it still exists; otherwise the agent's branch, the one recorded when its checkout went (the agent renames its branch itself to its session name [23], so the recorded name wins over the birth branch `agent-<agent id>`, which is the only fallback), is checked out again as a fresh checkout with the four skills [11] linked in. The agent's archived history is restored into the checkout, so it reopens its own event stream [9] instead of starting empty and stays one row. All of this runs under the agent's lock (`agent-locks.ts`), so a Resume never reuses a checkout that a teardown is removing. When none of this is possible, a new agent is started instead and the daemon logs "[framework] could not continue agent <agent id> (<reason>); starting a new one".
+After the preflight, the agent's checkout is reused when it still exists; otherwise the agent's branch, the one recorded when its checkout went (the agent renames its branch itself to its session name [23], so the recorded name wins over the birth branch `agent-<agent id>`, which is the only fallback), is checked out again as a fresh checkout with the same two skill links. The agent's archived history is restored into the checkout, so it reopens its own event stream [9] instead of starting empty and stays one row. All of this runs under the agent's lock (`agent-locks.ts`), so a Resume never reuses a checkout that a teardown is removing. When none of this is possible, a new agent is started instead and the daemon logs "[framework] could not continue agent <agent id> (<reason>); starting a new one".
 
 ### Every agent gets its own checkout and branch
 
@@ -122,7 +122,7 @@ After the preflight, the agent's checkout is reused when it still exists; otherw
 
 #### Business logic
 
-A new agent's id is derived from the moment of the start, unless the caller minted the id first: a sweep [15] that claimed a ticket for the agent wrote the claim [24] under the id it now starts the agent with. The checkout is created by the `branches` skill [11] in one sequence: a git worktree under the project's `.branches/` directory on a fresh branch `agent-<agent id>`, `.branches/` hidden from git, the project's dependency trees linked in, and the `tickets`, `queue` and `logs` skills linked in beside `branches` where the coding agent's [18] harness looks for skills.
+A new agent's id is derived from the moment of the start, unless the caller minted the id first: a sweep [15] that claimed a ticket for the agent wrote the claim [24] under the id it now starts the agent with. The checkout is created by the `branches` skill [11] in one sequence: a git worktree under the project's `.branches/` directory on a fresh branch `agent-<agent id>`, `.branches/` hidden from git, the project's dependency trees linked in, and the routine skill `work-queue` — the skill file shipped in this package that the daemon starts the queued work with — linked in beside `branches` where the coding agent's [18] harness looks for skills. The `tickets`, `queue` and `logs` skills are the project's own tracked files, not the daemon's to link.
 
 A project that is not a git repository cannot be given a checkout: its agents run in the project's own checkout, one at a time since they would collide, and the daemon logs "[framework] <project> is not a git repository, so it gets no worktree; running in the main checkout". A project that is a repository but whose checkout could not be created does not fall back to the user's checkout: the start is refused with "could not create a worktree for this run: <reason>", the dashboard shows it, and starting again is the retry, because a failed agent is recoverable and a user's checkout with an agent's edits mixed in is not. When the creation was cut short by its time budget, the partial directory it left is removed; a failure of any other kind leaves the directory alone, since it may be a path that was on disk before this agent asked for it.
 
@@ -146,7 +146,7 @@ Each agent holds a slot keyed by its project and its agent id [25]; an agent tha
 
 The daemon writes one agent spec [4] (`agent-spec.ts`): the prompt exactly as given, even when empty, and never re-rendered, so a preset the user reviewed in the composer runs verbatim; the kind (`build`, `prompt` or `research`); the checkout [3]; the agent id [25], which also tells the process that The Framework owns its branch; whether it continues an existing agent, in which case the process reopens the agent's event stream [9] instead of truncating it; and every option the start carried.
 
-The process runs detached from the daemon, with its input and output closed and its error output written to `.the-framework/stderr.log` in its checkout when it has one, so a process that dies at boot leaves a trace; when that file cannot be opened the agent still starts. Its environment is the daemon's with the `branches`, `tickets`, `queue` and `logs` commands first on its PATH, its agent id as `AGENT_ID` so that a claim [24] it makes names the agent and not its branch, and the daemon's own address once the daemon has one, so a `web` agent can ask this daemon for a cloud session [26]. The process id becomes the agent's live slot, and the start answers with the agent id so the dashboard selects that agent rather than guessing.
+The process runs detached from the daemon, with its input and output closed and its error output written to `.the-framework/stderr.log` in its checkout when it has one, so a process that dies at boot leaves a trace; when that file cannot be opened the agent still starts. Its environment is the daemon's, with nothing added to its PATH — a skill's command resolves from the project's own dependencies as `npx <skill>` — its agent id as `AGENT_ID` so that a claim [24] it makes names the agent and not its branch, and the daemon's own address once the daemon has one, so a `web` agent can ask this daemon for a cloud session [26]. The process id becomes the agent's live slot, and the start answers with the agent id so the dashboard selects that agent rather than guessing.
 
 Right before the spawn, and again because everything before it waited, the daemon checks whether it began shutting down meanwhile: if so the start is refused with "the daemon is shutting down" and everything it allocated is taken back: the spec, and for a new agent its checkout and branch; a continued agent's checkout is the agent's own and is left alone. A checkout left standing without an agent would otherwise be reclaimed at the next boot by pushing an empty branch.
 
@@ -172,7 +172,7 @@ For an agent with its own checkout [3], a retirement chain then runs and is park
 
 #### Business logic
 
-The teardown runs under the agent's lock (`agent-locks.ts`), one at a time with the dashboard's actions on the same agent, so whoever runs first pushes and the other finds the remote already has the branch. The agent's branch is read from the checkout while the checkout still exists, and only from a directory that is a checkout root, because a directory that no longer is one would answer with the user's own branch. The agent's record is then written as a run [5] on the `agent-data` branch [13] through the `logs` skill [11], the card from the agent's status and the diary from its event stream [9], committed and pushed the moment it lands, so it is durable without a human and never a commit on a code branch; a record that could not be written is logged as "[framework] could not archive session <checkout name>: <error>". Then the checkout is removed by the one rule in `worktrees.ts`, shared with the reclaim [6] sweep [15] and the dashboard's Remove: only what is on the remote may go, whatever state the agent ended in, since what decides is whether the work is recoverable, not how the agent ended. A push that cannot land keeps the checkout, logged as "[framework] keeping worktree <path>: <reason>", and the sweep retries it later; a removal is logged as "[framework] removed worktree <path> and <what was deleted>: nothing on it is missing elsewhere". Any failure along the way leaves the checkout on disk, which is the safe direction.
+The teardown runs under the agent's lock (`agent-locks.ts`), one at a time with the dashboard's actions on the same agent, so whoever runs first pushes and the other finds the remote already has the branch. The agent's branch is read from the checkout while the checkout still exists, and only from a directory that is a checkout root, because a directory that no longer is one would answer with the user's own branch. The agent's record is then written as a run [5] on the `agent-data` branch [13] through the `logs` skill [11], the card from the agent's status and the diary from its event stream [9], committed and pushed the moment it lands, so it is durable without a human and never a commit on a code branch; the commit is signed with the daemon's trailer (`daemon-writes.ts`), so the sweep that watches the branch for work does not read the record as a move; a record that could not be written is logged as "[framework] could not archive session <checkout name>: <error>". Then the checkout is removed by the one rule in `worktrees.ts`, shared with the reclaim [6] sweep [15] and the dashboard's Remove: only what is on the remote may go, whatever state the agent ended in, since what decides is whether the work is recoverable, not how the agent ended. A push that cannot land keeps the checkout, logged as "[framework] keeping worktree <path>: <reason>", and the sweep retries it later; a removal is logged as "[framework] removed worktree <path> and <what was deleted>: nothing on it is missing elsewhere". Any failure along the way leaves the checkout on disk, which is the safe direction.
 
 ### One more try after a transient death
 
diff --git a/packages/framework/src/daemon-runtime.test.LOGIC.md b/packages/framework/src/daemon-runtime.test.LOGIC.md
index c7388f9db..56889f436 100644
--- a/packages/framework/src/daemon-runtime.test.LOGIC.md
+++ b/packages/framework/src/daemon-runtime.test.LOGIC.md
@@ -4,3 +4,4 @@ What the tests cover, driving the runtime's waits and its process termination di
 - **A leg whose state cannot be read** - an unreadable state is asked again rather than taken for a live leg, so the exit is waited out instead of refused; an unreadable leg that then reports running still short-circuits to the busy guard, the asking having continued until the leg committed; a leg that once reported ended is not read again.
 - **Letting go of the repository at shutdown** - slots nothing has touched return at once; a slot whose process is gone but whose exit has not landed yet is waited for, together with the teardown that appears mid-wait; an agent with no checkout of its own parks no teardown and holds nothing up; a teardown that throws does not fail the shutdown; the wait is bounded, so a wedged teardown costs the grace period and not the exit.
 - **Terminating an agent's process** - an agent that ignores the graceful stop is ended forcibly together with its whole process group, so the browser it launched dies with it instead of living on unowned.
+- **What a spawned agent is handed** - its id as `AGENT_ID`, the daemon's address, and a PATH that is the daemon's own with nothing added; the routine skill the daemon links into every checkout is `work-queue`, a skill file whose front matter names it and marks it as invocable only by a person or the daemon.
diff --git a/packages/framework/src/daemon-services.LOGIC.md b/packages/framework/src/daemon-services.LOGIC.md
index bdbcfc335..c0c592c27 100644
--- a/packages/framework/src/daemon-services.LOGIC.md
+++ b/packages/framework/src/daemon-services.LOGIC.md
@@ -1,8 +1,8 @@
-Everything the daemon runs in the background beside serving the dashboard, wired as eight jobs on the daemon's one clock: the sweeps [1] that reclaim [2] checkouts [3], keep the `.branches/` links current, converge every project's `agent-data` branch [4] with the remote, watch the pull requests The Framework opened (the CI watch [5]), post notifications to Discord, run Auto PM [6], delete the scratch refs of `web` agents [7] and adopt the branches cloud sessions [8] worked on. Each job says how many ticks [9] it waits between turns and re-reads the preference [10] that gates it on every turn, so a switch flipped in the dashboard takes effect without a restart. The two jobs that start agents on their own, Auto PM and the CI watch's fix agent, start them the same way: unattended [11], with the project's own options, and only under the quota boundary [12] measured for the model the agent would run on. Auto PM's claims [13] and routine locks [14] are taken by the daemon before an agent starts and freed by it after. What each job does on its turn is its own file's logic: `merged-worktrees.ts`, `auto-pm.ts`, `ci-watch.ts`, `cloud-scratch-refs.ts`, `cloud-work.ts`, `dashboard/keyed-watcher.ts`; the clock itself is `daemon-tick.ts`.
+Everything the daemon runs in the background beside serving the dashboard, wired as eight jobs on the daemon's one clock: the sweeps [1] that reclaim [2] checkouts [3], keep the `.branches/` links current, converge every project's `agent-data` branch [4] with the remote, watch the pull requests The Framework opened (the CI watch [5]), post notifications to Discord, run Auto PM [6], delete the scratch refs of `web` agents [7] and adopt the branches cloud sessions [8] worked on. Each job says how many ticks [9] it waits between turns and re-reads the preference [10] that gates it on every turn, so a switch flipped in the dashboard takes effect without a restart. The two jobs that start agents on their own, Auto PM and the CI watch's fix agent, start them the same way: unattended [11], with the project's own options, and only under the quota boundary [12] measured for the model the agent would run on. Auto PM's claims [13] and routine locks [14] are taken by the daemon before an agent starts and freed by it after. Every write the daemon makes on its own — a run's record, a lock, a claim — is signed with a trailer naming the machine (`daemon-writes.ts`), so the sweep that starts work when the branch moves never reads the daemon's own commits as work. What each job does on its turn is its own file's logic: `merged-worktrees.ts`, `auto-pm.ts`, `ci-watch.ts`, `cloud-scratch-refs.ts`, `cloud-work.ts`, `dashboard/keyed-watcher.ts`; the clock itself is `daemon-tick.ts`.
 
 ## Context
 
-**User story**: the user switches "Spend what's left on the roadmap" on and, with nothing else to do, the daemon drains the agent queue [15] and refills it by triaging and planning tickets, bounded by the account's quota week; a pull request The Framework opened is merged once its checks pass, and an agent is put on it when a check goes red; a Discord message arrives when something needs the user or when an agent starts or finishes, even with no dashboard open; a finished agent's checkout is reclaimed once its work is on the remote; a ticket claimed on this machine is seen as claimed on every machine sharing the repository. Ctrl-C stops all of it before the agents it runs are stopped.
+**User story**: the user switches "Spend what's left on the roadmap" on; when someone queues work the daemon starts an agent on the agent queue [15] within a minute, and once a run finds nothing queued it refills the queue by triaging and planning tickets, bounded by the account's quota week; a pull request The Framework opened is merged once its checks pass, and an agent is put on it when a check goes red; a Discord message arrives when something needs the user or when an agent starts or finishes, even with no dashboard open; a finished agent's checkout is reclaimed once its work is on the remote; a ticket claimed on this machine is seen as claimed on every machine sharing the repository. Ctrl-C stops all of it before the agents it runs are stopped.
 
 **Problem**: background work that starts agents can spend the user's subscription on work nobody asked for, collide with the user's own actions, or run twice across machines. Every job here is therefore gated by a preference, measured against the quota, and coordinated through files on the `agent-data` branch [4].
 
@@ -13,7 +13,7 @@ Everything the daemon runs in the background beside serving the dashboard, wired
 [3] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [4] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [5] CI watch: the sweep that merges the pull requests The Framework opened once their checks pass, and starts a fix agent when a check goes red.
-[6] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[6] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [7] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [8] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 [9] tick: one beat of the daemon's single background clock; each sweep says how many ticks it waits between turns.
@@ -25,9 +25,9 @@ Everything the daemon runs in the background beside serving the dashboard, wired
 [15] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [16] the repo file: `the-framework.yml` at a project's root: per-repo defaults that travel with the code.
 [17] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
-[18] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[18] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [19] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
-[20] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[20] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [21] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
 [22] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it).
 [23] intervention: something that needs a human — an open question, a pull request to review, unpushed commits — one of the two notification feeds. The other is activity: an agent started or finished.
@@ -35,16 +35,16 @@ Everything the daemon runs in the background beside serving the dashboard, wired
 
 ## Business logic — TL;DR
 
-- **Eight jobs on one clock, in a fixed order** - the "worktree sweep" and the branch links every ten minutes, the data sync, the CI watch [5] and the Discord watchers every minute, Auto PM [6] every ten minutes, the cloud scratch sweep hourly, cloud work adoption every ten minutes; all take the start-up tick [9], in an order chosen so the sweep runs before any agent [7] exists and Auto PM reads the queue the sync just pulled.
+- **Eight jobs on one clock, in a fixed order** - the "worktree sweep" and the branch links every ten minutes, the data sync, the CI watch [5], the Discord watchers and Auto PM [6] every minute, the cloud scratch sweep hourly, cloud work adoption every ten minutes; all take the start-up tick [9], in an order chosen so the sweep runs before any agent [7] exists and Auto PM looks at the branch the sync just pulled.
 - **How a daemon-started agent is started** - always unattended [11], with the project's own options (the preferences [10], then the repo file [16] on top, the launcher's own mapping) under whatever the job adds, through the daemon's ordinary start.
 - **The quota boundary, measured for the project's model** - both self-starting jobs stand down past the boundary [12] as measured for the model their agent would run on, and stand down when the quota [17] cannot be read at all.
-- **What Auto PM is told** - its switch and the routines [18] the user unticked (both machine-wide), the queue's open entries, the held slots by name, the concurrency cap, the maintenance schedule, the routine list, and the tickets a plan fan-out [19] may take: unplanned, unclaimed, most important first.
-- **Claims before a start, freed after** - the daemon writes and pushes a claim [13] for every ticket a drain [20] or a plan fan-out is about to start an agent on, under the agent id [21] the agent is then born with; a plan claim skips a ticket already planned or claimed, a drain claim only one already claimed; the one claim the daemon frees itself is one whose agent ended with nothing to hand off.
+- **What Auto PM is told** - its switch and the routines [18] the user unticked (both machine-wide), the head of each project's `agent-data` branch and how many commits since its last look no daemon wrote, the held slots by name, the concurrency cap, the maintenance schedule, the routine list, and the tickets a plan fan-out [19] may take: unplanned, unclaimed, most important first.
+- **Claims before a start, freed after** - the daemon writes and pushes a claim [13] for every ticket a plan fan-out is about to start an agent on, under the agent id [21] the agent is then born with, skipping a ticket already planned or claimed; the one claim the daemon frees itself is one whose agent ended with nothing to hand off. The queued work [20] claims nothing: its agent claims for itself.
 - **Routine locks** - a routine lock [14] is taken before a routine's agent starts and dropped when that agent ends, and the locks a previous daemon of this machine left behind are freed unless an agent of this machine started since is still running.
-- **What a started agent carries** - the ticket it is about to implement or plan, the plan-agent mark for a fan-out so its pull request never closes the ticket's issue, and the `merge` handoff [22] when the job says its pull requests may land themselves.
-- **Retiring a drained entry** - the daemon takes a drained entry off the agent queue [15] itself, in one write to the `agent-data` branch [4], once the agent has settled and its work is published; an agent that published nothing leaves its entry open.
+- **What a started agent carries** - its prompt verbatim (`/work-queue` for the queued work), the plan-agent mark for a fan-out so its pull request never closes the ticket's issue, and the `merge` handoff [22] when the job says its pull requests may land themselves.
+- **Whether a run has ended** - the daemon answers Auto PM from the run's own record: still going, or ended, and how its handoff reported; the daemon touches no queue entry at the run's end, the agent marked its own entry done.
 - **The CI watch's fix agent** - merging is never gated; a fix agent starts only with Auto PM switched on and quota headroom, works on the pull request's own branch with a `local` handoff, and a stand-down for lack of quota is said once per failing head.
-- **The data sync** - every minute, every project's `agent-data` branch is converged with the remote, and the project's "data-sync" error is set by the failure or cleared by the success.
+- **The data sync** - every minute, every project's `agent-data` branch is converged with the remote in one pull through the shared branch library, and the project's "data-sync" error is set by the failure or cleared by the success.
 - **The Discord watchers** - two watchers, interventions [23] and activity, exist only when a webhook is configured, post only when the preferences allow the category at posting time, seed their baseline on their first poll so nothing old is announced, and are rebuilt whenever a credential is saved from the dashboard.
 - **What the daemon can ask of the services** - wake Auto PM now (plainly, when its preference was just switched on; on demand, from the dashboard's button, even while it is off), read Auto PM's last report, reload Discord, and quiesce: stop the clock after the turn in flight, then every job, before any agent is stopped.
 
@@ -62,10 +62,10 @@ The jobs are declared on the daemon's one clock (`daemon-tick.ts`), one tick [9]
 
 - "worktree sweep", every 20 ticks (ten minutes): reclaims the checkouts of finished agents whose work is on the remote (`merged-worktrees.ts`), leaving alone every agent the daemon is still responsible for. First, so its start-up turn lands while the daemon owns no agent at all; the case it exists for is a machine that was off while an agent's push could not land.
 - "branch links", every 20 ticks: brings the `.branches/` links, one per checkout named as its branch, up to date in every project; quiet and idempotent. Right after the sweep, so links to checkouts just reclaimed drop in the same turn.
-- "data sync", every 2 ticks (one minute): converges every project's `agent-data` branch [4] with the remote (see the data sync rule below). Before Auto PM [6], so a sweep of the same tick reads the queue the sync just brought in; its start-up turn is also what creates the branch's checkout on a fresh clone.
+- "data sync", every 2 ticks (one minute): converges every project's `agent-data` branch [4] with the remote (see the data sync rule below). Before Auto PM [6], so a look of the same tick sees the head the sync just brought in; its start-up turn is also what creates the branch's checkout on a fresh clone.
 - "CI watch", every 2 ticks: the CI watch [5] (`ci-watch.ts`).
 - "Discord watchers", every 2 ticks: one poll of each notification watcher; their first turn seeds the baseline, which must happen at start-up or the whole open backlog would read as new.
-- "auto PM", every 20 ticks: Auto PM (`auto-pm.ts`). Its start-up turn matters: a daemon started with the switch already on would otherwise sit for ten minutes doing nothing with quota [17] going spare.
+- "auto PM", every 2 ticks, behind the pull: Auto PM (`auto-pm.ts`). A look costs one git read; a run only ever starts when the branch moved. Its start-up turn matters: it remembers where the branch stands, and takes the rotation's first turn for a daemon started with the switch already on, which would otherwise sit idle with quota [17] going spare.
 - "cloud scratch sweep", every 120 ticks (hourly): deletes the scratch refs a `web` agent's handoff leaves on the remote, once they have sat for about a day and their work is provably on the default branch (`cloud-scratch-refs.ts`). Hourly because the refs must age a day first; its start-up turn starts that clock.
 - "cloud work adoption", every 20 ticks: matches each settled `web` agent to the branch its cloud session [8] pushed, records the branch and pull request on the agent, and opens the pull request the session never did (`cloud-work.ts`).
 
@@ -97,25 +97,25 @@ Both self-starting jobs, Auto PM [6] and the CI watch's [5] fix agent, ask the d
 
 #### Context
 
-**Business logic story**: Auto PM [6] decides per project whether to drain [20] the agent queue [15], run a routine [18] or fan out [19]; the decision rules are in `auto-pm.ts`. This file supplies what it decides on.
+**Business logic story**: Auto PM [6] decides per project whether to start the queued work [20], run a routine [18] or fan out [19]; the decision rules are in `auto-pm.ts`. This file supplies what it decides on.
 
 #### Business logic
 
-Auto PM is told: whether it is switched on (the "Spend what's left on the roadmap" preference [10]); which routines the user unticked, kept machine-wide like the switch itself, since the rotation is one schedule for the machine and not one per repository; the open entries of each project's queue, as entries rather than a bare "empty or not", because a batch of concurrent drains is pinned one entry each; the slots each project holds, each named as "<agent id> (pid <process id>)", "<agent id> (starting)", or "a run in the project checkout" for an agent that got no checkout [3] of its own, so its stand-down and fan-out lines say what they were measured against instead of a bare number; how many agents [7] a routine may keep going per project, from the preferences, machine-wide; whether the maintenance routine is due, read from the project's own schedule file so a daily reboot cannot reset it (`maintenance.ts`), and how to record a sweep; the four scheduled routines in rotation order, update tickets, triage quick, triage consensual, plan tickets, the two triages each holding a routine lock [14] and plan tickets fanning out; and the tickets a plan fan-out may take: every ticket that is unplanned and unclaimed, most important first by its numeric priority, a ticket without one last. No stale-claim sweep runs: a claim stands until the agent's pull request deletes it or the user releases it from the dashboard.
+Auto PM is told: whether it is switched on (the "Spend what's left on the roadmap" preference [10]); which routines the user unticked, kept machine-wide like the switch itself, since the rotation is one schedule for the machine and not one per repository; the local head of each project's `agent-data` branch, and, between two heads, how many commits carry no `Daemon:` trailer (both git reads on the project's repository, the rules in `daemon-writes.ts`); the slots each project holds, each named as "<agent id> (pid <process id>)", "<agent id> (starting)", or "a run in the project checkout" for an agent that got no checkout [3] of its own, so its stand-down and fan-out lines say what they were measured against instead of a bare number; how many agents [7] a routine may keep going per project, from the preferences, machine-wide; whether the maintenance routine is due, read from the project's own schedule file so a daily reboot cannot reset it (`maintenance.ts`), and how to record a sweep; the four scheduled routines in rotation order, update tickets, triage quick, triage consensual, plan tickets, the two triages each holding a routine lock [14] and plan tickets fanning out; and the tickets a plan fan-out may take: every ticket that is unplanned and unclaimed, most important first by its numeric priority, a ticket without one last. No stale-claim sweep runs: a claim stands until the agent's pull request deletes it or the user releases it from the dashboard.
 
 ### Claims before a start, freed after
 
 #### Context
 
-**User story**: a ticket an agent [7] is working shows as held on every machine that shares the repository, and `tickets show` names the agent holding it.
+**User story**: a ticket a plan agent [7] is working shows as held on every machine that shares the repository, and `tickets show` names the agent holding it.
 
-**Problem**: an agent pushes only at the end of its work, onto its own branch, so a claim [13] the agent wrote itself would not reach the machines it exists for. And a claim whose agent ended with nothing to hand off would stand forever, since the pull request that would delete it is never coming.
+**Problem**: a plan agent pushes only at the end of its work, onto its own branch, so a claim [13] the agent wrote itself would not reach the machines it exists for. And a claim whose agent ended with nothing to hand off would stand forever, since the pull request that would delete it is never coming. The queued work [20] is different: its agent claims its ticket itself, through the `tickets` skill, as one of the commits that move the branch; the plan fan-out is the one place the daemon still claims, and its own design is a follow-up.
 
 #### Business logic
 
-Before Auto PM [6] starts the agents of a drain [20] or of a plan fan-out [19], the daemon claims their tickets through the `tickets` skill, as one commit pushed to the `agent-data` branch [4], each claim naming as holder [24] the agent id [21] the agent is then born with, so the claim and the agent are one. A plan claim skips a ticket that already has a plan or that is already claimed; a drain claim skips only a ticket already claimed, because the plan a drain would also find is the drain's input, not a rival. A ticket already claimed by the same holder counts as claimed. Only the tickets actually claimed are started on. A batch that committed but could not push still counts as claimed, and the gap is logged.
+Before Auto PM [6] starts the agents of a plan fan-out [19], the daemon claims their tickets through the `tickets` skill, as one commit pushed to the `agent-data` branch [4] and signed with the daemon's trailer, each claim naming as holder [24] the agent id [21] the agent is then born with, so the claim and the agent are one. A plan claim skips a ticket that already has a plan or that is already claimed. A ticket already claimed by the same holder counts as claimed. Only the tickets actually claimed are started on. A batch that committed but could not push still counts as claimed, and the gap is logged.
 
-When a drained entry's agent settles with nothing to hand off, the one dead claim the daemon can know is dead, the daemon frees that exact claim, logging "[framework] auto PM: released the lock on <ticket> — its agent ended with nothing to hand off"; a release that cannot be committed is logged as "[framework] auto PM: the release of the lock on <ticket> could not be committed; it will be retried" and tried again.
+When a plan agent settles with nothing to hand off, the one dead claim the daemon can know is dead, the daemon frees that exact claim, logging "[framework] auto PM: released the lock on <ticket> — its agent ended with nothing to hand off"; a release that cannot be committed is logged as "[framework] auto PM: the release of the lock on <ticket> could not be committed; it will be retried" and tried again.
 
 ### Routine locks
 
@@ -125,27 +125,27 @@ When a drained entry's agent settles with nothing to hand off, the one dead clai
 
 #### Business logic
 
-Before a routine that holds a lock starts its agent [7], the daemon takes the routine lock [14] (`routine-locks.ts`), a pushed file on the `agent-data` branch; a live lock, anyone's, stands the routine down. When that agent ends, however it ended, the daemon that took the lock removes it, logging "[framework] auto PM: released the <routine> lock — its run ended", or "[framework] auto PM: the release of the <routine> lock could not be committed; it will be retried". On boot, the locks a previous daemon of this same machine left behind are freed, each logged as "[framework] auto PM: released the <routine> lock a previous daemon left behind", unless an agent of this machine started since the lock was taken is still running, which means the lock is that agent's.
+Before a routine that holds a lock starts its agent [7], the daemon takes the routine lock [14] (`routine-locks.ts`), a pushed file on the `agent-data` branch, signed with the daemon's trailer; a live lock, anyone's, stands the routine down. When that agent ends, however it ended, the daemon that took the lock removes it, logging "[framework] auto PM: released the <routine> lock — its run ended", or "[framework] auto PM: the release of the <routine> lock could not be committed; it will be retried". On boot, the locks a previous daemon of this same machine left behind are freed, each logged as "[framework] auto PM: released the <routine> lock a previous daemon left behind", unless an agent of this machine started since the lock was taken is still running, which means the lock is that agent's.
 
 ### What a started agent carries
 
 #### Context
 
-**Business logic story**: the moment Auto PM [6] starts an agent [7] is the one moment The Framework knows what the agent is about to implement or plan, and can say so on the agent's record.
+**Business logic story**: the daemon knows nothing about what an agent is going to do beyond the prompt it starts it with; what it records on the agent is only what the handoff needs.
 
 #### Business logic
 
-An agent started by a drain [20] carries the ticket its queue entry links back to: the entry the sweep pinned to it, or, for a drain job wired without one, the first open entry of the agent queue [15]; an entry that is plain text names no ticket. An agent started by a plan fan-out [19] carries the ticket it is pinned to, and is marked as planning it rather than implementing it, so its pull request title does not inherit the ticket's issue and the plan's merge cannot close an issue whose work is still undone. When the sweep minted a claim [13] for the agent, the agent is started under that claim's agent id [21]. When the job says its pull requests may land themselves, the agent's handoff [22] is `merge`, the top of the ladder: a drain implements work whose review already happened on the queue. The started agent's id is handed back to Auto PM; a start that failed hands back nothing.
+An agent started on the queued work [20] carries the prompt `/work-queue` and nothing about which entry or ticket it will take: the agent reads the queue itself. An agent started by a plan fan-out [19] is marked as planning rather than implementing, so a closing phrase in its pull request cannot close an issue whose work is still undone. When the sweep minted a claim [13] for the agent, the agent is started under that claim's agent id [21]. When the job says its pull requests may land themselves, the agent's handoff [22] is `merge`, the top of the ladder: a drain implements work whose review already happened on the queue. The started agent's id is handed back to Auto PM; a start that failed hands back nothing.
 
-### Retiring a drained entry
+### Whether a run has ended
 
 #### Context
 
-**Problem**: the agent queue [15] has one local writer; an entry crossed off by an agent on its own branch would have to be promoted off that branch. And "done" has to mean the work was published, not merely that the agent [7] ended.
+**Problem**: Auto PM [6] needs to know when a run it started is over, to release what the daemon took for it and to judge whether the queue wants refilling; and the daemon must not touch the queue at a run's end, since the agent marked its own entry done and the daemon reads no queue.
 
 #### Business logic
 
-For each drained entry, Auto PM [6] asks the daemon each tick [9] whether its agent has settled. An agent that is unknown or still running is not settled, and the entry is asked about again next tick. A settled agent counts as published only when it ended cleanly and its handoff [22] reported done, or was skipped because the pull request was already open (a resumed agent whose earlier leg published). A published agent's entry is taken off the queue in one write committed and pushed to the `agent-data` branch [4], where an entry already gone changes nothing; a write that fails is logged as "[framework] auto PM: the drained entry could not be taken off the queue (<agent id>)", the entry stays held and the write is retried next tick. An agent that published nothing leaves its entry open. Alongside, the daemon reports how the agent's handoff ended: a handoff skipped for lack of commits is the one case that frees the claim [13] (see above), and a clean end whose handoff has not reported yet is said to be still publishing rather than never going to.
+For each run it started, Auto PM [6] asks the daemon each look whether the agent has settled, and the daemon answers from the run's own record: an agent that is unknown or still running is not settled and is asked about again next look. A settled agent's answer carries how its handoff [22] ended: a handoff skipped for lack of commits is the one case that frees a plan claim [13] (see above), and a clean end whose handoff has not reported yet is said to be still publishing rather than never going to.
 
 ### The CI watch's fix agent
 
@@ -165,7 +165,7 @@ The CI watch [5] walks every registered project every minute (`ci-watch.ts`). It
 
 #### Business logic
 
-Every minute, for every registered project in turn, the daemon converges the project's `agent-data` branch [4] with the remote: first through the `tickets` skill (the branch's checkout, its link at the project root, then the pull), then, only if that succeeded, through the `queue` skill (its seed and pull). Anything a failed cycle left local is carried out. A success clears the project's "data-sync" error unconditionally, so the error lives exactly as long as the condition and is gone at the next tick after the user fixes the remote; a failure logs "[framework] data sync: <error>" and sets that error for the dashboard to show.
+Every minute, for every registered project in turn, the daemon converges the project's `agent-data` branch [4] with the remote in one pull through the shared branch library (`agent-data`'s), which creates the branch's checkout when there is none. Anything a failed cycle left local is carried out. The daemon knows nothing of what is on the branch: the `tickets` link at a project's root and the queue file's seed are each skill's own setup, no longer the daemon's. A success clears the project's "data-sync" error unconditionally, so the error lives exactly as long as the condition and is gone at the next tick after the user fixes the remote; a failure logs "[framework] data sync: <error>" and sets that error for the dashboard to show.
 
 ### The Discord watchers
 
@@ -187,7 +187,7 @@ The group is rebuilt against the credentials as they are now whenever a credenti
 
 #### Business logic
 
-- Wake Auto PM [6]: a plain wake runs the Auto PM turn now; the turn re-reads the preference [10] itself, so a wake that arrives after the switch went the other way records "off" and starts nothing. An on-demand wake, the dashboard's button, runs the turn even while the switch is off, because the click is the ask the preference would otherwise record; it can be narrowed to a drain [20], a plan fan-out [19], one locked routine [18] or one project. Both resolve when the turn finishes, so the button can await the sweep and show what it decided, and a failed turn resolves silently.
+- Wake Auto PM [6]: a plain wake runs the Auto PM turn now; the turn re-reads the preference [10] itself, so a wake that arrives after the switch went the other way records "off" and starts nothing. An on-demand wake, the dashboard's button, runs the turn even while the switch is off, because the click is the ask the preference would otherwise record; it can be narrowed to the queued work [20], a plan fan-out [19], one locked routine [18] or one project. Both resolve when the turn finishes, so the button can await the sweep and show what it decided, and a failed turn resolves silently.
 - Auto PM's report: what its last turn decided, for the usage panel.
 - Reload Discord: the rebuild described above.
 - Quiesce, the first phase of the daemon's shutdown: the clock is stopped and its turn in flight waited out, so the sweeps [1] are off the repository before any agent is stopped, since these jobs commit and push and stopping their clock does not stop their turn; then the Discord group, Auto PM, the CI watch [5], the reclaim [2] sweep, the branch links, the cloud scratch sweep and cloud work adoption are stopped, the agent-starting ones with the rest, so nothing can start or steer an agent while the daemon stops the ones it owns.
diff --git a/packages/framework/src/daemon-services.test.LOGIC.md b/packages/framework/src/daemon-services.test.LOGIC.md
index a71a1dd3f..0b9365546 100644
--- a/packages/framework/src/daemon-services.test.LOGIC.md
+++ b/packages/framework/src/daemon-services.test.LOGIC.md
@@ -1,8 +1,7 @@
-What the tests cover, with the registry and the agent queue read off disk from a real `agent-data` branch and only the agent's process stubbed:
+What the tests cover, with a real registry and a real `agent-data` branch and only the daemon's own spawn stubbed:
 
-- **The concurrency setting is the size of a drain's fan-out** - with Auto PM on and the setting at four, the start-up sweep starts four agents, not the shipped default and not the queue's length; each is pinned to one open entry in queue order ("Work on this one open entry of the agent queue only"), started unattended, handed off at `merge` because the drain lands its own pull requests, not marked as a plan agent, and carries the ticket its entry links to, so four agents land in four lanes; the sweep's report says "started 4 agents"; the claim committed ahead of the first agent sits on the `agent-data` branch and names the agent id the agent is started with.
-- **"Run now" with the schedule off** - with Auto PM off the start-up sweep starts nothing; the drain's "Run now" then fans out to the setting, each agent pinned to its own entry in queue order.
-- **Retiring a drained entry** - once the agent's record says done with its handoff reported done, the entry is deleted from the queue as a commit on the `agent-data` branch ("queue done: <entry>"), while the untouched entries stay exactly as written; an agent whose handoff failed leaves its entry open for the next drain.
-- **A claim on a ticket whose file is gone** - a drain whose entry links to a ticket file no longer on the branch still claims and starts, recreating the `tickets/` directory for the claim, instead of standing the batch down as already claimed.
-- **The data-sync error** - a project whose `agent-data` branch has no remote carries a "data-sync" project error saying "no remote", also said on the daemon's log; once a remote exists and a sync converges, the error is gone rather than reworded.
-- **The quota gate is the model's week** - with most of the account's week left but the week of the model the agents would run on fully spent, the sweep starts nothing and its report names the window that stopped it ("Current week (Fable) is 100% used"); the same spent model week does not stop a batch on another model with allowance left, and those agents start on the model the gate was measured for.
+- **A move starts one agent on the queued work** - with Auto PM on and the rotation switched off, the start-up look starts nothing; a commit on the data branch written through the skills' plain funnel (someone queued an entry) starts exactly one agent, however high the concurrency, told `/work-queue` and nothing else, unattended, with its handoff at `merge`, no plan-agent mark and no pre-minted id; the report names the routine; the next look with nothing new starts nothing.
+- **The daemon's own commit is not a move** - a run's record written through the daemon's funnel starts nothing, and the report says the owed rotation turn has nothing to fire.
+- **"Run now" with the schedule off** - with Auto PM off the start-up look starts nothing; the queued work's "Run now" starts one agent on the queue without any move.
+- **The data-sync error** - a project whose data branch has no remote carries a `data-sync` error naming the missing remote, said on the daemon log too, and the error is gone the first time a sync converges after a remote is added.
+- **The quota gate is the model's week** - with most of the account's week left but the week of the model the agent would run on fully spent, a move starts nothing and the report names the window that stopped it ("Current week (Fable) is 100% used"); the same spent model week does not stop the run on another model with allowance left, which starts on that model.
diff --git a/packages/framework/src/daemon-workspace.test.LOGIC.md b/packages/framework/src/daemon-workspace.test.LOGIC.md
index 43d5605b9..1c431c150 100644
--- a/packages/framework/src/daemon-workspace.test.LOGIC.md
+++ b/packages/framework/src/daemon-workspace.test.LOGIC.md
@@ -8,4 +8,4 @@ What the tests cover, starting agents through the runtime against real git repos
 - **What counts as a transient death** - a connection closed mid-response, a reset connection and an overloaded API count as transient; a boot death, an assertion failure and an absent detail do not; the detail is read from the agent's own final end event and only from a failed one, skipping malformed lines, with an empty stream yielding none and a later successful end canceling an earlier failure.
 - **Retrying a transient death** - an agent that dies to a transient error is continued as the same agent in its retained checkout, at most twice, after which it stays failed; an agent that fails on its own terms is not retried.
 - **Preflight before anything is spent** - a start on a logged-out coding agent is refused with the fix named ("not logged in", "auth login") and creates no checkout, no branch and no process; an `actions` agent is not probed at all; a passing preflight is probed once for a burst of starts; a failing one is probed again on every start, so logging in is picked up by the very next start.
-- **What a spawned agent finds** - the `branches`, `tickets`, `queue` and `logs` commands come first on its PATH, in that order, ahead of the daemon's own; `branches list` run by name from the project reports exactly the checkout the daemon allocated; the four skills are linked into the checkout wherever a coding agent's harness looks for skills, each link pointing at the package holding its `SKILL.md`.
+- **What a spawned agent finds** - its PATH is the daemon's own, with nothing added: a skill's command resolves from the project's dependencies; its checkout links exactly two skills wherever a coding agent's harness looks, the `branches` skill and the daemon's routine skill `work-queue`, each pointing at the directory holding its `SKILL.md`.
diff --git a/packages/framework/src/daemon-writes.LOGIC.md b/packages/framework/src/daemon-writes.LOGIC.md
new file mode 100644
index 000000000..d6b5615d6
--- /dev/null
+++ b/packages/framework/src/daemon-writes.LOGIC.md
@@ -0,0 +1,43 @@
+Tells the daemon's own commits on the `agent-data` branch [1] apart from everyone else's, so the daemon can react to a move of the branch without reacting to itself, and two daemons sharing a branch cannot fire at each other. Every automatic write the daemon makes goes through one funnel that signs the commit; the trigger counts only the commits without the signature.
+
+## Context
+
+**User story**: someone queues a task on another machine; within a minute this machine's daemon starts an agent on it. The agent's run ends and the daemon records it on the same branch; nothing starts because of that record, here or on the other machine.
+
+**Problem**: the daemon starts a run when the branch moved by a commit it did not write itself (the rules in `auto-pm.ts`). Its own commits — a run's record at teardown, a routine lock [2], a claim [3] minted for a plan agent — look like anyone else's, and the branch is shared with other machines' daemons, whose records look the same. Without a mark, every record would start the next run, forever, and two daemons would fire empty runs at each other's records without end.
+
+## Glossary
+
+[1] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
+[2] routine lock: a file on the `agent-data` branch (`routines/<name>.lock.md`) a daemon takes before running a routine so the routine runs once across machines.
+[3] claim: a ticket's lock file naming the holder working it, so two agents never work the same ticket.
+[4] a move: a commit on the `agent-data` branch that no daemon wrote — a person queuing an entry, an agent claiming, closing or marking done.
+[5] trailer: a `Key: value` line at the end of a git commit message, after a blank line, which git reads back by key.
+
+## Business logic — TL;DR
+
+- **The daemon's funnel signs its commits** - every write the daemon makes on its own goes through the persistent checkout's write cycle with `Daemon: <machine name>` as the commit message's last line, a trailer [5]; a person's write from the dashboard takes the skills' plain funnel and carries none.
+- **The head of the branch** - the local head of the project's `agent-data` branch, or nothing when the branch does not exist yet.
+- **Counting the moves** - between two heads, the commits whose message carries no `Daemon:` trailer are the moves [4]; a range git cannot walk counts as none, and the daily heartbeat is the belt for it.
+
+## Business logic
+
+### The daemon's funnel signs its commits
+
+#### Context
+
+See `## Context`.
+
+#### Business logic
+
+The funnel is the persistent checkout's serialized write cycle on the `agent-data` branch [1] (the shared branch library's): sync with the remote, apply the change, commit, push. What this module adds is the message: the caller's message, a blank line, then `Daemon: <machine name>`, the machine being this host's name. Every skill library the daemon writes through accepts a caller's funnel, and the daemon hands this one to each automatic write: the run's record at teardown and the surrogate end at boot (`daemon-runtime.ts`, `daemon.ts`), the routine locks and the plan claims and their releases (`daemon-services.ts`), and the patch of a run's card when a cloud session's branch is adopted. A write a person makes from the dashboard — queue an entry, release a claim, delete a run — takes the skill's own funnel and carries no trailer: a person asking for work is exactly what should start a run.
+
+### The head of the branch, and counting the moves
+
+#### Context
+
+**Problem**: the daemon must read two things off git and nothing else about the branch: where it stands, and whether it moved by someone else's hand.
+
+#### Business logic
+
+The head is the project's local `agent-data` branch ref; a repository without the branch has no head, which the sweep reports as a branch it cannot read. Between two heads, the commits in the newer's history but not the older's are listed with the value of their `Daemon:` trailer [5]; a commit with no such trailer is a move [4], and the count of those is what the sweep acts on. A word `Daemon` in the body of a message is not a trailer and does not count. When git cannot walk the range — the older head was rebased away after a push the daemon could not land — the count is zero, and the daily heartbeat is the belt.
diff --git a/packages/framework/src/daemon-writes.test.LOGIC.md b/packages/framework/src/daemon-writes.test.LOGIC.md
new file mode 100644
index 000000000..7cc090e9f
--- /dev/null
+++ b/packages/framework/src/daemon-writes.test.LOGIC.md
@@ -0,0 +1,5 @@
+What the tests cover, with real git:
+
+- **No branch, no head** - a repository without an `agent-data` branch has no head to read.
+- **Signed commits do not count as moves** - a plain write (someone queued work) moves the branch; a write through the daemon's funnel lands as a commit whose message ends in a blank line and `Daemon: <host>`, and counts as no move; an unsigned write after it counts as one, over either range; a message that merely mentions the word in prose is not a trailer and counts as a move.
+- **A range git cannot walk** - counts as no move.
diff --git a/packages/framework/src/daemon.LOGIC.md b/packages/framework/src/daemon.LOGIC.md
index cc1c92212..8175efbbe 100644
--- a/packages/framework/src/daemon.LOGIC.md
+++ b/packages/framework/src/daemon.LOGIC.md
@@ -15,12 +15,12 @@ Runs The Framework's one daemon per machine, in the foreground: it binds the das
 [5] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [6] control file: `.the-framework/control.jsonl`: the file the daemon appends steering to (stops, picks, chat messages) and the agent's process tails.
 [7] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
-[8] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[8] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [9] relay: running an agent on a device: the local daemon forwards the start, streams the events back and forwards steering, so the agent renders like a local one.
 [10] device: another machine's daemon the user saved by URL and token, to run agents on it from this dashboard.
 [11] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent.
 [12] pick: the answer to a gate: the option or options chosen, by the user or automatically.
-[13] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[13] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [14] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
 [15] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [16] spend offset: the user's adjustment of the quota boundary, in percentage points of the week.
@@ -70,7 +70,7 @@ The directory the daemon is started in is its home project. Its `.the-framework/
 
 #### Business logic
 
-At boot, across every registered project, each agent whose run [13] or archive [14] says running while its process is provably gone, or whose record names no process to check, is given a surrogate end: the agent is marked stopped with the detail "its process died without reporting an end", and the gate it died holding expires with it. The end is written to the run on the `agent-data` branch [15] and to the archive, each best-effort. An agent whose process is alive on this machine is left alone, because a second daemon may be driving it. The number repaired is logged per project as "[framework] reconciled N orphaned agent(s) in <project>". Then every agent browser nobody owns any more, a Chrome running on the throwaway profile agents use whose parent process is no longer an agent, is ended and its profile removed, and the process ids are logged as "[framework] closed N orphaned agent browser(s): pid …"; this does nothing on Windows. The exact liveness and ownership rules are in `store/agent-store.ts` and `browser.ts`. Each repair is best-effort and a failure is silent.
+At boot, across every registered project, each agent whose run [13] or archive [14] says running while its process is provably gone, or whose record names no process to check, is given a surrogate end: the agent is marked stopped with the detail "its process died without reporting an end", and the gate it died holding expires with it. The end is written to the run on the `agent-data` branch [15], as a commit signed with the daemon's trailer (`daemon-writes.ts`) so the daemon's own sweep does not read it as work, and to the archive, each best-effort. An agent whose process is alive on this machine is left alone, because a second daemon may be driving it. The number repaired is logged per project as "[framework] reconciled N orphaned agent(s) in <project>". Then every agent browser nobody owns any more, a Chrome running on the throwaway profile agents use whose parent process is no longer an agent, is ended and its profile removed, and the process ids are logged as "[framework] closed N orphaned agent browser(s): pid …"; this does nothing on Windows. The exact liveness and ownership rules are in `store/agent-store.ts` and `browser.ts`. Each repair is best-effort and a failure is silent.
 
 ### Nothing is resumed at boot
 
diff --git a/packages/framework/src/daemon.test.LOGIC.md b/packages/framework/src/daemon.test.LOGIC.md
index c61d18087..1c0755ee4 100644
--- a/packages/framework/src/daemon.test.LOGIC.md
+++ b/packages/framework/src/daemon.test.LOGIC.md
@@ -9,5 +9,6 @@ What the tests cover, against a real daemon bound to a free port and, where git
 - **What the spec carries** - a `research` start travels as its kind with its prompt; an empty prompt travels empty for the agent's process to default; a `prompt` start carries the prompt verbatim, never re-rendered.
 - **The fork-bomb guard** - a start whose entry script would be a test file is refused, with "test entry" named in the error.
 - **Steering through the control file** - a stop and a pick sent from the dashboard land in the project's `.the-framework/control.jsonl` as one entry each, the pick carrying the gate's id, the option chosen and who chose.
+- **The run's record is signed** - the record the teardown writes on the `agent-data` branch ends its commit message with the daemon's `Daemon:` trailer.
 - **Nesting** - a path counts as nested only when strictly inside another: not when equal, not the parent, not a sibling tree, not a name that merely shares a prefix.
 - **Registering the home project** - an activated directory nested inside a project already registered is not added as a second project; an activated directory that is not nested is added.
diff --git a/packages/framework/src/dashboard-rpc/context.LOGIC.md b/packages/framework/src/dashboard-rpc/context.LOGIC.md
index 0d2069540..66b8a2652 100644
--- a/packages/framework/src/dashboard-rpc/context.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/context.LOGIC.md
@@ -10,7 +10,7 @@ Gives every call the dashboard makes the daemon's own capabilities, wired once w
 [2] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [3] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
 [4] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
-[5] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[5] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [6] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
 [7] the Claude web bridge: the daemon's bridge endpoints plus the Chrome extension: carries the question a cloud session is parked on into the dashboard, and types the pick back into the session. The bridge browser is the Chrome for Testing the daemon runs for it.
 [8] relay: running an agent on a device: the local daemon forwards the start, streams the events back and forwards steering, so the agent renders like a local one.
diff --git a/packages/framework/src/dashboard-rpc/control.LOGIC.md b/packages/framework/src/dashboard-rpc/control.LOGIC.md
index ad86e0b48..e259b1787 100644
--- a/packages/framework/src/dashboard-rpc/control.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/control.LOGIC.md
@@ -28,12 +28,12 @@ Carries out every action the user takes on an agent [1] or a project from the da
 [18] driver session: the coding agent's own conversation for one agent, which the driver can resume by its session id.
 [19] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [20] build agent / prompt agent: the two kinds of agent: a build works the agent queue after its opening exchange; a prompt agent runs one prompt and stops there.
-[21] preset: a canned prompt the user launches from the dashboard; the drain preset is the one that works the agent queue's first open entry.
-[22] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[21] preset: a canned prompt the user launches from the dashboard.
+[22] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [23] the Overview: the dashboard's cross-project page at `/`.
 [24] location: where an agent's turns run: `local` (this machine), `actions` (a GitHub Actions runner), or `web` (a Claude Code cloud session).
 [25] vanilla: an agent started without the built-in system prompt but with the signal protocols kept. transparent: an agent started with nothing of The Framework's — the raw coding agent.
-[26] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[26] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [27] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [28] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
 [29] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
@@ -45,7 +45,7 @@ Carries out every action the user takes on an agent [1] or a project from the da
 - **Steering lands in the agent's own control file** - every stop, pick, message, handoff change and merge authorization is one line appended to the control file of the checkout the agent id resolves to; when the project is unknown here nothing is written.
 - **The steering entries and what each validates** - a stop needs nothing; a pick carries the gate's id, the option or options, and who picked; a message is trimmed and an empty one is dropped; a handoff change must name one of the four rungs or it is ignored.
 - **Answering the question a cloud session is parked on** - the pick is queued for the bridge's extension to type into the session, accepted only as labels of the question actually parked, and can be withdrawn until it is collected.
-- **Starting an agent** - a build or prompt agent needs a non-empty prompt, a research agent may have none; a hand-fired drain is tagged with the ticket it is about to work; the daemon's own start decides the rest and reports busy when it must.
+- **Starting an agent** - a build or prompt agent needs a non-empty prompt, a research agent may have none; the daemon's own start decides the rest and reports busy when it must.
 - **Removing a retained checkout** - refused while the agent is still going, for an unsafe id, for a checkout that is not there, and whenever the work is not yet on the remote; a clean checkout is pushed first and then removed.
 - **Deleting an agent** - refused while the agent is still going; the checkout goes with whatever it holds, the agent's records go, and its branch stays.
 - **Opening a checkout in the file manager or an editor** - a local command against the agent's own checkout, or the project's; the editor is the one the preferences name, else the environment's, else VS Code.
@@ -99,13 +99,13 @@ The pick is not a control-file write: it goes to the bridge's store of parked qu
 
 **User story**: the user fills the launcher and presses Start. The launcher's options travel with the start, the daemon spawns the agent, and the browser selects the agent it just started.
 
-**Problem**: the daemon's start is the one place that may spawn an agent, because it keeps the guard that refuses to start the same work twice; every start from the dashboard has to go through it. And a drain [22] fired by hand is the same work the daemon's own drain does, so it must say the same thing about itself: which ticket it is about to implement, so the Overview [23] shows that ticket as being worked rather than a lane staying empty.
+**Problem**: the daemon's start is the one place that may spawn an agent, because it keeps the guard that refuses to start the same work twice; every start from the dashboard has to go through it.
 
 #### Business logic
 
 The kind is a build agent [20] by default, a prompt agent, or a research agent. A build or a prompt agent needs a non-empty prompt after trimming ("a non-empty prompt is required"); a research agent may be started with none, its subject defaulting on the daemon's side. The options travel through untouched to the daemon's start, where their meaning is fixed (`dashboard/types.ts`): vanilla [25] or transparent, in-context directories, the on-before-mergeable follow-ups, a real browser for the agent, the handoff [4] level, the model, the driver, the location [24], unattended [19], a pre-minted agent id, the ticket it implements and whether it only plans it, the driver session [18] to resume, the agent to continue, and the device [12] to run on. The device's URL and token are memory-only relay configuration: never persisted, never a CLI flag, and stripped before the device starts the agent so it never relays onward.
 
-One thing is resolved here rather than trusted from the browser: the ticket. When the caller names a ticket it is kept. Otherwise, when the prompt is exactly the drain preset's [21] prompt, the ticket the agent queue's [7] first open entry links to becomes the agent's ticket; any other prompt, however busy the queue, gets none, since naming the queue's next entry would show a ticket as being implemented by an agent doing something else. A queue that cannot be read yields no ticket. The daemon's start answers: started, with the agent id when the agent got its own checkout; busy, when the same work is already active; or an error saying why.
+Nothing is resolved here beyond the trimmed prompt: the options travel as the browser sent them. The daemon's start answers: started, with the agent id when the agent got its own checkout; busy, when the same work is already active; or an error saying why.
 
 ### Removing a retained checkout
 
diff --git a/packages/framework/src/dashboard-rpc/control.test.LOGIC.md b/packages/framework/src/dashboard-rpc/control.test.LOGIC.md
index b03fd34eb..ddef5690a 100644
--- a/packages/framework/src/dashboard-rpc/control.test.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/control.test.LOGIC.md
@@ -1,4 +1,3 @@
 What the tests cover, against a real git repository whose tickets and agent queue sit on the `agent-data` branch, registered as a project in a throwaway registry:
 
-- **A drain started from the dashboard names its ticket** - starting an agent with exactly the drain preset's prompt tags the start with the ticket the agent queue's first open entry links to; any other prompt starts with no ticket however busy the queue is; a ticket named by the caller is kept rather than replaced by the guess.
 - **Releasing a ticket's claim** - the lock file is removed as a commit on the `agent-data` branch while the ticket itself stays; a ticket holding no claim answers "this ticket holds no lock"; anything but a bare ticket filename is refused with "not a ticket filename" before any project is resolved: a path with a parent segment, a nested path, the ticket's own `.lock.md` or `.plan.md` sibling, and a name that is not `.md`.
diff --git a/packages/framework/src/dashboard-rpc/events.LOGIC.md b/packages/framework/src/dashboard-rpc/events.LOGIC.md
index 8bf8d56c3..6ee7fb81a 100644
--- a/packages/framework/src/dashboard-rpc/events.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/events.LOGIC.md
@@ -14,7 +14,7 @@ Serves the live event stream [1] for one selected agent [2] to the browser: ever
 [4] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [5] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
 [6] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
-[7] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[7] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [8] device: another machine's daemon the user saved by URL and token, to run agents on it from this dashboard.
 [9] end-of-replay marker: the one wire-only event the stream sends after the events already on disk have been delivered and before any live event; it is not an agent event, is never written to any file, and the browser swallows it.
 
diff --git a/packages/framework/src/dashboard-rpc/preferences.LOGIC.md b/packages/framework/src/dashboard-rpc/preferences.LOGIC.md
index f9ca7ea65..dd8f7f828 100644
--- a/packages/framework/src/dashboard-rpc/preferences.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/preferences.LOGIC.md
@@ -13,7 +13,7 @@ The Settings surface of the dashboard's calls: reading and saving the user's pre
 [3] Settings: the settings page.
 [4] driver: a coding agent wrapped as a black box: start it in a directory, prompt it for one turn, stream what it does, resume it later. The user's driver choice is `claude` or `codex`; the driver implementations are `claude-code`, `codex`, `github-actions`, `claude-web` and `fake`.
 [5] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it). "Handoff level" is a rung of that ladder.
-[6] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[6] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [7] spend offset: the user's adjustment of the quota boundary, in percentage points of the week.
 [8] registry: `~/.the-framework.json`: where the user's preferences are kept, and which also lists the projects.
 [9] location: where an agent's turns run: `local` (this machine), `actions` (a GitHub Actions runner), or `web` (a Claude Code cloud session).
diff --git a/packages/framework/src/dashboard-rpc/quota.LOGIC.md b/packages/framework/src/dashboard-rpc/quota.LOGIC.md
index 0d11be43b..d38bd24d7 100644
--- a/packages/framework/src/dashboard-rpc/quota.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/quota.LOGIC.md
@@ -8,14 +8,14 @@ The three things the dashboard's usage panel asks the daemon: where the account'
 
 [1] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [2] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
-[3] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[3] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [4] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
 [5] tick: one beat of the daemon's single background clock; each sweep says how many ticks it waits between turns.
 [6] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [7] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
 [8] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
-[9] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
-[10] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[9] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
+[10] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [11] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
 [12] ticket: a markdown file under `tickets/` on the `agent-data` branch, with an optional plan and claim.
 [13] routine lock: a file on the `agent-data` branch a daemon takes before running a routine so the routine runs once across machines.
@@ -81,10 +81,10 @@ The daemon runs one sweep [4] immediately. It runs whether or not Auto PM [3] is
 
 The answer waits for the sweep to finish and carries what it decided, one line per project [15], so the panel can state the outcome without a poll having to race the sweep. A sweep that failed outright answers that it did not succeed. A sweep that ran but whose decisions could not be read back answers as a success with no lines.
 
-The request can narrow what the sweep does, which is what a "Run now" that fans out [11] means:
+The request can narrow what the sweep does, which is what a "Run now" on a routine's row means:
 
-- draining [9]: agents [7] are started on the agent queue's [8] entries. When the queue is empty this is reported as having nothing to work, rather than the click being borrowed for some other routine's [10] work nobody asked for.
+- the queued work [9]: one agent [7] is started on the agent queue [8] in every project, whether or not the branch moved; a run that finds nothing queued spends one run finding that out, which is what the click asked for.
 - planning: agents are started on the open tickets [12] to plan, through the same claim-then-start path the scheduled routine takes, so the fan-out [11] respects the same limits and claims.
-- one named routine [10], identified by the routine lock [13] it takes: a single agent, started by the sweep so the lock that guards it is taken the same way a scheduled firing takes it, and started from a fresh copy of its branch.
+- one named routine [10], identified by the routine lock [13] it takes: a single agent, started by the sweep so the lock that guards it is taken the same way a scheduled firing takes it.
 
 The request can also be scoped to a single project [15], which is what the panel's own project selection means.
diff --git a/packages/framework/src/dashboard-rpc/quota.test.LOGIC.md b/packages/framework/src/dashboard-rpc/quota.test.LOGIC.md
index a0b4bf08e..03a2c3c25 100644
--- a/packages/framework/src/dashboard-rpc/quota.test.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/quota.test.LOGIC.md
@@ -3,12 +3,12 @@ What the tests cover, for the usage panel's "Run now":
 - **The sweep is waited for, not fired and forgotten** - the request returns only once the sweep [1] has actually run, and answers with the lines that sweep decided, one per project [2], so the panel can show the outcome instead of flashing and saying nothing.
 - **The decisions survive the wait** - the lines the answer carries are the ones the sweep just decided, even when what the daemon exposes changes while the sweep is in flight.
 - **A failed sweep and an unreadable report are different answers** - a sweep that fails outright is answered as a failure; a sweep that ran but whose decisions cannot be read back is answered as a success with no lines, so the panel can say the sweep ran rather than pretend nothing happened.
-- **The narrowing reaches the sweep unchanged** - draining [3], planning, a single routine [4] named by the routine lock [5] it takes, a scope of one project [2], and no narrowing at all are each passed through exactly as asked for.
+- **The narrowing reaches the sweep unchanged** - the queued work [3], planning, a single routine [4] named by the routine lock [5] it takes, a scope of one project [2], and no narrowing at all are each passed through exactly as asked for.
 
 ## Glossary
 
-[1] sweep: a background job the daemon runs on its clock; here, Auto PM's — drain the agent queue, and refill it by running the routines.
+[1] sweep: a background job the daemon runs on its clock; here, Auto PM's — work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [2] project: a repository the user registered in the dashboard, identified by an id derived from its path.
-[3] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[3] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [4] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance.
 [5] routine lock: a file on the `agent-data` branch a daemon takes before running a routine so the routine runs once across machines.
diff --git a/packages/framework/src/dashboard-rpc/reads.LOGIC.md b/packages/framework/src/dashboard-rpc/reads.LOGIC.md
index e8713ad9d..77759d5e7 100644
--- a/packages/framework/src/dashboard-rpc/reads.LOGIC.md
+++ b/packages/framework/src/dashboard-rpc/reads.LOGIC.md
@@ -16,7 +16,7 @@ Answers everything the dashboard reads about a project or an agent [1]: the agen
 [6] relay: running an agent on a device: the local daemon forwards the start, streams the events back and forwards steering, so the agent renders like a local one.
 [7] device: another machine's daemon the user saved by URL and token, to run agents on it from this dashboard.
 [8] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
-[9] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[9] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [10] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
 [11] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [12] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
@@ -27,7 +27,7 @@ Answers everything the dashboard reads about a project or an agent [1]: the agen
 [17] intervention: something that needs a human — an open question, a pull request to review, unpushed commits — one of the two notification feeds. The other is activity: an agent started or finished.
 [18] open question: a gate nobody has answered yet, as the dashboard lists them across projects.
 [19] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent.
-[20] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[20] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [21] the built-in system prompt: the standing instructions every agent starts with (`prompts/system_prompt.md`); `SYSTEM.md` is the project's own instructions added on top.
 [22] pick: the answer to a gate: the option or options chosen, by the user or automatically.
 [23] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
diff --git a/packages/framework/src/dashboard/agent-handoff.LOGIC.md b/packages/framework/src/dashboard/agent-handoff.LOGIC.md
index 4a70168a9..650fd550e 100644
--- a/packages/framework/src/dashboard/agent-handoff.LOGIC.md
+++ b/packages/framework/src/dashboard/agent-handoff.LOGIC.md
@@ -21,7 +21,7 @@ Decides what becomes of an agent's [1] work once the agent has ended, its handof
 [9] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
 [10] hands-off: said of an agent whose work leaves this machine, so its first prompt is the whole agent: an agent whose location is `web`.
 [11] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
-[12] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[12] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [13] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 [14] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
 [15] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
@@ -46,7 +46,7 @@ Decides what becomes of an agent's [1] work once the agent has ended, its handof
 - **The "Open PR" button** - the agent's existing pull request first, even for a gone branch, unless the agent moved past it; a gone branch and an empty branch are refused with a reason; otherwise a pull request ready for review.
 - **A pull request for a branch only the remote has** - a cloud session's own branch gets a draft pull request with nothing pushed and `gh`'s default base.
 - **The "Merge" button on a finished agent** - refused when the agent has no pull request or it is no longer open; otherwise merged, a draft marked ready on the way, directly where GitHub cannot arm auto-merge.
-- **The pull request's title** - the agent's own title, else its session name, else "Session <agent id>", with the ticket's issue reference as "(fix #42)"; never the prompt.
+- **The pull request's title** - the agent's own title, else its session name, else "Session <agent id>", with an issue reference as "(fix #42)" when the caller names one; never the prompt.
 - **The pull request's body** - the agent's own description, else what was asked for, then which agent did it.
 - **What a handoff reports** - a button answers with success (and the pull request's URL and number) or one error line; the automatic handoff answers skipped with its reason, done, or failed at the push or the pull request step, and the number rides along so it gets recorded on the agent.
 
@@ -141,7 +141,7 @@ The push and the pull request start armed, so the common case costs nothing: an
 
 #### Business logic
 
-An armed merge may run only when the agent [1] emitted the ready-for-merge [4] signal and its own TODO file, `TODO_<session name [13]>.agent.md` in its checkout [3], has no open entries. The first condition that fails is the recorded reason: the agent never declared ready for merge (`not-ready-for-merge`), else its own TODO file still has open entries (`session-todo-open`). The agent queue [14] (`TODO_AGENTS.md`) never withholds a merge: it is decoupled from agents, and withholding on it would mean no merge ever runs while the project has a backlog at all. A withheld merge is not a failed handoff: the push and the pull request go ahead, and the pull request opens as a draft for a human. The user's "Merge" on a running agent bypasses this gate: the authorization the gate exists to collect has been given directly (`../cli.ts`, `../dashboard-rpc/control.ts`).
+An armed merge may run only when the agent [1] emitted the ready-for-merge [4] signal; the agent's word is enough. The recorded reason for withholding is `not-ready-for-merge`. A withheld merge is not a failed handoff: the push and the pull request go ahead, the pull request just opens as a draft for a human.
 
 ### The automatic handoff when an agent ends
 
diff --git a/packages/framework/src/dashboard/agent-handoff.test.LOGIC.md b/packages/framework/src/dashboard/agent-handoff.test.LOGIC.md
index 74c80e53d..d6be4ac03 100644
--- a/packages/framework/src/dashboard/agent-handoff.test.LOGIC.md
+++ b/packages/framework/src/dashboard/agent-handoff.test.LOGIC.md
@@ -10,6 +10,6 @@ What the tests cover, partly against a real git repository:
 - **The merge half** - an armed merge follows the pull request it just opened: the pull request opens ready rather than draft, GitHub's auto-merge is armed with a squash, and the outcome is done with the merge reported as armed; without the merge armed no merge is attempted; a merge that fails is reported as a failed merge on a handoff that still succeeded; an armed merge takes the already-open pull request a predecessor left, reporting the skip and the merge together.
 - **Which pull request is the agent's** - an open pull request counts whatever its age; a predecessor's merged pull request never does; among the pull requests created after the agent started, the oldest answers identity and the latest answers the handoff decision; without a start time only an open pull request is trusted; a gone branch still reports its pull request.
 - **The pull request the agent recorded** - the recorded pull request is the answer and only its state is read live, for that one branch; an agent that recorded none gets nothing and costs no `gh` read; a record the live read cannot confirm still answers with its number and URL and an unknown state; a different pull request on the branch is not the agent's answer.
-- **Configuration arms the merge, the agent authorizes it** - without the ready-for-merge signal the merge is withheld as not ready, whatever the TODO file says; with the signal but open entries in the agent's own TODO file it is withheld for that reason; with the signal and an empty TODO file it may run.
-- **The pull request's title** - an agent implementing a ticket carries the issue reference as "(fix #42)" after its session name; the agent's own title wins over the session name; an agent that named nothing is titled "Session <agent id>" and never with the prompt it was given, with the issue reference still appended.
+- **Withholding a merge** - an armed merge is withheld only when the agent never signalled ready for merge; declared done, it may run.
+- **The pull request's title** - an agent whose caller names an issue carries the reference as "(fix #42)" after its session name; the agent's own title wins over the session name; an agent that named nothing is titled "Session <agent id>" and never with the prompt it was given, with the issue reference still appended.
 - **The "Merge" button on a finished agent** - the agent's open pull request is merged through GitHub's auto-merge with a squash and the result carries the pull request's URL and number; an agent with no pull request is refused with "this session has no pull request to merge" and one whose pull request already landed with "this session's PR is already merged"; a merge the remote refuses comes back as that error, not as a success.
diff --git a/packages/framework/src/dashboard/docs.LOGIC.md b/packages/framework/src/dashboard/docs.LOGIC.md
index 7c5c14f26..48e1eb3eb 100644
--- a/packages/framework/src/dashboard/docs.LOGIC.md
+++ b/packages/framework/src/dashboard/docs.LOGIC.md
@@ -11,7 +11,7 @@ Decides which `PLAN` and `TODO` documents the dashboard's sidebar shows beside a
 [3] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [4] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch. The user's own working copy is the project's checkout.
 [5] the built-in system prompt: the standing instructions every agent starts with (`prompts/system_prompt.md`).
-[6] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
+[6] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command run as `npx <skill>`, and an API the product calls.
 [7] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 
 ## Business logic — TL;DR
diff --git a/packages/framework/src/dashboard/gh.LOGIC.md b/packages/framework/src/dashboard/gh.LOGIC.md
index 77b535f2a..cd20e364f 100644
--- a/packages/framework/src/dashboard/gh.LOGIC.md
+++ b/packages/framework/src/dashboard/gh.LOGIC.md
@@ -15,7 +15,7 @@ Every fact the daemon reads from GitHub, and the one thing it writes there, goes
 [5] launcher: the Start form on project home, a project's own page.
 [6] location: where an agent's turns run: `local` (this machine), `actions` (a GitHub Actions runner), or `web` (a Claude Code cloud session).
 [7] CI watch: the sweep that merges the pull requests The Framework opened once their checks pass, and starts a fix agent when a check goes red.
-[8] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[8] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [9] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [10] intervention: something that needs a human — an open question, a pull request to review, unpushed commits — one of the two notification feeds.
 
diff --git a/packages/framework/src/dashboard/git-status.LOGIC.md b/packages/framework/src/dashboard/git-status.LOGIC.md
index 2c779bbbf..f00f5eed8 100644
--- a/packages/framework/src/dashboard/git-status.LOGIC.md
+++ b/packages/framework/src/dashboard/git-status.LOGIC.md
@@ -8,7 +8,7 @@ Reads the git status bar of a project or of an agent's [1] checkout [2]: the cur
 [4] relay: running an agent on a device: the local daemon forwards the start, streams the events back and forwards steering, so the agent renders like a local one.
 [5] project home: a project's own page with the launcher (the Start form) and its composer (the prompt editor, also used for live chat).
 [6] agent view: one agent's page.
-[7] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[7] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 
 ## Business logic — TL;DR
 
diff --git a/packages/framework/src/dashboard/overview.LOGIC.md b/packages/framework/src/dashboard/overview.LOGIC.md
index 9b5210377..1c11ee7db 100644
--- a/packages/framework/src/dashboard/overview.LOGIC.md
+++ b/packages/framework/src/dashboard/overview.LOGIC.md
@@ -18,7 +18,7 @@ Builds the data behind the dashboard's cross-project Overview [1] and its shared
 [8] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 [9] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
 [10] the Claude web bridge (the bridge): the daemon's bridge endpoints plus the Chrome extension: carries the question a cloud session is parked on into the dashboard, and types the pick back into the session.
-[11] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[11] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [12] plan: a ticket's `.plan.md`: effort and uncertainty ratings and how to implement it.
 
 ## Business logic — TL;DR
@@ -87,15 +87,15 @@ Every project's agents, archive [9] included, are pooled and ordered by their st
 
 #### Context
 
-**User story**: the Overview's [1] hot-tickets card is a shortlist, not the whole backlog: what is being worked on right now, what The Framework will pick up on its own, and what a human would likely queue next. A ticket being coded at this moment links to the agent [2] coding it.
+**User story**: the Overview's [1] hot-tickets card is a shortlist, not the whole backlog: what is being worked on, what The Framework will pick up on its own, and what a human would likely queue next.
 
-**Problem**: a ticket's plan [12] says that someone planned it at some point, not that it is being coded as the user looks. Only an agent's own record tells the two apart, and an agent records the ticket it implements only when the daemon started it on a queue entry (a drain [11]), so tickets worked by hand still count through their plan.
+**Problem**: a ticket's plan [12] says that someone planned it at some point. Which ticket an agent is implementing right now is the ticket's own claim to say; The Framework no longer records it on the run, and the lane that read it will come back from the claim.
 
 #### Business logic
 
 Every project's tickets are read (`tickets.ts`) and each ticket is placed in the first lane that applies, or left off the card when none does:
 
-- **in progress**: a running agent of the same project recorded this ticket as the one it is implementing, in which case the row carries that agent's id for the card to link into; or, failing that, the ticket has a plan [12]. An agent that has ended is not implementing anything, however recently it stopped.
+- **in progress**: the ticket has a plan [12].
 - **on the agent queue** (the card's "AI Queue" lane): an open entry of the project's agent queue [3] begins with a markdown link, and that link points at this ticket's file under `tickets/`. A link elsewhere in the entry does not count, and neither does a link to something other than a ticket. A finished entry does not count.
 - **high priority**: the ticket's `Priority:` reads 7 or more on the ticket format's 10-to-0 scale, where 10 is critical and 0 is only-if-capacity. Word spellings such as `high`, `urgent`, `p0` or `p1` are not on that scale and never qualify.
 
diff --git a/packages/framework/src/dashboard/overview.test.LOGIC.md b/packages/framework/src/dashboard/overview.test.LOGIC.md
index 7175b1220..f26cbc1f6 100644
--- a/packages/framework/src/dashboard/overview.test.LOGIC.md
+++ b/packages/framework/src/dashboard/overview.test.LOGIC.md
@@ -4,6 +4,6 @@ What the tests cover:
 - **Web agents whose cloud side is still at work** - a web agent whose local half is over is listed as "in-cloud" while it has no pull request and started within the last 12 hours, and as "waiting" when the bridge holds a question for its cloud session; one with a pull request, one started more than 12 hours ago, and a stopped one are not listed; such a row is keyed to the project's own path; two projects sharing one archive list each such agent once.
 - **Open queue entries and recent projects** - the open entries of every project's agent queue are added into one number; recent projects are newest first and capped at 5; a project with no activity is left out.
 - **Recent agents across projects** - every project's agents are pooled newest first, each tagged with its project; a project whose agents cannot be read contributes nothing; an agent whose record two projects share is listed once, under the first project.
-- **A ticket's lane** - a planned ticket is in progress; a queued ticket is on the agent queue, which outranks a bare priority flag; work under way outranks a queued ticket; a ticket in no lane is dropped; on the 10-to-0 scale, `7` through `10` read as high priority and `0` through `6` do not; word spellings (`high`, `urgent`, `p0`, `p1`) never qualify; a ticket a running agent is implementing is in progress whatever its plan or priority says, and without that evidence the plan still decides.
-- **Hot tickets pooled across projects** - every project's tickets are pooled, placed in their lane, the rest dropped, and ordered lane first; a queue entry whose leading link names the ticket file puts it on the agent queue lane; the ticket a running agent recorded is in progress and carries that agent's id; an ended agent counts for nothing, so its ticket sits on the queue lane by its link alone; another project's agent never lights up a same-named ticket; a project whose tickets cannot be read contributes nothing.
+- **A ticket's lane** - a planned ticket is in progress, which outranks a queued ticket; a queued ticket is on the agent queue, which outranks a bare priority flag; a ticket in no lane is dropped; on the 10-to-0 scale, `7` through `10` read as high priority and `0` through `6` do not; word spellings (`high`, `urgent`, `p0`, `p1`) never qualify; a ticket a running agent is implementing is in progress whatever its plan or priority says, and without that evidence the plan still decides.
+- **Hot tickets pooled across projects** - every project's tickets are pooled, placed in their lane, the rest dropped, and ordered lane first; a queue entry whose leading link names the ticket file puts it on the agent queue lane.
 - **Every project's tickets** - one list per project in registry order; a project with no tickets is kept with an empty list; a project whose tickets cannot be read is kept with an empty list.
diff --git a/packages/framework/src/dashboard/queue.LOGIC.md b/packages/framework/src/dashboard/queue.LOGIC.md
index d42086b24..37e81bc33 100644
--- a/packages/framework/src/dashboard/queue.LOGIC.md
+++ b/packages/framework/src/dashboard/queue.LOGIC.md
@@ -9,8 +9,8 @@ Rolls the agent queue [1] of every project up into the dashboard's cross-project
 ## Glossary
 
 [1] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
-[2] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
-[3] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[2] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
+[3] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 
 ## Business logic — TL;DR
 
diff --git a/packages/framework/src/dashboard/quota.LOGIC.md b/packages/framework/src/dashboard/quota.LOGIC.md
index cc012168c..0bb66bc11 100644
--- a/packages/framework/src/dashboard/quota.LOGIC.md
+++ b/packages/framework/src/dashboard/quota.LOGIC.md
@@ -13,7 +13,7 @@ Assembles the dashboard's quota [1] view: the account's windows as the coding ag
 [3] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
 [4] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
 [5] spend offset: the user's adjustment of the quota boundary, in percentage points of the week.
-[6] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[6] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [7] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [8] driver: a coding agent wrapped as a black box. The user's driver choice is `claude` or `codex`.
 [9] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
diff --git a/packages/framework/src/dashboard/rpc-serve.LOGIC.md b/packages/framework/src/dashboard/rpc-serve.LOGIC.md
index cf6a4f9f0..aaadcbeef 100644
--- a/packages/framework/src/dashboard/rpc-serve.LOGIC.md
+++ b/packages/framework/src/dashboard/rpc-serve.LOGIC.md
@@ -14,7 +14,7 @@ Serves the dashboard's RPC surface at `/_rpc`: a call is a `POST /_rpc/<name>` w
 [4] device: another machine's daemon the user saved by URL and token, to run agents on it from this dashboard.
 [5] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
 [6] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
-[7] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[7] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 
 ## Business logic — TL;DR
 
diff --git a/packages/framework/src/dashboard/server.LOGIC.md b/packages/framework/src/dashboard/server.LOGIC.md
index b658b6c27..2a3afd1b0 100644
--- a/packages/framework/src/dashboard/server.LOGIC.md
+++ b/packages/framework/src/dashboard/server.LOGIC.md
@@ -15,7 +15,7 @@ The daemon's one HTTP server on its port. It serves the built dashboard, mounts
 [5] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [6] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
 [7] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
-[8] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[8] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [9] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 
 ## Business logic — TL;DR
diff --git a/packages/framework/src/dashboard/tickets.LOGIC.md b/packages/framework/src/dashboard/tickets.LOGIC.md
index 72f8470f9..8675195e3 100644
--- a/packages/framework/src/dashboard/tickets.LOGIC.md
+++ b/packages/framework/src/dashboard/tickets.LOGIC.md
@@ -2,7 +2,7 @@ Reads a project's tickets as the dashboard shows them: the rows the `tickets` sk
 
 ## Glossary
 
-[1] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
+[1] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command run as `npx <skill>`, and an API the product calls.
 [2] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [3] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch. Also "the `agent-data` branch's checkout".
 [4] holder: who a claim names: the agent's id when the daemon started the agent, else the branch the `tickets` command ran on.
diff --git a/packages/framework/src/dashboard/types.LOGIC.md b/packages/framework/src/dashboard/types.LOGIC.md
index 8228975d4..360e3a9c8 100644
--- a/packages/framework/src/dashboard/types.LOGIC.md
+++ b/packages/framework/src/dashboard/types.LOGIC.md
@@ -21,7 +21,7 @@ Fixes the vocabulary the dashboard and the daemon speak to each other for starti
 [17] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
 [18] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
 [19] claim: a ticket's lock file naming the holder working it, so two agents never work the same ticket.
-[20] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[20] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [21] plan: a ticket's `.plan.md`: effort and uncertainty ratings and how to implement it.
 [22] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
 [23] driver session: the coding agent's own conversation for one agent, which the driver can resume by its session id.
diff --git a/packages/framework/src/e2e/LOGIC.md b/packages/framework/src/e2e/LOGIC.md
index 457fb6fcb..b46944439 100644
--- a/packages/framework/src/e2e/LOGIC.md
+++ b/packages/framework/src/e2e/LOGIC.md
@@ -14,7 +14,7 @@ The backend end-to-end stories: what the user sees between registering a project
 [6] driver: a coding agent wrapped as a black box: start it in a directory, prompt it for one turn, stream what it does, resume it later.
 [7] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent.
 [8] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
-[9] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[9] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [10] sweep: a background job the daemon runs on its clock.
 [11] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [12] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request, the default), `merge` (also merge it).
@@ -23,7 +23,7 @@ The backend end-to-end stories: what the user sees between registering a project
 [15] turn: one prompt sent to the driver; the coding agent's own loop runs to completion and answers with a final message.
 [16] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
 [17] reclaim: removing a finished agent's checkout once its work is on the remote.
-[18] drain: starting an agent on the agent queue's first open entry.
+[18] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 
 ## Business logic — TL;DR
 
@@ -31,4 +31,4 @@ The backend end-to-end stories: what the user sees between registering a project
 - **Projects and settings** (`story-projects-and-settings.test.ts`) - registering a repository installs and lists it, unknown projects degrade quietly, preferences [8] set in Settings reach the next continued agent, and the usage panel and the Auto PM [9] line show what the daemon reports and fire a sweep [10] on demand.
 - **The agent lifecycle** (`story-session-lifecycle.test.ts`) - what the user sees between Start and the archived row: the live event stream in order, the finished row, a publish-nothing agent keeping its checkout [11], the archived replay and the cross-project surfaces, two agents at once each in its own checkout, and a finished agent pushed from the handoff [12] panel.
 - **Steering and gates** (`story-steering-and-gates.test.ts`) - answering a parked agent's question from the open questions [13] list, live chat [14] becoming the next turn [15] and surviving into the agent's record, rearming the handoff mid-run, and a stop [16] whose checkout is reclaimed [17] once its work is on the remote, then a delete that removes the row.
-- **Tickets and the queue** (`story-tickets-and-queue.test.ts`) - browsing the ticket backlog, queueing a ticket and having a drain [18] claim it so the boards show it in progress, and any other prompt claiming nothing.
+- **Tickets and the queue** (`story-tickets-and-queue.test.ts`) - browsing the ticket backlog, queueing a ticket so the boards show it queued, and a prompt about something else leaving the queue alone.
diff --git a/packages/framework/src/e2e/harness.LOGIC.md b/packages/framework/src/e2e/harness.LOGIC.md
index d9f4a471e..3f62a95da 100644
--- a/packages/framework/src/e2e/harness.LOGIC.md
+++ b/packages/framework/src/e2e/harness.LOGIC.md
@@ -9,7 +9,7 @@ The world the backend end-to-end stories run in: one daemon per story, its busin
 [5] relay: running an agent on a device: the local daemon forwards the start, streams the events back and forwards steering, so the agent renders like a local one.
 [6] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [7] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
-[8] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[8] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [9] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
 [10] bridge browser: the Chrome for Testing the daemon runs for the Claude web bridge.
 [11] preflight: the check that the chosen driver's coding agent can start an agent, run before a checkout is spent.
diff --git a/packages/framework/src/e2e/story-tickets-and-queue.test.LOGIC.md b/packages/framework/src/e2e/story-tickets-and-queue.test.LOGIC.md
index d1a902834..cf8162e8f 100644
--- a/packages/framework/src/e2e/story-tickets-and-queue.test.LOGIC.md
+++ b/packages/framework/src/e2e/story-tickets-and-queue.test.LOGIC.md
@@ -1,5 +1,5 @@
-What the tests cover: tickets are proposals, the agent queue holds confirmed work, and a drain claims the queue's next entry.
+What the tests cover: tickets are proposals and the agent queue holds confirmed work; working the queue is the daemon's, covered in `daemon-services.test.ts`.
 
 - **Browsing the ticket backlog** - the project's Tickets page lists every ticket with its parsed title, priority and summary; a ticket's own page carries its full text; a name that escapes the tickets directory is refused; the cross-project ticket pages see the same backlog under the project.
-- **Queueing a ticket and draining it** - the ticket page's Queue action lands an entry in `TODO_AGENTS.md` that links back to the ticket, and the Queue page counts it as open; the queued ticket shows on the hot-tickets rail; a drain started by hand (the "drain queue" preset) resolves the queue's next entry to its ticket before the agent starts, so the spawned agent carries the ticket, the agent's record names it while the agent is live, and the hot-tickets rail links the ticket to the agent implementing it.
-- **Only a drain claims** - any other prompt wears no ticket, and the queue entry stays open.
+- **Queueing a ticket** - the ticket page's Queue action lands an entry in `TODO_AGENTS.md` that links back to the ticket, and the Queue page counts it as open; the queued ticket shows on the hot-tickets rail.
+- **A prompt about something else leaves the queue alone** - the run is listed, and the queue entry stays open.
diff --git a/packages/framework/src/events.LOGIC.md b/packages/framework/src/events.LOGIC.md
index 668354b97..80a25a93b 100644
--- a/packages/framework/src/events.LOGIC.md
+++ b/packages/framework/src/events.LOGIC.md
@@ -20,7 +20,7 @@ Fixes the vocabulary of the event stream [1]: every kind of event an agent [2] c
 [8] view: a markdown document an agent pushes to the dashboard's right rail while it works.
 [9] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
 [10] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
-[11] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
+[11] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
 [12] turn signals: what The Framework reads off a turn's final message: the ready-for-merge signal, the pull request title and body, markdown views, reported errors, and the gate it stops at.
 [13] driver: a coding agent wrapped as a black box: start it in a directory, prompt it for one turn, stream what it does, resume it later. The user's driver choice is `claude` or `codex`; the driver implementations are `claude-code`, `codex`, `github-actions`, `claude-web` and `fake`.
 [14] turn: one prompt sent to the driver; the coding agent's own loop runs to completion and answers with a final message.
@@ -29,7 +29,7 @@ Fixes the vocabulary of the event stream [1]: every kind of event an agent [2] c
 [17] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles. The opposite is attended.
 [18] ready for merge: the signal an agent emits when it believes its work is complete: it flips the agent's badge from building to ready and authorizes the handoff.
 [19] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
-[20] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[20] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [21] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
 [22] location: where an agent's turns run: `local` (this machine), `actions` (a GitHub Actions runner), or `web` (a Claude Code cloud session).
 [23] cloud anchor: an empty commit a web agent pushes before its task leaves this machine, unique to the agent: the branch the cloud session later pushes descends from it, which is how the daemon recognises that branch as the agent's (cloud work adoption).
@@ -46,7 +46,7 @@ Fixes the vocabulary of the event stream [1]: every kind of event an agent [2] c
 - **What the agent shows the user** - a view updates in place by title, a reported error stays in the log as history, a log line narrates, and the agent's browser travels as a page URL and a stream port only, never as frames.
 - **A gate and its pick** - a gate is a question, at least one option and, for a single-select gate, a recommended option; a checklist pre-checks options instead; the pick is one option id or the chosen subset, and says whether the user or nobody picked.
 - **Ready for merge and the pull request text** - the ready-for-merge signal flips the agent from building to ready without blocking it; the pull request title and description the agent wrote travel as an event the handoff uses, the latest one winning.
-- **Facts that must survive a reload** - what the handoff is armed to do, the ticket being implemented, the branch and session name, the pull request once opened, and the cloud anchor each travel as events because only an event reaches a tab opened later.
+- **Facts that must survive a reload** - what the handoff is armed to do, the branch and session name, the pull request once opened, and the cloud anchor each travel as events because only an event reaches a tab opened later.
 - **The on-before-mergeable outcome** - the follow-up queued its prompts, queued them without finishing cleanly, or declined for one of five reasons; it is silent when the option was off.
 - **The handoff outcome** - the handoff is done (pushed, a pull request, how the merge went), skipped for one of nine reasons that are not faults, or failed at the push or at the pull request.
 - **How a merge went, and why it is withheld** - GitHub's own auto-merge is preferred, a direct merge is the fallback, the CI watch takes a pull request whose checks are pending, a failed merge never fails the handoff, and a merge is withheld when the agent never said it was ready or its own to-do list is still open.
@@ -123,7 +123,7 @@ A pick is normalized to a list of option ids wherever a list is needed: a subset
 #### Business logic
 
 - Ready for merge [18]: the agent [2] signaled that it believes the work is complete and ready for human review. Non-blocking: it flips the agent's badge from building to ready, and the on-before-mergeable follow-up hangs off it.
-- The pull request text: the title and description the agent asked for through its `open-pr` signal. This is how an agent opens a pull request through The Framework instead of running `gh pr create` itself, so the ticket's issue reference and the recording of the pull request number still apply. The title is the agent's name for the work and the description is what changed; either may be absent when the agent wrote only the other. Non-blocking; the handoff [5] uses the latest one.
+- The pull request text: the title and description the agent asked for through its `open-pr` signal. This is how an agent opens a pull request through The Framework instead of running `gh pr create` itself, so the recording of the pull request number still applies. The title is the agent's name for the work and the description is what changed; either may be absent when the agent wrote only the other. Non-blocking; the handoff [5] uses the latest one.
 
 Both are read off a turn's [14] final message as turn signals [12]; the parsing rules are `turn-gate.ts`'s.
 
@@ -131,12 +131,11 @@ Both are read off a turn's [14] final message as turn signals [12]; the parsing
 
 #### Context
 
-**Problem**: the dashboard's checkboxes, the ticket an agent [2] was started for and the branch it works on are known to the process that started the agent, but a dashboard tab opened later can only read the agent's folded state, which is built from events alone. Anything that is not an event is lost to that tab.
+**Problem**: the dashboard's checkboxes and the branch an agent [2] works on are known to the process that started the agent, but a dashboard tab opened later can only read the agent's folded state, which is built from events alone. Anything that is not an event is lost to that tab.
 
 #### Business logic
 
 - What the handoff [5] is armed to do: whether a push and whether a pull request are armed, and whether a merge is. Emitted at the start and again whenever the dashboard's checkboxes change it, which is what makes the boxes survive a reload. The merge flag has no checkbox and never changes during the agent [2], so every re-emit repeats it; when it is absent it reads as off, the conservative display. It is carried so the armed line can say the most consequential half of the plan: without it, a merge-armed agent would advertise "open a draft PR" and then merge.
-- The ticket the agent was started to implement, as a path `tickets/<file>.md` on the `agent-data` branch [19]. Emitted once at the start, and only when The Framework itself chose the ticket: the drain [20] agent whose queue entry links back to the ticket it was queued from. Absent means nobody knows what the agent is implementing, which is the case for every hand-written prompt.
 - The branch the agent's work is on, observed off the checkout [9] rather than guessed: emitted at the start with the branch the agent actually begins on, and again whenever a later read finds it changed, since the agent renames its own branch through `branches name`. When the branch carries a session name [21], the event carries it too. The session name is read off the branch by the agent's process, the one writer that knows which branch the checkout was created on; a reader of the stream alone cannot tell that birth branch from a named one. Every surface resolves the branch and the session name from this event first.
 - The pull request the agent's work is on, its number and URL, the moment one is opened for it, so that no surface has to guess the pull request from the branch afterwards.
 - The cloud anchor [23]: the empty commit an agent whose location [22] is `web` pushed before its task left this machine, unique to the agent. The branch the cloud session [24] later works on is a `claude/*` name of the cloud's own choosing, never the agent's designated branch, and is recognized as the agent's by descending from this commit; the daemon's cloud work adoption matches the anchor against the remote's `claude/*` heads once the cloud session has pushed.
diff --git a/packages/framework/src/events.test.LOGIC.md b/packages/framework/src/events.test.LOGIC.md
index cee672b71..b097723f2 100644
--- a/packages/framework/src/events.test.LOGIC.md
+++ b/packages/framework/src/events.test.LOGIC.md
@@ -12,4 +12,4 @@ What the tests cover, across the pick normalization in `events.ts`, the session
 - **The usage line** - "spend: $0.0400 over 2 turns", with "turn" in the singular for one; when the coding agent reported tokens but no price the line reads "tokens: 12,224 (6 out) over 1 turn — no price reported" and carries no dollar sign, because a "$0.0000" would read as free rather than unknown; the token total is the input, cache-read and output tokens together.
 - **The quota line** - "· quota allowed (five_hour)", "! quota running low (five_hour)" and "✗ quota exhausted (five_hour)" by the reported status, each followed by the reset time as an ISO timestamp; a status never seen before still renders as "quota <status>" rather than vanishing or crashing.
 - **The on-before-mergeable outcome lines** - "✓ post-merge cleanup: quality follow-ups queued"; "! post-merge cleanup: queueing did not complete cleanly"; a skip names its reason in the reader's terms: "the session never signalled ready-for-merge", "the run was stopped", "this was a fake run", "the session was never named", "the framework binary path is unknown".
-- **The handoff lines, merge half included** - "✓ opened <url>" is followed by its own merge line, "✓ merged the PR"; an armed auto-merge reads "auto-merge armed: the PR lands when its checks pass"; a failed merge reads "! could not merge the PR: <error>"; a withheld merge reads "~ merge withheld: the session never signalled ready-for-merge" or "~ merge withheld: the session's own TODO file still has open entries", and the withheld line also follows a skipped handoff; a handoff with no merge half reads exactly "✓ branch pushed"; a handoff skipped because the pull request already landed reads "handoff skipped: the branch's pull request already landed everything the session did", never "the branch already has a pull request".
+- **The handoff lines, merge half included** - "✓ opened <url>" is followed by its own merge line, "✓ merged the PR"; an armed auto-merge reads "auto-merge armed: the PR lands when its checks pass"; a failed merge reads "! could not merge the PR: <error>"; a withheld merge reads "~ merge withheld: the session never signalled ready-for-merge".
diff --git a/packages/framework/src/maintenance.LOGIC.md b/packages/framework/src/maintenance.LOGIC.md
index 20573f6a9..de66662e1 100644
--- a/packages/framework/src/maintenance.LOGIC.md
+++ b/packages/framework/src/maintenance.LOGIC.md
@@ -9,8 +9,8 @@ The maintenance sweep's [1] bookkeeping and schedule. Per project, a small state
 ## Glossary
 
 [1] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
-[2] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
-[3] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[2] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
+[3] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [4] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
 [5] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [6] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch. The user's own working copy is "the project's checkout".
diff --git a/packages/framework/src/preference-defaults.LOGIC.md b/packages/framework/src/preference-defaults.LOGIC.md
index ba35e2a18..5e1f543ea 100644
--- a/packages/framework/src/preference-defaults.LOGIC.md
+++ b/packages/framework/src/preference-defaults.LOGIC.md
@@ -11,7 +11,7 @@ Fixes what an unset preference [1] means and the bounds that the controls writin
 [1] preferences: the user's dashboard settings, kept in the registry (`~/.the-framework.json`, which also lists the projects).
 [2] spend offset: the user's adjustment of the quota boundary, in percentage points of the week.
 [3] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
-[4] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[4] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [5] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
 [6] intervention: something that needs a human — an open question, a pull request to review, unpushed commits — one of the two notification feeds. The other is activity: an agent started or finished.
 [7] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
diff --git a/packages/framework/src/preset-catalog.LOGIC.md b/packages/framework/src/preset-catalog.LOGIC.md
index 9879370c2..6bfae2f6f 100644
--- a/packages/framework/src/preset-catalog.LOGIC.md
+++ b/packages/framework/src/preset-catalog.LOGIC.md
@@ -1,4 +1,4 @@
-Holds every built-in preset in one table: fifteen rows, each naming the preset, its prompt (shipped as `prompts/presets/<stem>.md` and compiled in), its launcher [1] button's label, an optional one-line tooltip, what its one blank means when it has one, and whether it must always open an agent [2] of its own. From the table it derives the fourteen buttons the launcher shows, in order, and the rule that recognizes the prompt that drains [3] the agent queue [4]. The table reads nothing from the machine, so the dashboard renders any preset in the browser before an agent exists.
+Holds every built-in preset in one table: fourteen rows, each naming the preset, its prompt (shipped as `prompts/presets/<stem>.md` and compiled in), its launcher [1] button's label, an optional one-line tooltip, what its one blank means when it has one, and whether it must always open an agent [2] of its own. From the table it derives the fourteen buttons the launcher shows, in order. The table reads nothing from the machine, so the dashboard renders any preset in the browser before an agent exists.
 
 ## Context
 
@@ -10,12 +10,12 @@ Holds every built-in preset in one table: fifteen rows, each naming the preset,
 
 [1] launcher: the Start form on project home, a project's own page.
 [2] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
-[3] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[3] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [4] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [5] composer: the prompt editor on project home, also used for live chat.
 [6] agent view: one agent's page in the dashboard.
 [7] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
-[8] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[8] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [9] prompt agent: an agent that runs one prompt and stops there; a build agent works the agent queue after its opening exchange.
 [10] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent. When nobody can answer, the recommended option is taken.
 [11] routine lock: a file on the `agent-data` branch (`routines/<name>.lock.md`) a daemon takes before running a routine so the routine runs once across machines.
@@ -30,8 +30,7 @@ Holds every built-in preset in one table: fifteen rows, each naming the preset,
 - **Presets with a blank, and presets that scope themselves** - six presets wrap the user's target, the "what", whose default is the launching agent's session name or else the entire codebase; the other nine scope themselves to the repository's own tickets, plans or queue and render verbatim.
 - **The triage pair shares one queue-only rule** - both triage prompts end with the same appended rule: only queue work, never do it.
 - **"Update from GitHub" always opens its own agent** - picked from inside an agent view, it still starts a new agent rather than continuing that agent's driver session.
-- **What the launcher offers, in order** - fourteen buttons in a fixed order; the drain is absent because only the daemon fires it.
-- **Recognizing the drain prompt** - a prompt drains the agent queue exactly when its text equals the rendered drain preset, so a drain the user started by hand counts and a prompt that merely mentions the queue does not.
+- **What the launcher offers, in order** - fourteen buttons in a fixed order, one per preset; the routine only the daemon fires is a skill file, not a preset.
 - **Which presets may run unattended** - the presets that stop at a gate need a human and never back a routine; the ones that end in work or in tickets do not, and only those are routines.
 
 ## Business logic
@@ -58,7 +57,6 @@ Each row carries the preset's name, by which the daemon's routines [8] and their
 - "Suggest new tickets", name `suggest-new-tickets`: a single line the dashboard prefills and the user edits freely.
 - "Suggest new features", name `suggest-new-features`, tooltip "Propose net-new features as tickets in `tickets/`".
 - "Suggest tickets to work on", name `suggest-tickets-to-work-on`, tooltip "Add tickets to queue (TODO_AGENTS.md)".
-- "Spin up agents working on the AI queue", name `drain-queue`, tooltip "Work the entries already on the queue (TODO_AGENTS.md)".
 - "Add quick-win work to AI Queue", name `triage-quick`, tooltip "Add `tickets/*.md` to queue (TODO_AGENTS.md), only quick-win and consensual tickets".
 - "Add consensual work to AI Queue", name `triage-consensual`, tooltip "Add `tickets/*.md` to queue (TODO_AGENTS.md), only significant (no quick-wins) and consensual tickets".
 
@@ -102,17 +100,7 @@ The "Update from GitHub" row is marked as always running in an agent of its own.
 
 #### Business logic
 
-The launcher [1] shows fourteen buttons, in this order: "Research", "Readability", "Maintainability", "Security audit", "UX (auto)", "Suggest new tickets", "Suggest new features", "Suggest tickets to work on", "Plan tickets (aka spike)", "Market research", "Update from GitHub", "Maintenance", "Add quick-win work to AI Queue", "Add consensual work to AI Queue". "Spin up agents working on the AI queue" is not among them: only the daemon fires the drain [3].
-
-### Recognizing the drain prompt
-
-#### Context
-
-**Problem**: the daemon knows a drain [3] by the mark on its routine [8], but an agent [2] the user started arrives as plain prompt text with no such mark, so the text is all there is to recognize it by. The dashboard needs that recognition to show which agents are working the agent queue [4]: a lane on the Overview [13], and which ticket an agent is implementing.
-
-#### Business logic
-
-A prompt drains the queue exactly when its text, ignoring surrounding whitespace, equals the rendered "Spin up agents working on the AI queue" preset. The comparison is against the preset as rendered now, not against a copy of its words, so rewording the preset cannot leave the rule behind. It is deliberately exact: a prompt that merely mentions the queue is not a drain, and mistaking one for the other would name a ticket as being implemented by an agent doing something else entirely.
+The launcher [1] shows fourteen buttons, in this order: "Research", "Readability", "Maintainability", "Security audit", "UX (auto)", "Suggest new tickets", "Suggest new features", "Suggest tickets to work on", "Plan tickets (aka spike)", "Market research", "Update from GitHub", "Maintenance", "Add quick-win work to AI Queue", "Add consensual work to AI Queue": every preset. The routine that works the agent queue [4] is not a preset but the skill file `skills/work-queue/SKILL.md`, which only the daemon fires (the rules in `auto-pm.ts`).
 
 ### Which presets may run unattended
 
diff --git a/packages/framework/src/preset-catalog.test.LOGIC.md b/packages/framework/src/preset-catalog.test.LOGIC.md
index 28b719634..43f75c8d7 100644
--- a/packages/framework/src/preset-catalog.test.LOGIC.md
+++ b/packages/framework/src/preset-catalog.test.LOGIC.md
@@ -1,7 +1,7 @@
 What the tests cover:
 
-- **The names** - the fifteen preset names are pinned exactly (`drain-queue`, `maintainability`, `maintenance`, `market-research`, `plan-tickets`, `readability`, `research`, `security-audit`, `suggest-new-features`, `suggest-new-tickets`, `suggest-tickets-to-work-on`, `triage-consensual`, `triage-quick`, `update-tickets`, `ux`), since the launcher keys on the name and a queued entry's path to a preset resolves from it.
-- **What the launcher offers** - every preset except the daemon-only drain, each with a label.
+- **The names** - the fourteen preset names are pinned exactly (`maintainability`, `maintenance`, `market-research`, `plan-tickets`, `readability`, `research`, `security-audit`, `suggest-new-features`, `suggest-new-tickets`, `suggest-tickets-to-work-on`, `triage-consensual`, `triage-quick`, `update-tickets`, `ux`), since the launcher keys on the name and a queued entry's path to a preset resolves from it.
+- **What the launcher offers** - every preset, each with a label.
 - **Presets with a blank** - the six presets that take a target (maintainability, readability, research, security audit, UX, maintenance) declare exactly one blank, render the target into their opening phrase ("Refactor the queue package to make it…", "Security audit the auth package", "Review all UI flows of the settings page", "Analyze the auth package and…"), fall back to "entire codebase" when the target is omitted or blank instead of erasing it, leave no placeholder in the rendered prompt, and target the launching agent's session name when there is one ("Analyze fix-login and…").
 - **Presets that scope themselves** - the other nine declare no blank and render exactly as written, with nothing left to fill.
 - **The quality presets' instructions** - maintainability asks for maintainability red flags; readability rates the seams, does an altitude pass, commits each refactor separately and defines what counts as a function; security audit demands exhaustive coverage with a verdict per aspect and one commit per issue; UX lists every UI flow, rates each from 0 to 10, commits each improvement separately and reports old versus new ratings.
diff --git a/packages/framework/src/presets.LOGIC.md b/packages/framework/src/presets.LOGIC.md
index 03158d8ca..5749b1576 100644
--- a/packages/framework/src/presets.LOGIC.md
+++ b/packages/framework/src/presets.LOGIC.md
@@ -12,8 +12,8 @@ Joins the preset registry with the preset catalog on the daemon's side: the six
 [2] queue entry: an item on the agent queue, `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
 [3] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
 [4] ready for merge: the signal an agent emits when it believes its work is complete: it flips the agent's badge from building to ready and authorizes the handoff.
-[5] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
-[6] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[5] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
+[6] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 
 ## Business logic — TL;DR
 
diff --git a/packages/framework/src/quota-boundary.LOGIC.md b/packages/framework/src/quota-boundary.LOGIC.md
index dc928a065..01fcf241c 100644
--- a/packages/framework/src/quota-boundary.LOGIC.md
+++ b/packages/framework/src/quota-boundary.LOGIC.md
@@ -13,7 +13,7 @@ Computes the quota boundary [1]: the share of the account's quota [2] week that
 [3] coding agent: the CLI doing the actual work: Claude Code or Codex.
 [4] spend offset: the user's adjustment of the quota boundary, in percentage points of the week.
 [5] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
-[6] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[6] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [7] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 
 ## Business logic — TL;DR
diff --git a/packages/framework/src/registry.LOGIC.md b/packages/framework/src/registry.LOGIC.md
index 1924c0552..03374391b 100644
--- a/packages/framework/src/registry.LOGIC.md
+++ b/packages/framework/src/registry.LOGIC.md
@@ -17,7 +17,7 @@ Keeps the one file The Framework owns for the user, the registry [1] at `~/.the-
 [7] ready for merge: the signal an agent emits when it believes its work is complete: it flips the agent's badge from building to ready and authorizes the handoff.
 [8] transparent: an agent started with nothing of The Framework's — the raw coding agent.
 [9] intervention: something that needs a human — an open question, a pull request to review, unpushed commits — one of the two notification feeds. The other is activity: an agent started or finished.
-[10] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[10] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [11] the bridge: the daemon's bridge endpoints plus the Chrome extension: carries the question a cloud session is parked on into the dashboard, and types the pick back into the session. The bridge token is the secret the extension presents; the bridge browser is the Chrome for Testing the daemon runs for it.
 [12] the Overview: the dashboard's cross-project page at `/`.
 [13] coding agent: the CLI doing the actual work: Claude Code or Codex.
@@ -28,8 +28,8 @@ Keeps the one file The Framework owns for the user, the registry [1] at `~/.the-
 [18] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [19] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [20] quota boundary: the share of the quota week that may be spent by now, rising with the clock; unattended work stands down past it, work a human asked for never does.
-[21] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
-[22] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[21] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[22] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [23] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
 [24] tick: one beat of the daemon's single background clock; each sweep says how many ticks it waits between turns.
 
@@ -138,7 +138,7 @@ Each of these keys of the preferences [2] is kept only when its value is a true
 #### Business logic
 
 - `autoSpendOffset`, the spend offset [17]: a finite number, rounded to a whole number and clamped between -50 and 50 percentage points; anything else is dropped. Absent means about 7.1 points, a half day's share of the quota [18] week (100 divided by 14): unattended [19] work then starts a little ahead of the quota boundary [20] instead of exactly on it, where normal jitter would stop it. Negative holds unattended work back further; positive lets it borrow from the days still to come. It is an offset rather than an absolute percentage so the limit travels with the boundary as the week goes on.
-- `autoPmConcurrency`: how many agents Auto PM [10] may keep going at once on one project: a finite number, rounded, floored at 1, with no upper bound; anything else is dropped. Absent means 2. Only the routine [21] that drains [22] the queue fans out [23]; the routines that invent work stay at one agent per tick [24] whatever this says.
+- `autoPmConcurrency`: how many agents Auto PM [10] may keep going at once on one project: a finite number, rounded, floored at 1, with no upper bound; anything else is dropped. Absent means 2. The queued work [22] runs one agent per move of the branch and the cap is how many may overlap; planning fans out [23] to it; the routines that rewrite the queue stay at one agent per tick [24] whatever this says.
 
 ### The list preferences
 
diff --git a/packages/framework/src/routine-locks.LOGIC.md b/packages/framework/src/routine-locks.LOGIC.md
index af62e98d1..b2334ae5f 100644
--- a/packages/framework/src/routine-locks.LOGIC.md
+++ b/packages/framework/src/routine-locks.LOGIC.md
@@ -8,11 +8,11 @@ Keeps a routine [1] from running twice at once across the machines that share a
 
 ## Glossary
 
-[1] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[1] routine: a job the daemon fires on its own — the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
 [2] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks. Born as an orphan, written through one sync → commit → push cycle.
 [3] routine lock: a file on the `agent-data` branch (`routines/<name>.lock.md`) a daemon takes before running a routine so the routine runs once across machines.
 [4] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
-[5] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
+[5] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
 [6] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
 [7] tick: one beat of the daemon's single background clock; each sweep says how many ticks it waits between turns.
 
diff --git a/packages/framework/src/store/LOGIC.md b/packages/framework/src/store/LOGIC.md
index e36e0cfe0..68bcd8325 100644
--- a/packages/framework/src/store/LOGIC.md
+++ b/packages/framework/src/store/LOGIC.md
@@ -11,7 +11,7 @@ The persisted state of one agent [1] and every read of it. An agent's event stre
 [3] status snapshot: `.the-framework/agent.json` in an agent's checkout: the agent's current state as one small JSON document, folded from its event stream, so that reading an agent's status never means replaying the stream.
 [4] checkout: An agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch. Also "the `agent-data` branch's checkout". The user's own working copy is "the project's checkout" or "the user's checkout".
 [5] archive: The transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
-[6] run: Only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
+[6] run: Only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
 [7] the `agent-data` branch: The branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks. Born as an orphan, written through one sync → commit → push cycle.
 [8] skill: One of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads (its `SKILL.md`, linked into the checkout where the coding agent's harness looks for skills), a command on the agent's PATH, and an API the product calls.
 [9] agent id: An agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
diff --git a/packages/framework/src/store/agent-checkout.LOGIC.md b/packages/framework/src/store/agent-checkout.LOGIC.md
index 61279db1f..24efdfa50 100644
--- a/packages/framework/src/store/agent-checkout.LOGIC.md
+++ b/packages/framework/src/store/agent-checkout.LOGIC.md
@@ -13,7 +13,7 @@ Decides which checkout [1] an agent id [2] addresses, and which event stream [3]
 [3] event stream: everything an agent does, one event per line appended to `.the-framework/events.jsonl` in its checkout; every surface (dashboard, terminal, archive, run) is a projection of it.
 [4] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [5] status snapshot: `.the-framework/agent.json` in an agent's checkout: the agent's current state as one small JSON document, folded from its event stream, so that reading an agent's status never means replaying the stream.
-[6] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
+[6] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
 [7] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks. Born as an orphan, written through one sync → commit → push cycle.
 [8] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
 
diff --git a/packages/framework/src/store/agent-store.LOGIC.md b/packages/framework/src/store/agent-store.LOGIC.md
index c6b5066ca..06c7d34a1 100644
--- a/packages/framework/src/store/agent-store.LOGIC.md
+++ b/packages/framework/src/store/agent-store.LOGIC.md
@@ -16,8 +16,8 @@ Keeps on disk everything The Framework itself knows about one agent [1]: the age
 [3] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch. Also "the `agent-data` branch's checkout". The user's own working copy is "the project's checkout" or "the user's checkout".
 [4] status snapshot: `.the-framework/agent.json` in an agent's checkout: the agent's current state as one small JSON document, folded from its event stream, so that reading an agent's status never means replaying the stream.
 [5] archive: the transient copy of a finished agent's events and status under a project's `.the-framework/agents/`.
-[6] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
-[7] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads (its `SKILL.md`, linked into the checkout where the coding agent's harness looks for skills), a command on the agent's PATH, and an API the product calls.
+[6] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
+[7] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads (its `SKILL.md`, a tracked file of the project where the coding agent's harness looks for skills), a command run as `npx <skill>`, and an API the product calls.
 [8] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks. Born as an orphan, written through one sync → commit → push cycle.
 [9] coding agent: the CLI doing the actual work: Claude Code or Codex.
 [10] the Overview: the dashboard's cross-project page at `/`.
@@ -38,7 +38,7 @@ Keeps on disk everything The Framework itself knows about one agent [1]: the age
 [25] driver: a coding agent wrapped as a black box: start it in a directory, prompt it for one turn, stream what it does, resume it later. The user's driver choice is `claude` or `codex`; the driver implementations are `claude-code`, `codex`, `github-actions`, `claude-web` and `fake`.
 [26] leg: one process's stretch of an agent's life: a fresh agent has one leg, and a continued agent one more per continuation, each leg writing into the same agent.
 [27] ready for merge: the signal an agent emits when it believes its work is complete: it flips the agent's badge from building to ready and authorizes the handoff.
-[28] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[28] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 [29] claim: a ticket's lock file naming the holder working it, so two agents never work the same ticket.
 [30] CI watch: the sweep that merges the pull requests The Framework opened once their checks pass, and starts a fix agent when a check goes red.
 [31] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
@@ -128,7 +128,6 @@ Each event is folded into the status snapshot by one pure rule, the same on a li
 - **Browser preview port** - the browser-stream event records the loopback port the agent's browser preview listens on, which is how the daemon, a different process, learns where to proxy the pane from.
 - **Handoff arming** - the handoff-armed event records whether the handoff [22] is armed to push, to open a pull request, and to merge. The merge flag mirrors the merge arming for display only: the agent merges off its own configuration, never off the snapshot. A snapshot without this fact is read as armed to push and open a pull request, and as not armed to merge.
 - **Handoff report** - the handoff event records how the handoff went: `done`, `skipped` or `failed`. Between a clean end and this fact, an armed agent is still pushing or opening its pull request, which is the window a list shows as "publishing…"; absent reads as "still going". When the report is `skipped`, its reason is recorded (for instance `no-commits`), and on any other outcome the reason is cleared: a continued agent's second leg can publish after its first leg skipped, and a stale `no-commits` on a published agent is exactly the lie a release must not act on. The reason is what lets the daemon tell "published elsewhere" from "ended with nothing to hand off": a drain [28] that settles with `no-commits` will never run the pull request that lifts its ticket's claim [29], so the sweep releases the claim it minted. Unless the handoff failed, the outcome of its merge half is recorded too — `auto-armed`, `merged`, `watched`, `withheld` or `failed` — which the CI watch [30] scans: `watched` is a pull request waiting for green that this machine must merge, `auto-armed` one GitHub lands by itself but whose checks going red is still this machine's to notice.
-- **Ticket** - the ticket event records the ticket the agent implements, relative to the repository (`tickets/<file>.md`), only when The Framework picked the ticket itself, so that the Overview [10] can show a ticket being coded right now as implementing instead of inferring it from the plan the agent left behind.
 - **Pull request** - the pull-request event records the number and URL once one is opened, so that no surface re-derives it from branch names and timestamps.
 - **Branch** - the branch event records the branch the agent's work is on, as the agent observes it. The agent renames its branch itself when it names its work, so the branch named after the agent id [13] is not guaranteed to be the one holding the commits. The session name [31] is this branch minus its `agent-` prefix, read off it by every surface and never stored beside it.
 - **Cloud anchor** - the cloud-anchor event records the cloud anchor [32] a hands-off [33] agent pushed; it is absent on every other agent and on a web agent whose push before the task left this machine failed.
@@ -232,7 +231,7 @@ An agent whose process died without reporting an end is given one on its behalf,
 #### Business logic
 
 At startup the daemon (`daemon.ts`) runs the crash rescue [18] over every place a `running` record can be, ending each one whose owning process it cannot find, in this order:
-- Runs [6] on the `agent-data` branch: a card at `running` whose owning process is dead or unknowable is written again through the `logs` skill [7], with the ended status on the card and the surrogate end [16] as the last diary line — as one commit, because a card edited in place on the branch's checkout is not a fact yet: the next sync's rebase refuses the dirty tree and resets it. It counts as reconciled when the commit landed, pushed or not.
+- Runs [6] on the `agent-data` branch: a card at `running` whose owning process is dead or unknowable is written again through the `logs` skill [7], as a commit signed with the daemon's trailer when the daemon is the one repairing (`daemon-writes.ts`), with the ended status on the card and the surrogate end [16] as the last diary line — as one commit, because a card edited in place on the branch's checkout is not a fact yet: the next sync's rebase refuses the dirty tree and resets it. It counts as reconciled when the commit landed, pushed or not.
 - Archive entries: the surrogate end is appended to `<id>.jsonl` and `<id>.json` is rewritten as stopped. These go before the live status snapshot [4], so the archive entry made from it is not counted twice.
 - The live status snapshot at the project root: flipped through the surrogate end and archived.
 - Agents inside `.branches/*` checkouts: the surrogate end is recorded in the checkout's own files first, so that the copy which follows is an event stream [2] that actually ends; then the agent is copied into the project's archive. The checkout itself stays on disk: an agent that ended this way did not end cleanly, and those are kept for inspection; removing one is an explicit action.
diff --git a/packages/framework/src/store/run-record.LOGIC.md b/packages/framework/src/store/run-record.LOGIC.md
index e917e4dcb..171cdd536 100644
--- a/packages/framework/src/store/run-record.LOGIC.md
+++ b/packages/framework/src/store/run-record.LOGIC.md
@@ -8,8 +8,8 @@ Maps The Framework's status snapshot [1] and event stream [2] onto the `logs` sk
 
 [1] status snapshot: `.the-framework/agent.json` in an agent's checkout: the agent's current state as one small JSON document, folded from its event stream, so that reading an agent's status never means replaying the stream.
 [2] event stream: everything an agent does, one event per line appended to `.the-framework/events.jsonl` in its checkout; every surface (dashboard, terminal, archive, run) is a projection of it.
-[3] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads (its `SKILL.md`, linked into the checkout where the coding agent's harness looks for skills), a command on the agent's PATH, and an API the product calls.
-[4] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
+[3] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads (its `SKILL.md`, a tracked file of the project where the coding agent's harness looks for skills), a command run as `npx <skill>`, and an API the product calls.
+[4] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said). Never the unit of work.
 [5] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [6] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks. Born as an orphan, written through one sync → commit → push cycle.
 [7] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
@@ -40,7 +40,7 @@ See `## Context`.
 
 #### Business logic
 
-The card carries, from the status snapshot [1]: the agent id [7], the start time and the status always; and, only when known, the end time, the intent, the driver [8], the model, the branch, the pull request (number and URL), the ticket and the cost in US dollars. Everything else the snapshot holds — the last-updated time, the owning process's id and host, the workspace, the session id and session link, the cloud anchor [9], the ready-for-merge flag, the handoff [10] arming, report, skip reason and merge outcome, the pending gate [11], the settled [12] time, the browser preview port, the location [13], the device's [14] label and the agent's kind — rides under the card's one `caller` key, which the skill stores and never prints or reads. The `caller` key is left off when there is nothing to put under it.
+The card carries, from the status snapshot [1]: the agent id [7], the start time and the status always; and, only when known, the end time, the intent, the driver [8], the model, the branch, the pull request (number and URL) and the cost in US dollars; the card's ticket field is the agent's own to fill, never The Framework's. Everything else the snapshot holds — the last-updated time, the owning process's id and host, the workspace, the session id and session link, the cloud anchor [9], the ready-for-merge flag, the handoff [10] arming, report, skip reason and merge outcome, the pending gate [11], the settled [12] time, the browser preview port, the location [13], the device's [14] label and the agent's kind — rides under the card's one `caller` key, which the skill stores and never prints or reads. The `caller` key is left off when there is nothing to put under it.
 
 ### Back from a card
 
diff --git a/packages/framework/src/terminal.LOGIC.md b/packages/framework/src/terminal.LOGIC.md
index 7f3359d99..69bb53c33 100644
--- a/packages/framework/src/terminal.LOGIC.md
+++ b/packages/framework/src/terminal.LOGIC.md
@@ -27,11 +27,11 @@ Renders an agent's [1] event stream [2] in a terminal, one human-readable line p
 
 ## Business logic — TL;DR
 
-- **The agent's setup** - the driver and model in the checkout with the session link, the prompt, the branch, the ticket, the cloud anchor, the browser addresses, the pull request number.
+- **The agent's setup** - the driver and model in the checkout with the session link, the prompt, the branch, the cloud anchor, the browser addresses, the pull request number.
 - **What the agent signals** - its log lines, errors with their detail indented, views by title, "✓ ready for merge", the pull request it wrote, and "done for now" when it is settled.
 - **Gates and picks** - the question with one option per line, the recommended one marked, and the pick with who made it.
 - **The handoff, announced then reported** - one line saying what will happen when the agent ends, then what happened to the push and the pull request, and always a line for the merge.
-- **Why a merge was withheld** - "the session never signalled ready-for-merge" or "the session's own TODO file still has open entries", the same words the CLI prints.
+- **Why a merge was withheld** - "the session never signalled ready-for-merge", the same words the CLI prints.
 - **Why a handoff or the extra turn was skipped** - every reason as a sentence in the reader's terms.
 - **Usage** - the spend in dollars over the turns, or the tokens when no price was reported, never a zero that reads as free.
 - **The driver's own events** - the prompt, the text, the actions, the turn boundary, quota warnings only when the quota is tight, errors and notices.
@@ -47,7 +47,6 @@ See `## Context`.
 
 #### Business logic
 
-The opening line names the driver [5] (or "fake" for a fake agent [1]), the model when one was chosen, the checkout, and the session link [6] when the driver reports one: "◆ <driver> (<model>) in <checkout> — <link>". A later session id is "session <id>", with the link when known. The system prompt is acknowledged by its size only: "system prompt sent (<n> chars)". The prompt the agent was given is "▶ "<prompt>"", flattened to one line and cut to 100 characters. Then, as they happen: "your app is running at <url>" for a preview, "◆ browser preview: http://127.0.0.1:<port>/stream" and "◆ browser: <url>" for a browser, "branch: <branch>", "implementing <ticket path>", "hand-off anchor: <the first seven characters of the cloud anchor [7]>", and "pull request: #<number>".
 
 ### What the agent signals
 
@@ -89,7 +88,7 @@ When the agent [1] ends, the handoff's outcome is one line: "✓ opened <pull re
 
 #### Business logic
 
-An armed merge is withheld for one of two reasons, said as: "the session never signalled ready-for-merge", or "the session's own TODO file still has open entries" (the rule behind the second is `todo-loop.ts`'s). The wording is shared with the CLI's own output line.
+An armed merge is withheld for one reason, said as "the session never signalled ready-for-merge". The wording is shared with the CLI's own output line.
 
 ### Why a handoff or the extra turn was skipped
 
diff --git a/packages/framework/src/tickets.LOGIC.md b/packages/framework/src/tickets.LOGIC.md
index e7e6bac62..e8867b5df 100644
--- a/packages/framework/src/tickets.LOGIC.md
+++ b/packages/framework/src/tickets.LOGIC.md
@@ -5,9 +5,9 @@ Fixes the one wording of the ask for a ticket's plan, "Create tickets/<stem>.pla
 [1] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
 [2] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends.
 [3] queue entry: an item on the agent queue.
-[4] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
+[4] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
 
 ## Business logic — TL;DR
 
 - **The plan ask** - "Create tickets/<stem>.plan.md" for the ticket `tickets/<stem>.md`; as a queue entry it is plain text and not a link to the ticket, so it never reads as the ticket being queued for implementation.
-- **Who wrote a plan** - the newest agent whose ask contains the plan ask for that ticket, whether the ask is the sentence itself (the plan column's attended start) or a longer prompt carrying it (a drain [4] pinned to that entry); a plan written by an agent whose ask never named it, such as an unpinned drain told to work "the first open entry", is attributed to nobody.
+- **Who wrote a plan** - the newest agent whose ask contains the plan ask for that ticket, whether the ask is the sentence itself (the plan column's attended start) or a longer prompt carrying it; a plan written by an agent whose ask never named it, such as one told `/work-queue`, is not attributed.
diff --git a/packages/framework/src/todo-loop.BUG-ANALYSIS.md b/packages/framework/src/todo-loop.BUG-ANALYSIS.md
deleted file mode 100644
index 21e8ae498..000000000
--- a/packages/framework/src/todo-loop.BUG-ANALYSIS.md
+++ /dev/null
@@ -1 +0,0 @@
-Last analyzed: [25 August 2026](https://github.com/framework/the-framework/pull/1698)
diff --git a/packages/framework/src/todo-loop.LOGIC.md b/packages/framework/src/todo-loop.LOGIC.md
deleted file mode 100644
index c6235cf70..000000000
--- a/packages/framework/src/todo-loop.LOGIC.md
+++ /dev/null
@@ -1,150 +0,0 @@
-Works the agent queue [1] once a build agent's [2] opening work settles, as the backlog loop [3]: read the queue's first open queue entry [4] fresh off the `agent-data` branch [5], ask the user whether to start it when someone can answer, prompt the agent [6] to complete exactly that entry, take the entry off the queue, and repeat until the queue is empty, within a cap of 25 entries and stopping when a removal will not land. Beside the loop live the guess of which ticket the next drain [7] will work, which only labels a lane on the Overview [8], and the check whether an agent's own session backlog still has open work, which withholds its merge.
-
-## Context
-
-**User story**: the user starts a build with a very large scope, or a research preset that queues deep dives; the agent [6] adds follow-ups to the agent queue [1] as it goes, and once its opening work settles it works them one at a time. With the dashboard watching, a card "Start the next queue item?" precedes each entry, and the dashboard's autopilot [9] accepts it after a countdown, so a switched-on autopilot consumes the whole queue; unattended [9], nothing is asked and the agent ends when the queue is empty.
-
-**Problem**: the queue lives on the `agent-data` branch [5], which the agent's checkout [10] does not hold, and every edit of that branch goes through the `queue` skill's [11] one writer; so The Framework, not the agent, reads the queue and takes entries off it, and the agent is only ever told the one entry to complete. Left unattended, the loop must stay bounded: a stop [12] ends any turn [13], the entry cap bounds the agent, and a removal that never lands must not re-serve the same entry.
-
-## Glossary
-
-[1] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down. An item on it is a queue entry.
-[2] build agent: one of the two kinds of agent: a build works the agent queue after its opening exchange; a prompt agent runs one prompt and stops there.
-[3] backlog loop: after a build agent's opening work settles, the loop that works the agent queue one entry per turn until it is empty.
-[4] queue entry: an item on the agent queue.
-[5] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks. Born as an orphan, written through one sync → commit → push cycle.
-[6] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
-[7] drain: starting an agent on the agent queue's first open entry — the half of Auto PM that spends existing work.
-[8] the Overview: the dashboard's cross-project page at `/`.
-[9] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles. The opposite is attended.
-[10] checkout: an agent's own working copy of the project: a git worktree under the project's `.branches/` directory, named as its branch.
-[11] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
-[12] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
-[13] turn: one prompt sent to the driver; the coding agent's own loop runs to completion and answers with a final message.
-[14] hands-off: said of an agent whose work leaves this machine, so its first prompt is the whole agent: an agent whose location is `web`.
-[15] driver session: the coding agent's own conversation for one agent, which the driver can resume by its session id.
-[16] event stream: everything an agent does, one event per line appended to `.the-framework/events.jsonl` in its checkout; every surface (dashboard, terminal, archive, run) is a projection of it.
-[17] turn signals: what The Framework reads off a turn's final message: the ready-for-merge signal, the pull request title and body, markdown views, reported errors, and the gate it stops at.
-[18] ready for merge: the signal an agent emits when it believes its work is complete: it flips the agent's badge from building to ready and authorizes the handoff.
-[19] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent. When nobody can answer, the recommended option is taken.
-[20] pick: the answer to a gate: the option or options chosen, by the user or automatically.
-[21] await limit: the cap on consecutive gates within one exchange; an agent still asking past it finishes with its latest turn.
-[22] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it).
-[23] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts, the branch-links sweep, the cloud scratch sweep, cloud work adoption.
-[24] routine: a preset the daemon fires on its own on a schedule — update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
-[25] session name: the name an agent gives its own work (`[a-z0-9-]+`); its branch is renamed to `agent-<session name>` and the dashboard labels the agent by it.
-
-## Business logic — TL;DR
-
-- **When the loop runs** - for a build agent that is not hands-off, after its opening exchange, with one turn-signal reader for the whole loop.
-- **One entry per turn, fresh off the branch** - every round fetches the `agent-data` branch and reads the queue's first open entry; an empty queue ends the loop as done.
-- **The gate before each entry** - when someone can answer, "Start the next queue item?" is asked with "Work on: …" recommended and "Stop the queue loop" as the other option; unattended, nothing is asked.
-- **The prompt for one entry** - the agent is told to work on exactly that task and nothing else, and that The Framework takes it off the queue when the turn ends; the turn's gates and signals count like any other turn's.
-- **A rejecting pick ends the whole agent** - a pick marked to stop inside an entry's turn ends the agent, not only the loop, so rejected work is never published.
-- **The Framework takes the entry off the queue** - through the `queue` skill, tried twice; when the removal will not land, the loop stops with the queue intact rather than re-serving the entry.
-- **Bounds** - at most 25 entries per agent, announced when entries are left; a stop ends the loop before the next entry without narration.
-- **The next queued ticket** - the ticket the queue's first open entry links to, a best guess that only labels a lane on the Overview.
-- **A hand-started drain** - a prompt that is exactly the "Drain queue" preset is a drain, and its ticket is the next queued ticket.
-- **The agent's own backlog withholds the merge** - `TODO_<session name>.agent.md` in the checkout with an open entry means the agent is not done, whatever it signaled.
-
-## Business logic
-
-### When the loop runs
-
-#### Context
-
-**Business logic story**: the agent lifecycle in `agent.ts` starts the loop once the opening exchange has settled, for a build agent [2] that is not hands-off [14]: a prompt agent stops at its one prompt, and a hands-off agent's work is not on this machine. A build's live chat comes after the loop.
-
-#### Business logic
-
-The loop drives the agent's [6] existing driver session [15] in the agent's checkout [10] and writes what it does to the agent's event stream [16]. It reads each turn's [13] turn signals [17] with one reader kept for the whole loop, so ready for merge [18] fires once across every entry and an error restated on later entries is reported once (the reader's rules are `turn-gate.ts`'s). It runs with the agent's stop [12] signal, with a gate [19] answerer when a surface has one, and with the entry cap, 25 unless its caller sets another.
-
-### One entry per turn, fresh off the branch
-
-#### Context
-
-See `## Context`.
-
-#### Business logic
-
-Each round begins by checking for a stop [12]; a stopped agent [6] ends the loop before another entry. The round then fetches the `agent-data` branch [5] and reads the queue's open entries in file order, since a long-lived agent's local view may trail what other writers pushed; by the `queue` skill's [11] rules an entry is a markdown list item, a task checkbox counting only while unchecked, so a queue written in priority sections drains in priority order. The first open entry is the one to work. An empty queue, or none written at all, ends the loop as done: when at least one entry was worked, "Queue done: empty after N item(s)." is written to the event stream [16]; a loop that finds nothing on its first round writes nothing at all. On the first round the count is announced: "Queue: N open item(s).". Wherever the loop names the entry, an entry longer than 100 characters is cut to 100 characters followed by an ellipsis.
-
-### The gate before each entry
-
-#### Context
-
-**User story**: attended, the user decides before every entry whether the agent [6] goes on: the dashboard shows the card, and "Stop the queue loop" ends the loop and leaves the rest of the queue for later.
-
-#### Business logic
-
-Only when a surface can answer does the loop ask: a gate [19] titled "Start the next queue item? (N open)" with two options, "Work on: <the entry>", which is the recommended one, and "Stop the queue loop". Each round's gate is distinct from the one before, so a surface never confuses a new question with the answer it just gave. A pick [20] to stop writes "Queue loop stopped by you (N item(s) left)." to the event stream [16] and ends the loop with the reason "stopped"; the agent [6] itself is not ended, and the queue keeps its entries. Unattended [9], no gate is emitted and the entry is started.
-
-### The prompt for one entry
-
-#### Context
-
-See `## Context`.
-
-#### Business logic
-
-"Queue item K: <the entry>" is written to the event stream [16], K counting the entries worked so far plus one, and the agent [6] is prompted with exactly "Work on exactly this task from the project's agent queue, and nothing else:", the entry, and "Complete it fully and verify your work. Do not start any other task; the framework takes this entry off the queue when the turn ends.". The turn [13] is a turn like any other: a gate [19] it stops at is answered and the agent resumed, up to the await limit [21] (the rounds are `await-gate.ts`'s), and its views, errors, ready-for-merge [18] signal and pull request are read. The entry counts as worked once the turn is over, whatever the turn produced.
-
-### A rejecting pick ends the whole agent
-
-#### Context
-
-**Problem**: a plan the user declined inside an entry's turn [13] must not be followed by the handoff [22] publishing the very work that was rejected.
-
-#### Business logic
-
-When a gate [19] inside the entry's turn [13] is answered with a pick [20] marked to stop, the loop writes "Session stopped by your answer (N item(s) left)." to the event stream [16] and ends with the reason "stopped" together with the mark that the whole agent [6] is stopped; the agent lifecycle then ends the agent as stopped by the user's answer, and no handoff [22] runs. This is distinct from "Stop the queue loop" at the gate before an entry, which ends only the loop.
-
-### The Framework takes the entry off the queue
-
-#### Context
-
-**Problem**: the agent's [6] checkout [10] does not hold the `agent-data` branch [5], and every edit of the queue must go through the one writer; and re-doing finished work is worse than stopping with the queue intact.
-
-#### Business logic
-
-After the turn [13], the entry is taken off the queue through the `queue` skill [11], which re-reads the fresh queue before writing and counts an entry already gone, removed by someone else meanwhile, as landed. The removal is tried up to two times in a row; when neither lands, "Queue loop stopped: "<the entry>" could not be taken off the queue after 2 attempt(s)." is written to the event stream [16] and the loop ends with the reason "stalled", the queue left as it was.
-
-### Bounds
-
-#### Context
-
-**Problem**: an unattended [9] agent [6] must not work an unbounded queue on one subscription; and a stop [12] must end the loop without extra narration, since the agent is ending anyway.
-
-#### Business logic
-
-At most 25 entries are worked in one agent [6] unless the caller sets another cap. When the cap is reached, the queue is read again from the `agent-data` branch [5] as this machine last saw it, without fetching: when it is empty the loop ends as done, otherwise "Queue loop stopped at the 25-item cap; N item(s) left." is written to the event stream [16] and the loop ends with the reason "max-items". A stop [12] that arrives mid-loop ends it with the reason "stopped" and writes nothing. The result names how many entries were worked, whatever their outcome, and why the loop ended.
-
-### The next queued ticket
-
-#### Context
-
-**User story**: the Overview [8] shows which ticket is being implemented; when a drain [7] starts, its lane must name the ticket the drain is about to pick up.
-
-#### Business logic
-
-The next queued ticket is the ticket the queue's first open entry links to, read from the `agent-data` branch [5] as this machine last saw it, without fetching: the same copy the sweep [23] consults when it decides whether there is anything to drain [7], so the entry named is the entry that decision was made on. "First" is the queue's first open entry, because the "Drain queue" preset works the first open entry only and the queue reads in file order. Which entry links to a ticket is the `tickets` skill's [11] rule: only a markdown link into `tickets/`. An empty queue, or a first open entry that is plain text, names no ticket, even when a later entry links to one. It is a best guess by construction: the agent [6] reads the queue a moment later, and an entry taken off in between moves it on. Being wrong costs a mislabeled lane on the Overview [8] and nothing else, since no agent is started or steered by it.
-
-### A hand-started drain
-
-#### Context
-
-**Problem**: the daemon knows its own drain [7] by a mark on the routine [24], but a drain the user starts from the dashboard arrives as bare prompt text; unrecognized, the ticket it implements would sit in no lane on the Overview [8].
-
-#### Business logic
-
-A prompt is a drain [7] when, trimmed, it equals the rendered "Drain queue" preset exactly (the comparison is `preset-catalog.ts`'s), so a prompt that merely mentions the queue is not one. For a drain, the ticket the agent [6] is about to implement is the next queued ticket; for any other prompt, none. A failure to read the queue names no ticket and never fails the start: it is a lane label, not an agent.
-
-### The agent's own backlog withholds the merge
-
-#### Context
-
-**Business logic story**: the ready-for-merge [18] signal is the agent's [6] own word that it is done and what authorizes the handoff's [22] merge. This check is a safety belt beside that word: it catches an agent declaring done while its own session backlog file still says otherwise, and nothing more.
-
-#### Business logic
-
-An agent's [6] own backlog is the file `TODO_<session name>.agent.md` at the root of its checkout [10], the file a research preset or a very large scope has the agent keep for its own work, where the session name [25] is the agent's. It still has open work when that file exists and holds at least one open entry by the `queue` skill's [11] entry rules; a file with every checkbox ticked has none. No session name, a name that cannot name a file (only letters, digits, dots, underscores and dashes can; a path separator above all cannot), and a missing or unreadable file all count as no open work: pendingness unknown is not pendingness. The agent queue [1] is never consulted here: it is decoupled from agents, and withholding on it would mean an armed merge never fires while the project has any backlog at all. The handoff [22] in `cli.ts` uses this to withhold an armed merge once the agent has signaled ready for merge [18]; the push and the pull request go ahead regardless.
diff --git a/packages/framework/src/todo-loop.test.BUG-ANALYSIS.md b/packages/framework/src/todo-loop.test.BUG-ANALYSIS.md
deleted file mode 100644
index 21e8ae498..000000000
--- a/packages/framework/src/todo-loop.test.BUG-ANALYSIS.md
+++ /dev/null
@@ -1 +0,0 @@
-Last analyzed: [25 August 2026](https://github.com/framework/the-framework/pull/1698)
diff --git a/packages/framework/src/todo-loop.test.LOGIC.md b/packages/framework/src/todo-loop.test.LOGIC.md
deleted file mode 100644
index 169f80839..000000000
--- a/packages/framework/src/todo-loop.test.LOGIC.md
+++ /dev/null
@@ -1,14 +0,0 @@
-What the tests cover, against a real repository whose queue lives on the `agent-data` branch:
-
-- **Working the queue to empty** - two entries are worked one turn each, each prompt naming its entry and saying that The Framework takes it off the queue; the queue on the branch ends empty; the opening count, each entry and the completion line are written to the event stream; unattended, no gate is emitted.
-- **No queue** - without a queue the loop ends as done with nothing worked and writes nothing.
-- **The gate before each entry** - attended, a gate precedes each entry with "Work on: <the entry>" as the recommended option, each round's gate distinct from the last; picking to stop after one entry ends the loop as stopped, says so, and leaves the second entry on the branch.
-- **A removal that cannot land** - when the branch's write funnel is broken, the entry is worked once, the loop ends as stalled saying the entry could not be taken off the queue, and the queue is left untouched.
-- **The entry cap** - a cap of two over three entries works two, ends as capped, says one entry is left, and leaves the third on the branch.
-- **Gates inside an entry's turn** - an entry turn that stops to ask is answered and resumed with the pick like any gate, the entry's own gate coming first and the agent's question second.
-- **A stop before the first entry** - an already stopped agent works nothing and ends as stopped.
-- **Signals on backlog turns** - a backlog turn's view, its reported error with headline and detail, and its ready-for-merge signal reach the event stream; ready for merge is emitted once across several entries that each signal it.
-- **The next queued ticket** - an empty queue names none; the first open entry's ticket link is named, skipping a checked entry above it and an entry in a lower priority section; a first open entry of plain text names none even when the next entry links to a ticket.
-- **A hand-started drain** - the rendered "Drain queue" preset names the next queued ticket, with or without surrounding whitespace; any other prompt, another preset, and an empty prompt name none; a queue read that fails names none rather than failing the start.
-- **One drain** - the daemon's drain routine is marked as a drain and its prompt is recognized as one; no other Auto PM routine's prompt counts as a drain.
-- **The agent's own backlog** - a missing file means nothing pending; the session's file with an open entry withholds and a fully checked one releases; no session name, or one that cannot name a file, means nothing pending.
diff --git a/packages/framework/src/turn-gate.LOGIC.md b/packages/framework/src/turn-gate.LOGIC.md
index 371f668be..0040075d5 100644
--- a/packages/framework/src/turn-gate.LOGIC.md
+++ b/packages/framework/src/turn-gate.LOGIC.md
@@ -24,7 +24,7 @@ Reads the turn signals [1] off a turn's [2] final message, the one place The Fra
 [14] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 [15] vanilla: an agent started without the built-in system prompt but with the signal protocols kept.
 [16] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
-[17] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
+[17] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command run as `npx <skill>`, and an API the product calls.
 [18] handoff: what happens to an agent's work when the agent ends, as one ladder of four levels: `local` (keep the work in its checkout), `push` (push its branch), `pr` (also open a pull request — the default), `merge` (also merge it).
 [19] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
 [20] build agent / prompt agent: the two kinds of agent: a build works the agent queue after its opening exchange; a prompt agent runs one prompt and stops there.
diff --git a/packages/framework/src/worktrees.LOGIC.md b/packages/framework/src/worktrees.LOGIC.md
index 4152cc2bc..849605a17 100644
--- a/packages/framework/src/worktrees.LOGIC.md
+++ b/packages/framework/src/worktrees.LOGIC.md
@@ -12,7 +12,7 @@ Lists, removes and deletes the checkouts [1] that a project's agents [2] leave u
 [2] agent: the unit of work: one task worked by a coding agent under The Framework's control — in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
 [3] retained checkout: a checkout still on disk after its agent ended.
 [4] sweep: a background job the daemon runs on its clock: Auto PM, the CI watch, the notification watchers, the sweep that reclaims checkouts (the daemon's log calls it the "worktree sweep"), the branch-links sweep, the cloud scratch sweep, cloud work adoption.
-[5] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command on the agent's PATH, and an API the product calls.
+[5] skill: one of the four capabilities an agent is taught — `branches`, `tickets`, `queue`, `logs` — each a package with the instructions the agent reads, a command run as `npx <skill>`, and an API the product calls.
 [6] cloud session: a Claude Code cloud session on claude.ai, the far end of a `web` agent.
 [7] stop: ending an agent before it finishes: the Stop button, Ctrl-C, or a pick marked to stop.
 [8] agent id: an agent's stable id, derived from the moment it started; it names the agent's checkout directory, its branch until the agent names it, and its run.
@@ -22,7 +22,7 @@ Lists, removes and deletes the checkouts [1] that a project's agents [2] leave u
 [12] location: where an agent's turns run: `local` (this machine), `actions` (a GitHub Actions runner), or `web` (a Claude Code cloud session).
 [13] cloud anchor: an empty commit a web agent pushes before its task leaves this machine, unique to the agent: the branch the cloud session later pushes descends from it.
 [14] birth branch: the branch a checkout is created on, `agent-<agent id>`, which also names the checkout's directory; the agent's branch until the agent names its work.
-[15] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the ticket, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
+[15] run: only the `logs` skill's record of one agent on the `agent-data` branch: a card (what was asked, the branch, the pull request, how it ended, what it cost) and a diary (what the agent said).
 [16] the `agent-data` branch: the branch of a project's repository used as a file store for everything agents share: tickets, the agent queue, the runs, routine locks.
 [17] event stream: everything an agent does, one event per line appended to `.the-framework/events.jsonl` in its checkout; every surface (dashboard, terminal, archive, run) is a projection of it.
 

From 2fc446aca6ba50021b694feaa775bc31dd3f1fe9 Mon Sep 17 00:00:00 2001
From: Suleiman Shahbari <suleiman@averotech.com>
Date: Mon, 14 Sep 2026 00:06:57 +0300
Subject: [PATCH 3/5] The routine skill moves to its own package,
 @gemstack/routines

Two kinds of skill: capability skills (branches, tickets, queue, logs),
a SKILL.md and a command each; routine skills, a SKILL.md only, each a
job that composes capabilities. A routine names the capabilities it
uses and a capability never names another skill, so a routine cannot
live in a capability package. The routines package holds them, one
folder per routine under skills/, the skills-npm layout; the framework
depends on it and links the file into every checkout it makes.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DAh91ACHayiEsgT1k2i8Nf
---
 packages/framework/package.json                 | 10 +++++-----
 packages/framework/src/auto-pm.test.ts          |  8 +++++---
 packages/framework/src/auto-pm.ts               |  5 +++--
 packages/framework/src/daemon-runtime.ts        | 15 +++++++--------
 packages/framework/src/daemon-workspace.test.ts |  2 +-
 packages/routines/package.json                  | 17 +++++++++++++++++
 packages/routines/skills/work-queue/SKILL.md    |  7 +++++++
 pnpm-lock.yaml                                  |  5 +++++
 8 files changed, 50 insertions(+), 19 deletions(-)
 create mode 100644 packages/routines/package.json
 create mode 100644 packages/routines/skills/work-queue/SKILL.md

diff --git a/packages/framework/package.json b/packages/framework/package.json
index 61320d813..0672f058d 100644
--- a/packages/framework/package.json
+++ b/packages/framework/package.json
@@ -27,8 +27,7 @@
     "node": ">=22.12.0"
   },
   "files": [
-    "dist",
-    "skills"
+    "dist"
   ],
   "bin": {
     "the-framework": "dist/bin.js"
@@ -48,11 +47,11 @@
   "dependencies": {
     "@base-ui-components/react": "1.0.0-rc.0",
     "@gemstack/agent-data": "workspace:*",
+    "@gemstack/routines": "workspace:*",
     "@gemstack/skill-branches": "workspace:*",
-    "@gemstack/skill-tickets": "workspace:*",
-    "@gemstack/skill-queue": "workspace:*",
     "@gemstack/skill-logs": "workspace:*",
-    "agent-driver": "workspace:*",
+    "@gemstack/skill-queue": "workspace:*",
+    "@gemstack/skill-tickets": "workspace:*",
     "@puppeteer/browsers": "3.2.1",
     "@shadcn/react": "^0.2.1",
     "@tiptap/core": "^2.10.0",
@@ -60,6 +59,7 @@
     "@tiptap/react": "^2.10.0",
     "@tiptap/starter-kit": "^2.10.0",
     "@tiptap/suggestion": "^2.10.0",
+    "agent-driver": "workspace:*",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",
     "lucide-react": "^0.469.0",
diff --git a/packages/framework/src/auto-pm.test.ts b/packages/framework/src/auto-pm.test.ts
index a744d487a..cadc93ce7 100644
--- a/packages/framework/src/auto-pm.test.ts
+++ b/packages/framework/src/auto-pm.test.ts
@@ -1,7 +1,8 @@
 import { strict as assert } from 'node:assert'
 import { test } from 'node:test'
 import { readFileSync } from 'node:fs'
-import { fileURLToPath } from 'node:url'
+import { createRequire } from 'node:module'
+import { dirname, join } from 'node:path'
 import {
   autoPmDecision,
   quotaHeadroom,
@@ -545,10 +546,11 @@ test('a stand-down is logged when it is news, not once a minute (#1774)', async
 
 test('AUTO_PM_WORK_JOB fires the routine skill by its slash command, and lands its own PRs (#1216/#1774)', () => {
   // The prompt is the skill's name as a slash command; the agent's harness expands it. The skill
-  // file ships with this package, and only a person or the daemon may invoke it.
+  // file ships in the routines package, and only a person or the daemon may invoke it.
   assert.equal(AUTO_PM_WORK_JOB.prompt, `/${WORK_QUEUE_SKILL_NAME}`)
   assert.equal(AUTO_PM_WORK_JOB.works, true)
-  const skill = readFileSync(fileURLToPath(new URL(`../skills/${WORK_QUEUE_SKILL_NAME}/SKILL.md`, import.meta.url)), 'utf8')
+  const routines = dirname(createRequire(import.meta.url).resolve('@gemstack/routines/package.json'))
+  const skill = readFileSync(join(routines, 'skills', WORK_QUEUE_SKILL_NAME, 'SKILL.md'), 'utf8')
   assert.match(skill, new RegExp(`^---\\nname: ${WORK_QUEUE_SKILL_NAME}\\n`))
   assert.match(skill, /\ndisable-model-invocation: true\n/)
   // What the agent is told: one task, commit but do not push, committed counts as published,
diff --git a/packages/framework/src/auto-pm.ts b/packages/framework/src/auto-pm.ts
index f1ade45d1..0d1644e50 100644
--- a/packages/framework/src/auto-pm.ts
+++ b/packages/framework/src/auto-pm.ts
@@ -345,8 +345,9 @@ export const AUTO_PM_JOBS: readonly AutoPmJob[] = [
 
 /**
  * The routine skill the daemon fires on the queued work (#1774): `skills/work-queue/SKILL.md` in
- * this package, linked into every checkout the daemon makes, marked so that only a person or the
- * daemon invokes it. Its prompt is the slash command; the agent's harness expands it.
+ * the `@gemstack/routines` package, linked into every checkout the daemon makes, marked so that
+ * only a person or the daemon invokes it. Its prompt is the slash command; the agent's harness
+ * expands it.
  */
 export const WORK_QUEUE_SKILL_NAME = 'work-queue'
 
diff --git a/packages/framework/src/daemon-runtime.ts b/packages/framework/src/daemon-runtime.ts
index 87743c952..2f78e303a 100644
--- a/packages/framework/src/daemon-runtime.ts
+++ b/packages/framework/src/daemon-runtime.ts
@@ -1,7 +1,7 @@
 import { spawn, type ChildProcess } from 'node:child_process'
 import { closeSync, mkdirSync, openSync } from 'node:fs'
 import { basename, dirname, join, resolve } from 'node:path'
-import { fileURLToPath } from 'node:url'
+import { createRequire } from 'node:module'
 import { appendFile, mkdir, readFile, rm, stat, writeFile } from 'node:fs/promises'
 import { agentIdFromStartedAt, startedAtFromAgentId, readWorktreeAgent, restoreArchivedAgent, listAgents, findAgent, archivedAgentPaths, readLiveMetas, readLiveMeta, resolveAgentEventsPath, EVENTS_FILE, META_FILE, isPidAlive, toRunCard, diaryOf, fromDiaryLine, type AgentMeta } from './store/index.js'
 import { isGitRepo, nodeGitRunner, isGitTimeout } from '@gemstack/agent-data'
@@ -122,14 +122,13 @@ export function childEnv(daemonUrl: string | undefined, agentId: string | undefi
 
 /**
  * The routine skills the daemon fires (#1774), linked into every checkout it makes beside the
- * `branches` skill, through the branches package's caller-given list: `skills/work-queue/SKILL.md`
- * ships with this package, and the daemon starts the queued work with `/work-queue`. The skills
- * an agent composes — tickets, queue, logs — are the project's own tracked files, not the daemon's
- * to link.
+ * `branches` skill, through the branches package's caller-given list. They ship in the
+ * `@gemstack/routines` package, one `skills/<name>/SKILL.md` each, no code; the daemon starts the
+ * queued work with `/work-queue`. The skills an agent composes — tickets, queue, logs — are the
+ * project's own tracked files, not the daemon's to link.
  */
-export const ROUTINE_SKILLS: readonly SkillLink[] = [
-  { name: WORK_QUEUE_SKILL_NAME, dir: fileURLToPath(new URL(`../skills/${WORK_QUEUE_SKILL_NAME}/`, import.meta.url)) },
-]
+const ROUTINES_DIR = join(dirname(createRequire(import.meta.url).resolve('@gemstack/routines/package.json')), 'skills')
+export const ROUTINE_SKILLS: readonly SkillLink[] = [{ name: WORK_QUEUE_SKILL_NAME, dir: join(ROUTINES_DIR, WORK_QUEUE_SKILL_NAME) }]
 
 /** The daemon's signed write funnel to the data branch (`daemon-writes.ts`): the run's record is its own commit. */
 const funnel = daemonFunnel()
diff --git a/packages/framework/src/daemon-workspace.test.ts b/packages/framework/src/daemon-workspace.test.ts
index 67507ba2e..677e9e6b0 100644
--- a/packages/framework/src/daemon-workspace.test.ts
+++ b/packages/framework/src/daemon-workspace.test.ts
@@ -666,7 +666,7 @@ test("a spawned agent gets the daemon's PATH untouched, and its checkout links t
     // project's own dependencies, `npx tickets`, as its SKILL.md says.
     assert.equal(recorded.trim(), process.env['PATH'], "the agent's PATH is the daemon's own")
     // Two skills are linked into the checkout, where each harness looks for them: the branches
-    // package's own (#1739), and the routine skill the daemon fires (#1774). The skills an agent
+    // package's own (#1739), and the routine skill the daemon fires (#1774), from the routines package. The skills an agent
     // composes — tickets, queue, logs — are the project's tracked files, not links.
     const checkout = worktreePath(cwd, result.agentId!)
     for (const harnessDir of HARNESS_SKILL_DIRS) {
diff --git a/packages/routines/package.json b/packages/routines/package.json
new file mode 100644
index 000000000..5db7cb312
--- /dev/null
+++ b/packages/routines/package.json
@@ -0,0 +1,17 @@
+{
+  "name": "@gemstack/routines",
+  "version": "0.0.1",
+  "description": "The routines a daemon fires on its own: jobs for coding agents, one skill file each, that compose the tickets, queue and other capability skills of a project.",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/framework/the-framework.git",
+    "directory": "packages/routines"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "files": [
+    "skills"
+  ]
+}
diff --git a/packages/routines/skills/work-queue/SKILL.md b/packages/routines/skills/work-queue/SKILL.md
new file mode 100644
index 000000000..3ef564e60
--- /dev/null
+++ b/packages/routines/skills/work-queue/SKILL.md
@@ -0,0 +1,7 @@
+---
+name: work-queue
+description: Work one queued task off the project's agent queue, unattended.
+disable-model-invocation: true
+---
+
+Get tickets to work on. Nobody will answer you: never ask, decide yourself. Take one queued task only. Commit your work on your branch and do not push; the run that started you publishes your branch when you stop. For you, committed counts as published: once the work is committed, close its ticket and mark the queue entry done. Before you stop, release any claim you still hold unless you closed the ticket. If nothing is queued, say so and stop.
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index fb4df0358..d0a36df2e 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -50,6 +50,9 @@ importers:
       '@gemstack/agent-data':
         specifier: workspace:*
         version: link:../agent-data
+      '@gemstack/routines':
+        specifier: workspace:*
+        version: link:../routines
       '@gemstack/skill-branches':
         specifier: workspace:*
         version: link:../skill-branches
@@ -151,6 +154,8 @@ importers:
         specifier: ^4.1.10
         version: 4.1.10(@types/node@20.19.43)(jsdom@29.1.1)(vite@8.1.4(@types/node@20.19.43)(esbuild@0.28.1)(jiti@2.7.0)(tsx@4.22.4)(yaml@2.9.0))
 
+  packages/routines: {}
+
   packages/skill-branches:
     dependencies:
       '@gemstack/agent-data':

From 9620eb7a03ea7783072c98f34acaf2632045ed8a Mon Sep 17 00:00:00 2001
From: Suleiman Shahbari <suleiman@averotech.com>
Date: Mon, 14 Sep 2026 00:06:57 +0300
Subject: [PATCH 4/5] LOGIC.md and DECISIONS.md for the routines package

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DAh91ACHayiEsgT1k2i8Nf
---
 LOGIC.md                                      |  1 +
 packages/LOGIC.md                             |  1 +
 packages/framework/prompts/presets/LOGIC.md   |  2 +-
 packages/framework/skills/LOGIC.md            |  3 ---
 packages/framework/skills/work-queue/SKILL.md |  7 ------
 packages/framework/src/auto-pm.LOGIC.md       |  4 +--
 .../framework/src/daemon-runtime.LOGIC.md     |  2 +-
 .../framework/src/preset-catalog.LOGIC.md     |  2 +-
 packages/routines/DECISIONS.md                | 25 +++++++++++++++++++
 packages/routines/LOGIC.md                    | 12 +++++++++
 packages/routines/skills/LOGIC.md             |  3 +++
 .../skills/work-queue/SKILL.LOGIC.md          |  0
 12 files changed, 47 insertions(+), 15 deletions(-)
 delete mode 100644 packages/framework/skills/LOGIC.md
 delete mode 100644 packages/framework/skills/work-queue/SKILL.md
 create mode 100644 packages/routines/DECISIONS.md
 create mode 100644 packages/routines/LOGIC.md
 create mode 100644 packages/routines/skills/LOGIC.md
 rename packages/{framework => routines}/skills/work-queue/SKILL.LOGIC.md (100%)

diff --git a/LOGIC.md b/LOGIC.md
index 0845a9702..e0530e6f2 100644
--- a/LOGIC.md
+++ b/LOGIC.md
@@ -51,6 +51,7 @@ The Framework: autonomous AI programming. The user registers repositories as pro
 - `packages/agent-driver` — the driver [2] seam: one contract for driving a coding agent as a black box, with the Claude Code, Codex, GitHub Actions and fake implementations; the product adds its own cloud-session implementation behind the same contract. The Framework prompts one turn at a time, lets the coding agent's own loop run to completion, and learns everything from the turn's final message: it never gates on the agent's individual tool calls, holds no model key, and runs on the user's own subscription.
 - `packages/agent-data` — a branch of the project's repository used as a file store: the `agent-data` branch [6], checked out under `.branches/`, written through one sync → commit → push cycle that re-applies when a push loses a race. A library, not a skill: read by code, never by an agent. Every skill depends on it; nothing else does.
 - `packages/skill-branches`, `packages/skill-tickets`, `packages/skill-queue`, `packages/skill-logs` — the four skills [8]: an agent's own checkout [3] and branch; the tickets with their plans and claims; the agent queue [7]; the record of every run [18]. Tickets, queue, runs and routine locks live on the `agent-data` branch, never on a code branch, so the default branch stays code only. No skill depends on another.
+- `packages/routines` — the routines the daemon fires on its own, one skill file each and no code: jobs that compose the four skills [8], starting with the queued work; The Framework depends on it and fires a routine by its slash command.
 - `packages/chrome-extension` — the far end of the Claude web bridge [14], a Chrome extension reading claude.ai in a signed-in browser; it talks to the daemon over HTTP only.
 - `packages/the-framework.ai` — the marketing site at https://the-framework.ai; it presents the product and shares no code with it.
 - `.github/workflows` — every push builds, type-checks and tests the monorepo; the website deploys itself from the default branch; and one workflow is the far end of the `github-actions` driver implementation, running one turn per workflow run.
diff --git a/packages/LOGIC.md b/packages/LOGIC.md
index 083eddd39..ff1f9fab2 100644
--- a/packages/LOGIC.md
+++ b/packages/LOGIC.md
@@ -17,6 +17,7 @@ The deliverables The Framework ships, one directory each. The product is the `fr
 - **The `tickets` skill** (`skill-tickets/`) - the `@gemstack/skill-tickets` npm package: the project's tickets with their plans and claims on the `agent-data` branch, the `tickets` command that reads, writes, claims and closes them, and the skill text. Depends on `agent-data`.
 - **The `queue` skill** (`skill-queue/`) - the `@gemstack/skill-queue` npm package: the agent queue on the `agent-data` branch, the `queue` command that reads it, adds an entry at a priority and takes one off, and the skill text. Depends on `agent-data`.
 - **The `logs` skill** (`skill-logs/`) - the `@gemstack/skill-logs` npm package: the record of every run agents made on a project, on the `agent-data` branch, and the read-only `logs` command; the product writes every run through it. Depends on `agent-data`.
+- **The routines** (`routines/`) - the `@gemstack/routines` npm package: the jobs a daemon fires on its own, one skill file each under `skills/<name>/` and no code, each composing the capability skills of a project; the queued work first.
 - **The Claude web bridge's extension** (`chrome-extension/`) - a Chrome extension, not an npm package: the far end of the Claude web bridge [5], reading claude.ai in a signed-in browser. Talks to the product over HTTP only.
 - **The website** (`the-framework.ai/`) - the marketing site at https://the-framework.ai. Presents the product; shares no code with it.
 
diff --git a/packages/framework/prompts/presets/LOGIC.md b/packages/framework/prompts/presets/LOGIC.md
index 9620bf7ae..3681f5276 100644
--- a/packages/framework/prompts/presets/LOGIC.md
+++ b/packages/framework/prompts/presets/LOGIC.md
@@ -1,4 +1,4 @@
-The fourteen presets: the canned prompts behind the launcher's buttons and the daemon's rotation routines [2], one markdown file each. Five of them are quality passes over a target the user names; one sweeps the code and queues quality work; four are product management, proposing or picking tickets; four are the routines that keep the tickets and the agent queue [4] fresh. The routine that works the queue is not a preset: it is the skill file `../skills/work-queue/SKILL.md`, which only the daemon fires. The table in `src/preset-catalog.ts` says which button or routine each backs, in which order the launcher shows them, and appends the queue-only rule of `../triage_scope.md` to the two triage presets.
+The fourteen presets: the canned prompts behind the launcher's buttons and the daemon's rotation routines [2], one markdown file each. Five of them are quality passes over a target the user names; one sweeps the code and queues quality work; four are product management, proposing or picking tickets; four are the routines that keep the tickets and the agent queue [4] fresh. The routine that works the queue is not a preset: it is the skill file `skills/work-queue/SKILL.md` of the `@gemstack/routines` package, which only the daemon fires. The table in `src/preset-catalog.ts` says which button or routine each backs, in which order the launcher shows them, and appends the queue-only rule of `../triage_scope.md` to the two triage presets.
 
 ## Context
 
diff --git a/packages/framework/skills/LOGIC.md b/packages/framework/skills/LOGIC.md
deleted file mode 100644
index d6832bf89..000000000
--- a/packages/framework/skills/LOGIC.md
+++ /dev/null
@@ -1,3 +0,0 @@
-The routine skills The Framework ships: skill files the daemon fires, one directory each, linked into every checkout the daemon makes where the coding agent's harness looks for skills (`.claude/skills/<name>`, `.agents/skills/<name>`). Each is marked so that only a person or the daemon invokes it, and its body is the job's prompt: the daemon starts the agent with the skill's slash command and the harness expands it.
-
-- **Working the queue** (`work-queue/`) - one queued task off the agent queue, unattended; the routine the daemon fires when the `agent-data` branch moved (the rules in `../src/auto-pm.ts`).
diff --git a/packages/framework/skills/work-queue/SKILL.md b/packages/framework/skills/work-queue/SKILL.md
deleted file mode 100644
index 3ef564e60..000000000
--- a/packages/framework/skills/work-queue/SKILL.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-name: work-queue
-description: Work one queued task off the project's agent queue, unattended.
-disable-model-invocation: true
----
-
-Get tickets to work on. Nobody will answer you: never ask, decide yourself. Take one queued task only. Commit your work on your branch and do not push; the run that started you publishes your branch when you stop. For you, committed counts as published: once the work is committed, close its ticket and mark the queue entry done. Before you stop, release any claim you still hold unless you closed the ticket. If nothing is queued, say so and stop.
diff --git a/packages/framework/src/auto-pm.LOGIC.md b/packages/framework/src/auto-pm.LOGIC.md
index 323fbf3eb..41d89e12a 100644
--- a/packages/framework/src/auto-pm.LOGIC.md
+++ b/packages/framework/src/auto-pm.LOGIC.md
@@ -75,7 +75,7 @@ See `## Context`.
 
 #### Business logic
 
-A project whose branch moved [15] starts one agent [6] told `/work-queue`, the routine skill [22] shipped in this package and linked into every checkout the daemon makes (`daemon-runtime.ts`), unattended [16], with its handoff [18] at `merge`, since what it implements has already been triaged onto the queue where a human could have vetoed it. One agent per move, however high the concurrency cap: the next start needs the branch to move again, which the agent's own commits do. The start spends the move and the rotation's turn alike: whether the queue wants refilling is for this run to find out. A commit the daemon wrote itself is not a move: the run's record the daemon writes at teardown, a routine lock [10] it takes or drops, a claim [9] it mints for a plan agent all carry the trailer, on this machine and on every other machine running the daemon, so a record never starts the next run and two daemons on one branch never fire empty runs at each other's records. A person's writes from the dashboard — queue an entry, release a claim — carry no trailer and are moves: a person asking for work is exactly what should start a run.
+A project whose branch moved [15] starts one agent [6] told `/work-queue`, the routine skill [22] shipped in the `@gemstack/routines` package and linked into every checkout the daemon makes (`daemon-runtime.ts`), unattended [16], with its handoff [18] at `merge`, since what it implements has already been triaged onto the queue where a human could have vetoed it. One agent per move, however high the concurrency cap: the next start needs the branch to move again, which the agent's own commits do. The start spends the move and the rotation's turn alike: whether the queue wants refilling is for this run to find out. A commit the daemon wrote itself is not a move: the run's record the daemon writes at teardown, a routine lock [10] it takes or drops, a claim [9] it mints for a plan agent all carry the trailer, on this machine and on every other machine running the daemon, so a record never starts the next run and two daemons on one branch never fire empty runs at each other's records. A person's writes from the dashboard — queue an entry, release a claim — carry no trailer and are moves: a person asking for work is exactly what should start a run.
 
 ### The chain, and after an empty run the rotation
 
@@ -280,7 +280,7 @@ Before deciding, every agent this loop started on the project and has not yet be
 
 #### Business logic
 
-- The queued work [4] is the routine skill [22] `work-queue`: its name is the skill's, its prompt is the slash command `/work-queue`, its label "Work the queue" and its tooltip "Work one queued task off the agent queue, unattended." are written here, and it is declared as working the queue and as auto-merging its pull request. The skill file itself is `skills/work-queue/SKILL.md` in this package.
+- The queued work [4] is the routine skill [22] `work-queue`: its name is the skill's, its prompt is the slash command `/work-queue`, its label "Work the queue" and its tooltip "Work one queued task off the agent queue, unattended." are written here, and it is declared as working the queue and as auto-merging its pull request. The skill file itself is `skills/work-queue/SKILL.md` in the `@gemstack/routines` package, which The Framework depends on.
 - Each preset-backed routine carries the preset's stable name, which is what the rotation's position and the switched-off list key on; the prompt rendered from the preset; and the preset's label and one-line tooltip, read off the preset so a relabeled preset relabels its routine and the sentence the launcher shows for a preset and the sentence the routines list shows for its routine are the same sentence.
 - Only the maintenance routine carries a separate description line, "sweeping the codebase for maintenance work", because "Maintenance" names its preset rather than the work; the other routines' labels read as what they do, so their rows stay one line and their log lines say the label itself.
 - The planning routine is declared as fanning out [14]; the triage routines each declare their routine lock [10].
diff --git a/packages/framework/src/daemon-runtime.LOGIC.md b/packages/framework/src/daemon-runtime.LOGIC.md
index 2fada9eba..5cee92ce7 100644
--- a/packages/framework/src/daemon-runtime.LOGIC.md
+++ b/packages/framework/src/daemon-runtime.LOGIC.md
@@ -122,7 +122,7 @@ After the preflight, the agent's checkout is reused when it still exists; otherw
 
 #### Business logic
 
-A new agent's id is derived from the moment of the start, unless the caller minted the id first: a sweep [15] that claimed a ticket for the agent wrote the claim [24] under the id it now starts the agent with. The checkout is created by the `branches` skill [11] in one sequence: a git worktree under the project's `.branches/` directory on a fresh branch `agent-<agent id>`, `.branches/` hidden from git, the project's dependency trees linked in, and the routine skill `work-queue` — the skill file shipped in this package that the daemon starts the queued work with — linked in beside `branches` where the coding agent's [18] harness looks for skills. The `tickets`, `queue` and `logs` skills are the project's own tracked files, not the daemon's to link.
+A new agent's id is derived from the moment of the start, unless the caller minted the id first: a sweep [15] that claimed a ticket for the agent wrote the claim [24] under the id it now starts the agent with. The checkout is created by the `branches` skill [11] in one sequence: a git worktree under the project's `.branches/` directory on a fresh branch `agent-<agent id>`, `.branches/` hidden from git, the project's dependency trees linked in, and the routine skill `work-queue` — the skill file from the `@gemstack/routines` package that the daemon starts the queued work with — linked in beside `branches` where the coding agent's [18] harness looks for skills. The `tickets`, `queue` and `logs` skills are the project's own tracked files, not the daemon's to link.
 
 A project that is not a git repository cannot be given a checkout: its agents run in the project's own checkout, one at a time since they would collide, and the daemon logs "[framework] <project> is not a git repository, so it gets no worktree; running in the main checkout". A project that is a repository but whose checkout could not be created does not fall back to the user's checkout: the start is refused with "could not create a worktree for this run: <reason>", the dashboard shows it, and starting again is the retry, because a failed agent is recoverable and a user's checkout with an agent's edits mixed in is not. When the creation was cut short by its time budget, the partial directory it left is removed; a failure of any other kind leaves the directory alone, since it may be a path that was on disk before this agent asked for it.
 
diff --git a/packages/framework/src/preset-catalog.LOGIC.md b/packages/framework/src/preset-catalog.LOGIC.md
index 6bfae2f6f..15921b520 100644
--- a/packages/framework/src/preset-catalog.LOGIC.md
+++ b/packages/framework/src/preset-catalog.LOGIC.md
@@ -100,7 +100,7 @@ The "Update from GitHub" row is marked as always running in an agent of its own.
 
 #### Business logic
 
-The launcher [1] shows fourteen buttons, in this order: "Research", "Readability", "Maintainability", "Security audit", "UX (auto)", "Suggest new tickets", "Suggest new features", "Suggest tickets to work on", "Plan tickets (aka spike)", "Market research", "Update from GitHub", "Maintenance", "Add quick-win work to AI Queue", "Add consensual work to AI Queue": every preset. The routine that works the agent queue [4] is not a preset but the skill file `skills/work-queue/SKILL.md`, which only the daemon fires (the rules in `auto-pm.ts`).
+The launcher [1] shows fourteen buttons, in this order: "Research", "Readability", "Maintainability", "Security audit", "UX (auto)", "Suggest new tickets", "Suggest new features", "Suggest tickets to work on", "Plan tickets (aka spike)", "Market research", "Update from GitHub", "Maintenance", "Add quick-win work to AI Queue", "Add consensual work to AI Queue": every preset. The routine that works the agent queue [4] is not a preset but the skill file `skills/work-queue/SKILL.md` of the `@gemstack/routines` package, which only the daemon fires (the rules in `auto-pm.ts`).
 
 ### Which presets may run unattended
 
diff --git a/packages/routines/DECISIONS.md b/packages/routines/DECISIONS.md
new file mode 100644
index 000000000..ecd1431a0
--- /dev/null
+++ b/packages/routines/DECISIONS.md
@@ -0,0 +1,25 @@
+Non-obvious decisions only, grouped by business-logic flow. Anything not listed is left
+to the implementer's judgment. Flag conflicts instead of silently deviating. Keep
+outdated decisions (no history).
+
+A bullet is a person's pick, and says what it was picked over. What the code does belongs
+in LOGIC.md; a choice made while implementing is the implementer's judgment, not a
+decision. An AI proposes a bullet and asks; it never adds or rewrites one.
+
+## Routines
+- Two kinds of skill: capability skills (`branches`, `tickets`, `queue`, `logs`), each a
+  SKILL.md and a command, each saying how to do one thing; and routine skills, each a
+  SKILL.md only, each a job that composes capabilities. A routine names the capabilities
+  it uses; a capability never names another skill. Picked over shipping a routine inside
+  the capability package it mostly uses (the queue's), which would make that package know
+  about tickets.
+- Routines are their own package, SKILL.md files only, under `skills/<name>/`. Picked over
+  the framework package's own `skills/` folder, so a project can install the routines
+  without the daemon and can replace one with its own; and over one package per routine,
+  which gains nothing while every routine is a single file.
+- A routine is marked `disable-model-invocation`: a person or a daemon fires it, the
+  agent never picks it on its own.
+- The daemon fires a routine by its name, `/work-queue`; the agent's harness expands the
+  skill. The routine's words are the rules of the job — one task, commit but do not push,
+  committed counts as published, say so and stop when nothing is queued — never a skill's
+  name or command.
diff --git a/packages/routines/LOGIC.md b/packages/routines/LOGIC.md
new file mode 100644
index 000000000..70d17ed90
--- /dev/null
+++ b/packages/routines/LOGIC.md
@@ -0,0 +1,12 @@
+The `@gemstack/routines` npm package: the routines [1] a daemon fires on its own, one skill file each under `skills/<name>/SKILL.md`, no code. A routine is a job for a coding agent [2] that composes the capability skills [3] of a project; it names no command and no package, and it is marked so that only a person or a daemon invokes it, never the agent by itself. The Framework's daemon depends on this package and starts an agent with a routine's slash command, `/work-queue`; a project that installs the skills without The Framework can fire the same routine by hand or from another runner.
+
+## Glossary
+
+[1] routine: a job the daemon fires on its own — the queued work, and later update tickets, triage quick, triage consensual, plan tickets, maintenance — each switchable off and runnable on demand.
+[2] agent: the unit of work: one task worked by a coding agent under a runner's control, in its own checkout, on its own branch.
+[3] capability skill: a skill that says how to do one thing and ships its command — `branches`, `tickets`, `queue`, `logs`; a routine composes them and none of them knows another.
+
+## Business logic — TL;DR
+
+- **One folder per routine** (`skills/`) - the skills-npm layout, so a tool that scans `node_modules/**/skills/*/SKILL.md` finds them and `$ skills` can copy them into a project.
+- **Working the queue** (`skills/work-queue/`) - one queued task off the agent queue, unattended.
diff --git a/packages/routines/skills/LOGIC.md b/packages/routines/skills/LOGIC.md
new file mode 100644
index 000000000..b1bafc402
--- /dev/null
+++ b/packages/routines/skills/LOGIC.md
@@ -0,0 +1,3 @@
+The routine skills: one folder per routine, each holding the `SKILL.md` the daemon fires, marked so that only a person or the daemon invokes it. Its body is the job's prompt: the daemon starts the agent with the skill's slash command and the coding agent's harness expands it.
+
+- **Working the queue** (`work-queue/`) - one queued task off the agent queue, unattended; the routine The Framework's daemon fires when the `agent-data` branch moved (the rules in `packages/framework/src/auto-pm.ts`).
diff --git a/packages/framework/skills/work-queue/SKILL.LOGIC.md b/packages/routines/skills/work-queue/SKILL.LOGIC.md
similarity index 100%
rename from packages/framework/skills/work-queue/SKILL.LOGIC.md
rename to packages/routines/skills/work-queue/SKILL.LOGIC.md

From ec333e6971f39443906eae89b0dadb1cdba11a7b Mon Sep 17 00:00:00 2001
From: Suleiman Shahbari <suleiman@averotech.com>
Date: Mon, 14 Sep 2026 16:10:57 +0300
Subject: [PATCH 5/5] The work-queue command says so when the project has no
 ticketing system or no AI queue

Rom's note on #1774: a command assumes no capability; where it would be
broken without one, it tells the user in capability words and stops.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DAh91ACHayiEsgT1k2i8Nf
---
 packages/framework/src/auto-pm.test.ts             | 3 +++
 packages/routines/skills/work-queue/SKILL.LOGIC.md | 1 +
 packages/routines/skills/work-queue/SKILL.md       | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/packages/framework/src/auto-pm.test.ts b/packages/framework/src/auto-pm.test.ts
index cadc93ce7..85c83c75b 100644
--- a/packages/framework/src/auto-pm.test.ts
+++ b/packages/framework/src/auto-pm.test.ts
@@ -559,6 +559,9 @@ test('AUTO_PM_WORK_JOB fires the routine skill by its slash command, and lands i
   assert.match(skill, /do not push/)
   assert.match(skill, /committed counts as published/)
   assert.match(skill, /If nothing is queued, say so and stop/)
+  // Rom's note (#1774): a command assumes no capability; when it would be broken without one, it says so in capability words, never a skill's name.
+  assert.match(skill, /no ticketing system or no AI queue, show an error to the user and stop/)
+  assert.doesNotMatch(skill, /`tickets`|`queue`|npx/)
   // The queued work implements entries whose triage a human could have vetoed, so its review
   // happened before the agent. Every other job writes tickets/plans and has nothing to merge.
   assert.equal(AUTO_PM_WORK_JOB.autoMerge, true)
diff --git a/packages/routines/skills/work-queue/SKILL.LOGIC.md b/packages/routines/skills/work-queue/SKILL.LOGIC.md
index df01f42ad..8247ff305 100644
--- a/packages/routines/skills/work-queue/SKILL.LOGIC.md
+++ b/packages/routines/skills/work-queue/SKILL.LOGIC.md
@@ -14,3 +14,4 @@ The `work-queue` routine skill: the prompt of the agent the daemon starts on the
 - **Committed counts as published** - once the work is committed it closes the task's ticket and marks the queue entry done, so a ticket whose skill says "close once published" is closed rather than left open.
 - **Release before stopping** - any claim it still holds is released unless it closed the ticket.
 - **Nothing queued** - it says so and stops.
+- **No ticketing system, no AI queue** - it shows an error to the user and stops; the note is in capability words and names no skill.
diff --git a/packages/routines/skills/work-queue/SKILL.md b/packages/routines/skills/work-queue/SKILL.md
index 3ef564e60..9e93e5cff 100644
--- a/packages/routines/skills/work-queue/SKILL.md
+++ b/packages/routines/skills/work-queue/SKILL.md
@@ -4,4 +4,4 @@ description: Work one queued task off the project's agent queue, unattended.
 disable-model-invocation: true
 ---
 
-Get tickets to work on. Nobody will answer you: never ask, decide yourself. Take one queued task only. Commit your work on your branch and do not push; the run that started you publishes your branch when you stop. For you, committed counts as published: once the work is committed, close its ticket and mark the queue entry done. Before you stop, release any claim you still hold unless you closed the ticket. If nothing is queued, say so and stop.
+Get tickets to work on. Nobody will answer you: never ask, decide yourself. Take one queued task only. Commit your work on your branch and do not push; the run that started you publishes your branch when you stop. For you, committed counts as published: once the work is committed, close its ticket and mark the queue entry done. Before you stop, release any claim you still hold unless you closed the ticket. If nothing is queued, say so and stop. If this project has no ticketing system or no AI queue, show an error to the user and stop.