The hosted orchestration for creating and continuing GripForge games from the web or terminal, one way among others (a Game Kit project made directly, the user's local project with gripforge game-attach, parts written by the user's AI: all welcome and mixable). Any game is accepted: no character, enemy, level, ending or known genre is required. The server owns planning, fabrication, development, checkpoints, budgets and verification of its own tasks; while one runs, do not run a second copy of it locally. If an existing creation id is supplied, get it and resume that exact project, never create a replacement. Ask which engine (Bevy (the GripForge player), Godot, Unity or Unreal) if unspecified and no engine project is in the folder of the user (project.godot, Unity ProjectSettings, an Unreal .uproject, a Bevy crate: then that engine); do not choose silently. A local project is never exported: once built, gripforge game-attach <gc_id|gkp_id> <folder> brings the game into it, whatever the engine. Creation mode is explicit, never guessed silently: when the user has not said it, ask whether the game is generated at once or built step by step. At once: quote build covers the whole saved queue; show its size and maximum price to the user (the first level is playable early, progress.playable). Step by step: each step is quoted, accepted and validated on its own: quote build for the foundation and the first playable level, then quote develop with a message naming the next step, one step at a time; the total duration or size plays no role. A game asked at once that is too long for one build switches to step by step, and the user is told; it is never refused. create saves a brief without spending. When the user already has their own plan (design documents, chosen kits), offer use_plan instead of the AI plan step: use_plan with expected_revision and plan_document (gripforge.game-plan/1: design = the game-designer proposal schema with origin/basis optional, plus optional title kept as written, modules or preset, controls, world, art_direction) is free, uses no AI and no quote, and reaches the same plan-ready state as an accepted AI plan (design agent user). The server keeps every content choice as written: it refuses only an unreadable or structurally invalid document, naming the exact field path, and returns plan_review { ready, diagnostics, suggestions } (kits that realise the features, missing world or controller, features outside the catalog to implement, items naming an absence, unmeasured quality metrics, a journey without a gameplay state). Show them to the user; apply_plan_suggestions with suggestions = the ids the user chose (apply=true) applies only those, never automatically. quote(operation=plan) never replaces a supplied plan; quote refine reworks it with the AI only on request. quote(operation=plan) estimates AI preparation (player_accounts=true adds player accounts through central.client even to a solo game; off by default, online multiplayer always has it), accept(quote_token) starts its durable job ONLY after user approval of the shown price. get returns a persistent operation log, slots, studio_url and the same project to resume. Planning can select an appropriate preset OR compose real engine-compatible modules. A missing preset never means the genre needs a native engine. composition.modules pins all module versions; composition.tasks lists the custom logic still to implement. New plans return design from a separate game-designer agent: named content lists and their counts, animation clips per actor, user-request versus agent-proposal attribution, assumptions and a machine-readable completion contract. Show this saved scope before assembly; refine changes it. get also returns production_sources. quote(operation=produce, production_source=one source ID) estimates a bounded production batch for any contract content, animation, capability or journey obligation; omit production_source to choose the next unprepared source. After price approval, accept runs decomposition, compatible Library matching, authored source documents and at most one concept board for missing visual assets, cropped into individually traceable review drafts. Audio, animation and executable VFX never become complete through a picture. An unavailable matcher with candidates requires review rather than speculative replacement. production.batches persists tasks, dependencies, acceptance checks, candidates, concepts, text, deferred work and diagnostics. asset_matched is not acquisition or integration. draft_ready is not gameplay verification. Changed design fingerprints retain old batches as stale. Use existing concept review/manufacturing and content tools for integration; Develop can read production batches using creation_production. Never report prepared-source coverage as game completeness. Assembly persists that contract on the project before auditing. A design is not implementation or passing evidence. The quoted planning budget includes this bounded stage; old accepted jobs retain their original behavior. New plans also return world: structure (open_world, semi_open, linear, arena, interior or circuit), deterministic seed, validated kit configurations, level documents and remaining work. Assembly applies this saved layout atomically. Reuse it when continuing in the CLI; a visual-theme change does not imply changing geography. A seed change alone is not a designed level. Show world.remaining, including unbuilt architecture or transitions, before calling the game complete. Assembly is a foundation, not a completed custom game: For contract-backed web games, quote build includes a persistent queue derived from every named source and capability, with isolated authoring sessions and independent final verification; there is no twelve-turn limit for the entire game. Review the quoted maximum before acceptance. Unattempted credit-funded tasks are not charged. development.work records reported_unverified and blocked tasks, retained authoring IDs and pending IDs; these are not release evidence. delivery.status=ready requires the build-specific contract and final checks. For an assembled project, quote operation=develop with an optional message to continue the saved queue under a new approved budget, preserving the same project and completed authoring work. The development result distinguishes agent-declared changes, actual checks, remaining work and unsupported runtime capabilities. Each additional pass needs its own estimate. When the contract requires a HUD, new build/develop quotes expose interface_preparation: they reuse the saved concept or include one bounded HUD concept generation and editable document. Its price is included; accepted older quotes never add it. Read creation_hud during authoring, implement the game data in its presenter and use the existing gripforge_hud runtime artistic review. A concept alone does not complete the HUD. Other asset generation requires its own quoted stage. The hosted development worker currently supports target web. For native targets, keep the shared plan, selections and build, then use the engine delivery/import adapter; native custom-code execution is not implemented by the hosted worker. Inside an already running development task, implement only that assigned task; never recursively create or accept a new creation job. After a build, get also returns creatures (the models bound so that no unit is a capsule) and audit { verdict: complete | playable_with_defects | incomplete, headline, fixed (the free fixes applied: models, standard clips, control scheme), defects [{ severity, message, fix { tool, args, credits? } }], next }: show the user the verdict and what is left, work through next (gripforge_game_audit reads it again), and never present a verdict other than complete as a finished game. quote refine with message updates the same plan after approval, preserves selected assets and reviewed work, and persists the conversation. use_reference with slot_id and an owned image asset_id supplies an uploaded concept for visual review. assets searches workspace/community items by actual role before invented generation details. Generic nature packs may cross world themes while keeping the rendering look. New plans consider available styles before inventing one; selection_reason explains planner choices. other_styles=true reveals alternatives with explicit mismatch/unknown compatibility for manual review; never bind a known look mismatch automatically. Prefer reuse before generation; select chooses one or sets mode=generate with a prompt. For generation: quote concept, obtain approval, accept, poll get, show the concept, approve_concept only after visual user review; quote generate, obtain approval, accept, poll and show the model in its studio. A quote with auto_select_character=true selects the missing main character by default when ready; it remains inspectable and replaceable. Other models, replacement generations and older approved jobs remain drafts: approve_asset only after visual review. Never infer visual approval from technical success. quote build then accept acquires the selected community assets and binds them to a Game Kit prototype; generated artwork and models must appear in the accepted quote. The main playable character is presented first. If no usable matching rigged/animated model is found, offer existing ones (gripforge assets show <lib_id> lists their clips) or its generation. A game without a character simply has no such slot. A slot left without an asset uses the module default or stays empty, and a generated model awaiting review is left out until approved; the answer says so (build_incomplete, character_concept_missing). Show missing_assets before approval; never imply that an incomplete prototype is finished. Native engine projects still need CLI delivery/import; a web project has a play_url. Revision required for edits. Every get, list item and action response carries status: idle | running | failed | cancelled | ready, with status_detail { job_id, operation, job_status, stage, message, actions }. Poll get while status=running; stop on failed or cancelled, show status_detail.message and offer the listed actions (retry, dismiss). On any error or failed job, follow client_guidance: explain, offer retry, step-by-step continuation or making that part in the project, then go on as the user chooses. pending alone never means in progress: a failed job stays pending until retried or dismissed. Cancel/retry preserve completed steps. Forward preparation_resume.resume_token through retry when offered. quote_continuation with geometry_mode=designed then accept_continuation with its quote_token use the same saved continuation as the web. platforms on create records web/mobile/windows/mac independently of the engine. A 2D request is made in 3D with a camera that keeps the 2D feel (warning 2d_not_supported). No automatic spending, invented asset IDs, or unrelated template substitutions. Build the engine of the game, never the game in code. The code holds only generic systems: plugged kits, rules set by parameters, hooks. All content is data loaded at run time: levels and scenes, characters, weapons, items, balance values, texts, assets and inputs, in data files or through modding (the game.engine contract), changeable without recompiling, on every engine (Bevy, Godot, Unity, Unreal) and on a local project. Adding a weapon, a level or an enemy is adding data, not code. Each asset is described by its passport (asset.meta, the mesh passport: skeleton, clips, colliders, LOD, weapon grips, sizes): the game reads clips, bones, grips and sizes from it and never writes a clip name, a bone or a scale in code; changing an asset is changing its passport, not the code (gripforge assets show <lib_id> shows it and says what it lacks). Recommend kits with this in mind: the ones whose config, registries and documents carry the content as data. GripForge never refuses a game action for a business reason: when something blocks, it goes on without it and returns warnings [{ code, message, skipped, howToFix }] (applied=false when nothing could be done). Read every warning, tell the user what was skipped, and follow howToFix or offer it; never treat a warning as a finished result. Only security refusals (sign-in, rights, paths outside the sandbox, payment quotas, data of others) remain errors.