@zigrivers/scaffold 3.4.1 → 3.5.1

package/content/pipeline/specification/modding-ugc-spec.md

@@ -0,0 +1,116 @@
+---
+name: modding-ugc-spec
+description: Specify mod API surface, packaging format, sandboxing, versioning, content moderation, and distribution channels
+summary: "Specifies the modding and user-generated content system — mod API surface and capability tiers, packaging format and validation, runtime sandboxing, compatibility and versioning strategy, content moderation pipeline, and distribution channels (Steam Workshop, mod.io, local file-based) with platform certification implications."
+phase: "specification"
+order: 872
+dependencies: [system-architecture]
+outputs: [docs/modding-spec.md]
+conditional: "if-needed"
+reads: [game-design-document]
+knowledge-base: [game-modding-ugc]
+---
+
+## Purpose
+Specify the modding and user-generated content (UGC) system — the APIs,
+packaging formats, runtime boundaries, and distribution infrastructure that
+allow players and third-party creators to extend the game safely and
+sustainably.
+
+Modding support is an architectural commitment, not a feature toggle. The mod
+API surface determines what creators can change (textures, levels, gameplay
+rules, UI), the packaging format determines how mods are distributed and
+validated, and the sandboxing model determines what damage a malicious or
+buggy mod can inflict. These decisions cascade into security requirements,
+platform certification constraints, and long-term versioning strategy.
+
+Three categories of modding complexity exist, each with different engineering
+costs:
+
+1. **Asset replacement**: Swapping textures, models, audio, or localization
+   strings. Lowest risk — mods cannot execute code, only replace data.
+2. **Content authoring**: Creating new levels, quests, items, or game entities
+   using structured data formats (JSON, YAML, custom editors). Medium risk —
+   mods define data that the engine interprets, with schema validation as the
+   safety boundary.
+3. **Scripted mods**: Running custom logic via a scripting layer (Lua, C#,
+   WASM). Highest risk — mods execute code, requiring sandboxing, resource
+   limits, and capability-based permission models.
+
+This specification must also address the tension between openness and platform
+certification: console platforms restrict arbitrary code execution and require
+content moderation for UGC, which constrains what modding features can ship on
+each platform.
+
+## Conditional Evaluation
+Enable when: the project config indicates modding support (`hasModding` is
+true) — the GDD describes mod support, workshop integration, user-generated
+content, level editors, or any system allowing players to create, share, or
+install content beyond the shipped game.
+
+Skip when: the game has no modding or UGC features — players can only
+experience developer-created content. Games with cosmetic customization
+(character creators, paint jobs) that use built-in assets do not require a
+modding specification.
+
+## Inputs
+- docs/system-architecture.md (required) — engine architecture, asset loading pipeline, scripting runtime, security boundaries
+- docs/plan.md (required) — target platforms informing modding feasibility per platform (PC vs console vs mobile)
+- docs/game-design.md (optional, forward-read) — moddable systems, expected mod types, community creation goals
+- docs/security.md (optional, forward-read) — threat model, sandboxing requirements, anti-cheat considerations for modded game states
+
+## Expected Outputs
+- docs/modding-spec.md — mod API surface, packaging format, sandboxing model,
+  versioning strategy, content moderation pipeline, and distribution channel
+  integration
+
+## Quality Criteria
+- (mvp) Mod capability tiers defined: which game systems are moddable (asset replacement, content authoring, scripted logic) with explicit boundaries for each tier
+- (mvp) Packaging format specified: mod manifest schema, directory structure, required metadata (name, version, author, compatibility range, permissions)
+- (mvp) Runtime sandboxing model documented: what mods can and cannot access (filesystem, network, memory), resource limits (CPU time, memory allocation), and failure isolation (one mod crash does not crash the game)
+- (mvp) Mod loading and conflict resolution: load order management, asset override priority, incompatible mod detection, graceful degradation when mods fail validation
+- (mvp) Distribution channel integration for at least one channel: Steam Workshop, mod.io, or local file-based sideloading
+- (deep) Versioning and compatibility strategy: semantic versioning for mod API, compatibility matrix (which game versions support which mod API versions), migration tooling for mod authors when API breaks
+- (deep) Content moderation pipeline: automated scanning (file type validation, size limits, known-malware signatures), community reporting, manual review queue, takedown process
+- (deep) Platform certification analysis: which modding features are permitted per platform (PC unrestricted, console UGC requires certification-compliant moderation, mobile requires app store policy compliance)
+- (deep) Mod development toolkit: editor tools, debugging support, documentation generation, sample mods, mod template scaffolding
+- (deep) Multiplayer mod compatibility: mod-matching in matchmaking (only connect players with identical mod sets), server-authoritative mod validation, anti-cheat interaction with modded game states
+
+## Methodology Scaling
+- **deep**: Full modding specification covering all three capability tiers,
+  comprehensive sandboxing with capability-based permissions, multi-channel
+  distribution, content moderation pipeline, platform certification analysis,
+  versioning strategy with migration tooling, mod development toolkit, and
+  multiplayer mod compatibility. 15-25 pages.
+- **mvp**: Mod capability tiers, packaging format, basic sandboxing, single
+  distribution channel, and load-order conflict resolution. 4-8 pages.
+- **custom:depth(1-5)**:
+  - Depth 1: asset replacement tier only with local file-based sideloading.
+  - Depth 2: add content authoring tier with packaging format and manifest schema.
+  - Depth 3: add scripted mod tier with sandboxing model, conflict resolution, and second distribution channel.
+  - Depth 4: add content moderation pipeline, versioning strategy, platform certification analysis, and mod development toolkit.
+  - Depth 5: full specification with multiplayer mod compatibility, automated mod testing infrastructure, mod analytics (install rates, crash rates, popularity), and community curation tools.
+
+## Mode Detection
+Check for docs/modding-spec.md. If it exists, operate in update mode: read
+existing modding spec and diff against current system architecture and GDD
+modding requirements. Preserve existing API surface definitions, packaging
+format, and distribution channel integrations. Update sandboxing model if
+security requirements changed. Add new capability tiers if GDD expanded
+moddable systems.
+
+## Update Mode Specifics
+- **Detect prior artifact**: docs/modding-spec.md exists
+- **Preserve**: mod API surface definitions, packaging format and manifest
+  schema, sandboxing model, distribution channel integrations, versioning
+  strategy, content moderation pipeline
+- **Triggers for update**: system architecture changed asset loading or
+  scripting runtime, GDD expanded or narrowed moddable systems, security
+  requirements changed sandboxing constraints, target platforms changed
+  (affects platform certification analysis), distribution channel added or
+  removed
+- **Conflict resolution**: if platform certification requirements conflict
+  with desired modding features (e.g., console prohibiting scripted mods),
+  document the per-platform capability matrix explicitly — never silently
+  reduce PC modding capability to match console restrictions; instead, define
+  platform-specific mod capability tiers with clear feature parity documentation

