Redlamp Reports

The reports room

Every report is followed in one canvas, the reports room: the reporter's own words, the owner's triage, each bug's agent and how far it has got, the fixes on main and the release each is expected in, and the suggestions with the owner's decision. The owner triages everything by hand for now; nothing is fixed, answered, closed or added to the roadmap until he says so on the board.

Where

Read ~/.cursor/skills-cursor/canvas/SKILL.md once per session before the first edit of the room. Link the room in every reply that changes it: [Reports room](/Users/pedrogomes/.cursor/projects/Users-pedrogomes-src-darkroom/canvases/reports-room.canvas.tsx).

Every time: know where things stand

1. Run python3 .cursor/skills/redlamp-reports/room.py status. Never take states from memory. It lists the reports waiting for triage, the decisions waiting to be applied, the agents at work, and the closed ones, with each one's commits on main and branches, the release it's expected or was released in, and the replies. It folds in the owner's clicks.
2. Write a read of each report waiting for triage when the owner asks for one (Refresh, or Ask the agent): what the person says happened, the code it's likely about, whether main has fixed it since their version, whether something already tracks it. Two or three sentences, with no GitHub writes and no code changes: room.py note <n> --read "…".
3. Give each suggestion a proposal: what Accept would do. A new row (its ID, the next free one in the right section of docs/research/research-tracker.md, its item text and phase), follows an existing row, or a duplicate of one: room.py note <n> --proposal '{"kind": "new row", "id": "TON-31", "text": "…", "phase": "P3"}'.
4. After a release ships, see After a release below.
5. Sync: room.py sync, and say plainly what you didn't check.

Triage: what each button does

The owner decides on the Triage tab. Each card shows the report's own sections (What happened, What I expected, Steps to reproduce; What I'd like to do; Message), its area, how often, the version and Mac, the replies, a thumbnail of the first screenshot, a read and a proposal when an agent has written them.

• Fix it (bugs): records fix with a token and opens a new chat for that bug alone, prompted to follow bug-agent.md. The agent claims the report with the token, which ties the chat to the board.
• Accept (suggestions): records accept; its label says what the proposal does.
• Reject… (suggestions) and Close… (bugs, questions): record reject or close with the owner's reason, in a sentence written for the reporter.
• Answer it (questions): records answer and opens a chat that answers it (Questions, below).
• Ask the agent: opens a chat to look into the report and write a read; it changes nothing.
• Apply decisions: opens one chat that carries out every recorded Accept, Reject and Close (Applying decisions, below). Undo removes a click that hasn't been applied.
• Refresh: opens a chat that brings the room up to date, as above.

A Fix it that no agent has claimed shows under "Fix it, no agent has picked it up yet", with Start its agent again.

Reopened reports

When a report is reopened after its fix (the reporter says it isn't fixed, or asks for more), it goes back to Triage. Its card says who reopened it and when, and shows the earlier round: the commits, the release they shipped in, its reply, and Open the first agent's chat. Clicks, reads and fixes from before the reopen no longer count; room.py finds the reopen in the issue's events and keeps the earlier round in the report's history (rounds). Fix it again opens a new agent chat whose prompt names the earlier fix and the first agent's chat, and asks it to find out why that fix wasn't enough before changing anything. When the agent claims the report, the earlier round is filed under rounds in its note.

Applying decisions

Take each recorded decision in turn, then record it with room.py note <n> --triage <decision> --applied "<what you did>" (and --tracked <ID> where it became one), so the board stops showing it as waiting.

• Close (a bug): reply with the owner's reason, in his voice, and close it as not planned (gh issue close <n> --reason "not planned").
• Reject (a suggestion): the same; add a SKIP- row to the tracker when the reason is worth keeping (section 13, Recorded skips).
• Accept, a new row: add the row to the tracker, as .cursor/rules/tracker-issues.mdc says: a new ID in the right section, never reused; Decision Accepted (<date>): the owner accepted it from #<n>; Status Not started; Source linking the issue. Start the issue's title with the ID (gh issue edit <n> --title "TON-31: …"), so the next sync adopts it and keeps the reporter's text above its block. Then bring the README roadmap and the Lightroom comparison into step (scripts/roadmap-sync.py, .cursor/rules/roadmap-and-comparison.mdc), commit, push, and sync the issues (scripts/tracker-issues.py, then --apply) only when .cursor/rules/main-branch.mdc allows it. Reply to the reporter: it's on the roadmap as the row, and the app's Your Reports shows it as Tracked as that ID.
• Accept, follows a row: label it follows:<ID> (create the label the first time, gh label create follows:<ID> --color ededed), and reply that it's tracked as the row (link its issue) and that the reply will come there when it lands. It stays open for the person who asked.
• Accept, a duplicate: close it as a duplicate of the row's issue, with a reply that links it.