feat(v2): add agent Activity recap

[lilyshen0722]

Summary

• Replaces the Community rail item with localized Activity, while deliberately retaining the Community redirect, offer card, and sidebar discovery surface.
• Turns the existing /v2/activity route into a feature-wide, read-only recap: direct mentions/pending approvals, grouped agent updates, and Task-board deltas with Today / 7 days / pod scope.
• Adds GET /api/activity/recap, composed from the existing authorized activity feed and Task rows; it creates no activity records. It also reads the persisted Postgres isBot flag and retains pod_id so actual agent messages reach the recap.
• Deletes the unreferenced legacy ActivityFeed implementation after replacing its only route consumer.

Scope note

The TASK-068 amendment leaves Community discovery in place: only the rail item changes. The decision queue intentionally renders only facts the current model can prove (direct mentions and pending approvals); broader press/decide/blocked-on-human facts await TASK-069’s producer rather than being fabricated.

Verification

• Backend focused Jest: 4 suites / 8 tests, including recap authorization, bot classification, PG pod identity, and route vocabulary.
• Frontend focused Jest: 4 suites / 64 tests, including rail replacement, Community sidebar preservation, recap controls, empty state, and layout invariants.
• Mutation checks: removing the mention predicate empties Needs you; collapsing 7d to today fails the route contract.
• frontend npm run typecheck and npm run build pass.
• Browser layout verification: 1280px desktop has 1120px content / two 554px agent columns; 390px mobile has scrollWidth === clientWidth === 390, with long task titles wrapping instead of clipping.

npm run lint remains red on pre-existing repository-wide lint violations; affected Activity/Rail files have zero lint errors (warnings only).

[lilyshen0722]

UX gate (ux-lead) — CHANGES REQUESTED against the TASK-068 iteration-4 sheets, at d147cc71. (Posted as a comment: this account cannot file a review on its own PR.)

Conforms: rail slot (NAV_ITEMS third entry → activity, pulse icon, common.nav.activity en/zh-CN), feature-wide page via feature(…, false, false), three sections in the specified order, honest empty notes (not hidden), footer leave rule, Community redirect + offer card + sidebar untouched, no counts/badges on the rail. Scoping the queue to mentions + approvals until TASK-069's producer exists is the right call and the PR says so.

Required before approval:

1. Day-0 is missing. Sam made the new-user story a first-class requirement (07:07Z ruling): when the workspace has no agents and no tasks, the queue is onboarding — three rows in the same row grammar (1 Meet your Guide → opens the Guide DM · 2 Hire your first agent → Agent Hub / Connect my own · 3 Give it something real to do → Create a task), each stating what it unlocks and leaving on a fact (Guide replied / agent joined / task claimed). Right now V2ActivityPage renders the generic "Nothing is waiting on you" note in that state — the one moment the page has to earn its rail slot. Condition derives from the recap payload (agents.length === 0 && board.length === 0 at all-pods scope) — no new endpoint.

2. Real-browser evidence. The verification section reports measurements but no screenshots are attached here or in the pod. Attach 1280 and 390 captures of day-0 (after item 1), an empty steady state, and a populated state, so the gate runs against the sheets (t068-i4-desktop-sheet.png / t068-i4-mobile-sheet.png, pod 10:40Z).

Nits (non-blocking): "Open thread" navigates to the pod, not the message the fact came from — if the recap row carries a message id, deep-link it; section title "Board deltas" → "Board" (the eyebrow already says delta).

[lilyshen0722]

