Keep forwarded invoices out of Inbox and show Inbox as a simple list

Start with frontend/src/surfaces/operations/inbox.js and inbox-actions.js, then trace GET /api/intake and invoice handoff through backend/src/routes/emailDocuments.ts and backend/src/invoices/service.ts. Run the listed backend intake/email-document tests, frontend Inbox tests, typecheck, and Inbox Playwright journeys. Done means invoice-route items stay out of Inbox, ad-hoc items remain actionable in a flat list, and all listed automated checks pass; the live post-deploy check is still pending.

Keep forwarded invoices out of Inbox and show Inbox as a simple list

Status: pending
Tags: bug, portal, frontend, backend, data, P1
Depends on: None
Blocks: None

Scope

Inbox at /#/inbox is currently a master-detail triage console whose default
queue is filled with forwarded invoice/receipt emails. Those emails were
forwarded for invoice processing, not as ad-hoc work to convert into tasks.
The operator cannot tell what Inbox is for, and the nested-disclosure layout
is too heavy to use.

Product decision (do not re-litigate):

1. Forwarded invoices and receipts are Finance review work. They must not
   appear in Inbox as items that need converting into tasks.
2. Inbox stays, but only as the list of untriaged ad-hoc inputs that are not
   already owned by another surface (manual notes, Telegram, non-invoice email,
   files, links).
3. Inbox is a list. Remove the master-detail + nested-disclosure triage
   console. If an item still needs a decision, the operator sees it in a list
   and can act without opening a second pane of nested <details>.

Keep this as one slice. The unusable Inbox is one operator problem: the wrong
work is in the wrong place, and the place itself is too heavy.

Why invoices are in Inbox today

Email documents enter through Dapier + POST /api/v1/intake/email-documents
(backend/src/routes/emailDocuments.ts). Invoice recipient routes
(invoice, receipts, invoice-attachment, invoice-pdf) then call
processInvoiceIntake (backend/src/invoices/service.ts), which stages
Finance drafts and writes invoiceReviewIds into intake metadata. The intake
row is left status: new. Inbox (frontend/src/surfaces/operations/inbox.js
and inbox-actions.js) treats every new item as triage work and offers
Convert to task as the primary action. There is no Finance handoff.

Intake records remain the source identity for imported documents. Do not stop
creating them. Do not delete them. Stop treating invoice-route records as
Inbox work.

Inbox purpose after this change

Inbox is the list of things that arrived but are not work yet. Use it to
convert a note into a task, attach it to existing work, or dismiss it.
Forwarded invoices are reviewed in Finance, not Inbox.

Copy, empty state, and header must say that in operator language. Do not keep
"Capture raw operational inputs, then triage them into executable work."

Layout after this change

• Default Inbox is one vertical list of items that still need a decision.
• Each row shows title, source, and captured date. The next action is
  available from the list, not from a required side panel.
• Nested action trees are gone: no primary <details> for Convert to task,
  no "Other valid actions" wrapping more disclosures, no nested "Resolution
  actions".
• The always-on master-detail split (queue + empty "select an item" pane) is
  gone.
• Manual capture may stay, collapsed, and must not dominate the page.
• Filter chrome can be reduced to what a list needs (Actionable vs
  dismissed/resolved). The current eight-tab bar is part of the overload.
• Existing convert / attach / ignore / archive behavior remains available for
  remaining non-invoice items; it just cannot be buried in nested disclosures.
• One-click convert with safe defaults (today's date, no card) is preferred
  over a form-first disclosure.

API and data

• Inbox's operator list must not include invoice-route email-document items.
  Change the authenticated list used by /#/inbox (GET /api/intake and/or
  the Inbox client) so those rows are not triage work. Direct
  GET /api/intake/:id may still return the source record for Finance/CLI.
• After a successful invoice-route import, processInvoiceIntake must leave
  the intake resolved for Inbox (existing archived status plus a Finance
  handoff history event is enough; do not invent a compatibility status).
  Processing issues still belong in Finance, not as Convert-to-task Inbox
  work.
• Exact duplicate or retry of the same invoice email must not resurrect the
  item as Inbox new work. Today's duplicate short-circuit in
  emailDocuments.ts is gated on status === 'new'; archiving without
  fixing that path would reopen the pile.
• Finance reprocess (POST /api/bookkeeping/invoices/process, CLI
  dataops invoices process --intake-item-id) must keep working and must
  not re-open Inbox work.
• No new operator API is required for "send to Finance". The system routes
  invoice-route intake. Existing authenticated convert/attach/block/ignore/
  archive paths stay for remaining Inbox items.
• Do not delete intake rows, artifacts, or invoice drafts. Portable export/
  restore must still include the intake records. This is a status/list-rule
  change, not a table replacement. Do not leave a permanent dual-read of
  "invoice items are both Inbox work and Finance work."

Existing production new invoice-route rows must disappear from the operator
Inbox list on deploy without a standing migration job. Filtering invoice-route
items out of the Inbox list is sufficient for that; also resolve them when
processing so stored status matches the product rule.

Related work that must not be duplicated here: #232 (Finance processing and
publication), #237 (extraction and invoice ledger), #242 (bookkeeping page
redesign).

