Project Lists: idea capture with agent triage
Why
Jay needs a place to log ideas the moment they occur, especially while the lead
agent is offline (rate limits, weekly reset). When the agent returns it checks
the lists, triages every new entry, and tidies the text. The list is the
asynchronous handoff between human thought and agent action.
Where
A "Lists" section in each project in the Projects app, alongside Board, Files,
Canvas. Lists are per-project (an idea about the website lands in taos-website).
Data model (BaseStore discipline: SCHEMA first, MIGRATIONS list = [])
project_lists: id, project_id, title, created_by, created_at, archived_at NULL
project_list_entries:
- id, list_id, project_id
- text (current, possibly agent-tidied, display text)
- original_text (verbatim as first written; NEVER modified after creation)
- category (nullable; agent- or user-assigned)
- status one of: new | seen | actioned | discuss
- done 0/1 checkbox, user-controlled
- author_kind user | agent
- author_id
- edited_by nullable agent id of last tidy
- position int, for ordering
- created_at, updated_at
Append-only ethos: tidying updates text only; original_text is immutable so
nothing Jay wrote can be lost to an agent "improvement". Status semantics:
- new: nobody has looked at it
- seen: an agent read it and acknowledged (auto-set on agent read-with-ack, not
on mere listing)
- actioned: an agent did something concrete (card filed, spec written) - the
entry should link what was done in a comment/annotation field
- discuss: agent flags it needs Jay; these surface prominently
API (project-bound, mirrors canvas/tasks gating)
Under /api/projects/{project_id}/lists[...]. Session owner/admin full access.
Agents authorize via two NEW scopes lists_read, lists_write added to
VALID_SCOPES + the single _PROJECT_SCOPES definition (they are meaningless
without a project binding - see the #2127 regression test, extend it).
- CRUD lists + entries; PATCH entry accepts text/category/status/done/position
- PATCH by an agent may not touch original_text (server-enforced), and sets
edited_by
- entries list endpoint supports ?status=new filter (the "what came in while I
was offline" query)
UI (Projects app)
- Lists tab; left rail of lists, entries as rows: checkbox, text, category
chip, status pill (new=blue, seen=grey, actioned=green, discuss=amber)
- Quick-add box at top: type, enter, done (capture speed is the whole point;
no dialog)
- Tap original-text indicator to see Jay's verbatim wording when tidied
- Mobile-first: this is the phone capture surface; ARIA labels + keyboard nav
per accessibility standard
Agent behaviour (lead agents, documented in agent manual)
On coming online: GET entries?status=new across own projects; for each entry
mark seen, then either action it (file card/spec, set actioned + note) or set
discuss. Tidying (spelling, layout, categorising, splitting run-on entries into
separate entries) is allowed and encouraged; original_text preserves the source.
Slices (one card each)
S1 backend: stores + routes + scope wiring + tests (incl. original_text
immutability test and agent-cannot-modify-original test)
S2 UI: Lists tab in Projects app + quick-add + status pills + vitest
S3 agent surface: agent manual section + lead cron hook (check lists on wake)
Project Lists: idea capture with agent triage
Why
Jay needs a place to log ideas the moment they occur, especially while the lead
agent is offline (rate limits, weekly reset). When the agent returns it checks
the lists, triages every new entry, and tidies the text. The list is the
asynchronous handoff between human thought and agent action.
Where
A "Lists" section in each project in the Projects app, alongside Board, Files,
Canvas. Lists are per-project (an idea about the website lands in taos-website).
Data model (BaseStore discipline: SCHEMA first, MIGRATIONS list = [])
project_lists: id, project_id, title, created_by, created_at, archived_at NULL
project_list_entries:
Append-only ethos: tidying updates
textonly;original_textis immutable sonothing Jay wrote can be lost to an agent "improvement". Status semantics:
on mere listing)
entry should link what was done in a comment/annotation field
API (project-bound, mirrors canvas/tasks gating)
Under /api/projects/{project_id}/lists[...]. Session owner/admin full access.
Agents authorize via two NEW scopes
lists_read,lists_writeadded toVALID_SCOPES + the single _PROJECT_SCOPES definition (they are meaningless
without a project binding - see the #2127 regression test, extend it).
edited_by
was offline" query)
UI (Projects app)
chip, status pill (new=blue, seen=grey, actioned=green, discuss=amber)
no dialog)
per accessibility standard
Agent behaviour (lead agents, documented in agent manual)
On coming online: GET entries?status=new across own projects; for each entry
mark seen, then either action it (file card/spec, set actioned + note) or set
discuss. Tidying (spelling, layout, categorising, splitting run-on entries into
separate entries) is allowed and encouraged; original_text preserves the source.
Slices (one card each)
S1 backend: stores + routes + scope wiring + tests (incl. original_text
immutability test and agent-cannot-modify-original test)
S2 UI: Lists tab in Projects app + quick-add + status pills + vitest
S3 agent surface: agent manual section + lead cron hook (check lists on wake)