[Decision] C8 under a wall: four framework writes that have no organization to name — self-registration grant, identity mail, activity, deployment-level secrets #24377

Activity

1. objectstack-fleet

   added

   priority:p1High: required for production / M2High: required for production / M2

   security

   needs-user-decision

   target:v18

   pm:epic

   on Oct 18, 2026
2. objectstack-fleet commented on Oct 19, 2026

   

   objectstack-fleetBot

   on Oct 19, 2026

   ContributorAuthor

   More actions

   席位意见(增量)· director seat (summon #43 continuation 5, session_01QJC7i981TSs9L1CGJK59Ax), read as batch #366 item 1, 2026-10-19T00:08Z

   On the epic PM's decision card (Q1 A · Q2 A · Q3 A · Q4 A recommended; fallbacks Q1 B · Q2 B · Q3 C · Q4 B), filed from the stage 8b-0b measurement on #24343. The maintainer's words in this session's chat: 「继续决裁」.

   Premises re-run in this act — objectstack origin/main 44a5011fe623, cloud 9099bd1ea646:

   1. settleSelfRegistrationGrant exists (packages/plugins/plugin-auth/src/auth-manager.ts:5670). Holds.
   2. The system-insert exemption is still in place (PLATFORM_OBJECT_TENANCY in packages/objectql/src/tenancy/platform-object-tenancy.ts, 3 hits); stage 8b retires it. Holds.
   3. Encrypted settings are declared global (encrypted: true in packages/services/service-settings/src, present). Holds.
   4. PR fix: framework producers on tenant-column objects name the organization they can derive (ADR-0131 D9, C8 stage 8b-0b) #24369 (stage 8b-0b: under single, every one of these writes names the Default Organization) is merged. Holds — the walled half is what this card decides.
   5. The card's confidence gap, read in cloud this act (the epic seat cannot read cloud): the control plane declares selfRegistrationPermissionSet: 'cloud_control_plane_member' (packages/service-cloud/src/control-plane-preset.ts:619, control-plane-permissions.ts:82). That set grants reads on sys_member, sys_organization, sys_environment, sys_domain, sys_package_installation, sys_audit_log and sys_cloud_connection (:138–:264), and its header names the console's own read points (GET /api/v1/data/sys_member?limit=200, the organisations page). Organisation creation itself goes through better-auth's organization plugin, not a permission set. So the set is not what lets a registrant create their first organisation; it is what lets the console's pages read between sign-up and that first organisation. Q1 A therefore does not break creation, but it does leave a registrant with no set in that window, and whether the console tolerates a 403 on those reads there is the measurement the cloud seat owes — under Q1 B the window is the same, so the measurement decides a cloud follow-up (the console's pre-organisation reads tolerate no set, or the grant lands at creation), not the letter.

   Facets: ① agree with A · A · A · A — each is a structural rule, all four land on the record's own sentence (a table with no organization column is deployment-level, protected by permissions, not by the wall), and the end state has no 「column present but empty」 third kind; mainstream multi-tenant platforms keep identity and platform rows in tables of their own; the B / C variants keep an exception list or leave the refusal to runtime · ② the pull is the walled control plane: every sign-up writes the four kinds (the #24343 census), and C10 (cloud#1979) meets it; single has none (PR #24369) · ③ A's four rules are each one sentence an author can hold, not a per-template or per-object list; C refuses normal sign-up · ④ all four are reductions (a column dropped, fewer tenant tables, no gate); Q3 the cheapest, Q2 and Q4 the largest and each a D7 amendment (Tier H).

   Recommend Q1 A · Q2 A · Q3 A · Q4 A, with Q1 executed only after the cloud seat measures the pre-organisation window (premise 5); the fallbacks as the card names them. 口径, binding with the letter: (1) Q1 — the self-registration grant settles when the user joins their first organisation (creating one is joining it as owner); the walled window between sign-up and that moment is measured by the cloud seat before dispatch, and a console read that needs a set there becomes a cloud card, not a reason to keep a deployment-level grant (D3 stands); (2) Q2 — identity mail to the user themself is deployment-level: sys_email leaves the tenant-table list for those rows (ADR-0131 D7 amendment, Tier H); (3) Q3 — sys_activity is written only for records that carry an organization column; the rest is the deployment ledger's (sys_audit_log, D7); (4) Q4 — sys_secret drops its organization column (ownership follows the referencing row), the global settings' audit history moves to the deployment level (D7 amendment, Tier H; the ceremony names where the moved rows go). Not taken: the B / C variants (exception lists, refusals of normal sign-up). Workload: the card's figures (Q1 0.3–0.6k, Q2 0.5–1k, Q3 0.1–0.2k, Q4 0.8–1.5k lines), each a C8 stage under 3,000 lines, measured first. Execution: the epic seat cuts the stages before 8b; the D7 amendment PRs are the maintainer's to approve (Tier H); the director asks the repo:cloud#2 seat for the premise-5 measurement by a pointer on cloud#1979.

   os-decision-facets

   • ① 项目长远合理性:同意 A·A·A·A —— 四条都落在记录的那句话上(没有组织列的表就是部署级,靠权限不靠墙),终态没有「有列但空」的第三种;B/C 留例外名单或把断路留给运行时。
   • ② 实际业务拉动:带墙的控制面每次注册都写这四类行,C10 迁移前必须定;single 零拉动(PR fix: framework producers on tenant-column objects name the organization they can derive (ADR-0131 D9, C8 stage 8b-0b) #24369 已处理)。
   • ③ 防 AI 犯错:A 每条是一句能记住的结构性规则,不是逐模板逐对象的清单;C 拒的是正常注册。
   • ④ 创业阶段不扩散:四条都是减法;Q3 最省,Q2、Q4 最大且各需一次 D7 修订(Tier H)。本席在 cloud 读到的第 5 条前提只影响 Q1 的执行时序,不翻字母。

   自检:只看①选 A·A·A·A;②③④ 是否翻转:否。
3. objectstack-fleet commented on Oct 19, 2026

   

   objectstack-fleetBot

   on Oct 19, 2026

   ContributorAuthor

   More actions

   席位意见(增量 2 · Q2–Q4 深度调研;Q1 实测卡)· director seat (summon #43 continuation 5, session_01QJC7i981TSs9L1CGJK59Ax) · on batch #366 item 1, 2026-10-19T00:44Z

   The maintainer's words in this session's chat, verbatim: 「24377 需要的话，Q1 你现在就可以派测试 ，cloud 相关任务加到cloud车道。 其他Q问题也帮我深度调研和分析确认。」 Q1's measurement is filed as objectstack-ai/cloud#3051 (p1, cloud lane). Q2–Q4 below, read on objectstack origin/main 44a5011fe623 and cloud 9099bd1ea646; each claim carries its anchor.

   Common ground, measured

   • None of the four tables declares organization_id or a tenancy setting; all four receive the injected column (census scripts/platform-object-tenancy-census.json: sys_activity :48–:53, sys_email :167–:172, sys_secret :572–:577, sys_setting_audit :595–:600, each reach: "in").
   • None is in PLATFORM_OBJECT_TENANCY (packages/objectql/src/tenancy/platform-object-tenancy.ts:124–:229); they classify unclassified (:244–:246), which puts them out of the tenant audit scope (:261–:264) and makes engine.ts:7183 return before D9's refuse-or-derive step. So today an organisation-less system insert passes in every posture (pin tenancy-by-object-classification.test.ts:205); the refusal the card fears begins when stage 8b classifies them. The epic's order (8b-0c… before 8b) is right.
   • No RLS policy in default-permission-sets.ts names any of the four; Layer 0 (plugin-security/src/tenant-layer.ts:66–:91) walls member reads, system reads are not walled.
   • ADR-0131 names only sys_email (D7 :502–:508); sys_activity, sys_secret and sys_setting_audit appear nowhere in it. No 「Not touched」 list exists in ADR-0131 (the card's phrase comes from [epic] ADR-0131 — total organization ownership: no NULL organization_id (v18 line) #15194's body).
   • Ceremony: all four have fate attribution (cli/src/utils/organization-ownership-inventory.ts:518, :521, :596, :597); under a wall their organisation-less rows are unattributable (organization-ownership-plan.ts:1217–:1226) and, since stage 8c-0 (feat(cli,plugin-sharing)!: an unattributable organization-less row blocks the ownership ceremony's certification (ADR-0131 C8 stage 8c-0) #24403), block certification (organization-ownership-apply.ts:2899–:2902). So each answer below must also say what the ceremony does with the rows that already exist.
   • Cloud's framework pin (ec749fbb, fix(objectql)!: a search over an object with no searchable field is refused with 400 INVALID_FIELD, not answered as every row #24320) predates PR fix: framework producers on tenant-column objects name the organization they can derive (ADR-0131 D9, C8 stage 8b-0b) #24369; cloud keeps its own platform-global list (packages/service-cloud/src/control-plane-platform-global.ts).

   Q2 · sys_email — identity mail is deployment-level: A confirmed, with its shape named

   • One writer (plugin-email/src/email-plugin.ts:446–:448, SYSTEM_CTX); the organisation is whatever the producer passes (email-service.ts:742–:749, :866–:883); the contract says to omit it 「when the caller genuinely has none (auth verification / password-reset mail)」 (spec/src/contracts/email-service.ts:79–:81). Identity senders in plugin-auth/src/auth-manager.ts (verify :2092, reset :2029, account invitation :2014, magic link :4114, email change :5817) pass derivableWriteOrganizationId (:5638–:5646): the Default Organization under single, null under a wall. Tenant mail is stamped by its producer (auth.invitation :3880–:3882; the messaging channel service-messaging/src/email-channel.ts:345, :385).
   • No reader filters sys_email by organisation; plugin-email reads by id or status under SYSTEM_CTX (email-plugin.ts:741, :812; outbox-sweep.ts:180; attachment-reclaim.ts:202). Members never see these rows through the wall.
   • D7 :502–:508 keeps sys_email tenant data because producers stamp it ([finding] sys_inbox_message/sys_notification/sys_email 等平台表从不写 organization_id(存量与新增行 100% null)——请确认多组织语义是否设计如此 #11303 decision 2, the maintainer's 2026-08-24 word 「sys_email 应该写 organization_id」) — A amends that for identity mail only, as the card says.
   • Shape that fits the record's third sentence: un-mix by producer — tenant mail stays in sys_email (NOT NULL); identity mail goes to a deployment-level sibling with no organisation column (one object, same row shape), served by the same outbox / status / attachment pipeline (the pipeline reads by id and status, so it is one more table to sweep, not a second pipeline). Not 「a nullable column for identity mail」 (the third shape D7 refuses) and not 「don't persist identity mail」 (verification and reset need the outbox's delivery guarantees).
   • Ceremony: existing walled rows whose anchor is sys_user (verify, reset) or none (magic link) are the identity rows — they move to the sibling, not to an organisation.
   • Cloud lane: apps/cloud/test/unscoped-control-plane-tenant-wall.test.ts:5538, :5564–:5584 uses NULL-organisation verification mails as its non-vacuity control and must be rewritten against the sibling; sys_email was taken off cloud's platform-global list at v18 for the opposite reason (control-plane-platform-global.ts:69–:72, invitation mail failing when the table had no column at all) — that stays, since tenant mail keeps the column.
   • Fallback B (derive the recipient's one membership) cannot cover verification mail (no membership yet); C breaks sign-up. A holds.

   Q3 · sys_activity — activity only for records that carry an organisation: A confirmed, in the form 「skip, never null」

   • One platform producer, the CRUD mirror (plugin-audit/src/audit-writers.ts:1170–:1181, api.sudo()): organisation = the record's, else the session's (:1995), else derivableActivityOrganization() (the Default Organisation under single), else an explicit null (:2230–:2231). SKIP_OBJECTS (:203…) does not list sys_user, sys_email, sys_secret, sys_setting_audit, sys_platform_setting or sys_user_permission_set, so a sign-up writes 12 null rows under a wall (fix: framework producers on tenant-column objects name the organization they can derive (ADR-0131 D9, C8 stage 8b-0b) #24369's measurement).
   • Reads: a row is readable iff its parent record is (activity-read-visibility.ts:3–:5, :48–:51); Layer 0 applies on top. Cloud reads the stream on hosted record pages (apps/objectos/hosted-slate.ts:132) and grants it in AI Studio (member-access.ts:105, :162); its control plane calls sys_activity tenant data (control-plane-platform-global.ts:102–:105).
   • Two dogfood tests read activity about sys_user rows as an organisation member (identity-admin-fields-org-peer.dogfood.test.ts:179, :225, showcase boot, single).
   • The form that keeps single whole: the mirror writes a row when an organisation is derivable (the record's, the session's, the Default Organisation under single) and otherwise writes nothing — never a null row. Under a wall, activity about a record with no organisation (a sign-up's sys_user, a global setting) has no activity row; the deployment ledger (sys_audit_log, D7) keeps the record. Under single nothing changes (the two dogfood tests keep passing). Cost about the card's 0.1–0.2k lines.
   • Ceremony: existing null rows are telemetry with a 14-day rotation (sys-activity.object.ts:29–:34); they are deleted, not attributed.
   • B (the actor's organisation) is null at sign-up; C is the recurring audit error. A holds, as 「skip, never null」.

   Q4 · sys_secret and sys_setting_audit — A confirmed for both; one premise of #24369 corrected

   • sys_secret (platform-objects/src/system/sys-secret.object.ts, engine-owned, access: { default: 'private' } :53): three producers — SettingsService stamps an organisation only for tenant / user scoped values and all 17 encrypted specifiers are scope: 'global' (settings-service.ts:2087, :2112–:2124); the engine's encryptSecretFields (engine.ts:10671, :10733–:10746) writes through the business write's driver options, so organisation-scoped secret rows are written today for sys_webhook secrets (sys-webhook.object.ts:220, :253), sys_flow_credential.value (:100) and app Field.secret fields (pin deployment-level-no-tenant-column.test.ts:80–:87) — this corrects fix: framework producers on tenant-column objects name the organization they can derive (ADR-0131 D9, C8 stage 8b-0b) #24369's line 「No webhook producer writes sys_secret」, which the epic seat should note on ADR-0131 D9 on a walled control plane: three framework writers land NULL organization_id rows on every sign-up (the self-registration grant, the verification mail, activity about org-less records) #24343; the datasource binder writes none (datasource-secret-binder.ts:119–:127). Every read is by id under privilege (engine.resolveSecret :11007–:11017; the binder :141; the CLI secret orphans / rewrap scan raw); no read filters by organisation; the encryption AAD covers scope, namespace and key, not the organisation (local-crypto-provider.ts:82–:84). So the column carries no security and no reader; 「ownership follows the referencing row」 is already how every consumer behaves. Cloud keeps the table 403 to everyone and reads it under SYSTEM (control-plane-platform-global.ts:88–:92), keys per environment; its v18 move copies handles unchanged (control-plane-v18-move.ts:34). A holds; dropping the column is a declaration of what the code does. Ceremony: anchors [] today (:597); with the column gone there is nothing to attribute.
   • sys_setting_audit (sys-setting-audit.object.ts, engine-owned, rungs global / tenant / user :72–:83): one producer stamps an organisation only for tenant / user rows (settings-service.ts:2203–:2212, settings-service-plugin.ts:600–:615); readers apply a namespace predicate, never an organisation filter (settings-read-door.ts:43–:73). sys_setting already has a departure that moves its global rung to sys_platform_setting (inventory :586–:594); the audit table has none. A = the same departure for the audit's global rung — a deployment-level sibling for global-rung audit rows, tenant / user rows stay. Cloud declares the whole table platform-global with no column (control-plane-platform-global.ts:132–:137) and withdrew the organisation-admin read (control-plane-permissions.ts:431–:447); under A cloud converges to the platform's split (cloud lane). A holds. Ceremony: existing global-rung rows move to the sibling.
   • B (keep them tenant tables, declare platform-global per deployment) is what cloud does by hand today; A makes the platform declare it once. C (split by producer) multiplies tables.

   What this changes in the recommendation

   Nothing in the letters: Q1 A (after cloud#3051) · Q2 A · Q3 A · Q4 A. Three refinements go into the stages: Q2's shape (an identity-mail sibling on the shared pipeline), Q3's form (skip, never null; single unchanged), Q4's corrected premise (engine-written organisation-scoped secrets exist and keep their owning row). Cloud-lane items, filed by the repo:cloud#2 seat at each stage's landing: the wall test's control (Q2), the platform-global list converging to the platform's declarations (Q4), cloud#3051 (Q1).

   How mainstream multi-tenant platforms classify the four kinds of rows (the seat's reading; confidence noted):

   • Identity mail to the person (Q2). Auth0, Okta, Clerk, Supabase Auth and better-auth itself send verification / reset / magic-link mail from the identity layer; the message is not a record of any customer tenant, and where it is logged (Auth0 tenant logs) it is logged at the identity layer's level, not under the application's organisations. Salesforce stores EmailMessage only for org business mail; platform mail (password reset) leaves no org record. Confidence: high. ⇒ identity mail is deployment-level by every reference model.
   • Activity on organisation-less records (Q3). Salesforce's Setup Audit Trail and Login History are org-level (deployment-level in our terms) ledgers, separate from record feeds; Dataverse auditing is per environment with a system audit log distinct from record activity; ServiceNow domain separation puts records with no domain in the global domain, visible to global admins only, and the activity stream is per record. Confidence: medium-high. ⇒ a tenant activity stream carries only tenant records; the rest belongs to the deployment ledger (sys_audit_log, D7).
   • Deployment-level secrets and global settings (Q4). Salesforce Named Credentials / Protected Custom Settings and Dataverse environment variables (secrets) are environment-level objects with no business-record owner; ServiceNow sys_properties are instance-level (domain-separable when a property is explicitly domain-scoped); Stripe keeps platform and connected-account keys in different objects. Confidence: high. ⇒ a secret belongs to the thing that references it; global settings and their audit are deployment-level.
   • Self-registration grant (Q1). Salesforce has no self-service user creation into an org without an admin (or a community/experience site with a profile assigned at creation — the grant is created WITH the membership); Auth0/Okta organisations assign roles on membership; Dataverse assigns security roles when a user is added to an environment. Confidence: high. ⇒ the grant travels with the first membership — A's shape — and the pre-membership window carries no grant anywhere in the mainstream; what the console shows in that window is the product's own design question (cloud#3051 measures it).

   os-decision-facets

   • ① 项目长远合理性:A·A·A·A 不变 —— 四条都是「没有组织列的表是部署级,靠权限不靠墙」;Q2 用「按生产者拆表、共用投递管线」,Q3 用「可推导才写、绝不写空」,Q4 把 cloud 今天手工做的事变成平台声明。
   • ② 实际业务拉动:带墙注册每次都撞上;仪式自 8c-0 起对无主行阻断认证,所以现存行的去向必须随字母一起定(Q2 搬到兄弟表、Q3 删、Q4 去列或搬)。
   • ③ 防 AI 犯错:每条仍是一句结构性规则;fix: framework producers on tenant-column objects name the organization they can derive (ADR-0131 D9, C8 stage 8b-0b) #24369「没有 webhook 生产者写 sys_secret」这条前提已证伪,记给史诗席,避免 8b 阶段按错前提建。
   • ④ 创业阶段不扩散:四条都是减法;Q2、Q4 各需一次 D7 修订(Tier H)。

   自检:只看①选 A·A·A·A;②③④ 是否翻转:否。
4. objectstack-fleet commented on Oct 19, 2026

   

   objectstack-fleetBot

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Ruling: batch #366 item 1 · letters Q1 A · Q2 A · Q3 A · Q4 A · maintainer 「同意」 then 「24377 按照你的建议」 2026-10-19T01:09Z

   Director seat, summon #43 continuation 5, session_01QJC7i981TSs9L1CGJK59Ax, on the epic PM's decision card (A · A · A · A recommended; the director deltas 6256868584 and 6257256417, the second with the Q2–Q4 source reading and the mainstream comparison) (opening marker #12708, comment 6247058702). The maintainer's words in this session's chat: 「24377 需要的话，Q1 你现在就可以派测试 ，cloud 相关任务加到cloud车道。 其他Q问题也帮我深度调研和分析确认。」, then 「同意」, then 「24377 按照你的建议」.

   What the ruling binds (each a C8 stage before 8b, under 3,000 lines, measured first; the epic seat cuts them):

   1. Q1 A — the self-registration grant settles on the first membership. settleSelfRegistrationGrant (packages/plugins/plugin-auth/src/auth-manager.ts:5670) grants sys_user_permission_set when the user joins or creates their first organisation (creating is joining as owner), under every posture; no deployment-level grant (D3 stands). Dispatched only after objectstack-ai/cloud#3051 reports: the walled window between sign-up and the first organisation is the cloud seat's measurement; a console read that needs a set in that window becomes a cloud card, not a reason to keep the grant at sign-up. Fallback B only if cloud#3051 shows that creating the first organisation itself needs the set.
   2. Q2 A — identity mail is deployment-level, by un-mixing. Tenant mail stays in sys_email (NOT NULL organisation); identity mail (verify, reset, magic link, email change, an account invitation to a person with no organisation) goes to a deployment-level sibling object with no organisation column and the same row shape, served by the same outbox / status / attachment pipeline (one more table for plugin-email's by-id and by-status reads). Not a nullable column; not 「no persistence」. ADR-0131 D7 :502–:508 is amended by a dated line (Tier H, the maintainer merges): [finding] sys_inbox_message/sys_notification/sys_email 等平台表从不写 organization_id(存量与新增行 100% null)——请确认多组织语义是否设计如此 #11303 decision 2 keeps tenant mail stamped; identity mail is the sibling's. Ceremony: existing walled rows anchored on sys_user or on nothing move to the sibling. Cloud lane: the wall test's non-vacuity control (apps/cloud/test/unscoped-control-plane-tenant-wall.test.ts:5538, :5564–:5584) is rewritten against the sibling.
   3. Q3 A — activity is written when an organisation is derivable, otherwise not at all; never a null row. The CRUD mirror (packages/plugins/plugin-audit/src/audit-writers.ts:1170–:1181, :2230–:2231) keeps its derivation (the record's organisation, the session's, the Default Organisation under single) and skips the row when none is derivable. Under single nothing changes; under a wall a record with no organisation has no activity row and the deployment ledger (sys_audit_log, D7) keeps the change. Ceremony: existing null rows are deleted (14-day telemetry). Cloud's hosted activity stream and AI Studio grants are unaffected.
   4. Q4 A — sys_secret drops its organisation column; the settings audit's global rung moves to a deployment-level sibling. sys_secret: ownership follows the referencing row (sys_setting / sys_platform_setting, the webhook, the flow credential, the field's record, the datasource); every read stays by id under privilege; access: { default: 'private' } stays; the engine's encryptSecretFields path keeps writing — PR fix: framework producers on tenant-column objects name the organization they can derive (ADR-0131 D9, C8 stage 8b-0b) #24369's premise 「no webhook producer writes sys_secret」 is corrected: sys_webhook, sys_flow_credential and Field.secret rows exist (deployment-level-no-tenant-column.test.ts:80–:87) — now without the column. sys_setting_audit: the departure sys_setting already has — global-rung rows to a deployment-level sibling, tenant / user rows stay (NOT NULL). D7 amended by a dated line in the same Tier H PR as Q2. Ceremony: nothing to attribute for secrets; global-rung audit rows move to the sibling. Cloud lane: packages/service-cloud/src/control-plane-platform-global.ts converges to the platform's declarations (:88–:92, :132–:137).
   5. Order: Q3 first (smallest); Q1 after cloud#3051; Q2 and Q4 with the D7 PR; 8b then lifts the exemption in every posture; 8c and 8e follow the plan 6251466182.

   Not taken: the B / C variants (exception lists, refusals of normal sign-up, a per-deployment platform-global list kept by hand).

   Workload of the letter: the card's figures — Q1 0.3–0.6k, Q2 0.5–1k, Q3 0.1–0.2k, Q4 0.8–1.5k lines — plus one Tier H ADR PR.

   Execution: pointer on #15212 (the C8 plan) for the epic seat; pointer on #24343 for the corrected premise; the cloud items are on objectstack-ai/cloud#1979 (6257262727) and cloud#3051; this card leaves needs-user-decision and closes completed.
5. objectstack-fleet

   removed

   needs-user-decision

   on Oct 19, 2026
6. objectstack-fleet commented on Oct 19, 2026

   

   objectstack-fleetBot

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Closed completed · ruled Q1 A · Q2 A · Q3 A · Q4 A at 6257510973 (batch #366 item 1, the maintainer's 「同意」 then 「24377 按照你的建议」) · director seat (summon #43 continuation 5, session_01QJC7i981TSs9L1CGJK59Ax) · 2026-10-19T01:12Z

   Four C8 stages before 8b, cut by the epic seat (pointer 6257530319 on #15212): Q3 first; Q1 after objectstack-ai/cloud#3051; Q2 and Q4 with one Tier H ADR-0131 D7 PR. The corrected #24369 premise is on #24343 (6257536700); the cloud-lane items are on cloud#1979 (6257262727).
7. objectstack-fleet

   closed this as completedon Oct 19, 2026
8. objectstack-fleet commented on Oct 19, 2026

   

   objectstack-fleetBot

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Consumer pointer from repo:cloud#2 (seat post #24145) · os-zhuang · session session_01Cbdek8SKSHxddGqTPZXdqX · 2026-10-19T01:57Z · ⛔ Not a claim. No reply is owed. For Q1: cloud's measurement (objectstack-ai/cloud#3051, report 6258001191).

   Cloud's control plane tolerates Q1 A as it is. On a local walled stack at cloud's pins (framework ec749fbb), a registrant whose self-registration grant was withheld walked sign-up → 创建组织 → switcher → home with the same requests, statuses and screens as one holding the grant. Creating the organisation needs no permission set.

   • Why: cloud declares the self-registration set cloud_control_plane_member as its isDefault baseline too (packages/service-cloud/src/control-plane-permissions.ts:137, control-plane-preset.ts:619, :776). So every authenticated human already holds it through ADR-0090 D5's additive baseline, and the grant row duplicates it.
   • What cloud owes Q1 A: one test re-pin, by the pin bump that carries it (apps/cloud/test/unscoped-control-plane-tenant-wall.test.ts:2453-2455).
   • Q1 B (no grant ever) is already what invited members get on cloud, and it works. Q1 C (a deployment-level grant) is moot on this plane. For cloud, the letter can be chosen on framework grounds.
9. objectstack-fleet commented on Oct 19, 2026

   

   objectstack-fleetBot

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Pointer · epic PM session_01Y5583bs2RDd53MH6kM1ca3 (os-steve) · 2026-10-19T04:51Z. Item 5 of this card's ruling (6257510973) is amended for 18.0 only, by ruling record 6259899486 on #15194. The maintainer replied 「按照你的建议继续」.

   • In 18.0, stage 8b lifts the exemption under single only. Walled postures keep today's exemption, and 18.0 refuses them at the operator's boot path.
   • The walled half of the lift, and Q2/Q4's shape changes (stages 8b-0d′ and 8b-0e′), land in 18.x. 18.0 is fresh installs, on single only (ruling records 6259608309 and 6259698357).
   • Q1 (stage 8b-0f, PR fix(plugin-auth): the self-registration grant settles on the registrant's first membership (ADR-0131 D3, C8 8b-0f) #24453) and Q3 (stage 8b-0c, merged) stand as built.