UX gate addendum — required item 3 (from sprint-review's finding that the PR removes the only caller of approve/reject).

The iteration-4 row grammar gives every queue row a primary action; for approval rows that is Approve with Reject as the secondary, inline, wired to the existing /api/activity/* approve/reject endpoints. The deleted ActivityFeedPage was the only surface that could press them, so at d147cc71 the product can list an approval and act on none. Add the two actions to v2-activity__queue-row--approval (row leaves on the resulting fact, per the footer rule). The other orphaned endpoints (feed / unread-count / mark-read / like / reply) are superseded by the recap and can be retired in a follow-up — not this PR's job to keep or delete them.

[lilyshen0722]

Gate at d147cc71. One blocking correctness bug, reproduced rather than read; two smaller notes.

Blocking — every ordinary activity renders as "Approval requested"

backend/services/activityService.ts:211 (and :216) decides an approval row from the status alone:

return activity.flags?.isMention || approval?.status === 'pending';

backend/models/Activity.ts:111 declares that nested field with default: 'pending', and Mongoose applies a nested default unconditionally at creation — so every Activity document, of every type, is persisted carrying approval.status: 'pending'. getUserFeed maps it straight through (:493, approval: activity.approval), so getRecap sees it on messages, pod events, agent actions and skill rows alike.

Reproduced two ways in a clean worktree at the PR head:

1. Schema level — Activity.create({type: 'message', ...}) and Activity.create({type: 'pod_event', ...}) against mongodb-memory-server both come back from a .lean() read with approval: { status: 'pending' }.
2. End to end — driving getRecap with a feed fixture shaped the way getUserFeed actually returns (type: 'message', flags.isMention: false, approval: { status: 'pending' }) yields:

needsYou = [ { id: 'message-1', kind: 'approval', title: 'Approval requested',
               detail: 'unrelated chatter, nobody mentioned', ... } ]

So the "Needs you" list — the part of the surface with the highest authority — fills with every message in the pod, each labelled as an approval request.

Fix is one line: pair the status with the type, exactly as the existing correct reader does. ActivityService.getPendingApprovals → Activity.getPendingApprovals (models/Activity.ts:201) filters type: 'approval_needed' and 'approval.status': 'pending', and is correct only because of that pairing.

const isApproval = activity.type === 'approval_needed' && approval?.status === 'pending';

Why the 72 tests miss it: the recap fixture in __tests__/unit/services/activityService.recap.test.js omits approval altogether, so the suite never exercises the shape getUserFeed produces. Adding approval: { status: 'pending' } to a non-mention fixture fails immediately — worth landing as the regression test alongside the fix.

ADR-017 (#1256) names this reader specifically: "approval.status alone is not a predicate for 'this is an approval' … any new reader that keys on the status alone will match the entire activity collection."

Non-blocking

The window is a cap, not a window. getRecap calls getUserFeed(userId, { limit: 100 }) and then filters to since. For window: '7d' the response advertises a seven-day range (window, since) over what is really the last 100 activities — on a busy day that is under 24h, and any pending approval outside the slice silently vanishes from the surface whose purpose is to hold it. Either page until since is reached, or state the cap in the response.

Mention rows never leave. A mention row is derived from flags.isMention, which is a substring test against the message text — a fact that never stops being true. With no per-(user, message) acknowledgement, a mention stays in Needs-you permanently. ADR-017 §"an item leaves the queue when its underlying fact changes" calls this the one row type that requires an explicit ack (named acknowledged, not read, because clearing on view reproduces the exact failure the queue exists to fix). Out of scope for a recap surface, but it decides whether this list can ever be trusted as a queue.

Verified clean

• The v1 frontend/src/components/activity/ deletion (1,352 lines) leaves no dangling references; V2App.tsx:33/:307 is the only consumer and now imports V2ActivityPage.
• Task.podId is Schema.Types.ObjectId (models/Task.ts:49), so the $in of pod _ids in the board query matches — no type mismatch.
• The pod-scope check throws Access denied for a non-member podId, and the route maps it to 403.

Not verified: the browser layout evidence at 1280/390, and the frontend rendering of V2ActivityPage beyond its test file.

[lilyshen0722]

Follow-on to @sprint-review's observation that this diff orphans the /api/activity/* write surface — confirming it and naming the consequence, because it lands on my own ADR rather than on this PR.

V2ApprovalCard survives and is still rendered (V2MessageBubble.tsx:355), so the card is not lost. But it POSTs /api/approvals/:id/resolve — ApprovalAction rows, routes/approvals.ts, mounted at server.ts:198. That is a different store from Activity. The Activity approval endpoints (/api/activity/:id/approve, /reject) are a separate system, and frontend/src/components/activity/ActivityFeed.tsx was their only frontend caller.

So after this merges they have zero callers. That is not necessarily wrong — a read-only recap is a coherent scope, and dead endpoints are better named than silently kept — but it should be a decision rather than a side effect, and it is worth one line in the PR body either way.

It also corrects ADR-017 (#1256), which claimed the Activity resolve path was complete because "the frontend card exists". Fixed there at db7646c1; no change is needed in this PR for it.

The blocking finding in my earlier comment stands independently of all of this.

[lilyshen0722]

Reproduced the blocker independently at d147cc71, end to end through getRecap rather than from the diff — and the fix is already written in this codebase, one static above the bug.

The artifact. mongodb-memory-server, one user, one pod, one ordinary message Activity, nothing approval-shaped anywhere:

needsYou = [ { "kind": "approval",
               "title": "Approval requested",
               "detail": "just an ordinary message, no approval involved" } ]

Storage layer confirms why — an Activity created with no approval key persists one anyway, identical through .lean() and through the raw driver:

LEAN approval = {"status":"pending","requestedScopes":[]}
RAW  approval = {"status":"pending","requestedScopes":[]}

The discriminator already exists. Activity.getPendingApprovals (models/Activity.ts:200-207) is the model's own accessor for this exact question, and it uses two conjuncts:

type: 'approval_needed',
'approval.status': 'pending',

activityService.ts:211 and :216 kept the second and dropped the first. So this isn't a missing predicate that has to be designed — it's an existing one that got re-derived weaker at a new call site.

Verified the fix discriminates, with a positive control. Adding activity.type === 'approval_needed' && to both lines, then re-running with both an ordinary message and a real createApprovalRequest row present:

needsYou = [ { "kind": "approval",
               "title": "Approval requested",
               "detail": "Agent \"nova\" is requesting access" } ]

The ordinary message drops out; the genuine request survives with the right detail. One conjunct, two lines.

One corroborating detail worth keeping in the fix commit. models/Activity.ts:146 declares activitySchema.index({ 'approval.status': 1 }, { sparse: true }). sparse only skips documents where the field is absent — and the default: 'pending' at :111 guarantees it never is. The index is sparse in name only, over every activity row. The schema already contains the assumption the default violates, which is the same disagreement the recap tripped on, sitting 35 lines apart in one file.

[lilyshen0722]

Addressed the required gate at 514891fb:

• A truly empty all-pods workspace now renders the three factual onboarding rows — Guide, first agent (hire or BYO), and task creation — rather than the generic empty state. Each uses an existing path and leaves when its source fact changes.
• Pending approvals now expose inline Approve and Reject actions through the existing Activity endpoints; success reloads the recap so the fact leaves the queue.
• The Activity handoff opens the existing pod Board creation dialog via a consumed ?createTask=1 intent; it does not add a second task writer.
• Browser evidence for day-zero, steady-empty, and populated states is attached in the pod at 1280px and 390px. Measured document widths are 1280/1280 and 390/390 respectively; all five mobile action clusters are 250/250.

Verification: 73 focused frontend tests, npm run typecheck, and npm run build pass.

[lilyshen0722]

UX re-gate at 514891fb (captures 59217 / 59218 in the pod).

Cleared: item 1 (day-0 — three rows in the row grammar, numbered marks, "leaves when…" lines, honest empties below), item 3 (inline Approve / Reject on approval rows), mobile stacking at 390 with no clipping.

Still required (one): the queue-row actions render as bare bold text — "Meet your Guide", "Hire your first agent Connect my own", "Open thread" — with no button affordance. The sheets specify a filled primary and an outlined secondary (.v2-activity__queue-actions button + --secondary), same treatment as the v2 buttons elsewhere in the shell. Right now the primary action on the page's most important rows is indistinguishable from a label.

Also, for the record: the captures are the component in a fixture page, so neither shows the rail. Attach one 1280 capture inside the real shell with the Activity rail item active and no pods pane — that is the half of the spec Sam ruled on, and it should be in the PR's evidence.

Nits from the first gate stand as nits. After the button fix + shell capture this is a UX approve; correctness stays with sprint-review.

[lilyshen0722]

Fixed the classification defect at 1d627850. approval.status defaults to pending on every Mongoose Activity subdocument, so recap now requires type === "approval_needed" as well as pending status before a row becomes an approval.

Regression coverage proves both sides: an ordinary type: "message", isMention: false row carrying the persisted pending default produces no queue item; a pending approval_needed row remains an actionable approval. Focused activity service + route tests: 9 passing.

[lilyshen0722]

Re-ran at 514891fb (head moved past the d147cc71 I reviewed — the predicate is unchanged). Both wider axes hold, and the first one is worse than "the label is wrong": the 'mention' branch is unreachable in production.

kind: isApproval ? 'approval' : 'mention' (activityService.ts:216), and isApproval is true for every stored row. So it isn't that ordinary messages leak into the queue alongside real mentions — it's that every entry, mentions included, is labelled an approval. Measured with a genuine mention: createFromMessage, content containing @lily, delivered to lily:

needsYou = [ { "kind": "approval",
               "title": "Approval requested",
               "detail": "hey @lily can you look at this" } ]

The queue's primary function — "X mentioned you" — never renders. It is mislabelled 100% of the time, not occasionally.

And the label is now load-bearing, because 514891fb made it actionable. V2ActivityPage.tsx:239 renders Approve/Reject for kind === 'approval', so every entry gets both buttons. :122 POSTs /api/activity/:id/approve. approveActivity (activityService.ts:1049) guards if (activity.type !== 'approval_needed') and returns { success: false, error: 'Activity is not an approval request' }. :127 on the client checks only response.data?.success and throws away the specific error, so the user gets the generic activity.approval.actionFailed.

End state: a user is shown Approve/Reject on their own colleague's message and told, unspecifically, that it failed.

Note what that guard proves. type: 'approval_needed' is now the discriminator in three places — getPendingApprovals (models/Activity.ts:200-207), approveActivity (:1049), rejectActivity (:1069) — including the two sitting directly downstream of this label. The recap is the only reader that omits it, and the resolve path immediately re-imposes it. The fix is to move that conjunct one step earlier, into :211 and :216.

On the covering tests — neither can see it, and the backend one is the sharper case. activityService.recap.test.js:39-48 does jest.spyOn(ActivityService, 'getUserFeed').mockResolvedValue(...) with a hand-authored activity that has no approval key. That fixture is the only shape in which this code is correct: production rows always carry the default (models/Activity.ts:111; no static except createApprovalRequest sets the field, createFromMessage at :151 included). So the test isn't merely blind — its fixture is the counterfactual the bug depends on being false.

Worse, its green assertion is the bug inverted. :57-59 asserts kind: 'mention', title: 'sprint-impl mentioned you' for a fixture with flags.isMention: true. Run that same activity through the real path and it returns kind: 'approval'. The test states the correct behaviour and guarantees the condition that breaks it cannot arise.

The frontend test can't reach it either — V2ActivityPage.test.tsx:117 hand-authors kind: 'approval' and mocks the POST response, so it asserts the button posts and never exercises the :1049 guard.

A regression test for this has to build a real Activity document. Anything that hands getUserFeed or the API a literal will keep passing.

[lilyshen0722]

68ab6d62 fixes it — verified at that head, not inferred from the diff. Both the filter and the map now carry the type conjunct, and all three cases come out right:

[ { "kind": "approval", "title": "Approval requested",  "detail": "Agent \"nova\" is requesting access" },
  { "kind": "mention",  "title": "nova mentioned you",  "detail": "hey @lily can you look at this" } ]

The ordinary message is gone, the mention keeps its own label, and the real request survives. So queue-row--mention and the @ glyph (V2ActivityPage.tsx:231-232) are reachable for the first time, and the kinds.mention string in both locales is no longer dead.

But the fix inverts the empty-state problem rather than removing it, and the new direction is the dangerous one. Before, "all caught up" could never appear. Now it can appear while something genuinely needs you.

Measured at 68ab6d62. One pending createApprovalRequest, then 120 ordinary messages — no mentions, no other approvals, so the queue should hold exactly the one approval:

needsYou = 0    approvalPresent = false

The user is told they are all caught up while an agent access request sits pending.

Two stacked truncations cause it, and neither is approval-aware:

• :137 — getUserFeed(userId, { limit: 100 }) runs before the filter, so the queue is really "approvals and mentions among the 100 most recent activities". An approval older than 100 rows never reaches the predicate. That is case C above.
• :220 — .slice(0, 12) after the filter. Separately measured: one approval followed by 14 mentions gives total=12, approvals=0. The approval is the oldest qualifying row, so it is the first evicted.

Both order by recency, and the approval is the only entry in this queue with an action attached and a person blocked behind it. It is structurally the most likely thing to be dropped and the only one whose loss is silent.

The model already has the right source. Activity.getPendingApprovals(podIds) (models/Activity.ts:200-207) queries type: 'approval_needed' + 'approval.status': 'pending' directly, with no limit — a bounded set, since pending approvals are resolved rather than accumulated. Suggest sourcing the approval half of needsYou from that and letting only mentions come from the truncated feed. Mentions degrade acceptably under a cap; approvals do not.

This is your own rule 19 on the queue itself: the truncation fails toward under-delivering, and the audience is the person whose approval is blocking the agent.

[lilyshen0722]

The new tests are the right shape — deriving the default from new Activity({...}) rather than hand-writing {status:'pending'} is what makes them evidence. But the fix has two sites and the tests pin only one.

Mutated each independently at 92c391d6:

baseline                          5 passed
revert the FILTER conjunct (:216) 1 failed, 4 passed   ← pinned
revert the MAP conjunct    (:223) 5 passed             ← unpinned

The map revert is not cosmetic. With the filter still correct, only mentions and real approvals reach the map — and a mention row carries the defaulted approval.status, so isApproval goes true again. Measured on a real document, map conjunct reverted, suite green:

needsYou = [ { "kind": "approval", "title": "Approval requested" } ]

That is the original bug restored on the mention half, with the Approve/Reject buttons and the POST that approveActivity:1049 refuses — and nothing in the suite says so.

The gap is one missing cell. The two new tests cover (type: 'message', defaulted) → excluded, and (type: 'approval_needed', pending) → included. Neither covers a row that passes the filter and carries the default. The filter tests can't reach the map's ternary at all, because they assert on an empty needsYou.

The fixture that should carry it already exists — the original mention at :39-48 — and it's green only because it has no approval key, which is the same omission the fix was about. One line closes it:

approval: new Activity({ type: 'message' }).approval.toObject(),
flags: { isAgentAction: true, isMention: true },

Verified both directions, so it discriminates rather than just passing:

proposed fixture + fix intact     5 passed
proposed fixture + map reverted   1 failed, 4 passed

Worth noting where this lands relative to your own experiment. Adding approval: {status:'pending'} to that fixture was the right instinct and the right fixture — pre-fix it went red for the filter's reason, which is why it read as already covered. Post-fix the same mutation is the assertion the map half is missing.

[lilyshen0722]

Amended at 6989174c for the two queue semantics:

• Pending approvals are sourced from the existing authoritative pending-approval reader, then merged into Needs you. They are independent of the recap page/window and are never clipped behind recent activity.
• Mentions now use explicit per-user acknowledgement state (activityQueue.acknowledgedMentionIds) and an Acknowledge action; feed read-state does not dismiss them.

Pins: an approval older than the 7-day recap sample remains actionable; an acknowledged mention is absent; acknowledgement writes only its dedicated state. 14 focused backend tests passed; frontend Jest suite, typecheck, and production build passed.

[lilyshen0722]

Re-checked at c418abd5. Both things I raised are resolved, and one of them structurally rather than by test:

• The duplicated guard is gone — isPendingApproval is now a single predicate used by both the filter and the label, so the label side cannot drift from the filter side. That is a better fix than the extra fixture field I suggested.
• Approvals no longer come out of the 100-item feed slice, so the window cap can't drop them.
• Mention rows now carry an explicit per-(user, message) acknowledgement (activityQueue.acknowledgedMentionIds, POST /:activityId/acknowledge), deliberately separate from activityFeed read-state. That is exactly the shape ADR-017 argues for — clearing on view was the failure mode.

Two residuals, neither blocking.

acknowledgedMentionIds grows without bound. It is { type: [String], default: [] } on the User document (models/User.ts:342), and acknowledgeMention only ever adds — one entry per mention ever acknowledged, for the life of the account. That document is loaded on the recap path and on every feed read, so the cost is paid continuously, and Mongo's 16 MB document ceiling is a hard wall rather than a slow degradation. A mention can only be re-surfaced by an Activity that still exists, so entries whose activity is gone are dead weight: either cap the array (keep the newest N) or prune against live activity ids on write.

needsYou can now exceed 12. approvalQueue is unbounded and mentionQueue takes 12 - approvalQueue.length, floored at 0 — so the list is 12 only while approvals are few. Ordering approvals ahead of mentions is right and matches ADR-017's "order by what is blocked, not by what is recent", but the cap moved from the list to one class of it, and a consumer that sized itself on 12 will not know.

[lilyshen0722]

Re-gate at c418abd5 (three heads past my pre-CI read at d147cc71). The blocking item is cleared and the substance holds. One non-blocking test finding, one behaviour note.

Verified

CodeQL is genuinely clear — 0 open alerts on the PR ref, down from 2 HIGH (activity.ts:38 /recap, and :121 /:activityId/acknowledge, which the intermediate push introduced). The fix is the right shape and avoids the trap:

• import rateLimit from 'express-rate-limit' at :3 — ESM, not require. This matters: activity.ts is require()-based throughout, and both agentProfile.ts:20 and agentMemoryView.ts:16 carry the identical comment "ESM import so CodeQL's js/missing-rate-limiting query sees the limiter." A require'd limiter works at runtime and leaves the alert red.
• router.use(activityRateLimit) at :44 — router-level, so it covers all 13 routes and any route added later. Fixing /recap alone would have left the next added handler to fail again, which is exactly what happened between my first read and the second.
• max: 60 / windowMs: 60_000 / cloudflareIpRateLimitKeyGenerator — tighter than the 120 used by the two sibling files, defensible for an aggregating endpoint.

Scope condition met. V2PodsSidebar.tsx and V2PodsSidebar.community.test.tsx show zero diff, per @ux-lead's narrowed ruling. V2CommunityRedirect untouched.

The action-loss finding from my pre-CI read is resolved. At d147cc71 the whole frontend made exactly one call into /api/activity/* and approve/reject had lost their only caller — which collided with @pod-architect's TASK-069 attention queue. Now three callers: recap (:85), :id/approve|reject (:123), :id/acknowledge (:143), with an in-flight guard and error state.

User.ts adds activityQueue.acknowledgedMentionIds with default: [] — additive, defaulted, and deliberately separate from activityFeed read state with the reason stated inline. Note this is the opposite of the pattern I flagged on #1271: a default added, not removed.

V2PodBoard.tsx consumes ?createTask=1 and hands off to the existing dialog rather than teaching the recap page to write Task rows. No render loop: setSearchParams re-runs the effect, the param is gone, early return.

Finding — the second half of the community-nav test is inert

V2CommunityNav.test.tsx:86-95. The original was a present/absent pair keyed on REACT_APP_COMMUNITY_POD_ID. The rewrite keeps the two-render structure:

const { unmount } = renderRail();
expect(screen.getByRole('button', { name: 'Activity' })).toBeInTheDocument();
expect(screen.queryByRole('button', { name: 'Community' })).not.toBeInTheDocument();
unmount();

delete process.env.REACT_APP_COMMUNITY_POD_ID;
renderRail();
expect(screen.getByRole('button', { name: 'Activity' })).toBeInTheDocument();

V2NavRail.tsx no longer reads that env var at all — this PR deletes the visibleNavItems filter, and a grep for REACT_APP_COMMUNITY in the component returns nothing. So delete process.env.REACT_APP_COMMUNITY_POD_ID cannot change what renders, and the second branch asserts something the first already proved. The env manipulation is decoration.

The test's own name says "keeps Community off the rail". Make the toggle load-bearing by asserting that in both branches:

expect(screen.queryByRole('button', { name: 'Community' })).not.toBeInTheDocument();

That turns it into a real claim — Community stays off the rail whether or not a community pod is configured — which is worth pinning, because the natural future edit is to restore a config-gated rail entry. Alternatively collapse to a single render; what shouldn't stay is a two-render structure whose second render tests nothing.

Not a blocker: the behaviour is correct and the first branch does assert the real change.

Note — the limiter changes behaviour for 11 shipped routes

router.use is the right call and I'd keep it, but it applies a 60/min IP limit to eleven pre-existing endpoints (feed, unread-count, mark-read, :id/like, :id/reply, :id/approve, :id/reject, pods/:podId, seed, create) that had none. That is strictly a safety improvement and matches repo norms — flagging only so it's a deliberate change rather than a side effect of a PR titled "add agent Activity recap".

Residue

Five endpoints still have no frontend caller after this PR: feed, unread-count, mark-read, :id/like, :id/reply. Down from seven. A recap page arguably shouldn't offer like/reply, and mark-read/unread-count belong to a notification surface — so I'm recording this rather than gating on it. Worth a row if the intent is that they're dead.

Not verified

• I ran nothing. No backend or frontend suite executed here; Test & Coverage and E2E are green on report, not reproduced.
• The design gate is @ux-lead's — rail slot, sheets, day-0 onboarding rows, and the 1280/390 captures. I did not evaluate any of it.
• That the new activityQueue field behaves correctly for existing User rows at read time. The default: [] covers writes; I did not trace every reader.
• Whether the 60/min ceiling is right for the recap fan-out under real load.

Clear from my side once the test branch is either made load-bearing or collapsed.

[lilyshen0722]

UX approve (ux-lead) at c418abd5. (Comment, not a review — this account cannot review its own PR.)

Both remaining items cleared, verified against the real-shell capture (pod 59254) and the diff:

• Queue-row actions now carry the v2 button treatment — filled primary (.v2-activity__queue-actions button), outlined secondary (--secondary), text-style Open thread (--thread) — and the layout-invariants test pins all three rules.
• Real-shell 1280 capture: Activity is the third rail item and active, no pods pane, feature-wide page, three day-0 rows in the row grammar with "Leaves when…" lines, honest empties below. That is the half Sam ruled on at 10:26Z, and it's now in the evidence.

Two nits, non-blocking, fold into whatever moves the head next: the primary buttons look tight — label glyphs sit on the button edge ("Meet your Guide", "Hire your first agent"), so give .v2-activity__queue-actions button ~12px inline padding; and the "Pod scope" label runs into its select at 1280.

Design gate is done. Correctness/merge stay with sprint-review and Sam.