@@ -283,10 +283,14 @@ contradicts it, and correct it here when it does.
   before scoring any connector clause, prove where the live dispatch lands: create a
   `showcase_task`, read the `showcase_declarative_connector_ping` run it fires, and confirm
   it completed with a `ping.body` whose uptime matches THIS boot, not another server's.
-  ⛔ Do not read the instance metadata for it: `os dev` boots the prebuilt
-  `dist/objectstack.json` unless `--compile` is passed (`packages/cli/src/commands/dev.ts`),
-  so `GET /api/v1/meta/connector/showcase_status_api`'s `item.providerConfig.baseUrl` can
-  carry the build-time value. QA run #25817 at `6679644a` measured it: with `OS_PORT=41302`
+  ⛔ Do not read the instance metadata for it: an `os dev --no-compile` boot serves the
+  existing `dist/objectstack.json` as built, so `GET /api/v1/meta/connector/showcase_status_api`'s
+  `item.providerConfig.baseUrl` can carry the build-time value. Since #26130 a default
+  `os dev` compiles the config under the boot's own environment first
+  (`packages/cli/src/commands/dev.ts`, the `compile` flag, default on), so on a default
+  boot that read can follow an exported `OS_PORT` — the dispatch check above stays the
+  proof on either boot. Before #26130 `os dev` booted the prebuilt artifact unless
+  `--compile` was passed, and QA run #25817 at `6679644a` measured that old default: with `OS_PORT=41302`
   exported, that read still answered `http://127.0.0.1:3000`, while the live
   `connector_action` reached 41302 (`ping.body` uptime matched the boot, and nothing
   listened on 3000) — so the metadata read misreports the fixture in both directions.
