Product discovery from an internal demo production run (video-studio #151), recorded here unassigned per repo convention — not claiming, not proposing a specific fix.
Observed (HotCRM carrier app, dev server, 2026-08-29): a custom React page created and published through the metadata API renders correctly at its direct URL, but:
- it appears in no navigation group — all 26 app navigation links were scanned with every group expanded;
- the command palette search cannot find it (searching by page name returns nothing);
- the only way to reach it is a direct link.
Root cause established (code-level evidence, 2026-08-29 follow-up) — an agent cannot register the nav entry itself, even if asked to:
GET /api/v1/meta/types — the app type carries allowRuntimeCreate=true, allowOrgOverride=false, supportsOverlay=true.GET /api/v1/meta/app/crm_enterprise — this app's packageId is app.objectstack.hotcrm, i.e. a code package.- Overlay writes are gated on
OVERLAY_ALLOWED_TYPES = types whose allowOrgOverride is true — app is not among them. - Platform's own refusal text:
[not_overridable] … is provided by a code package and the type has not opted into per-org overlay writes (allowOrgOverride=false). Edit the source artifact and redeploy, or set OS_METADATA_WRITABLE … - Second gate behind it:
namedBase && !isWritablePackage(engine, packageId) → readOnlyBaseOverrideError.
So app can be created at runtime but its code-package instance cannot be overlaid. HotCRM's navigation lives in src/apps/crm.app.ts (code package), so the only sanctioned path is "edit source and redeploy". The nearest runtime-only approximation is for the agent to create its own app and put the page in that app's navigation ({id, type:'page', pageName, label, icon} is a valid shape; nav_account_workbench is an existing example) — but that is a different application in the launcher, not an entry in the CRM the team already uses.
Why it matters: in the "AI builds a page into your running app" flow, the page an agent publishes is unreachable for end users, and the agent has no in-protocol way to fix that. Either publishing should be able to register a nav entry for the target app, or published pages should at least be findable in palette search.
⚠ Evidence level, stated honestly: the above is code-level (platform decision functions and verbatim refusal text). A live confirmation — one ?mode=draft overlay write against crm_enterprise, which would prove the refusal without taking effect — was blocked by the session permission gate and not worked around, so there is no live receipt.
Related but distinct: #3371 covered palette record-search hits; this is about published pages being undiscoverable and un-registerable.
Product discovery from an internal demo production run (video-studio #151), recorded here unassigned per repo convention — not claiming, not proposing a specific fix.
Observed (HotCRM carrier app, dev server, 2026-08-29): a custom React page created and published through the metadata API renders correctly at its direct URL, but:
Root cause established (code-level evidence, 2026-08-29 follow-up) — an agent cannot register the nav entry itself, even if asked to:
GET /api/v1/meta/types— theapptype carriesallowRuntimeCreate=true,allowOrgOverride=false,supportsOverlay=true.GET /api/v1/meta/app/crm_enterprise— this app'spackageIdisapp.objectstack.hotcrm, i.e. a code package.OVERLAY_ALLOWED_TYPES= types whoseallowOrgOverrideis true —appis not among them.[not_overridable] … is provided by a code package and the type has not opted into per-org overlay writes (allowOrgOverride=false). Edit the source artifact and redeploy, or set OS_METADATA_WRITABLE …namedBase && !isWritablePackage(engine, packageId)→readOnlyBaseOverrideError.So
appcan be created at runtime but its code-package instance cannot be overlaid. HotCRM's navigation lives insrc/apps/crm.app.ts(code package), so the only sanctioned path is "edit source and redeploy". The nearest runtime-only approximation is for the agent to create its own app and put the page in that app'snavigation({id, type:'page', pageName, label, icon}is a valid shape;nav_account_workbenchis an existing example) — but that is a different application in the launcher, not an entry in the CRM the team already uses.Why it matters: in the "AI builds a page into your running app" flow, the page an agent publishes is unreachable for end users, and the agent has no in-protocol way to fix that. Either publishing should be able to register a nav entry for the target app, or published pages should at least be findable in palette search.
⚠ Evidence level, stated honestly: the above is code-level (platform decision functions and verbatim refusal text). A live confirmation — one
?mode=draftoverlay write againstcrm_enterprise, which would prove the refusal without taking effect — was blocked by the session permission gate and not worked around, so there is no live receipt.Related but distinct: #3371 covered palette record-search hits; this is about published pages being undiscoverable and un-registerable.