package/content/pipeline/specification/online-services-spec.md

@@ -0,0 +1,104 @@
+---
+name: online-services-spec
+description: Specify identity/auth, leaderboards, matchmaking, entitlements, remote config, moderation, and cloud save
+summary: "Specifies online service infrastructure — identity and authentication, leaderboards, matchmaking, entitlements and DLC, remote config, content moderation, and cloud save — bridging system architecture with platform-specific service requirements."
+phase: "specification"
+order: 871
+dependencies: [system-architecture]
+outputs: [docs/online-services-spec.md]
+conditional: "if-needed"
+reads: [game-design-document, netcode-spec]
+knowledge-base: [game-networking, game-liveops-analytics]
+---
+
+## Purpose
+Specify the online services layer that sits between the game client and backend
+infrastructure. Online services are the platform-facing systems that handle
+player identity, persistent state, social features, and content delivery —
+distinct from the netcode layer (which handles real-time gameplay
+synchronization) and the economy layer (which handles virtual currency and
+progression).
+
+Every online service has platform-specific requirements: Xbox Live, PlayStation
+Network, Steam, Epic Online Services, Apple Game Center, and Google Play Games
+each have mandatory integration points for identity, achievements, entitlements,
+and cloud saves. Abstracting these behind a unified service layer prevents
+platform-specific code from spreading throughout the game codebase.
+
+This specification covers: identity and authentication (platform SSO, cross-play
+identity linking), leaderboards (submission, anti-cheat validation, seasonal
+resets), matchmaking (skill-based, region-based, queue management), entitlements
+and DLC (purchase verification, content unlocking), remote configuration
+(feature flags, A/B testing, live tuning), content moderation (chat filtering,
+reporting, sanctions), and cloud save (conflict resolution, migration).
+
+## Conditional Evaluation
+Enable when: the game requires any online service beyond local storage — online
+multiplayer, leaderboards, cloud saves, in-app purchases requiring server
+verification, remote configuration, or any feature requiring server
+communication outside of real-time gameplay.
+
+Skip when: the game is entirely offline with no online features — no
+leaderboards, no cloud saves, no server-verified purchases, no remote config.
+Games using only local save files and platform-native achievement systems
+(which are handled by platform SDKs without custom backend) do not need this
+specification.
+
+## Inputs
+- docs/system-architecture.md (required) — backend service boundaries and data flow
+- docs/plan.md (required) — target platforms informing platform-specific service requirements
+- docs/game-design.md (optional, forward-read) — multiplayer modes, social features, progression requiring persistence
+- docs/netcode-spec.md (optional, forward-read) — matchmaking requirements, session management, connection lifecycle
+
+## Expected Outputs
+- docs/online-services-spec.md — service specifications for identity, leaderboards,
+  matchmaking, entitlements, remote config, moderation, and cloud save
+
+## Quality Criteria
+- (mvp) Identity and authentication flow documented: platform SSO integration per target platform, session token lifecycle, guest-to-account upgrade path
+- (mvp) Every online service specifies: API contract (request/response), failure modes and fallback behavior, data ownership and retention policy
+- (mvp) Cloud save strategy documented: save format, conflict resolution (last-write-wins, merge, user-choice), platform-specific cloud save API mapping
+- (mvp) Entitlement verification flow documented: purchase validation, content unlocking, receipt verification per platform
+- (deep) Leaderboard specification: submission validation (anti-cheat checks before write), ranking algorithm, seasonal reset strategy, regional vs global boards
+- (deep) Matchmaking specification: skill rating system (Elo, Glicko-2, TrueSkill), queue management, region selection, party handling, backfill strategy
+- (deep) Remote configuration specification: feature flag schema, A/B test segmentation, rollout strategy, emergency kill switches
+- (deep) Content moderation specification: text filtering (blocklist + ML classification), player reporting workflow, sanction tiers (warning, mute, temp ban, permanent ban), appeal process
+- (deep) Cross-play identity linking: account merging strategy, entitlement portability, platform TOS compliance for cross-platform purchases
+- (deep) Service degradation strategy: graceful fallback when individual services are unavailable (offline mode, cached leaderboards, local save fallback)
+
+## Methodology Scaling
+- **deep**: Full online services specification covering all seven service
+  domains with platform-specific integration details, failure mode analysis,
+  cross-play considerations, moderation pipeline, and service degradation
+  strategy. 15-25 pages.
+- **mvp**: Identity/auth, cloud save, and entitlement verification for primary
+  platform. 4-8 pages.
+- **custom:depth(1-5)**:
+  - Depth 1: identity/auth flow and cloud save strategy for primary platform only.
+  - Depth 2: add entitlement verification and basic leaderboard submission.
+  - Depth 3: add matchmaking specification, remote config, and multi-platform identity mapping.
+  - Depth 4: add content moderation pipeline, cross-play identity linking, and service degradation strategy.
+  - Depth 5: full specification with A/B testing infrastructure, analytics event taxonomy for online services, and platform certification compliance checklist.
+
+## Mode Detection
+Check for docs/online-services-spec.md. If it exists, operate in update mode:
+read existing spec and diff against current system architecture and platform
+targets. Preserve existing service API contracts, identity flows, and cloud
+save strategy. Update matchmaking if netcode-spec changed session management.
+Add services for new platforms added to target list.
+
+## Update Mode Specifics
+- **Detect prior artifact**: docs/online-services-spec.md exists
+- **Preserve**: identity/auth flow, cloud save conflict resolution strategy,
+  entitlement verification flow, leaderboard ranking algorithm, matchmaking
+  skill rating system, moderation sanction tiers
+- **Triggers for update**: system architecture changed backend service
+  boundaries, target platforms changed (new platform requires new SSO
+  integration), netcode-spec changed matchmaking or session management,
+  GDD added social features or new online modes, economy-design added
+  server-verified purchases
+- **Conflict resolution**: if platform requirements conflict across target
+  platforms (e.g., different cloud save APIs with incompatible merge
+  strategies), document the conflict and propose an abstraction layer that
+  accommodates all platforms; never implement platform-specific behavior
+  without the abstraction boundary

package/content/pipeline/specification/review-economy.md

