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 $phaser4-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/visuals, or an independent decision record, and clear the corresponding pending flags; do not write to the Approval Ledger, and do 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 current phase's plan, design, technical approach, acceptance, implementation, and confirmed decisions, and distinguish factual gaps, professional issues, and user trade-offs.
2. First close facts through code, configuration, existing documentation, and actual execution; leave professional quality to independent review. Enter grilling only when user decisions remain that would materially change scope, priority, experience, architecture, risk, acceptance, dependencies, visual direction, cost, or release authorization.
3. For the first module or a boundary change, first check code, configuration, contracts, and evidence; enter grilling only when substantive user trade-offs remain. 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, ask only about gaps, conflicts, assumptions, or dependencies, and do not repeat existing conclusions.
5. A new phase, new page, first module, or boundary change is not itself a trigger.
6. Conduct open-ended visual grilling only when trade-offs remain in visual direction, budget, signature strength, or implementation/asset cost. 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 defaults to using visual_validation.mode=usability, minor position, size, margin, and line-break differences can be fixed directly and re-verified; only when there is a product direction, gameplay semantics, upstream structural change, or explicit exact requirement, explain the impact and candidate options and request one confirmation. Release is still recorded according to A5/A6.
8. When there is no user decision, continue the original task directly and do not generate placeholder records.

Conversation rules

• Ask only one question at a time; each question states the impact, recommended answer, and 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 consent.
• A clear, conflict-free answer from the user to the trade-off being asked satisfies the confirmation requirement for that question, with no separate confirmation restatement needed. Continue clarifying only if the answer still contains substantive ambiguity; suspend directly affected work until the necessary answer is obtained, while work with no dependencies continues. Silence does not constitute an answer or approval.

Scope branch

• 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 architecture trade-offs, platforms, capability toggles, 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 record

After the user answers explicitly, 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 replace execution with a summary or handoff note. 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 manual visual confirmation uniformly followsControl plane cannot bypass 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 stage progression, module existence, or boundary changes.
• Do not advance directly affected formal implementation or resource production while unresolved scope, risks, or acceptance trade-offs remain.