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

[os-warren]

Observation from #7, filed for triage rather than as a defect — the seed works today and nothing refuses the write.

@objectstack/platform-objects declares the column as readonly: true and documents it as derived:

The user's primary business unit — a denormalised projection of sys_business_unit_member.is_primary, maintained by plugin-sharing (ADR-0057 addendum D12). … Do not edit directly; set it via business-unit membership.

#7's org.seed.ts sets it directly, on both sys_user.primary_business_unit_id and sys_user.manager_id (also readonly). Those writes land because the seed loader writes under { isSystem: true }, and they survive a real objectstack dev boot with SharingServicePlugin loaded — measured: all twelve seeded people come back with their unit and manager resolved.

Why it may matter later

The value is a cache of a junction table this app never populates. If plugin-sharing ever recomputes the projection — a membership edit, a backfill, a future version that reconciles on boot — it would recompute it from an empty sys_business_unit_member and blank all twelve. Nothing would error; the demo's unit rollups and any own_and_reports / unit_and_below scope would just quietly go empty.

The durable shape is presumably to seed sys_business_unit_member rows (with is_primary) and let the projection be derived. That was out of #7's stated file surface and its scope, and doing it speculatively would have meant seeding a platform junction whose contract this app has not read — so it is recorded instead.

What would settle it

Whether plugin-sharing recomputes primary_business_unit_id on any path an app can trigger, and if so whether an app seed is expected to write the membership rows rather than the projection. If the answer is "write the membership rows", src/data/org.seed.ts is a small change.

No pm:queue — this is an observation, not a queued fix.

[os-warren]

Tried to settle this from inside the repo and cannot — which is itself the useful part of the answer.

Neither primary_business_unit_id nor business_unit_member appears anywhere in the installed @objectstack/* tree (searched all packages, excluding sourcemaps). The code that would recompute the projection is in the sharing/enterprise package this app deliberately does not install — the same boundary pnpm validate reports on every boot:

⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise (ADR-0057 hierarchy scopes ship in the enterprise edition).

So the risk this card names is real and unobservable from here: the recompute path, if it exists, lives in a package the open-source app never loads, and would first appear in exactly the deployment we cannot test — an enterprise customer, where the hierarchy scopes that depend on the projection are also the ones that actually do something.

That moves this from "read the source and decide" to a contract question only the platform can answer, so I have asked it upstream rather than guessing: objectstack-ai/objectstack#14162.

Keeping this as finding, not queueing it. The seed works today, and src/data/org.seed.ts is a small change if the answer is "write the membership rows". Restart when #14162 is answered.

---

Generated by Claude Code

[os-warren]

Correction to the reference above: the upstream question is objectstack-ai/objectstack#14172, not #14162 — I wrote the number before the issue was created. Restart-when: answered objectstack-ai/objectstack#14172.

---

Generated by Claude Code

[os-warren]

Answered, and it is a real defect — not an open question. My earlier comment on this card was wrong.

I said this "cannot be settled from here" because the recompute path lives in an enterprise package the open-source app does not install. That was wrong. The maintainer pushed back — sys_business_unit is community — and checking properly settles it in the other direction.

Measured, three ways

1. sys_business_unit_member is a community platform object. It is in PLATFORM_OBJECT_NAMES in @objectstack/spec, and the table exists in this app's own database right now:

   tables matching business_unit: ["sys_business_unit", "sys_business_unit_member"]
   sys_business_unit_member rows: 0
   

2. The projection is actively maintained, in the community edition. packages/qa/dogfood/test/primary-bu-projection.dogfood.test.ts in the platform repo boots the showcase stack and asserts primary_business_unit_id is set when a primary member is inserted and follows the primary flag when it moves to another business unit. So the hooks recompute from the junction; the column's "do not edit directly" comment is enforced behaviour.

3. Our seed writes the projection and leaves the junction empty — the 0 above. That is the defect.

Upstream question closed as answered: objectstack-ai/objectstack#14172.

Why it works today and why that is not reassuring

The recompute hooks fire on sys_business_unit_member writes. We have no member rows, so nothing fires, so our directly-written values survive. The app looks correct because the mechanism that would correct it has never been triggered.

Two ways that ends, neither loud:

• Someone writes a membership row — through the console, an import, a later feature, a customer's own setup — and the hook recomputes that user's primary_business_unit_id from the junction. The seeded value is replaced by whatever the junction says, or cleared if the new row is not primary. No error.
• Anything that resolves people through membership rather than through the projection sees nobody in any unit. Sharing rules and hierarchy scopes are the obvious candidates. Our permission sets happen to read the projection today, which is luck, not design.

Scope

1. src/data/org.seed.ts writes sys_business_unit_member rows — one per person, is_primary: true for their primary unit — and stops writing sys_user.primary_business_unit_id directly. Let the platform derive it. Same question for sys_user.manager_id: check whether it is also a maintained projection before deciding, do not assume it matches.
2. A test asserting the derived value, not the written one: seed, then read sys_user.primary_business_unit_id back and assert it matches the member row — so the assertion passes only if the platform's hook actually ran.
3. Seed ordering matters — sys_business_unit and sys_user must both exist before their junction rows. src/data/index.ts already documents the ordering constraint; extend it rather than inventing a second convention.

Note for whoever takes it: { context: { isSystem: true } } is why the direct write landed at all — it exempts the write from the readonly strip. That is the sanctioned path for writing history (completed_at, per AGENTS.md), and it is not a licence to write a column another component owns. Worth a line in AGENTS.md next to the existing seed-writes-history section, so the distinction is recorded rather than re-learned.

Relabelling pm:queue, dropping the Restart-when — nothing is blocking this.

---

Generated by Claude Code

[os-warren]

Claiming this.

• Session: session_01SqkTcrxUFci7nqXdbBSe2p
• Branch: claude/issue-74-business-unit-membership
• Worktree: ../duly-issue-74 off origin/main (75d086f)

Working the three-item scope from the most recent comment (membership rows + derived-value assertion + seed ordering), plus the AGENTS.md line on isSystem being a history-write path and not a licence to write another component's column. Will check sys_user.manager_id against the platform source rather than assuming it matches primary_business_unit_id.

---

Generated by Claude Code

---

Generated by Claude Code