@@ -0,0 +1,87 @@
+---
+name: review-economy
+description: Review economy design for inflation trajectories, exploit vectors, ethical monetization, and legal compliance
+summary: "Multi-pass review of economy design checking inflation/deflation trajectories, exploit vectors, ethical monetization compliance, pay-to-win detection, legal compliance per market, progression-monetization separation, and live-service sustainability."
+phase: "specification"
+order: 869
+dependencies: [economy-design]
+outputs: [docs/reviews/specification-review-economy.md]
+conditional: "if-needed"
+reads: [game-design-document]
+knowledge-base: [review-game-economy, review-step-template, multi-model-review-dispatch]
+---
+
+## Purpose
+Multi-pass review of the economy design targeting economy-specific failure modes:
+unchecked inflation or deflation trajectories, exploitable currency conversion
+paths, predatory monetization patterns, pay-to-win competitive advantages,
+legal non-compliance per target market, broken progression-monetization
+separation, and unsustainable live-service economy plans.
+
+Economy bugs discovered in live service cost orders of magnitude more to fix
+than those caught at design time — a duplication exploit discovered post-launch
+can destroy an economy in hours, and rebalancing a live economy with real-money
+purchases has legal implications. This review catches these failures before
+implementation begins.
+
+At depth 4+, dispatches to external AI models (Codex, Gemini) for
+independent review validation.
+
+## Conditional Evaluation
+Enable when: economy-design is enabled (i.e., the game has virtual currencies,
+resource systems, loot tables, or monetization mechanics). If economy-design
+runs, this review must follow it.
+
+Skip when: economy-design is skipped (i.e., the game has no resource economy).
+No economy design means no economy review.
+
+## Inputs
+- docs/economy-design.md (required) — economy specification to review
+- docs/game-design.md (required) — core loop and progression mechanics for cross-reference
+- docs/plan.md (required) — target markets and business model for legal compliance verification
+
+## Expected Outputs
+- docs/reviews/specification-review-economy.md — findings and resolution log
+- docs/economy-design.md — updated with fixes
+- docs/reviews/economy/review-summary.md (depth 4+) — multi-model review synthesis
+- docs/reviews/economy/codex-review.json (depth 4+, if available) — raw Codex findings
+- docs/reviews/economy/gemini-review.json (depth 4+, if available) — raw Gemini findings
+
+## Quality Criteria
+- (mvp) Inflation/deflation trajectory verified: currency generation and removal rates produce a stable or managed economy over the player lifecycle
+- (mvp) Exploit vectors audited: duplication, overflow, conversion rate manipulation, and timing exploits identified and mitigated at design level
+- (mvp) Ethical monetization verified: no pay-to-win advantages in PvP contexts, spending limit awareness mechanisms present, no predatory patterns targeting vulnerable players
+- (mvp) Every finding categorized P0-P3 with specific section and issue. Severity definitions: P0 = Breaks downstream work. P1 = Prevents quality milestone. P2 = Known tech debt. P3 = Polish.
+- (mvp) Fix plan documented for all P0/P1 findings; fixes applied to economy-design.md and re-validated
+- (deep) Legal compliance verified per target market: probability disclosure, age-gating, spending limits, loot box classification
+- (deep) Progression-monetization separation verified: removing all real-money paths leaves a satisfying progression experience
+- (deep) Live-service sustainability checked: seasonal economy additions do not compound inflation, event currencies have clear expiration or conversion paths
+- (deep) Economy simulation formulas verified for mathematical consistency (no negative balances, no infinite loops, no unreachable milestones)
+- (mvp) Review report includes explicit Readiness Status section
+- (mvp) Downstream readiness confirmed — no unresolved P0 or P1 findings remain
+- (depth 4+) Multi-model findings synthesized: Consensus, Majority, or Divergent with user escalation
+
+## Methodology Scaling
+- **deep**: All 7 review passes (Inflation Trajectory, Exploit Vectors,
+  Ethical Monetization, Pay-to-Win Detection, Legal Compliance,
+  Earn Rate vs Engagement Projection, Sink Effectiveness Analysis).
+  Multi-model review dispatched to Codex and Gemini if available, with
+  graceful fallback to Claude-only enhanced review.
+- **mvp**: Three passes — Inflation Trajectory, Exploit Vectors, and Ethical
+  Monetization only.
+- **custom:depth(1-5)**:
+  - Depth 1: two passes — Inflation Trajectory and Exploit Vectors only.
+  - Depth 2: three passes — add Ethical Monetization compliance.
+  - Depth 3: five passes — add Pay-to-Win Detection and Legal Compliance.
+  - Depth 4: all 7 passes + one external model (if CLI available).
+  - Depth 5: all 7 passes + multi-model with reconciliation.
+
+## Mode Detection
+Re-review mode if previous review exists. If multi-model review artifacts exist
+under docs/reviews/economy/, preserve prior findings still valid.
+
+## Update Mode Specifics
+- **Detect**: `docs/reviews/specification-review-economy.md` exists with tracking comment
+- **Preserve**: prior findings still valid, resolution decisions, multi-model review artifacts
+- **Triggers**: upstream artifact changed since last review (compare tracking comment dates)
+- **Conflict resolution**: previously resolved findings reappearing = regression; flag and re-evaluate

package/content/pipeline/specification/review-game-ui.md

