settled-reach/docs/sprints/sprint-28/planning.md

---
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
```