Implement Phase 17a Prop Roles UI/UX Specification and associated functionality

- Added UI/UX specification for prop roles and set down mechanics in phase 17a.
- Created `PropStageRoles` script to manage normalized behavior for props, including depth, motion, and collision settings.
- Introduced `StagePhysicsPolicy` for shared physics configurations related to props and actors.
- Developed comprehensive tests for prop roles, including default settings, legacy migration, serialization, and runtime behavior.
- Ensured proper handling of set down actions, including clearance and orientation preservation.

.codex/agents/architect.toml

@@ -13,6 +13,15 @@ You are the Lead Systems Architect specializing in Godot 4 and idiomatic GDScrip
 3. **Design:** Define API payload shapes, static GDScript type hints, node hierarchies, and signal flows.
 4. **Log:** Append trade-offs to `docs/architecture/tech_debt_and_optimizations.md`.
 
+### Shared Stage inspector UI
+For an in-stage selected-object inspector, first read `docs/specs/stage_panel_ui_system.md`
+and inspect `scripts/shared/stage_ui/` plus the `stage_panels` theme tokens. Use the existing
+`StageInspectorPanel`, `StagePanelChoiceGroup`, and `StagePanelToggleRow` contracts as the
+starting point; propose extending them before adding duplicate panel controls or styling.
+State explicitly in the spec which shared pieces the feature adopts or extends. The kit is
+currently scoped to in-stage inspector cards, so evaluate dialogs and other editor workflows
+on their own interaction needs instead of forcing this component hierarchy onto them.
+
 ---
 
 ## TWO-PHASE WORKFLOW

.codex/agents/uiux.toml

