Back to Details

grilling

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Grilling

Grilling

全局控制接入

Global Control Access

控制面边界：可提议、可审查、可在 Work Item 任务授权或显式批准范围内记录决定，且必须回到 
$phaser4-game-workflow-control
风险门。
Grilling 只形成 
USER_DECISION
澄清记录。把用户选择回写到 
taskAuthorization
、需求/架构/视觉等权威工件或独立决策记录，并清除对应未决标志；不得写 Approval Ledger，也不得使用批准、审批、pending、handoff 或 approve 描述产品选择。
只让用户决定不能从代码库、配置、现有权威工件或确定性执行确认的事项。不要阻塞纯事实查询、专业可判定缺陷或已确认的低风险执行。
Control Plane Boundary: Proposals can be made, reviewed, and decisions recorded within the scope of Work Item task authorization or explicit approval, and must return to the 
$phaser4-game-workflow-control
risk gate.
Grilling only generates 
USER_DECISION
clarification records. Write user choices back to 
taskAuthorization
, authoritative artifacts such as requirements/architecture/vision, or independent decision records, and clear the corresponding pending flags; do not write to the Approval Ledger, nor use terms like approval, review, pending, handoff, or approve to describe product choices.
Only let users decide matters that cannot be confirmed from the codebase, configurations, existing authoritative artifacts, or deterministic execution. Do not block pure factual queries, professionally determinable defects, or confirmed low-risk execution.

进入方式

Entry Methods

  1. 读取当前阶段的计划、设计、技术方案、验收、实现和已确认决定，区分事实缺口、专业问题与用户取舍。
  2. 先通过代码、配置、现有文档和实际执行关闭事实；专业质量交给独立审核。只有仍存在会实质改变范围、优先级、体验、架构、风险、验收、依赖、视觉方向、成本或发布授权的用户决定时才进入 grilling。
  3. 首次模块或边界变化先检查代码、配置、契约和证据；仅当仍存在实质用户取舍时进入 grilling。记录必须绑定 Work Item、当前门、基线与失效条件，不得虚构候选身份。
  4. 无产品定义时从目标用户、首次价值、范围、商业约束和风险开始；已有定义时只追问缺口、冲突、假设或依赖，不重复已有结论。
  5. 新阶段、新页面、首次模块或边界变化本身都不是触发器。
  6. 视觉方向、预算、签名强度或实现/资产成本仍需取舍时才做开放式视觉拷问。已有明确适用基线时不重复确认。
  7. V1/V2 已有明确需求或冻结基线，且候选不存在可见偏差或实质取舍时不提问。指定效果图忠实还原中，只有不改变冻结视觉事实且处于项目预定义容差内的适配可 
    AUTO
    ；专业质量修复、工程适配或提升游戏感造成可见偏差时，必须说明影响与候选方案，请求一次精确确认并绑定已批准例外。新方向、同等方案、可见结构/交互变化或高返工成本取舍同样只请求一次确认；发布仍按 A5/A6 记录。
  8. 不存在用户决定时直接继续原任务，不生成占位记录。
  1. Read the planning, design, technical solutions, acceptance, implementation, and confirmed decisions of the current phase, and distinguish between factual gaps, professional issues, and user trade-offs.
  2. First close factual gaps through code, configurations, existing documents, and actual execution; leave professional quality to independent reviews. Enter grilling only when there are still user decisions that will substantially change scope, priorities, experience, architecture, risks, acceptance, dependencies, visual direction, cost, or release authorization.
  3. For the first module or boundary change, first check code, configurations, contracts, and evidence; enter grilling only when substantive user trade-offs still exist. Records must be bound to Work Item, current gate, baseline, and failure conditions, and candidate identities cannot be fabricated.
  4. When there is no product definition, start from target users, initial value, scope, business constraints, and risks; when there is an existing definition, only ask about gaps, conflicts, assumptions, or dependencies, and do not repeat existing conclusions.
  5. New phases, new pages, first-time modules, or boundary changes themselves are not triggers.
  6. Conduct open visual grilling only when trade-offs are still needed for visual direction, budget, signature strength, or implementation/asset costs. Do not re-confirm when a clear applicable baseline exists.
  7. For V1/V2 with clear requirements or frozen baselines, and no visible deviations or substantive trade-offs among candidates, no questions are needed. During faithful restoration of specified renderings, only adaptations that do not change frozen visual facts and are within the project's predefined tolerance can be marked as 
    AUTO
    ; when professional quality fixes, engineering adaptations, or game feel improvements cause visible deviations, the impact and candidate solutions must be explained, and a precise confirmation must be requested while binding to approved exceptions. For new directions, equivalent solutions, visible structure/interaction changes, or trade-offs with high rework costs, only one confirmation request is needed; releases are still recorded according to A5/A6.
  8. If there are no user decisions to be made, continue the original task directly without generating placeholder records.

