Catalog instantiation — apply and sync a position's duty catalog by os-warren · Pull Request #34 · objectstack-ai/duly

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

os-warren · 2026-09-01T03:57:43Z

Fixes#5

Adds the onboarding path: apply a position's duty catalog to people, and replay catalog cadence edits onto the duties it produced.

What landed

duly_catalog_apply — for each active duly_catalog_item with the given position_code, create a duly_duty for each selected user. Content and cadence come from the item; owner from the selection; business_unit from the person's sys_user_position.business_unit_id; source: 'catalog', catalog_item, status: 'active'.

Idempotent on (catalog_item, owner) — one probe for the whole run, plus a same-run guard so two identical items cannot both land on one person. A second apply creates nothing and reports the skips.

duly_catalog_sync — replays cadence only: frequency, due_anchor, due_offset_days, lead_days, grace_days. owner, status, timezone and the effective_* window are never written, because the patch is built from that five-field tuple rather than by diffing records. A duty whose source is 'self' is never touched. A duty whose catalog item has been deactivated is reported, never deleted. position_code is an optional narrowing — syncing rewrites authored cadence, so being able to run it for one position instead of the whole org is the difference between a correction and an incident.

Both return a per-row summary; sync records from/to per field, because it is destructive to authored cadence and has to be legible after the fact.

Handler wiring — asserted, because nothing else can

registerCatalogActionHandlers(ql) is called inside the existing registerDulyActionHandlers; the function's shape is untouched so #4 can add its call beside it. objectstack.config.ts is not touched.

An action whose handler is not registered renders, is clickable, and 404s at call time, and pnpm validate cannot see it. Reverse-verified: with the registration call commented out, pnpm validate still exits 0 (✓ Validation passed) while pnpm test exits 1 on × every declared action has a registered handler. Restored byte-identically (clean git status).

The source !== 'catalog' guard in sync is re-applied in code, not left to the where clause — a product invariant that lives only in a query is one lenient driver away from being untrue. Reverse-verified: removing the in-code guard reds × the source guard is in the code, not only in the query filter and nothing else, which is the point — the other self-duty test stays green because the query filter alone still looks correct there.

Three things measured against the platform, two of which change the picture

sys_user_position.business_unit_id is real — a nullable lookup to sys_business_unit, defined in @objectstack/plugin-security (not platform-objects). Used as declared. A person with no position row, or an unanchored one, gets a duty with no business unit rather than a null one: position_code is free text so a customer can load their catalog before positions are modelled, which makes "no sys_user_position row" a normal day-one state that must not fail the apply.

A duty's timezone has nothing to read it from → filed as #26. sys_user declares no timezone or locale field, and ExecutionContext.timezone (the resolved tenant zone) is not propagated into an action handler's context — buildSession() carries userId/organizationId/positions/roles and no zone. So the ladder resolves to UTC. resolveDutyTimezone() is a named function with the ladder written out, deliberately not a ctx.user.timezone ?? … chain: that would be a tolerant consumer standing in for a producer that does not exist. Pinned against duly_duty.timezone's own defaultValue so the two cannot drift. This changes what #20's deployment docs have to say.

A global action has no UI home in protocol 17 → filed as #27. global_nav was retired from ACTION_LOCATIONS in spec 17 (#6888) and every surviving location is object-bound, so an object-less action's honest declaration is locations: [] (headless), invoked over POST /api/v1/actions/global/duly_catalog_apply or MCP. There is no button. Reported rather than redesigned around; #27 lays out the options.

The PM's assumption that a global action can take a position_code plus a multi-user picker holds — confirmed in the built artifact: {name: position_code, type: text, required: true} and {name: users, type: user, required: true, multiple: true}.

