diff --git a/docs/sprints/sprint-28/client.md b/docs/sprints/sprint-28/client.md
new file mode 100644
index 000000000..fd28c66ec
--- /dev/null
+++ b/docs/sprints/sprint-28/client.md
@@ -0,0 +1,118 @@
+---
+title: "Sprint 28 — Client Briefing"
+description: "Sprite layer compositor and character creation screen implementation"
+type: sprint
+status: planning
+sprint: 28
+team: "client"
+---
+
+# Sprint 28: Character Visuals — Client Tasks
+
+**Goal:** Move beyond placeholder art to final product candidate character visuals, from design specs through asset production and compositor implementation.
+
+**Branch:** `client`
+**Agents:** Stig (dev), Tyre (arch), Hoshe (QA)
+
+## New Tickets
+
+| # | Title | Blocked by |
+|---|-------|------------|
+| #693 | Sprite layer compositor | #684 (workshop), #686 (body type sprites) |
+| #694 | Character creation screen | #685 (wireframe), #693 (compositor) |
+
+Use `tooling/db/ticket show <id>` for full details.
+
+## Key Decisions
+
+- `decisions/architecture.md` — D-134 (full character customisation: hair, clothing, colors at tile scale), D-146 (character creation preview: tile-scale sprite with heavy zoom — the compositor IS the preview renderer, no separate portrait system), D-043 (art direction: "functional warmth"), D-044 (visual hierarchy)
+- `decisions/content.md` — D-147 (aesthetic taste as character personality trait — compositor reads layer choices, does not write to apartment generator)
+
+## Notes
+
+### Existing code to understand first
+
+Before starting either ticket, read:
+
+- `client/scripts/rendering/entity_renderer.gd` — the current entity sprite system. It creates one `Sprite2D` per entity, loads textures from `client/assets/sprites/npc_generic_{direction}_64.png`, applies `self_modulate` for D-033 relationship tinting, and handles 4-direction rotation. The compositor replaces the single-sprite model for the player character with a multi-layer node stack.
+- `client/scenes/character_select.tscn` + `client/ui/character_select.gd` — the existing character archetype selection panel (two-card overlay, keyboard + mouse). The new character creation screen (#694) lives in the same flow, after archetype selection.
+- `client/scripts/constants.gd` — TILE_SIZE, entity footprint constants (ENTITY_WIDTH=24, ENTITY_HEIGHT=32), color constants.
+- `client/scripts/autoloads/game_state.gd` — player entity ID and state. The compositor will need to know the player entity to apply the correct layer stack during gameplay.
+
+### #693 — Sprite layer compositor
+
+**Blocked by:** #684 (workshop spec) and #686 (body type sprites available as test input).
+
+Wait for `docs/design/compositor-api-spec.md` (output of #684) before writing the compositor architecture. Do not design the layer API yourself — the workshop decides the layer ordering, color override struct, and Godot node architecture. This note describes what the compositor must accomplish, not how.
+
+**What the compositor must do:**
+- Accept a character definition (layer choices + color overrides) and render the composited character sprite in the correct layer order
+- Support 8-direction rotation (or 4-direction if workshop spec reduces this) — swaps all layer textures simultaneously
+- Apply color mesh recoloring per layer (color region ID → Color mapping) using the mesh regions defined in the visual spec
+- Handle occlusion rules (e.g. helmet clothing hides hair layer)
+- Expose a node or API that `EntityRenderer` can use for the player character in gameplay
+- Expose the same node/API for use in the character creation screen preview pane (#694)
+
+**Integration point with EntityRenderer:**
+The current `EntityRenderer` creates a bare `Sprite2D` for each entity. For the player character, the compositor replaces this with a layered `Node2D` subtree. The cleanest integration: compositor exports a `Node2D` root that EntityRenderer parents under the entity position node, same as it would a `Sprite2D`. EntityRenderer detects `entity_id == GameState.player_entity_id` and uses the compositor node instead of a single sprite.
+
+**Color mesh recoloring approach in Godot:**
+Godot 4 does not have a built-in color mesh system. Options:
+1. Per-layer `self_modulate` (works only for solid single-color regions — too limited)
+2. Shader-based recoloring: pass a `from_color` and `to_color` uniform, replace pixels matching `from_color` within a threshold. This is the standard tile-game approach.
+3. Multiple texture layers per sprite (premultiplied masks).
+
+Wait for workshop spec to select the approach. If the workshop spec is silent on implementation, use option 2 (shader-based) — it is the most flexible and supports arbitrary palette swaps without new textures.
+
+**File locations:**
+- Compositor script: `client/scripts/rendering/character_compositor.gd`
+- Compositor scene (if needed as a PackedScene): `client/scenes/character_compositor.tscn`
+- Shader (if approach 2): `client/shaders/character_recolor.gdshader`
+
+### #694 — Character creation screen
+
+**Blocked by:** #685 (wireframe design) and #693 (compositor for the preview pane).
+
+This is the full implementation of the wireframe produced by #685. Do not start until `docs/design/character-creation-screen-wireframe.md` exists and is approved.
+
+**What the screen must deliver:**
+- Layer selection controls for each character layer type (body, face, hair, clothing, accessories, scars, tattoos)
+- Live preview pane showing the composited character at heavy zoom (tile-scale sprite, zoomed in — same sprite that appears in gameplay)
+- Color picker or palette selector per colorable region
+- Randomise button (randomises all layer choices and color selections)
+- Confirm / Back navigation
+- Full keyboard + mouse support (matching existing character_select.gd pattern — left/right/tab navigation, Enter to confirm, Esc to cancel)
+
+**Integration into game flow:**
+The existing flow: `main_menu.tscn` → `character_select.tscn` (archetype card). The new flow inserts character creation after archetype selection (or replaces the archetype select, depending on how #684 resolves the bookmark/archetype question). Wire the scene transition from the existing entry point.
+
+**Preview pane — D-146:**
+The preview is the gameplay sprite, zoomed. The compositor (#693) provides this. The preview pane is a `SubViewport` or a simple `Node2D` with the compositor node, scaled up. Heavy zoom means: render the 32×32 gameplay sprite at 4× or 6× scale so individual pixels are visible and character detail reads clearly. Rimworld uses approximately 4×–6× zoom on its character customisation screen.
+
+**Data flow:**
+- Character creation screen maintains a `CharacterDefinition` (layer choices + color overrides)
+- On any change, pushes the updated definition to the compositor — compositor re-renders the preview in real time
+- On confirmation, stores `CharacterDefinition` to `GameState` (or session state) for use by the game on load
+- The `CharacterDefinition` structure is defined by the compositor API spec (from #684)
+
+**File locations:**
+- Scene: `client/scenes/character_creation.tscn`
+- Script: `client/ui/character_creation.gd`
+
+## Dependency Chain
+
+```
+#684 (workshop) ──┬──> #693 (compositor)
+#686 (body sprites) ──┘         └──> #694 (creation screen)
+                                      ↑
+#685 (wireframe) ────────────────────┘
+```
+
+Both #693 and #685 must be complete before #694 can start. #693 and #685 can run in parallel.
+
+## PR Workflow
+
+When ready to submit, create a PR with `tea` CLI. **All flags are required** to avoid TTY prompts (see `CLAUDE.md` "Gitea access" section):
+```bash
+tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(client): character sprite compositor and creation screen" --description "body" --base main --head client
+```
diff --git a/docs/sprints/sprint-28/joint.md b/docs/sprints/sprint-28/joint.md
new file mode 100644
index 000000000..c4f42fb01
--- /dev/null
+++ b/docs/sprints/sprint-28/joint.md
@@ -0,0 +1,87 @@
+---
+title: "Sprint 28 — Joint Briefing"
+description: "Cross-team coordination, integration points, sprint completion proof"
+type: sprint
+status: planning
+sprint: 28
+team: "joint"
+---
+
+# Sprint 28: Character Visuals — Joint
+
+**Goal:** Move beyond placeholder art to final product candidate character visuals, from design specs through asset production and compositor implementation.
+
+## Pre-Sprint Checks
+
+| Item | Owner | Status |
+|------|-------|--------|
+| Sprint 27 all done (9/9) | SI | confirmed |
+| D-146 (tile-scale preview) locked — no portrait system | Planning | confirmed |
+| D-147 (aesthetic taste trait) locked — no cosmetic→apartment pipeline | Planning | confirmed |
+| Sprint 28 record created in planning status | SI | confirmed (ID: 28) |
+| All 11 tickets (#683–#694) assigned to Sprint 28 | SI | confirmed |
+
+## Cross-Team Dependencies
+
+| Dependency | Upstream | Downstream | Notes |
+|------------|----------|------------|-------|
+| #684 (workshop) outputs `docs/design/character-visuals-spec.md` | planning | visual (#686–#692) | Visual team cannot start production without this spec. Block ALL visual tickets until spec is published. |
+| #684 (workshop) outputs `docs/design/compositor-api-spec.md` | planning | client (#693) | Client compositor architecture must match the workshop-specified API. #693 should read this before writing any code. |
+| #685 (wireframe) outputs `docs/design/character-creation-screen-wireframe.md` | planning | client (#694) | Client creation screen is a direct implementation of the wireframe. #694 is blocked until wireframe is approved. |
+| #686 (body type sprites) delivers sprites to `client/assets/sprites/character/body/` | visual | client (#693) | Compositor needs at least one complete body type sprite set as test input. #693 can begin architecture with a stub but must have real sprites for integration testing. |
+| #693 (compositor) exports its node API | client | client (#694) | The creation screen's preview pane is driven by the compositor node. #694 cannot wire the preview until #693 is testable. |
+
+**Action required — workshop start:** Planning team (#684 agent) to publish `docs/design/character-visuals-spec.md` and `docs/design/compositor-api-spec.md` before any visual or client work begins. These are gating documents. SI will update ticket statuses once they are published.
+
+**Action required — body sprites handoff:** Visual team (#686 agent) to notify client team (#693 agent) when the first complete body type sprite set is committed to the `visual` branch. Client team needs this for compositor integration testing.
+
+## Sprint Completion Proof
+
+Sprint 28 is done when all of the following are observable:
+
+**Planning:**
+- `docs/design/character-visuals-spec.md` exists and is complete (all 7 layer types specified)
+- `docs/design/compositor-api-spec.md` exists and specifies the layer enum, color override struct, and Godot node architecture
+- `docs/design/character-creation-screen-wireframe.md` (or `.png`) exists and has been reviewed by Jeroen
+- `docs/workshops/character-visuals/workshop-outcomes.md` exists with all decisions recorded
+- Any new D-records filed to `decisions/` for architectural decisions made during the workshop
+
+**Visual:**
+- `client/assets/sprites/character/body/` contains 2 body type sprite sheets (8 directions each) with color mesh region maps
+- `client/assets/sprites/character/face/` contains 2 face type sprite sheets (8 directions each)
+- `client/assets/sprites/character/hair/` contains 2 hair style sprite sheets (8 directions each)
+- `client/assets/sprites/character/expressions/` contains sprite sheets for all workshop-defined expression states (min 3)
+- `client/assets/sprites/character/overlays/scars/` and `.../tattoos/` each contain 2 overlay sprites
+- `client/assets/sprites/character/overlays/injuries/` contains damage state overlay sprites (min 3 states)
+- `client/assets/sprites/character/clothing/` contains 2 clothing set sprite sheets; `.../accessories/` contains 2 sets
+
+**Client:**
+- `client/scripts/rendering/character_compositor.gd` exists and layers all sprite types in the correct workshop-specified order
+- Color mesh recoloring works: changing a color override in the compositor updates the rendered output in real time
+- 8-direction rotation works: compositor switches all layer textures consistently
+- `client/scenes/character_creation.tscn` + `client/ui/character_creation.gd` exist and wire into the new game flow
+- Preview pane shows the composited character at heavy zoom (≥4×) with live updates on layer/color changes
+- All layer selection controls are functional (body, face, hair, clothing, accessories, scars, tattoos, colors)
+- Randomise button works
+- Keyboard navigation (tab/arrow/enter/esc) is fully functional
+
+**Integration eyeball test:**
+Launch the game → New Game → reach character creation screen → change body type → preview updates → change hair color → preview updates → confirm → game loads with character definition stored. No placeholder gray blobs — you see a recognizably distinct character with distinct hair and clothing.
+
+## Test Plan Alignment
+
+Sprint 28 is an art + UI sprint. No new ECS systems, no IPC protocol changes. Test surface:
+
+- **#693 compositor:** Unit test (Godot scene runner or headless) that instantiates the compositor with a known `CharacterDefinition`, verifies the correct number of child nodes, and verifies the facing direction swap triggers a texture change. Use a minimal stub sprite (1×1 PNG) for the test — no need for production assets.
+- **#694 creation screen:** UI test that navigates the creation screen via keyboard input, changes a layer, and asserts the preview compositor was updated. Use `client/tests/` pattern (matching existing test files e.g. `test_dialogue_speaker_colors.gd`).
+- **Visual sprites:** No automated test. Acceptance is the integration eyeball test above — does the compositor render a legible composited character from the production sprites?
+- **Do NOT use TestHarness mocks for rendering verification.** Per CLAUDE.md testing preferences: use the live pipeline. For the creation screen preview specifically, the full compositor is the production path — test against it directly.
+
+## Sprint Retro Triggers
+
+Flag to SI immediately if any of these conditions are hit:
+
+- Workshop spec (#684) is incomplete or contradicts D-146/D-147 — do not start production work until SI escalates to Jeroen
+- Color mesh recoloring approach selected by the workshop requires shader work that Stig estimates as blocking — surface this before #693 is committed, not after
+- Body type sprite footprint deviates from the 24×32/64px convention used by `entity_renderer.gd` — this will break gameplay rendering and must be caught before #686 merges
+- #694 wireframe design (from #685) is received after visual sprites are already in progress and requires a layer reordering — SI to assess impact and decide whether to hold visual or accept the rework cost
diff --git a/docs/sprints/sprint-28/planning.md b/docs/sprints/sprint-28/planning.md
new file mode 100644
index 000000000..efd5d4980
--- /dev/null
+++ b/docs/sprints/sprint-28/planning.md
@@ -0,0 +1,103 @@
+---
+title: "Sprint 28 — Planning Briefing"
+description: "Character visuals planning workshop and character creation screen wireframe"
+type: sprint
+status: planning
+sprint: 28
+team: "planning"
+---
+
+# Sprint 28: Character Visuals — Planning Tasks
+
+**Goal:** Move beyond placeholder art to final product candidate character visuals, from design specs through asset production and compositor implementation.
+
+**Branch:** `planning`
+**Agents:** Araminta (art direction — proposer), Gestalt (systems — proposer), Tyre (technical — proposer), Ozzie (player experience — proposer), Qatux (documenter — records decisions, updates domain files), SI (project manager — creates follow-up tickets, updates sprint assignments)
+
+## New Tickets
+
+| # | Title | Blocked by |
+|---|-------|------------|
+| #684 | Character visuals planning workshop | — |
+| #685 | Character creation screen wireframe | #684 |
+
+Use `tooling/db/ticket show <id>` for full details.
+
+## Key Decisions
+
+- `decisions/architecture.md` — D-134 (full character customisation: hair, clothing, colors at tile scale), D-146 (character creation preview: tile-scale sprite with heavy zoom — NO separate portrait system)
+- `decisions/scope.md` — D-115 (character creation scope: superseded by Sprint 28 workshop), D-146 (tile-scale preview as the production approach)
+- `decisions/content.md` — D-147 (aesthetic taste as character personality trait — shared root for cosmetic + apartment expression)
+
+## Notes
+
+### #684 — Character visuals planning workshop
+
+This ticket gates all downstream work in the sprint. Nothing else starts until this workshop outputs its spec documents.
+
+**Discussion structure — three rounds:**
+
+**Round 1 — Inventory and constraints**
+Each domain agent assesses their area:
+- Araminta: What does tile-scale readable character art require? What layer order is needed? Color mesh regions — how are they defined per sprite type?
+- Gestalt: What data model does the compositor (#693) need? How do layer stacks, color overrides, and 8-direction rotation map to a clean API?
+- Tyre: What does the Godot client need from the compositor? How does it plug into the existing `EntityRenderer` (`client/scripts/rendering/entity_renderer.gd`) which currently uses a single `Sprite2D` per entity?
+- Ozzie: What does the player need from the character creation screen? What are the emotional beats — first impression, customisation flow, confirmation?
+
+**Round 2 — Specification proposals**
+Agents propose specs per deliverable. Each proposal must be concrete enough for Araminta to start drawing:
+- Body type spec: shapes, proportions, 8-direction rotation consistency rules, color mesh region definitions
+- Face type spec: feature range, skin tone mesh regions, expression state requirements
+- Hair style spec: silhouette guidelines, color mesh regions
+- Expression state list: named states, how expressions layer over base face
+- Scar/tattoo overlay spec: placement grid, additive blending rules
+- Injury overlay spec: damage state progression (states TBD — min viable: undamaged / light / heavy)
+- Clothing/apparel spec: layer ordering, occlusion rules, color mesh regions
+- Compositor API spec: layer enum, color override struct, direction enum, Godot node architecture
+
+**Round 3 — Convergence and sign-off**
+Review proposals for consistency conflicts. Lock specs. Qatux records all decisions. SI creates any follow-up tickets identified during the workshop.
+
+**Output specification — what this workshop must produce:**
+
+1. `docs/design/character-visuals-spec.md` — complete spec document covering all layer types, color mesh regions, 8-direction rotation rules, layer ordering, and occlusion rules
+2. `docs/design/compositor-api-spec.md` — Godot-side compositor data model and node architecture
+3. Any new D-records filed to `decisions/` for architectural decisions made during the workshop (claim IDs before writing: `tooling/db/decision claim D <domain> "title"`)
+4. Workshop outcomes captured in `docs/workshops/character-visuals/workshop-outcomes.md`
+
+**Important — D-146 is locked:** The character creation screen uses tile-scale sprite at heavy zoom. No portrait render. Do not reopen this question. Ozzie's dissent is on record.
+
+**Important — D-147 is locked:** The `aesthetic_taste` trait is the shared root for cosmetic choices and apartment expression. The compositor does not pipeline choices into the apartment generator. Do not reopen this question.
+
+### #685 — Character creation screen wireframe
+
+Produces the UI layout artifact that drives client implementation (#694).
+
+**Scope:** Collaborative design between the planning team and Jeroen (project lead) using Frame0 (or equivalent wireframing tool). This is a design document, not a code deliverable.
+
+**Coverage:**
+- Layout of all layer selection controls (body, face, hair, clothing, accessories, scars, tattoos)
+- Preview pane position and scale (tile-scale sprite at heavy zoom — D-146)
+- Color picker / palette selector UX
+- Randomise button placement
+- Navigation: how player confirms, goes back, returns to main menu
+- Keyboard navigation flow (must support controller/keyboard-only — existing character_select.gd is keyboard-friendly)
+
+**Output:** `docs/design/character-creation-screen-wireframe.md` — annotated wireframe (or image file at `docs/design/character-creation-wireframe.png` if drawn). This is the acceptance input for #694 (Character creation screen, client team).
+
+**Dependency note:** #685 must complete before #694 starts. The wireframe IS the spec for the client implementation.
+
+## Dependency Chain
+
+```
+#684 (workshop) → #685 (wireframe) → unblocks #694 (client: creation screen)
+#684 (workshop) → unblocks ALL visual team tickets (#686–#692)
+#684 (workshop) → unblocks #693 (client: compositor) via #686 (body type sprites)
+```
+
+## PR Workflow
+
+When ready to submit planning artifacts, create a PR with `tea` CLI. **All flags are required** to avoid TTY prompts (see `CLAUDE.md` "Gitea access" section):
+```bash
+tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "chore(meta): character visuals planning workshop outputs" --description "body" --base main --head planning
+```
diff --git a/docs/sprints/sprint-28/visual.md b/docs/sprints/sprint-28/visual.md
new file mode 100644
index 000000000..133c3e5d4
--- /dev/null
+++ b/docs/sprints/sprint-28/visual.md
@@ -0,0 +1,157 @@
+---
+title: "Sprint 28 — Visual Briefing"
+description: "Character sprite production: body types, faces, hair, expressions, overlays, clothing — all layers for compositor"
+type: sprint
+status: planning
+sprint: 28
+team: "visual"
+---
+
+# Sprint 28: Character Visuals — Visual Tasks
+
+**Goal:** Move beyond placeholder art to final product candidate character visuals, from design specs through asset production and compositor implementation.
+
+**Branch:** `visual`
+**Agents:** Araminta (art direction)
+
+## New Tickets
+
+| # | Title | Blocked by |
+|---|-------|------------|
+| #686 | Body type sprites | #684 (workshop) |
+| #687 | Face type sprites | #684 (workshop) |
+| #688 | Hair type sprites | #684 (workshop) |
+| #689 | Facial expression sprites | #684 (workshop) |
+| #690 | Scar and tattoo overlay sprites | #684 (workshop) |
+| #691 | Visible injuries overlay sprites | #684 (workshop) |
+| #692 | Clothing, apparel and accessory layer sprites | #684 (workshop) |
+
+Use `tooling/db/ticket show <id>` for full details.
+
+## Key Decisions
+
+- `decisions/architecture.md` — D-134 (full character customisation: hair, clothing, colors at tile scale — readability solved through outline/highlight, not by limiting options), D-043 (art direction: "functional warmth" visual style), D-044 (visual hierarchy: entity > object > structure), D-046 (lighting system: three-reference model), D-066 (dual-scale grid: 0.5m simulation, 1m visual)
+- `decisions/scope.md` — D-146 (tile-scale sprite with heavy zoom as the preview — these sprites ARE the final product at game scale)
+
+## Notes
+
+### Blocking condition — wait for #684 outputs
+
+All seven tickets are blocked by #684 (planning workshop). Do not start production until the workshop outputs `docs/design/character-visuals-spec.md`. That document defines:
+- Layer ordering for the compositor
+- Color mesh region definitions per layer type
+- 8-direction rotation consistency rules
+- Expression state list
+- Damage state progression for injuries
+
+If the workshop spec is incomplete in any area, block the relevant ticket and flag to SI before proceeding.
+
+### Existing sprite reference
+
+Current placeholder sprites are at `client/assets/sprites/`:
+- `npc_generic_{north,south,east,west}_64.png` — 64×64 px source textures, 4 directions
+- Rendered at 0.5 scale → 32×32 runtime footprint within 32×32 visual tiles (D-066)
+- Entity footprint in `entity_renderer.gd`: 24×32 within the 32×32 tile (ENTITY_WIDTH/HEIGHT constants)
+
+All new sprites must maintain this 64×64 px source resolution and 4-direction (or 8-direction, per workshop spec) convention. The compositor (#693) will layer them — produce each layer as a separate sprite sheet, not composited into a single texture.
+
+### #686 — Body type sprites
+
+Base layer. All other character sprites composite on top of this.
+
+**Deliverables:**
+- 2 distinct body type sprite sheets (8 directions each = 16 sprites per body type)
+- Color mesh region map per body type (defines recolorable skin/clothing zones)
+- Source files and exported PNGs at `client/assets/sprites/character/body/`
+
+**Art guidance:** Body type is the widest-impact decision — proportions set the silhouette that all overlaid layers must match. Produce body_a and body_b with visibly distinct silhouettes while sharing the same feet-anchor point and 24×32 footprint convention. Color mesh regions: at minimum, skin region must be separately recolorable.
+
+### #687 — Face type sprites
+
+Overlay on the upper portion of the body sprite.
+
+**Deliverables:**
+- 2 distinct face type sprite sheets (8 directions each)
+- Color mesh region map per face (skin tone recolorability at minimum)
+- Source files and exported PNGs at `client/assets/sprites/character/face/`
+
+**Art guidance:** Face sprites overlay on the head region of the body. The 8-direction face must register exactly with the 8-direction body for all orientations. Skin tone region should match the body skin region color mesh ID for consistent tinting.
+
+### #688 — Hair type sprites
+
+Overlay on top of the face layer.
+
+**Deliverables:**
+- 2 distinct hair style sprite sheets (8 directions each)
+- Color mesh region map per style (hair color region fully recolorable)
+- Source files and exported PNGs at `client/assets/sprites/character/hair/`
+
+**Art guidance:** Hair sprites must read at 32×32 game resolution. Silhouette is more important than fine detail — thick, distinct hair shapes read better than thin ones at tile scale. Test at 32px, not at the 64px source.
+
+### #689 — Facial expression sprites
+
+Overlay states on the face layer. Expression sprites swap the face layer's neutral state.
+
+**Deliverables:**
+- Named expression state sprite sheets (states defined by workshop — minimum: neutral, alert, distressed)
+- 8 directions per expression state
+- Source files and exported PNGs at `client/assets/sprites/character/expressions/`
+
+**Art guidance:** At tile scale, expression reads through body posture and head angle as much as facial detail. Exaggerate. Neutral is the default — alert and distressed are the two most important non-neutral states. Count of expression states is TBD by the workshop spec.
+
+### #690 — Scar and tattoo overlay sprites
+
+Additive overlays above the skin layer. Placement must work for both body types.
+
+**Deliverables:**
+- 2 scar overlay sprites (with placement anchors, 8 directions each)
+- 2 tattoo overlay sprites (with placement anchors, 8 directions each)
+- Source files and exported PNGs at `client/assets/sprites/character/overlays/scars/` and `.../tattoos/`
+
+**Art guidance:** These are visible at tile scale only when zoomed in (character creation preview, heavy zoom mode per D-146). Placement anchors must be defined relative to the body sprite coordinate system so the compositor can offset them correctly per body type.
+
+### #691 — Visible injuries overlay sprites
+
+Damage state overlays representing combat injury. These appear during gameplay, not just in character creation.
+
+**Deliverables:**
+- Damage state overlay sprites (states defined by workshop — minimum: light damage, heavy damage, critical)
+- 8 directions per damage state
+- Source files and exported PNGs at `client/assets/sprites/character/overlays/injuries/`
+
+**Art guidance:** Injury overlays are visible during gameplay at normal zoom (32×32). They must read clearly at that scale. Use color and silhouette change (blood, torn clothing, posture change baked in) — not fine line detail.
+
+### #692 — Clothing, apparel and accessory layer sprites
+
+Outermost visible layer. Must handle occlusion of face/hair layers when appropriate (e.g. helmets).
+
+**Deliverables:**
+- 2 clothing set sprite sheets (full outfit, 8 directions each)
+- 2 accessory sprite sheets (8 directions each)
+- Layer ordering and occlusion rules documented in the spec (or confirmed against workshop spec)
+- Color mesh region map per clothing set (primary + secondary color regions)
+- Source files and exported PNGs at `client/assets/sprites/character/clothing/` and `.../accessories/`
+
+**Art guidance:** Clothing is what the player sees 99% of the time during gameplay. Make it read clearly at 32×32. Two clothing sets should have visibly different silhouettes (one formal/professional, one casual/work). Color mesh regions: minimum two — primary garment color, secondary accent.
+
+## Dependency Chain
+
+```
+#684 (workshop) → #686 (body) → #693 (client compositor — body sprites are its first input)
+#684 (workshop) → #687 (face)
+#684 (workshop) → #688 (hair)
+#684 (workshop) → #689 (expressions)
+#684 (workshop) → #690 (scars/tattoos)
+#684 (workshop) → #691 (injuries)
+#684 (workshop) → #692 (clothing/accessories)
+
+#686–#692 can all run in parallel after #684 completes.
+#686 is highest priority — it unblocks #693 (client compositor).
+```
+
+## PR Workflow
+
+When ready to submit, create a PR with `tea` CLI. **All flags are required** to avoid TTY prompts (see `CLAUDE.md` "Gitea access" section):
+```bash
+tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(assets): character sprite layers — body, face, hair, expressions, overlays, clothing" --description "body" --base main --head visual
+```