The daemon reads no queue: it starts /work-queue when the agent-data branch moves

[suleimansh]

👤 My picks for this PR, in my words as I gave them to the agent:

• Where the routine file lives: "lets go with Rom rule" (skills don't know each other), then "yes I prefer B" (its own package) and "now, in The daemon reads no queue: it starts /work-queue when the agent-data branch moves #1777".
• The chain and the cooldown: "Chain ignores the cooldown".
• How the daemon tells its own commits apart: "Yes, the line 'Daemon: '".
• At boot: "Just remember the head".
• After Rom's review: "Yes, we can go with Command skills"; his note goes into the command.

What to look at: the first section below, the "What remains" list, and the proof at the end. Every prompt I gave for this PR is in the 👤 comment on this PR, verbatim.

The daemon half of #1774, step 2 of Q6. Built as posted in the plan, six picks as picked.

🤖 automated · Fable 5.1, effort high

What the daemon does now

The daemon reads no queue and names no skill. It watches the head of the agent-data branch, once a minute, right behind its own pull. When the branch moved by a commit no daemon wrote, it starts one agent told /work-queue. The agent reads the skills in its checkout and takes one queued task. Its claim, close and done are commits, so the branch has moved again by the time the run ends, and the daemon fires again on the next look. A run that finds nothing queued writes nothing, and the chain stops. Then the rotation gets its turn. One run a day is the belt when nothing moved.

The routine is a skill file, skills/work-queue/SKILL.md in a new package, @gemstack/routines, the first preset converted for #1770. Its body is the prompt from the plan, "committed counts as published" included, plus Rom's note from the review: no ticketing system or no AI queue, show an error to the user and stop. Rom named this kind "command skills"; the rename to that name, and one package per command, wait for his name shape. It is marked disable-model-invocation, so only a person or the daemon invokes it. The framework depends on the package and links the file into every checkout it makes, beside the branches skill. The routines list shows it as "Work the queue"; Run now on that row starts one agent on the queue in every project.

Two kinds of skill from here. Capability skills, branches, tickets, queue, logs: a SKILL.md and a command each, each saying how to do one thing. Routine skills: a SKILL.md only, no code, each a job that composes capabilities. A routine names the capabilities it uses; 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. A project can install them without the daemon and replace one with its own. The picks are in packages/routines/DECISIONS.md.

How the daemon tells its own commits apart

A run's record, a routine lock and a plan claim are commits the daemon writes. Counted as moves, every record would start the next run, forever. Two daemons sharing the branch would fire empty runs at each other's records without end. So every automatic write goes through one funnel, src/daemon-writes.ts, that ends the commit message with a git trailer:

logs: record run 2026-09-13T19-00-52-977Z

Daemon: Suleimans-MacBook-Pro.local

The trigger counts the commits since its last look that carry no Daemon: trailer. A person's write from the dashboard (queue an entry, release a claim) takes the skills' plain funnel and carries none: that is a move, as it should be.

What stays as it was

The quota gate, the concurrency cap and the rotation's 30 minute cooldown. The cooldown paces the rotation only. A move of the branch, from a person or an agent, is never paced, so the chain runs back to back. The rotation fires after a run that moved nothing, and keeps its start-up turn on a daemon that boots with the setting on. The first look after boot only remembers the head: a restart starts no run on the queue.

What goes

• prompts/presets/drain_queue.md, its catalog row, and the exact-text match that recognised a hand-fired drain.
• In auto-pm.ts: the drain job, the pinned prompt, the drain mode of the decision, the drain batch and its claims, the settle half that deleted the entry and freed the claim, the "ended dry" memory for entries. The plan fan-out keeps its claims and its dead-claim release; that is the follow-up's design.
• In daemon-services.ts: the queue read, the drain claim and release, the promote, the ticket named on the start.
• todo-loop.ts whole, with its 13 tests, and the merge-gate belt that read the session's own TODO file with the queue parser. The agent's ready-for-merge signal is the authorization now.
• In daemon-runtime.ts: the PATH entries, the three skill links in every checkout, and AGENT_ID as an import from the tickets skill. AGENT_ID_ENV is the framework's own constant in agent-id.ts.
• In cli.ts: the ticket start option, the (fix #N) read from the ticket for the PR title, the ticket event. With them the card's ticket field, the meta's, and the Overview's "implementing" lane, which the dashboard half brings back from the claim.
• The per-tick data sync: the tickets sync then the queue sync become one pull of agent-data through the shared branch library. The root tickets link and the queue seed leave the daemon; they belong to the skills' own setup.

What remains

Named here so the follow-ups have a list.

• The rotation's tickets imports in daemon-services.ts: update tickets, triage quick, triage consensual, plan tickets. Plan tickets still reads and claims tickets in the daemon.

• The dashboard's tickets and queue imports.

• The two package dependencies, @gemstack/skill-tickets and @gemstack/skill-queue; the queue one only for the dashboard now.

• Two imports the plan keeps until step 4: the checkout from the branches package, the record write from the logs package.

• The scheduler, auto-pm.ts, knows the routines by name: the list, its order, which one works the queue, which one fans out, which two take a lock. Adding a routine means editing the daemon.

Four follow-up PRs, one rotation job each, each becoming a folder in the routines package the same way: update tickets, triage quick, triage consensual, then plan tickets last, since its fan-out claims tickets in the daemon and needs its own design.

Then two more, in this order:

• Routines declare their own trigger in the SKILL.md front matter (the branch moved; after a run that found nothing, in order; once a week). The daemon reads the routines folder and fires by the declared trigger, so it knows no names, and a user's own routine is fired by dropping a folder in.
• The scheduler becomes a package: the trigger, the gates, the rotation, the heartbeat, the routine locks and the signed writes, as a library the daemon wires, like agent-driver and agent-data. Another runner, or a cron job, can then fire routines without the dashboard. Its policy is already one function with every reading injected; the move waits for the trigger step so no name moves with it.

Temporary

• The framework links work-queue into checkouts through the branches package's caller list. That list was marked temporary for the tickets, queue and logs skills; those three links are gone, and the list now carries the routines package's skill. The comment in skill-branches says so. If Replace presets in favor of skills with disable-model-invocation #1770 ends with projects tracking the routine skills too, the list goes.
• The label and tooltip of the queued-work routine are written in auto-pm.ts, since it has no preset. Once the launcher reads skill files (Replace presets in favor of skills with disable-model-invocation #1770), the skill's own description is the sentence.

Cutover

The daemon no longer links the tickets, queue and logs skills into checkouts, and puts nothing on an agent's PATH. After merging, each project must track the three SKILL.md files under .agents/skills/<name>/ (with the .claude/skills/<name> links), and list the four @gemstack/skill-* packages in its dependencies so npx tickets resolves. gemstack lists the packages already; the files are not tracked yet in any project. Until a project tracks them, its agents see no skills. Then restart the daemon.

Preference files that opted out drain-queue name a routine that no longer exists; the entry is inert.

Tests

• auto-pm.test.ts: the trigger and the chain with a fake branch and fake starts. The first look remembers and starts nothing on the queue. A commit no daemon wrote starts the queued work once. A daemon's commit is not a move. The chain over three tasks under a cap of one, ending on the empty run. The rotation after an empty run, and a move taking the turn back. A move is not paced by the cooldown, the rotation is. The heartbeat. Run now on the row. The routine switched off. An unreadable branch. The stand-down logged once until it changes.
• daemon-writes.test.ts: real git. The funnel's trailer, unsigned commits counted, signed ones not, prose mentioning the word not a trailer, a range git cannot walk.
• daemon-services.test.ts: real registry, real branch, only the spawn stubbed. A plain commit on the branch starts one agent told /work-queue, unattended, merging, one per move however high the concurrency; a commit through the daemon's funnel starts nothing; Run now with the schedule off; the model-week gate on a move.
• daemon-runtime.test.ts and daemon-workspace.test.ts: the spawned agent's environment has its AGENT_ID and the daemon's own PATH untouched; the checkout links exactly two skills, branches and work-queue; the skill file names itself and is not model-invocable.
• daemon.test.ts: the teardown's record commit ends with the trailer.

Each of the trigger, the chain and the signing was broken on purpose once, and the tests failed: counting signed commits as moves failed 2 tests, never setting the move failed 9, dropping the trailer from the record write failed the teardown test.

Removed with the drain: 28 tests in auto-pm.test.ts, 4 in daemon-services.test.ts, 13 in todo-loop.test.ts, 3 in control.test.ts, the ticket lane tests in overview.test.ts and HotTickets.test.tsx, the drain story in story-tickets-and-queue.test.ts.

pnpm build, pnpm typecheck and pnpm test pass: 1350 node tests, 865 dashboard tests.

LOGIC.md updated beside every touched file; auto-pm.LOGIC.md rewritten around the branch head, the chain and the heartbeat; daemon-writes.LOGIC.md and the routines package's LOGIC.md, DECISIONS.md and SKILL.LOGIC.md are new. The LOGIC changes are their own commits.

Proof

This PR's own daemon, on a throwaway repository with the tickets, queue and logs SKILL.md tracked, origin on GitHub (suleimansh/dogfood-uns), an isolated config: Opus, concurrency 1, every routine but the queued work switched off. Three tickets, an empty queue. The daemon started, took its first look, and stood down. Then one commit on agent-data queued three entries. Nobody touched anything after that.

The daemon's log:

auto PM: standing down for …/rig2/work — the quota could not be read, so there is no way to tell what is spare
auto PM: standing down for …/rig2/work — every routine that makes new work is switched off
auto PM: Work the queue in …/rig2/work
auto PM: Work the queue in …/rig2/work
auto PM: standing down for …/rig2/work — 1 run is already going (2026-09-13T19-01-53-016Z (pid 51345))
auto PM: Work the queue in …/rig2/work
auto PM: Work the queue in …/rig2/work
removed worktree …/rig2/work/.branches/agent-2026-09-13T19-04-53-396Z and its branch agent-2026-09-13T19-04-53-396Z: nothing on it is missing elsewhere
auto PM: standing down for …/rig2/work — every routine that makes new work is switched off
CI watch: checks passed on PR #2, merged it (https://github.com/suleimansh/dogfood-uns/pull/2) (session 2026-09-13T19-01-53-016Z)
CI watch: checks passed on PR #3, merged it (https://github.com/suleimansh/dogfood-uns/pull/3) (session 2026-09-13T19-03-52-944Z)

The queue was pushed at 19:00:01 UTC. The first run started at 19:00:52. Each next run started on the look after the previous run's record landed. The fourth run started at 19:04:53 and ended nine seconds later. Nothing fired after it.

agent-data on origin afterwards, newest first, with the trailer where there is one:

d471f56 logs: record run 2026-09-13T19-04-53-396Z        Daemon: Suleimans-MacBook-Pro.local
bd30a93 logs: record run 2026-09-13T19-03-52-944Z        Daemon: Suleimans-MacBook-Pro.local
d1515f1 queue done: [Fix the README title](tickets/2026-09-13_readme-title.md)
557c858 close tickets/2026-09-13_readme-title
cef76e4 claim tickets/2026-09-13_readme-title
2f28baa logs: record run 2026-09-13T19-01-53-016Z        Daemon: Suleimans-MacBook-Pro.local
ba8566c queue done: [Add a CONTRIBUTING.md](tickets/2026-09-13_contributing.md)
c86a1f6 close tickets/2026-09-13_contributing
589569f claim tickets/2026-09-13_contributing
d3985fc logs: record run 2026-09-13T19-00-52-977Z        Daemon: Suleimans-MacBook-Pro.local
e1365ed queue done: [Add a license line to the README](tickets/2026-09-13_readme-license-line.md)
49e01c0 close tickets/2026-09-13_readme-license-line
7c861e3 claim tickets/2026-09-13_readme-license-line
24d9d2c queue add: three entries
2933e79 three tickets and an empty queue

The queue is empty and tickets/ holds nothing. PRs #1, #2 and #3 are merged into the throwaway's main.

npx logs in a fresh clone lists the four runs:

run	intent	branch	PR	cost	duration
2026-09-13T19-00-52-977Z	/work-queue	agent-2026-09-13T19-00-52-977Z	#1	$0.29	36 s
2026-09-13T19-01-53-016Z	/work-queue	agent-add-contributing	#2	$0.35	66 s
2026-09-13T19-03-52-944Z	/work-queue	agent-fix-readme-title	#3	$0.30	49 s
2026-09-13T19-04-53-396Z	/work-queue	agent-2026-09-13T19-04-53-396Z	none	$0.12	9 s

npx logs show <id>, what each agent said:

Run 1: "I added the line License: MIT to the end of README.md, which was the first ticket in the queue. Commit fcd0c94 is on branch agent-2026-09-13T19-00-52-977Z. I didn't push it; the run that started me publishes the branch. I claimed it before starting and closed it after committing, so there's no claim left to release. The entry is marked done. Two tasks are still queued." Then ready-for-merge and an open-pr block.

Run 2: "I took the 'Add a CONTRIBUTING.md' ticket from the queue and finished it. Committed as 3bd97e7 on agent-add-contributing. I didn't push. The ticket is closed and its queue entry is gone. The only entry left is 'Fix the README title', which I didn't touch." It also reported an error: the throwaway's package.json did not list @gemstack/skill-branches, so npx branches fetched a stranger package from the registry; it renamed the branch with git branch -m instead.

Run 3: "I fixed the one ticket in the queue: the README title now reads # throwaway. Commit 9c7b6dd on branch agent-fix-readme-title. I closed the ticket (which also removed my claim) and marked its queue entry done. The queue is now empty." The same branches error, handled the same way.

Run 4: "The agent queue is empty (npx queue returned []), so there was nothing to pick up. I didn't claim a ticket, commit anything or change the queue."

The branches error in runs 2 and 3 is the rig's: I wired only the tickets, queue and logs packages into the throwaway. It is the cutover rule above, seen from the agent's side. gemstack lists all four packages.

Total: $1.05 on Opus for three tasks and one empty run.

[suleimansh]

👤 How this PR was driven. Everything I typed to the agent, verbatim, in order. What the agent did between my prompts is summarized under 🤖. One session, 2026-09-13 19:00 to 2026-09-14 01:30 IDT, Fable 5.1, effort high.

---

1. My brief that opened the session:

Context: gemstack, main at 6facc28 or later. Read memory first: tf-daemon-half-plan-next.md (the brief: six picks, the rig results, the tested prompt), tf-capabilities-experiment.md, tf-dashboard-1768-next.md, rom-slop-rules.md, ask-before-starting-work.md, tf-no-compat-no-bloat.md, no-claude-attribution.md, tf-effort-marker.md, tf-logic-md-rename.md.

Then read, in this order:

1. The posted plan: comment 5654851317 on Dashboard architecture: the plan and six questions #1774 (gh api repos/framework/the-framework/issues/comments/5654851317 --jq .body). It is the design. Six picks: (1) D, the routine is a skill file work-queue/SKILL.md with disable-model-invocation: true, the daemon starts the agent with /work-queue; (2) D, fire when the agent-data head moved since the last run ended by a commit the daemon did not write, the chain, one heartbeat a day; (3) A, two imports stay (branches checkout, logs writeRun), everything tickets and queue leaves the daemon; (4) A plus D, the release sentence in the routine, the Release button for the rest; (5) A, the drain only, the rotation stays with its imports and the PR body says so; (6) C, three-entry proof.
2. The facts file with every file:line: /private/tmp/claude-501/-Users-suleiman-Projects-gemstack/151baf33-4630-450b-a793-85276cd99e69/scratchpad/facts-daemon.md. If it is gone, re-read the code named in the memory file.
3. The rig: /private/tmp/claude-501/-Users-suleiman-Projects-gemstack/d9ccc194-57ad-400a-aa1b-4c7bbbf015e3/scratchpad/rig/. Its origin.pristine.git main already carries the tickets, queue and work-queue SKILL.md; runs/f3-opus is the passing run. reset.sh's clone can fail its checkout once; a plain git clone plus wiring node_modules by hand as reset.sh does works.

Task: build the daemon half as ONE PR, in a scratchpad worktree off main, branch daemon-half. Nothing on main, no push, no PR opened until I say so.

The PR, per the plan's section 5:

• The routine skill: work-queue/SKctly as posted in section 1 of thecomment (the "committed counts as published" sentence included). Decide with me first where the framework ships it: its own skills directory linked into checkouts, or tracked in the project.
• The trigger and chain (section 2 head, fire when it moved by acommit the daemon did not write, fire again when the run's own commits moved it, stop after an empty run, heartbeat daily. The quota gate, cooldown, concurrency cap stay. The rotation firesafter an empty run.
• The removal list (section 5), all of it: drain preset and drainsQueue, the drain half of auto-pm.ts and its ~28 tests, the drain parts of daemon-services.ts and 4 tests, todo-loop.ts whole with 13 tests and the agentTies and checkout symlinks andAGENT_ID_ENV import in daemon-runtime.ts (AGENT_ID becomes the framework's own constant), the ticket option and (fix #N) and ticket event in cli.ts, syncTickets+syncQueue replaced by one agent-data pull, the routine row ok-queue.
• What remains, listed in the PR body under a "remains" heading: the rotation's tickets import(update tickets, triage quick, trits), the dashboard's tickets andqueue imports, the two package dependencies. Four follow-up PRs named: one rotation job each, plan tickets last.
• Tests: the trigger and the chain with fakes; the environment without PATH entries; the routine started with /work-queue. ing the code once (memorytf-verify-a-test-by-breaking-it).- LOGIC.md files beside every toucriven-development skill BEFOREtouching any of them, then update- pnpm build, typecheck, test all -rf dist-test after the branchswitch if tests fail with 503s.The proof, before the PR body is wn (its build, not :4200) on therig's throwaway repo with three enn, untouched. Expected: three runs, one empty run, the chain stops; npx logs in a fresh clone lists four runs; npx logs show prints a diary. Use Opus. Do not u drain. Transcripts and the logsoutput go into the PR body.PR body: short sentences, one idearemains, the proof, temporarythings labelled temporary; no Rom with Claude Code" footer; the 🤖marker with the effort actually seefore opening the PR.

Do not: push, open the PR, merge, he :4200 daemon, post on GitHub,without my word. Ask me before anydoes not settle.

🤖 Read the memory, the plan, the facts file and the rig. Read the daemon code: auto-pm.ts, daemon-services.ts, todo-loop.ts, daemon-runtime.ts, cli.ts, the skill packages' libraries, the tests, the LOGIC.md files. Found four things the plan did not settle and asked them in one go: where the skill file lives, whether the chain waits the cooldown, how the daemon tells its own commits apart, what the first look after boot does. The first version of the questions was too long and named a Haiku probe.

2.

first thing, we dont care for claude haiku, second thing, I dont understand the question, make it more clear..

🤖 Asked the same four questions again, one situation each, plainer.

3. My picks, one per question:

why not in the queue package?

Chain ignores the cooldown

Yes, the line 'Daemon: '

Just remember the head

🤖 Argued the skill file's home: the routine names both skills, and Rom's rule is that skills do not know each other. Asked again with three options, and flagged the step-1 gap: the plan removes the checkout links assuming projects track the SKILL.md files, and gemstack does not yet.

4.

lets go with Rom rule

🤖 Read that as: the routine is a job the framework ships, not a skill package's file; the links go, the cutover tracks the files. Built the PR in a scratchpad worktree: the trigger and chain in auto-pm.ts, the signed funnel in daemon-writes.ts, the removal list, the tests, broke the trigger three ways on purpose to see the tests fail, LOGIC.md beside every touched file. Ran the proof on a throwaway GitHub repo with this branch's daemon: three entries, four Opus runs, chain stopped, $1.05. Drafted the PR body and asked for the effort level and the word to open the PR.

5.

1. the effort is high
2. yes open PR

🤖 Pushed the branch and opened #1777.

6.

about our #1774 (comment)
lets mark the question as Q6.1/Q6.2/Q6.3 ...

it will be easy to talk about them with Rom, so we dont have conflict about prev questions..

and about (The sweep starts an agent with a prompt. Today that prompt says "use the tickets skill")

what prompt exactly that say "use the tickets skill", we need to make every thing clear to understand

🤖 Prepared the two edits and showed them, plus a third: the comment's first line said "Nothing is built yet".

7.

go ahead with all three

🤖 Edited the comment: headings Q6.1 to Q6.6, the exact drain prompt quoted in Q6.1, "Built as #1777" on top.

8.

why didn't we move packages/framework/skills/work-queue/SKILL.md to the skill-queue package?

🤖 Answered: the routine names tickets, so it cannot live in the queue package under Rom's rule, and the daemon would need a queue import for the path.

9.

I dont understand, I think the routine should be a separate package and this prompt part of it, the main issue was #1768

chat with Rom to remind you about our discussions:
[the Discord thread from 9/8 to 9/13 pasted]

🤖 Laid out two kinds of skill, capability and routine, and three homes for routines: the framework's own skills folder, one routines package, one package per routine. Recommended the routines package.

10.

yes I prefer B, and about 'routine', make it more clear.

🤖 Explained "routine": a job the daemon runs by itself, no click; a preset is the same shape started by a person. Asked whether to make the package now or in the next round.

11.

now, in #1777
also update our comment on #1774 (comment)

🤖 Created packages/routines (@gemstack/routines, SKILL.md only), moved the file, made the framework depend on it, wrote its LOGIC.md and DECISIONS.md, pushed two commits, updated the PR body, rewrote the Q6.1 pick with the two-kinds model.

12.

can you make '[the Q6.1 pick paragraph]' shorter / easier to read and understand!
I dont like long texts!

🤖 Drafted a shorter pick and showed it.

13.

go ahead

🤖 Posted it.

14.

why its name not 'skill-routines'?

🤖 Answered: the sibling packages ship one skill each, this one ships several; and the name is Rom's to decide.

15.

what you recommend?

🤖 Recommended keeping @gemstack/routines and letting Rom rename it.

16.

tell me about 'Auto PM': should it be in the routines package, or a separate package? as we want everything modular.

🤖 Answered: Auto PM is the scheduler, daemon code, not a routine; what is still not modular is that it knows the routines by name; the end state is triggers declared in each SKILL.md.

17.

the scheduler, should it be a package? WDYT?

🤖 Recommended yes, later: it is already one function with every reading injected, a library like agent-driver; after the triggers step, so no name moves with it.

18.

add the scheduler and the triggers as remains in #1777, and tell me the next steps.

🤖 Added both under "What remains" in the PR body and listed the next steps.

19.

also update the #1774 comment with the scheduler and the triggers.

🤖 Added them to the comment's remains and order of work.

20. After Rom's review on Discord (2026-09-14, 13:15 to 14:32):

go ahead, then give me a prompt to continue what is left in the next fresh session.

🤖 Added Rom's note to the work-queue command, put my picks as a 👤 block on top of the PR body, posted this comment.

---

Every design pick above is mine. The agent wrote the code, the tests, the LOGIC.md files, the PR body and the comment edits, and posted only on my word.