Skip to content

QA run · walled:isolated+group (11/14) · 580fd4ed · 2026-10-20 · 8 PASS / 1 PARTIAL / 1 FAIL / 1 BLOCKED / 3 NOT-RUN #24783

Closed

Description

@objectstack-fleet

QA run record: the walled-posture pass of the 18.0 round-3 top-up (anchor #24579). Server half (2): surface:cli, surface:build and this walled pass. The sister card S1 runs surface:api on the default single posture and parked its walled legs here. Maintainer-approved top-up, dispatched from session session_01CfRDy7SuTfUqaTu2AEH2Hi on 2026-10-20.

Scope rule for this record: for each item, only the walled leg is judged, i.e. the clauses its fixtures.knownGaps names as walled. Each is judged once under isolated and once under group, and both answers are written. Non-walled clauses are out of scope (walled pass). Console clauses are not-run (browser). A knownGaps entry recorded as blocked for another reason is carried as written.

Environment fingerprint

  • framework: 580fd4ed3c98a1752dfb0041b45cc713644fef7e (no pull, no sha change). .objectui-sha: not used. The console was not built, by dispatch decision.
  • build: pnpm install --frozen-lockfile then pnpm build --concurrency=2, giving 76/76 tasks. node scripts/check-dev-prereqs.mjs is green.
  • runner: one Claude Code cloud session. A second, independent agent did the RUNNER rule 7 re-derivation (see "Rule 7").
  • scratch app: a copy of examples/app-showcase (tar, without node_modules, .objectstack or dist) in a session scratch directory. Its own package.json carries every showcase dependency as link: to the workspace package, plus "@objectstack/organizations": "link:/home/user/objectstack/packages/plugins/organizations", installed there with pnpm install --ignore-workspace.
    • Package-file refs, for example the OpenAPI connector spec, resolve against the served root, so a config that only re-exports the stock showcase does not boot. The copy has to carry src/.
  • boot command, run from the scratch app:
    • OS_PLATFORM_OWNER_EMAIL=admin@objectos.ai OS_AUTH_MEMBERSHIP_POLICY=invite-only OS_PORT=P OS_TENANCY_POSTURE=isolated|group node packages/cli/bin/run.js dev --seed-admin -p P -d file:RUNDIR/{iso,grp}.db
    • isolated ran on port 47621, then group on 47631, one after the other.
    • A third short isolated boot on 47651 ran the removed-member producer probe.
    • Each boot printed Tenancy: isolated or Tenancy: group and mounted Organizations. GET /api/v1/auth/config answered features.multiOrgEnabled: true with tenancyPosture equal to the posture.
  • personas, per boot:
    • operator admin@objectos.ai: the seeded admin. It is OS_PLATFORM_OWNER_EMAIL, positions include platform_admin, and isPlatformAdmin: true.
    • A, B, N: minted with POST /api/v1/auth/admin/create-user, then change-password. Self-registration answers 403 SELF_REGISTRATION_CLOSED (audience invite_only). Each answered membershipCreated: false.
    • A and B each created their own organization: POST /api/v1/auth/organization/create, then set-active.
    • N holds no membership at all.
    • A later created a second organization, A2.
  • fixture writes made outside HTTP (system-level stamps on the run's own scratch SQLite, never a shared DB):
    • one sys_user_permission_set row granting A a runtime-authored qa_meta_author set (systemPermissions: ['manage_metadata']) in organization A. No HTTP door could place it: the operator is refused writing into an organization it is not a member of, and A's own org-admin insert is refused by ADR-0090 D12 condition (c).
    • sys_setting.locked = 1 on A's tenant row. No HTTP door sets a tenant lock: sys_setting refuses update with 405 OBJECT_API_METHOD_NOT_ALLOWED, and PUT /api/settings/NS carries no lock.
    • one legacy unscoped admin_full_access grant row for N, used for the platform-owner leg.
  • times (UTC): install and build 04:57–05:09. Scratch app and prerequisite probes 05:10–05:17. isolated 05:17–05:26, group 05:26–05:30, removed-member probe 05:37–05:39.

Environment self-check (run before scoring)

  • OS_TEST_TIERS=nightly vitest packages/cli/test/serve-organizations-host-resolution.e2e.test.ts and serve-organizations-mount-failure.e2e.test.ts: Test Files 2 passed (2), Tests 7 passed (7). These are the seven walled e2e cases.
  • vitest packages/qa/dogfood/test/wall-*.dogfood.test.ts: Test Files 6 passed (6), Tests 121 passed (121).
  • Prerequisite refusals, measured through os dev from the scratch app under isolated, one prerequisite absent each time:
    • @objectstack/organizations removed from the app's package.json (the link still present in node_modules): exit 1, ✖ FATAL: tenancy posture 'isolated' was requested but @objectstack/organizations could not be loaded, so the organization wall is INACTIVE … (ADR-0093 D5).
    • OS_PLATFORM_OWNER_EMAIL unset: exit 1, ✗ [auth] tenancy posture 'isolated' requires OS_PLATFORM_OWNER_EMAIL to be set ….
    • OS_AUTH_MEMBERSHIP_POLICY unset: exit 1, ✖ FATAL: tenancy posture 'isolated' is walled, but this deployment never declared a membership policy (membership policy "auto", source: default).
    • With all three present, the boot served (✓ Server is ready, health 200). No FATAL refusal occurred with the prerequisites met.

Scope: items and revisions

access-security.no-active-org-session-semantics r4 (P0) · access-security.walled-environment-metadata-operator-only r3 (P0) · platform-core.settings-organization-isolation-and-platform-rung r3 · access-security.activation-write-operator-gate r6 · access-security.platform-owner-email-anchor r5 · access-security.grant-table-write-contract r4 · access-security.parent-and-organization-write-guards r3 · records-forms.record-discussion-mentions r4 · integration-system.webhook-lifecycle r8 (all P1) · api-backend.action-activation-door-contract r3 · attachments-storage.chunked-upload-integrity r5 · automation.connector-dispatch-matrix r3 · identity-auth.workspace-org-switch r4 · studio-authoring.metadata-diagnostics-sweep r5 (all P2).

Per-clause verdicts (walled legs only; ISO = isolated, GRP = group)

access-security.no-active-org-session-semantics (P0): FAIL (GRP), pass on ISO

The whole item is a walled leg (requires[0]). Producer used: walled posture plus invite-only. An admin-created user with no membership is durable and non-racy: ADR-0093 D1 no-target-org, membershipCreated: false. Its session reads activeOrganizationId: null (get-session payload) and it has 0 sys_member rows. Second producer: an organization member who clears the active org with POST /api/v1/auth/organization/set-active {"organizationId": null}; get-session then reads null.

  • a[0] tenant-scoped reads resolve to nothing:
    • ISO pass: N, GET /data/showcase_task and /data/showcase_account answer 200 records: [].
    • GRP pass for N.
    • Note: under GRP the member with no active org (A) reads its own organization's rows (11 tasks, all organization A), because group reads span the caller's memberships. See accuracy finding F3.
  • a[1] tenant-scoped writes refused 4xx naming the missing org:
    • ISO pass: N and A (cleared) get 403 PERMISSION_DENIED "[Security] Access denied: 'showcase_task' is scoped to an organization, and this session has no active organization — so this insert has no organization to place the record in …".
    • GRP pass for N, same 403.
    • GRP fail for A (member, cleared active org): POST /api/v1/data/showcase_task answers 500 {"error":"Internal server error","code":"ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED"}. Reproduced twice by the runner and twice by the rule-7 verifier on fresh boots. Reproduction is below.
    • showcase_account is no control: its 403 is the object-permission gate (allowCreate: false for the caller's sets), which runs first.
  • a[2] no NULL stamping: ISO pass, GRP pass. Admin-side counts of showcase_task / showcase_account rows with NULL or empty organization_id were 0 before and 0 after every refused attempt, including the 500s, and no row titled with the probe exists.
  • a[3] org-scoped holder with no active org reads and writes nothing across tenants:
    • ISO pass: A (owner of org A, organization_admin in A) with active org cleared. /auth/me/permissions drops organization_admin, so systemPermissions is []. Lists of showcase_task, showcase_account, sys_member and sys_invitation return 0 rows. B's task by id answers 404, and so does A's own task. Writes are refused, and invite-member into B's org answers MEMBER_NOT_FOUND.
    • GRP pass on the cross-tenant point: A sees only organization A rows (its membership), and B's task answers 404.
  • a[4] audit rows are not permanently invisible:
    • ISO and GRP pass, with a note. N's login/logout rows in sys_audit_log carry tenant_id: null because the user belongs to no organization at all, so there is no real tenant to stamp.
    • The platform operator reads them through GET /api/v1/data/sys_audit_log?filter={user_id} (200, login and logout listed), so they are not invisible to every RLS reader. N itself gets 403 on sys_audit_log. See F3.
  • a[5] the state is legal and nothing 500s:
    • ISO pass: get-session 200, GET /data/sys_user 200, POST /auth/update-user 200, no 5xx.
    • GRP fail: the member write path in a[1] answers 500 (negative[3]).
  • a[6] the three subsystems agree:
    • ISO pass. Sharing drops org grants with no active org; the wall gives empty reads and 403 writes; the audit rows are recorded and readable by the operator.
    • GRP fail: the write path gives two answers to the same state, 403 for a non-member and 500 for a member.
  • Negatives: negative[0], [1], [2], [4] and [5] did not occur on either posture. negative[3] (a 500) occurred on GRP.

access-security.walled-environment-metadata-operator-only (P0): PASS

The walled legs per knownGaps[0] are a[1], a[2] and negative[0]. A holds manage_metadata in organization A only: /auth/me/permissions includes it, positions are [org_owner, everyone], isPlatformAdmin: false.

  • a[1]: ISO pass, GRP pass. As A:
    • PUT /meta/object/qa_walled_probe (sharingModel set) → 403 FORBIDDEN, "… requires the platform operator: this deployment runs the 'isolated'/'group' tenancy posture …".
    • PUT /meta/permission/showcase_member_access → 403 FORBIDDEN.
    • POST /meta/view/showcase_task.urgent/publish → 403 FORBIDDEN.
    • DELETE /packages/com.example.showcase → 403 PERMISSION_DENIED.
    • POST /security/permission-sets/showcase_member_default/clone → 403 PERMISSION_DENIED.
    • POST /meta/_migrate-stored → 403 FORBIDDEN.
    • POST /automation → 403 PERMISSION_DENIED.
    • POST /marketplace/install-local with a catalog-carrying manifest → 403 FORBIDDEN.
    • Read-backs as the operator: the object, clone and flow answer 404, the package is absent, and the showcase package is still present.
  • a[2], walled half: ISO pass, GRP pass. The operator's identical object PUT answers 200 ("Saved object … env-wide"), GET answers 200, and the follow-up delete answers 200. The single half is out of scope (walled pass).
  • negative[0]: ISO pass, GRP pass. No org-owner write succeeded.

platform-core.settings-organization-isolation-and-platform-rung (P1): PASS

  • a[2]: ISO pass, GRP pass.
    • A PUT /api/settings/company {"legal_name":"A Corp"} stores a tenant row in organization A. B's read stays default/null, then B's own value. The lock was stamped on A's row (see the fixture writes above); A's read shows locked: true.
    • B reads locked: false and B's write is admitted. The DB holds one row per organization, A locked and B unlocked.
  • a[3]: ISO pass, GRP pass. The operator with active org cleared, PUT /api/settings/company → 400 SETTINGS_VALIDATION "… Legal name is a per-organization setting, and this write names no organization to store it for …". No row was written.
    • Callers without setup.write get 403 SETTINGS_FORBIDDEN first.

access-security.activation-write-operator-gate (P1): PASS

The walled leg is a[4], live.

  • ISO pass, GRP pass. As A (org admin with manage_metadata):
    • POST /automation/showcase_urgent_task_alert/toggle {"enabled":false} → 403 PERMISSION_DENIED "Enabling or disabling a packaged flow writes an INSTALL-WIDE activation row, and this deployment runs the 'isolated'/'group' tenancy posture … It requires the platform operator (ADR-0126 §5) … ask your platform operator; an organization that needs flows of its own is given an environment of its own." No clone is recommended.
    • Action door POST /actions/_activation/showcase_task/showcase_mark_done → the 403 action sentence, also operator-only with no clone.
    • The invalid body {"enabled":"false"} still answers the 403.
    • sys_metadata_activation is empty after the refusals.
  • The operator's toggles answer 200 at both doors. The ledger rows are flow and action, active: false, with no organization_id key on either. Both were restored to enabled.
  • B (no manage_metadata) gets the tier sentence "requires the manage_metadata capability".

access-security.platform-owner-email-anchor (P1): PASS

The walled half of a[5], live.

  • ISO pass, GRP pass. The config anchor confers on the walled rig: the operator has isPlatformAdmin: true and platform_admin among its positions.
  • A legacy unscoped admin_full_access grant row (N, organization_id NULL) confers no rung on a walled posture: N reads positions [everyone], isPlatformAdmin: false. The held set's capabilities still apply: GET /datasources answers 200 and systemPermissions includes manage_platform_settings. This matches the clause ("the held set still grants its own capabilities; only the rung and the built-in platform_admin position go").
  • With that set, N is still refused metadata writes: 403 "requires the platform operator".

access-security.grant-table-write-contract (P1): PASS

  • a[4]: ISO pass, GRP pass. A (org admin, org A) POST /data/sys_user_permission_set {"user_id": B, "permission_set": "showcase_member_default"} → 400 VALIDATION_FAILED, fields[0] {field: user_id, code: reference_not_found}, "… is not a member of the organization … add the user to that organization first".
  • Controls: naming B's organization explicitly → 403 "the row belongs to organization …, not the one you administer". A grant to A itself → 201.

access-security.parent-and-organization-write-guards (P1): PASS

  • a[1]: ISO pass, GRP pass.
    • A PATCH /data/showcase_task/ID {"organization_id": null} → 403 PERMISSION_DENIED "the update would leave 'showcase_task' with no organization". "" gives the same answer. Naming B's org → 403 "would place … in another tenant". The row is unchanged.
    • Inserts carrying organization_id: "" or null → 201, stamped with organization A (DB read).

records-forms.record-discussion-mentions (P1): NOT-RUN (no walled leg)

  • Its knownGaps names no walled leg. The hit that put it on the list is a pin fixture name (lead_walled); see F1. Every clause is out of scope (walled pass), and the console clauses are not-run (browser).
  • Observed while probing the server half on both walled boots: an authorization / tenancy-wall finding, filed separately with detail withheld pending maintainer (see "Extracted"). Reproduced on both postures by the runner and by the rule-7 verifier.

integration-system.webhook-lifecycle (P1): BLOCKED

  • a[2] (bulk pair): blocked(dependency), carried as knownGaps[1] writes it. The flow-node predicate multi-write organization question on QA run · surface:mixed (90/90) · 36b2889c · 2026-10-12 · 72 PASS / 10 PARTIAL / 8 FAIL / 0 BLOCKED / 0 NOT-RUN #23166 is unruled. Not hard-judged.
  • Observed on both walled boots, outside the clauses:
    • The declared showcase_task_changed is switched on only by the operator. An org admin gets 403 "writes an INSTALL-WIDE activation row … requires the platform operator"; an undeclared name answers 404.
    • Once on, it delivered one sys_http_delivery row per task create, stamped with that event's organization: declared:showcase_task_changed for A, and the same for B. Each organization reads only its own delivery rows.
    • An in-organization scratch sys_webhook authored by A (organization A) received A's create only. B's create in the same window did not reach it. B reads no sys_webhook row of A's: list empty, by-id 404, PATCH 404.
    • B's POST /api/v1/webhooks/redeliver of A's delivery id → 404 RESOURCE_NOT_FOUND.
    • See F4: requires[0]'s "under a walled posture it would be refused as belonging to no organization" no longer holds.

api-backend.action-activation-door-contract (P2): PASS

The walled reading is a[0], authority first under a wall. knownGaps[2] calls it unreachable; see F5.

  • ISO pass, GRP pass.
    • A (org admin with manage_metadata) POST /actions/_activation/showcase_task/no_such_action {"enable": false} (mis-bodied and undeclared) → 403 PERMISSION_DENIED with the posture/operator sentence. That is neither the 400 nor the 404, and it recommends no clone.
    • B (no manage_metadata) → 403 with the manage_metadata "functionally equivalent to deleting it" sentence. Anonymous → 401 UNAUTHENTICATED.
  • Operator controls: undeclared → 404 "has no declaration — there is nothing to switch off"; {"enable":false} on the declared action → 400 VALIDATION_FAILED unknown_field, "did you mean enabled?".
  • No ledger row was written by any refusal.

attachments-storage.chunked-upload-integrity (P2): PASS

  • a[3]: ISO pass, GRP pass.
    • Cookie sign-in as A with active org A. POST /api/v1/storage/upload/chunked (2 chunks), then chunk 0 → 200.
    • set-active to A2, then chunk 1 PUT → 409 RESOURCE_CONFLICT "This upload was started in a different organization than your active one …", and complete → the same 409.
    • Progress → 200, status: in_progress, uploadedChunks: 1. Its expiresAt is 24 h after the start, so the stamp is not due.
  • Cross-user probe: B with A's upload id gets progress 403 "Only the user who started this upload can act on it" and file URL 404.

automation.connector-dispatch-matrix (P2): NOT-RUN (no walled leg)

  • No walled leg: the "isolated boot" in its text means the dogfood §0 own-port boot (F1).
  • Observed: on both walled boots a task created in organization A or B fired showcase_declarative_connector_ping and showcase_mcp_connector_echo, both completed, with runs stamped with that organization. Each organization reads only its own sys_automation_run rows.

identity-auth.workspace-org-switch (P2): PARTIAL

  • a[0], a[2], a[4]: not-run (browser). The posture precheck for a[0] holds: /auth/config tenancyPosture is isolated/group and multiOrgEnabled: true.
  • a[1]: ISO pass, GRP pass. A, holding organizations A and A2, set-active A2 → 200. get-active-member names A2.
  • a[3]: ISO pass, GRP pass.
    • ISO: A's org-A task by id → 404 after the switch, and the list holds only A2 rows (10 seeded).
    • GRP: org-A rows stay readable (13 A plus 10 A2, reads span memberships), and a create after the switch lands in A2 (DB read of organization_id).
    • Both: GET /meta/object/showcase_task is byte-identical (md5) before and after.
  • a[5] API half: ISO pass, GRP pass. Forged set-active to B's organization → 403 USER_IS_NOT_A_MEMBER_OF_THE_ORGANIZATION. Afterwards get-active-member → 400 NO_ACTIVE_ORGANIZATION and get-session active is null, never B's org. The UI half is not-run (browser).

studio-authoring.metadata-diagnostics-sweep (P2): NOT-RUN (no walled leg)

  • No walled leg: "isolated scratch file DB" means the run's own DB (F1).
  • Observed on both walled boots: an org admin GET /meta/diagnostics → 200 entries: [], scannedTypes: 28, scannedItems: 402. ?type=viewes → 400 with the spelling refusal.

Reproduction rule: the one publishable fail (GRP only)

  1. Boot the scratch app as in the fingerprint, with OS_TENANCY_POSTURE=group.
  2. As the operator, POST /api/v1/auth/admin/create-user {"email":"qa-a@wall.test","password":"…"}. Sign in as that user, change the password, and sign in again to get token T.
  3. POST /api/v1/auth/organization/create {"name":"qa-org-a","slug":"qa-org-a"}, then POST /api/v1/auth/organization/set-active {"organizationId": "ORG_A"}.
  4. Create showcase_account {name}, then showcase_project {name, account}, and keep the project id.
  5. POST /api/v1/auth/organization/set-active {"organizationId": null}. GET /api/v1/auth/get-session now shows session.activeOrganizationId: null.
  6. POST /api/v1/data/showcase_task {"title":"x","project":"PROJECT_ID"}.
    • expected (a[1], and the ISO answer to the same steps): 403 PERMISSION_DENIED naming the missing active organization.
    • actual: 500 {"error":"Internal server error","code":"ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED"}. The server log shows [REST] Unhandled error: SystemWriteOrganizationRequiredError: Insert on 'showcase_task' was REFUSED: a system-context write on a tenant-scoped object must carry an organization …. No row was written.
  • Disposition: product defect. The fix is in the walled write path, not the checklist; it was extracted.

Rule 7

The P0 fail and the authorization finding were re-derived by an independent agent on its own fresh isolated and group boots, from the steps alone. It agrees on both:

  • the 500 reproduces on group only, with no row written;
  • the 403 holds for a member-less caller on both postures;
  • the 500 is error-contract severity, not a security bypass: the write is evaluated as the session, and only the error text says "system-context".

Removed-member producer (knownGaps[0] of the P0 item)

On isolated:

  1. The operator add-members M into organization A. M's session reads A's task (200).
  2. A remove-members M; M's sys_member count is 0.
  3. M's live token then answers 401 UNAUTHENTICATED on reads, list, create and update. The removal revokes the session, so this path no longer yields "a live session with no organization" (F3).

Extracted

See the comments below; card numbers are added at close-out.

Checklist-accuracy findings / fixture gaps (for the anchor #24579, not extracted)

  • F1, the dispatch's list of 14 walled items: three carry no walled leg in fixtures.knownGaps. Their keyword hit is a word collision:
    • records-forms.record-discussion-mentions: the pin fixture name lead_walled.
    • automation.connector-dispatch-matrix: "boot showcase isolated", the dogfood §0 own-port boot.
    • studio-authoring.metadata-diagnostics-sweep: "isolated scratch file DB".
    • They are NOT-RUN here, so the denominator 14 overstates the walled set by three.
  • F2, the RUNNER entry "A walled boot is a fixture of its own" and the rewritten knownGaps:
    • The three prerequisites refuse as described through os dev.
    • Through bare os serve (and so os start) without NODE_ENV=development, the boot runs in production mode and needs OS_AUTH_SECRET and a stable encryption key first. Without them AuthPlugin is skipped (⚠ AuthPlugin skipped — set OS_AUTH_SECRET …), the walled OS_PLATFORM_OWNER_EMAIL and membership-policy gates never run, and the walled server comes up ⚠ Server is ready — DEGRADED: missing core services: auth, not FATAL. Measured with os serve --no-ui from the scratch app, prerequisites 1 and 3 present and 2 absent, and with 1 and 2 present and 3 absent.
    • So the entry's "each one absent refuses the boot naming itself" holds for os dev only; serve/start need the auth secret as a fourth prerequisite before the other two are judged.
    • A config that only re-exports examples/app-showcase/objectstack.config.ts from a scratch directory does not boot: package-file refs (the OpenAPI connector spec) resolve against the served root. The scratch app must be a full copy.
  • F3, access-security.no-active-org-session-semantics:
    • knownGaps[0] and [1] say the durable producers are the removed-member path or a reconciler that binds nobody, and that invite-only is blocked(fixture). On a walled boot with OS_AUTH_MEMBERSHIP_POLICY=invite-only (a walled-boot prerequisite), every admin-created user lands with membershipCreated: false, which is a durable producer. set-active {"organizationId": null} is a second durable producer.
    • The removed-member path now revokes the session (401), so it no longer produces the state.
    • a[0] reads "resolve to nothing", but under group a member with no active org reads its memberships' rows by design. The clause should scope itself to a caller with no membership, or say what group answers.
    • a[4] assumes every first-session audit row has a real tenant; for a user with no organization at all the rows are NULL-tenanted and readable only by the platform operator. The clause should say whether that is the intended answer.
  • F4, integration-system.webhook-lifecycle requires[0]: "under a walled posture it would be refused as belonging to no organization" is stale.
    • Under isolated and group the declared webhook, switched on by the operator, delivers one row per event stamped with that event's organization, and each organization reads only its own. That is the shape wall-declared-webhook-deployment-wide.dogfood.test.ts pins.
    • Creating a scratch sys_webhook over /data needs definition_json (required) and lower-case method; the recipe names neither.
  • F5, api-backend.action-activation-door-contract knownGaps[2] still says the group/isolated legs "need an enterprise tenancy runtime no example app composes". That is stale since feat(objectql,cli)!: 18.x step 4: the walled lift (8b walled half plus the walled part of #24489) #24580; a scratch app with the open @objectstack/organizations composes it, and the ordering held on both postures.
  • F6, platform-core.settings-organization-isolation-and-platform-rung steps[2] says "save a tenant key and lock it". No HTTP door sets a tenant-row lock: sys_setting refuses update 405, and the settings PUT carries no lock. The run stamped locked directly, so the step needs a named recipe.
  • F7, access-security.walled-environment-metadata-operator-only requires[2] and access-security.activation-write-operator-gate need an organization owner holding manage_metadata in their own org. No HTTP door grants it on a walled boot:
    • the operator cannot insert a grant into an organization it is not a member of (403 "outside the caller's organization scope");
    • the org admin's own insert is refused (ADR-0090 D12 condition (c): manage_metadata is not scope org).
    • The run used a system stamp; the fixture needs a named recipe (the dogfood harness inserts it through the engine).
  • F8, identity-auth.workspace-org-switch requires[0]: the parenthetical "measured by QA run QA run · surface:mixed (90/90) · 36b2889c · 2026-10-12 · 72 PASS / 10 PARTIAL / 8 FAIL / 0 BLOCKED / 0 NOT-RUN #23166 … REFUSES TO BOOT" predates feat(objectql,cli)!: 18.x step 4: the walled lift (8b walled half plus the walled part of #24489) #24580, and step text should cite the RUNNER walled-boot entry instead. A user can hold two memberships by creating a second organization itself; the platform-admin add-member is not needed.

Handover

None of the 14 is left un-handled. The three NOT-RUN items have no walled leg (F1). The browser clauses of identity-auth.workspace-org-switch need a console build.

Activity

  1. objectstack-fleet commented on Oct 20, 2026

    @objectstack-fleet
    ContributorAuthor

    Close-out: extraction for this record (RUNNER extraction obligation; one line each).

    Extracted: #24784 · access-security.no-active-org-session-semantics · acceptance[1] (group posture: a member with no active organization gets 500 ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED; also acceptance[5], acceptance[6], negative[3])
    Extracted: #24785 · records-forms.record-discussion-mentions · acceptance[4] (authorization class: detail withheld pending maintainer)
    Parked-on: #24579 · checklist-accuracy findings F1–F8 and the walled-boot prerequisite note (F2), from this record's "Checklist-accuracy findings / fixture gaps" section

    Both extracted findings were re-derived on fresh walled boots by an independent agent (RUNNER rule 7), which agreed with each.


    Generated by Claude Code

  2. objectstack-fleet commented on Oct 20, 2026

    @objectstack-fleet
    ContributorAuthor

    Closure complete (checklist-test §5): every FAIL in this record has a disposition (the Extracted: / Parked-on: lines in comment 6284383133). #24784 and #24785 are both closed: #24785 was fixed by PR #24794, and its ledger clause landed through PR #24811 and PR #24869. Accuracy findings F1–F8 are parked on #24579 (comment 6284472874), and round 11 (#24801) took the walled-boot corrections.

    Closed by: the 18.0 QA wave dispatch session session_01CfRDy7SuTfUqaTu2AEH2Hi, on the maintainer's standing instruction there (2026-10-19, verbatim 「qa-run的卡片处理完的是不是可以关闭」), at 2026-10-20T13:11Z, after 18.0.0 was published.


    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

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions