Release 1.1.0 — one config file, and a process weight you choose

`project.yaml` at the repo root is now the single source of truth for a
project's configuration, replacing `production/stage.txt`,
`production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all
three still read as a fallback; nothing is force-deleted).

**`modes.rigor` — one question instead of six.** `minimal`, `standard` or
`full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`,
`modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to
`minimal`, which is a change from 1.0's behaviour: the heavier tier was
measured costing several times more to reach working code without producing a
better result, and returning nothing when a fresh developer inherited the
project. Pin `modes.rigor: standard` to keep 1.0's process level.

Also in this release:

- `/settings` to view or change any setting, and `project.local.yaml` for
  per-developer preferences that should not be committed.
- `system_overrides` to hold one system to a higher standard than the rest of
  the project, and `testing.strict` to set per test type whether missing
  evidence blocks a story or warns.
- A story that changes anything the player sees is not closed until the game
  has been launched, observed, and a screenshot retained in
  `production/qa/evidence/`. A parse check is not a run. This holds at every
  rigor level, including `minimal`, where automated tests are waived but the
  look is not.
- The code root is engine-specific and enforced as such: Godot `src/`, Unity
  `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a
  project laid out any other way.
- Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh`
  converts a 1.0 layout, non-destructively by default, with a report to review
  before `--finalize` deletes anything.
- Ask-before-write holds regardless of personal automation settings.

Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes:
CHANGELOG.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd

.claude/skills/ux-design/references/sections-hud.md

@@ -0,0 +1,120 @@
+> Section-authoring guidance, loaded by `/ux-design` for the ACTIVE MODE ONLY.
+> Never load the other two — one mode applies per invocation.
+
+# Section Guidance — HUD Design Mode
+
+
+HUD design follows a different order from UX spec mode. Begin with philosophy;
+do not touch layout until the information architecture is complete.
+
+#### Section A: HUD Philosophy
+
+Ask the user to describe the game's relationship with on-screen information in
+1-2 sentences.
+
+Offer framing examples to help:
+- "Nearly HUD-free — atmosphere requires unobstructed immersion (e.g., Hollow Knight, Firewatch)"
+- "Minimal but present — only critical information visible, everything else contextual (e.g., Dark Souls)"
+- "Information-dense — all decision-relevant data always visible (e.g., Diablo IV, StarCraft II)"
+- "Adaptive — HUD density responds to combat state, exploration mode, menus (e.g., God of War)"
+
+This philosophy becomes the design constraint for every subsequent HUD decision.
+If a proposed element conflicts with the stated philosophy, surface that conflict.
+
+---
+
+#### Section B: Information Architecture
+
+Complete this before any layout work. Do not skip it.
+
+**Step 1 — Full information inventory**:
+Pull all information from GDD UI Requirements sections gathered in Phase 2.
+Present the full list: "These are all the things your game systems say they need
+to communicate to the player on screen."
+
+**Step 2 — Categorization**:
+For each item, ask the user to categorize it:
+
+| Category | Description |
+|----------|-------------|
+| **Must Show** | Always visible, player needs it for core decisions |
+| **Contextual** | Visible only when relevant (in combat, near interactable, etc.) |
+| **On Demand** | Player must actively request it (toggle, hold button) |
+| **Hidden** | Communicated through world/audio, never on-screen text |
+
+Use `AskUserQuestion` to step through items in groups of 3-4, not all at once.
+This is the most consequential design decision in the HUD — do not rush it.
+
+**Conflict check**: If the information philosophy (Section A) says "nearly HUD-free"
+but the Must Show list is growing long, surface the conflict explicitly:
+> "The current Must Show list has [N] items. That may conflict with the HUD-free
+> philosophy. Options: reduce the Must Show list, revise the philosophy, or define
+> a hybrid approach where HUD is absent in exploration and present in combat."
+
+---
+
+#### Section C: Layout Zones
+
+Only after the information architecture is approved, design layout zones.
+
+Base layout on:
+- Which items are Must Show (they drive the permanent zone decisions)
+- Where player attention naturally goes during gameplay (center-screen for action games,
+  corners for strategy games)
+- Platform and aspect ratio targets
+
+Offer 2-3 zone arrangements. Include rationale based on the HUD philosophy and the
+categorization from Section B.
+
+---
+
+#### Section D: HUD Elements
+
+For each element in the layout, specify:
+- Element name and category (Must Show / Contextual / On Demand)
+- Content displayed
+- Visual form (bar, number, icon, counter, map)
+- Update behavior (real-time, event-driven, player-queried)
+- Contextual trigger (if not always visible)
+- Animation behavior (does it pulse when low? Fade in? Slam in?)
+
+Work element by element. Reference the interaction pattern library if relevant patterns
+exist for status displays, resource bars, or cooldown indicators.
+
+---
+
+#### Sections E, F, G: Dynamic Behaviors, Platform Variants, Accessibility
+
+These parallel the UX spec's States, Interaction, and Accessibility sections.
+The guidance you need is below — **do not load `sections-ux-spec.md`; one mode
+file applies per invocation.** For the HUD, apply it as follows.
+
+**Dynamic Behaviors (states over time).** Beyond the happy path, capture what
+changes the HUD mid-gameplay and present it as a table for approval:
+
+| State / Variant | Trigger | What Changes |
+|-----------------|---------|--------------|
+| Default | Normal play | — |
+| Low-resource | Health/ammo/etc. below threshold | [element pulses, recolors, …] |
+| Empty / no-data | Element has nothing to show | [hidden, or placeholder] |
+| [etc.] | [trigger] | [changes] |
+
+Ask specifically: what causes the HUD to change density mid-gameplay
+(combat vs. exploration), and what fades, pulses, or slams in on each transition?
+
+**Platform Variants.** Does mobile/console require different element sizes or
+positions? Note per-platform overrides — touch targets, safe-area insets, and
+whether any element moves or is dropped on a given platform.
+
+**Accessibility.** Cross-reference `design/accessibility-requirements.md` if it
+exists, then walk this checklist for the HUD:
+- Gamepad/keyboard focus order for any interactive HUD element
+- Text contrast and minimum readable font sizes at gameplay distance
+- Color-independent communication (no state conveyed by color alone — a
+  low-health cue must not be red-only)
+- Reduced-motion alternative for any pulsing/flashing HUD animation
+- Screen-reader considerations for non-text indicators
+
+If no accessibility tier has been defined for this project, note the gap in the
+HUD design's Open Questions section (WCAG-AA is a reasonable baseline) and
+continue without stopping.