@@ -2319,7 +2319,7 @@
       "title": "Editing the permission matrix and publishing flips an affected persona's live API access; revoke flips it back; assign/unassign moves access",
       "since": "v16",
       "status": "active",
-      "revision": 6,
+      "revision": 7,
       "priority": "P1",
       "surface": "mixed",
       "personas": [
@@ -2337,7 +2337,7 @@
       "steps": [
         "boot showcase with the console; admin session; provision member M granted a writable set S that WITHHOLDS a verb on an object (e.g. delete:false on showcase_task); as M create the showcase_task rows the DELETE probes below use — M's OWN rows, never seeded ids: a set silent on writeScope is owner-only (packages/plugins/plugin-security/src/permission-evaluator.ts getEffectiveScope), so a seeded task owned by someone else stays refused after the verb flips ON and confounds the verb with ownership",
         "baseline: as M, DELETE /api/v1/data/showcase_task/<one of M's own ids> — must be refused 403 (the withheld verb)",
-        "in the console Permission Matrix editor for S (Setup's metadata-admin door, which mounts the editor with no packageId), flip delete ON for showcase_task and Save. That Save is a plain PUT that lands state:'active' at once, not a draft: only a package-scoped editor (Studio's Access pillar, packageId set) saves with mode 'draft' (ui/packages/app-shell/src/views/metadata-admin/PermissionMatrixEditor.tsx, the saveVersioned call; QA run #27441). Capture PUT /api/v1/meta/permission/S, then POST /api/v1/meta/permission/S/publish, which answers 404 code NO_DRAFT after that active save, per acceptance[1]; a run that edits through the package door instead publishes the pending draft and captures a 2xx",
+        "in the console Permission Matrix editor for S (Setup's metadata-admin door: /apps/setup/metadata/permission/S redirects to /_console/studio/~all/metadata/permission/S, which mounts the editor with no packageId and saves on an explicit Save), flip delete ON for showcase_task and Save. That Save is a plain PUT that lands state:'active' at once, not a draft: only a package-scoped editor (Studio's Access pillar, packageId set) saves with mode 'draft' (ui/packages/app-shell/src/views/metadata-admin/PermissionMatrixEditor.tsx, the saveVersioned call; QA run #27441). Capture PUT /api/v1/meta/permission/S, then POST /api/v1/meta/permission/S/publish, which answers 404 code NO_DRAFT after that active save, per acceptance[1]; a run that edits through the package door instead publishes the pending draft and captures a 2xx",
         "as M: DELETE /api/v1/data/showcase_task/<another of M's own ids> — must now be 2xx (access flipped)",
         "flip delete back OFF in the matrix and Save (active at once, as in steps[2]; publish only a package-door draft); as M: DELETE again — must be refused 403",
         "field-level half: flip an FLS bit (a showcase_project field editable:false→true) in the lower matrix and Save (as in steps[2]); as M PATCH that field — the write flips accordingly",
@@ -2431,6 +2431,12 @@
           "date": "2026-11-01",
           "change": "negative[2] moved to source[6]: it was a scope note naming the items that own the neighbouring surfaces, which no run can decide, so it could only score skipped. Its text is unchanged. Ruling 6545938831 item ① on #28345 (scope notes leave negative[], which keeps only decidable entries; the #27651 precedent). No clause changed. Wave anchor #27377",
           "ref": "#28345"
+        },
+        {
+          "revision": 7,
+          "date": "2026-11-08",
+          "change": "steps[2]: /apps/setup/metadata/permission/NAME redirects to /_console/studio/~all/metadata/permission/NAME, where the editor uses an explicit Save. Checklist-accuracy finding of QA run #31486 (owed:weekly, at 0647dabb). Read at base 4894cfe1",
+          "ref": "#31499"
         }
       ]
     },
 
@@ -134,7 +134,7 @@
       "title": "MCP HTTP transport (/mcp) and the public /mcp/skill endpoint gate exactly as documented: 404 when opted out, 501 when unimplemented, 401 anonymous, 403 scopeless-OAuth, full tool list when keyed",
       "since": "v15",
       "status": "active",
