feat(docs): assign teams to v0.2 story tickets (#614-#626)

Resolve Q-WTF-039 (tile-scale heavy zoom, not portrait — D-146) and
Q-WTF-040 (aesthetic taste trait as shared root — D-147). Split #617
into server generator + client rendering, split #620 into server
culture resolution + client location picker. Sprint 28 candidate list
with 7 unblocked tickets.

Ticket: #676

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

decisions/content.md

@@ -555,4 +555,17 @@ How narrative, NPCs, and world content are created: content tiers, NPC generatio
 
 ---
 
-*43 decisions. Last updated: 2026-03-14 (D-144 Sirius as Reach capital)*
+### D-147: Aesthetic taste as character personality trait — shared root for cosmetic and environmental expression
+- **Date:** 2026-03-17
+- **Decision:** Characters have an `aesthetic_taste` personality trait (preferred palette, style leanings) that naturally expresses in both personal appearance and living space. This is NOT a cosmetic→apartment pipeline — hair color does not map to wall color. Instead, taste is a shared root: someone who gravitates toward teal will pick teal clothing AND own a teal vase. The apartment generator reads the character's taste trait (alongside economic position from #615 and cultural context from #620); the character customization screen lets the player express that same taste through appearance choices. Neither system depends on the other — both read the same underlying trait.
+- **Rationale:** The naive approach (pipe cosmetic choices into apartment generator) creates a crude "team color" mapping that feels artificial. The elegant approach: taste is a personality attribute, like traits or skills. It manifests independently in multiple contexts. This keeps #619 (customization) and #617 (apartment) architecturally independent while producing coherent identity expression. The taste trait is also reusable: NPC aesthetic preferences, gift preferences, "does this room feel like home" comfort checks, cultural style variations.
+- **Dependency implication:** #619 does NOT block #617. Both read the character's taste trait independently. The taste trait definition belongs to the character data model (server), not to either consuming system.
+- **Source:** Sprint 27 planning pass — Q-WTF-040 resolution
+- **Raised by:** Project lead (taste-as-shared-root framing), Gestalt (ColorHint concept evolved into trait), Paula (culture + economics as primary apartment drivers)
+- **Dissent:** Ozzie argued for direct cosmetic→apartment pipeline. Tyre and Paula argued for no connection at all. The taste trait is the synthesis: connection through personality, not through data pipeline.
+- **Cross-reference:** [D-125](#d-125-world-is-quietly-responsive--gradient-of-caring-by-social-proximity) (quiet responsiveness), [D-134](#d-134-full-character-customization) (full character customization), [D-136](architecture.md#d-136-first-settled-reach-moment-auto-generated-apartment--insert-activation) (first game moment), ticket #617 (auto-generated apartment), ticket #619 (full character customisation)
+- **Resolves:** Q-WTF-040
+
+---
+
+*45 decisions. Last updated: 2026-03-17 (D-147 aesthetic taste trait)*

decisions/questions-content.md

@@ -205,4 +205,20 @@ Narrative, NPCs, dialogue, templates, setting, worldbuilding, and storyteller me
 
 ---
 
-*21 questions (7 resolved, 2 partially resolved, 12 open). Last updated: 2026-03-13 (Q-015 closed as obsolete per D-122)*
+### Q-WTF-039: Character creation — portrait render or tile-scale preview?
+- **Status:** Resolved → [D-146](scope.md#d-146-character-creation-preview--tile-scale-sprite-with-heavy-zoom)
+- **Question:** Does the character creation screen show a portrait render or a tile-scale in-world preview of the player character? Affects #618 (CK3-style character creation screen) team assignment: portrait render is a visual team deliverable; tile-scale preview is client.
+- **Resolution:** Tile-scale sprite with heavy zoom. The creation screen shows the game sprite rendered at high resolution, zoomed in so cosmetic details are clearly visible. Same approach as Rimworld: one rendering pipeline, no separate portrait system. #618 stays as a single client ticket. Resolved by [D-146](scope.md#d-146-character-creation-preview--tile-scale-sprite-with-heavy-zoom).
+- **Assigned to:** Tyre (architecture), confirmed by project lead
+- **Source:** Sprint 27 planning pass (2026-03-17)
+
+### Q-WTF-040: Do creation choices trace into the generated apartment?
+- **Status:** Resolved → [D-147](content.md#d-147-aesthetic-taste-as-character-personality-trait--shared-root-for-cosmetic-and-environmental-expression)
+- **Question:** If the player picks hair colour and clothing in #619, does the generator use those choices when laying out the starting apartment (furniture style, colour palette)? Affects #617 scope and dependency.
+- **Resolution:** Not directly. Cosmetic choices do not pipeline into the apartment generator. Instead, characters have an `aesthetic_taste` personality trait that independently informs both appearance choices and living space. Someone who likes teal picks teal clothing AND owns a teal vase — but through shared taste, not data coupling. #619 does NOT block #617. Resolved by [D-147](content.md#d-147-aesthetic-taste-as-character-personality-trait--shared-root-for-cosmetic-and-environmental-expression).
+- **Assigned to:** Gestalt (systems), Paula (narrative), confirmed by project lead
+- **Source:** Sprint 27 planning pass (2026-03-17)
+
+---
+
+*23 questions (9 resolved, 2 partially resolved, 12 open). Last updated: 2026-03-17 (Q-WTF-039, Q-WTF-040 resolved)*

decisions/scope.md

@@ -287,4 +287,17 @@ What we're building: game concept, design pillars, prototype definition, map spe
 
 ---
 
-*25 decisions (16 active, 9 superseded). Last updated: 2026-03-15 (D-145 added)*
+### D-146: Character creation preview — tile-scale sprite with heavy zoom
+- **Date:** 2026-03-17
+- **Decision:** The character creation screen shows the player character's game sprite at heavy zoom — the same top-down tile-scale rendering used in gameplay, rendered at high resolution so it holds up when zoomed in. No separate portrait rendering system. Cosmetic choices (hair, clothing, colors) update the zoomed sprite in real time. Rimworld uses this exact approach: the character customization screen shows the same pawn sprite rendered larger, with clothing/equipment layers visible.
+- **Rationale:** The tile-scale sprite IS the player's character for the entire game. Showing it zoomed in character creation: (1) sets accurate expectations for in-game appearance, (2) reuses the production sprite/animation pipeline — zero new rendering infrastructure, (3) validates that cosmetic customization (#619) reads correctly at game scale, (4) keeps #618 as a single client ticket with no visual-team split. A separate portrait system would be a one-off rendering context (different camera, lighting, asset pipeline) that serves no other game feature. "CK3-style" in the bookmark concept refers to the bookmark structure, not the portrait aesthetic. Portraits can be added later as an additive feature if needed.
+- **Team implication:** Ticket #618 (CK3-style character creation screen) stays as a single `client` team ticket. No split required.
+- **Source:** Sprint 27 planning pass — Q-WTF-039 resolution
+- **Raised by:** Tyre (architecture), Paula (narrative), Gestalt (systems), confirmed by project lead
+- **Dissent:** Ozzie argued for portrait render (emotional attachment). Overruled: tile-scale at heavy zoom provides sufficient character identity without a second rendering pipeline.
+- **Cross-reference:** [D-115](#d-115-character-creation-scoped-to-skills--bookmark-for-v02) (creation scope), [D-134](content.md#d-134-full-character-customization) (full character customization), [D-136](architecture.md#d-136-first-settled-reach-moment-auto-generated-apartment--insert-activation) (first game moment), ticket #618 (CK3-style character creation screen)
+- **Resolves:** Q-WTF-039
+
+---
+
+*26 decisions (17 active, 9 superseded). Last updated: 2026-03-17 (D-146 tile-scale heavy zoom)*