app-shell: on the console HOME the inbox feed polls every 2 s (sys_inbox_message + sys_notification_receipt top=200) instead of the declared 10 s; realtime is loaded but unused for the bell

[hotlong]

What happens

Measured with performance.getEntriesByType('resource') on objectui @ 67dadd6 against the showcase (objectstack main @ a39b02a6b), signed in as the seeded admin:

page	pair GET /data/sys_inbox_message?top=20 + GET /data/sys_notification_receipt?top=200
/_console/home, idle	every 2000 ms (24 pairs in 85 s; gaps 1999-2001 ms)
any app page, idle	every ~10 s (as INBOX_POLL_MS in packages/app-shell/src/hooks/sharedUserFeeds.ts says)

So the home page issues one request per second just to keep the bell current, five times the declared cadence, and the receipt read carries top=200 each time. The SharedFeed dedupes consumers, so the 2 s cadence on home points at a second scheduler on that page (useHomeInbox / the todo card, or a useClientNotifications pollInterval) racing the shared feed rather than joining it.

Separately: the runtime loads RealtimeServicePlugin on a stock boot, but the bell does not subscribe to it — polling is the only transport.

Expected

• One cadence, owned by the shared feed, on every page (home included); the todo card and the bell read the same snapshot.
• Prefer the realtime channel for the bell when the server advertises it, with polling as the fallback; 10 s (30 s hidden) is fine as the fallback cadence.

Related noise found on the same run: the ⌘K palette fires the identical GET /api/v1/search?q=… three times per typed query, and the kanban issues its ?top=100&select=… fetch twice on mount.

