You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Found while implementing catalog instantiation (#5). Reported rather than redesigned around, because which way this goes is a product call.
What was measured
duly_catalog_apply and duly_catalog_sync are global actions — neither operates on a record, so neither declares an objectName. In @objectstack/spec@17.2.0 that means they have no place to surface in the UI:
global_nav was removed from ACTION_LOCATIONS in spec 17 (#6888, ADR-0049 enforce-or-remove). The console's ⌘K palette composes its groups from nav items, objects, dashboards, pages, reports and record search — it reads no action metadata, so the location never rendered anything.
Every surviving location is object-bound: list_toolbar, list_item, record_header, record_more, record_related, record_section.
The spec's own prescription for this case is locations: [] (headless), which is what both actions declare. They keep their param contract, capability gate and audit trail, and they are invoked over the platform action route:
POST /api/v1/actions/global/duly_catalog_apply
{ "position_code": "plant_compliance_officer", "users": ["u1","u2","u3"] }
...or over MCP. There is no button.
Why it is worth a decision
#5 opens by calling this "the onboarding path, and the single biggest adoption risk in the product" — the thing that has to be easy or the rollout dies in week one. An admin who has just imported their catalog currently cannot click anything to apply it; they need an API client, or the MCP surface (#21).
B. Also attach an object-bound twin to duly_catalog_item with objectName: 'duly_catalog_item' and locations: ['list_toolbar'] — a real button on the Role catalog list view, which is exactly where an admin is standing when they want it. Costs a second declaration whose handler can be the same function.
C. A page (src/pages/) that collects the inputs and calls the action. Most control over the onboarding experience, most work.
D. ai: { exposed: true, requiresConfirmation: true, description: … } so the MCP/agent surface can drive it conversationally. Deliberately not done in Catalog instantiation — apply a position's duty catalog to a person #5: nothing needs it for reachability (the REST route works without it), and arming an agent to bulk-create duties for arbitrary users is a decision to take deliberately rather than as a side effect.
Filing unassigned for triage. B is the cheapest thing that gives the onboarding flow a button, and it does not invalidate A.
Found while implementing catalog instantiation (#5). Reported rather than redesigned around, because which way this goes is a product call.
What was measured
duly_catalog_applyandduly_catalog_syncare global actions — neither operates on a record, so neither declares anobjectName. In@objectstack/spec@17.2.0that means they have no place to surface in the UI:global_navwas removed fromACTION_LOCATIONSin spec 17 (#6888, ADR-0049 enforce-or-remove). The console's⌘Kpalette composes its groups from nav items, objects, dashboards, pages, reports and record search — it reads no action metadata, so the location never rendered anything.list_toolbar,list_item,record_header,record_more,record_related,record_section.The spec's own prescription for this case is
locations: [](headless), which is what both actions declare. They keep their param contract, capability gate and audit trail, and they are invoked over the platform action route:...or over MCP. There is no button.
Why it is worth a decision
#5 opens by calling this "the onboarding path, and the single biggest adoption risk in the product" — the thing that has to be easy or the rollout dies in week one. An admin who has just imported their catalog currently cannot click anything to apply it; they need an API client, or the MCP surface (#21).
Options
duly_catalog_itemwithobjectName: 'duly_catalog_item'andlocations: ['list_toolbar']— a real button on the Role catalog list view, which is exactly where an admin is standing when they want it. Costs a second declaration whose handler can be the same function.src/pages/) that collects the inputs and calls the action. Most control over the onboarding experience, most work.ai: { exposed: true, requiresConfirmation: true, description: … }so the MCP/agent surface can drive it conversationally. Deliberately not done in Catalog instantiation — apply a position's duty catalog to a person #5: nothing needs it for reachability (the REST route works without it), and arming an agent to bulk-create duties for arbitrary users is a decision to take deliberately rather than as a side effect.Filing unassigned for triage. B is the cheapest thing that gives the onboarding flow a button, and it does not invalidate A.