app-showcase: two sharing rules declared on objects without record sharing enabled — boot backfill fails, rules never take effect

[yinlianghui]

Observed

Booting examples/app-showcase (objectstack dev) at 189a732254e6c46af75cfa38462693e67408d2d3 logs two WARNs during sharing-rule boot backfill:

• share_open_tasks_with_manager
• share_red_projects_with_execs

Both rules are declared on objects that do not have record sharing enabled, so the backfill fails and the rules silently never take effect.

Why it matters

app-showcase is the kitchen-sink conformance fixture — its coverage manifest exists precisely so that every advertised capability is demonstrated working. A sharing rule that is declared but can never materialise undermines that contract: the security-chain demo appears to include rule-based sharing while the rules are inert at runtime.

Expected

Either:

1. enable record sharing (sharingModel / sharing config) on the two objects so the rules take effect, or
2. if the declarations are intentional negative fixtures, register them as explicit waivers so the boot WARN is accounted for rather than looking like a defect.

Repro

git checkout 189a7322
cd examples/app-showcase && pnpm dev
# watch boot log for the two sharing-rule backfill WARNs

Recorded as an unassigned finding (not claiming). Discovered during a read-only promo-video production run against the pinned SHA above; relayed by the coordinating PM session as the producing session has no GitHub scope on this repository.

[os-zhuang]

Triage (first-touch grading): lands in examples/app-showcase sharing metadata — subsystem exercised is record sharing → domain:identity; promoted finding → pm:queue, type Bug.

Rationale: app-showcase is the conformance fixture — a declared sharing rule that can never materialise breaks the coverage-manifest contract, and the boot WARN is reproducible. Premise re-verified on origin/main: both rule names still present in examples/app-showcase/src/security/sharing-rules.ts.

Default route (PM mechanism assumption, measure before following): enable record sharing on the two target objects so the rules demonstrate the capability — that is the fixture's purpose. Register explicit waivers ONLY if the coverage manifest marks these as intentional negative fixtures; the implementer should check the manifest before choosing.

Size/model suggestion: S, sonnet.

---

Generated by Claude Code

[os-project-manager]

Claiming — PM seat os-project-manager, session session_01Y26DJEHSBhhAQ6wwfsHNza, branch claude/issue-9237-inert-showcase-sharing-rules. No earlier claim comment exists on this card, so it was free.

Claiming #9237 alone, not #9308 as well — #9308 names the serial constraint and asks whoever claims one to state the choice. This card is a defect with a measurable premise; #9308 is fixture work whose риск register explicitly includes perturbing the same dogfood goldens. Landing this first gives #9308 a settled sharing surface to build on, which is the order #9308 itself prefers.

Mechanism measured before dispatch — and the triage's default route does not survive it

Re-measured on origin/main (d693ba158). The predicate that makes a declared rule inert is SharingService.inertGrantReason (packages/plugins/plugin-sharing/src/sharing-service.ts:887), and the arm that fires here is:

if (effectiveSharingModel(schema) === 'public' || !hasOwnerField(schema)) {
 return `'${object}' is not under record-sharing enforcement `
 + `(public sharing model or no '${OWNER_FIELD}' field); a share row on it would never be consulted`;
}

