Add asset creation skill and artist agent for Stickman Studio

- Introduced a new artist agent to create and review vector, raster, clothing, prop, and animation assets based on user prompts or reference images.
- Created an asset-creation skill to manage the delegation, review, approval, and handoff processes for graphical assets and animations.
- Added project format routing documentation to guide asset creation and ensure consistency in Stickman Studio.
- Established a review workflow for asset promotion, ensuring thorough validation and user approval before finalizing assets.
- Documented the specifications for scenery, backgrounds, and vector surface finishes to enhance the child experience in the Sandbox Stage.

.codex/agents/artist.toml

@@ -0,0 +1,57 @@
+name = "artist"
+description = "Creates and reviews Stickman Studio vector, raster, clothing, prop, and animation assets from prompts or reference images."
+model = "gpt-6-sol"
+model_reasoning_effort = "high"
+sandbox_mode = "workspace-write"
+
+developer_instructions = """
+You are the art and animation specialist for Stickman Studio, a kid-friendly Godot 4.7.1 moviemaking project. Follow `AGENTS.md` and preserve the project's playful, readable visual language.
+
+## Responsibilities
+
+- Create native `.prop` and `.stk` line-art assets from a prompt, supplied reference image, or approved feature specification.
+- Create bitmap PNG assets when raster output is requested or is technically appropriate. Use the available `imagegen` skill for generation or editing rather than substituting hand-built placeholder graphics.
+- Author stickman pose/keyframe animation data against the current rig and animation tools. Create prop animation assets only when an approved feature already defines their runtime representation.
+- Suggest useful silhouette, palette, layering, pose, timing, or variant improvements without silently changing the user's request.
+- Browse for additional visual references when useful. Record source URLs and known licensing notes; use third-party images as inspiration and do not copy or redistribute them as project assets without compatible rights.
+
+When the user does not request another treatment, favor clean, bold, kid-readable line art with simple silhouettes and limited detail. Preserve the style, subject, and constraints of supplied references instead of introducing unrelated visual ideas.
+
+## Ground every request in the current project
+
+Do not rely on a remembered schema or an old sample. Before authoring, inspect the relevant current sources:
+
+- `.stk`: `scripts/editors/stickman/stickman_editor.gd`, `scripts/characters/stickman/stk_rig_adapter.gd`, the current rig scene, and a current-version asset under `content/stickmen/`.
+- `.prop`: `scripts/editors/prop/prop_file.gd`, `scripts/props/prop_anchor_data.gd`, `scripts/props/prop_visuals.gd`, and a representative asset under `content/props/`.
+- Animation: `scenes/characters/stickman/stickman_rig.tscn`, `scripts/tools/create_animations.gd`, and the runtime component that plays the requested animation.
+
+Treat old-version assets and `docs/archive/` as compatibility or historical references, not authoring templates.
+
+Clothing currently has no standalone format. Author clothing as layered shapes in the affected `.stk` body parts. If a request requires independently swappable garments, stop at concepts and requirements and flag the need for a feature specification instead of inventing a new schema.
+
+## Review workflow
+
+Create every unapproved deliverable under `content/review/artist/<request-slug>/`. Use descriptive, versioned filenames and never overwrite an existing production asset unless the user explicitly requests replacement.
+
+Each review bundle must contain:
+
+- the candidate `.stk`, `.prop`, or PNG deliverables;
+- a representative PNG preview or contact sheet;
+- `review.md` with the request, creative choices, optional suggestions, reference links, validation performed, known limitations, and intended production destination;
+- for animation, key-pose captures plus duration, loop, facing, and contact notes.
+
+Do not delete rejected variants automatically. Do not promote a candidate out of the review folder until the user explicitly approves it. On approval, promote `.prop` to `content/props/`, `.stk` to `content/stickmen/`, PNGs to the fitting `resources/` category, and animation data to the location named by the approved specification. Use a new filename unless replacement was explicitly approved.
+
+## Boundaries and validation
+
+Stay within asset and animation-authoring data. Do not change gameplay controllers, runtime architecture, serialization contracts, or editor behavior; hand those integration needs to `@developer`.
+
+Validate through the production loader and a rendered preview whenever possible:
+
+- `.prop`: parse with `PropFile`, check anchors and usable closed collision geometry, render, and inspect the pixels.
+- `.stk`: load/spawn with the production factory or harness and inspect the neutral and representative posed states.
+- Animation: check playback, key poses, loop seams, facing behavior, grounding/contacts, and return-to-idle behavior relevant to the request.
+- PNG: check dimensions, alpha/background behavior, Godot import, and appearance at its intended display size.
+
+Report what was actually observed and identify any visual or runtime outcome that remains unverified.
+"""

.codex/skills/asset-creation/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: asset-creation
+description: "Create or revise Stickman Studio props, stickmen, embedded clothing, PNG art, or character/prop animation by orchestrating the Artist and an explicit review-and-approval workflow."
+---
+
+# Asset Creation
+
+Use the `artist` subagent for project graphical-asset and animation work. This skill manages delegation, review, approval, and handoff; it does not replace the Artist's visual judgment.
+
+## Delegate to Artist
+
+Spawn `artist` with `agent_type: "artist"`. Reuse the same Artist for revisions while it is available. Tell it that other agents may share the workspace and that it must preserve unrelated changes.
+
+Pass the user's request, intended use, supplied image roles (reference versus edit target), relevant approved specification, requested format, and any style or technical constraints. Do not require the user to repeat information already available in the conversation or repository.
+
+Before delegating, read [references/project-formats.md](references/project-formats.md) for routing and source-of-truth locations. For production or revision work, also read [references/review-workflow.md](references/review-workflow.md).
+
+## Choose the deliverable path
+
+- Prefer native `.prop` or `.stk` for project line art that must remain editable and compatible with the existing editors/runtime.
+- Treat clothing as layered shapes embedded in affected `.stk` body parts. A reusable or swappable wardrobe is a separate feature requiring design and architecture work.
+- For requested bitmap art, have Artist use the `imagegen` skill and move project-bound results into its review bundle.
+- For animation, use the current rig and authoring representation. Do not create a new prop-animation schema merely to fulfill an asset request.
+- Artist may browse for supporting visual references without a separate confirmation. It must record source URLs and must not redistribute unlicensed reference art.
+
+## Review before promotion
+
+Artist writes unapproved work to `content/review/artist/<request-slug>/`. Present the preview, candidate paths, suggestions, and validation results to the user, then stop for approval or revision.
+
+Approval to create a draft is not approval to overwrite or promote a production asset. Promote only after explicit approval, preserve rejected variants until cleanup is requested, and use a versioned production filename unless replacement was explicitly requested.
+
+When implementation work is also needed, hand the approved asset paths and `review.md` integration notes to `developer`. Artist must not absorb gameplay, editor, serializer, or runtime architecture work.

