plans: Case 2 row briefs from Gosalyn's a2d94b2c2 (Webby r9 notes, webby-0032: row A README line on claude-session.env and the dist/providers/data/zai.json path, C2-13 XDG_DATA_HOME precheck and last-assignment-wins key file parse)

docs/plans/2026-10-20_case2-rows.md

@@ -770,6 +770,10 @@ The precheck refuses unless all of these hold:
 - The business file, `.history`, `changes.jsonl` and persona files have the modes in design 4, and
   each persona digest matches.
 - The run root is 0700.
+- `XDG_DATA_HOME` is unset or is `<home>/.local/share`. `copy_root` reads the copies dir from it
+  (`scripts/stack-copy.sh:6`), and the unit fixes `<home>/.local/share`, so any other value would
+  put the copy where the unit refuses it (webby-0032 N2). A test sets it elsewhere and the precheck
+  refuses.
 - `node --version` is 24 or later, because every package's `engines` field says `>=24` (row 195: .53
   has v22.22.2).
 - `bwrap --unshare-all --ro-bind / / true` exits 0 as `<user>`. Without it no session starts. Row 195
@@ -780,7 +784,8 @@ The precheck refuses unless all of these hold:
   With design r9's model path, Bean and Chet run pi, so this check is skipped unless she adds a
   claude-code specialist.
 - When an instance's provider is `zai`, `<configDir>/secrets/claude-session.env` exists, is a regular
-  file owned by `<user>` at 0600, and sets a nonempty `ZAI_API_KEY` (design 10 step 2d). A pi launch
+  file owned by `<user>` at 0600, and sets a nonempty `ZAI_API_KEY` (design 10 step 2d). It parses the
+  file the way systemd does, so the last assignment of a name wins (webby-0032 N3). A pi launch
   has no credential check, so without this the first turn is where a missing key shows. The precheck
   prints the name and never the value.
 - `library.sync` fetches her repo read-only, and `library.status` lists R-problems.
@@ -791,7 +796,8 @@ It also prints free memory and verifies HOME is `/srv/mosaic`.
 Tests run against a scratch data root and a local bare repo. Each precheck refusal has a case. The
 claude check runs against a fake claude that appends rather than replaces, and that case refuses. With
 no claude-code instance the claude check doesn't run, and a test shows a missing claude passes. The key
-file refuses when missing, at 0644, a symlink, or with `ZAI_API_KEY=` empty. A search of the test
+file refuses when missing, at 0644, a symlink, with `ZAI_API_KEY=` empty, and with `ZAI_API_KEY=x`
+followed by `ZAI_API_KEY=`. A search of the test
 output for the fixture key value finds nothing.
 `case2-unit.sh` runs against a scratch unit directory. These cases refuse:
 - an installed unit edited to `User=root`
@@ -861,7 +867,7 @@ Dewey runs the script and approves. It is green on Sage's gate with every `scrip
 ### Problem
 
 For 10-27, Bean and Chet both run pi with provider `zai` on `glm-5.3` (Q186, mos-1090, sage-1469). Pi
-reads the zai key from `ZAI_API_KEY` (pi-ai `env-api-keys.js:89`, with `glm-5.3` in `data/zai.json`).
+reads the zai key from `ZAI_API_KEY` (pi-ai `env-api-keys.js:89`, with `glm-5.3` in `dist/providers/data/zai.json`).
 `ENV_ALLOW` (`packages/seat/src/session.mjs:83-88`) doesn't hold that name, so `sessionEnv` (`:97-99`)
 drops it. A pi launch has no credential check (`packages/plugins/harness/pi/index.mjs:42`
 `countsAccount: false`, `packages/cli/src/launcher.mjs:299`), so today a zai role launches and fails at
@@ -885,7 +891,9 @@ its first turn, as `packages/cli/README.md:439-444` says.
 - `packages/cli/README.md`, after "A Pi session gets the same variables through the allowlist." (`:435`),
   one sentence: a Pi session on provider `zai` logs in with `ZAI_API_KEY`, which the allowlist passes. Like
   every allowlist variable, it reaches every session the host starts, Claude Code ones included, and a
-  shell inside any of them can read it.
+  shell inside any of them can read it. A second sentence where the README names
+  `claude-session.env` ("Unit"): the file holds every session provider key, not only Claude's
+  (webby-0032).
 - One test in `session.test.mjs`: `ENV_ALLOW` includes `ZAI_API_KEY`, and
   `sessionEnv({ ZAI_API_KEY: "fixture-zai", ZAI_TOKEN: "t" }, run)` returns `ZAI_API_KEY` with the fixture
   value and no `ZAI_TOKEN`. The existing allowlist test (`:51-59`) stays as it is.