fix(docs): address PR #92 review comments

- Fix D-134 cross-references to point to architecture.md (not content.md)
- Fix stale #620 reference in D-147 body (now #679)
- Fix content.md footer count (44, not 45)
- Add D-145, D-146, D-147 to decisions/README.md index
- Add Q-WTF-041 entry to questions-content.md (was referenced but untracked)
- Fix sprint-28-candidates.md totals line
- Align spelling to British "customisation" throughout new decisions
- Add information boundary classification to D-147 (public trait, per D-010)
- Add "first message" instruction to proposer rules in sprint-start skill

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-03-17 08:26:58 +01:00
co-authored by Claude Opus 4.6
parent 8db83b1589
commit a69c75d4ae
6 changed files with 21 additions and 13 deletions
+5 -4
View File
@@ -557,15 +557,16 @@ How narrative, NPCs, and world content are created: content tiers, NPC generatio
### 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.
- **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 #679); the character customisation 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 (customisation) 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.
- **Information boundary (D-010):** `aesthetic_taste` is a public trait — visible to other entities and the client. NPCs can observe the player's taste (e.g. gift relevance, comfort assessment). This is not private knowledge behind the information boundary.
- **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)
- **Cross-reference:** [D-125](#d-125-world-is-quietly-responsive--gradient-of-caring-by-social-proximity) (quiet responsiveness), [D-134](architecture.md#d-134-full-character-customisation--hair-clothing-colors-at-tile-scale) (full character customisation), [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)*
*44 decisions. Last updated: 2026-03-17 (D-147 aesthetic taste trait)*