Step 22: four decisions folded in

Repo defaults allowed in the home file, but only inside an explicit
defaults: block, merged below every repo's own layers (accepted cost:
secrets may live in two places). Registry wins over cwd when a home
config exists. Repo names default to the directory basename,
overridable per registry entry, duplicates abort loudly. The file name
stays .werkator.yml in all three locations — the location carries the
meaning.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/plan/22-multi-repo.md

@@ -25,7 +25,10 @@ Consequences:
 
 Today all config comes from the repo's own layers; multi-repo splits ownership:
 
-- **Instance-level** (decided 2026-09-01: a `.werkator.yml` in the *home directory* of the user running the instance): `server.*` (port, bind address, public base URL / domain, nginx), the repository registry, the control token (one UI, one token), `executor.maxConcurrent` as the *global* cap, watcher interval, metrics.
+- **Instance-level** (decided 2026-09-01: a `.werkator.yml` in the *home directory* of the user running the instance — the name stays `.werkator.yml` in all three locations, the location carries the meaning): `server.*` (port, bind address, public base URL / domain, nginx), the repository registry, the control token (one UI, one token), `executor.maxConcurrent` as the *global* cap, watcher interval, metrics.
+- **Repo defaults** (decided 2026-09-01): the home file MAY carry defaults for repo-level keys (e.g. one `git.account`/`git.token` for all repos of the same forge), in an explicit `defaults:` block so instance keys and repo defaults never blur syntactically.
+  The block merges BELOW every repo's own layers: home `defaults` → committed project config → repo machine config → branch layer (pinning semantics unchanged — home and repo machine config are both host-side layers, the branch layer still cannot reach pinned keys).
+  Accepted cost: secrets may then live in two places; a repo without its own secrets is no longer self-contained on its own.
 - **Repo-level** (unchanged, from the repo's own layers — machine config in its `.git/werkator/`, committed project config, branch layer): `gitea.*` (each repo has its own owner/repo/token/statusContext), `git.*` credentials, `builds`, retention, per-repo watcher options (e.g. `pullRequestGate`), sandbox policy and its pinning.
 - **Both**: a per-repo concurrency cap below the global one may come later; not in the first cut.
 
@@ -40,7 +43,8 @@ The pinning model is untouched: pinned keys still come from each repo's machine
 - Define the instance config: `~/.werkator.yml` (decided 2026-09-01) — the repository registry plus the instance-level keys above; one instance per OS user, which matches the platform model (pac users on a webspace, service users elsewhere).
   `werkator server` without a home config serves the current directory exactly as today.
 - Decide the transition for instance keys that today sit in a repo's machine config (mih34's carries `server.*`): once a home config exists, repo-level instance keys are ignored with a warning naming both files — never merged silently.
-- Define repo identity for display and routes: a short unique name per registry entry (default: directory basename), used as the route segment (`/repos/<name>/…`) and UI grouping key.
+- Repo identity for display and routes (decided 2026-09-01): a short unique name per registry entry, defaulting to the repository's directory basename, overridable in the entry; duplicate resulting names abort the start loudly. Used as the route segment (`/repos/<name>/…`) and UI grouping key.
+- Precedence (decided 2026-09-01): when a home config with a registry exists, `werkator server` serves the registry regardless of the current directory — one user, one instance, deterministic; without a home config it serves the current directory exactly as today.
 - Update `docs/Werkator-Konzept.md` and AGENTS.md wording ("one instance per repository set").
 
 ### B — RepoContext refactor, behavior unchanged
@@ -70,11 +74,6 @@ The pinning model is untouched: pinned keys still come from each repo's machine
 
 ## Open Questions
 
-- May `~/.werkator.yml` also carry *repo defaults* (e.g. one `git.account`/`git.token` for all repos of the same forge), merged beneath every repo's own layers — or is it strictly instance-only?
-  Defaults are convenient but widen where secrets live; strictly-instance-only keeps the "repository stays self-contained" property clean.
-- What wins when `werkator server` is started inside a repository while a home config exists — the registry, the cwd, or is that an error demanding an explicit flag?
-- Repo names for routes and display: registry-entry name with directory-basename default — or always explicit?
-- The same file name `.werkator.yml` now exists in a third location (home, repo root committed, repo `.git/werkator/`) — accept the overload, or name the home file differently (e.g. `~/.werkator-instance.yml`)?
 - Fairness across repos when the global concurrency cap is contended (round-robin per repo vs. FIFO) — decide in session C with the real queue behavior at hand.
 - Whether buildenv rootfs trees should be shared across repos (today each repo unpacks its own under `.git/werkator/buildenv/`) — the natural answer is Werkdock's image store (step 21 session C), not instance-level state; until then duplicate unpacked rootfs trees are the accepted cost.
 - Whether `artifactKey` needs a repo prefix or stays globally unique by construction (random suffix) — decide in session B when the routes are designed.