Filed unlabelled by the domain:ui execution seat @ objectui (session session_012wwHa4aaFybxXrfmfHioDM). Routing, domain:*, type and grading are triage's to produce — this seat does not apply them. Suggested routing at the bottom.
What is needed
One ruling. No code, no measurement — the measurement is already done and is reproduced below.
objectui#7135 records that user:profile is the one palette shell singleton with no renderer anywhere. Its own body ends by saying a claimant must settle this before building:
A claimant should establish which of the two answers is wanted before building either — ideally by asking on objectstack#12183, which is the thread that already holds the ruling for its four siblings.
This card is that ask. #12183 is closed completed (3/3 sub-issues), so it cannot itself carry a new ruling — hence a fresh card rather than a comment on a closed thread.
The question, precisely
objectstack#12183's own Ask offered two acceptable answers for the four members it covered. Both are still open for this fifth member:
A. Implement the renderer — as #6757 did for global:search + global:notifications, and #7091 for app:launcher + nav:menu.
B. Make it explicit in the spec and in validate that this type is not author-placeable, so the failure lands at author time rather than in front of a user.
⇒ For user:profile: A or B?
The seat notes without arguing for it that B may well be the right answer for a profile widget specifically — a user-profile surface is plausibly shell chrome rather than something a page author places. But that is a product call, not a reading, and this seat will not make it.
Why this is not just "a later phase of #12183"
That was the implementer's hypothesis, and the seat did the lookup that settles it. #12183 never covered user:profile:
- It is titled and scoped to exactly four members:
nav:menu / global:search / global:notifications / app:launcher.
- Its body enumerates the same four in the
ComponentPropsMap excerpt; its reproduction table lists five instances across those four types.
sub_issues_summary reads 3 of 3 completed, 100%.
⇒ user:profile appears nowhere in it. The asymmetry is unplanned, not sequenced — which is why it needs a ruling rather than a queue position.
The measurement (already done — objectui#7117 / PR #7133)
Of the 8 keys in PALETTE_EXCLUSIONS, exactly 3 are shell singletons:
| key |
renderer |
app:launcher |
✅ real, app-shell views/app-launcher-renderer.tsx, eager at module load |
global:notifications |
✅ real, app-shell views/global-notifications-renderer.tsx, eager |
user:profile |
⛔ none anywhere — only the PlaceholderRenderer scaffold, and only under the opt-in registerPlaceholders() (ns protocol-placeholder), which just apps/console calls |
The repo-wide grep for a real registration returned zero with a control in the same query shape that returned many hits, so the zero is a reading, not an instrument failure.
User-visible consequence: an authored page carrying user:profile draws SchemaRenderer's red unknown-type panel in every host except apps/console, which opts into the placeholder scaffold and gets the dashed "Component Placeholder" box instead. That is precisely the symptom objectstack#12183 was filed about.
⛔ What is NOT being asked
Why this seat cannot answer it
Answer B lands in @objectstack/spec and validate — outside the domain:ui seat's dispatch scope, in this repo. So the answer decides not just what is built but which lane builds it, which is why it cannot be resolved inside objectui by picking the half that happens to be reachable.
Waiting state
objectui#7135 is being moved to pm:blocked with Blocked-by: pointing at this issue in the same write, so its queue label stops claiming it is dispatchable and the reverse index returns it automatically when this is answered.
Suggested routing (triage's call, not this seat's)
If the ruling is A, it is a domain:ui implementation card and returns to objectui. If B, it lands in spec + validate and belongs to whichever lane holds that surface. Naming that dependency is the reason this is one card and not two.
Refs: objectstack#12183 (the four-member ruling, 3/3 complete) · objectui#7135 · objectui#6757 · objectui#7091 · objectui#7117 / PR #7133 (the measurement) · objectstack-ai/hotcrm#734.
Filed unlabelled by the
domain:uiexecution seat @ objectui (sessionsession_012wwHa4aaFybxXrfmfHioDM). Routing,domain:*,typeand grading are triage's to produce — this seat does not apply them. Suggested routing at the bottom.What is needed
One ruling. No code, no measurement — the measurement is already done and is reproduced below.
objectui#7135 records that
user:profileis the one palette shell singleton with no renderer anywhere. Its own body ends by saying a claimant must settle this before building:This card is that ask. #12183 is closed
completed(3/3 sub-issues), so it cannot itself carry a new ruling — hence a fresh card rather than a comment on a closed thread.The question, precisely
objectstack#12183's own Ask offered two acceptable answers for the four members it covered. Both are still open for this fifth member:⇒ For
user:profile: A or B?The seat notes without arguing for it that B may well be the right answer for a profile widget specifically — a user-profile surface is plausibly shell chrome rather than something a page author places. But that is a product call, not a reading, and this seat will not make it.
Why this is not just "a later phase of #12183"
That was the implementer's hypothesis, and the seat did the lookup that settles it. #12183 never covered
user:profile:nav:menu/global:search/global:notifications/app:launcher.ComponentPropsMapexcerpt; its reproduction table lists five instances across those four types.sub_issues_summaryreads 3 of 3 completed, 100%.⇒
user:profileappears nowhere in it. The asymmetry is unplanned, not sequenced — which is why it needs a ruling rather than a queue position.The measurement (already done — objectui#7117 / PR #7133)
Of the 8 keys in
PALETTE_EXCLUSIONS, exactly 3 are shell singletons:app:launcherapp-shellviews/app-launcher-renderer.tsx, eager at module loadglobal:notificationsapp-shellviews/global-notifications-renderer.tsx, eageruser:profilePlaceholderRendererscaffold, and only under the opt-inregisterPlaceholders()(nsprotocol-placeholder), which justapps/consolecallsThe repo-wide grep for a real registration returned zero with a control in the same query shape that returned many hits, so the zero is a reading, not an instrument failure.
User-visible consequence: an authored page carrying
user:profiledrawsSchemaRenderer's red unknown-type panel in every host exceptapps/console, which opts into the placeholder scaffold and gets the dashed "Component Placeholder" box instead. That is precisely the symptom objectstack#12183 was filed about.⛔ What is NOT being asked
PALETTE_EXCLUSIONSentry foruser:profileis correct either way and should not be touched — that is a palette decision about authoring ergonomics, independent of whether a renderer exists (objectui#6071,standalone-stack.test.tshand-mirrorsappDefaultPermissionSetNameand calls the copy "the exact CLI wiring" — a conformance claim over a duplicate of the rule #7092, and fix(verify,plugin-security,cli): bootStack honours the app-declared default permission set (#7001) #7091's own docblock all settle this). A ruling of B must not be read as licence to change it.Why this seat cannot answer it
Answer B lands in
@objectstack/specandvalidate— outside thedomain:uiseat's dispatch scope, in this repo. So the answer decides not just what is built but which lane builds it, which is why it cannot be resolved inside objectui by picking the half that happens to be reachable.Waiting state
objectui#7135 is being moved to
pm:blockedwithBlocked-by:pointing at this issue in the same write, so its queue label stops claiming it is dispatchable and the reverse index returns it automatically when this is answered.Suggested routing (triage's call, not this seat's)
If the ruling is A, it is a
domain:uiimplementation card and returns to objectui. If B, it lands in spec +validateand belongs to whichever lane holds that surface. Naming that dependency is the reason this is one card and not two.Refs: objectstack#12183 (the four-member ruling, 3/3 complete) · objectui#7135 · objectui#6757 · objectui#7091 · objectui#7117 / PR #7133 (the measurement) · objectstack-ai/hotcrm#734.