Record the repository on a thread so resume can filter structurally #210

Closed AtlantisPleb opened this 2d ago 1 comment

Outcome

POST /api/v3/threads accepts an optional repository field (owner/name string), stores it on the thread, and returns it in thread views, so openagents coder --resume can filter the picker structurally instead of parsing the objective sentence the CLI itself composed ("openagents coder in on ") — the workaround OpenAgentsInc/openagents#24 ships today.

Contract

Optional, bounded string; no validation against the forge's repository table (a thread may concern a repo the forge does not host).
Returned in thread_view and available as a GET /api/v3/threads?repository= filter.
The CLI sends it at open and prefers it over objective parsing when present.

AtlantisPleb opened this issue 2d ago
A AtlantisPleb Author 2d ago

Closing as completed. Both halves are on main: the server as 7b8f939 (WAL receipt seq 307) and the CLI as OpenAgentsInc/openagents 06d16d9b32 (WAL receipt seq 74). Threads carry an optional bounded repository (nullable text, 1-200 bytes, changeset plus DB check, no FK — a thread may concern a repo the forge does not host); POST accepts it, thread_view returns it, GET /api/v3/threads?repository= filters exactly, the web thread list shows it, and the extension manifest documents it. The coder sends it at open and the resume picker prefers it over parsing the objective sentence, with the parse retained as fallback for pre-field threads. Two judgment calls worth noting: a blank repository on create is refused (a caller that sent whitespace and read 201 would believe something was recorded) while a blank filter is simply ignored; and delegation child threads deliberately do not send the field, since surfacing them in the filtered picker would offer non-resumable threads. 77 server tests and 60 CLI tests pass.
closed this as completed 2d ago