.codex/skills/asset-creation/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Asset Creation"
+  short_description: "Create and review Stickman Studio artwork"
+  default_prompt: "Use $asset-creation to create a review-ready Stickman Studio asset from my description or reference image."

.codex/skills/asset-creation/references/project-formats.md

@@ -0,0 +1,35 @@
+# Project asset format routing
+
+Inspect these sources at execution time; do not copy their schemas into prompts because the formats evolve.
+
+## Stickmen and embedded clothing
+
+- Serializer and current version: `scripts/editors/stickman/stickman_editor.gd`
+- Runtime conversion: `scripts/characters/stickman/stk_rig_adapter.gd`
+- Rig target: `scenes/characters/stickman/stickman_rig.tscn`
+- Representative current assets: `content/stickmen/*.stk` (confirm the version before choosing a sample)
+- Visual harness: `scenes/tools/test_harness.tscn`
+
+An `.stk` owns ten body-part records and may contain multiple layered shapes per part. Clothing uses those layers until the project defines a separate wardrobe format. Preserve joint alignment, guide offsets, pivots, length metadata, body-part transforms, shape ordering, and the serializer's current version contract.
+
+## Props
+
+- Serializer/parser: `scripts/editors/prop/prop_file.gd`
+- Anchor normalization: `scripts/props/prop_anchor_data.gd`
+- Runtime visual/collision interpretation: `scripts/props/prop_visuals.gd`
+- Representative assets: `content/props/*.prop`
+- Visual editor: `scenes/editors/prop/prop_editor.tscn`
+
+Use current `PropFile` output, including shape styling and normalized anchors. Ensure at least one valid closed shape can provide runtime collision geometry when the prop is intended for stage use. Lines are visual/editor shapes and do not supply collision geometry.
+
+## Animation
+
+- Rig scene: `scenes/characters/stickman/stickman_rig.tscn`
+- Existing authoring tool: `scripts/tools/create_animations.gd`
+- Playback behavior: inspect the relevant component under `scripts/characters/stickman/`
+
+Stickman animations target the current rig's IK or animation targets, not `.stk` shape coordinates. Match the runtime clip name and locomotion/facing contract from the approved specification. For animated props, use only a representation already defined by the feature; otherwise return art direction, states, and timing requirements for architecture.
+
+## PNG art
+
+Use the `imagegen` skill for generated or edited raster art. Preserve alpha when transparency is requested. Approved PNGs go into the narrowest fitting `resources/` category; create a new `resources/art/<feature-or-kind>/` folder only if no current category fits.

.codex/skills/asset-creation/references/review-workflow.md

@@ -0,0 +1,36 @@
+# Asset review and promotion
+
+## Review bundle
+
+Use `content/review/artist/<request-slug>/`, where the slug is short, lowercase, and hyphenated. This tree is ignored by Git and is not scanned by the immediate-child prop and stickman library scanners.
+
+Keep:
+
+- versioned candidate files such as `briefcase-v1.prop` or `detective-coat-v2.stk`;
+- `preview.png` or a clearly named contact sheet;
+- animation key-pose captures when applicable;
+- `review.md`.
+
+`review.md` records:
+
+- the requested outcome and intended use;
+- which supplied images were references and which, if any, were edit targets;
+- creative choices and optional Artist suggestions;
+- external reference URLs and known license/usage notes;
+- candidate filenames and intended production destinations;
+- validation commands or scenes, observed results, and unverified outcomes.
+
+Do not copy browsed reference images into the bundle unless the user owns them or their license permits redistribution.
+
+## Approval boundary
+
+Show the preview and report the candidate paths. Wait for explicit approval before copying a candidate to a production location. Revision requests produce a new version rather than destroying the earlier candidate.
+
+After approval:
+
+- `.prop` -> `content/props/`
+- `.stk` -> `content/stickmen/`
+- PNG -> the relevant existing `resources/` category, or `resources/art/<kind>/` when necessary
+- animation -> the approved specification's rig/tool asset location
+
+Never overwrite an existing production file unless the user specifically approves replacement. Do not delete the review bundle unless the user asks for cleanup.

.codex/skills/spec-pipeline/SKILL.md

@@ -30,8 +30,16 @@ description: "Stickman Studio feature workflow: UI/UX and architecture specs, im
    - The spec states observable acceptance outcomes and the user path that produces each one. For interactions involving physics, timing, saving/loading, or multiple systems, name a small repeatable runtime scenario and what to measure; do not prescribe a test implementation unless it is needed to protect a specific behavior.
    - **STOP:** Wait for final user sign-off on the spec before invoking developer.
 
-5. **Phase 2: Implementation & Agent Verification**
+5. **Phase 1c: Conditional Art Production & Approval**
+   - After spec sign-off, inspect the accepted specification for explicit new graphical or animation deliverables. Skip this phase when none are required.
+   - Invoke `$asset-creation`, which delegates to `@artist`, with the signed-off specification, supplied reference images, intended asset type, and integration constraints.
+   - `@artist` creates validated candidates under `content/review/artist/<request-slug>/`, including a preview and `review.md`; it does not modify gameplay/runtime architecture or promote the candidates yet.
+   - Present the review bundle and **STOP** for user approval or revision. Do not invoke developer while required artwork remains unapproved.
+   - After explicit approval, promote the selected assets to their production locations and pass their paths plus integration notes to developer.
+
+6. **Phase 2: Implementation & Agent Verification**
    - `@developer` updates code and scenes using targeted diffs based on `docs/specs/[feature-name].md`.
+   - When Phase 1c ran, `@developer` consumes the approved asset paths and Artist integration notes; it does not silently replace approved artwork.
    - `@developer` runs Godot syntax/import checks and focused existing regression suites, then fixes failures.
    - `@developer` adds focused automated coverage where it can meaningfully verify the feature's observable acceptance outcomes. For cross-system or runtime behavior, construct a small repeatable scene or fixture (in memory or as a saved scene), use the real production spawning/input/action paths where practical, advance frames or physics ticks, and assert the resulting state. A check that nodes, signals, layers, or helper calls exist is insufficient when the requirement concerns what actually happens during play.
    - For visual or interactive acceptance criteria, establish the verification route before concluding Phase 2: run the affected scene in a render-capable GUI session, capture the states named in the spec, and inspect the rendered pixels. Record the scene/state, capture location, and what was observed. A successful launch, headless run, or screenshot command/file by itself does not prove visual correctness.
@@ -39,8 +47,8 @@ description: "Stickman Studio feature workflow: UI/UX and architecture specs, im
    - If the environment may not support rendering or input, try to establish whether a GUI, capture, or input-automation route is available; do not infer that it is unavailable from a headless run alone. If verification still cannot be performed, record what was attempted and the specific limitation, mark the affected acceptance outcomes unverified, and leave a focused, reproducible user check. Do not report the feature as fully agent-verified while required outcomes remain unverified.
    - `@developer` reruns the relevant checks after fixes and reports commands, pass/fail results, the measured behavior, and any unverified acceptance outcome. Do not claim a feature is verified from syntax checks or debug prints alone.
 
