Files
settled-reach/docs/assets/briefs/doors.md
T
jpmschweitzerandClaude Fable 5 2bac820c77 docs(assets): per-class production briefs + template + formal deferral register (T-1049)
The asset-brief template (scope/visual-reference/naming/gen-path/
acceptance, one page) and five real briefs — station walls, rural walls,
doors, floors, furniture/props — each citing its D-235 axis tokens and
palette.md register rows (or the D-257 toon default), conventions.md
naming/mask/footprint rules, and the image-gen -> glb-gen -> promotion
path with concrete acceptance counts. Doors carry the negative
no-state-frame-files constraint (runtime mechanism stays Phase 5);
furniture/props' first acceptance is promoting the three unpromoted
spike GLBs. deferred.md is the formal register for the T-1051 four
(lamp posts, barns, TVs, billboards) + cars/Q-067, with rationale and
revisit triggers — satisfying T-1051's own 'or record formal deferral'
deliverable. Child stories under T-961 are created lead-side at merge.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-25 23:00:51 +02:00

4.3 KiB

title, description, type, status, ticket, decision_refs, author, created, updated
title description type status ticket decision_refs author created updated
Asset Brief — Doors Door models — no D-235 ObjectTag axis; logical DoorSpec exists, runtime open/closed mechanism deferred to Phase 5 design active
D-231
D-244
D-257
Araminta 2026-07-25 2026-07-25

Asset Brief — Doors

One page. Gates its child story — the story does not enter in_progress without this brief attached.


1. Scope

Door models (furniture or props manifest category — a door is a fitted architectural object, closer to props; the manifest's category field is authoritative regardless of subdirectory per conventions.md §1). Doors have no D-235 ObjectTag axis — wall/roof/facade/street are building- exterior surface tags; a door is a discrete object that sits in a wall opening. What DOES exist already: the logical DoorSpec/ InteriorDescriptor model (T-979/T-998, D-231) — door count derivation (Main/Service/Emergency/Hidden) and initial-state derivation (Open/ Closed/TemporalWindow/Locked/Sealed) — but that work is server-side struct definition only, not visual. This brief covers the visual asset only; it does not touch T-979/T-998's derivation logic.

2. Visual Reference

No D-235 token to cite — doors take palette.md §2's toon default (same shader family as characters/furniture: toon.gdshader or toon_masked .gdshader, roughness=1.0/specular=0.0). A door with a glazed panel (e.g. a station door with a window) falls under the §2.1 glazing carve-out if the pane is gameplay-load-bearing for sightlines — treat that panel as a separate material slot at minimal-PBR, the rest of the door stays flat toon. No dedicated door row exists in palette.md §3's material register (that table only covers wall/roof/facade/street) — if a door's finish should match its host building's wall material (e.g. a timber door on a timber_wall building), that is a future content-authoring choice, not something this brief specifies.

3. Naming

<category>_<descriptor>.glb per conventions.md §1 — e.g. door_sliding .glb, door_hinged.glb. Negative constraint, binding (conventions.md §5): do NOT author state-frame suffix files (door_open.glb/ door_closed.glb). One door .glb per descriptor; the DoorSpec states (Open/Closed/TemporalWindow/Locked/Sealed) are a runtime transform/animation on that single model — the actual mechanism (AnimationPlayer swing, procedural hinge rotation, or a named "open" bone convention) is explicitly a Phase-5 rendering decision, out of scope for this Phase-4 asset brief and for the story it gates. Mask sidecar (<model>_mask.png) only if a tintable variant is wanted; footprint is single-tile ([1, 1], omit the field) — a door does not span multiple sim tiles.

4. Generation Path

Standard path: /image-gen (toon-shaded concept, 3/4 front view, closed-door pose since there is no baked open state) → /glb-gen (Trellis) → Blender postprocess → promotion into client/assets/models/props/ + manifest.json entry. No texture-only alternative here — a door is inherently a discrete mesh, not a tileable surface.

5. Acceptance

2 starter assets enter models.md + manifest.json at planned: (1) door_hinged — the generic single-leaf door, the closest thing this class has to a D-235-style fallback default even though no generic_door tag is formally ratified (Q-119's text lists "generic door/floor/furniture parents" as a candidate milestone-0 set alongside the ratified generic_wall/roof/ facade/street — milestone-0 IF Q-119 resolves yes, not resolved here); (2) door_sliding — matches the workshop-outcomes.md §3.3 door_sliding prior-art mention and a plausible station-context default. Both ship as one model each, no state-frame variants, per §3's negative constraint.


Cross-References

  • docs/assets/visual/conventions.md §1, §2, §5 — model naming, mask sidecar, door-state negative constraint
  • docs/assets/visual/palette.md §2 — toon default, glazing carve-out if applicable
  • docs/assets/visual/models.md — target catalog
  • client/assets/models/manifest.json
  • T-979/T-998 (D-231) — the logical DoorSpec/InteriorDescriptor this brief's visual asset will eventually attach to (Phase 5, not this brief's scope)