feat(features,web): the account's inbox read carries the open items of agents with no plan, by their automation and repository, under keys an old build drops

Merged
DA
4d ago
+644-24

Step 6 of the automations plan (docs/proposals/automations-scope.md). It is stacked on #2681 (planless Inbox writes).

What changes

  • The account Inbox read carries planless items. GET /api/inbox (accountInboxPast) now answers, beside items and plans:

    • planless: every open item of an agent with no plan in the account's workspaces, whichever member's agent posted it. Each entry names the automation whose run started the agent (with its name) and the repository, which together stand where a plan's name would, as the "⚡ · " breadcrumb.
    • automations: every automation holding such items, open or settled, with its count and latest change, as plans lists plans. A null automation groups agents whose automation was deleted.

    Both go through the same workspace reach as #2681's itemReachableBy, and they move the same cursor.

  • An automation's name goes only to readers allowed to read it. The automation is joined only where automationReadableBy (a new export wrapping automation-store.ts's own READ rule) lets the reader read it. A member beside another's personal automation reads its runs' items, since D2 makes runs and questions workspace-visible, but with automationName null. The id stays, so items still group.

  • The old-build filter is the keys themselves. The proposal sketched a ?planless=include query parameter. A separate key needs no flag:

    • items and plans stay plan-only and unchanged.
    • Every desktop build, v0.12.0 included, reads a service answer through readServiceAnswer, which drops keys it doesn't know (EXCESS_KEYS.DROP).
    • So an old build never meets a row it can't place.
    • The new keys are optionalKey in the wire, so a new build reading an older service is fine too.

  • Wire goldens. accountPlanlessEntrySchema and accountInboxAutomationSchema are new, recorded with LUKE_UPDATE_FIXTURES=1. The accountInboxAnswerSchema and codingAgentAccountInboxAnswerViewSchema goldens gain only the two optional properties (additions only, nothing reordered).

Nothing draws the new keys yet; step 9 does, in the desktop Inbox and notices.

Tests

  • inbox-store.test.ts, through accountInboxPast:
    • A teammate reads an automation's planless item under planless, with its automation id and name and its repository, and automations groups it with a count of 1.
    • It never appears among the plans' items.
    • An account outside the workspace reads both keys empty.
    • Once the automation is made personal, the teammate reads the item with no name and the creator reads it with the name.
    • This fails without the change.

pnpm check:affected passes. This change is server and wire only; CI cannot verify the Mac UI, and ./scripts/verify.sh was not run (LUKE-159 stands in before the first release).

🤖 Generated with Claude Code