docs: row 325 brief, re-key the Case 1 project to stack (ops-0288, mos-1563, mos-1564)

(cherry picked from commit 60d78e44e1e66cfb506bbae7399abc581729c97e)

docs/plans/2026-10-24_case1-project-key-brief.md

@@ -0,0 +1,47 @@
+# Case 1 business file: project key must match the project file (#414 stage 2)
+
+Written 2026-10-24 by Sage for ops-0288 and Mos's ruling mos-1563.
+
+## Brief: re-key the Case 1 project to stack
+
+**Why.** The .53 stage 2 run on 99930362e stopped at step 8 (ops-0288). `case2-install.sh --profile factory`
+refused with:
+`validate: mosaic business: project file /srv/mosaic/src/mosaic-stack/.mosaic/project.json has id stack, but
+business mosaic-stack declares it as mosaic-stack`. Row 323's `docs/guides/case1-business.mosaic-stack.json`
+keys its one project `mosaic-stack`. The repo's `.mosaic/project.json` has id `stack`, and the loader requires
+the key to equal that id (packages/business/src/cli.mjs:80, packages/cli/src/config.mjs:67). Row 323's test
+missed it because it validates against a scratch root with no project file, which only warns (cli.mjs:74-78).
+
+**Ruling (mos-1563).** Fix the business file. Don't touch the project id: `stack` is read elsewhere.
+
+**What to change.**
+1. In `docs/guides/case1-business.mosaic-stack.json`, rename the `projects` key from `mosaic-stack` to
+   `stack`. Keep its `root` (`/srv/mosaic/src/mosaic-stack`). Business id stays `mosaic-stack`. Change nothing
+   else in the file.
+2. A new test file, `packages/business/tests/case1-project-key.test.mjs`, that validates the committed case1
+   file against the repo's own `.mosaic/project.json`, so a mismatch fails in CI instead of on a host:
+   - read the repo's `.mosaic/project.json` and assert the case1 file has exactly one project whose key equals
+     its `id`;
+   - run the business `validate` path (the same one cli.mjs:80 runs) with that project's root pointed at a
+     scratch copy holding the repo's real `.mosaic/project.json` bytes, and assert it passes with the project
+     reported `valid`, not `absent`;
+   - a negative case: the same run with the key set back to `mosaic-stack` refuses with the cli.mjs:80
+     message.
+3. The one old-test line this change breaks, `packages/business/tests/case1-business-file.test.mjs:70`
+   (`assert.deepEqual(b.projects, { "mosaic-stack": ... })`), changes its key to `stack` and nothing else. This
+   edit has Mos's go (mos-1564, under mos-1272). Don't change any other line of any old test. If another old
+   test reds, stop and report it.
+
+**Gate.** Use `export TMPDIR=$(mktemp -d /mnt/storage/scratch/tmp/XXXXXX)` (BRIEF-TEMPLATE Gate). On my CLEAR
+only: the new test file whole, then the packages/business suite whole. One mutant: set the case1 key back to
+`mosaic-stack`, show the new test red, restore and check the bytes. The cli suite counts from my landing gate.
+
+**Boundaries.** No host action, no .53 contact, no credential reads, no queue writes, no push to refactor.
+Work in a new worktree off refactor at 99930362e or later, on branch `goldie/row325`. Push the branch and
+report the tip, base and manifest to Sage and to the reviewer. Record design choices in
+agents/goldie/work/queue-325/BUILD.md.
+
+**Acceptance.** At a landed commit, `case2-install.sh --business mosaic-stack --business-file
+docs/guides/case1-business.mosaic-stack.json --profile factory` passes step 8's validate against
+`/srv/mosaic/src/mosaic-stack/.mosaic/project.json`, and the new test fails if the key and the project id
+drift apart again.