Flip duly_duty.source and duly_task.source defaults from catalog to self

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code

[os-warren]

Fixes#50
Fixes#55

What

duly_duty.source and duly_task.source — the two caliber columns — both
declared catalog as the default option, so a hand-created record (no
source supplied) was born into the governed, scoreable set. That is the
exact inverse of the invariant source exists to serve: self-declared work
is surfaced, never scored. On the duty side it also exposed a hand-authored
duty to duly_catalog_sync, which rewrites cadence fields on anything whose
source is 'catalog'.

Moves default: true from the catalog option to the self option on both
duly_duty.source (src/objects/duty.object.ts, #50) and duly_task.source
(src/objects/task.object.ts, #55 — extended into this PR by PM call: the
task-side field is unowned this round, and splitting a one-line sibling-field
fix across two rounds was judged worse than the file-surface discipline was
worth). duly_catalog_item is untouched — a catalog item is the
organisation's declaration by construction.

Why this is safe — duty side (#50)

Every path that legitimately produces a governed duly_duty already stamps
source explicitly:

• duly_catalog_apply writes source: 'catalog' — confirmed unchanged at
  src/actions/catalog.handlers.ts:324, and pinned by
  test/catalog-instantiate.test.ts ("copies the catalog item's content and
  cadence onto the duty").
• The assignment fan-out (src/flows/assignment.flow.ts) writes
  source: 'assigned' — but on duly_task, not duly_duty (it never
  creates a duly_duty row at all; objectName: 'duly_task' at both
  create_record nodes). It is therefore orthogonal to this field's default.
  Confirmed unchanged by test/assignment-fanout.test.ts. Noting this
  because the issue and adjudication comment both describe the fan-out as a
  duty producer — it isn't; it produces tasks directly. Doesn't change the
  fix, but the premise as stated is imprecise (acknowledged on A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

So the duty-side default was only ever reachable by a hand-created
duly_duty, which is by definition self-declared.

Why this is safe — task side (#55), verified rather than copied

The producer set is different on duly_task, so each was re-checked rather
than assumed:

• The dispatcher (src/jobs/dispatch.plan.ts, dispatch.job.ts) copies
  duty.source onto every dispatched task explicitly —
  source: duty.source ?? '' is always present in the TaskDraft, never
  omitted from the insert. Confirmed unchanged; still relies on nothing from
  the field default.
• The assignment fan-out writes source: 'assigned' directly on both
  create_record nodes in assignment.flow.ts. Re-confirmed unchanged after
  the task-side edit.
• The actual gap the default governs: duly_member's permission grant
  on duly_task is allowCreate: true (src/security/permission-sets.ts),
  and src/views/task.view.ts defines no create form that stamps source.
  A member hand-creating their own task falls through to the field default —
  which is exactly the self-declared case this fix protects. No producer was
  found riding on the old default; the finding is the create-path gap itself,
  now closed by the same mechanism as A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50.

Checked and found clean

• docs/product/data-model.md's caliber paragraph — describes catalog/
  assigned as governed and self as surfaced-never-scored, but never
  states which is the default. No edit needed.
• The seed (Demo seed data — the product working on first boot #7) — not yet landed (no seed files exist outside
  node_modules). Nothing to fix.
• src/views/duty.view.ts — puts source on the form as a plain field with
  no override either way; out of file surface, unaffected by the fix.

Tests

test/invariants.test.ts carries one generalized test — a hand-created record is self-declared, not born governed (#50, #55) — looping over both
duly_duty and duly_task rather than duplicating the block per object, so
a third caliber-bearing object landing with the wrong default fails the same
assertion. Each iteration asserts exactly one source option carries
default: true, that its value is 'self', and that neither catalog nor
assigned does.

Ablation (both halves, same script shape)

For each object: committed the fix first, moved default: true back onto
catalog on disk, confirmed the mutation landed via grep/git diff --stat
before measuring, ran test/invariants.test.ts and got the expected red
naming that object (AssertionError: <object>.source: expected 'catalog' to be 'self'), then restored via a trap ... EXIT INT TERM from the committed
state. Verified git status --short / git diff --stat empty after each
restore, and the full suite green again both times.

Gates (all green on 1123013, final head)

pnpm validate # ✓ Validation passed
pnpm typecheck # ✓ (tsc --noEmit, no output)
pnpm test # ✓ 12 files, 371 tests passed
pnpm build # ✓ Build complete, dist/objectstack.json written

File surface

src/objects/duty.object.ts, src/objects/task.object.ts (PM-extended,
unowned this round — no collision with #46/#51/#27), test/invariants.test.ts.
Nothing in objectstack.config.ts or AGENTS.md touched.

---

Generated by Claude Code