Seed the demo: the product working on first boot

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Fixes#7

pnpm dev on an empty database now opens on a system that is obviously working: a three-level business-unit tree, thirteen people, a twenty-item role catalog across three position codes, thirty-one duties and 186 tasks covering six months of history plus everything currently in flight. 459 rows, errored: 0.

The two decisions worth reviewing

History comes out of the dispatcher's own planner, not a second period walk.demo-history.ts calls planDispatch twice — once with a six-month backfill window, once as today's scheduled run — and unions the drafts on (duty, owner, period_key). The card's hardest rule (period keys must come from the engine, never hand-typed) is then satisfied structurally rather than by discipline, and two invariants fall out of the shape instead of being asserted on top of it:

• Standing duties hold zero tasks because planForDuty refuses them by form before it reads anything else. SKIPS is exported so the test asserts the mechanism, not just that no such row happens to exist.
• Paused duties hold zero tasks the same way (not_active).

The seeded rows are literally what the dispatcher would have produced — same keys, same due dates, same lead windows — so a real dispatch run over these duties reproduces them and the unique index absorbs it.

Four task datasets, and the last two are the half that fails silently. Per #32 / #64: completed_at rides along on a system-context insert, last_update_at cannot — beforeInsert stamps it unconditionally and lifecycle hooks run on the seed path. It takes a second pass in mode: 'update' carrying only that column. Skip it and every row reads as touched at boot: "Not moving" is empty, and the seed reports complete success.

The two insert datasets use different external ids, deliberately: dispatched rows are keyed (duty, owner, period_key) — the dispatch identity itself — because a subject repeats across every period of its duty; assignment fan-out rows are keyed (subject, owner) because they have no period_key at all, and a composite containing a blank collapses to an empty key that matches nothing and re-inserts on every boot.

What the screens show

Measured through the running app's REST API as the logged-in dev admin, not inferred from the fixture:

Screen	Shows
My week	5 — two monthlies, a quarterly in progress, the half-year audit, one self-declared
Late	4 — past due, still open, across four people and three units
Not moving	3 — and 2 of them are not yet due, which is the product's whole argument
Board	5 populated columns: 151 done · 27 open · 6 in progress · 1 skipped · 1 cancelled
Schedule (gantt)	186 bars, every row has both visible_from and due_date
Calendar	186
Role catalog	20 items, 3 position codes, 19 citing a clause
By business unit	86 / 61 / 31 / 7 / 1 — five units, all different
Manager dashboard (#67)	open 29 · >7d 6 · >14d 3 · >30d 2 (properly nested), unit bar chart, 27 tasks in the forward workload window
Assignments → Sent by me	1
Work log	8 of 15, mostly private

Every {current_user_id} view is scoped to Dev Admin, the account objectstack dev logs you in as — a demo whose data belongs entirely to twelve other people renders four screens blank. That row is seeded carrying its natural key and nothing else, so on a real boot the loader's no-op-replay check skips it rather than updating a live credential-bearing account. Verified: email and sys_account untouched, 13 users not 14.

⚠️ One thing to know before you boot — objectstack#14157

On a genuinely fresh.objectstack/data, this app now has no loginable account. plugin-auth seeds the dev admin only on a zero-user DB and does it on kernel:ready, which fires after the app seed — so thirteen seeded people pre-empt it, permanently. sign-in 401s and bootstrap-status says hasOwner: true, so the console offers no first-admin flow either.

It is a platform gate that asks the wrong question (any sys_user row, rather than any credential-bearing account) and it is not fixable from src/data/. Filed upstream as objectstack-ai/objectstack#14157 with both measurements, and tracked here as #73. If you have run pnpm dev in a worktree before, the admin is already there and everything just works — that is the path this was verified on, end to end.

Verification

All four gates green at e671ea1, run after the final commit: pnpm validate exit 0 (one expected warning — the hierarchy-security provider, which AGENTS.md documents as this repo's expected state) · pnpm typecheck exit 0 · pnpm test exit 0, Test Files 20 passed (20) / Tests 536 passed (536) · pnpm build exit 0, Artifact: dist/objectstack.json (276.0 KB).

test/seed.test.ts (25 tests) boots a real kernel with skipSeedData: false and reads the rows back from the database — the failures this card exists to prevent (an owner natural key that resolved to nothing, a stripped completed_at, a last_update_at overwritten at boot) all report success on the fixture side.

Ablation. Removed both mode: 'update' datasets from the barrel; predicted the stagnation assertions go red and nothing else. Confirmed on disk before running by the injected marker plus git diff --stat (1 insertion, 2 deletions), restored by a trap … EXIT INT TERM with the restore verified as an empty git diff HEAD. Observed exactly the prediction: Tests 3 failed | 22 passed (25) — "Not moving has 2-3 rows", "stagnation is NOT lateness", and "the replay leaves the stalled rows stalled". The other 22 stayed green, which is the point: without that pass the seed still loads perfectly and only the product's headline signal goes quiet.

Idempotence is exercised through the platform's own loader with the boot's own config, asserting totalInserted === 0andtotalRecords === every declared row, so "inserted nothing" cannot be an empty run.

Also filed

• maybeSeedDevAdmin gates on "any sys_user row", but runs at kernel:ready — so any app that seeds people permanently loses the objectstack dev login objectstack#14157 — the dev-admin gate, above.
• A clean git clone && pnpm dev has no loginable account — make the demo seed opt-in, default off #73 — the duly-side decision: wait for the platform fix, or document the two-step boot.
• The seed writes sys_user.primary_business_unit_id directly and leaves sys_business_unit_member empty — the platform owns that column and recomputes it #74 (finding) — the seed writes sys_user.primary_business_unit_id directly, which the platform documents as a projection of sys_business_unit_member. It lands and survives a real boot, but a future recompute would blank it.

Scope

src/data/** and test/seed.test.ts only. No change to objectstack.config.ts, src/objects/, src/hooks/, src/jobs/, src/dashboards/, src/flows/ or AGENTS.md. Rebased twice mid-flight, onto #66 (cadence fields are now form-scoped — the two standing catalog items carry none of the five) and onto #72 (record_change is bound now; a seeded assignment still does not fan out, because the loader's own skipTriggers exempts it, which is a better reason and a stable one).

No real company, person or regulation is named anywhere: the domain is under RFC 2606's reserved .example, and every citation is an invented internal policy number. Nothing in the seed ranks or compares item counts between people.

Generated by Claude Code

---

Generated by Claude Code