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

title, description, type, status, sprint, team

title	description	type	status	sprint	team
Sprint 28 — Planning Briefing	Character visuals planning workshop and character creation screen wireframe	sprint	planning	28	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):

tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "chore(meta): character visuals planning workshop outputs" --description "body" --base main --head planning