studio(interfaces): object nav items that carry filters or viewName collapse into one surface — the preview drops the filter and every item for that object highlights

Filing gate ① — product defect with a named location and a reproduction. reach: Studio → showcase → Interfaces: clicking the "Urgent Tasks" nav item previews every task, including Low and Medium priority rows.

Who acts on it: objectui triage → the Studio / app-shell owner. ⛔ Not a claim. Found in a manual browser QA pass of Studio on 2026-10-07; filed one card per finding on the maintainer's word: 「你发现的问题全部提交 issue」, and on the one-card-per-finding question 「覆盖规则，逐条立卡」.

What happens

The showcase app has nav items that point at the same object with different filters ("In-Progress Tasks", "Urgent Tasks", "In-Review Tasks") or a viewName ("Task List" → tabular). In Studio's Interfaces rail:

every one of them opens the same unfiltered showcase_task list — the filter and view are dropped;
all five rows (Tasks + 3 slices + Task List) are highlighted at once;
the URL is ?surface=object:showcase_task for all of them, so a reload or shared link lands on the first match ("Tasks").

Reproduction

/studio/com.example.showcase/interfaces.
Click Urgent Tasks in the rail. The canvas shows rows with priority Low/Medium; five rail rows are highlighted.
Reload: the highlighted entry is Tasks.

Expected

Each nav entry is its own surface: the preview applies that entry's filters / viewName, only that row is active, and the deep link restores it.

Where it comes from (read in source)

resolveSurface and findSurfaceInTree (app-shell/src/views/studio-design/navSurface.ts) return {type, name, label} and match on {type, name} alone; NavTree in StudioDesignSurface.tsx computes isActive from the same pair.

Suggested direction (triage to rule)

Key the surface by the nav item's id, carry filters / viewName into the preview, and put the nav id in the ?surface= deep link.

Environment

objectstack 879bd38c · examples/app-showcase booted with objectstack dev --ui --seed-admin on an isolated port and SQLite file · objectui 179f6fe9 (HEAD; the framework pin .objectui-sha is a58626c8) served by the console's Vite dev server, perf numbers from a vite build of the same commit · Chromium 141 at 1440×900 · signed in as the seeded platform admin admin@objectos.ai unless stated.

Duplicate check

Semantic issue search on objectstack-ai/objectui (open and closed), interfaces nav item filters viewName surface preview highlight data slice: 3 hits (0 open, 3 closed).
Semantic issue search on objectstack-ai/objectui (open and closed), interfaces nav item with filter or view opens wrong preview active highlight multiple items same object: 3 hits (0 open, 3 closed).
Related, not the same defect:
- finding(plugin-view): the registered object-view renderer (route 2) ignores a named view's grid members, and the Studio view preview hands it stored views — the objectui#7924 named-view family successor card #10885 (closed) — Studio preview / named-view fidelity, adjacent but different defect
Positive control in the same run: related lists action id refusal notice shown to end users on objectstack-ai/objectui returned related lists: an action id the related object does not define draws a refusal notice above the list for whoever opens the record — an authoring fault shown to end users; scope it to authors/admins #11768: yes.

Dedupe words: interfaces nav filters dropped · data slice preview unfiltered · multiple nav items highlighted · surface keyed by object name

Filed by Claude Code (session session_01D76mrPJrSSdaKRxR2rvrMG) from that QA pass.

Generated by Claude Code

Path: ② the capabilities an end user meets in the app — navigation that opens a filtered view | 缺项 | P2

Triage: first grade, `bug` · `priority:p2` (re-graded from the filed p1) · `domain:ui` · `area:studio` · `pm:queue`. Direction as the body proposes

