ADR-first greenfield: deciding the load-bearing architecture before the first feature

## Spark

The busiest repo in the 2026-07-05→07-12 digest window was brand new: partir.qua.world, a Haskell game engine / GUI client (13 commits, 17 PRs, 25 issues in one week). What stands out isn't the volume — it's the sequencing. Toolchain first (GHC 9.10, Travis→Actions; #30/#37), then a pure `Partir.World.*` domain extraction (#38), then a wall of architecture-decision issues opened *before* feature work.

## Why it could be interesting

A methodology piece: resolving the load-bearing architecture up front, ADR by ADR, on a greenfield repo — effect system (#43), world-store ECS vs pure `Map` (#41), fixed-timestep vs FRP substrate (#40), build system buck2 vs Bazel vs native cabal/rebar3 (#60), publication/packaging (#36). Most "how I start a project" posts show scaffolding; this shows the decision graph you resolve before the first feature, and why front-loading those choices is cheaper than retrofitting them into a running system.

## Open questions

- [ ] How-to (a repeatable greenfield checklist) or explanation (why ADR-first beats decide-as-you-go)?
- [ ] Is Haskell+games too niche a vehicle, or is the specificity the appeal?
- [ ] Does this overlap "Personal repos as a fleet" (#128) enough to be one post, or is greenfield-bootstrap a distinct angle from fleet-standardization?
- [ ] Failure mode to address: ADR-first can slide into analysis-paralysis. Where's the line?

## Source material

- qua-world/partir.qua.world: #30/#5 (GHC 9.10 modernization) · #37/#6 (Travis→Actions) · #38/#10 (pure `Partir.World.*` domain) · #39/#8 (`Partir/Client/GLUT` namespace) · ADRs #40 (simulation-stepping FRP) · #41 (world-store ECS) · #43 (effect system) · #46 (client/server) · #60 (build system) · #36 (publication) · #47–#49 (Yarn dialogue → NPC-client pipeline)