Port Inbox and intake lifecycle to the canonical frontend

Status: blocked — groomed; resume after #150 is accepted and integrated
Tags: enhancement, portal, 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

Implement the production-visible /api/intake workflow in top-level frontend/: manual capture; queue/list/filter/select; source/context/history; task, workflow, assistant, link, file, and artifact relationships; attach; convert to task; mark duplicate; block; follow-up sent; response received/unblock; prepare assistant input; ignore; and archive.

Use the #150 canonical route contract for #/inbox?intakeId=<id> and all relationship links. Reuse authenticated API, error, dialog/detail, accessibility, and responsive patterns. Do not copy the legacy shell/API client or change the intake data model unless a concrete parity defect requires a separately documented amendment.

Acceptance criteria

• Inbox is reachable in the canonical shell and no longer reports intake as unconnected.
• Actionable, new, blocked, due, future, assistant-ready, resolved, and all filters use backend semantics and deterministic Europe/Berlin time.
• Manual capture and every supported transition call the real authenticated API contract, enforce required fields, prevent double submission, and show validation, conflict, permission, and network failures honestly.
• Task/workflow/assistant relationships use Preserve canonical frontend routes and deep links #150 URLs, preserve intake return context, and open the created/attached record.
• Source body/binaries remain behind safe storage references; links are safe clickable links; intake content is not treated as task proof.
• Loading, empty, not-found, partial relationship failure, stale/conflict, success, and retry states are explicit and accessible.
• The 390x844 flow uses progressive disclosure: primary action and current state are visible, secondary/destructive fields do not become one unscannable full-page form, and no horizontal overflow occurs.
• Behavior tests exercise the backend intake lifecycle through the normal test server/in-memory data path; mock-only screenshots and source-string checks are insufficient.
• Legacy Inbox tests remain until equivalent canonical behavior assertions pass; no fallback assets are deleted here.

Test scenarios

Scenario: Capture and triage

Given: an authenticated operator and deterministic empty intake state
When: the operator captures an item, attaches/converts it, blocks it, records follow-up/response, prepares assistant context, and resolves it
Then: each backend state transition and relationship is visible and the canonical URL opens the resulting context

Scenario: Validation and conflict

Given: missing required reasons/waiting fields and a stale/conflicting mutation
When: the operator submits each action
Then: the action remains retryable, no duplicate mutation is sent, focus/error copy identifies the problem, and existing data is preserved

Scenario: Honest queue states

Given: new, blocked-due, blocked-future, assistant-ready, resolved, and relationship-load-failure fixtures
When: each filter and item is opened
Then: counts, readiness/status, history, source context, and partial-error states match the backend

Scenario: Mobile triage

Given: a 390x844 viewport and a blocked intake item
When: the operator reads context and performs the next action
Then: the primary action is reachable without scanning every secondary field, disclosures are keyboard operable, and there is no clipping or horizontal overflow

Required verification

• Focused intake route/unit tests plus canonical UI behavior tests.
• Preserve/port the behavior covered by backend/e2e/intake-inbox.spec.js.
• npm --prefix backend test
• npm --prefix backend run typecheck
• npm --prefix backend run test:e2e
• Tester screenshots under .tmp/screenshots/issue-151/ at 1440x900 and 390x844 for queue/detail, blocked/follow-up, validation/error, and relationship navigation.
• Designer reviews hierarchy/progressive disclosure/mobile; then Tester and PM gates run.

Lifecycle gates

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

Prototype handoff

The Inbox additions in the current .tmp/worktrees/issue-148/frontend/src/{app.js,styles.css}, its canonical E2E fixture, and issue-148 screenshots are useful drafts for #151. Reimplement/refactor the narrow slice in a fresh #151 worktree. The current mobile screen is too dense and the test is mostly mocked; neither is accepted evidence.

Out of scope

• Assistant lifecycle beyond preparing/creating its relationship (Port assistant job lifecycle to the canonical frontend #152).
• Runtime-template administration (Port runtime template and workflow administration to the canonical frontend #153).
• Legacy deletion or SAM packaging (Package the canonical frontend and delete the backend fallback SPA #154).
• Changes to source repositories outside dataops.