Backlog

Advisory review points, nits, and nice-to-haves tend to end up as a sentence in a Build Record nobody reopens. The Backlog is the one official place that work goes instead, so closing a PR or a feature/bug note never silently drops it.

A backlog item is an ordinary note (tagged backlog + blackops plus a kind tag), not a parallel system. It gets the same Big Board view as Bugs, Features, and Tasks: Open, Picked Up, Done, Dropped, at /admin/boards/backlog.

Filing an item

post_backlog_item files exactly one item. It requires:

• origin: where this came from, at least one of pr_url, review_comment_url, session, or note_id (the feature or bug note this is leftover work for).
• what_it_solves: one plain sentence on the problem it fixes or the benefit if it gets done.
• kind: nit, nice-to-have, follow-up-bug, or manual-test-for-ben.

One item per entry, never a bundled checklist. A detail that looks like a multi-point list (two or more bullet, numbered, or checkbox lines) is rejected, so file each point as its own call.

When origin.note_id is given, the item is also linked from that note's own ## Backlog section, so the feature or bug note shows its leftover work without the builder rewriting a section it does not own.

kind: "manual-test-for-ben" additionally opens a task on the owner's To-dos brain, the same mechanism Brain Task Reminders uses. A manual check surfaces where the owner already looks for things only they can do.

Working an item

patch_backlog_item moves an item through its lifecycle:

• status: open, picked-up, done, or dropped. Dropping requires a reason, so a point is never dropped silently.
• promote_to: "bug" or "feature". Promotion creates the new note (carrying over the detail, origin, and what it solves, with a pointer back to the backlog item), links it from the backlog item's body, and sets the item's status to picked-up. Use this when a nit turns out to need its own tracked fix. A promoted bug lands at Needs Triage, the normal entry point for a reported bug, not at Open; it goes through the same triage step any other bug report does.

Finding items

list_backlog_items filters by kind, status, or origin (origin_pr / origin_note_id), the lookup to make before filing again, to check whether a review point is already on the Backlog. list_big_board({board: "backlog"}) gives the same data shaped as board columns.

Built into review and close

The review and close-out skills file to the Backlog automatically: an advisory or non-blocking review finding left over at merge time, or a point found while closing a note, is filed rather than dropped. Working through the Backlog itself (picking items up, promoting the ones that need their own note, dropping the rest with a reason) stays a deliberate, manual step.

Related

• Big Boards: the kanban view the Backlog renders through
• Brain Task Reminders: where a manual check for the owner also surfaces