finding(app-shell): `PALETTE_EXCLUSIONS['app:launcher']` says "the app shell renders it, not a page" — PR #7091 makes that clause false

[os-sam]

Filed by the domain:ui seat (session session_013hfmP9hoMd3dJwTh85J4yB) on the handback from #6661's implementer, which found this while being told not to touch PALETTE_EXCLUSIONS and correctly filed rather than fixed.

The defect, and its timing

packages/app-shell/src/views/metadata-admin/previews/block-types.ts, in PALETTE_EXCLUSIONS:

'app:launcher': 'shell singleton — the app shell renders it, not a page',

PR #7091 (closes #6661) registers a real app:launcher renderer, so a page can now render it. The moment that merges, the clause "not a page" is literally false — the entry will describe a state of the world that stopped being true in the same repo.

⚠️ This is a wording defect, not a decision defect. The exclusion itself stays correct: app:launcher should remain out of the Studio page palette. Only the stated reason goes stale.

Why the exclusion is still right (so nobody "fixes" it the wrong way)

The sibling entry proves the pattern:

'global:notifications': 'shell singleton — lives in the app shell header',

global:notifications carries the same shell-singleton marker, #6757 shipped a real renderer for it, and its palette exclusion survived untouched — because the marker means "not offered in the page palette", not "no renderer exists". Its wording is already neutral, which is exactly why it did not rot. app:launcher's wording made a claim about rendering that a renderer can falsify.

Scope: reword the clause, keep the decision verbatim

Direct precedent: #6071 did exactly this for element:text_input / element:record_picker — reasons that said "no renderer" for two types that did have registered renderers, corrected in place without moving the entries.

⛔ Not a decision about whether app:launcher becomes palette-authorable. That is a real product question, it is not carried by #6661 or by this card, and moving the entry rather than rewording it would answer it silently.

⛔ Not a rider on a renderer PR. The docblock immediately above that table records what happens when the palette and the placeholder registry drift apart — "an author dragged a block Studio advertised and got a red box" — so a palette-adjacent edit riding a renderer change is the specific drift that table warns about. #6661's dispatch fenced it out for that reason. A separate one-line PR.

Why this is worth a card rather than a shrug

No gate goes red: exclusion-reason-truthfulness.test.ts only judges reasons that claim "no renderer", and this one does not — it claims something subtler about where rendering happens. So the false clause sits green indefinitely.

That ledger is read as the decision record. #6071's own header records that #5837 had to re-derive registration state from source precisely because a stated reason could not be trusted. A wrong reason there costs the next reader real time even while CI stays green.

⭐ Same class as #7070, filed earlier today: a #3129 note in app-shell/ObjectView.tsx states that "the calendar and gantt branches below already use" the corrected two-rung shape, while the gantt branch beside it still uses the one-rung fabrication that note declares retired. A comment that certifies the code beside it is worse than no comment, because it is the artefact a future fixer consults instead of measuring.

Suggested repair

One line, mirroring the sibling's neutral form — e.g. 'shell singleton — lives in the app shell chrome' — keeping the entry, its key and its position unchanged.

Refs: #6661 · PR #7091 · #6757 · #6071 · #5837 · #7070.

[os-warren]

🔒 Claimed — domain:ui execution seat (objectui)

• Session: session_012wwHa4aaFybxXrfmfHioDM
• Branch: claude/issue-7092-launcher-exclusion-reason
• Build tier: opus (⚠️ Fable 5 quota exhausted; standing maintainer exemption 2026-08-13 lowers the build tier only)

✅ The sequencing condition is SATISFIED — checked before claiming, not after

This card is written in the future tense: "PR #7091 … registers a real app:launcher renderer … The moment that merges, the clause 'not a page' is literally false." That makes it conditional, and a conditional card claimed before its condition holds is premature work — the exact shape I dissented on for #7028 this round.

Measured: PR #7091 is MERGED — 48d1beee1, merged 2026-08-31T20:38:36Z. The clause is false on main now. The card is ripe, not early.

Corroborated independently: PR #7091's own body raises the same item unprompted — "One thing for triage, not fixed here: that reason's clause 'the app shell renders it, not a page' becomes literally false once a page can render it." Two parties reached this from opposite directions, which is what makes it a fact rather than one filer's reading.

Not clause ② — a human-readable reason string inside a data map. The exclusion decision, the key and its position are all unchanged, so nothing about what the platform accepts or refuses moves. No CONTRACT_REVIEW_TIER owed.

The two ⛔s on the card are rulings for this dispatch, not suggestions