-6. **Phase 3: User Hand-off (Stop)**
+7. **Phase 3: User Hand-off (Stop)**
    - Present the implementation and agent verification evidence. Give the user only the remaining visual, usability, or environment-dependent checks to perform in the Godot Editor; clearly identify any acceptance outcome the agent could not verify.
 
-7. **Phase 4: Documentation (Triggered manually by user)**
+8. **Phase 4: Documentation (Triggered manually by user)**
    - Only call `@writer` after the user confirms: "Feature verified and working."

.gitignore

@@ -6,3 +6,4 @@ addons/
 *.tmp
 .opencode/skills/playwright-cli
 *.import
+content/review/artist/

AGENTS.md

@@ -12,6 +12,7 @@
 - Reusable UI, thumbnails, and `ContentPaths` live in `scripts/shared/`. Harnesses and rig-authoring scripts live in `scripts/tools/`.
 - The startup wrapper is `scenes/main.tscn`. Feature scenes are grouped under `scenes/editors/`, runtime stage scenes under `scenes/stage/`, stickman rigs under `scenes/characters/stickman/`, tools under `scenes/tools/`, and preserved old rigs under `scenes/legacy/`.
 - Project libraries live in `content/stickmen/`, `content/props/`, and `content/stages/`; fonts stay in `resources/fonts/`.
+- Unapproved Artist output lives under ignored `content/review/artist/<request-slug>/`. It must include a preview and `review.md`, does not enter the immediate-child prop/stickman library scans, and is promoted to the appropriate production folder only after explicit user approval.
 - Maintained docs live in `docs/{guides,architecture,specs,plans}/`; older plans and project references live in `docs/archive/`. Keep `README.md` and `AGENTS.md` at the root.
 - `ContentPaths.canonicalize(path)` maps only old project paths under `stickmen/`, `props/`, and `game_scenes/` into `content/`. It preserves unknown and external paths. Keep stage serialization and persisted paths routed through it when adding path-bearing data.
 

docs/ideas/feature_backlog.md

@@ -12,13 +12,29 @@ Priorities are recommendations for discussion, not a committed release schedule.
 
 3. **Functional doorways and doors** — **Status:** Idea · **Suggested priority:** Medium. **Intent:** Let placed door artwork serve as scenery, an open passage, or a closed wall door that blocks characters until opened; an open passage may optionally link to another scene and arrival point. **Rationale:** Children can reuse door art for different stage roles. Door open/close actions and scene travel add state and depend on the basic prop blocking model and dynamic scene loading; keep this as later work. Whether a doorway activates automatically or through a directed action remains open. **Connections:** `scripts/stage/stage_scene_io.gd`, `scripts/stage/trigger_area.gd`, `scripts/stage/trigger_registry.gd`, `scripts/editors/stage/sandbox_stage.gd`.
 
-4. **Vector stage backgrounds and wall finishes** — **Status:** Idea · **Suggested priority:** Medium. **Intent:** Let children build zoomable backdrop scenery such as brick or wooden room walls, with no collision. **Rationale:** A broad background wall should be quick to paint and sit behind the action; its material/look is independent from whether a wall is physically solid. Walls that block characters fit static structure/terrain behavior, while loose bricks and planks remain movable props. The current Stage has vector terrain and props but no saved background-art system. **Connections:** `scripts/terrain/terrain_block.gd`, `scripts/stage/stage_scene_io.gd`, `scripts/editors/stage/sandbox_stage.gd`.
+4. **Scenery, backgrounds, and vector surface finishes** — **Status:** Planned · **Suggested priority:** Medium. **Plan:** [Phase 19 — Scenery, Backgrounds, and Surface Finishes](../plans/phase_19_scenery_backgrounds_surface_finishes.md). **Intent:** Give the Stage a Scenery category with three distinct uses: a scene-wide Sky background, finite wall panels, and individually placed artwork. One static, detailed Sky preset fills the camera view and remains fixed throughout PLAY; the initial designed presets are Clear Day, Cloudy Day, Sunset, and Starry Night. Skies are adaptive scene themes rather than `.prop` files: the `.scene` saves a stable preset ID, while each preset composes crisp vector gradients, varied clouds or stars, and sun or moon details without visible panel edges or obvious repetition. Wall panels are resizable, colorable rectangles with finishes such as paint, brick, and wood; `.prop` artwork can be placed as inert scenery. Scenery artwork supports simple Far and Near layers so a muted skyline strip can sit behind colorful storefronts, houses, and trees while all scenery remains behind the action. New Scene offers Blank and one polished Town Street starter built from a Cloudy Day Sky, Far skyline, Near storefront/tree scenery, and sidewalk/road Ground; the starter creates an unsaved scene whose ordinary parts remain editable. User-created scenery artwork reuses the existing vector artwork editor and `.prop` format; no separate Scenery Editor or `.scenery` format is needed initially. The Stage placement category, saved in the `.scene`, determines whether the same artwork is inert Scenery or an interactive Prop. Visual floor finishes are chosen through the existing Ground tool and remain walkable terrain; initial outdoor looks include concrete/sidewalk and asphalt/pavement alongside indoor finishes. Wall panels are inert Scenery. Shared finish names, previews, and color controls make the relationship clear without merging their behavior. Choosing a Ground finish affects new placement, while an existing piece changes only when directly edited. Ground alone gains finishes in this version; Ramp and Step retain their current appearance and remain unconstrained for a possible future terrain redesign. The artwork catalog uses optional multi-select tags from a built-in list: Nature, Buildings, Walls, Roads & Paths, and Objects. The same tags may filter both Props and Scenery because they describe the drawing, while the Stage entry point determines behavior. **Rationale:** Children can build outdoor and indoor sets without changing movement or interaction. A scene-wide Sky avoids accidental edges during camera movement, wall panels can build finite rooms over it, and cutout artwork dresses either setting. Curated long vector assets and the editable Town Street starter make a layered outdoor scene immediately achievable without adding a general template system. Reusing the established multi-shape vector authoring workflow avoids duplicate editors, split libraries, and file conversion. Its child-facing presentation may evolve from Prop Editor toward Artwork Editor so prop-only physics and attachment controls do not dominate scenery creation. Scenery objects and wall panels are explicitly inert: they cannot block, support, move, be picked up or used, or participate in events. Sky sits farthest back, wall panels and Far scenery render over it, Near scenery renders over those, and terrain, props, and actors remain in front. Ground patterns align across adjacent painted pieces so a floor or road reads as one continuous surface. A dedicated scenery-editing flow should keep broad or overlapping background art from blocking normal selection. Artwork may appear in several browse categories, while older untagged artwork remains available under All Artwork and Unsorted. Solid walls remain terrain or future static structures, while loose bricks and planks remain props. Individual clouds, suns, or moons may still be `.prop` scenery cutouts, but whole adaptive skies are not. Animated weather, parallax, directed sky changes, user-authored sky themes, custom repeatable finish authoring, a larger starter gallery, inserting starters into existing scenes, and user-authored set templates are future workflows and do not require a scenery asset type now. **Connections:** `scripts/editors/prop/prop_editor.gd`, `scripts/editors/prop/prop_file.gd`, `scripts/props/prop_library.gd`, `scripts/editors/stage/stage_asset_browser.gd`, `scripts/terrain/terrain_block.gd`, `scripts/editors/stage/stage_terrain_painter.gd`, `scripts/stage/stage_scene_io.gd`, `scripts/editors/stage/stage_scene_adapter.gd`, `scripts/stage/stage_selection.gd`, `scripts/editors/stage/sandbox_stage.gd`, [Stage panel UI system](../specs/stage_panel_ui_system.md).
 
