Add notification hook, directory CLAUDE.md scaffolding

- Wire Notification event in settings.json to new notify.sh hook
- notify.sh: Windows toast notifications via PowerShell balloon tip
- docs/CLAUDE.md: authoring standards for ADRs, TR registry, control manifest, engine reference
- design/CLAUDE.md: GDD directory guidance placeholder
- src/: scaffold with .gitkeep and CLAUDE.md authoring guide

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/hooks/notify.sh

@@ -0,0 +1,35 @@
+#!/usr/bin/env bash
+# Notification hook — fires when Claude Code sends a notification
+# Shows a Windows toast via PowerShell
+
+# Read notification JSON from stdin
+INPUT=$(cat)
+
+# Extract message — try jq first, fall back to grep
+if command -v jq &>/dev/null; then
+  MESSAGE=$(echo "$INPUT" | jq -r '.message // empty' 2>/dev/null)
+fi
+if [ -z "$MESSAGE" ]; then
+  MESSAGE=$(echo "$INPUT" | grep -oE '"message":"[^"]*"' | sed 's/"message":"//;s/"//')
+fi
+if [ -z "$MESSAGE" ]; then
+  MESSAGE="Claude Code needs your attention"
+fi
+
+# Sanitize message for PowerShell string embedding (escape single quotes)
+MESSAGE_SAFE=$(echo "$MESSAGE" | sed "s/'/''/g" | head -c 200)
+
+# Show Windows balloon tip notification (works on all Windows 10/11 without extra modules)
+powershell.exe -NonInteractive -WindowStyle Hidden -Command "
+  Add-Type -AssemblyName System.Windows.Forms
+  \$notify = New-Object System.Windows.Forms.NotifyIcon
+  \$notify.Icon = [System.Drawing.SystemIcons]::Information
+  \$notify.BalloonTipTitle = 'Claude Code'
+  \$notify.BalloonTipText = '$MESSAGE_SAFE'
+  \$notify.Visible = \$true
+  \$notify.ShowBalloonTip(5000)
+  Start-Sleep -Seconds 6
+  \$notify.Dispose()
+" 2>/dev/null &
+
+echo "Notification: $MESSAGE_SAFE"

.claude/settings.json

@@ -83,6 +83,18 @@
         ]
       }
     ],
+    "Notification": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .claude/hooks/notify.sh",
+            "timeout": 10
+          }
+        ]
+      }
+    ],
     "PreCompact": [
       {
         "matcher": "",

design/CLAUDE.md

@@ -0,0 +1,38 @@
+# Design Directory
+
+When authoring or editing files in this directory, follow these standards.
+
+## GDD Files (`design/gdd/`)
+
+Every GDD must include all **8 required sections** in this order:
+1. Overview — one-paragraph summary
+2. Player Fantasy — intended feeling and experience
+3. Detailed Rules — unambiguous mechanics
+4. Formulas — all math defined with variables
+5. Edge Cases — unusual situations handled
+6. Dependencies — other systems listed
+7. Tuning Knobs — configurable values identified
+8. Acceptance Criteria — testable success conditions
+
+**File naming:** `[system-slug].md` (e.g. `movement-system.md`, `combat-system.md`)
+
+**Systems index:** `design/gdd/systems-index.md` — update when adding a new GDD.
+
+**Design order:** Foundation → Core → Feature → Presentation → Polish
+
+**Validation:** Run `/design-review [path]` after authoring any GDD.
+Run `/review-all-gdds` after completing a set of related GDDs.
+
+## Quick Specs (`design/quick-specs/`)
+
+Lightweight specs for tuning changes, minor mechanics, or balance adjustments.
+Use `/quick-design` to author. Template: `.claude/docs/templates/quick-spec.md`
+
+## UX Specs (`design/ux/`)
+
+- Per-screen specs: `design/ux/[screen-name].md`
+- HUD design: `design/ux/hud.md`
+- Interaction pattern library: `design/ux/interaction-patterns.md`
+- Accessibility requirements: `design/ux/accessibility-requirements.md`
+
+Use `/ux-design` to author. Validate with `/ux-review` before passing to `/team-ui`.

docs/CLAUDE.md

@@ -0,0 +1,33 @@
+# Docs Directory
+
+When authoring or editing files in this directory, follow these standards.
+
+## Architecture Decision Records (`docs/architecture/`)
+
+Use the ADR template: `.claude/docs/templates/adr.md`
+
+**Required sections:** Title, Status, Context, Decision, Consequences,
+ADR Dependencies, Engine Compatibility, GDD Requirements Addressed
+
+**Status lifecycle:** `Proposed` → `Accepted` → `Superseded`
+- Never skip `Accepted` — stories referencing a `Proposed` ADR are auto-blocked
+- Use `/architecture-decision` to create ADRs through the guided flow
+
+**TR Registry:** `docs/architecture/tr-registry.yaml`
+- Stable requirement IDs (e.g. `TR-MOV-001`) that link GDD requirements to stories
+- Never renumber existing IDs — only append new ones
+- Updated by `/architecture-review` Phase 8
+
+**Control Manifest:** `docs/architecture/control-manifest.md`
+- Flat programmer rules sheet: Required / Forbidden / Guardrails per layer
+- Date-stamped `Manifest Version:` in header
+- Stories embed this version; `/story-done` checks for staleness
+
+**Validation:** Run `/architecture-review` after completing a set of ADRs.
+
+## Engine Reference (`docs/engine-reference/`)
+
+Version-pinned engine API snapshots. **Always check here before using any
+engine API** — the LLM's training data predates the pinned engine version.
+
+Current engine: see `docs/engine-reference/godot/VERSION.md`

src/CLAUDE.md

@@ -0,0 +1,36 @@
+# Source Directory
+
+When writing or editing game code in this directory, follow these standards.
+
+## Engine Version Warning
+
+The LLM's training data predates the pinned engine version.
+**Always check `docs/engine-reference/` before using any engine API.**
+Do not guess at post-cutoff API signatures — look them up first.
+
+## Coding Standards
+
+- All public APIs require doc comments
+- Gameplay values must be **data-driven** (external config files), never hardcoded
+- Prefer dependency injection over singletons for testability
+- Every new system needs a corresponding ADR in `docs/architecture/`
+- Commits must reference the relevant story ID or design document
+
+## File Routing
+
+Match the engine-specialist agent to the file type being written.
+See `CLAUDE.md` → Technical Preferences → Engine Specialists → File Extension Routing.
+
+When in doubt, use the primary engine specialist configured in `CLAUDE.md`.
+
+## Tests
+
+Tests live in `tests/` — not in `src/`.
+Run `/test-setup` to scaffold the test framework if it doesn't exist yet.
+Every gameplay system should have unit tests covering its formulas and edge cases.
+
+## Verification-Driven Development
+
+Write tests first when adding gameplay systems.
+For UI changes, verify with screenshots.
+Compare expected output to actual output before marking work complete.