@@ -347,6 +351,23 @@ contradicts it, and correct it here when it does.
   wrote a CRM manifest there for 25 s before removing it through
   `DELETE /api/v1/marketplace/install-local/<id>` (#23163).
 
+- **A per-boot `-d file:…` database does NOT isolate the showcase's upload root or its
+  external datasource either — the same class as the install-local entry above.** Two
+  more paths resolve against the server's working directory: the local storage root,
+  whose settings-manifest default is `./.objectstack/data/uploads` unless
+  `OS_STORAGE_LOCAL_ROOT` is exported (only `--fresh` sets it, to its own temp home:
+  `packages/cli/src/commands/dev.ts`), and the showcase's external datasource file
+  `.objectstack/data/showcase_external.db`
+  (`examples/app-showcase/src/system/datasources/showcase-external.datasource.ts`). So a
+  tree boot with only `-d` writes uploads into `examples/app-showcase/.objectstack/data/uploads/`
+  and creates `showcase_external.db` beside it, and even a boot that writes neither leaves
+  `.objectstack/data/` behind, empty. All of it is git-ignored, so a clean `git status` is
+  no evidence (QA runs #26456, #26476 and #26481 met all three). **Fix:** export
+  `OS_STORAGE_LOCAL_ROOT=/tmp/RUN/uploads` beside `OS_PORT` for any item that uploads, and
+  boot from a scratch copy of the app for any item that writes the external datasource.
+  An empty `.objectstack/data/` left by a tree boot is harmless and is not the
+  installed-packages trap.
+
 - **`ss` is not installed in these containers — read liveness with `curl`, never a socket
   table.** `ss` and `netstat` are both absent (`command not found`); `lsof` and `fuser`
   are present. The trap is that the usual spelling hides the cause: `ss -ltn | grep`
@@ -376,6 +397,11 @@ contradicts it, and correct it here when it does.
   read the group from the listener, `PGID=$(ps -o pgid= -p "$(lsof -ti tcp:PORT)" | tr -d ' ')`;
   stop it with `kill -TERM -- -$PGID`, and confirm `lsof -ti tcp:PORT` then prints nothing.
   ⛔ Never stop a server by name (`pkill`), and never a group you did not start.
+  ⚠️ Run that stop as a command of its own: the repo's PreToolUse hook
+  `.claude/hooks/guard-process-kill.sh` refuses any one Bash command that runs `ps` and
+  `grep` and also kills, judged over the whole command rather than per pipeline (its
+  header says why), so a stop chained after a `ps … | grep` look at the process table is
+  refused although its `kill` is group-scoped (QA run #26476 met it).
 
 - **Console session auth is a bearer token in `localStorage`, and a form sign-in ALSO
   sets a cookie — you need both halves.** The console's auth client stores the session
 
@@ -8,7 +8,7 @@
     "qa-contributor-bound-member": {
       "title": "A CONTRIBUTOR-BOUND member — an identity that reads a strict SUBSET of showcase_invoice rows (invited sign-up + one sys_user_position row)",
       "why": "Both-sides RLS needs a persona for whom a specific row is invisible while the object itself is readable. ⚠️ Neither seeded demo persona is that persona, and reaching for them is the trap this recipe closes — measured on 17.1.0 (#10257): Mei (phone.demo@example.com) holds NO position, so showcase_contributor never merges and showcase_invoice answers PERMISSION_DENIED — the OBJECT gate, no rows at all, not a subset; Ada (auditor.demo@example.com) holds `auditor` → showcase_auditor, which carries `showcase_invoice: { allowRead: true, viewAllRecords: true }` — VAMA bypasses record scope entirely, so she sees all 12 — also not a subset. The persona that IS a subset is a member bound to the `contributor` position: showcase_contributor grants read/create/edit on showcase_invoice while the `invoice_own_rows` RLS narrows selects to `owner == current_user.email`, and none of the seeded invoices are owned by a fresh sign-up. Nothing here needs a seed change or a repo file — the whole gap was that the recipe existed only as prose on one item, which is why a runner reached for the demo personas instead and recorded blocked(fixture).",
-      "provenance": "run #7629 (framework, 2026-08-11) drove search.rls-both-personas to 4/4 PASS on exactly this persona — 3 invoices visible to the member vs 15 to admin. Promoted from prose on that one item to a replayable area recipe by the 17.1.0 sweep (#10236 B1); the Mei/Ada measurements above are from #10257. Step 1 re-pointed invite-first by #21060 after QA run #21056 met the invite_only default (403 SELF_REGISTRATION_CLOSED on an uninvited sign-up). Step 5's body gained the `owner` it always needed after QA run #23166 met an own-row invisible to its creator (#23169). Steps 2 and 3 name the admin REST doors QA run #24574 measured (an admin GET of sys_user by email and an admin POST of sys_user_position, the position as plain text), and step 5 names the invoice number field `name`, after that run met 400 INVALID_FIELD on `number` and #24593 met 400 on an OData `$filter` (wave anchor #24579, PR #24671).",
+      "provenance": "run #7629 (framework, 2026-08-11) drove search.rls-both-personas to 4/4 PASS on exactly this persona — 3 invoices visible to the member vs 15 to admin. Promoted from prose on that one item to a replayable area recipe by the 17.1.0 sweep (#10236 B1); the Mei/Ada measurements above are from #10257. Step 1 re-pointed invite-first by #21060 after QA run #21056 met the invite_only default (403 SELF_REGISTRATION_CLOSED on an uninvited sign-up). Step 5's body gained the `owner` it always needed after QA run #23166 met an own-row invisible to its creator (#23169). Steps 2 and 3 name the admin REST doors QA run #24574 measured (an admin GET of sys_user by email and an admin POST of sys_user_position, the position as plain text), and step 5 names the invoice number field `name`, after that run met 400 INVALID_FIELD on `number` and #24593 met 400 on an OData `$filter` (wave anchor #24579, PR #24671). Step 5 asks for a non-churned account after QA run #26456 (wave anchor #25807) met the first listed account churned and the invoice POST refused 400.",
       "app": "showcase",
       "requires": [
         "a stock dev boot — the `contributor` position declares `showcase_contributor` in its `permissionSets` (examples/app-showcase/src/security/positions.ts), which the resolver reads by name (ADR-0131 D3/D4). ⛔ Do NOT hand-create a sys_position_permission_set row: no resolver reads it, so it proves nothing about the merge",
@@ -45,7 +45,7 @@
         {
           "step": 5,
           "call": "give the member a row of their OWN: as the member, POST /api/v1/data/showcase_invoice with `owner` set to the member's OWN email (the step-1 address) — contributors hold allowCreate",
-          "expect": "2xx, and that row IS visible to them on a re-read — turning the subset from empty into a proper non-empty one. This is what makes the restriction provably SUBTRACTIVE rather than a blackout; without it, zero-hits and no-access are indistinguishable. ⚠ The body MUST carry `owner: '<the member's email>'`: invoice_own_rows narrows SELECT to owner == current_user.email, and `owner` is a plain text field with no default (examples/app-showcase/src/data/objects/invoice.object.ts), so an invoice the member creates WITHOUT it lands 2xx and is then invisible to its own creator — reading exactly like a blackout (QA run #23166). The invoice number is the required `name` field (there is no `number` field: a body naming `number` answers 400 INVALID_FIELD, QA run #24574); `status` may be omitted (its 'draft' option is default:true). Point the invoice's required `account` at a SEEDED account id (read one from GET /api/v1/data/showcase_account), never at one a consuming item later deletes: a required lookup turns set_null into restrict, so that delete answers 409 DELETE_RESTRICTED (records-forms.crud-roundtrip met it in QA run #21056).",
+          "expect": "2xx, and that row IS visible to them on a re-read — turning the subset from empty into a proper non-empty one. This is what makes the restriction provably SUBTRACTIVE rather than a blackout; without it, zero-hits and no-access are indistinguishable. ⚠ The body MUST carry `owner: '<the member's email>'`: invoice_own_rows narrows SELECT to owner == current_user.email, and `owner` is a plain text field with no default (examples/app-showcase/src/data/objects/invoice.object.ts), so an invoice the member creates WITHOUT it lands 2xx and is then invisible to its own creator — reading exactly like a blackout (QA run #23166). The invoice number is the required `name` field (there is no `number` field: a body naming `number` answers 400 INVALID_FIELD, QA run #24574); `status` may be omitted (its 'draft' option is default:true). Point the invoice's required `account` at a SEEDED account id whose `status` is not churned (read one from GET /api/v1/data/showcase_account and check it: the first row the list returns can be a churned one, and an invoice against it answers 400 'This account has churned — reactivate it before invoicing.', the invoice object's own validation rule, QA run #26456), never at one a consuming item later deletes: a required lookup turns set_null into restrict, so that delete answers 409 DELETE_RESTRICTED (records-forms.crud-roundtrip met it in QA run #21056).",
           "source": "ContributorPermissionSet.objects.showcase_invoice.allowCreate === true (permission-sets.ts); the seeded owner emails hold no credential, so borrowing a seeded owner is not an option — this is why the own-row is CREATED"
         }
       ],
 
@@ -9,7 +9,7 @@
       "title": "Every user-initiated write answers visibly — success names what changed, a refusal says why, and a no-op claims nothing",
       "since": "v17.7",
       "status": "active",
-      "revision": 6,
+      "revision": 7,
       "priority": "P1",
       "surface": "browser",
       "personas": [
@@ -34,7 +34,7 @@
         "record create — New form save on showcase_task",
         "record inline edit — double-click a Priority cell on the task grid (the grid has no 'Edit inline' button), change it, then Save row or Save All",
         "bulk delete — select two rows → Delete in the selection bar → confirm",
-        "kanban move — drag a card Backlog → To Do (direct manipulation: the card in its new column IS the success feedback; a refused move must revert with an error)",
+        "kanban move — drag a card Backlog → To Do (direct manipulation: the card in its new column IS the success feedback; a move the transition rule blocks never leaves the client — its lane is dimmed, data-kanban-drop-blocked, and the drop sends nothing, #25933)",
         "declared record action — Mark Done on a task record (declared successMessage 'Task marked done.', examples/app-showcase/src/ui/actions/index.ts#MarkDoneAction)",
         "param action dialog — Setup → Users → Invite User → Confirm (declared successMessage 'Invitation sent to ${result.email}')",
         "approval decision — open the request from the approvals page, /_console/apps/com.example.showcase/system/approvals (the 'Approvals inbox' link opens the review-queue page, which is not where the decision is taken). The route has no drawer: opening a request navigates to its record page (sys_approval_request_detail), where the decision is taken → Approve with a comment",
@@ -49,8 +49,8 @@
         "for each variant perform the write once, then within ~2 s capture a screenshot and the DOM of every feedback region — toasts ([data-sonner-toast]), role=status / role=alert regions, and the surface's own save indicator — recording the verbatim text, or its absence",
         "for each variant read server-side whether the write landed (GET the record, the metadata item or the sys_ row) and record the request's status from the network log",
         "repeat the record rows signed in as the member persona, on member-owned records — the stock member's set (showcase_member_default) grants showcase_task read + create only, and the console applies it up front: it offers the member no inline edit, no row selection and no kanban drag, so those three rows cannot be driven as the member (record them as not offered, never as refused). The member's create row runs; for the refusal row use the member's Mark Done on a task record, which answers 403 PERMISSION_DENIED (its error feedback is clause 3's to score). To drive the edit rows as a member, bind the member to the contributor position (showcase_contributor grants task edit, not delete)",
-        "negative pass: (a) submit the create form with a required field empty; then break a validation rule — showcase_task's only rule is the UPDATE-time state machine task_status_flow (no create-time rule exists), so drive it as a refused transition, e.g. a kanban move Backlog → Done; (b) open an inline editor and leave it without changing the value",
-        "where a variant offers Undo, click it and read the record back — on stock the import does (knownGaps[3]): run the two-row CSV import as a job, once creating and once updating, then 'Undo import' from the import history and read the rows back"
+        "negative pass: (a) submit the create form with a required field empty; then break a validation rule — showcase_task's only rule is the UPDATE-time state machine task_status_flow (no create-time rule exists), so drive it as a refused transition, Backlog → Done, on the record form or an inline status edit. ⛔ Not the kanban: the drop gate (#25933, ui/packages/plugin-kanban/src/KanbanImpl.tsx) dims a lane the transition rule blocks (data-kanban-drop-blocked) and a drop there sends no request, so no refusal reaches the server; record the dimmed lane as that surface's answer; (b) open an inline editor and leave it without changing the value",
+        "where a variant offers Undo, click it and read the record back — on stock the import does (knownGaps[3]): run the two-row CSV import as a job, once creating and once updating, then 'Undo import' from the import history — it asks through the browser's native window.confirm (ui/packages/plugin-grid/src/ImportWizard.tsx), unlike Studio discard's in-app dialog, so a driver accepts it as a dialog event — and read the rows back"
       ],
       "acceptance": [
         {
@@ -62,7 +62,7 @@
         {
           "clause": "success feedback names its subject: a record-level write names the record or item (its title, label or display name) or the count; a singleton page (settings) and a named automation (e.g. Flow \"X\" completed) are their own subject and pass as they are; a bare 'Success' / 'Done' or a machine name never passes",
           "oracle": "screenshot",
-          "verify": "two steps per row. First classify the write: record-level (a record create, edit or delete, the import, the approval decision, a record or param action, a Studio item) or singleton / named automation (the settings save, a named Flow run). Then score it by that class's test. Record-level: PASS when the captured text names the record or item (record title or display name, invitee email, package or item label, e.g. 'Approved \"EXP-2001\"') or the count ('N created · M skipped', '1 row saved'); text that names only the object ('Task created successfully') scores FAIL — the console's record create and edit toasts read that way until ui card #26172 lands, so those rows are expected FAILs that cite it. Singleton / named automation: PASS when the text names that page or automation ('Settings saved', 'Flow \"Reassign Task\" completed'). In either class a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row",
+          "verify": "two steps per row. First classify the write: record-level (a record create, edit or delete, the import, the approval decision, a record or param action, a Studio item) or singleton / named automation (the settings save, a named Flow run). Then score it by that class's test. Record-level: PASS when the captured text names the record or item (record title or display name, invitee email, package or item label, e.g. 'Approved \"EXP-2001\"') or the count ('N created · M skipped', '1 row saved'); text that names only the object ('Task created successfully') scores FAIL — the console's record create and edit toasts read that way until #26172 (the dialog paths) and #26461 (the full-page /new and /edit form route) — both closed fixed, so those rows are now expected PASS, and a toast naming only the object is a regression. Singleton / named automation: PASS when the text names that page or automation ('Settings saved', 'Flow \"Reassign Task\" completed'). In either class a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row",
           "evidence": "the verbatim feedback strings"
         },
         {
@@ -141,6 +141,12 @@
           "date": "2026-10-26",
           "change": "acceptance[1] clause and verify reworded to the maintainer's ruling on the object-only success strings QA run #25817 (release-18.2.0-manual-set at 6679644a, objectui pin b41ed7f68956) asked about: ruling comment 6417978207 on #25849, letter C — a record-level write names the record (its title) or the count; a singleton page (settings) and a named automation (Flow \"X\" completed) are their own subject and pass as they are, and the clause states that boundary. verify now classifies each row (record-level, or singleton / named automation) before scoring it by that class's test. Not loosened: a generic 'Success' / 'Done' or a machine name still FAILS, and a record-level toast that names only the object ('Task created successfully') is an expected FAIL until the ui card #26172 lands. The 2026-10-07 instruction the clause rests on (every write has feedback; no machine names) is unchanged in meaning",
           "ref": "#25849"
+        },
+        {
+          "revision": 7,
+          "date": "2026-10-27",
+          "change": "steps[4], variants[3], acceptance[1].verify and steps[5] follow the console at the wave-2 head. Checklist-accuracy findings of the 18.2.0 wave 2 (QA run #26456, release-18.2.0-w2-manual-browser, at 756220c4; wave anchor #25807, slice A): the kanban refused-transition leg is no longer drivable (the #25933 drop gate dims a blocked lane and a drop sends nothing), the record create/edit rows are no longer expected FAILs (#26172 and #26461 both closed fixed), and the import Undo confirms through window.confirm. Re-read at base e4ba846f (KanbanImpl.tsx data-kanban-drop-blocked; ImportWizard.tsx undo confirm). The dimmed lane carries no reason text; that is reported on the wave anchor as an observation, not edited here. No clause's assertion changed",
+          "ref": "#25807"
         }
       ]
     },