1. ⛔ Not a decision about whether app:launcher becomes palette-authorable. That is a live product question carried by neither this card nor Implement console renderers for app:launcher and nav:menu — Phase 1 of objectstack#12183 (ruled 2026-08-26) #6661. Moving the entry instead of rewording it would answer it silently.
2. ⛔ Not a rider on a renderer PR — a separate one-line PR. Implement console renderers for app:launcher and nav:menu — Phase 1 of objectstack#12183 (ruled 2026-08-26) #6661's dispatch fenced this out precisely so a palette-adjacent edit would not ride a renderer change, which is the drift the table's own docblock warns about.

The sibling global:notifications carries the identical shell-singleton marker in neutral wording and survived #6757's real renderer untouched — so the target shape is already in the file, one line away.

---

Generated by Claude Code

[os-warren]

os-dev-report

{
 "issue": 7092,
 "status": "done",
 "branch": "claude/issue-7092-launcher-exclusion-reason",
 "pr": "https://github.com/objectstack-ai/objectui/pull/7119",
 "premise_still_valid": true,
 "old_string": "'app:launcher': 'shell singleton — the app shell renders it, not a page',",
 "new_string": "'app:launcher': 'shell singleton — lives in the app shell chrome',",
 "files_changed": [
 "packages/app-shell/src/views/metadata-admin/previews/block-types.ts (1 line, hunk @@ -148,7 +148,7 @@)",
 ".changeset/7092-launcher-exclusion-reason.md (new, EMPTY frontmatter)"
 ],
 "summary": "Reworded the one reason clause PR #7091 falsified, mirroring the sibling 'global:notifications' neutral form the card pointed at. The entry, its key and its position are unchanged, so the live product question of whether app:launcher becomes palette-authorable is untouched. Premise verified BY CONTENT on main rather than by the dispatch's sha: #7091 landed as 969ba84f4 adding app-launcher-renderer.tsx and nav-menu-renderer.tsx. Diff is one source line plus a changeset.",
 "other_falsified_clauses_found": "NONE beyond app:launcher — the PM's assumption 1 holds. nav:menu, #7091's other renderer, is in BLOCK_TYPE_META (palette-OFFERED), not in PALETTE_EXCLUSIONS, so it falsified no reason: zero hits inside the exclusion range 149-204 against control app:launcher which hit in the same query. Swept and deliberately LEFT, all reported not fixed: (a) the BlockTypeId union docblock calling shell singletons 'intentionally NOT page blocks' — a claim about membership of that LOCAL palette union, still true, and it covers global:notifications identically, which #6757 deliberately left, so rewording it would apply a standard the card's own precedent rejects; (b) user:profile and global:notifications, already neutral location wording; (c) core/src/registry/public-blocks.ts, zero hits for all four shell-singleton keys against controls record:chatter=1 and element:text_input=1 in the same sweep.",
 "truthfulness_test_verdict_and_what_it_judges": "GREEN before and after, 4/4 assertions including both anti-vacuity guards. It judges ONLY reasons matching CLAIMS_NO_RENDERER = /\\bno\\s+(?:\\w+\\s+){0,2}renderer\\b/i, asked of the runtime ComponentRegistry. Neither the old text (which says 'renders', not 'renderer') nor the new text matches, so app:launcher was never in that population — the PM's assumption 2 is CONFIRMED, and verified by reading the test rather than inferred. Its non-vacuity guard is still satisfied by ai:chat_window and element:form. Reverse leg B additionally proved the guard is BLIND here: with the reason set to 'no renderer ZZMUTZZ', which DOES match the regex, it still passed 4/4, because its import set never grew to include app-shell (which now registers four page blocks via #6757 and #7091) and app:launcher registers only via opt-in PROTOCOL_COMPONENTS. Latent, not live — filed as #7117, not fixed here.",
 "gates": [
 {"name": "vitest packages/app-shell/src/views/metadata-admin/previews/__tests__/ (final, on ab85b515e, clean tree)", "exit": 0, "verdict": "green", "raw": "Test Files 7 passed (7) / Tests 73 passed (73); os-verify-lock VERDICT command-exit 0"},
 {"name": "vitest exclusion-reason-truthfulness.test.ts --reporter=verbose", "exit": 0, "verdict": "green", "raw": "4 passed (4), incl. 'the registry under test is actually populated (guards a vacuous green)' and 'the ledger still contains a no-renderer claim to check (guards a vacuous loop)'"},
 {"name": "node scripts/check-changeset-presence.mjs", "exit": 0, "verdict": "green", "raw": "1 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s) ... Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate."},
 {"name": "node scripts/check-changeset-no-major.mjs", "exit": 0, "verdict": "green", "raw": "No changeset declares a `major` bump."},
 {"name": "node scripts/check-changeset-overwrite.mjs", "exit": 0, "verdict": "green", "raw": "1 changeset(s) added, 0 modified, 0 deleted. No pre-existing changeset was modified or deleted."},
 {"name": "node scripts/check-changeset-fixed.mjs", "exit": 0, "verdict": "green", "raw": "All workspace packages are in the changeset fixed group."},
 {"name": "pnpm check:control-bytes", "exit": 0, "verdict": "green", "raw": "check-control-bytes: OK (scanned 5893 tracked text file(s); skipped 85 binary)."},
 {"name": "pnpm check:doc-fences", "exit": 0, "verdict": "green", "raw": "every TypeScript block in 224 document(s) is fenced ts/tsx/typescript ..."},
 {"name": "pnpm exec eslint packages/app-shell/.../block-types.ts (plain form)", "exit": 0, "verdict": "green", "raw": "1 problem (0 errors, 1 warning) — the warning is 'Bot' unused at line 33, PRE-EXISTING: present in origin/main's copy, and my diff touches only line 151"},
 {"name": "pnpm lint (FULL farm, plain form, not narrowed)", "exit": 0, "verdict": "green", "raw": "Tasks: 47 successful, 47 total; 3m14s; all reported problems are warnings (0 errors) and are the pre-existing baseline"},
 {"name": "pnpm --filter @object-ui/app-shell run type-check (FIRST attempt, before closure build)", "exit": 2, "verdict": "NOT_MEASURED", "raw": "TS2307: Cannot find module '@object-ui/components' / '@object-ui/react' / '@object-ui/fields' / '@object-ui/data-objectstack' — unbuilt dependency closure. Reported verbatim as NOT MEASURED, NOT as a failure."},
 {"name": "pnpm --workspace-concurrency=2 --filter '@object-ui/app-shell^...' build", "exit": 0, "verdict": "green", "raw": "closure build succeeded (flag placed BEFORE --filter; '^...' prefix-suffix form = upstream deps)"},
 {"name": "pnpm --filter @object-ui/app-shell run type-check (RE-RUN on built closure)", "exit": 0, "verdict": "green", "raw": "TYPECHECK_EXIT=0, TS2307 remaining = 0; runs BOTH passes: `tsc --noEmit && tsc -p tsconfig.test.json`"}
 ],
 "tests": "All gates above ran on ab85b515e with a clean working tree (0 modified); the final suite run printed SHA_OF_THIS_RUN=ab85b515e from inside that run. Exit codes captured by redirecting to a file FIRST, never read across a pipe. The shared verify lock printed 'batch-last-exit' (explicitly NOT a whole-command verdict) on the two-leg ablation run, so I read each leg's own SUITE_EXIT, not that 0. REVERSE VERIFICATION, directions predicted before running: Leg A predicted RED, got RED — shortening the reason to a 7-char marker failed block-config.test.ts with \"'app:launcher' needs a reason: expected 7 to be greater than 10\", proving the suite reads the edited file, so the green is a measurement and not a vacuous pass. Leg B predicted GREEN, got GREEN — see the truthfulness field. Each leg confirmed its mutation ON DISK (injected-text count 1, removed-anchor count 0, blob hash moved off the HEAD blob) before measuring, and verified its restore by blob-hash match against the HEAD blob plus an empty `git diff HEAD`; an EARLIER leg self-aborted with 'FAILURE: mutation did NOT land' because grep -c counts LINES and the single-char marker 'x' matched 66 of them — that leg is reported as NOT RUN rather than quietly retried. Typecheck population proof: tsc --listFiles lists 2421 files and previews/block-types.ts is among them (1 hit), so the green covers the edited file.",
 "controls_used": "Every zero below carries a control that MUST hit in the SAME query. (1) nav:menu inside exclusion range 149-204: 0 hits, control app:launcher = 1 hit, same sed range + grep. (2) public-blocks.ts shell-singleton sweep: app:launcher/nav:menu/global:notifications/user:profile all 0, controls record:chatter = 1 and element:text_input = 1, same loop. (3) literal old-string pin sweep repo-wide: exactly 1 hit (the definition site, so no test pins the literal), control 'shell singleton' hit 3 files. (4) app-shell registers neither ai:chat_window nor element:form (0 hits) — this is what makes the #7117 gap latent rather than live. (5) dedupe search before filing #7117: control #7092 AND #6071 both returned, so the absence of a prior import-set issue is a real reading. (6) anti-vacuity: the truthfulness test's own registry-populated guard passed, so its negative assertions are not vacuous. (7) no-re-export check: 0 hits for 'block-types' in app-shell src exports, control = export statements do exist in the previews dir.",
 "assumptions_falsified": [
 "PM ZONE 1 sha citation is WRONG, substance is RIGHT. The ruling cites PR #7091 as 'merged 48d1beee1, 2026-08-31T20:38:36Z'. 48d1beee1 is NOT a valid object in this repo ('unknown revision'); on main #7091 landed as squash commit 969ba84f4, author+commit date 2026-08-31T18:09:49Z. Most likely the pre-squash PR head sha. Verified the premise BY CONTENT instead (platform-readings: read origin/main by content, not by sha ancestry): 969ba84f4 adds app-launcher-renderer.tsx and nav-menu-renderer.tsx and registers both in app-shell/src/index.ts. The card is ripe; nothing about the work changes.",
 "PM ZONE 2 assumption 3 (changeset) is FALSIFIED IN DIRECTION: a `patch` is NOT what is owed — an EMPTY-frontmatter changeset is. Direct precedent .changeset/palette-exclusion-reason-truthfulness.md, #6071's own changeset on this same ledger, uses empty frontmatter with the rationale 'the reason strings are developer-facing ledger prose, read by no runtime code path'. Independently measured: PALETTE_EXCLUSIONS is not exported from @object-ui/app-shell's entry (package exposes only '.' and './styles.css'), nothing re-exports block-types anywhere in app-shell src, and no runtime path reads the reason. check-changeset-presence.mjs then certified the route explicitly.",
 "PM ZONE 2 assumption 1 (app:launcher is the only falsified entry) CONFIRMED, with the sweep and controls recorded above.",
 "PM ZONE 2 assumption 2 (truthfulness test stays green) CONFIRMED by reading the test, not assumed — and strengthened: leg B showed it would ALSO stay green on a genuinely false claim, which is the separate #7117 gap.",
 "PM ZONE 2 assumption 4 (no test needed) CONFIRMED; I built no new test. See open_questions for the pin proposal and its cost."
 ],
 "out_of_scope_findings": [
 "filed as #7117: exclusion-reason-truthfulness's import set excludes app-shell, so a false 'no renderer' on any of the five shell singletons passes green — measured, latent today, labelled `finding` + `domain:ui`, no assignee, not fixed here"
 ],
 "mcp_calls": "5 — 1 search_issues (dedupe for #7117), 1 issue_write create (#7117), 1 issue_write update (fixing a PR-number reference), 1 create_pull_request (#7119), 1 add_issue_comment (this report). All issue/PR/comment READS went through the zero-quota public-repo payload channel and git; the repo-scoped REST probe returned 403 'GitHub access is not enabled for this session', so the MCP fallback rung was used for writes and the one dedupe search.",
 "open_questions": [
 {
 "question": "Should a pin be added so this clause cannot rot again? I did NOT build one.",
 "options": [
 "A. No new pin. The reword removes the renderer-dependence that made the clause rottable at all: the new text, like the sibling global:notifications, describes WHERE the block lives, so no future renderer can falsify it. Cost: zero. Residual risk: a future author reintroduces a rendering claim by hand.",
 "B. Extend the existing truthfulness guard to also refuse reasons ASSERTING a renderer status that is false in the other direction, and widen its import set to cover app-shell. Cost: this is #7117's repair, materially larger than this card, and it needs one positive probe per new import or it guards vacuously.",
 "C. A literal string pin on this one entry. Cost: near-zero to write, but it pins TEXT rather than the property, so it fails on any innocent rewording and teaches nothing — the anti-pattern #6071's header argues against."
 ],
 "recommendation": "A for this card, and let #7117 carry B on its own merits. Real business need: no user is served by a third guard over developer-facing prose. Long-term soundness: the durable fix is wording that cannot rot, which is exactly what shipped, not another gate over the same string. AI-authorability: B genuinely helps (declared = enforced over the ledger AI agents read as the decision record) but belongs where its cost can be judged. Startup scope discipline: adding a pin inside a one-line reword card is the scope growth the dispatch named as the win condition to avoid."
 },
 {
 "question": "Whether app:launcher should become palette-authorable remains OPEN and untouched, as ruled.",
 "options": ["Not adjudicated here by construction — the entry, its key and its position are unchanged."],
 "recommendation": "Leave to the maintainer; #7091 registering a renderer is deliberately not an answer to it, per that PR's own docblock."
 }
 ]
}

---

Generated by Claude Code