Port assistant job lifecycle to the canonical frontend

[alexeygrigorev]

Port assistant job lifecycle to the canonical frontend

Status: blocked — groomed; resume after #150 is accepted and integrated
Tags: enhancement, portal, assistant, frontend, backend, testing, design, P0
Parent: #148
Depends on: #150 accepted and integrated
Blocks: #154
Next owner: Software Engineer after the dependency resume condition is met

Scope

Port the existing /api/assistant-jobs operator lifecycle to top-level frontend/: create a contextual draft, update it while draft, submit, run the supported deterministic podcast dry-run, inspect detail/events/attempts/input refs/output artifacts, approve, reject with reason, retry, and cancel.

Use #150 for #/assistants?assistantJobId=<id> and task/workflow return context. Reuse the current backend contracts; do not transplant the legacy shell/client or couple assistant-local files/prompts into canonical portal state.

Acceptance criteria

• An operator can create and update a draft from task/workflow context, submit it, and open the resulting canonical detail URL.
• Available commands match backend state: draft submit/update; eligible dry-run; waiting-approval approve/reject; eligible failed/rejected retry; nonterminal cancel. Invalid commands are neither presented as valid nor treated as success.
• Retry performs the required two-step transition: successful POST .../retry to retrying, then POST .../submit to queue. If either request fails, the UI shows the actual retained state and a safe retry path; it never reports “queued” after only the first call.
• Rejection requires a non-secret reason; retry limit/override, relationship, transition, and API errors remain visible without losing the dialog/context.
• Detail shows task/workflow/input refs, attempts/max attempts, last error, chronological events, approval state, and output artifacts.
• Each output artifact has an accessible safe Open/Download action through the existing artifact access contract. A raw/private storageUri is never exposed as the only access mechanism or rendered as inert plain text.
• Approve/reject preserve backend permission and review boundaries and refresh both the job and related artifact state.
• Behavior tests use the real in-memory backend API lifecycle; mock-only action handlers and source-marker tests are insufficient.
• Desktop and 390x844 mobile detail/review states have readable hierarchy, reachable actions/focus, no overflow, and honest loading/empty/error states.
• Legacy assistant tests remain until equivalent canonical assertions pass; no fallback assets are deleted here.

Test scenarios

Scenario: Create, update, and submit

Given: a deterministic task/workflow and authenticated operator
When: the operator creates a draft, changes supported draft fields, and submits it
Then: the backend job becomes queued, its input relationships are preserved, and its canonical detail URL opens

Scenario: Dry-run and approval

Given: an eligible podcast job requiring approval
When: the operator runs the deterministic dry-run and opens output review
Then: events/attempts/output artifact are visible, the artifact can be safely opened, and approve updates both job and artifact state

Scenario: Reject and retry-submit

Given: a waiting-approval job followed by a rejected or failed job
When: the operator rejects with a reason and then retries
Then: retry transitions to retrying, submit transitions to queued, attempt count is correct, and failures between the two calls remain recoverable and accurately labeled

Scenario: Mobile review and errors

Given: 390x844 and transition/permission/network failures
When: the operator opens detail and attempts an action
Then: context, status, artifact action, reason/error, and close/back controls remain readable and reachable with no horizontal overflow

Required verification

• Assistant route/unit tests and deterministic canonical UI lifecycle tests through the normal test server.
• Preserve/port meaningful behavior from backend/e2e/assistant-jobs.spec.js and backend/tests/assistant-ui.test.ts.
• npm --prefix backend test
• npm --prefix backend run typecheck
• npm --prefix backend run test:e2e
• Tester screenshots under .tmp/screenshots/issue-152/ at 1440x900 and 390x844 for draft/queued, approval with artifact link, rejected/failed retry, and error state.
• Assistant Engineer reviews assistant/tool/artifact boundaries; Designer reviews hierarchy/mobile/artifact access; then Tester and PM gates run.

Lifecycle gates

• Dependency Preserve canonical frontend routes and deep links #150 accepted and integrated
• Software Engineer implementation, uncommitted
• Assistant Engineer PASS
• Designer PASS with screenshot findings
• Tester PASS with commands, exit codes, counts, and screenshots
• PM ACCEPTED
• Software Engineer commit with Closes #152
• Orchestrator local merge and push
• On-Call source CI/CD PASS

Prototype handoff

The current issue-148 assistant dialog/list code and screenshot are research for #152 only. Reuse narrow presentation ideas after reimplementation. The draft omits create/update/submit/dry-run, calls retry without the required submit, and renders the artifact URI as plain text, so it cannot be accepted or copied wholesale.

Out of scope

• New assistant engines/prompts or edits to ../podcast-assistant.
• Intake beyond its assistant relationship (Port Inbox and intake lifecycle to the canonical frontend #151).
• Runtime-template administration (Port runtime template and workflow administration to the canonical frontend #153).
• Legacy deletion/SAM packaging (Package the canonical frontend and delete the backend fallback SPA #154).

[alexeygrigorev]

Dependency clarification: depends on #150.

[alexeygrigorev]

PM GROOMING PASS — dependency blocked

#152 is agent-ready but must not start until #150 is accepted and integrated. It now explicitly requires create/update/submit/dry-run, correct retry→submit behavior, safe clickable artifact access, state/error/permission behavior, mobile evidence, Assistant Engineer review, and real-backend behavior tests.

Resume condition: #150 Tester PASS + PM ACCEPTED + commit + merge/push + applicable On-Call source gate.
Next owner after resume: Software Engineer in a fresh #152 worktree.