Repository navigation
impl(aggregator): 'request status change' action on project/board cards - orchestrator applies it as single writer #1154
Description
Finding
Evidence (live review 2026-10-26 ~22:40 CDT, laptop loopback + gh, cross-checked): The Project is the canonical layer and the orchestrator is its single writer (by design, #910) - but Drew has no dashboard affordance to say "this is actually done / blocked / in progress" when he sees a wrong status on /projects or the board. His only channel is a free-text comment and hope. Status drift (e.g. #910 sat In Progress->Todo mechanically) is exactly what a 5-second correction action exists for.
Proposal
Per pool item: a "request status change" control (target status + optional note) that writes a dashboard-local action record (same pattern as triage actions issue); the orchestration pass applies it on its next run (it remains the only Project writer) and reports the applied change back; the card shows a "change requested" badge until applied.
Acceptance
- A requested change appears in the Project within one orchestration cycle, with provenance (requested by Drew via dashboard) in the run log.
- Conflicting derived state after application shows the disagreement badge, not silent override.
Refs: design+impl: org-level GitHub Project as the conceptual-project layer — orchestrator-synced, dashboard-read #910.
Activity
developing-today commentedon Oct 27, 2026
CODE-290
dezren39 commentedon Oct 27, 2026
Agent note (pickup, 2026-10-27): building this now on branch
pm/triage-write-path— the actions store (src/actions.ts, mirroringsrc/comments.ts), the three endpoints, and the card controls land together with #1152/#1154/#1156 as one slice of epic #1184, plus the orchestration-pass (+ keeper, for Jules session actions) consumer steps. Verb names align with the needs-user actions addendum from the start (answer/delegate/dismiss included in the enum; proposal verbs reserved for #1290–#1293).pm-stack aggregator: dashboard actions store + triage write path UI (#…
Merge pull request #1346 from developing-today/pm/triage-write-path
dezren39 commentedon Oct 27, 2026
Agent note (status, 2026-10-27): aggregator half SHIPPED (PR #1346 merge 2cc9324 + treefmt follow-up #1350; deployed live). 'Request status change' renders on board cards (pool-matched links), /projects pool cards, and /item — target from the Project Status values + optional reason, always as a request with a ⏳/✓/✗ badge from the actions store, never a direct write. Consumer: the orchestration-pass DASHBOARD ACTIONS step (byte-verified in the job definition) performs the write in its PROJECT RECONCILIATION segment as single writer, run log naming 'status change requested via dashboard, action '.
Live verification so far: the same poll/apply/result loop is proven end-to-end by the #1152 acknowledge (applied by run orch-2026-10-27T07:36:37Z). A status-request-specific test action is pending in the live store: da-mvqdom44-2pdnsk (gh:#812, request Todo — the status the item already carries, so application is a no-op write by design). It will be consumed by the next orchestration pass; leaving this issue OPEN until that application + its run-log provenance line are observed, then closing with the evidence.
dezren39 commentedon Oct 27, 2026
Agent note — observation resolved, closing. The pending observation this issue waited on has landed: the no-op status-request test action
da-mvqdom44-2pdnskwas consumed and marked applied by orchestration runorch-2026-10-27T07:48:30Z, with the result note following the exact convention — "status change requested via dashboard, action da-mvqdom44-2pdnsk: #812 -> Todo; verified current Project status…" (the requested status already held, so the application is the recorded no-op verification the test was designed to observe). Verified directly against the live actions store on the laptop aggregator (/api/actions.json) on 2026-10-27: stateapplied,appliedByRunset, no pending status-requests outstanding. The status-request slice of the triage write path is therefore observed end-to-end (post → consume → single-writer application → store audit), not just fixture-proven.