grilling

Grilling

Global control access

Control plane boundary: can propose, can review, and can record decisions within the current Work Item task scope, and must return to the $threejs-game-workflow-control risk gate; approval of high-impact external operations is still handled by the control plane.

Grilling only produces USER_DECISION clarification records. Write user choices back to the Work Item, authoritative artifacts such as requirements/architecture/visual, or a standalone decision record, and clear the corresponding pending flags; must not write to the Approval Ledger, and must not use approval, approve, pending, handoff, or approve to describe product choices.

Let users decide only matters that cannot be confirmed from the codebase, configuration, existing authoritative artifacts, or deterministic execution. Do not block pure factual queries, professionally determinable defects, or confirmed low-risk execution.

Entry method

1. Read the plan, design, technical approach, acceptance, implementation, and confirmed decisions of the current phase, and distinguish factual gaps, professional questions, and user trade-offs.
2. First close facts through code, configuration, existing documentation, and actual execution; professional quality is left to independent review. Enter grilling only when user decisions still exist that would substantively change scope, priority, experience, architecture, risk, acceptance, dependencies, visual direction, cost, or release authorization.
3. For the first module or boundary change, first check code, configuration, contracts, and evidence; enter grilling only when substantive user trade-offs still exist. Records must be bound to the Work Item, current gate, baseline, and invalidation conditions, and must not fabricate candidate identities.
4. When there is no product definition, start from target users, first value, scope, business constraints, and risks; when a definition already exists, only ask about gaps, conflicts, assumptions, or dependencies, and do not repeat existing conclusions.
5. A new phase, a new page, the first module, or a boundary change is itself not a trigger.
6. Conduct open-ended visual interrogation only when visual direction, budget, signature strength, or implementation/asset cost still require trade-offs. Do not repeat confirmation when a clear applicable baseline already exists.
7. Do not ask questions when V1/V2 already has clear requirements or a frozen baseline, and the candidate has no product direction, gameplay semantics, or upstream structural trade-offs. Faithful reproduction of a specified mockup uses visual_validation.mode=usabilityby default; minor position, size, margin, and line-wrap differences can be fixed directly and revalidated; only when there is a product direction, gameplay semantics, upstream structural change, or an explicit exact requirement should the impact and candidate options be explained and a single confirmation requested. Release is still recorded per A5/A6.
8. When there is no user decision, continue the original task directly and do not generate placeholder records.

Dialogue rules

• Ask only one question at a time; each question states the impact, the recommended answer, and the rationale.
• Proceed layer by layer from root decisions to dependent decisions, expanding only branches relevant to the current scope.
• When an answer exposes a conflict or new dependency, handle the conflict first, then return to the original branch.
• Do not disguise recommendations as facts, and do not treat unanswered questions or silence as agreement.
• When the user gives a clear, conflict-free answer to the trade-off asked, that question's confirmation requirement is satisfied, and no separate confirmation restatement is needed. Continue clarifying only if the answer still has substantive ambiguity; pause directly affected work until the necessary answer is obtained, while work with no dependencies continues. Silence does not constitute an answer or approval.

Scope branches

• Product and scope: target users, first value, success criteria, MVP, non-goals, priorities, and dependencies.
• Experience and trust: key flows, failure recovery, permissions, privacy, payment, feedback, accessibility, and reversibility.
• Technology and delivery: irreversible architectural trade-offs, platforms, feature flags, API/data boundaries, acceptance, evidence, quality metrics, and risks.
• Visuals and resources: direction, information hierarchy, expression budget, licensing, cost, release eligibility, and verifiable quality standards.
• Release: candidate scope, remaining risks, rollback conditions, and external release authorization.

Completion and records

After the user explicitly responds, summarize the actual decisions, open items, dependencies, rejected items, and next steps, update the authoritative artifacts, and resume work that was unblocked in the original task; do not substitute a summary or handoff note for execution. Only explicit approval for high-impact external operations is written into .workflow-control/approvals/ledger.json; ordinary tasks do not create authorization records. Credentials, personal data, or full text of restricted contracts must not be recorded.AUTO The distinction from visual human confirmation uniformly followsControl plane non-bypassable constraints。

Prohibited items

• Do not ask about facts that can be confirmed from code, configuration, documentation, or execution evidence.
• Do not make the user bear the risk of implementation defects, missing evidence, or professional aesthetic issues.
• Do not mechanically trigger or repeat questions because of phase progression, module existence, or boundary changes.
• Do not advance directly affected formal implementation or resource production while unresolved scope, risk, or acceptance trade-offs remain.