Also filed

Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 (sub-issue of Security model — positions, permission sets, sharing rules #8) — both actions are ungated; requiredPermissions needs the duly_admin capability Security model — positions, permission sets, sharing rules #8 creates. ctx.engine is the trusted, RLS-bypassing facade, so the invoke-time gate is the only boundary.
A factual note on duly_duty.timezone accepts any string — a typo'd IANA zone validates clean and fails at dispatch #24 — duly_catalog_item carries no timezone field, so that validation has one home, not two.

Gates

All four green on 13feae8, the commit this PR points at:

pnpm validate ✓ Validation passed (UI: 2 Actions)
pnpm typecheck tsc --noEmit, no output
pnpm test Test Files 2 passed | Tests 36 passed (36)
pnpm build ✓ Build complete (dist/objectstack.json, 53.5 KB)

No changeset — this repo has none.

Generated by Claude Code

Adds two object-less actions and their handlers: - duly_catalog_apply — instantiate every active duly_catalog_item for a position onto one or more people. Idempotent on (catalog_item, owner): a second apply creates nothing and reports the skips. - duly_catalog_sync — replay catalog CADENCE edits (frequency, due_anchor, due_offset_days, lead_days, grace_days) onto derived duties. Never touches owner, status, timezone or the effective_* window; never touches a duty whose source is 'self'; reports duties from deactivated catalog items rather than deleting them. The handler↔declaration wiring is asserted in tests because no author-time gate covers it: an unregistered handler renders, is clickable, and 404s at call time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

The separator itself is right: a NUL cannot occur in a record id, so the composite key cannot collide the way plain concatenation can - ('ab','c') and ('a','bc') would otherwise produce the same key and silently skip a duty that was never created. Encoding it as a literal 0x00 in the source was the defect. It made git treat catalog.handlers.ts as binary (Bin 0 -> 17555 bytes, no diff, no blame, no review for the life of the file), left the separator invisible in an editor, and would be dropped silently on copy-paste - degrading the key back to plain concatenation with no error. Now written as the \u0000 escape, so the file stays ASCII while the runtime value is unchanged. pairKey is exported and the collision property is pinned in tests, since the reason for the separator is not obvious and would otherwise be "simplified" away. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback.

* Flip duly_duty.source default from catalog to self (#50) A hand-created duty was born into the governed, scoreable set because the source select's default option was 'catalog'. Every path that legitimately produces a governed duty already stamps source explicitly (duly_catalog_apply writes 'catalog' per #34; the assignment fan-out writes 'assigned' on duly_task per #33), so the field default was only ever reached by a hand-created duty, which is by definition self-declared. Moves default: true from the catalog option to the self option on duly_duty.source. Adds a test pinning the direction next to the existing invariant tests: the default is self, and both governed values (catalog, assigned) are reachable only by explicit assignment, never as a fallback. * Flip duly_task.source default from catalog to self (#55) Same defaulting bug as #50, on the sibling caliber column. Verified before changing rather than copying: both manufactured producers already stamp source explicitly and do not rely on the field default -- the dispatcher copies duty.source onto every dispatched task (dispatch.plan.ts), and the assignment fan-out writes 'assigned' directly on both create_record nodes (assignment.flow.ts). The path that actually reaches the default is duly_member's allowCreate: true on duly_task with no create form stamping source -- a member hand-creating their own task, which is self-declared by definition. Generalizes the #50 pinning test in test/invariants.test.ts to assert the caliber-defaults-to-self property on both duly_duty and duly_task instead of duplicating the block, per PM extension of #50's file surface to include this sibling field.

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

claude added 2 commits September 1, 2026 03:52

os-warren mentioned this pull request Sep 1, 2026
Catalog instantiation — apply a position's duty catalog to a person #5
Closed

os-warren marked this pull request as ready for review September 1, 2026 04:10

os-warren merged commit a4540ae into mainSep 1, 2026
1 check passed

os-warren mentioned this pull request Sep 1, 2026
A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50
Closed

Uh oh!

Conversation

os-warren commented Sep 1, 2026

What landed

Handler wiring — asserted, because nothing else can

Three things measured against the platform, two of which change the picture

Also filed

Gates

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

os-warren commented Sep 1, 2026

What landed

Handler wiring — asserted, because nothing else can

Three things measured against the platform, two of which change the picture

Also filed

Gates

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

os-warren commented Sep 1, 2026

What landed

Handler wiring — asserted, because nothing else can

Three things measured against the platform, two of which change the picture

Also filed

Gates

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

os-warren commented Sep 1, 2026

What landed

Handler wiring — asserted, because nothing else can

Three things measured against the platform, two of which change the picture

Also filed

Gates

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

os-warren commented Sep 1, 2026

What landed

Handler wiring — asserted, because nothing else can

Three things measured against the platform, two of which change the picture

Also filed

Gates