@@ -0,0 +1,73 @@
+---
+name: review-game-ui
+description: Review game UI specification for completeness, accessibility coverage, and controller navigation
+summary: "Multi-pass review of game UI spec checking HUD clarity, menu completeness, controller accessibility, settings coverage, FTUE effectiveness, state machine completeness, and platform shell compliance."
+phase: "specification"
+order: 864
+dependencies: [game-ui-spec]
+outputs: [docs/reviews/specification-review-game-ui.md]
+conditional: null
+reads: [game-design-document, game-accessibility, input-controls-spec]
+knowledge-base: [review-game-ui, game-accessibility, review-step-template, multi-model-review-dispatch]
+---
+
+## Purpose
+Review the game UI specification for completeness, accessibility compliance,
+and controller navigation coverage. This is a multi-pass review targeting
+game-UI-specific failure modes: HUD information overload, incomplete menu
+hierarchies, missing controller navigation paths, inadequate settings coverage,
+ineffective FTUE design, incomplete UI state machines, and platform shell
+non-compliance.
+
+At depth 4+, dispatches to external AI models (Codex, Gemini) for
+independent review validation.
+
+## Inputs
+- docs/game-ui-spec.md (required) — spec to review
+- docs/game-design.md (required) — for mechanic-to-HUD coverage verification
+- docs/game-accessibility.md (required) — for accessibility requirement compliance
+- docs/input-controls-spec.md (required) — for controller navigation consistency
+
+## Expected Outputs
+- docs/reviews/specification-review-game-ui.md — findings and resolution log
+- docs/game-ui-spec.md — updated with fixes
+- docs/reviews/game-ui/review-summary.md (depth 4+) — multi-model review synthesis
+- docs/reviews/game-ui/codex-review.json (depth 4+, if available) — raw Codex findings
+- docs/reviews/game-ui/gemini-review.json (depth 4+, if available) — raw Gemini findings
+
+## Quality Criteria
+- (mvp) Every GDD mechanic with player-visible feedback has a corresponding HUD element or UI flow
+- (mvp) Controller navigation verified: every menu screen is reachable and has defined focus order
+- (mvp) Accessibility requirements from game-accessibility.md are reflected in UI spec (colorblind palette, font scaling, subtitle rendering)
+- (mvp) Settings screen covers all five minimum categories (gameplay, video, audio, controls, accessibility)
+- (mvp) Every finding categorized P0-P3 with specific screen, element, and issue
+- (mvp) Fix plan documented for all P0/P1 findings; fixes applied to game-ui-spec.md and re-validated
+- (deep) FTUE teaches all core loop mechanics — no mechanic requires undocumented player discovery
+- (deep) UI state machines cover all transitions (no orphaned states, no missing error/disconnect states)
+- (deep) Platform shell compliance verified (console certification UI requirements)
+- (mvp) Review report includes explicit Readiness Status section
+- (mvp) Downstream readiness confirmed — no unresolved P0 or P1 findings remain
+- (depth 4+) Multi-model findings synthesized: Consensus, Majority, or Divergent with user escalation
+
+## Methodology Scaling
+- **deep**: Full multi-pass review covering HUD clarity, menu completeness,
+  controller navigation, accessibility compliance, FTUE effectiveness, state
+  machine completeness, and platform shell compliance. Multi-model review
+  dispatched if available.
+- **mvp**: HUD coverage and controller navigation pass only.
+- **custom:depth(1-5)**:
+  - Depth 1: two passes — HUD-to-mechanic coverage and controller navigation reachability.
+  - Depth 2: four passes — add settings completeness and accessibility compliance.
+  - Depth 3: six passes — add FTUE effectiveness and UI state machine completeness.
+  - Depth 4: all 7 passes (add platform shell compliance) + one external model (if CLI available).
+  - Depth 5: all 7 passes + multi-model review with reconciliation.
+
+## Mode Detection
+Re-review mode if previous review exists. If multi-model review artifacts exist
+under docs/reviews/game-ui/, preserve prior findings still valid.
+
+## Update Mode Specifics
+- **Detect**: `docs/reviews/specification-review-game-ui.md` exists with tracking comment
+- **Preserve**: prior findings still valid, resolution decisions, multi-model review artifacts
+- **Triggers**: upstream artifact changed since last review (compare tracking comment dates)
+- **Conflict resolution**: previously resolved findings reappearing = regression; flag and re-evaluate

package/content/pipeline/specification/save-system-spec.md

@@ -0,0 +1,116 @@
+---
+name: save-system-spec
+description: Specify persistence strategy, serialization format, save slots, cloud save, corruption detection, anti-tamper, and migration
+summary: "Specifies the save system — what data is persisted (adapts by persistence level), serialization format, save slot management, cloud save per platform, auto-save strategy, corruption detection and recovery, anti-tamper measures, and save format migration strategy for patches and DLC."
+phase: "specification"
+order: 873
+dependencies: [system-architecture, domain-modeling]
+outputs: [docs/save-system-spec.md]
+conditional: "if-needed"
+reads: [economy-design, narrative-bible]
+knowledge-base: [game-save-systems]
+---
+
+## Purpose
+Specify the save system — the persistence layer that captures, stores,
+restores, and migrates player state across sessions. The save system sits at
+the intersection of gameplay design (what matters enough to persist), engine
+architecture (when and how to serialize), platform requirements (cloud save
+APIs, storage quotas), and security (anti-tamper for competitive or economy-
+critical data).
+
+Save system design decisions cascade widely. The serialization format affects
+load times and save file size. The persistence granularity affects what players
+lose on crash vs. what they can exploit via save-scumming. The migration
+strategy determines whether patches and DLC can ship without corrupting
+existing saves. Cloud save conflict resolution determines whether players lose
+progress when switching devices.
+
+Three persistence levels exist, each requiring different engineering depth:
+
+1. **Minimal persistence**: Settings, preferences, and high scores only. No
+   gameplay state survives between sessions beyond configuration.
+2. **Session persistence**: Game progress is saved at checkpoints or manual
+   save points. The canonical model for single-player narrative and campaign
+   games.
+3. **Continuous persistence**: Game state is persisted in near-real-time
+   (auto-save, server-authoritative state). Required for live-service games,
+   MMOs, and games where progress loss is unacceptable.
+
+This specification adapts its depth to the project's persistence level — a
+minimal-persistence game needs a settings serializer, not a cloud save
+conflict resolution strategy.
+
+## Conditional Evaluation
+Enable when: the project config indicates persistence is not `none` — the
+game saves any player state between sessions, whether settings, progress,
+inventory, narrative choices, world state, or any data that must survive
+application exit and relaunch.
+
+Skip when: persistence is `none` — the game is entirely session-based with no
+state carried between launches. Pure arcade games, party games with no
+unlock systems, and ephemeral multiplayer-only experiences with server-
+authoritative state (no client save) do not need a save system specification.
+
+## Inputs
+- docs/system-architecture.md (required) — data flow, storage layer, serialization strategy, platform abstraction
+- docs/domain-models/ (required) — entity definitions, relationships, and state that must be persisted
+- docs/plan.md (required) — target platforms informing cloud save APIs and storage quotas
+- docs/economy-design.md (optional, forward-read) — currency balances, inventory, transaction history requiring tamper-resistant persistence
+- docs/narrative-bible.md (optional, forward-read) — narrative state, branching flags, relationship values, quest progress requiring persistence
+
+## Expected Outputs
+- docs/save-system-spec.md — persistence scope, serialization format, save slot
+  management, cloud save integration, auto-save strategy, corruption detection,
+  anti-tamper measures, and migration strategy
+
+## Quality Criteria
+- (mvp) Persistence scope defined: explicit list of what is saved (player progress, inventory, settings, world state) and what is not saved (transient visual state, cached data, derived values) with rationale for each exclusion
+- (mvp) Serialization format specified: binary vs text (JSON, MessagePack, FlatBuffers, custom), versioning header, compression strategy, target save file size budget
+- (mvp) Save slot management: number of slots (or slotless), slot metadata (timestamp, playtime, thumbnail, location), manual save vs auto-save slot allocation
+- (mvp) Auto-save strategy: trigger conditions (checkpoint reached, zone transition, timer interval), player notification, performance budget for serialization (max frame time impact)
+- (mvp) Corruption detection: checksum or hash validation on load, recovery strategy (fall back to previous save, partial recovery, notify player), write-ahead or atomic write to prevent partial-write corruption
+- (deep) Cloud save integration per platform: Steam Cloud, PlayStation Plus Cloud, Xbox Cloud Saves, iCloud, Google Play saved games — API mapping, conflict resolution strategy (last-write-wins, merge, user-choice), quota management
+- (deep) Anti-tamper measures: signed save files for economy-critical or competitive data, server-side validation for live-service games, tamper detection response (flag vs reject vs re-sync)
+- (deep) Save format migration strategy: version field in save header, forward-compatible schema design, migration functions per version increment, rollback plan if migration fails, DLC-aware save extension (new fields without breaking base game saves)
+- (deep) Performance profiling: serialization/deserialization benchmarks per platform, async save to prevent hitching, memory budget for save buffers, streaming save for large world states
+- (deep) Platform certification compliance: required save behaviors per platform (PS5 Activities integration, Xbox Quick Resume state, Switch suspend/resume), mandatory user-facing save indicators
+
+## Methodology Scaling
+- **deep**: Full save system specification covering persistence scope analysis,
+  serialization format with benchmarks, save slot management, cloud save per
+  platform with conflict resolution, auto-save with performance profiling,
+  corruption detection and recovery, anti-tamper for competitive/economy data,
+  migration strategy with DLC awareness, and platform certification compliance.
+  15-25 pages.
+- **mvp**: Persistence scope, serialization format, save slots, auto-save
+  strategy, and corruption detection. 4-8 pages.
+- **custom:depth(1-5)**:
+  - Depth 1: persistence scope and serialization format only (settings and minimal state).
+  - Depth 2: add save slot management, auto-save strategy, and basic corruption detection.
+  - Depth 3: add cloud save for primary platform, anti-tamper for economy data, and save format versioning.
+  - Depth 4: add multi-platform cloud save with conflict resolution, migration strategy with DLC awareness, and performance profiling.
+  - Depth 5: full specification with platform certification compliance, save analytics (save frequency, corruption rates, cloud sync failures), automated save system testing framework, and save-game replay for debugging.
+
+## Mode Detection
+Check for docs/save-system-spec.md. If it exists, operate in update mode:
+read existing spec and diff against current domain model and system
+architecture. Preserve existing serialization format, save slot structure,
+and cloud save strategy. Update persistence scope if domain model added new
+entities. Update migration strategy if save format version needs incrementing.
+
+## Update Mode Specifics
+- **Detect prior artifact**: docs/save-system-spec.md exists
+- **Preserve**: serialization format, save slot structure, cloud save conflict
+  resolution strategy, anti-tamper approach, existing migration functions
+- **Triggers for update**: domain model changed entity definitions requiring
+  new persisted fields, system architecture changed storage layer or platform
+  abstraction, economy-design added new currency types or inventory systems,
+  narrative-bible added new branching flags or quest state, target platforms
+  changed (new platform requires new cloud save integration)
+- **Conflict resolution**: if domain model changes require new persisted fields
+  that would break existing save format, document the migration path explicitly
+  — specify the new version number, the migration function from previous
+  version, default values for new fields, and the testing strategy for
+  migration; never add fields to the save format without incrementing the
+  version and providing a migration path