Acceptance Criteria

• Invoice-route email-document intakes (invoice, receipts,
  invoice-attachment, invoice-pdf) do not appear in the default Inbox
  list as work to convert into tasks. That includes newly imported mail
  and already-stored new rows.
• After a successful invoice-route import, Inbox does not show Convert to
  task for that mail. Finance still has the staged draft(s) and original
  document. Duplicate/retry deliveries do not put the item back into
  Inbox as new.
• A non-invoice Inbox item (manual capture is enough) still appears in
  the list and can be converted, attached, ignored, or archived without
  nested disclosure trees.
• /#/inbox is a list: no master-detail split, no nested "Other valid
  actions" / "Resolution actions" console. Header and empty state explain
  that Inbox is untriaged inputs, and that forwarded invoices are reviewed
  in Finance.
• Deep-linking /#/inbox?intakeId= for an invoice-route item does not
  present Convert to task as the job. Prefer a clear "this is Finance
  work" state and a path to Finance.
• Intake records, artifacts, and invoice drafts are not deleted. Export
  still includes the intake rows. No secrets, real invoice subjects,
  account identifiers, or unsanitized fixtures land in this public repo,
  issue comments, tests, logs, or screenshots.
• Playwright covers the changed Inbox list (empty, one non-invoice item,
  invoice-route fixture absent from the list) with screenshots under
  .tmp/screenshots/ for desktop and mobile. Existing Inbox E2E that
  asserts .intake-action-disclosure / "Convert to task" as a
  <summary> is updated to the new list.
• [HUMAN] After deploy, open live /#/inbox and confirm the forwarded
  invoice pile is gone. Confirm one real forwarded invoice/receipt lands
  in Finance review and does not reappear in Inbox as Convert-to-task
  work. Do not attach live invoice screenshots to this public issue.

Test Scenarios

Scenario: Invoice email is not Inbox work

Given: an authenticated operator and a sanitized invoice-route email-document
intake that imported a PDF and ran processInvoiceIntake
When: they open /#/inbox
Then: that item is not in the default list, Convert to task is not offered
for it, and Finance still lists the staged draft

Scenario: Duplicate invoice delivery stays out of Inbox

Given: an invoice-route intake that was already imported and handed off to
Finance
When: the identical email-document request is replayed
Then: the API remains idempotent and the intake does not return to Inbox as
status: new Convert-to-task work

Scenario: Inbox is a usable list for real ad-hoc intake

Given: a sanitized manual Inbox item that is still new
When: the operator opens /#/inbox
Then: they see a single list, understand from the page copy what Inbox is
for, and can convert or dismiss the item from the list without a
master-detail nested-disclosure console

Scenario: Empty Inbox explains the job

Given: no remaining non-invoice actionable intake
When: the operator opens /#/inbox
Then: the empty state says there is nothing to triage and that forwarded
invoices are reviewed in Finance, not Inbox

Scenario: Invoice deep link does not become a task form

Given: an invoice-route intake id
When: the operator opens /#/inbox?intakeId=<id>
Then: the page does not ask them to convert it to a task; it points them at
Finance if it shows anything

Out of Scope

• Invoice field extraction, publication, Dropbox/Sheets, or the Finance
  ledger redesign (#232, #237, #242).
• Changing Dapier, ../dtc-operations, ../datatasks, or
  ../podcast-assistant.
• Deleting intake/artifact records, replacing the intake table, or adding
  standing migration machinery.
• New Telegram/email capture channels, assistant Inbox features, or a
  Designer-led visual redesign beyond the operator-requested list.
• Copying raw SOPs, live invoice subjects, account identifiers, or the
  original operator screenshot into this public repo or issue.

Dependencies

• Invoice staging already exists in-tree from #232. This issue does not wait
  on that issue's remaining [HUMAN] live publication check.
• No new secrets or infrastructure. Inbox and email-document intake stay on
  the existing authenticated APIs and declared DynamoDB tables.
• Verification lives in frontend/ and backend/ (TypeScript). Do not
  require the retired Python docs-app pytest workflow, a search-index
  rebuild, or live Dapier/email forwarding in CI.

Required agent verification:

• Focused backend tests for email-document invoice-route handoff, duplicate
  replay, and Inbox list exclusion (backend/tests/api-email-documents.test.ts,
  backend/tests/api-intake.test.ts, and invoice processing tests that
  currently assume the intake stays new).
• npm --prefix frontend test for Inbox surface tests
  (frontend/test/operations-surface.test.mjs).
• npm --prefix backend run typecheck.
• Playwright for the changed Inbox journeys, including updates to
  backend/e2e/canonical-frontend.spec.js and
  backend/e2e/canonical-route-parity.spec.js, plus screenshots.
• Do not require npm --prefix backend test to be skipped; if the engineer
  runs a focused subset while iterating, Tester still runs the Inbox/intake/
  invoice-related tests and the Playwright Inbox journeys as the issue's
  full verification workflow. Broad unrelated E2E failures that already exist
  on main are not this issue's gate.
• Live Dapier/email forwarding and production Inbox checks are [HUMAN]
  only.