Found during the objectstack pin-bump dogfood (objectstack#14295).

Generated by Claude Code

[hotlong]

Claim: PM loop round 4 (dogfood dispatch)
Session: session_62849a16-0144-4728-8942-9f60bb3a73f1
Branch: claude/issue-7249-inbox-feed-single-cadence
Worktree: objectui-issue-7249
Domain: domain:ui
File surface: packages/app-shell/src/hooks/sharedUserFeeds.ts, useHomeInbox.ts, useInboxBell.ts and the home-page consumers that schedule their own inbox reads (+ tests), .changeset/ (stop on breach; explain in the report)
Container & model: M, model: opus, mode:subagent
Clause-②: no
Serial constraints cleared: objectui PR #7284 (app-shell ObjectView/InterfaceListPage, #7245) MERGED 2026-09-02 — start from a main that carries it; no open objectui PR touches app-shell hooks (REST pulls list 2026-09-03 09:10); in-flight #7247 (plugin-charts) disjoint

Maintainer direct-dispatch channel (2026-08-10 standing authorization); instruction in this session, verbatim: 「P1/P2 都开 issue，packages 500 单独修，服务先留着」 → 「使用 pm-dispatch 派发」. Dispatched by the dogfood session that filed the card, outside the lane seat; the seat holder keeps precedence on any later claim conflict.

Generated by Claude Code

[hotlong]

Claim: os-dev, single-issue dispatch.
Session: session_62849a16-0144-4728-8942-9f60bb3a73f1
Branch: claude/issue-7249-inbox-feed-single-cadence
Worktree: objectui-issue-7249 (from origin/main @ b652514)

Starting on the home-page inbox cadence now. Locating the second scheduler before touching any constant.

Generated by Claude Code

[hotlong]

os-dev-report

{
 "issue": 7249,
 "status": "needs_decision",
 "branch": "claude/issue-7249-inbox-feed-single-cadence",
 "pr": "https://github.com/objectstack-ai/objectui/pull/7387",
 "premise_still_valid": false,
 "summary": "The headline defect did not reproduce. Re-measured on the card's own URL (/_console/home on the showcase at :3911, published console bundle), same backend and same seeded admin, 60s idle in a controlled Playwright context: the inbox pair goes out every 10054-10077 ms, i.e. the declared INBOX_POLL_MS, not the reported 2000 ms. Same 10s on this package's dev build (10042-10089 ms), same 10s after 4 rounds of home<->app route churn with the bell popover open, and 1 read per 60s with the tab hidden; approvals held its declared 30s throughout. There is no second scheduler: useHomeInbox and useInboxBell both fetch nothing, and useClientNotifications (the card's other suspect) has zero call sites in the repo. The card's own figures are internally inconsistent too (24 pairs at 2000 ms spans 46s, not the 85s reported). Premise check also passed on the code axis: the measured commit 67dadd602a3a is an ancestor of main and NOTHING has touched sharedUserFeeds.ts / useHomeInbox.ts / useInboxBell.ts since, so the code that produced the report is the code on main today. What was genuinely missing is enforcement, so the PR is tests only, no runtime change: the neighbouring twoSurfaces pins assert only the MOUNT-time dedupe, which any number of schedulers satisfies if they agree on the first tick, so nothing advanced a clock and counted. Four new cases make the cadence a property of the feed rather than of how many consumers mount or which page they are on, plus the hidden-tab throttle and the return-to-tab refresh. The card's second Expected (realtime for the bell) is unreachable from this repo: the server does not advertise a channel.",
 "tests": "All at final commit 1ab3ad61d. (1) pnpm exec vitest run packages/app-shell/src/hooks packages/app-shell/src/console/home -> exit 0, 'Test Files 47 passed (47)', 'Tests 366 passed (366)'. (2) pnpm --filter @object-ui/app-shell type-check -> exit 0; NOT assumed to cover the new test - tsc -p tsconfig.test.json --listFiles | grep -c the new file = 1. (3) pnpm exec eslint --no-inline-config --format json on the changed file -> exit 0, 'files linted: 1', 0 errors 0 warnings; repo-wide pnpm lint NOT run, narrowing declared in the PR with three evidences (population from eslint.config.js which declares no projectService and no parserOptions.project so type-aware linting is off; count read from --format json; per-file judgement means a new-file diff cannot move an untouched file's verdict). (4) node scripts/check-changeset-presence.mjs -> exit 0, names the empty frontmatter as 'the explicit exemption and a complete answer to this gate'; check-changeset-no-major.mjs -> exit 0. (5) Control-byte self-scan of both changed files -> clean. ABLATION, fix committed BEFORE mutating so the restore had a real commit to return to: set INBOX_POLL_MS to 2_000 (the reported cadence) -> three counting cases RED ('expected 31 to be 7'; 'expected 32 to be 8' for the return-to-tab window), 'Test Files 1 failed | 1 passed', 'Tests 3 failed | 15 passed (18)', while sharedInboxFeed.twoSurfaces stayed entirely GREEN - the mutation is the exact defect the card describes and the existing suite cannot see it. Predicted two red cases, measured three (the return-to-tab case counts a window too); the file's note records the measured numbers, not the predicted ones. Hidden-tab case correctly stayed green because the backgrounded delay is max(HIDDEN_POLL_MS, backoff), which a foreground constant cannot move. Mutation proven on disk BEFORE the run: removed-text grep -c = 0, injected-text = 1, blob hash moved 687fd012 -> 6ecf7303. Restore proven AFTER, not assumed from the trap: text counts back to 1/0, git hash-object equal to the HEAD blob 687fd012, git diff HEAD empty, git status --porcelain empty. No dist step is involved - these tests import ../sharedUserFeeds as a relative source path, so no build stands between mutation and assertion. Verification ran UNLOCKED: os-verify-lock.sh found no usable flock on this macOS host and printed 'VERDICT command-exit 0 · UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized'; its official wording is pasted in the PR body.",
 "mcp_calls": "0 - all GitHub work went through the gh CLI; the repo-scoped REST read probe (gh api /repos/objectstack-ai/objectui) succeeded, so no MCP fallback was needed. Dedupe search used gh search issues and was validated by a control term (useClientNotifications returned #7249).",
 "open_questions": [
 {
 "question": "The 2000 ms cadence does not reproduce on the card's own URL, backend and account, across foreground, hidden, and route churn. How should #7249 be dispositioned?",
 "options": [
 "A - Close #7249 as not-reproduced, keeping PR #7387's cadence pin so the invariant is enforced rather than re-measured by the next dogfood; re-open only if a reporter supplies a session that reproduces it.",
 "B - Keep #7249 open narrowed to the receipt read only (sys_notification_receipt?top=200 is re-fetched in full on every 10s tick), which IS confirmed and which the card itself deprioritised.",
 "C - Keep #7249 open pending a re-measurement by the original reporter with the raw resource-timing entries attached, since their figures are internally inconsistent (24 pairs at 2000 ms spans 46s, not 85s)."
 ],
 "recommendation": "A, with B filed separately if wanted. Long-term soundness (weighted highest): the durable asset here is the pin, which converts 'one cadence, owned by the shared feed' from a measured property into an enforced one - that is the declared-equals-enforced direction, and it closes the gap that let this card be filed at all. Real business need: the reported user-visible harm (one request per second from an idle page) is not occurring on any surface measured, so there is no pull for a fix; keeping a card open against a defect that does not reproduce spends triage attention every round. AI-error-prevention: leaving the card open invites the next agent to 'fix' the cadence by editing a constant that is already correct, which the pin would then fight. Startup scope discipline: B is a real but small efficiency item and should stand on its own pull, not ride this card's premise. C only if the maintainer wants the reporter's raw data before closing - it costs a round-trip and does not block A."
 },
 {
 "question": "The card's second Expected asks the bell to prefer realtime 'when the server advertises it'. Measured on the running showcase, the server does not: GET /api/v1/discovery reports realtime as enabled true but status 'degraded', handlerReady false, message 'In-process event bus only - no HTTP/WS realtime surface is mounted', and the routes map carries no realtime entry. Where should the realtime half go?",
 "options": [
 "A - File the transport work on the objectstack side (advertise a realtime route in discovery, expose a subscribe primitive in @objectstack/client) and leave objectui out of it until a channel exists.",
 "B - Build a client-side subscription in objectui now against a channel shape agreed in advance.",
 "C - Drop the realtime half entirely and keep polling as the only transport."
 ],
 "recommendation": "A. Long-term soundness: the missing piece is a server transport, and the contract-first rule says fix it at the producer - option B would mean inventing a transport client-side against a surface that does not exist, which is exactly the speculative-consumer shape the repo's #0.1 forbids, and this dispatch explicitly barred creating one. Real business need: none measurable today - polling at 10s is meeting the surface's needs and no user-visible staleness was observed. AI-error-prevention: worth recording on the objectstack card that 'enabled: true' is NOT the predicate a client should read - a client keying on it would subscribe to nothing and silently lose the bell; the honest predicate is handlerReady true AND a route to connect to. Startup scope discipline: C is premature - the capability is plausibly wanted later and costs nothing to leave unbuilt, whereas deleting the intent loses the analysis. I did not file the objectstack card myself: it lands in a different repo than this dispatch's landing repo, so it is handed to the PM."
 }
 ],
 "out_of_scope_findings": [
 "filed as #7389 (label: finding, no assignee): @object-ui/react exports useClientNotifications with its own setInterval poller over the same ADR-0030 notification rows and has ZERO call sites - dead surface, and a live second-scheduler trap one import away from reintroducing the duplicate-read shape #4197/#4225/#4316 closed. Verified by exhaustive grep: only its own file, the barrel export, one docs page and two changelog entries.",
 "NOT filed, handed to PM with reason: the card's closing paragraph also reports the command palette firing GET /api/v1/search three times per typed query and the kanban double-fetching on mount. Dedupe search found no existing cards for either. I did NOT file them because I could not verify either claim and I had just disproved that same dogfood run's headline measurement - filing two more cards on its unverified word would repeat the failure this task exposed. My palette probe was inconclusive, not negative: the palette never opened under headless Meta+K (paletteOpened false, 0 search requests), so it measured nothing either way. They remain recorded in #7249's body; if #7249 is closed under open question 1 they should be re-filed as their own cards first, ideally after a measurement.",
 "Observation, not filed: the receipt read sys_notification_receipt?top=200 is re-fetched in full on every 10s tick and never incrementally. Confirmed present (it is in the measured request URL) and it is the one factual sub-claim of #7249 that survives; the card itself called it secondary. Covered as option B of open question 1 rather than filed, to avoid pre-empting that disposition."
 ]
}

Generated by Claude Code

[hotlong]

PM disposition — reviewer of record: PM session session_62849a16-0144-4728-8942-9f60bb3a73f1.

The os-dev re-measurement (controlled Playwright context, same URL / backend / account, foreground + hidden + route churn) reads the declared 10 s on every surface; useClientNotifications has zero call sites; nothing on main touched the three hooks since the reported commit. The PM's original reading (resource-timing entries in the Claude Code browser pane, 2026-09-02) showed 12 consecutive 2000 ms gaps at the tail of a 24-request window and is not reproducible in a clean context, so it is treated as a pane artefact (the pane toggles visibility and emulation in ways a user session does not).

Decisions:

1. Close as not-reproduced (option A), keeping PR test(app-shell): pin the shared inbox feed's one declared cadence (#7249) #7387 — the cadence pin that turns "one cadence, owned by the shared feed" from a measured property into an enforced one. Re-open only with a session that reproduces it.
2. Realtime half → objectstack#14646 (option A): the server advertises no channel (handlerReady: false, no route), so the transport is filed at the producer.
3. Surviving sub-claims filed separately: app-shell: the inbox tick re-fetches sys_notification_receipt?top=200 in full every 10 s — never incrementally #7392 (receipt re-fetched in full each tick), command palette: one typed query fires the identical GET /api/v1/search request three times #7393 (palette triple search, PM reading), plugin-list/kanban: switching to the kanban view issues the identical records fetch twice on mount #7394 (kanban double fetch, PM reading); react: useClientNotifications ships a polling notification bridge with zero call sites — dead, and a live second-scheduler trap next to the shared inbox feed #7389 (dead useClientNotifications poller) filed by the dev.

Generated by Claude Code

[hotlong]

ACCEPT (tests-only pin) — reviewer of record: PM session session_62849a16-0144-4728-8942-9f60bb3a73f1. PR #7387 targets main, first line Part of #7249 (the card is closed as not-reproduced; nothing to close), changed files = one cadence test + an empty-frontmatter changeset (no governed path), every check-run green. Spot-read: the pin advances a fake clock and counts reads, so a 2 s constant goes red (3 failed) while the existing mount-time dedupe pins stay green — the invariant is now enforced rather than re-measured. Flipping to ready and arming queue merge.

Generated by Claude Code