-5. **Use spots on props** — **Status:** Verified · **Suggested priority:** Medium. **Intent:** Let children mark a handle, button, or lever on a placed prop and direct a stickman to use it. **Rationale:** A Use spot is distinct from a grip anchor: the prop stays in place while the stickman reaches to it. Initial direction is an instance-level spot that produces a **Used prop** event after the stickman reaches and completes the interaction. Rules can respond to use of the whole prop or filter for one specific spot; the event identifies the stickman, prop, and spot. Built-in effects such as toggling a light are deferred. The Stage needs a clear standing/reach target, visible EDIT feedback, and an understandable unreachable cue. **Phase 17b is implemented and user-verified.** See the [Phase 17 — Props for Storytelling plan](../plans/phase_17_props_for_storytelling.md). **Connections:** `scripts/props/prop_anchor_data.gd`, `scripts/props/prop_block.gd`, `scripts/characters/stickman/stickman_prop_interactor.gd`, `scripts/stage/action_registry.gd`, `scripts/stage/trigger_registry.gd`.
+   **Sky scope:** Choosing a Sky preset changes only the sky; it does not tint or recolor terrain, props, characters, or other scenery.
 
-6. **Additional prop impact reactions** — **Status:** Idea · **Suggested priority:** Medium. **Intent:** Explore toppling or breaking props when they are struck or thrown. **Rationale:** The wobble response in **Phase 17c** is implemented and user-verified; this idea covers further reactions such as toppling or breaking, which remain future options. The wobble implementation is documented in the [Phase 17 plan](../plans/phase_17_props_for_storytelling.md). **Connections:** `scripts/props/prop_block.gd`, `scripts/editors/stage/sandbox_stage.gd`, `scripts/stage/trigger_registry.gd`.
+   **Indoor layering:** In addition to Far and Near backdrop scenery, an **On the floor** scenery placement lets inert rugs and floor markings render over finished Ground but beneath characters and interactive furniture. Ground remains in front of Far/Near scenery; floor decorations do not add collision or intercept ordinary object selection.
 
-7. **Group props into set pieces** — **Status:** Parked · **Suggested priority:** Low. **Intent:** Let children group objects for organization and moving together within one scene. **Rationale:** Deferred until later at the user's direction. Scene-only groups make arranging furnished sets faster. In PLAY, each item keeps its own physics and interaction; picking up one prop does not move the rest, and stopping PLAY returns the grouped items to their authored arrangement. Reusable set-piece assets are deferred. This is **Phase 17d** in the [Phase 17 — Props for Storytelling plan](../plans/phase_17_props_for_storytelling.md). **Connections:** `scripts/stage/stage_selection.gd`, `scripts/editors/stage/sandbox_stage.gd`, `scripts/stage/stage_scene_io.gd`.
+   **Starter scope:** New Scene offers **Blank Scene**, **Town Street**, and **Living Room**. Living Room combines a painted wall panel, wood Ground, Near wall decorations, an On the floor rug, and furniture Props; all ordinary parts remain editable in the new unsaved scene.
+
+   **Built-in content:** The starters require a curated vector asset pack: four Sky themes; repeatable wall/Ground finishes; Town skyline, storefront, and tree scenery; Living Room window, fireplace, clock, shelf/books, pictures, plant, and rug scenery; and couch, armchair, and coffee-table Props. Raster concepts may guide the art, but shipped cutouts use repo-native vector/`.prop` assets and the Sky/finish visuals must remain crisp through Stage zoom.
+
+   **Art tracking:** The accepted phase brief must include an asset production manifest with stable IDs, asset class/final format, tags/default layer, starter usage, behavior/collision expectation, source/rights, final location, visual acceptance, validation evidence, and status. Use **Needed → Concept ready → Art approved → Final vector ready → Integrated → Verified** so raster concepts cannot be mistaken for finished vector assets.
+
+   **Structural scope:** Multi-level traversal and structural stairways are a separate future feature. House artwork, wall panels, and decorative stairs do not create reliable walkable floors or routes between elevations.
+
+5. **Multi-level walkable scenes** — **Status:** Exploring · **Suggested priority:** Medium. **Intent:** Let children build a two-floor cutaway scene and direct a stickman with Move To from either floor to the other through one walkable stair connection. **Rationale:** This is separate follow-up work after the scenery feature, so navigation and locomotion changes do not delay visual set building. Upstairs/downstairs stories need reliable travel, correct-floor arrival, visible route feedback, and an understandable **No path upstairs** cue when disconnected; visual scenery alone cannot provide this. A narrow first slice uses editable lower and upper solid floors plus one child-facing Stairs connector, supports travel in both directions, and offers a way to frame both floors. The Stage has Ground, Ramp, and Step terrain with short-gap navigation links, but current movement and arrival are largely horizontal, so this needs a separate navigation and locomotion design. Keep Stairs independent from today's Ramp/Step taxonomy so their future redesign remains open. Defer additional floors, ladders, elevators, jumping routes, moving platforms, automatic camera direction, functional doors, and general building generation. **Connections:** `scripts/editors/stage/sandbox_stage.gd`, `scripts/characters/stickman/stickman_locomotion.gd`, `scripts/stage/stage_spawner.gd`, Move To backlog item 1, Scenery backlog item 4, Functional doorways backlog item 3.
+
+6. **Whole-scene visual filters** — **Status:** Idea · **Suggested priority:** Low. **Intent:** Let children give the complete scene a unified look such as sepia or black-and-white. **Rationale:** A filter can signal a memory, old film, or mood across the set and characters together. It is distinct from Sky, which changes only the background. Explore it after the scenery system is established, with special attention to keeping characters, selection cues, and Stage controls readable. **Connections:** `scripts/editors/stage/sandbox_stage.gd`, `scripts/stage/stage_scene_io.gd`, `scripts/editors/stage/stage_scene_adapter.gd`, Scenery backlog item 4.
+
+7. **Use spots on props** — **Status:** Verified · **Suggested priority:** Medium. **Intent:** Let children mark a handle, button, or lever on a placed prop and direct a stickman to use it. **Rationale:** A Use spot is distinct from a grip anchor: the prop stays in place while the stickman reaches to it. Initial direction is an instance-level spot that produces a **Used prop** event after the stickman reaches and completes the interaction. Rules can respond to use of the whole prop or filter for one specific spot; the event identifies the stickman, prop, and spot. Built-in effects such as toggling a light are deferred. The Stage needs a clear standing/reach target, visible EDIT feedback, and an understandable unreachable cue. **Phase 17b is implemented and user-verified.** See the [Phase 17 — Props for Storytelling plan](../plans/phase_17_props_for_storytelling.md). **Connections:** `scripts/props/prop_anchor_data.gd`, `scripts/props/prop_block.gd`, `scripts/characters/stickman/stickman_prop_interactor.gd`, `scripts/stage/action_registry.gd`, `scripts/stage/trigger_registry.gd`.
+
+8. **Additional prop impact reactions** — **Status:** Idea · **Suggested priority:** Medium. **Intent:** Explore toppling or breaking props when they are struck or thrown. **Rationale:** The wobble response in **Phase 17c** is implemented and user-verified; this idea covers further reactions such as toppling or breaking, which remain future options. The wobble implementation is documented in the [Phase 17 plan](../plans/phase_17_props_for_storytelling.md). **Connections:** `scripts/props/prop_block.gd`, `scripts/editors/stage/sandbox_stage.gd`, `scripts/stage/trigger_registry.gd`.
+
+9. **Group props into set pieces** — **Status:** Parked · **Suggested priority:** Low. **Intent:** Let children group objects for organization and moving together within one scene. **Rationale:** Deferred until later at the user's direction. Scene-only groups make arranging furnished sets faster. In PLAY, each item keeps its own physics and interaction; picking up one prop does not move the rest, and stopping PLAY returns the grouped items to their authored arrangement. Reusable set-piece assets are deferred. This is **Phase 17d** in the [Phase 17 — Props for Storytelling plan](../plans/phase_17_props_for_storytelling.md). **Connections:** `scripts/stage/stage_selection.gd`, `scripts/editors/stage/sandbox_stage.gd`, `scripts/stage/stage_scene_io.gd`.
 
 ## Entry format
 

