roblox-game-grilling

Roblox Game Interrogation

When a critical product or technical trade-off cannot be eliminated by project evidence, and proceeding would change the goal, scope, boundary of authority, cost, risk, or acceptance, investigate first, then ask the user to decide item by item, and write the conclusions into the workflow control plane. Interrogation is a process for resolving necessary decisions, not a fixed prerequisite step for every work item.

Triggers and Boundaries

Enter this process when the user explicitly requests interrogation. When there is no explicit request, it is triggered only if there remain human trade-offs that would materially affect the affected work item, for example:

• Player goals, core loop, multiplayer cooperation or competition mode, version scope, and priorities.
• Authority ownership between server and client, Remote contracts, module boundaries, responsibilities between Places, or persistence responsibilities.
• Visual direction, usable scope of reference images, asset sources and licenses, production cost, or performance budget.
• Economy pacing, reward rules, randomness, paid entitlements, data retention, and operations strategy.
• Release targets, public scope, commercialization, privacy impact, data migration, rollback, and risk acceptance.
• There are still multiple reasonable options for human acceptance criteria, risk thresholds, or authorization boundaries.

The following situations do not trigger interrogation: the first implementation itself, small fixes, API or object facts that can be determined from official materials/projects/Studio, ordinary and already authorized local testing, and implementation details that do not change approved goals and scope. First eliminate factual questions through existing documentation, read-only project inspection, read-only queries actually provided by Studio plugins, or trusted sources; content that cannot be verified should be marked as assumptions or unknowns and must not be disguised as facts. Questions that can be answered by evidence must not be handed to the user.

When a domain skill discovers a necessary trade-off, hand it to this skill to obtain a decision and record it, then hand it back to the original work item. After the decision is closed, reversible file or Studio implementation that is already authorized by the original task and still within its goals and scope may continue without repeated approval; the interrogation conclusion does not expand the original task's authorization. Uploads, online service operations, payments, public releases, destructive data operations, or real-device acceptance still require separate verification of explicit authorization for that action, object, and impact.

Execution Order

1. Read the current work item, its scope, design documents, related instances/files, existing decisionRefs and valid decision records. Use only the Studio plugin to complete the minimum read-only inspection required for that decision; according to Studio Plugin Routingidentify the tool's actual capabilities. States not provided by the plugin remain unknown.
2. List verified facts and their traceable sources, assumptions, unknowns, and matters that must be chosen by the user. Source records are used for traceability; SHA is not calculated or compared.
3. Sort by dependency and impact. Decisions that are independent of each other, low-impact, and have the same recommendation may be grouped together; matters that are high-impact, mutually dependent, conflicting, or that would affect downstream approval should be asked one at a time.
4. Each question states the known facts, the single matter to be decided, the impact on goals/scope/cost/risk/rework/acceptance, two to three mutually exclusive options, and a recommendation with rationale. A recommendation is not a fact, and silence, continued execution, review passage, or a technical PASS must not be treated as an answer.
5. Record only authentic user messages or trusted message receipts provided by the host as the source of user answers. For replies that are vague, missing the object/version, conflicting with one another, or not covering the question, continue clarifying the current question; do not guess the user's intent.
6. After the question has been fully answered and all unknowns have been cleared, submit a versioned conclusion stating the approved object, scope, non-goals, rejected options, accepted risks, acceptance basis, and next steps, and ask the user to explicitly approve that conclusion. If an existing authentic answer explicitly approves the same complete object and scope, it may be reused without asking for approval again; when uncertain, first verify against the original message.
7. Per thedecision record convention, save a JSON record and add its project-relative path to the current work item's decisionRefs. After approval, verify that the record revision, object, and scope match the authentic user approval, then return the affected content to the original work item.

Roblox Decision Scope

• Experience and scope: target players, core loop, failure and retry, session context, target devices, MVP, and non-goals.
• Architecture and multiplayer: server-authoritative state, client presentation, Remote invocation direction and validation, multiplayer relationships and player-count boundaries, respawn/exit cleanup, and ownership of modules and shared state.
• Experience and Place: target Experience/Universe, Place, DataModel objects, and work item scope.get_studio_state does not provide Place identity; the current open state in Studio must not be inferred as an approved target or the state of another Place.
• Visuals and assets: global style, asset usage, permitted use of reference images, model/texture/animation boundaries, licensing evidence, Asset IDs, budgets and performance trade-offs. Search or generation results do not equal permission to use.
• Economy and online services: reward and progression rules, paid entitlements, randomized items, data fields and retention, DataStore policy, developer products and receipt behavior, operational configuration, and test namespaces.
• Quality and release: observable acceptance, applicable device/multiplayer test scope, risk acceptance, public scope, uploads/payments/live writes, version release, and rollback impact.

An existing valid record is reused only when it is bound to the same work item, subject, and revision scope. Candidate implementation changes or ordinary implementation adjustments do not automatically invalidate a decision; only a substantive change to the goal or approved scope creates a higher revision and requires re-handling of affected decisions. An unresolved decision pauses only the content that depends on that decision; independent and already authorized work may continue.

Write and Authorization Boundaries

• Before recording, first check the work item's scope。subject.files and subject.instances items, each of which must fall within its exact whitelist; conceptual decisions may leave both empty. Decision records cannot expand work item authorization.
• Before explicit approval is obtained, perform only read-only investigation, candidate comparison, question recording, and already authorized work that does not depend on that decision. Write to affected files or Studio instances only when the current authorization explicitly covers the target object.
• When uploads, external service writes, live configuration, payments, public release, destructive data operations, or on-device acceptance are required, separate explicit authorization must be obtained for that action, object, and impact; interrogation conclusions cannot be presumed to grant such authorization.
• Decision records are project-internal data, not proof of identity. User answers, user message quotations, approvers, or approval times must not be forged, signed on behalf of others, or fabricated after the fact. Tools can check JSON structure but cannot prove that message sources are authentic; the operator must verify against the actual conversation or a trusted host receipt.
• Do not store credentials, personal data, or the full text of restricted contracts in records. Examples only demonstrate the structure to be decided and must not serve as project facts, valid approvals, or evidence that work may continue.

Completion conditions

• Factual questions requiring human decisions have been investigated first; facts, assumptions, unknowns, and options are kept separate from one another.
• All blocking questions have been explicitly answered by a real user, unknowns have been reduced to zero, and the conclusion has received explicit approval within the applicable scope; existing valid approvals are reused after verification against the original message.
• The JSON decision record complies with thedecision record conventions, and decisionRefs corresponds to the work items, subjects, and revisions in the record.
• Open questions continue to block completion of the affected work items; independent work is not paused by unrelated questions, and decision approval is not extended into permission for other protected operations.