Skip to content

Inbox: every section of the list reads newest first - #1800

Merged
backnotprop merged 1 commit into
mainfrom
feat/inbox-newest-first
Oct 8, 2026
Merged

backnotprop merged 1 commit into
mainfrom
feat/inbox-newest-first

Conversation

@backnotprop

Copy link
Copy Markdown
Owner

Story

The owner saw Pi's older question above OpenCode's newer one in "Waiting on you" and asked twice why the newer one was not on top. Every section of the Inbox list now reads newest first, by the thread's latest message. The section order and the held "N new" rule (PR 1772) do not change.

What changed

  • packages/shared/inbox/list.ts: one order for every section, last_at descending (the time the row shows), ties on the thread id. The old per-section orders are gone: "oldest waiting first" for Stopped and Waiting, "most held up first, then oldest" for Holding.
  • packages/server/inbox-threads.test.ts: the existing sections test now expects Waiting as ["Flag name", "Header"]. Updated, not deleted.
  • tests/e2e/inbox-order.spec.ts (new, in playwright.config.ts and named in inbox-e2e.yml): Playwright against the compiled binary.
  • AGENTS.md Inbox section: the sort line and the spec list.
  • The phone app (apps/ios) needs no change. PlannotatorKit decodes the sections and draws list.sections in the order the server sends (InboxList.swift). Nothing in the app sorts rows.

What it makes real

The 2026-10-08 ruling: newest first in every section (Stopped on you, Holding up work, Waiting on you, Sent, New since you looked, Quiet). The window record's addendum comes from the overseer.

Proofs

  • bun run test:e2e:inbox (inbox-order.spec.ts). Three MCP SDK agents ask a question in the order Pi (A), OpenCode (B), Claude Code (C). Waiting on you reads C, B, A. A pick plus Send on A moves A to Sent ("Saved for Pi"), and Waiting reads C, B. A newer OpenCode message in B's thread waits behind "1 new in ledger" with the order on screen unchanged. After Show, B is first in Waiting. The page logs no errors. On the unfixed list.ts, test 1 fails (it receives A, B, C).
  • Frames, light and dark: research/operational/mobile-proofs/INBOX-ORDER-2026-10-08/ (1-waiting-newest-first, 2-reply-moves-a-to-sent, 3-newer-message-first).
  • The full Playwright suite on the compiled binary: 73 passed, 1 skipped (the tailnet test, which needs PLANNOTATOR_E2E_TAILNET).

Gates

bun run typecheck green. bun test packages apps/hook tests scripts under a temp data dir: 5866 pass, 0 fail. bun run check:release-version green. No packages/ui or packages/core change, so no smoke:package.

Deviation, with the reason

  • The sort key. The brief says "by the time of the row's latest event the section keys on". This PR uses the thread's latest message (last_at) in every section. That is the time each row shows, so the time column reads down in order, which is what the owner complained about. A per-section key (for example, the latest open question's time in Waiting) would need a new wire field, and rows could then look out of order against their own times. Consequence: a plain reply that leaves a question open moves its row to the top of its section, because the reply is the thread's newest message.
  • Holding up work drops "most held up first". The ruling names every section, and Workspaces' approved model ranked Holding by count.
  • waiting_since stays on the wire row. Nothing sorts by it now. Removing it would change the contract the phone decodes, so it is left for a cleanup.

Leaves out

The window record addendum (the overseer writes it). No change to which section a row is in.

The owner saw Pi's older question above OpenCode's newer one in Waiting on
you. Every section now sorts by the thread's latest message (last_at, the
time the row shows), newest first; the section order and the held "N new"
rule stay. Proof: tests/e2e/inbox-order.spec.ts in the inbox-e2e job.
@backnotprop
backnotprop merged commit bd4858b into main Oct 8, 2026
33 checks passed
@backnotprop
backnotprop deleted the feat/inbox-newest-first branch October 8, 2026 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant