Add inline task status update control to web dashboard#229
Merged
Conversation
Tasks: - ORB-00025: Add inline task status update control to web dashboard
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task
ORB-00025 — Add inline task status update control to web dashboard
Description
Problem
The web dashboard's per-task actions row (
buildActionsRow()atcrates/orbit-cli/assets/dashboard/app.js:404–433) exposes three mutation paths:approve,reject,archive. There is no way to move a task between lifecycle-internal statuses (e.g.proposed → in-progress,in-progress → blocked,blocked → review) from the UI. Today the only options are the CLI (orbit task update) or the MCP (orbit.task.update).The backend already supports it.
PATCH /tasks/:id(crates/orbit-cli/src/command/web/api/tasks.rs:88–112, wired atcrates/orbit-cli/src/command/web/api/mod.rs:286) accepts a partialUpdateTaskBodywhosestatus: Option<TaskStatus>field already routes throughruntime.update_task_with_identity(...). The work is frontend-only.Why It Matters
Dashboard users (humans, not agents) currently context-switch to a terminal to do something as basic as "move this task from
proposedtoin-progressso I can start it." That breaks the dashboard's promise as a control surface and pushes users toward the CLI for routine state changes. Adding an inline status control closes the gap without touching backend code paths that are already in production.Scope
Exposed statuses (lifecycle-internal):
proposed,backlog,someday,in-progress,review,blocked,done.Explicitly excluded — dedicated flows already exist:
rejected— keep going throughPOST /tasks/:id/reject, which requires a note (RejectBody.note: Stringattasks.rs:36–41). The new control must not offer this status, otherwise it bypasses the note requirement.archived— keep going throughPOST /tasks/:id/archiveplus the existingwindow.confirm()atapp.js:426.archivedis also not part of theTaskStatusenum accepted byPATCH.friction— deprecated from the lifecycle (see ORB-00024).Backend changes — none.
PATCH /tasks/:idalready accepts{ "status": "..." }and writes history viaupdate_task_with_identity. Do not add a new endpoint, do not change the routing inmod.rs, do not modifyUpdateTaskBody.Known Consequence
DASHBOARD_TASK_STATUSESattasks.rs:17–26does not includeTaskStatus::Done. Tasks transitioned todonevia the new control will disappear from the dashboard's task list immediately after refresh. This is accepted for this task — expanding the dashboard's visibility set is a separate decision and a separate task. The control should still exposedoneas a target; the implementer should add a post-action toast or inline note clarifying the disappearance ("task marked done — no longer shown in dashboard list") so users aren't confused.Constraints / Notes
buildActionsRow()next to the existingapprove/reject/archivebuttons, OR as a dedicated control adjacent to the status pill in the detail view — implementer's call, but it must not visually displace the existing three buttons.STATUS_ORDERordering (app.js:4–13, post-ORB-00024) for in-set statuses, thendonelast.runAction()atapp.js:464–499— disable the control while the PATCH is in flight, surface backend errors via the same.action-errorelement pattern, and callrefreshDashboard()on success./approve,/reject,/archive. The new control inherits the same trust model; if that's wrong, it's wrong for everything and needs its own task.buildActionsRoworrunAction, extend them. Otherwise, smoke-test manually and document the steps inexecution_summary(open dashboard, transitionproposed → in-progress, observe history reflects the change, verify error path on a forced 4xx).Acceptance Criteria
(captured in the acceptance_criteria field)
Acceptance Criteria
buildActionsRow()incrates/orbit-cli/assets/dashboard/app.js).proposed,backlog,someday,in-progress,review,blocked,done. It does NOT exposefriction,rejected, orarchived.PATCH /tasks/:idrequest with body{ "status": "<target>" }and no other fields. The existingrunAction()helper is reused or extended — do not duplicate its disable/error/refresh logic.refreshDashboard(), the task's status pill reflects the new value, and the task's history (visible in the detail expansion) shows the transition..action-errorelement is prepended to the task detail with the server's error message, and the task's status pill remains unchanged.done, the UI surfaces a user-visible cue (toast, inline note, or post-refresh message) that the task is no longer shown in the default dashboard list. The cue must be testable — it appears in the DOM after a successful done-transition.approve,reject, andarchivebuttons render and function exactly as before. The reject flow still requires a note viashowRejectForm()atapp.js:435. The archive flow still confirms viawindow.confirm()atapp.js:426.crates/orbit-cli/src/command/web/api/tasks.rsandcrates/orbit-cli/src/command/web/api/mod.rsare unchanged.DASHBOARD_TASK_STATUSESis unchanged.UpdateTaskBodyis unchanged.make cipasses.Execution Summary
Click to expand
Outcome: success
Changes:
Validation:
Assessment: Frontend-only task status transitions are implemented through the existing dashboard action path; backend task API files remain unchanged.
Deviations from original plan:
Validation
Branch Freshness
origin/agent-mainorbit/ORB-00025-6a0682a8authored by: claude-opus-4-7