-      "revision": 8,
+      "revision": 9,
       "priority": "P1",
       "surface": "api",
       "fixtures": {
@@ -185,9 +185,9 @@
           "evidence": "the 401 response incl. headers"
         },
         {
-          "clause": "a keyed MCP client completes initialize + tools/list, and the tool set over /api/v1/mcp (the HTTP door) is the documented principal-bound surface: list_objects, describe_object, query_records, aggregate_records, get_record, create_record, update_record, delete_record, list_actions, run_action, resume_run, validate_expression. The stdio door on the same build serves 9 of these, without the action family (list_actions, run_action, resume_run): the tool set is a function of the bridge (wireBridgeTools, packages/mcp/src/mcp-http-tools.ts), and the stdio data bridge implements no action methods (createStdioDataBridge, packages/mcp/src/stdio-data-bridge.ts), so a stdio count of 9 is not a shortfall against this clause",
+          "clause": "a keyed MCP client completes initialize + tools/list, and the tool set over /api/v1/mcp (the HTTP door) is the documented principal-bound surface: list_objects, describe_object, query_records, aggregate_records, get_record, create_record, update_record, delete_record, delete_records, list_actions, run_action, resume_run, validate_expression, read_file, create_upload_link: 15 tools. list_remote_tables and import_object are not in it: they register only for a token whose scopes name metadata:write (registerFederationTools, the same file), so a key or a session never lists them. The stdio door on the same build serves 10 of these: every tool but the action family (list_actions, run_action, resume_run) and the file pair (read_file, create_upload_link). The tool set is a function of the bridge (wireBridgeTools, packages/mcp/src/mcp-http-tools.ts), and the stdio data bridge implements no action methods and neither readRecordFile nor createUploadLink (createStdioDataBridge, packages/mcp/src/stdio-data-bridge.ts), so a stdio count of 10 is not a shortfall against this clause",
           "oracle": "network",
-          "verify": "tools/list names against packages/mcp/src/mcp-http-tools.ts registrations (aggregate_records may be absent only when the bridge cannot route it, and resume_run only when the host cannot resume runs — both graceful degradation; record which)",
+          "verify": "tools/list names against packages/mcp/src/mcp-http-tools.ts registrations (aggregate_records may be absent only when the bridge cannot route it, resume_run only when the host cannot resume runs, and read_file / create_upload_link only when the bridge implements no readRecordFile / createUploadLink — all graceful degradation; record which)",
           "evidence": "the session trace + tool-name list"
         },
         {
@@ -225,7 +225,8 @@
           "change": "automated.ref and variants[2] corrected. Checklist-accuracy findings of the 18.2.0 wave 2 (QA run #26468, Tier 1 half A, at 756220c4; wave anchor #25807, slice B). (1) The ref said no named file scores a clause alone, but mcp-skill-method-not-allowed.hono.integration.test.ts asserts acceptance[2] in full (status, Allow: GET, the exact envelope message) over a real Hono socket and the real dispatcher, and a 405 never reaches the faked services; the ref now says it scores that clause. (2) The ref gains packages/cli/test/serve-mcp-capability-collision.e2e.test.ts as corroboration (spawned server, osk_ key, initialize + tools/list, /mcp/skill 200) and says the scopes test's fake bridge has no resumeRun, so it counts 11 tools. (3) variants[2] omitted resume_run, which the same actions:execute scope grants. Re-read at base fd246c22: packages/mcp/src/mcp-http-tools.ts registerActionTools (canResume, 'the same actions:execute scope grants both'), mcp-http-tools.scopes.test.ts ACTION_TOOLS. No clause changed",
           "ref": "#25807"
         },
