unity-game-grilling

Unity game interrogation

Before performing irreversible, expensive, or approval-boundary-changing work, first eliminate factual questions with evidence, then obtain user decisions item by item. Interrogation cannot be replaced by agent review, default values, or a single vague "continue."

Strict triggers

Enter interrogation when any of the following conditions occurs and the repository, artifacts, or reasonable assumptions cannot eliminate a substantive trade-off:

• Multiple reasonable options exist at a module or scene boundary that would significantly change scope, state ownership, public contracts, cost, or rework surface.
• Selecting the global Visual Bible, V1 scene targets, V2 production boundaries, 3D model/texture targets, or final device visuals.
• Scope, priorities, cost, risk acceptance, acceptance evidence, authorization, privacy, release eligibility, or Windows delivery method is unclear or mutually conflicting.

First implementation itself does not constitute grounds for interrogation. Other matters trigger only when the repository, documentation, and evidence cannot eliminate the unknowns, and continuing genuinely requires a human trade-off. Do not repeatedly ask about existing, valid conclusions bound to the current version.

Execution order

1. Read the current plan, GDD/TDD, scene and asset contracts, Visual Bible, quality gates, verification evidence, and existing approvals. First output an evidence list, with each fact accompanied by a project-relative path, object version, or source revision; when there is no evidence, it can only be marked as an assumption or unknown, and must not be inferred as fact. Divide the content into verified facts, assumptions, unknowns, and decisions that must be chosen by the user.
2. First eliminate verifiable questions through read-only checks. It is forbidden to forward to the user questions that can be answered by the repository, Unity Editor, build reports, or existing evidence.
3. Order decisions by dependency and impact. Low-risk, mutually independent matters that recommend the same default strategy may form one decision package; high-impact, mutually dependent, conflicting issues, or issues that would invalidate downstream approvals should be asked one at a time.
4. Each question must state: verified facts, the single decision question, the impact on scope/cost/risk/rework/gates, two to three mutually exclusive options, and the recommendation with rationale. Do not present the recommendation as fact or treat silence as consent.
5. Record the user's answer and check whether it conflicts with approved boundaries, Unity 6/URP/UI Toolkit/Windows constraints, and upstream evidence. If the answer is vague or the object or version is unclear, continue asking the current question and do not interpret it as approval on your own.
6. After all blocking items are closed, submit a versioned decision summary specifying the approved object, scope, non-goals, rejected items, risk acceptance, acceptance evidence, invalidation impact, and next steps, and request the user's explicit approval of that summary.
7. After approval, update the control plane and machine records, verify that references, versions, SHA-256, and status are consistent, then return the affected tasks to the overall control. When the user requests changes, generate a new version and return to the earliest affected question; old records serve only as history.

Interrogation scope

• Product: target users, core problem, first value, core loop, MVP, non-goals, success metrics, priorities, business and time constraints.
• Experience: key flows, operation feedback, failure/retry/exit, pause and save, tutorial, readability, accessibility, input devices, and experience acceptance.
• Technical: Unity 6 version, URP, UI Toolkit, Windows, architecture, data lifecycle, save compatibility, security/privacy, performance budget, third-party dependencies, and capability degradation.
• Modules and Scenes: necessity, responsibilities and non-goals, state ownership, public contracts, dependency direction, loading/unloading, failure isolation, shared services, implementation order, testing, and definition of done.
• Visual Assets: global visual language, permitted uses of reference images, authorization and generation methods, V0-V4 decision points, 2D adaptation, fonts/UI/motion, cost, asset map, and release eligibility. Screenshots may only assist in judging content, composition, and information hierarchy; they cannot be approved as final style or as a source for cropped assets.
• 3D: scale and units, silhouette, topology, modularity, axes/Pivot, UV, material slots, texture atlases, skeleton/animation, LOD, Collider, performance budget, DCC/MCP capability boundaries, and source file delivery.
• Quality: verifiable acceptance, test levels, visual and interaction review, target frame rate, memory/build size budget, supported resolutions, P0/P1 defect policy, and evidence retention.
• Release: version, build configuration, license list, save/upgrade risks, rollback, signing and distribution, release blockers, final risk acceptance, and user sign-off.

Write Boundary

Before the user explicitly approves the current decision summary, only read-only investigation, candidate options, issue logging, and work that does not depend on that decision are permitted. The following are prohibited for directly affected content:

• @Unity Unity Editor writes, Scene/Prefab/asset imports, and any directly affected code, test, generated code, configuration, or project file modifications.
• Batch production of images, models, textures, materials, or animations, and replacement of approved visual assets.
• Rewriting the approved scope, module/scene boundaries, acceptance, risk status, quality gates, or release status.
• Having sub-agents implement first within unapproved boundaries, or substituting agent review for user approval.

Before approval, candidate options and issue logs may only be kept in the conversation or in an explicitly isolated non-production draft area; writing to the Unity project's Assets/、Packages/、ProjectSettings/ or affected module source directories is prohibited. Screenshot authorization, permitted reference dimensions, and prohibited uses must be separately confirmed before any visual candidate generation; providing screenshots does not mean the user has approved their copyright status, style replication, or batch production scope.

User approval only releases the objects and versions it explicitly covers. Any change to upstream content, version, hash, source revision, or approval scope must invalidate affected downstream conclusions and trigger re-interrogation.

Local approval files and hashes are only for content integrity, not user identity credentials. Agents must not create, modify, or countersign user approval originals on their own; identity must be sourced from a genuine user approval event in the current host conversation, or from a host-provided read-only/signed receipt. When the host cannot provide a verifiable approval event, the record must explicitly state that identity has not yet been machine-verified; external vendors, payments, signing, uploads, releases, and overwriting stable artifacts remain BLOCKED, and local YAML/text records must not be interpreted as authorization.

Decision Record

Write the current decision summary to docs/control-plane.md 's "Pending Human Decision", "Effective Changes", or corresponding gate index, and generate for each interrogation a machine record conforming to the current grilling-record Schema of the master control directory. If the contract does not exist, validation fails, or it cannot be bound to the current subject and version, keep BLOCKED, and do not continue after creating a substitute format on your own.

The machine record must at least express: record ID/version and source revision, trigger reason, approving entity and its ID/version/SHA-256, verified facts, assumptions and unknowns, per-question options/impact/recommendation/user answer, final scope and non-goals, rejected items, accepted risks, acceptance evidence, affected gates and deliverables, invalidation relationships, approval authority and time, conclusion and next steps. Recording credentials, personal data, or the full text of restricted contracts is prohibited.

Run contract validation before completion, and confirm that the control-plane summary and the machine record point to the same approved object and version. Missing answers, ambiguous approval, proxy approval on behalf of another, invalidated evidence, or inconsistent records must never be marked as approved.

Completion conditions

• All mandatory trigger scopes are covered, and explicit answers are obtained item by item for all high-impact questions.
• The user explicitly approves the versioned summary, and the approval is bound to the exact object, version, SHA-256, source revision, and conclusion scope.
• docs/control-plane.md and grilling-record have both been updated and passed validation.
• Affected tasks, gates, downstream invalidated items, and next steps are all clear; unresolved items remain blocking, and completion is not falsely reported.