对话规则

Dialogue Rules

  • 一次只问一个问题；每个问题说明影响、推荐答案及理由。
  • 从根决定到依赖决定逐层推进，只展开当前范围相关分支。
  • 回答暴露冲突或新依赖时先处理冲突，再回到原分支。
  • 不把推荐伪装成事实，也不把未回答或沉默视为同意。
  • 用户未明确确认共同理解前，不推进被拷问的直接受影响工作；无依赖工作可以继续。
  • Ask only one question at a time; each question should explain the impact, recommended answer, and reasons.
  • Advance layer by layer from root decisions to dependent decisions, and only expand branches relevant to the current scope.
  • When answers expose conflicts or new dependencies, resolve the conflicts first, then return to the original branch.
  • Do not disguise recommendations as facts, nor treat unanswered questions or silence as consent.
  • Do not proceed with work directly affected by the grilling until the user explicitly confirms mutual understanding; independent work can continue.

范围分支

Scope Branches

  • 产品与范围：目标用户、首次价值、成功标准、MVP、非目标、优先级和依赖。
  • 体验与信任：关键流程、失败恢复、权限、隐私、付费、反馈、无障碍和可撤销性。
  • 技术与交付：不可逆架构取舍、平台、能力开关、API/数据边界、验收、证据、质量指标和风险。
  • 视觉与资源：方向、信息层级、表达预算、授权、成本、发布资格和可验证质量标准。
  • 发布：候选范围、剩余风险、回滚条件和外部放行授权。
  • Product & Scope: Target users, initial value, success criteria, MVP, non-targets, priorities, and dependencies.
  • Experience & Trust: Key processes, failure recovery, permissions, privacy, payment, feedback, accessibility, and revocability.
  • Technology & Delivery: Irreversible architecture trade-offs, platforms, capability switches, API/data boundaries, acceptance, evidence, quality metrics, and risks.
  • Visual & Resources: Direction, information hierarchy, expression budget, authorization, cost, release eligibility, and verifiable quality standards.
  • Release: Candidate scope, remaining risks, rollback conditions, and external release authorization.

完成与记录

Completion & Documentation

用户明确确认共同理解后，只汇总实际决定、未决项、依赖、拒绝项和下一步。只有显式人工门决定写入 
.workflow-control/approvals/ledger.json
；普通任务授权留在 Work Item。领域负责人再更新权威工件，不得记录凭据、个人数据或受限合同全文。
After the user explicitly confirms mutual understanding, only summarize actual decisions, pending items, dependencies, rejected items, and next steps. Only explicit manual gate decisions are written to 
.workflow-control/approvals/ledger.json
; regular task authorizations remain in Work Item. Domain owners then update authoritative artifacts, and must not record credentials, personal data, or full restricted contracts.

禁止事项

Prohibited Items

  • 不询问可从代码、配置、文档或执行证据确认的事实。
  • 不把实现缺陷、缺证或专业审美问题交给用户承担风险。
  • 不因阶段推进、模块存在或边界变化机械触发或重复提问。
  • 不在仍有未决范围、风险或验收取舍时推进直接受影响的正式实现或资源生产。
  • Do not ask facts that can be confirmed from code, configurations, documents, or execution evidence.
  • Do not leave implementation defects, lack of evidence, or professional aesthetic issues to users to bear risks.
  • Do not mechanically trigger or repeat questions due to phase advancement, module existence, or boundary changes.
  • Do not proceed with formal implementation or resource production directly affected when there are still unresolved scope, risk, or acceptance trade-offs.