-        { "revision": 8, "date": "2026-10-31", "change": "acceptance[4] names its transport. Checklist-accuracy finding of QA run #27409 (18.3.0 sweep, wave 3, Tier 1 half A, at c4c515ad; sweep anchor #27377): the HTTP door listed the twelve, while the stdio door on the same build listed 9 with no action family, and the clause did not say which door 'the documented twelve' meant. It now names /api/v1/mcp and says why stdio serves 9. Re-read at base 488b3ed0: packages/mcp/src/mcp-http-tools.ts wireBridgeTools (the action pair registers only when the bridge implements listActions and runAction), packages/mcp/src/stdio-data-bridge.ts createStdioDataBridge (an McpDataBridge, no action methods). The HTTP assertion is unchanged", "ref": "#27409" }
+        { "revision": 8, "date": "2026-10-31", "change": "acceptance[4] names its transport. Checklist-accuracy finding of QA run #27409 (18.3.0 sweep, wave 3, Tier 1 half A, at c4c515ad; sweep anchor #27377): the HTTP door listed the twelve, while the stdio door on the same build listed 9 with no action family, and the clause did not say which door 'the documented twelve' meant. It now names /api/v1/mcp and says why stdio serves 9. Re-read at base 488b3ed0: packages/mcp/src/mcp-http-tools.ts wireBridgeTools (the action pair registers only when the bridge implements listActions and runAction), packages/mcp/src/stdio-data-bridge.ts createStdioDataBridge (an McpDataBridge, no action methods). The HTTP assertion is unchanged", "ref": "#27409" },
+        { "revision": 9, "date": "2026-11-08", "change": "acceptance[4].clause and .verify name the HTTP tool set as 15: delete_records, read_file and create_upload_link joined the 12 it listed, and the stdio door serves 10 (its former 9 plus delete_records). Checklist-accuracy finding of QA run #31486 (owed:weekly, at 0647dabb): tools/list answered 15 on a keyed session. Read at base 4894cfe1", "ref": "#31499" }
       ]
     },
     {
 
@@ -1030,7 +1030,7 @@
       "title": "A field's declared accept/maxSize is re-enforced SERVER-SIDE on record write — the control the client widget check explicitly is not — with the declared missing-metadata and dotless-extension holes scored as documented boundaries",
       "since": "v17",
       "status": "active",
-      "revision": 7,
+      "revision": 8,
       "priority": "P1",
       "surface": "api",
       "personas": ["seeded admin (admin@objectos.ai) — the check is a declaration constraint, not an authz gate: it binds every caller identically, so no restricted persona is needed"],
@@ -1039,7 +1039,7 @@
         "requires": [
           "the qamedia_media scratch object with field-level accept/maxSize (see provisioning) — no stock showcase object declares either",
           "the storage service live at the default base — presign/complete is how the probe sys_file rows are minted, and their mime_type/size are the DECLARED values the check reads (packages/services/service-storage/src/storage-routes.ts#registerStorageFamily: its POST /storage/upload/presigned handler persists the pending sys_file row with the declared mimeType and size)",
-          "a system-write channel to CLEAR mime_type and size on one committed sys_file row for the missing-metadata clause — the presign door refuses a body without mimeType/size (400 INVALID_REQUEST, storage-routes.ts), so a metadata-less row cannot be minted through the API; without the system write that one clause is blocked(fixture)"
+          "a system-write channel to CLEAR mime_type and size on one committed sys_file row for the missing-metadata clause — the presign door refuses a body without mimeType/size (400 INVALID_REQUEST, storage-routes.ts), so a metadata-less row cannot be minted through the API. Since #27399 the data door cannot be that channel either: a PATCH of mime_type / size through /api/v1/data/sys_file answers 200 and changes nothing. Name a direct database write: an UPDATE of the sys_file row in the run's own database (for a file DB, node:sqlite against the OS_DATABASE_URL file). Without the system write that one clause is blocked(fixture)"
         ],
         "provisioning": {
           "use": "qa-media-constraints",
@@ -1135,6 +1135,12 @@
           "date": "2026-10-28",
           "change": "steps[1](B), steps[5] and negative[3] corrected. Checklist-accuracy findings of the 18.2.0 wave 2 (QA run #26476, manual api set, at 756220c4; wave anchor #25807, slice B). (1) steps[1](B) said the bytes need not match the declared size; since #24548 upload/complete answers 409 when the backend's bytes differ from the declared size, so B must carry its 2097152 bytes. (2) steps[5] offered PUT, which a record answers 405. (3) negative[3] said an unknown id passes untouched; since #26043 a write with a caller refuses it 400 VALIDATION_FAILED, the same answer as an unreadable file. Re-read at base fd246c22: packages/services/service-storage/src/storage-routes.ts heldBytesRefusal (getInfo size against the declared size), file-reference-lifecycle.ts findReferenceableFile ('refused' for an id the lookup cannot see when a caller is asked). The run's recipe line (media_qa_media, 422 NAMESPACE_PREFIX) is already closed by revision 6 (#26876, qamedia_media). The negative still says the probe measures nothing; only the reason changed",
           "ref": "#25807"
+        },
+        {
+          "revision": 8,
+          "date": "2026-11-08",
+          "change": "fixtures.requires[2] names a direct database write as the system-write channel: since #27399 a PATCH through the data door answers 200 and changes nothing. Checklist-accuracy finding of QA run #31486 (owed:weekly, at 0647dabb). Read at base 4894cfe1",
+          "ref": "#31499"
         }
       ]
     },
@@ -1252,7 +1258,7 @@
       "title": "Chunked upload integrity on v18: complete with a missing chunk is 409 with details.missingChunks and the session stays in_progress, a re-sent chunk counts once, parallel chunks all record, and an org switch mid-upload answers 409 on chunk and complete, and on progress only once the session's expiry stamp is due",
       "since": "v18",
       "status": "active",