package/dist/cli/commands/adopt.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"adopt.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/adopt.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,aAAa,EAAQ,MAAM,OAAO,CAAA;AAYhD,UAAU,SAAS;IACjB,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,IAAI,CAAC,EAAE,OAAO,CAAA;IACd,OAAO,CAAC,EAAE,OAAO,CAAA;IACjB,IAAI,CAAC,EAAE,MAAM,CAAA;IACb,KAAK,CAAC,EAAE,OAAO,CAAA;IACf,SAAS,EAAE,OAAO,CAAA;CACnB;AAED,QAAA,MAAM,YAAY,EAAE,aAAa,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,SAAS,CAuGnE,CAAA;AAED,eAAe,YAAY,CAAA"}
+{"version":3,"file":"adopt.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/adopt.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,aAAa,EAAQ,MAAM,OAAO,CAAA;AAahD,UAAU,SAAS;IACjB,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,IAAI,CAAC,EAAE,OAAO,CAAA;IACd,OAAO,CAAC,EAAE,OAAO,CAAA;IACjB,IAAI,CAAC,EAAE,MAAM,CAAA;IACb,KAAK,CAAC,EAAE,OAAO,CAAA;IACf,SAAS,EAAE,OAAO,CAAA;CACnB;AAED,QAAA,MAAM,YAAY,EAAE,aAAa,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,SAAS,CA+HnE,CAAA;AAED,eAAe,YAAY,CAAA"}

package/dist/cli/commands/adopt.js

@@ -1,5 +1,6 @@
 import fs from 'node:fs';
 import path from 'node:path';
+import yaml from 'js-yaml';
 import { findProjectRoot } from '../middleware/project-root.js';
 import { resolveOutputMode } from '../middleware/output-mode.js';
 import { createOutputContext } from '../output/context.js';
@@ -82,6 +83,28 @@ const adoptCommand = {
                     stateManager.saveState(state);
                 }
             }
