The queue

Findings stop respecting project boundaries the moment you run agents across several of them. A session working on one tool discovers a bug in another; a review in one repo produces work for three. Letting the discovering session go fix things over there is how two agents end up editing the same tree. The queue is the alternative: the only sanctioned write a session makes into another project is a file that describes work, and the receiving project’s next session picks it up.

When it applies

• Work surfaces in one project but belongs in another, and the discoverer should not be the executor.
• Humans and machines both need to read the same task list, with no translation layer between them.
• You want the task history to be the files themselves, greppable and diffable forever, not rows in a service.
• It does not apply inside one project with one session; that is what your own issue list is for. The queue exists for crossing boundaries.

The moving parts

One directory per target, one markdown file per task, a status line in the front matter. No database, no integration; the board is a one-page summary generated from the files.

handovers/
├── board.md                  generated from the entries, one page
├── site/
│   ├── 004-syndication.md    status: done
│   └── 007-display-shapes.md status: pending
└── tooling/
    └── 012-retry-helper.md   status: taken

Four states and two side doors:

              take                       evidence pasted
 pending ──────────────▶ taken ──────────────────────────▶ done
   │  ▲                    │
   │  │ date reached       └──▶ dropped, reason written into the entry
   │  │
   ▼  │
 snoozed, until a date         severity: risk ignores the snooze and
                               resurfaces every session until dealt with

A complete entry fits on one screen:

---
status: done
severity: normal
created: 2026-08-09
---
# Align the retry helper with the new timeout API

The ask: the helper still passes an option the API dropped in v3.
Update the call sites and run the suite.
Context: the failing CI run, and the changelog entry that dropped it.
Acceptance: `npm test` exits 0 with the retry cases green.
Evidence: "12 passed, 0 failed", pasted by the taker, 2026-08-10.

Three authoring rules make or break it, all learned from watching entries fail:

1. Every entry carries an acceptance test. The body must be complete for a stranger: the ask, the context links, and how to know it is done.
2. Done requires evidence, one pasted line of the acceptance test passing.
3. Absence claims name what was checked. “Nothing documents X” is only writable alongside the list of places you looked.

The time vocabulary is small on purpose: a snooze field hides an entry until a date (a real date; “next week” is rejected at the door), and a risk severity ignores snoozing entirely and resurfaces every session until someone deals with it.

- Done is a pasted line of output, never an opinion.

The same queue serves the nightly automation: it drains the same entries interactive sessions do, skips what is marked for the owner, and flips the same statuses under the same evidence rule. The incident that proved the pattern, including the night the files told the truth and I did not, is the queue’s own piece.