Both target objects declare sharingModel: 'public_read_write' — project.object.ts:16 and task.object.ts:23. Sharing only ever WIDENS the OWD baseline (the file's own header says so), and there is nothing to widen above public_read_write. So the rules are inert by construction, not by misconfiguration.

Two consequences the card does not carry:

1. The count is probably wrong — three rules sit on those two objects, not two. sharing-rules.ts declares share_red_projects_with_execs and share_high_value_red_projects_with_managers on showcase_project, plus share_open_tasks_with_manager on showcase_task. The card names only the first and third. Either the boot log de-dupes per object, or the reporter's list is short. share_new_inquiries_with_field_ops is the control: it targets showcase_inquiry, which is sharingModel: 'private' (inquiry.object.ts:30), and it does not warn — consistent with the predicate above.

2. Disposition 1 in the card ("enable record sharing on the two objects") means flipping their OWD off public_read_write. That is not a seed tweak — it is the showcase's record-visibility baseline, asserted by the packages/qa/dogfood golden suites and examples/app-showcase/src/coverage.ts. Re-grading from S accordingly.

Precedent this card sits on

sharing-rules.ts:73-81 already retired an inert rule once, for exactly this class: share_contributor_tasks_with_manager was type: 'owner', "validated but was silently skipped at seed time (ADR-0078: nothing on the authoring surface may be silently inert)", and was replaced with an enforced criteria equivalent. Its replacement — share_open_tasks_with_manager — is one of the rules that is inert today. The previous fix moved the inertness rather than removing it, which is the finding worth carrying.

Dispatching now with a stop-and-report fence on any change to the two objects' sharingModel.

---

Generated by Claude Code

[os-project-manager]

{
 "issue": 9237,
 "status": "done",
 "branch": "claude/issue-9237-inert-showcase-sharing-rules",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/9697",
 "premise_still_valid": true,
 "summary": "Premise confirmed by boot on current main (c07d6e8b9): exactly the two WARNs the card names, verbatim. The measurement you flagged changed the deliverable — THREE rules sat on those two objects and only two warn. share_high_value_red_projects_with_managers is equally dead and produces NO diagnostic: its compound condition (health=='red' && budget>100000) matches no seeded row (the only red project, Compliance Audit, is budget 90_000), so reconcile builds an empty desired set, never calls grant, and never throws. The WARN is a function of the seed data, not of the declaration. Disposition: the OWD fence held and was never touched. showcase_project/showcase_task are public_read_write by deliberate ADR-0090 D1 stamp and that OWD is load-bearing beyond the security demo (it is what lets a contributor PATCH a project row it did not create — the #8023 write floor), so no sharing rule can ever take effect there. ADR-0049 enforce-or-remove: all three removed rather than re-homed onto another public object, which is the shape the previous repair took (share_open_tasks_with_manager WAS that repair, and it moved the inertness instead of removing it). The two capabilities they carried — a position recipient and a compound CEL condition (ADR-0058 D3) — move to share_key_account_qualified_contacts_with_managers on showcase_contact (OWD private, and the showcase_manager set grants it allowRead, the object-level bit a share row still needs). Acceptance measured in the artifact: boot diagnostics 3 warnings to 1, zero sharing WARNs, and the showcase now materialises its first rule-sourced sys_record_share row on a stock boot (Nora West, the one qualified Northwind contact of three qualified) where it previously materialised none at all.",
 "tests": "All at final head 17fc6a40b, heavy steps under flock /tmp/os-heavy-verify.lock. (1) BOOT BEFORE, origin/main c07d6e8b9, `pnpm dev -- --fresh -p 39237`: '⚠ Boot diagnostics — 3 warnings logged during startup' incl. WARN SharingServicePlugin: boot rule backfill failed for rule {\"rule\":\"share_open_tasks_with_manager\",\"error\":\"SHARING_NOT_ENABLED: 'showcase_task' is not under record-sharing enforcement (public sharing model or no 'owner_id' field); a share row on it would never be consulted\"} and the same for share_red_projects_with_execs / showcase_project. share_high_value_red_projects_with_managers did NOT warn. (2) BOOT AFTER, `pnpm dev -- --fresh -p 39238`: '⚠ Boot diagnostics — 1 warning logged during startup' — the remaining one is the pre-existing unrelated #8686 autonumber tenancy split; grep -c 'boot rule backfill failed' = 0. (3) A third boot against a persistent OS_HOME, queried with better-sqlite3: sys_sharing_rule holds 2 rows (share_new_inquiries_with_field_ops, and share_key_account_qualified_contacts_with_managers with criteria_json {\"$and\":[{\"stage\":\"qualified\"},{\"company\":\"Northwind\"}]}), and sys_record_share holds 1 row source='rule' on showcase_contact for record Nora West to the manager position holder, access_level read. Three seeded contacts are qualified; exactly one is at Northwind — the AND narrows in both directions on live data. (4) REVERSE VERIFICATION, prediction recorded before running: 1 red (inert-wirings §6 OWD arm naming exactly 3 offenders), §6 audience-read arm green, all other showcase tests green, totals 1 failed / 336 passed. Observed exactly that, offenders in the predicted order: share_red_projects_with_execs → showcase_project, share_high_value_red_projects_with_managers → showcase_project, share_open_tasks_with_manager → showcase_task. 336 pre-existing tests stayed green under the ablation, including no-startup-warnings.test.ts (#3420 'examples must boot with ZERO warnings'), which is scoped to password fields — that is why the defect survived. Fix committed BEFORE ablating; restore was `git checkout HEAD -- …`; tree clean at final commit, no ablation markers (`git status --porcelain` empty). (5) SUITES: @objectstack/example-showcase typecheck + 337 tests pass (21 files); @objectstack/dogfood typecheck passes; the three changed dogfood suites pass (14 tests). (6) GATE UNION re-derived after the last commit from the ACTUAL changed paths off `git merge-base origin/main HEAD` (c07d6e8b9) via scripts/pm/dispatch-gates.mjs — 14 path-matched + 5 convention-triggered — all run and green: check:changeset-gate-self-tests, check:cross-package-test-inputs, check:objectui-changeset, check:test-source-alias, check:type-source-resolution, check-adr-0087-registration, check-changeset-no-major, check-empty-changeset, docs-audit/check-affected-docs, spec check:empty-state / check:liveness / check:strictness-ledger / check:variant-docs, check:query-options-erasure, check:type-check-coverage, check:type-check-debt, check:engine-double-contract, check:where-matcher. Added beyond the derivation from reading my own diff: check:nul-bytes (any edit) and check:platform-checklist (the docs/qa/platform-checklist edit, which the path derivation did NOT name) — both green. Control-character self-scan over every changed path: clean. No ablation was run against dist/, so no rebuild claim applies here.",
 "open_questions": [
 {
 "question": "The fix removes the projects/tasks sharing narrative rather than keeping it. Is that the disposition you want, or would you rather take the fenced route and flip the two objects' OWD so the original rules take effect as written?",
 "options": [
 "A (shipped) — retire the three rules that can never be consulted; keep the position + compound-condition capabilities on showcase_contact. Blast radius: sharing-rules.ts, 3 dogfood suites, 1 checklist item. No OWD change, no permission-set change, access-matrix.json untouched, no golden re-baselined. Cost: the security demo stops describing projects/tasks, and the exec position no longer appears in any sharing rule (its demo remains readScope 'org' depth on its own permission set).",
 "B (fenced, not shipped) — flip showcase_project/showcase_task to a restrictive OWD so the original rules materialise. Measured blast radius: this is a reversal of #8023, whose whole subject is that a public_read_write project is what lets a showcase_contributor PATCH a row it did not create; the access-matrix.json snapshot carries sharingModel per entry, so 4 entries move (contributor + member_default on each object); 22 dogfood suites reference the two objects, with showcase-crud-persona-matrix the P0 one #9308 reasons about. Not a seed tweak — a showcase design call.",
 "C (rejected) — register waivers so the WARN is accounted for. Refused on evidence: the WARN states a true fact, and one of the three rules is dead WITHOUT a WARN, so a waiver keyed on the boot log would have covered two of three and hidden the worst one. That is the ADR-0078 defect wearing a hat."
 ],
 "recommendation": "A, and it is what shipped. B is not a fix for this card but a reversal of a landed decision (#8023) with a P0 matrix in its blast radius, and it would still leave the third rule silently matching nothing. Under ADR-0049 enforce-or-remove, an object deliberately declared public_read_write is a place where sharing CANNOT be enforced, so removal is the enforce-or-remove answer rather than a coverage loss — nothing that worked was dropped, and both capabilities the retired rules advertised are now demonstrated materialising a real grant instead of failing a backfill. If you prefer B, this PR is a clean base for it: the guard added here would go red on the flipped tree only until the rules were restored, which is the correct signal."
 }
 ],
 "out_of_scope_findings": [
 "filed as #9698: lint — a sharing rule declared on an object whose effective sharing model is `public` (or `controlled_by_parent`) is statically decidable from authored metadata and is only reported at boot, and then only when the seed data happens to match the rule's criteria. Unassigned, `finding` label, no pm:queue. Precedent cited: #7503. #9697 closes this class for examples/app-showcase only, via a per-app test guard."
 ]
}

---

Generated by Claude Code