feat: add generated scene skill platform hardening

docs/superpowers/specs/2026-04-19-scene-skill-102-final-materialization-design.md

@@ -0,0 +1,98 @@
+# Scene Skill 102 Final Materialization Design
+
+> Date: 2026-04-19
+> Parent Framework: `2026-04-19-scene-skill-102-full-coverage-framework-plan.md`
+> Upstream Status: `framework-auto-pass = 102 / 102`
+
+## Intent
+
+Freeze a single final skill asset set for the current 102 scenes.
+
+The previous framework work proved that all 102 scenes can be adapted at the framework layer, but the generated skill packages are spread across multiple follow-up directories. Before static, mock, or production-like validation, the project needs one canonical materialized skill set.
+
+## Key Decision
+
+Do not clean or overwrite existing `examples/*` follow-up directories.
+
+Instead, create a new isolated materialization root:
+
+`examples/scene_skill_102_final_materialization_2026-04-19`
+
+Rationale:
+
+1. previous `examples/*` directories are audit artifacts for earlier plans;
+2. deleting them would destroy provenance;
+3. a new root gives validation a stable input set;
+4. final materialization can be repeated without mutating history.
+
+## Inputs
+
+1. official board: `tests/fixtures/generated_scene/scene_execution_board_2026-04-18.json`
+2. final framework rollup: `tests/fixtures/generated_scene/scene_skill_102_framework_closure_rollup_2026-04-19.json`
+3. scene source root: `D:/desk/智能体资料/全量业务场景/一平台场景`
+4. generator binary: `cargo run --bin sg_scene_generate`
+
+## Required Hygiene
+
+Before generation, build a clean materialization input manifest.
+
+The official board is the status authority, but it may contain historical encoding or control-character artifacts. The materialization manifest must therefore validate:
+
+1. exactly 102 rows;
+2. unique scene ids;
+3. source directory exists for each row;
+4. scene name used for generation is stable;
+5. unsafe control characters are not propagated into final manifest fields.
+
+## Output Layout
+
+```text
+examples/scene_skill_102_final_materialization_2026-04-19/
+  skills/
+    sweep-001-scene/
+      SKILL.toml
+      SKILL.md
+      scene.toml
+      scripts/
+      references/
+        generation-report.json
+        generation-report.md
+  manifest/
+    scene_skill_102_final_materialization_manifest_2026-04-19.json
+```
+
+Repository-level fixture outputs:
+
+1. `tests/fixtures/generated_scene/scene_skill_102_final_materialization_manifest_2026-04-19.json`
+2. `tests/fixtures/generated_scene/scene_skill_102_final_materialization_failures_2026-04-19.json`
+
+Report:
+
+1. `docs/superpowers/reports/2026-04-19-scene-skill-102-final-materialization-report.md`
+
+## Success Criteria
+
+The materialization is successful when:
+
+1. all 102 scene ids are attempted;
+2. all 102 have a generated skill directory;
+3. each generated skill directory has required files;
+4. each generated report has `readiness.level = A` or otherwise has a named failure in the failures asset;
+5. the manifest is the only input to later static/mock validation plans.
+
+## Non-Goals
+
+1. no production execution;
+2. no mock validation;
+3. no static validation beyond presence/manifest checks;
+4. no deletion of old `examples/*`;
+5. no official board mutation;
+6. no new family or runtime implementation.
+
+## Follow-Up
+
+After materialization succeeds, the next roadmap should be:
+
+`102 static and mock validation roadmap`
+
+That roadmap must consume the final materialization manifest, not scattered follow-up directories.