Record the ninja 1.12.1 finding and the product-directory rule

Author: speak-agent

.agents/docs/2026-09-29-workspace-build-graph-design.md

@@ -523,6 +523,8 @@ left open, the answer is recorded here.
 | Tests | `mcpp test` keeps one plan per member (`-p X` each), in the shared directory; the members' dev-dependencies are their own. | cmd_build.cppm |
 | Concurrency | Groups are planned in turn and built on threads with a static share of the jobs; the `.build_cache` write is one locked step. | cmd_build.cppm |
 | The orders of `mcpp.graph` | Three: the stable order, the module graph's own (Kahn with the ready units on a stack, over the edges in their recorded order) and a depth-first post-order from roots in the given order. Each migrated site keeps the order it had: the module graph's unit order is the order of the objects on a link line, which Mach-O uses as initializer order, and the first migration to the stable order made openkal's `same-source` example crash at start on aarch64-macos from all three build hosts (CI, run 36486818199). With the orders restored, the link line of that example is byte-identical to 2026.9.28.3's. | modules/graph |
+| ninja 1.12.1 and a shared directory | A directory is now reused by graphs of other dependency sets, and re-staging a cached dependency while the scans are current crashed ninja 1.12.1: it loads the importer's dyndep file inside the completion of the staged BMI, and the load grows the list that completion iterates (ninja-build/ninja#2662, a use-after-free; the fix, ninja-build/ninja#2840, is unmerged). Measured on e2e 196 under gcc; ninja 1.13.2 happened not to crash on the same state. The staged cache is placed by a ninja pass of its own, so the graph that reads it starts with it current and loads those dyndep files when it starts. | ninja_backend.cppm |
+| `bin/` in a workspace plan | Products only: the workspace's own package's and each member's directory. A program shipped through `artifacts` is linked among its package's intermediate files and placed in each member's directory whose closure asks for it (a member named like the program otherwise took the program's path as its directory, e2e 833 G8). A file that would take a product directory's path is refused. | plan.cppm |
 | Module names across members | A graph has one module namespace (BMIs are found by name), so two members that each provide a module of one name are refused in one `--workspace` plan, as two `artifacts` programs are (#732, which tracks per-provider BMI names). Measured over the package index's 172 members: no module name is provided twice. | scanner |
 
 Readings with the implementation (Linux, llvm 22.1.8):

CHANGELOG.md

@@ -77,6 +77,11 @@ to 2026.9.29.1.
   beside several programs is one file with several names where the file system
   supports links, and a copy elsewhere. Other deployed files are copied, since
   a program may write a file beside itself (e2e 835).
+- **Files served from the global cache are staged by a ninja pass of their
+  own**, before the build that reads them. ninja 1.12.1 crashed when a cached
+  dependency was staged again in a directory whose scans were current
+  (ninja-build/ninja#2662); a directory named by its configuration makes that
+  the ordinary case of a dependency upgrade.
 - **The fast path records the request.** `build.ninja` states the workspace
   members and the features it was planned for, and a fast path replays it only
   for the same request; one record is kept per selection and configuration.