@@ -7,6 +7,14 @@ sandbox_mode = "read-only"
 developer_instructions = """
 ## 1. Kid-Friendly UI Guardrails (10-Year-Old Persona)
 
+* **Shared Stage Inspector UI:** Before proposing an in-stage selected-object inspector, read
+  `docs/specs/stage_panel_ui_system.md` and inspect the existing controls in
+  `scripts/shared/stage_ui/`. Treat the shared shell, choice group, toggle row, and
+  `stage_panels` theme tokens as the default visual and interaction system. Prefer extending
+  them over inventing a parallel panel style. The system is scoped to in-stage inspectors;
+  for dialogs or other editor workflows, reuse its visual principles only when their layout
+  and interaction model fit, and call out any exception.
+
 * **Touch & Click Target Rules:**
   * Minimum pointer hit-target: **44×44 logical pixels** (never build tiny 16px/24px buttons).
   * Control heights (buttons, dropdowns, rows) must obey `button_min_height` tokens from the theme.
@@ -56,4 +64,4 @@ Output a structured spec covering:
 * Theme & Color Tokens (Active state colors, badge accents)
 * Cursor & Canvas Feedback (Floating labels, ghost markers, trajectory lines)
 * Kid-Friendly Copy Map (Exact string replacements for all visual labels)
-"""
+"""

.codex/skills/feature-ideation/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: feature-ideation
+description: "Review possible Stickman Studio features with the Designer, compare value and risks, then help a chosen idea become a saved design brief."
+---
+
+# Feature Ideation
+
+Use this skill when the user wants to compare, discuss, or plan one or more future Stickman Studio features. Keep the work at the product/design level. The skill has two distinct stages: review possible features and stop for the user's choice; later, after discussion and the user's readiness, have Designer create a phase brief and report its path.
+
+## Delegate to Designer
+
+Use the `designer` subagent for feature evaluation and design discussion. Spawn it with `agent_type: "designer"` and `model: "gpt-6-sol"`; that role is configured for GPT-6-sol. Pass the user's goal and candidate features in the first message, along with the relevant project context, so Designer can begin from the stated goal. Reuse the same designer agent during follow-up turns when available. If it is no longer available, spawn another with a concise summary of the candidates, decisions, and unresolved questions.
+
+Have Designer inspect relevant current project docs and code before judging fit, dependencies, or likely implementation issues. Prefer maintained docs and current code; treat archived roadmap material as history, not a priority list. Do not invent certainty where details are unknown: label assumptions and open questions.
+
+When the discussion involves a new in-stage selected-object inspector, have Designer review
+`docs/specs/stage_panel_ui_system.md` and the current shared controls in
+`scripts/shared/stage_ui/`. Treat them as the established panel design to extend where it fits;
+do not assume they apply unchanged to dialogs or other editor workflows.
+
+## Stage 1: Compare ideas, then stop
+
+When the user provides one or more candidate features:
+
+1. Identify the child-facing outcome and the project's current behavior relevant to each feature. Ask the user for more input only if there is no usable feature goal; otherwise let Designer state assumptions and uncertainties in the review.
+2. Ask Designer to assess each candidate's user value, fit with the project direction, relevant dependencies, likely product/design/technical issues, and relative priority. Ask for a clear recommendation on what to discuss first, with reasons. Avoid treating priority as a release commitment.
+3. Ask Designer for one to three additional feature ideas that fit the project, with a short rationale and any important dependency or risk.
+4. Keep `docs/ideas/feature_backlog.md` current as ideas become clear: add or update substantive user candidates and Designer-suggested ideas, preserving existing entries, rationale, links, and priorities that remain valid. Use its existing status and entry conventions. Do not duplicate an existing idea, promote an idea to Verified without evidence, or import the archived roadmap wholesale.
+5. Present a compact comparison, normally a table with feature, expected child outcome/value, fit/dependencies, likely issues, and suggested priority. Then show the recommended next feature and the additional ideas. Link the backlog if it changed.
+6. End with the question **“Which feature would you like to discuss further?”** and stop. Do not start the deeper discussion, write a phase plan, invoke the architect/developer, or begin implementation in this turn.
+
+## Stage 2: Discuss the chosen feature
+
+After the user chooses a feature, use Designer as a product-design partner to refine the goal, intended audience, child flow and feedback, scope, success criteria, risks, and relevant project references. Keep the discussion conversational; ask only focused questions that materially affect the idea. Reflect the user's answers in the discussion and keep its backlog entry marked `Exploring` until a brief is accepted. Do not write a phase plan merely because the user chose the idea or asked to talk about it.
+
+Treat the user's clear statement that they are ready to work on the discussed, sufficiently settled feature as acceptance to prepare a Designer handoff. If scope or a key product decision is still unresolved, ask Designer to identify it and resolve it with the user before drafting. If the user has not supplied the phase number, ask exactly **“What phase number will this be?”** and wait. If the user already supplied it, use that number without asking again.
+
+## Stage 3: Write and hand off the brief
+
+Once the user is ready and the phase number is known, have Designer create the accepted product/design brief at `docs/plans/phase_<number>_<feature_slug>.md`, following `docs/plans/README.md`. The brief should cover the goal and audience, desired child outcome, behavior/flow and feedback, story or directing value where relevant, success criteria, included and excluded scope, known risks/dependencies, project references, and remaining questions for the spec-pipeline. Keep architecture/API decisions for the architect's later technical specification in `docs/specs/`.
+
+Do not overwrite an existing phase brief without the user's direction. Confirm the resulting file exists, update the matching backlog entry to `Planned` with a link to the brief, then tell the user where the plan is using a clickable local file link. Stop there; this skill creates the design handoff, not the technical spec or implementation.

.codex/skills/feature-ideation/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Feature Ideation"
+  short_description: "Help with Feature Ideation tasks"

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

@@ -7,6 +7,7 @@ description: "Lean implementation loop: UI/UX (Ideas -> Spec) -> Architect (Clar
 
 1. **Phase 0a: UI/UX Proposal & Alternative Ideas (User-Facing Features Only)**
    - `@uiux` analyzes the user's initial idea for cognitive friction, accessibility, and kid-friendliness.
+   - For an in-stage selected-object inspector, `@uiux` first reviews `docs/specs/stage_panel_ui_system.md` and the current shared controls under `scripts/shared/stage_ui/`; proposals should build on that system unless the interaction needs justify a specific exception.
    - `@uiux` pitches **1–3 alternative interaction approaches** (e.g., comparing floating tooltips vs. top-center banners, custom cursor reticles, or streamlined dialogs).
    - `@uiux` highlights the most intuitive option with `[Recommended]` and asks up to 3 clarification questions.
    - `@uiux` **STOP:** Waits for user feedback/selection before writing the UI spec.
@@ -15,9 +16,11 @@ description: "Lean implementation loop: UI/UX (Ideas -> Spec) -> Architect (Clar
 2. **Phase 0b: UI Spec Generation**
    - User approves an option or provides feedback.
    - `@uiux` outputs the UI/UX specification (control layouts, widget behaviors, visual feedback states, and cursor logic).
+   - For Stage inspector work, name which shared components and theme tokens the design uses or proposes to extend. Treat dialogs and other editor panels as separate workflows unless their interaction model fits the inspector kit.
 
 3. **Phase 1a: Architecture Proposal & Clarification**
    - `@architect` analyzes existing patterns and the Phase 0b UI/UX specification.
+   - For Stage inspector work, `@architect` inspects the shared panel implementation and theme as well as the design spec, and identifies reuse or justified extension before proposing new controls.
    - `@architect` pitches 1–3 Godot best-practice implementation options and asks up to 3 clarification questions with `[Recommended]` choices.
    - `@architect` stops without writing the spec file yet.