Triage seat (objectstack-wide, seat post objectstack-ai/objectstack#6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T15:58Z. ⛔ Not a claim, ⛔ not a dispatch.

Triage: lands in the Studio Interfaces preview and its ?surface= deep link ⇒ domain:ui; rationale: a Studio or console surface in objectui. Filed from the Studio browser QA pass of 2026-10-07 (objectstack 879bd38c, objectui 179f6fe9).

Why p2, not p1: the defect is in Studio's preview of nav items. The measured symptom (filters dropped, items collapsed) is in the preview, and no published runtime path is shown to break. It runs, but wrong.
Direction:
- key the preview surface by the nav item's id
- carry filters and viewName into the preview
- put the nav id in the ?surface= deep link
Clause-②: no. Patch changeset in objectui.

Claim: PM loop round 5
Session: session_01DrKzdPdyLLBW3qpZ4vtk7z
Account: huangyiirene
Branch: claude/issue-11774-nav-surface-identity
Worktree: objectui-issue-11774
Domain: domain:ui
Seat: domain:ui#1
File surface:

packages/app-shell/src/views/studio-design/navSurface.ts: Surface, resolveSurface (:105) and findSurfaceInTree (:149).
packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx, only the Interfaces pillar's surface regions. Line numbers are on d53fd02:
- NavTree (:1666), and its isActive at :1712;
- the ?surface= capture and mirror (about :2135);
- the deep-link resolve (about :2371);
- the code that hands the current surface to the canvas preview.
packages/app-shell/src/views/studio-design/useSurfaceDeepLink.ts.
packages/app-shell/src/views/studio-design/studio-canvas-preview.tsx, only if the preview needs the entry's filters / viewName passed through.
The tests beside these, and .changeset/11774-*.md.

⛔ Not on it:

the other readers of the surface descriptor: utils/appRoute.ts, layout/ConsoleLayout.tsx, layout/ChatDock.tsx, hooks/surfaceAgent.ts, views/studio-design/StudioAiCopilot.tsx. An additive descriptor field must leave them working unedited.
the Data, Automations and Access pillars' ?surface= handlers (object:, flow:, permission: / owd:);
the nav editor's save path, which is objectui#11776's;
views/metadata-admin/i18n.ts, packages/i18n/**;
views/metadata-admin/PackagesPage.tsx, which is objectui#11784's.

Any file outside this list: the dev reports it before opening the PR (stop on breach; explain in the report).
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier --repo objectstack-ai/objectui over these paths: no path-derived mandate; default tier)
Clause-②: no
Responsibility: objectui app-shell Studio: the Interfaces rail identifies a nav entry's surface by {type, name} alone (navSurface.ts resolveSurface/findSurfaceInTree, NavTree isActive, the ?surface= deep link), so entries that point at one object with different filters or viewName collapse into one unfiltered surface | the published navigation metadata carries each entry's id, filters and viewName, and the filer's showcase app declares them | every author previewing an app whose nav holds data slices or named views of one object; measured by the filer on showcase: Urgent Tasks previews Low and Medium rows, five rail rows highlight, and a reload lands on Tasks
Thread-read: 6041675593
Serial constraints cleared: none blocking.

area:studio in flight:
- seat 3's objectui#11784 (claim 6044180897; draft PR objectui#11829: PackagesPage.tsx, its test, metadata-admin/i18n.ts, a changeset). Disjoint from this surface.
- seat 3's objectui#11773 was released at 6045522210 (pm:blocked). Its client half landed as 2dec305, so the round-3 and round-4 serial line on StudioDesignSurface.tsx no longer holds this card.
Other open objectui PRs: objectui#11830 (plugin-grid / plugin-dashboard), objectui#11600 (release), objectui#11069 (CLI). None touches these files. Read 2026-10-07T19:51Z.
This seat: dispatch is serial (maintainer instruction, seat post 6020143345). Its previous card, objectui#11780, landed at d53fd02, so nothing else of this seat is in flight.
Fold-or-serial with objectui#11776 (the untargeted "Add nav item" placeholder is sent on save): serial, not folded. It is a different defect shape on the nav editor's save path, which this surface leaves alone.

Why Clause-②: no: this is Studio-internal identity for a preview surface. navSurface.ts is not on the @object-ui/app-shell package entry. No accepted input widens, and no export, prop, type member of @object-ui/types, or locale key is added. Fence:

every existing ?surface=<type>:<name> link keeps resolving as today. The app→Studio bridge and shared links emit that form.
the nav-id form is additive.

If the fix needs a published export, a contract change, or a change to how the runtime console applies filters / viewName, the dev stops and reports, and the seat re-claims.

os-dev-report
{
"issue": 11774,
"status": "done",
"branch": "claude/issue-11774-nav-surface-identity",
"pr": "#11833",
"session": "session_01DrKzdPdyLLBW3qpZ4vtk7z (subagent of the domain:ui#1 PM session; the claim 6045642220 names this branch, re-read before the first edit)",
"premise_still_valid": true,
"summary": "The Interfaces surface is now the nav ENTRY. resolveSurface carries the entry id as navId, plus an object entry's filters and viewName as authored; the binding stays object:showcase_task for all five showcase entries. isSameSurface (nav id when both sides carry one, else {type,name}) drives NavTree isActive. findSurfaceInTree opens the entry a deep link names by id while that entry exists, else falls back to the first {type,name} match as before. The deep link carries the id in a separate key, ?surface=TYPE:NAME&nav=ID, so every TYPE:NAME parser stays untouched. The default object canvas receives the entry through a Studio-internal context, not the published StudioCanvasPreviewProps. It reads the entry the runtime's way: resolveHref decides the landing, a /data landing is read with parseUrlFilterTriples and becomes table.filter, and a /view/ID landing is matched with resolveViewId against the object's merged listViews and passed as listViews plus defaultListView. Draft PR objectui#11833. The filer's three steps were reproduced before the fix and cleared after it, in Chromium.",
"tests": {
"head": "1a301c4 (local git rev-parse --short HEAD for the gate union; remote branch head equal, read back)",
"gates": [
"pnpm exec vitest run --maxWorkers=2 packages/app-shell/src/views/studio-design/ apps/console/src/components/StudioRoute.test.tsx apps/console/src/components/StudioRoute.landingI18n.test.tsx (via os-verify-lock) → 0 → Test Files 97 passed (97) / Tests 604 passed (604)",
"pnpm --filter @object-ui/app-shell type-check (script echoed: tsc --noEmit && tsc -p tsconfig.test.json) → 0; tsc --listFilesOnly on tsconfig.test.json lists all 4 touched test files",
"pnpm --workspace-concurrency=2 --filter '@object-ui/app-shell^...' build → 0 (run once before the first commit; the closure excludes app-shell, the only package the diff touches)",
"pnpm check:control-bytes → 0 → check-control-bytes: OK",
"pnpm check:new-line-citations → 0 → VERDICT new-cross-file-line-citations: 0 new citation(s), enforcement report-only → exit 0",
"pnpm check:changeset-claims → 0 → No pending changeset names a file this change touches.",
"pnpm check:pending-changeset-literals → 0 → No test source names a pending changeset.",
"ADDED from the actual diff (new package imports in studio-canvas-preview.tsx, a new vi.mock test file): pnpm check:phantom-deps → 0 → Every in-scope import is declared by the package that publishes it.; pnpm check:esm-specifiers → 0 → no un-ledgered package emits an extensionless relative specifier; pnpm check:vi-mock-specifiers / check:vi-mock-inherit / check:vi-mock-override-shape → 0 / 0 / 0 → OK; pnpm check:test-path-roots → 0 → OK",
"node scripts/check-changeset-presence.mjs → 0 → 8 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s); node scripts/check-changeset-no-major.mjs → 0; node scripts/check-governed-queue-guard.mjs --test (the 9 diff paths) → 0 → NOT GOVERNED",
"eslint --no-inline-config over the 8 changed TS files, compared per file with the base blobs: only new findings are +2 react-refresh/only-export-components warnings in studio-canvas-preview.tsx (3 of that rule already there); the run's 1 error (react-hooks/static-components, Data pillar) is identical on the base. Repo-wide pnpm lint: NOT MEASURED, reason: CI-owned."
],
"H1_measurement_on_base": "scratch vitest run of resolveSurface over the five showcase showcase_task entries (never committed): nav_tasks, nav_slice_in_progress {status:in_progress}, nav_slice_urgent {priority:urgent}, nav_slice_review {status:in_review}, nav_report_tabular {viewName:tabular} each returned exactly {type:object,name:showcase_task,label} with no id, filters or viewName; findSurfaceInTree(object:showcase_task) returned Tasks. H1 confirmed, NavNode already declared id.",
"H2": "confirmed all three ({type,name} in findSurfaceInTree, NavTree isActive, the ?surface= mirror keyed on type+name). Fourth reader: leafKeyOf (draft buffer, selection stamp, autosave target) is deliberately left on {type,name}, since two entries on one page edit the same page. The copilot chip (onSurfaceLabelChange vs StudioAiCopilot's ?surface= parse) also matches by type/name; it stays correct unedited because the reported label is the open entry's.",
"H3": "runtime path found. NavigationRenderer resolveHref (exported by @object-ui/layout, documented as the single nav-to-URL source; precedence recordId, then filters, then viewName) sends a filters entry to /OBJECT/data?filter[F]=V, which ObjectDataPage reads with parseUrlFilterTriples, and a viewName entry to /OBJECT/view/VIEW, which ObjectView matches with resolveViewId. The preview reuses exactly those functions. Nothing outside the fence was needed.",
"H4": "id is REQUIRED on every nav item (BaseNavItemSchema id: SnakeCaseIdentifierSchema, installed @objectstack/spec 17.7.0), so served nav carries it; the schema states unique but enforces no uniqueness. Fallback for an id-less draft entry: compare by {type,name} (the old rule), and the mirror writes no nav key. No id is invented.",
"reverse_check": "the 4 source files were checked out from d53fd02 with the pins kept, with a trap restoring from HEAD; the restore was proven by git diff HEAD empty and 4 blob hashes equal to HEAD. Markers on disk: isSameSurface count 0, the old isActive line count 1. StudioDesignSurface.navEntryIdentity-11774.test.tsx went 4 failed / 2 passed. First pin, predicted direction: expected [Tasks], received [Tasks, In-Progress Tasks, Urgent Tasks, In-Review Tasks, Task List]. Round-trip: expected nav_slice_urgent, received null. The CONTROL pin and the fixture-parse pin passed on the base as on the fix.",
"browser_reading": "Chromium /opt/pw-browsers/chromium at 1440x900 against a dev-only harness, never committed and deleted: the real InterfacesPillar from source over an in-memory metadata backend (fetch shim) and an in-memory data source, with the showcase nav abridged to its showcase_task entries. BEFORE (source at d53fd02): step 2, click Urgent Tasks: 5 rows active, find had no filter, 8 rows with priorities Urgent/High/Medium/Low, URL ?surface=object:showcase_task. Step 3, reload: caption Tasks, 5 rows active. AFTER (1a301c4 source): step 2: 1 row active (Urgent Tasks), find filter [[priority,=,urgent]], 3 rows all urgent, URL ?surface=object:showcase_task&nav=nav_slice_urgent. Step 3, reload: caption Urgent Tasks, 1 row active, same 3 rows. Extra, click Task List: 1 row active, the tabular view's columns (no priority column).",
"deviations": [
"Control URL: highlight, preview and restore on a distinct-object app are unchanged (the control pin is green on base and fix), but the mirrored URL now carries the entry id for every entry with one, distinct-object apps included. This is deliberate: a shared link keeps naming its entry if a second entry on the same object is added later. It reads against the order's literal 'behaves exactly as before' only on the URL.",
"The entry reaches the canvas through a Studio-internal React context (StudioCanvasNavEntryContext in studio-canvas-preview.tsx, not re-exported from the package entry) rather than a StudioCanvasPreviewProps member. The claim's Clause-② basis rules out a new prop on the published face, so a canvas registered over the default does not see the entry (see open_questions).",
"The browser reading used a dev-only harness, not the full console against objectstack dev, because the shared objectstack checkout is not installed or built in this container. The URL path is the harness page, not /studio/com.example.showcase/interfaces.",
"Shared hook useSurfaceDeepLink: on the Data, Automations and Access pillars the mirror now also clears a stray nav key. This is inert because no producer writes one there, and their handlers are unedited.",
"Repo-wide lint not run (CI-owned); targeted eslint only, as above."
],
"files_changed": [
".changeset/11774-nav-surface-identity.md",
"packages/app-shell/src/views/studio-design/navSurface.ts",
"packages/app-shell/src/views/studio-design/navSurface.test.ts",
"packages/app-shell/src/views/studio-design/useSurfaceDeepLink.ts",
"packages/app-shell/src/views/studio-design/useSurfaceDeepLink.test.ts",
"packages/app-shell/src/views/studio-design/studio-canvas-preview.tsx",
"packages/app-shell/src/views/studio-design/studio-canvas-preview.test.tsx",
"packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx",
"packages/app-shell/src/views/studio-design/StudioDesignSurface.navEntryIdentity-11774.test.tsx"
]
},
"mcp_calls": "0",
"api_writes": "2 REST writes via the scripts/pm relay tools, plus git push. (1) pr_create through fleet-write/dispatch.mjs: repository_dispatch POST /repos/objectstack-ai/objectstack/dispatches, executed as POST /repos/objectstack-ai/objectui/pulls (draft forced), run 37684144137, read-back 8886 bytes sent = 8886 stored. (2) this os-dev-report comment through post-stamped.mjs: POST /repos//issues/11774/comments. git push of claude/issue-11774-nav-surface-identity: empty-branch probe plus 2 pushes, not REST. Zero label writes, zero assign writes. Reads used gh api GET only.",
"open_questions": [
{
"question": "Should a canvas registered over the default with registerStudioCanvasPreview('object', ...) also receive the open nav entry (filters / viewName)? Today only the built-in StudioObjectRecordsCanvas reads it, through a Studio-internal context, because a new StudioCanvasPreviewProps member widens a published face (Clause-②).",
"options": [
"A: add optional members to StudioCanvasPreviewProps (Clause-② yes, a minor-shaped published change, docs and README entry). It costs a published contract that someone must keep.",
"B: keep it Studio-internal (this PR). It costs nothing now; a downstream override keeps today's unfiltered behaviour."
],
"recommendation": "B. Business need, measured: no in-tree producer registers an object canvas override (git grep of registerStudioCanvasPreview( on origin/main outside tests finds one call, the built-in default; out-of-tree hosts were not read), so there is zero measured pull. Long-term: the context is a seam that can be promoted to a prop later without a breaking change. AI-error axis: a published prop nobody reads is a declared-but-unenforced surface. Startup focus: no capability expansion without pull."
}
],
"out_of_scope_findings": [
"carrier: 承接者:无 · noted, not filed (no public-door reach measured) · the nav item id is described as unique (BaseNavItemSchema 'Unique identifier for this navigation item') but the installed spec 17.7.0 carries no uniqueness refinement for navigation ids (a grep finds one only for flow edge ids); two entries sharing an id would both highlight in the rail and the deep link opens the first · dedupe words: nav item id uniqueness · duplicate navigation id · app navigation id refinement",
"carrier: 承接者:无 · noted, not filed (not reproduced through a public door) · a page entry's params, like an object entry's filters, makes two entries on one page different landings; identity is now per entry (navId), but the Interfaces page preview does not apply params · dedupe words: interfaces page nav params preview · nav entry params dropped studio",
"carrier: objectui#10885 family (closed; named-view member coverage of the registered object-view renderer) · noted · the viewName preview passes the object's merged listViews entry the way the Studio's ViewPreview does, so it inherits that route's coverage; ObjectDataPage's field-level trimming and filter chips are not reproduced in the preview, and a view held only as a saved sys_view row previews the plain list · dedupe words: studio viewName preview fidelity · object-view listViews route coverage"
]
}

Review: ACCEPT — PR objectui#11833 (head `1a301c4`) · the dev's open question ruled B: the nav entry stays Studio-internal

domain:ui seat 1 · session_01DrKzdPdyLLBW3qpZ4vtk7z · reviewed against the PR diff, its file list and check runs, read 2026-10-07T20:49Z. Report: os-dev-report 6046532332 on this card.

Ruling on the open question: B

A canvas registered over the default with registerStudioCanvasPreview('object', …) does not receive the open entry. The entry reaches only the built-in StudioObjectRecordsCanvas, through the Studio-internal StudioCanvasNavEntryContext. No StudioCanvasPreviewProps member is added.

Reasons, by the four axes:

Business need, measured: no in-tree producer registers an object canvas override. Outside tests, registerStudioCanvasPreview( has one call on main, the built-in default. There is no pull for the published member.
Long-term: a context can later become a prop without a breaking change.
AI-error axis: a published prop that nothing reads is a declared-but-unenforced surface.
Startup scope: no capability expansion without pull.

If an override ever needs the entry, that is a Clause-②: yes card of its own.

Review

Shape: draft → main. The first line is Fixes #11774, and Clause-②: no starts a later line.
Scope: 9 files, +860/−38, all inside claim 6045642220's surface:
- navSurface.ts;
- useSurfaceDeepLink.ts;
- StudioDesignSurface.tsx: three hunks, at NavTree's isActive, the deep-link resolve comment, and the canvas mount;
- studio-canvas-preview.tsx;
- their tests, plus one new pin file and one changeset (@object-ui/app-shell patch).
None of appRoute.ts, ConsoleLayout.tsx, ChatDock.tsx, surfaceAgent.ts or StudioAiCopilot.tsx is touched. Neither is any other pillar's ?surface= handler, nor i18n.ts.
Clause-② re-read on the diff:
- The added exports are module-level: isSameSurface, SurfaceIdentity, DESIGNER_SURFACE_NAV_PARAM, parseSurfaceTarget, StudioCanvasNavEntry, StudioCanvasNavEntryContext, navEntryListTarget, NavEntryListTarget.
- packages/app-shell/src/index.ts re-exports studio-canvas-preview.js by name (registerStudioCanvasPreview, getStudioCanvasPreview, listStudioCanvasPreviewTypes, StudioObjectRecordsCanvas, and the two types). It names none of the new ones.
- StudioCanvasPreviewProps is unchanged, and StudioObjectRecordsCanvas keeps its signature.
- No locale key is added, and no @object-ui/types member. no holds.
Mechanism checked on the diff:
- resolveSurface carries navId on every variant, and filters / viewName on object. The binding is unchanged: all five showcase entries still bind object:showcase_task.
- isSameSurface compares by nav id when both sides carry one, else by {type, name}. It drives isActive.
- findSurfaceInTree prefers an existing id, then falls back to the first {type, name} leaf in tree order, the old rule.
- The deep link adds a separate ?nav= key, so the ?surface=<type>:<name> grammar every reader parses is unchanged. No nav query key exists elsewhere in app-shell, apps/console or layout; I checked by grep.
- On pillars without entry ids, the mirror deletes a stray nav. That is inert, because no producer writes one there.
Preview reuses the runtime's reading rather than a second interpretation:
- resolveHref (@object-ui/layout) decides the landing.
- A /data landing is read with parseUrlFilterTriples, as ObjectDataPage reads it.
- A /view/<id> landing is matched with resolveViewId against the object's merged listViews, as ObjectView matches it.
- A plain entry, or no entry, renders the exact schema rendered before.
- useAuth and useMetadata both fall back safely outside their providers.
- @object-ui/auth, layout, core, react and types are already declared dependencies of app-shell; check:phantom-deps is green.
H1 to H4, as measured by the dev:
- H1 is confirmed on base: the five entries each resolved to the same {type, name, label}, with no id.
- H2: all three readers are confirmed. A fourth, leafKeyOf (the draft buffer and autosave target), is deliberately left on {type, name}, because two entries on one page edit the same page. I accept that.
- H3: the runtime path was found and reused.
- H4: the spec requires id on every nav item. An id-less draft side falls back to {type, name}, and no id is invented.
Declared deviation, accepted: the mirrored URL now carries &nav= for every entry with an id, including apps whose entries open distinct objects. Highlight, preview and restore are unchanged there, and the control pin is green on base and fix. A shared link keeps naming its entry if a second entry on the same object is added later.
Tests:
- Pins: 6 rows in the new surface pin file (spec-validity of the fixture, exact highlight with the preview's slice or view, deep-link round trip, back-compat, fallback for a removed id, and the distinct-object control). There are also new rows in navSurface.test.ts (8), studio-canvas-preview.test.tsx (9) and useSurfaceDeepLink.test.ts (5).
- Reverse check: the 4 sources at base turned 4 of 6 rows red in the predicted direction. All five entries were active where one was expected, and the round trip returned null. The control and fixture rows stayed green, and the restore was proven by blob hash.
- Local runs: studio-design/ plus the two console StudioRoute tests, 97 files and 604 tests green. app-shell type-check green.
- Real browser (a dev-only harness over the real InterfacesPillar):
  - before the fix, Urgent Tasks highlighted 5 rows and previewed all 8 rows, and a reload landed on Tasks;
  - after it, 1 row is active, the preview queries [[priority, =, urgent]] and shows 3 rows, and the reload restores Urgent Tasks;
  - Task List shows the tabular view's columns.
Overlap re-read: since the PR's base d53fd02, main gained only objectui#11830 (plugin-grid / plugin-dashboard). None of this PR's paths changed.
CI at 1a301c4: 42 runs, still converging at this read: 28 green, 3 expected skips, 11 in progress, none red. The PR waits to be queued until every check completes.
Out-of-scope notes, not filed (no public-door reach measured):
- nav-id uniqueness is described but not enforced by the spec;
- a page entry's params are not applied in the page preview;
- the viewName preview inherits the objectui#10885 family's view-preview coverage.
PR assignee: set by this seat to huangyiirene, the card's assignee.

Generated by Claude Code

Landed: PR objectui#11833 → `main` `8273f4b`

domain:ui seat 1 · session_01DrKzdPdyLLBW3qpZ4vtk7z · verified 2026-10-07T21:19Z.

Merged through the merge queue at 2026-10-07T21:18:25Z, after it was queued at 2026-10-07T21:02:08Z.
- CI on head 1a301c4 before queueing: 40 of 43 check runs passed, and the 3 skipped are the expected ones.
- check-governed-merges.mjs read 0 of 9 paths governed and 898 changed lines, under the human-merge threshold.
Content check:
- 8273f4b is one squash commit on parent 58b277c. It changes 9 files, +860/−38, the same as the PR.
- 8 of the 9 files are blob-identical between the reviewed head 1a301c4 and 8273f4b.
- The ninth, StudioDesignSurface.tsx, also took seat 3's objectui#11831 (58b277c, the post-delete landing) between this PR's base d53fd02 and its merge. Its per-file patch-id matches: ee445a6e… in the PR and in the squash.
- The squash's whole diff has the PR diff's patch-id, 0176e9a1….
- So the landed bytes are the reviewed change, applied on top of fix(app-shell): package sheet asks in-app before Delete, Discard and Duplicate; Studio returns to its landing after a delete (objectui#11784) #11831. The merge queue ran CI on that combined tree.
- On main: isSameSurface hits navSurface.ts.
Card: closed completed by the PR's Fixes. pm:dispatched was removed and read back.
Landing window: objectui#11784 (seat 3, PR objectui#11831) also closed after 21:00Z, by its own PR. This PR closes only this card.
On record from the ACCEPT (6046586240): the open question was ruled B. The entry stays Studio-internal, and no StudioCanvasPreviewProps member was added. An override that needs it is a Clause-②: yes card of its own.

Generated by Claude Code

fix(app-shell): Studio's Interfaces rail keys a nav entry by its id, …

Navigation Menu

Repository navigation

studio(interfaces): object nav items that carry filters or viewName collapse into one surface — the preview drops the filter and every item for that object highlights #11774

What happens

Reproduction

Expected

Where it comes from (read in source)

Suggested direction (triage to rule)

Environment

Duplicate check

Triage: first grade, `bug` · `priority:p2` (re-graded from the filed p1) · `domain:ui` · `area:studio` · `pm:queue`. Direction as the body proposes

Review: ACCEPT — PR objectui#11833 (head `1a301c4`) · the dev's open question ruled B: the nav entry stays Studio-internal

Ruling on the open question: B

Review

Landed: PR objectui#11833 → `main` `8273f4b`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

studio(interfaces): object nav items that carry filters or viewName collapse into one surface — the preview drops the filter and every item for that object highlights #11774

Description

What happens

Reproduction

Expected

Where it comes from (read in source)

Suggested direction (triage to rule)

Environment

Duplicate check

Activity

objectstack-fleet commented on Oct 7, 2026

Triage: first grade, bug · priority:p2 (re-graded from the filed p1) · domain:ui · area:studio · pm:queue. Direction as the body proposes

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

Review: ACCEPT — PR objectui#11833 (head 1a301c4) · the dev's open question ruled B: the nav entry stays Studio-internal

Ruling on the open question: B

Review

objectstack-fleet commented on Oct 7, 2026

Landed: PR objectui#11833 → main 8273f4b

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Triage: first grade, `bug` · `priority:p2` (re-graded from the filed p1) · `domain:ui` · `area:studio` · `pm:queue`. Direction as the body proposes

Review: ACCEPT — PR objectui#11833 (head `1a301c4`) · the dev's open question ruled B: the nav entry stays Studio-internal

Landed: PR objectui#11833 → `main` `8273f4b`