-      "revision": 8,
+      "revision": 9,
       "priority": "P2",
       "surface": "api",
       "personas": [
@@ -1264,7 +1270,8 @@
           "a fresh boot of the showcase: `pnpm dev -- --fresh -p PORT --seed-admin` (ephemeral DB; the seeded admin is printed)"
         ],
         "knownGaps": [
-          "CLOSED for the pin half: packages/plugins/organizations/src/storage-upload-organization-change.wall.test.ts now drives the CHUNKED doors after an organization switch over a booted wall (chunk PUT 409, chunked complete 409, progress 200 on a live session and 409 when its expiry stamp is due), so the door-level 409 of acceptance[3] is pinned at http-in-process and the automated.ref names it. The guard is the doors' shared requireStartingOrganization (packages/services/service-storage/src/storage-routes.ts, asking packages/services/service-storage/src/metadata-store.ts#organizationOutOfWriteReach). acceptance[3]'s live leg, steps[3], needs a second organization the admin can make active. A stock boot holds one: POST /api/v1/auth/organization/create answers 403 ORGANIZATION_CREATION_DISABLED on every boot whose posture enforces no wall (packages/plugins/plugin-auth/src/auth-manager.ts#ORGANIZATION_CREATION_DISABLED_CODE; QA runs #24560 / #24558). On 18.0.0, where 18.x step 4 (#24580) has deleted the walled boot refusal that of the published prereleases only 18.0.0-next.5 carries, a walled boot provisioned per RUNNER.md's environment-facts entry 'A walled boot is a fixture of its own' creates it through that same door (RUNNER.md 'A stock `single` boot holds exactly one organization, and no door mints a second; a walled boot mints them through the auth API'). A run that provisions neither records acceptance[3] blocked(fixture) naming those entries, never fail. Such a run scores the guard from the wall pin alone; a run that stages the second organization with a system write, as QA run #24560 did, scores a fixture of its own making and records that its verdict rests on it"
+          "CLOSED for the pin half: packages/plugins/organizations/src/storage-upload-organization-change.wall.test.ts now drives the CHUNKED doors after an organization switch over a booted wall (chunk PUT 409, chunked complete 409, progress 200 on a live session and 409 when its expiry stamp is due), so the door-level 409 of acceptance[3] is pinned at http-in-process and the automated.ref names it. The guard is the doors' shared requireStartingOrganization (packages/services/service-storage/src/storage-routes.ts, asking packages/services/service-storage/src/metadata-store.ts#organizationOutOfWriteReach). acceptance[3]'s live leg, steps[3], needs a second organization the admin can make active. A stock boot holds one: POST /api/v1/auth/organization/create answers 403 ORGANIZATION_CREATION_DISABLED on every boot whose posture enforces no wall (packages/plugins/plugin-auth/src/auth-manager.ts#ORGANIZATION_CREATION_DISABLED_CODE; QA runs #24560 / #24558). On 18.0.0, where 18.x step 4 (#24580) has deleted the walled boot refusal that of the published prereleases only 18.0.0-next.5 carries, a walled boot provisioned per RUNNER.md's environment-facts entry 'A walled boot is a fixture of its own' creates it through that same door (RUNNER.md 'A stock `single` boot holds exactly one organization, and no door mints a second; a walled boot mints them through the auth API'). A run that provisions neither records acceptance[3] blocked(fixture) naming those entries, never fail. Such a run scores the guard from the wall pin alone; a run that stages the second organization with a system write, as QA run #24560 did, scores a fixture of its own making and records that its verdict rests on it",
+          "acceptance[3] needs a second organization, and a single stock boot cannot make one: QA run #31486 (owed:weekly, at 0647dabb) met create organization → 403 ORGANIZATION_CREATION_DISABLED and scored it blocked(fixture). The walled group boot (OS_TENANCY_POSTURE=group) that run's C3a slice provisioned would serve it; access-security.no-active-org-session-semantics (blocked, #9334) needs the same boot"
         ]
       },
       "steps": [
@@ -1355,6 +1362,12 @@
           "date": "2026-10-28",
           "change": "knownGaps[0], acceptance[0] and automated.ref follow the chunked-door wall pin. Checklist-accuracy finding of the 18.2.0 wave 2 (QA run #26468, Tier 1 half A, at 756220c4; wave anchor #25807, slice B): knownGaps[0] said no file drives a chunked door after an organization switch, but packages/plugins/organizations/src/storage-upload-organization-change.wall.test.ts pins the chunk PUT 409, the chunked-complete 409, progress 200 and the progress-with-due-expiry 409 over a booted wall. The file joins the ref, knownGaps[0] is closed for the pin half (its live-leg fixture text is kept), and acceptance[0]'s 'no chunked-door pin' sentence is replaced. Re-read at base fd246c22 (the wall file's chunk-PUT, chunked-complete and progress cases). No clause's assertion changed",
           "ref": "#25807"
+        },
+        {
+          "revision": 9,
+          "date": "2026-11-08",
+          "change": "fixtures.knownGaps gains acceptance[3]'s second-organization fixture gap and the group boot that would serve it. Coverage gap of QA run #31486 (owed:weekly, at 0647dabb). Read at base 4894cfe1",
+          "ref": "#31499"
         }
       ]
     }