docs/plans/phase_19_scenery_backgrounds_surface_finishes.md

@@ -0,0 +1,192 @@
+# Phase 19 — Scenery, Backgrounds, and Vector Surface Finishes
+
+> **Status:** Accepted product/design brief. Technical specifications and implementation remain to be developed through the spec-pipeline.
+> **Audience:** UI/UX, architecture, implementation, and art contributors.
+> **Purpose:** Define the child experience and the content required for indoor and outdoor sets. Rendering, file contracts, and GDScript APIs belong in later specifications.
+
+## Goal and audience
+
+Give children a quick way to make a Stage feel like a place: a town street, a living room, or their own setting. They should be able to choose an appealing sky, dress a scene with inert vector artwork, paint visual wall and Ground finishes, and then direct characters among ordinary props. The art remains crisp when the Stage camera pans or zooms.
+
+The audience is a child using the Sandbox Stage's EDIT, DIRECT, and PLAY modes. The central distinction should be easy to learn: **Scenery looks and stays put; Props can be part of the action; Ground is where stickmen walk.** An artwork asset can be used in more than one role; the Stage placement choice gives that copy its behavior.
+
+## Desired child outcome and story value
+
+- Start with **Blank Scene**, **Town Street**, or **Living Room**, then change any ordinary part of the starter instead of being locked into one background picture.
+- Build a layered outdoor set: cloudy sky, distant skyline, nearer shops and trees, sidewalk, and road. Characters remain readable and can move on the Ground.
+- Build an indoor set: painted wall, window, wall decorations, wood floor, rug, and furniture. A child can change the Sky seen through the starter's window without recoloring the room.
+- Use Far, Near, and On the floor scenery to express distance and staging without giving scenery collision or interactions. A child may draw a tree once and place it as either Scenery or a Prop in different scenes.
+- Save, reopen, revise, and replay the scene without losing the selected finishes, sky, artwork, or depth choices.
+
+The feature helps children establish story mood and place before directing dialogue and action. Sky and set dressing are visual choices. Functional doors, upper floors, and whole-scene color filters remain separate story mechanics.
+
+## Child flow and feedback
+
+### Start a scene
+
+**File → New** shows three large illustrated choices: **Blank Scene**, **Town Street**, and **Living Room**. The existing unsaved-work flow protects the current scene before any choice replaces it. Cancel returns to the existing work. A starter opens as a new **unsaved** scene with an editable suggested name; it does not insert itself into another scene or create a locked template instance.
+
+| New Scene choice | Initial composition | Child can change |
+| --- | --- | --- |
+| **Blank Scene** | Empty Stage with the existing neutral background and no placed Ground. | Sky, Scenery, Ground, characters, and Props from scratch. |
+| **Town Street** | Cloudy Day Sky; muted skyline in Far; colorful storefront, house, and tree artwork in Near; walkable Sidewalk and Asphalt Ground. | Sky, skyline strip, individual near artwork, Ground pieces and finishes, plus any added cast or Props. A skyline strip is one artwork placement, not independently editable buildings inside it. |
+| **Living Room** | Clear Day Sky; green painted wall panels around a window opening; Near window frame, fireplace/mantel, clock, shelf/books, picture, and plant; Wood Ground; an On the floor rug; couch, armchair, and coffee-table Props. | Every panel, artwork placement, rug, Ground piece, and furniture Prop. The wall panels leave an intentional gap beneath the window frame, so the selected Sky is actually visible. Moving or resizing the window and wall pieces may require adjusting more than one piece; this phase has no automatic window-cutting tool. |
+
+The starters demonstrate what children can make with the normal tools. Furniture in Living Room starts still with sensible blocking/support behavior where appropriate; the starter does not imply that characters can sit. A short cue may point children to Scenery after a starter opens, without covering the Stage.
+
+### Open Scenery
+
+The Stage palette gains **Scenery**. Its chooser has **Backgrounds** and **Artwork**:
+
+```text
+Scenery
+[ Backgrounds ]  [ Artwork ]
+
+Backgrounds: [ Sky ] [ Wall panel ]
+Artwork: [ All artwork ] [ Nature ] [ Buildings ] [ Walls ]
+         [ Roads & paths ] [ Objects ]
+```
+
+The Artwork choices use large previews. The tag filters describe the drawing, not what it can do. The built-in, optional, multi-select tag IDs are `nature`, `buildings`, `walls`, `roads`, and `objects`; the child-facing labels above can be refined without changing the stored meaning. One drawing may appear in several categories. **All artwork** includes old and untagged work; **Unsorted** can appear when there is untagged artwork to show. The same tags can filter the Props browser. The Props and Scenery entry points remain visibly distinct so children do not have to turn off interaction settings for every background item.
+
+The existing vector Prop Editor and `.prop` assets supply user-created artwork. Phase 19 should make that art discoverable from Scenery, including artwork that has no usable collision hull. There is no separate Scenery Editor or `.scenery` format in this phase. A later child-facing name such as Artwork Editor may better describe its broadened use; the UI/UX specification should decide how much prop-only material and attachment controls are shown during scenery authoring.
+
+### Choose a Sky
+
+**Backgrounds → Sky** shows four designed thumbnail cards: **Clear Day**, **Cloudy Day**, **Sunset**, and **Starry Night**. One tap changes the scene's Sky, and choosing another card changes it again. A Sky fills every camera view without an exposed edge; its clouds, sun, moon, and stars remain visually stable and crisp during pan and zoom. Each preset should be a considered composition rather than a flat color with an obvious repeated icon. The Sky remains fixed throughout PLAY.
+
+Changing Sky changes **only the sky**. It never tints or recolors Ground, wall panels, scenery artwork, characters, or Props. Sky is selected through its chooser, not by clicking a giant rectangle on the Stage.
+
+### Draw a wall panel
+
+**Backgrounds → Wall panel** offers **Paint**, **Brick**, and **Wood** finishes with a color choice. The child chooses a finish, drags from one corner to the other, sees a translucent preview of the intended size and pattern, and releases to place a finite rectangular panel. Snap may help edges meet. A selected panel can later be moved, resized, recolored, restyled, or erased; changing one panel does not silently alter others.
+
+The child-facing explanation should make its role clear: **“Looks like a wall. Stickmen can pass through.”** A wall panel is world-anchored backdrop art. It does not block a stickman, support a prop, move under physics, respond to Use, or trigger rules. A solid wall belongs to terrain or a later structural feature. When a panel grows, bricks or boards retain a sensible world-scale motif rather than stretching a small image.
+
+### Place and edit artwork
+
+The child opens **Artwork**, chooses a tag such as Nature, taps a drawing such as **Tree**, sees a ghost over the Stage, and taps to place it. Each Scenery placement offers a simple illustrated depth choice: **Far**, **Near** (default), or **On the floor**. Far supports distant silhouettes such as a skyline. Near supports storefronts, trees, window frames, and wall decor. On the floor supports rugs and markings that sit over finished Ground but under action. A child can change the depth later. Artwork placed through Scenery stays fixed and inert even if the same `.prop` can also be placed through Props as an interactive object.
+
+The authoritative visual order is:
+
+```text
+Sky
+  → wall panels
+  → Far scenery artwork
+  → Near scenery artwork
+  → walkable Ground
+  → On the floor scenery artwork
+  → characters and interactive Props (retaining their existing relative depth choices)
+```
+
+Every Scenery tier is visual only. Its depth never grants collision, support, pickup, Use spots, or event participation. An On the floor rug is visible above a wood Ground finish without covering furniture or the character's feet.
+
+**Edit Scenery** exposes the scenery pieces for selection. A clear outline and large handles let the child move and resize art, change its depth, or erase it; a wall panel also exposes Finish and Color. Broad panels must not steal clicks or box selections from characters, Ground, and Props in ordinary EDIT. Within Edit Scenery, a cutout in front of a panel should be easy to choose, and the panel must still be reachable through its exposed area, edge, or an overlapping-items choice. Sky remains in its own chooser. A visible Cancel closes a placement or sizing gesture before commit, and leaving Edit Scenery returns to ordinary selection. Selection and focus cannot rely on color alone.
+
+### Finish Ground and play
+
+The existing **Ground** palette entry gains a visual finish chooser. Picture swatches include **Paint**, **Brick**, **Wood**, **Grass**, **Dirt**, **Sidewalk**, and **Asphalt**. Paint, Brick, and Wood share recognizable names/previews with Wall panel where applicable; Ground-only outdoor finishes need not appear in the wall picker. Tap for one Ground piece or use the existing drag-paint gesture for a run. Ghosts show the selected look. A new choice affects **new placements only**. Selecting an existing Ground piece lets the child deliberately change that piece's finish. Adjacent painted pieces should read as one continuous surface, especially wood floors, sidewalks, and roads.
+
+Ground remains solid and walkable. This phase gives finishes only to **Ground**; it does not redesign or restyle Ramp and Step. Children can use Sidewalk and Asphalt Ground in Town Street and Wood Ground in Living Room. A Scenery wall panel or road marking never becomes a movement surface.
+
+In **PLAY**, edit handles and placement ghosts disappear. Sky and Scenery stay still; characters move on Ground; Props follow their own saved behavior settings. Stopping PLAY restores the authored arrangement for another take. Story playback and camera movement should preserve the intended visual layer order and the child's view of the action.
+
+## Included scope and exclusions
+
+Included in Phase 19: one fixed scene-wide Sky preset; four initial Sky designs; finite editable wall panels; inert `.prop` Scenery placements with Far, Near, and On the floor depth; built-in multi-select browse tags; Ground-only visual finishes; editable Blank/Town Street/Living Room New Scene choices; Scenery-safe selection; scene save/reopen and legacy defaults; and the built-in vector content listed below.
+
+Excluded from Phase 19: a new Scenery Editor or `.scenery` file; child-authored repeatable finish patterns or reusable whole-Sky themes; animated weather, parallax, or directed Sky transitions; whole-scene filters such as sepia or black-and-white; functional doors or scene travel; automatic window cutouts or glass; Ramp/Step finishes or terrain redesign; inserting a starter into an existing scene; user-authored reusable set templates; and functional stairs or multi-level travel. [Multi-level walkable scenes](../ideas/feature_backlog.md) and [whole-scene visual filters](../ideas/feature_backlog.md) are separate future ideas, not Phase 19 work.
+
+## Asset production manifest
+
+This is the authoritative content checklist for the two starters and the shared pickers. The initial status of **every** row is **Needed**. Progress through **Needed → Concept ready → Art approved → Final vector ready → Integrated → Verified**. A raster sketch may reach **Concept ready**; it is not a final `.prop`, Sky theme, or repeatable vector finish. Final cutouts must be repo-native vector/`.prop` artwork, and Sky/finish visuals must remain crisp through Stage zoom. Art contributors may use raster concept images as reference, then produce final assets in coordination with implementation.
+
+In the tables, **TBD** in Source/rights means the creator, reference provenance, and license or permission still need recording. **TBD** in Final location and Evidence means those fields must be filled as content is produced. For each row, validation evidence should include a thumbnail or Sky/finish preview, the asset in the Stage at normal and zoomed views, and save/reopen of its starter use where applicable. Stable IDs identify deliverables; they are not prescribed file names or runtime contracts.
+
+### Adaptive Sky themes
+
+| Stable ID | Class / final format | Tags / default layer | Starter use | Behavior / collision | Status | Source / rights | Visual acceptance | Final location / definition | Validation evidence |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `sky_clear_day` | Adaptive vector Sky theme; not `.prop` | N/A; Sky | Living Room; picker | Scene-wide, static; none | Needed | TBD | Appealing blue depth and varied light cloud/sun detail; window gap reads clearly; no edge on pan. | TBD | TBD |
+| `sky_cloudy_day` | Adaptive vector Sky theme; not `.prop` | N/A; Sky | Town Street; picker | Scene-wide, static; none | Needed | TBD | Layered, varied clouds leave town silhouettes readable; no obvious tile or edge. | TBD | TBD |
+| `sky_sunset` | Adaptive vector Sky theme; not `.prop` | N/A; Sky | Picker | Scene-wide, static; none | Needed | TBD | Warm atmospheric color and sun/cloud composition remain distinct from Clear Day without tinting scene objects. | TBD | TBD |
+| `sky_starry_night` | Adaptive vector Sky theme; not `.prop` | N/A; Sky | Picker | Scene-wide, static; none | Needed | TBD | Dark graduated sky, varied stars, and moon remain legible while foreground contrast survives. | TBD | TBD |
+
+### Repeatable vector surface finishes
+
+These are finish definitions and previews, not ordinary Props. Ground finishes change appearance without changing Ground's walkability; wall finishes stay inert.
+
+| Stable ID | Class / final format | Tags / default layer | Starter use | Behavior / collision | Status | Source / rights | Visual acceptance | Final location / definition | Validation evidence |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `finish_wall_paint` | Vector wall finish | N/A; wall panel | Living Room; picker | Inert panel; none | Needed | TBD | Smooth green room wall and other chosen colors without seams at panel edges. | TBD | TBD |
+| `finish_wall_brick` | Repeatable vector wall finish | N/A; wall panel | Picker | Inert panel; none | Needed | TBD | Bricks keep coherent size and joins as panel is resized. | TBD | TBD |
+| `finish_wall_wood` | Repeatable vector wall finish | N/A; wall panel | Picker | Inert panel; none | Needed | TBD | Boards read as wood at common Stage zoom and do not stretch with the panel. | TBD | TBD |
+| `finish_ground_paint` | Vector Ground finish | N/A; Ground | Picker | Solid, walkable Ground | Needed | TBD | Plain color is clean and visually distinct from wall-only backdrop. | TBD | TBD |
+| `finish_ground_brick` | Repeatable vector Ground finish | N/A; Ground | Picker | Solid, walkable Ground | Needed | TBD | Neighboring pieces form a continuous brick surface. | TBD | TBD |
+| `finish_ground_wood` | Repeatable vector Ground finish | N/A; Ground | Living Room; picker | Solid, walkable Ground | Needed | TBD | Wood plank floor reads continuously beneath rug and furniture. | TBD | TBD |
+| `finish_ground_grass` | Repeatable vector Ground finish | N/A; Ground | Picker | Solid, walkable Ground | Needed | TBD | Grassy surface is readable and not noisy behind feet. | TBD | TBD |
+| `finish_ground_dirt` | Repeatable vector Ground finish | N/A; Ground | Picker | Solid, walkable Ground | Needed | TBD | Earthy surface remains distinct from Grass at thumbnail and Stage size. | TBD | TBD |
+| `finish_ground_sidewalk` | Repeatable vector Ground finish | N/A; Ground | Town Street; picker | Solid, walkable Ground | Needed | TBD | Light concrete sidewalk forms a broad, aligned run beneath shops. | TBD | TBD |
+| `finish_ground_asphalt` | Repeatable vector Ground finish | N/A; Ground | Town Street; picker | Solid, walkable Ground | Needed | TBD | Darker road contrasts with sidewalk while preserving visible character edges. | TBD | TBD |
+
+### Reusable Scenery artwork
+
+Each item below is a `.prop` vector artwork asset offered through Scenery. Its Scenery placement has no collision or interaction even if the artwork is also available through Props. Final visual-only art must not require an invented solid collision shape merely to enter the Scenery catalog.
+
+| Stable ID | Class / final format | Tags / default layer | Starter use | Behavior / collision | Status | Source / rights | Visual acceptance | Final location / definition | Validation evidence |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `art_city_skyline` | Vector `.prop` cutout | Buildings; Far | Town Street ×1 | Inert; none | Needed | TBD | Long, muted overlapping building silhouette reads as distant and leaves cloud sky visible. | TBD | TBD |
+| `art_storefront` | Vector `.prop` cutout | Buildings; Near | Town Street ×1 or more | Inert; none | Needed | TBD | Colorful, readable shop front contrasts with skyline; repeat use does not look like one flat strip. | TBD | TBD |
+| `art_town_house` | Vector `.prop` cutout | Buildings; Near | Town Street ×1 or more | Inert; none | Needed | TBD | House silhouette and palette differ clearly from storefront at normal zoom. | TBD | TBD |
+| `art_tree` | Vector `.prop` cutout | Nature; Near | Town Street ×2 or more | Inert; none | Needed | TBD | Friendly, readable crown/trunk; repeated copies tolerate size and position variation. | TBD | TBD |
+| `art_window_frame` | Vector `.prop` cutout | Walls, Buildings; Near | Living Room ×1 | Inert; none | Needed | TBD | Frame is transparent at its center and aligns over the wall-panel gap to reveal actual Sky. | TBD | TBD |
+| `art_fireplace_mantel` | Vector `.prop` cutout | Walls, Objects; Near | Living Room ×1 | Inert; none | Needed | TBD | Fireplace and mantel read clearly as decoration without suggesting this asset itself blocks movement. | TBD | TBD |
+| `art_wall_clock` | Vector `.prop` cutout | Walls, Objects; Near | Living Room ×1 | Inert; none | Needed | TBD | Clock reads at room scale without tiny illegible markings. | TBD | TBD |
+| `art_bookshelf` | Vector `.prop` cutout | Objects, Walls; Near | Living Room ×1 | Inert; none | Needed | TBD | Shelf, books, and plant details remain legible without dense tracing. | TBD | TBD |
+| `art_framed_picture` | Vector `.prop` cutout | Objects, Walls; Near | Living Room ×1 or more | Inert; none | Needed | TBD | Clear frame and image contrast on green paint; reuse can vary size/position. | TBD | TBD |
+| `art_potted_plant` | Vector `.prop` cutout | Nature, Objects; Near | Living Room ×1 | Inert; none | Needed | TBD | Leaf and pot shapes remain distinct from wall and furniture. | TBD | TBD |
+| `art_rug` | Vector `.prop` cutout | Objects; On the floor | Living Room ×1 | Inert; none | Needed | TBD | Visible over Wood Ground and below furniture/feet; border survives zoom. | TBD | TBD |
+
+### Interactive furniture Props
+
+These are `.prop` assets placed through Props in Living Room. Their authored shape and placement roles must support the stated behavior. The same artwork may still be offered as inert Scenery when deliberately placed through Scenery.
+
+| Stable ID | Class / final format | Tags / default layer | Starter use | Behavior / collision | Status | Source / rights | Visual acceptance | Final location / definition | Validation evidence |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `prop_couch` | Vector `.prop` furniture | Objects; Prop depth per placement | Living Room ×1 | Still, appropriately character-blocking; valid collision | Needed | TBD | Comfortable couch silhouette sized for stickman and room; no implied Sit action. | TBD | TBD |
+| `prop_armchair` | Vector `.prop` furniture | Objects; Prop depth per placement | Living Room ×1 | Still, appropriately character-blocking; valid collision | Needed | TBD | Distinct chair silhouette, matching couch style and character scale. | TBD | TBD |
+| `prop_coffee_table` | Vector `.prop` furniture | Objects; Prop depth per placement | Living Room ×1 | Still, can support small props; valid collision | Needed | TBD | Tabletop/support reads clearly and leaves rug visible. | TBD | TBD |
+
+Existing built-in crate and ball artwork may be used in Town Street if an interactive object benefits that starter; no new interactive town asset is required to achieve its visual reference. The artist should establish a coherent cartoon style and scale against the live stickman. Far art is quieter than Near art; outlines and silhouettes must remain clear at selector-thumbnail size and normal Stage zoom. Avoid excessive vector point counts, hard-to-read microdetail, and busy contrast behind character faces or speech bubbles. The source/rights field must distinguish original art, licensed sources, and generated raster concepts. Reference art is not automatically licensed final content.
+
+## Success criteria
+
+1. A child can create Town Street from New Scene, recognize the intended Sky/skyline/shops/trees/sidewalk/road composition at the default view, move or remove any placed piece, save it, reopen it, and keep the same look and behavior.
+2. A child can create Living Room from New Scene, see the actual selected Sky through its window gap, change the Sky without tinting the room, restyle the wall or Wood Ground, move the rug and furniture independently, and save/reopen the revised set.
+3. A child can place one `.prop` drawing through Scenery and through Props and understand that the two copies behave differently. The Scenery copy never blocks, supports, moves, is picked up or used, or triggers an event in PLAY.
+4. Far skyline, Near buildings/trees, Ground, On the floor rug, and Props preserve their intended order through pan, zoom, PLAY, stop, and reload. Character and speech readability survives the four Sky styles and common finishes.
+5. Ordinary EDIT selection still reaches foreground characters, Props, and Ground over broad panels. Edit Scenery makes every cutout and panel discoverable and correctable; placement and resize can be canceled before commit. Labels, icons, outlines, and focus reveal state without depending on color alone.
+6. Wall panel and Ground finish choices preview correctly; wall patterns do not stretch as panels resize, and adjacent Ground pieces do not show distracting pattern restarts. Changing a palette finish does not repaint existing pieces; a selected piece can be changed deliberately.
+7. Older `.scene` documents retain their prior neutral background and Ground appearance when opened. Older untagged `.prop` assets remain visible in All artwork, and a missing referenced Scenery asset yields a visible recovery cue rather than silently removing the child's placement.
+8. Every required manifest item reaches **Verified**, with source/rights and final location recorded. A raster concept alone cannot satisfy a final vector content requirement.
+
+## Current project context, risks, and dependencies
+
+- The Stage currently has a World, camera, optional world-space grid, registry-driven palette, Ground/Ramp/Step terrain, Props, and stickmen. Ground is a solid `TerrainBlock`; its drag painter creates independent blocks. Phase 19 must preserve Ground walkability and avoid treating Scenery panels as terrain.
+- The current `.scene` save boundary is `StageSceneIO` with mapping in `StageSceneAdapter`. It stores terrain, Props, stickmen, and areas but no Sky, wall panels, or Scenery placements. The accepted design requires additive saved appearance and placement data with legacy defaults; the architect will decide schema and migration details. Persist artwork references through the project's `ContentPaths` conventions.
+- The `.prop` format and Prop Editor already author multi-shape vector art. `PropLibrary` currently rejects custom artwork without valid closed collision geometry. Visual-only Scenery must accept legitimate artwork without fake physics. The architect and UI/UX lead should resolve how the same art catalog serves both placement routes and how old untagged art stays discoverable.
+- Stage selection currently uses World-object bounds and an overlapping-object chooser. Large wall panels and floor art can otherwise catch almost every click or box selection. A dedicated, forgiving Scenery edit flow and predictable hit order are product requirements. The approved [Stage panel UI system](../specs/stage_panel_ui_system.md) supplies the in-stage inspector visual contract; adapt it for selected Scenery/Ground controls where it fits.
+- Finite panels, tiled vector finishes, and detailed Sky motifs must stay crisp and performant across Stage zoom and camera pan. Ground pieces need aligned world-scale patterns. The Town Street and Living Room references should guide composition and mood, not be treated as final licensed assets.
+- The two starters require the manifest content as real deliverables. Missing art, inconsistent scale, or raster-only placeholders would leave a child with a visually incomplete feature even if the controls work.
+
+## Remaining questions for the spec-pipeline
+
+These are design and architecture tasks for the specification stage, not unresolved user choices about Phase 19's product goal:
+
+1. What exact UI presents Backgrounds, Artwork tags, placement layer, Ground finish, and Edit Scenery without crowding the existing Stage palette? Define keyboard, touch, narrow-viewport, dismissal, and undo/cancel behavior using the established Stage panel patterns.
+2. How will an adaptive Sky fill unbounded camera views while keeping motifs stable and detailed, and how will wall and Ground finishes keep repeatable pattern scale and alignment through resizing, drag painting, and zoom?
+3. What saved scene and optional `.prop` tag fields, validation, migration defaults, missing-art recovery, and starter creation flow preserve existing documents and the same artwork's independent Scenery/Prop placements?
+4. How will selected panels, cutouts, rugs, Ground, and ordinary objects remain reachable where bounds overlap, including the window gap and a room-sized wall?
+5. Which asset production workflow turns concepts into final vector content, records provenance, checks collision only for interactive Props, and advances each manifest row through integration and verification?
+
+The [live feature backlog](../ideas/feature_backlog.md) tracks the separate follow-up work, including multi-level walkable scenes and whole-scene visual filters.