+            // Write detected game config into config.yml
+            if (!dryRun && adoptResult.projectType) {
+                const configPath = path.join(projectRoot, '.scaffold', 'config.yml');
+                let raw = {};
+                if (fs.existsSync(configPath)) {
+                    try {
+                        const content = fs.readFileSync(configPath, 'utf8');
+                        const parsed = yaml.load(content);
+                        if (typeof parsed === 'object' && parsed !== null && !Array.isArray(parsed)) {
+                            raw = parsed;
+                        }
+                    }
+                    catch { /* start fresh if parse fails */ }
+                }
+                const project = (raw['project'] ?? {});
+                project['projectType'] = adoptResult.projectType;
+                if (adoptResult.gameConfig) {
+                    project['gameConfig'] = adoptResult.gameConfig;
+                }
+                raw['project'] = project;
+                fs.writeFileSync(configPath, yaml.dump(raw), 'utf8');
+            }
             const resultData = {
                 mode: adoptResult.mode,
                 artifacts_found: adoptResult.artifactsFound,
@@ -89,6 +112,8 @@ const adoptCommand = {
                 steps_remaining: adoptResult.stepsRemaining,
                 methodology: adoptResult.methodology,
                 dry_run: dryRun,
+                ...(adoptResult.projectType && { project_type: adoptResult.projectType }),
+                ...(adoptResult.gameConfig && { game_config: adoptResult.gameConfig }),
             };
             if (outputMode === 'json') {
                 output.result(resultData);

package/dist/cli/commands/adopt.js.map

@@ -1 +1 @@
-{"version":3,"file":"adopt.js","sourceRoot":"","sources":["../../../src/cli/commands/adopt.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,MAAM,SAAS,CAAA;AACxB,OAAO,IAAI,MAAM,WAAW,CAAA;AAC5B,OAAO,EAAE,eAAe,EAAE,MAAM,+BAA+B,CAAA;AAC/D,OAAO,EAAE,iBAAiB,EAAE,MAAM,8BAA8B,CAAA;AAChE,OAAO,EAAE,mBAAmB,EAAE,MAAM,sBAAsB,CAAA;AAC1D,OAAO,EAAE,YAAY,EAAE,MAAM,8BAA8B,CAAA;AAC3D,OAAO,EAAE,WAAW,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAA;AACtE,OAAO,EAAE,mBAAmB,EAAE,MAAM,2CAA2C,CAAA;AAC/E,OAAO,EAAE,qBAAqB,EAAE,MAAM,mBAAmB,CAAA;AACzD,OAAO,EAAE,WAAW,EAAE,MAAM,wBAAwB,CAAA;AAWpD,MAAM,YAAY,GAAsD;IACtE,OAAO,EAAE,OAAO;IAChB,QAAQ,EAAE,yCAAyC;IACnD,OAAO,EAAE,CAAC,KAAoC,EAAE,EAAE;QAChD,OAAO,KAAK;aACT,MAAM,CAAC,MAAM,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,QAAQ,EAAE,wBAAwB,EAAE,CAAC;aACtE,MAAM,CAAC,SAAS,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,yBAAyB,EAAE,CAAC;aAC3F,MAAM,CAAC,OAAO,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,qCAAqC,EAAE,CAAC;aACrG,MAAM,CAAC,QAAQ,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,QAAQ,EAAE,eAAe,EAAE,CAAC;aAC/D,MAAM,CAAC,MAAM,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,iBAAiB,EAAE,CAAC;aAChF,MAAM,CAAC,SAAS,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,gBAAgB,EAAE,CAAoB,CAAA;IAC1G,CAAC;IACD,OAAO,EAAE,KAAK,EAAE,IAAI,EAAE,EAAE;QACtB,MAAM,WAAW,GAAG,IAAI,CAAC,IAAI,IAAI,eAAe,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,CAAA;QAE/D,IAAI,CAAC,WAAW,EAAE,CAAC;YACjB,MAAM,MAAM,GAAG,mBAAmB,CAAC,MAAM,CAAC,CAAA;YAC1C,MAAM,CAAC,KAAK,CAAC,EAAE,IAAI,EAAE,yBAAyB,EAAE,OAAO,EAAE,+BAA+B,EAAE,QAAQ,EAAE,CAAC,EAAE,CAAC,CAAA;YACxG,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;YACf,OAAM;QACR,CAAC;QAED,MAAM,UAAU,GAAG,iBAAiB,CAAC,IAAI,CAAC,CAAA;QAC1C,MAAM,MAAM,GAAG,mBAAmB,CAAC,UAAU,CAAC,CAAA;QAE9C,eAAe;QACf,MAAM,UAAU,GAAG,WAAW,CAAC,WAAW,EAAE,OAAO,CAAC,CAAA;QACpD,IAAI,CAAC,UAAU,CAAC,QAAQ,EAAE,CAAC;YACzB,IAAI,UAAU,CAAC,KAAK;gBAAE,MAAM,CAAC,KAAK,CAAC,UAAU,CAAC,KAAK,CAAC,CAAA;YACpD,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;YACf,OAAM;QACR,CAAC;QAED,IAAI,CAAC;YACH,MAAM,MAAM,GAAG,IAAI,CAAC,SAAS,CAAC,IAAI,KAAK,CAAA;YACvC,MAAM,aAAa,GAAG,qBAAqB,CAAC,WAAW,CAAC,CAAA;YACxD,MAAM,WAAW,GAAG,MAAM,CAAA;YAE1B,MAAM,WAAW,GAAG,WAAW,CAAC,EAAE,WAAW,EAAE,aAAa,EAAE,WAAW,EAAE,MAAM,EAAE,CAAC,CAAA;YAEpF,IAAI,CAAC,MAAM,EAAE,CAAC;gBACZ,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,WAAW,EAAE,YAAY,CAAC,CAAA;gBAEnE,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,SAAS,CAAC,EAAE,CAAC;oBAC9B,mBAAmB;oBACnB,MAAM,WAAW,GAAG,mBAAmB,CAAC,aAAa,CAAC,CAAA;oBACtD,MAAM,QAAQ,GAAG,CAAC,GAAG,WAAW,CAAC,OAAO,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC;wBAC/D,IAAI;wBACJ,QAAQ,EAAE,EAAE,CAAC,WAAW,CAAC,OAAO,IAAI,EAAE;qBACvC,CAAC,CAAC,CAAA;oBACH,MAAM,YAAY,GAAG,IAAI,YAAY,CAAC,WAAW,EAAE,GAAG,EAAE,CAAC,EAAE,CAAC,CAAA;oBAC5D,YAAY,CAAC,eAAe,CAAC;wBAC3B,YAAY,EAAE,QAAQ;wBACtB,eAAe,EAAE,OAAO;wBACxB,WAAW;wBACX,QAAQ,EAAE,WAAW,CAAC,IAAI,KAAK,cAAc;4BAC3C,CAAC,CAAC,cAAc;4BAChB,CAAC,CAAC,WAAW,CAAC,IAAI,KAAK,YAAY;gCACjC,CAAC,CAAC,YAAY;gCACd,CAAC,CAAC,YAAY;qBACnB,CAAC,CAAA;gBACJ,CAAC;qBAAM,CAAC;oBACN,8CAA8C;oBAC9C,MAAM,YAAY,GAAG,IAAI,YAAY,CAAC,WAAW,EAAE,GAAG,EAAE,CAAC,EAAE,CAAC,CAAA;oBAC5D,MAAM,KAAK,GAAG,YAAY,CAAC,SAAS,EAAE,CAAA;oBACtC,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAA;oBACpC,KAAK,MAAM,IAAI,IAAI,WAAW,CAAC,cAAc,EAAE,CAAC;wBAC9C,IAAI,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;4BACtB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG;gCAClB,GAAG,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC;gCACpB,MAAM,EAAE,WAAW;gCACnB,EAAE,EAAE,GAAG;gCACP,YAAY,EAAE,gBAAgB;6BAC/B,CAAA;wBACH,CAAC;oBACH,CAAC;oBACD,YAAY,CAAC,SAAS,CAAC,KAAK,CAAC,CAAA;gBAC/B,CAAC;YACH,CAAC;YAED,MAAM,UAAU,GAAG;gBACjB,IAAI,EAAE,WAAW,CAAC,IAAI;gBACtB,eAAe,EAAE,WAAW,CAAC,cAAc;gBAC3C,eAAe,EAAE,WAAW,CAAC,cAAc;gBAC3C,eAAe,EAAE,WAAW,CAAC,cAAc;gBAC3C,WAAW,EAAE,WAAW,CAAC,WAAW;gBACpC,OAAO,EAAE,MAAM;aAChB,CAAA;YAED,IAAI,UAAU,KAAK,MAAM,EAAE,CAAC;gBAC1B,MAAM,CAAC,MAAM,CAAC,UAAU,CAAC,CAAA;YAC3B,CAAC;iBAAM,CAAC;gBACN,MAAM,CAAC,OAAO,CACZ,sBAAsB,WAAW,CAAC,cAAc,oBAAoB;oBACpE,GAAG,WAAW,CAAC,cAAc,CAAC,MAAM,kBAAkB,CACvD,CAAA;YACH,CAAC;YAED,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;QACjB,CAAC;gBAAS,CAAC;YACT,WAAW,CAAC,WAAW,CAAC,CAAA;QAC1B,CAAC;IACH,CAAC;CACF,CAAA;AAED,eAAe,YAAY,CAAA"}
+{"version":3,"file":"adopt.js","sourceRoot":"","sources":["../../../src/cli/commands/adopt.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,MAAM,SAAS,CAAA;AACxB,OAAO,IAAI,MAAM,WAAW,CAAA;AAC5B,OAAO,IAAI,MAAM,SAAS,CAAA;AAC1B,OAAO,EAAE,eAAe,EAAE,MAAM,+BAA+B,CAAA;AAC/D,OAAO,EAAE,iBAAiB,EAAE,MAAM,8BAA8B,CAAA;AAChE,OAAO,EAAE,mBAAmB,EAAE,MAAM,sBAAsB,CAAA;AAC1D,OAAO,EAAE,YAAY,EAAE,MAAM,8BAA8B,CAAA;AAC3D,OAAO,EAAE,WAAW,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAA;AACtE,OAAO,EAAE,mBAAmB,EAAE,MAAM,2CAA2C,CAAA;AAC/E,OAAO,EAAE,qBAAqB,EAAE,MAAM,mBAAmB,CAAA;AACzD,OAAO,EAAE,WAAW,EAAE,MAAM,wBAAwB,CAAA;AAWpD,MAAM,YAAY,GAAsD;IACtE,OAAO,EAAE,OAAO;IAChB,QAAQ,EAAE,yCAAyC;IACnD,OAAO,EAAE,CAAC,KAAoC,EAAE,EAAE;QAChD,OAAO,KAAK;aACT,MAAM,CAAC,MAAM,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,QAAQ,EAAE,wBAAwB,EAAE,CAAC;aACtE,MAAM,CAAC,SAAS,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,yBAAyB,EAAE,CAAC;aAC3F,MAAM,CAAC,OAAO,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,qCAAqC,EAAE,CAAC;aACrG,MAAM,CAAC,QAAQ,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,QAAQ,EAAE,eAAe,EAAE,CAAC;aAC/D,MAAM,CAAC,MAAM,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,iBAAiB,EAAE,CAAC;aAChF,MAAM,CAAC,SAAS,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,gBAAgB,EAAE,CAAoB,CAAA;IAC1G,CAAC;IACD,OAAO,EAAE,KAAK,EAAE,IAAI,EAAE,EAAE;QACtB,MAAM,WAAW,GAAG,IAAI,CAAC,IAAI,IAAI,eAAe,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,CAAA;QAE/D,IAAI,CAAC,WAAW,EAAE,CAAC;YACjB,MAAM,MAAM,GAAG,mBAAmB,CAAC,MAAM,CAAC,CAAA;YAC1C,MAAM,CAAC,KAAK,CAAC,EAAE,IAAI,EAAE,yBAAyB,EAAE,OAAO,EAAE,+BAA+B,EAAE,QAAQ,EAAE,CAAC,EAAE,CAAC,CAAA;YACxG,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;YACf,OAAM;QACR,CAAC;QAED,MAAM,UAAU,GAAG,iBAAiB,CAAC,IAAI,CAAC,CAAA;QAC1C,MAAM,MAAM,GAAG,mBAAmB,CAAC,UAAU,CAAC,CAAA;QAE9C,eAAe;QACf,MAAM,UAAU,GAAG,WAAW,CAAC,WAAW,EAAE,OAAO,CAAC,CAAA;QACpD,IAAI,CAAC,UAAU,CAAC,QAAQ,EAAE,CAAC;YACzB,IAAI,UAAU,CAAC,KAAK;gBAAE,MAAM,CAAC,KAAK,CAAC,UAAU,CAAC,KAAK,CAAC,CAAA;YACpD,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;YACf,OAAM;QACR,CAAC;QAED,IAAI,CAAC;YACH,MAAM,MAAM,GAAG,IAAI,CAAC,SAAS,CAAC,IAAI,KAAK,CAAA;YACvC,MAAM,aAAa,GAAG,qBAAqB,CAAC,WAAW,CAAC,CAAA;YACxD,MAAM,WAAW,GAAG,MAAM,CAAA;YAE1B,MAAM,WAAW,GAAG,WAAW,CAAC,EAAE,WAAW,EAAE,aAAa,EAAE,WAAW,EAAE,MAAM,EAAE,CAAC,CAAA;YAEpF,IAAI,CAAC,MAAM,EAAE,CAAC;gBACZ,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,WAAW,EAAE,YAAY,CAAC,CAAA;gBAEnE,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,SAAS,CAAC,EAAE,CAAC;oBAC9B,mBAAmB;oBACnB,MAAM,WAAW,GAAG,mBAAmB,CAAC,aAAa,CAAC,CAAA;oBACtD,MAAM,QAAQ,GAAG,CAAC,GAAG,WAAW,CAAC,OAAO,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC;wBAC/D,IAAI;wBACJ,QAAQ,EAAE,EAAE,CAAC,WAAW,CAAC,OAAO,IAAI,EAAE;qBACvC,CAAC,CAAC,CAAA;oBACH,MAAM,YAAY,GAAG,IAAI,YAAY,CAAC,WAAW,EAAE,GAAG,EAAE,CAAC,EAAE,CAAC,CAAA;oBAC5D,YAAY,CAAC,eAAe,CAAC;wBAC3B,YAAY,EAAE,QAAQ;wBACtB,eAAe,EAAE,OAAO;wBACxB,WAAW;wBACX,QAAQ,EAAE,WAAW,CAAC,IAAI,KAAK,cAAc;4BAC3C,CAAC,CAAC,cAAc;4BAChB,CAAC,CAAC,WAAW,CAAC,IAAI,KAAK,YAAY;gCACjC,CAAC,CAAC,YAAY;gCACd,CAAC,CAAC,YAAY;qBACnB,CAAC,CAAA;gBACJ,CAAC;qBAAM,CAAC;oBACN,8CAA8C;oBAC9C,MAAM,YAAY,GAAG,IAAI,YAAY,CAAC,WAAW,EAAE,GAAG,EAAE,CAAC,EAAE,CAAC,CAAA;oBAC5D,MAAM,KAAK,GAAG,YAAY,CAAC,SAAS,EAAE,CAAA;oBACtC,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAA;oBACpC,KAAK,MAAM,IAAI,IAAI,WAAW,CAAC,cAAc,EAAE,CAAC;wBAC9C,IAAI,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;4BACtB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG;gCAClB,GAAG,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC;gCACpB,MAAM,EAAE,WAAW;gCACnB,EAAE,EAAE,GAAG;gCACP,YAAY,EAAE,gBAAgB;6BAC/B,CAAA;wBACH,CAAC;oBACH,CAAC;oBACD,YAAY,CAAC,SAAS,CAAC,KAAK,CAAC,CAAA;gBAC/B,CAAC;YACH,CAAC;YAED,6CAA6C;YAC7C,IAAI,CAAC,MAAM,IAAI,WAAW,CAAC,WAAW,EAAE,CAAC;gBACvC,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,WAAW,EAAE,YAAY,CAAC,CAAA;gBACpE,IAAI,GAAG,GAA4B,EAAE,CAAA;gBACrC,IAAI,EAAE,CAAC,UAAU,CAAC,UAAU,CAAC,EAAE,CAAC;oBAC9B,IAAI,CAAC;wBACH,MAAM,OAAO,GAAG,EAAE,CAAC,YAAY,CAAC,UAAU,EAAE,MAAM,CAAC,CAAA;wBACnD,MAAM,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,CAAA;wBACjC,IAAI,OAAO,MAAM,KAAK,QAAQ,IAAI,MAAM,KAAK,IAAI,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,EAAE,CAAC;4BAC5E,GAAG,GAAG,MAAiC,CAAA;wBACzC,CAAC;oBACH,CAAC;oBAAC,MAAM,CAAC,CAAC,gCAAgC,CAAC,CAAC;gBAC9C,CAAC;gBACD,MAAM,OAAO,GAAG,CAAC,GAAG,CAAC,SAAS,CAAC,IAAI,EAAE,CAA4B,CAAA;gBACjE,OAAO,CAAC,aAAa,CAAC,GAAG,WAAW,CAAC,WAAW,CAAA;gBAChD,IAAI,WAAW,CAAC,UAAU,EAAE,CAAC;oBAC3B,OAAO,CAAC,YAAY,CAAC,GAAG,WAAW,CAAC,UAAU,CAAA;gBAChD,CAAC;gBACD,GAAG,CAAC,SAAS,CAAC,GAAG,OAAO,CAAA;gBACxB,EAAE,CAAC,aAAa,CAAC,UAAU,EAAE,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC,CAAA;YACtD,CAAC;YAED,MAAM,UAAU,GAAG;gBACjB,IAAI,EAAE,WAAW,CAAC,IAAI;gBACtB,eAAe,EAAE,WAAW,CAAC,cAAc;gBAC3C,eAAe,EAAE,WAAW,CAAC,cAAc;gBAC3C,eAAe,EAAE,WAAW,CAAC,cAAc;gBAC3C,WAAW,EAAE,WAAW,CAAC,WAAW;gBACpC,OAAO,EAAE,MAAM;gBACf,GAAG,CAAC,WAAW,CAAC,WAAW,IAAI,EAAE,YAAY,EAAE,WAAW,CAAC,WAAW,EAAE,CAAC;gBACzE,GAAG,CAAC,WAAW,CAAC,UAAU,IAAI,EAAE,WAAW,EAAE,WAAW,CAAC,UAAU,EAAE,CAAC;aACvE,CAAA;YAED,IAAI,UAAU,KAAK,MAAM,EAAE,CAAC;gBAC1B,MAAM,CAAC,MAAM,CAAC,UAAU,CAAC,CAAA;YAC3B,CAAC;iBAAM,CAAC;gBACN,MAAM,CAAC,OAAO,CACZ,sBAAsB,WAAW,CAAC,cAAc,oBAAoB;oBACpE,GAAG,WAAW,CAAC,cAAc,CAAC,MAAM,kBAAkB,CACvD,CAAA;YACH,CAAC;YAED,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;QACjB,CAAC;gBAAS,CAAC;YACT,WAAW,CAAC,WAAW,CAAC,CAAA;QAC1B,CAAC;IACH,CAAC;CACF,CAAA;AAED,eAAe,YAAY,CAAA"}

package/dist/cli/commands/adopt.test.js

@@ -226,7 +226,34 @@ describe('adopt command', () => {
         expect(mockInitializeState).toHaveBeenCalled();
         expect(exitSpy).toHaveBeenCalledWith(0);
     });
-    // Test 6: Marks matched steps as completed in state
+    // Test 6: Writes detected game config to config.yml (even when config doesn't exist)
+    it('writes projectType and gameConfig to config.yml when game detected', async () => {
+        // Create .scaffold/ dir in tmpDir but no config.yml
+        const scaffoldDir = path.join(tmpDir, '.scaffold');
+        fs.mkdirSync(scaffoldDir, { recursive: true });
+        // No state.json either — triggers initializeState path
+        mockFindProjectRoot.mockReturnValue(tmpDir);
+        mockRunAdoption.mockReturnValue({
+            mode: 'brownfield',
+            artifactsFound: 1,
+            detectedArtifacts: [],
+            stepsCompleted: [],
+            stepsRemaining: [],
+            methodology: 'deep',
+            errors: [],
+            warnings: [],
+            projectType: 'game',
+            gameConfig: { engine: 'unity' },
+        });
+        await adoptCommand.handler(defaultArgv({ 'dry-run': false }));
+        const configPath = path.join(scaffoldDir, 'config.yml');
+        expect(fs.existsSync(configPath)).toBe(true);
+        const configContent = fs.readFileSync(configPath, 'utf8');
+        expect(configContent).toContain('projectType: game');
+        expect(configContent).toContain('engine: unity');
+        expect(exitSpy).toHaveBeenCalledWith(0);
+    });
+    // Test 7: Marks matched steps as completed in state
     it('marks stepsCompleted in state when state.json exists', async () => {
         // Create .scaffold/state.json in tmpDir so fs.existsSync returns true
         const scaffoldDir = path.join(tmpDir, '.scaffold');