Skip to content

C3 stage 9 (#15204): declared sharing rules read from the registry, bootstrapDeclaredSharingRules retires, and the ceremony deletes the declared-rule mirrors; the verified marker follows (director ordering ruling) #23952

Open

Description

@objectstack-fleet

Part of #15204 (C3, ADR-0131). Filing gate: ④ a ruled execution card — the director's ordering ruling the record whose id is the first line of #15204's body on #15204 (batch #357 item 3, the maintainer's 「总监裁顺序」), under the stage-0 addendum 6100442578 (「If stages 1–8 land while stage 9 is still gated, stage 9 moves to its own card under the epic」). Filed by the director seat (summon #43, session_01QJC7i981TSs9L1CGJK59Ax). ⛔ Not a claim. pm:epic: the epic PM dispatches it. Facts were read at objectstack origin/main 099cc9d6.

The order (ruled)

Stage 9 goes first; the ownership ceremony's verified marker is reached after it. ADR-0131 D13/D14's zero-NULL gate is read as satisfied by a D10 report whose only remaining NULL rows are the declared-rule-mirrors the ceremony itself charts for this stage; any other NULL row keeps blocking both the marker and this stage.

The work

  1. Registry read. Declared sharingRules are served from the registry at enforcement. packages/plugins/plugin-sharing/src/sharing-rule-service.ts (listRules, getRule, findRuleRowByName, the orphan sweep) reads declared rules from the registry and organization-authored rules from sys_sharing_rule; the recipient and condition shapes are reconciled (the registry copy and the metadata-door copy differ today: recipient 'role', condition string versus {dialect, source} — packages/runtime/src/standalone-stack-seeder-declaration-copy.test.ts). Measure first: whether a reader like createSecurityCatalogReader for sharing_rule needs sharing_rule to become a registered metadata kind (the addendum's item (a) — packages/spec work for the spec seat, Blocked-by: this card if so).
  2. Seeder retired. bootstrapDeclaredSharingRules (packages/plugins/plugin-sharing/src/bootstrap-declared-sharing-rules.ts, called from sharing-plugin.ts) stops running; its retirement note is written where D13 asks (the seeder is machinery, not an authorable shape, so the ADR-0087 entry is the note).
  3. sys_record_share.source_id → name BEFORE any deletion (the addendum's item (c)): grants that point at a declared rule's row id are rewritten to the rule's name and verified to resolve in the registry.
  4. Mirrors deleted. The ceremony deletes sys_sharing_rule rows with managed_by in (package, platform) and customized not true — the mirror-deletion departure made executable on the fate-3 table, or this stage's own idempotent migration step; the executor chooses and pins either way. After it, remainingFor reaches 0 on sys_sharing_rule and the ceremony's post-check can verify.
  5. Text. The post-check label for declared-rule-mirrors names this card.

Pins

  • A fresh boot in every posture writes zero rows to sys_sharing_rule for declared rules, and a declared rule still enforces (positive control: remove the declaration and the grant stops).
  • On a database that completed the ceremony with the mirror rows standing (the maintainer's hotcrm dev.db: 11 rows), this stage's step deletes exactly those rows, every sys_record_share.source_id resolves by name, and the post-check reports zero remaining; a customized or organization-authored rule is untouched.
  • An organization-authored rule keeps working through sys_sharing_rule in every posture.

Decision owed, maybe

The addendum's item (b): what switching off a vendor's declared rule means under D6 (no regime charted for this type). If ADR-0131 D6 and ADR-0057 D6 do not settle it when this stage is planned, the epic PM files a decision card; it does not block items 2–5.

Governing text

ADR-0131 D2 (the seeder retires), D10 fate 2, D13 (:673), D14 (:697); the stage-0 addendum 6100442578; the ordering ruling the record whose id is the first line of #15204's body on #15204; ADR-0057 D6 (the runtime shape is canonical).

Dedupe

Open target:v18 cards whose title or body names stage 9, bootstrapDeclaredSharingRules or declared sharing rules at filing: #15204 only (REST list of 100 open). Dedupe words: C3 stage 9 declared sharing rules registry bootstrapDeclaredSharingRules retire declared-rule-mirrors ceremony verified marker.

Activity

  1. objectstack-fleet commented on Oct 16, 2026

    @objectstack-fleet
    ContributorAuthor

    Triage: first touch, target:v18 · the interim is #23948 (P0) · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-16T13:56Z

    Triage seat (objectstack-wide, seat post #6015). ⛔ Not a claim, ⛔ not a dispatch.

  2. objectstack-fleet commented on Oct 16, 2026

    @objectstack-fleet
    ContributorAuthor

    Hand-off from #23948 (landed): the flip point this stage owns · domain:cli seat 1 (#6024) · marchtian · session session_01PFB9ZGRWYvjhTXsd8i6KBp · 2026-10-16T17:07Z · ⛔ Not a claim.

    PR #23988 (merged as adce192974) makes the organization-ownership ceremony certify a database whose only remaining organization-less rows are sys_sharing_rule's declared-rule-mirrors. This is the interim the maintainer ordered on #23948 (「框架先放行这一项」), read with this card's ordering ruling.

    • The flip point. DECLARED_SHARING_RULE_SEEDER_RUNS in packages/cli/src/utils/organization-ownership-inventory.ts is true today. Set it to false in the same change that retires bootstrapDeclaredSharingRules, and in no other. From then on the mirrors hold certification again until this stage's deletion step (item 4) removes them.
    • What turns red until you flip it. packages/cli/src/commands/migrate/organization-ownership.declared-rule-mirrors.integration.test.ts case 1 boots a served stack declaring one sharing rule. It asserts that the rows the boot writes match the constant, and its message names the constant. Its case 2 and utils/organization-ownership-apply.declared-rule-mirrors.test.ts pin today's verdict and the restore ([complete, blocking, advisory] = [true, 11, 0] with the seeder retired).
    • Two readings for this stage's owner, from os migrate organization-ownership never certifies a database whose packages declare sharing rules: it waits on the declared-rule-mirrors departure (D2) while the same release's boot still seeds them #23948's dev report (6219947656, out_of_scope_findings 0 and 1); no change was made for either:
      1. Your ruling says "any other NULL row keeps blocking both the marker and this stage". On main before PR feat(cli): os migrate organization-ownership reports the declared sharing-rule mirrors as advisory while this release's boot still seeds them #23988, unattributable rows (fate 4 reported rows, and fate 3 rows no anchor names under a wall) were already counted as advisory, never blocking (advisory = after.summary.unattributableRows in the apply's post-check). Whether the ruling means to make them block is its owner's reading.
      2. After a database certifies, every served boot re-runs the seeder's upsert, and a rule a package adds later lands as a new organization-less mirror. The marker is not re-read at boot, so nothing re-blocks. This stage's deletion step covers all of them.

    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions