How must a Modeling Session distinguish missing source evidence, unresolved assumptions, missing Attribute data, and unsupported runtime capability; what prerequisites may it create as canonical game data; when does “create missing mechanics automatically” require a reusable code/schema/editor/runtime change instead; and what validation, tests, review, and release boundary makes such a change fully resolved rather than best effort?
Part of #1
## Question
How must a Modeling Session distinguish missing source evidence, unresolved assumptions, missing Attribute data, and unsupported runtime capability; what prerequisites may it create as canonical game data; when does “create missing mechanics automatically” require a reusable code/schema/editor/runtime change instead; and what validation, tests, review, and release boundary makes such a change fully resolved rather than best effort?
The agent classifies each blocked record before any canonical mutation.
Condition
Required result
Stored prose omits or contradicts behavior needed for a valid model
clarification_required; identify the exact missing evidence and write nothing
Stored prose defines the behavior, but evaluation needs an encounter value
Create a typed Scenario Input and use requires_assumptions
A required Attribute is absent
Reuse an exact canonical match, create a fully determined supported Attribute through its owning audited action, or report a capability gap
The mechanic grammar, persistence, editor, value pipeline, or runtime cannot represent the behavior
capability_gap; do not approximate or persist a best-effort model
An ambiguity in game behavior is missing evidence. The agent must not turn ambiguity into a Scenario Input. A Scenario Input represents an explicit variable that the authored prose leaves to the combat situation.
Canonical prerequisites
The agent may create a prerequisite when the stored descriptions determine its identity and semantics, the current schema represents it, and the normal owning action can validate and audit it. The agent uses the same permissions, duplicate checks, moderation rules, and audit path as an Operator.
Creating an Attribute is insufficient when the Builder cannot produce its authoritative loadout value. That case requires a capability change covering the value pipeline. The agent must not create aliases, placeholder Attributes, fabricated IDs, or inactive records to make validation pass.
Prerequisite creation and model persistence remain separate idempotent mutations. A retry reuses an exact prerequisite created by an earlier attempt.
Capability changes
The agent may implement a reusable capability change. The branch must cover every affected layer rather than patching generated data around an unsupported contract:
mechanic runtime types, registries, validation, and evaluation;
draft grammar and compiler;
normalized schema, migrations, and persistence;
ISAC editor and mechanic reference;
AI context, capability manifest, prompt contract version, and response validation;
Builder value production and consumption when the outcome depends on an Attribute;
focused unit, persistence, route, and integration tests;
relevant architecture and mechanic-authoring documentation.
The agent records the affected source descriptions, unsupported behavior, proposed semantic contract, branch, commits, migration impact, and verification evidence. Independent code and security review must find no blocking issue.
Automated release gate
A capability gap reaches verified_branch after focused tests, the repository check/build/test suite, migration and rollback checks, and independent review pass. The original record remains pending and no generated canonical model may rely on branch-only behavior.
The release pipeline then:
merges through the normal protected-branch path;
deploys to staging and verifies migrations, health, editor round trips, and one representative generation without canonical production writes;
deploys to production and verifies health and the installed mechanic contract version;
resumes the original generation run from its stored checkpoint.
A failed check, review, merge, migration, or health verification stops the pipeline. The agent preserves the prior database and deployed application, marks the release failure on the capability result, and leaves affected records pending. It must not downgrade them to captured_only or save partial models.
The capability gap itself may report resolved by its verified branch reference. The parent modeling record becomes successful only after deployment and resumed persistence succeed.
Completion boundary
A record is fully modeled only when all canonical prerequisites exist, the deployed runtime supports the program, the source fingerprint still matches, the owning action persists a current immutable model revision, and post-save validation reads it back successfully. Tests or a branch alone do not make the record modeled.
Retries reuse prior prerequisites and do not duplicate records.
Unsupported behavior cannot enter storage as an approximation or empty captured placeholder.
Capability branches exercise compiler, persistence, runtime, editor, AI contract, and Builder integration.
Release failures leave canonical models and the previous deployment unchanged.
A resumed run rechecks source fingerprints before persisting any model.
# Autonomous mechanic-capability boundary
## Generation classification
The agent classifies each blocked record before any canonical mutation.
| Condition | Required result |
| --- | --- |
| Stored prose omits or contradicts behavior needed for a valid model | `clarification_required`; identify the exact missing evidence and write nothing |
| Stored prose defines the behavior, but evaluation needs an encounter value | Create a typed Scenario Input and use `requires_assumptions` |
| A required Attribute is absent | Reuse an exact canonical match, create a fully determined supported Attribute through its owning audited action, or report a capability gap |
| The mechanic grammar, persistence, editor, value pipeline, or runtime cannot represent the behavior | `capability_gap`; do not approximate or persist a best-effort model |
An ambiguity in game behavior is missing evidence. The agent must not turn ambiguity into a Scenario Input. A Scenario Input represents an explicit variable that the authored prose leaves to the combat situation.
## Canonical prerequisites
The agent may create a prerequisite when the stored descriptions determine its identity and semantics, the current schema represents it, and the normal owning action can validate and audit it. The agent uses the same permissions, duplicate checks, moderation rules, and audit path as an Operator.
Creating an Attribute is insufficient when the Builder cannot produce its authoritative loadout value. That case requires a capability change covering the value pipeline. The agent must not create aliases, placeholder Attributes, fabricated IDs, or inactive records to make validation pass.
Prerequisite creation and model persistence remain separate idempotent mutations. A retry reuses an exact prerequisite created by an earlier attempt.
## Capability changes
The agent may implement a reusable capability change. The branch must cover every affected layer rather than patching generated data around an unsupported contract:
- mechanic runtime types, registries, validation, and evaluation;
- draft grammar and compiler;
- normalized schema, migrations, and persistence;
- ISAC editor and mechanic reference;
- AI context, capability manifest, prompt contract version, and response validation;
- Builder value production and consumption when the outcome depends on an Attribute;
- focused unit, persistence, route, and integration tests;
- relevant architecture and mechanic-authoring documentation.
The agent records the affected source descriptions, unsupported behavior, proposed semantic contract, branch, commits, migration impact, and verification evidence. Independent code and security review must find no blocking issue.
## Automated release gate
A capability gap reaches `verified_branch` after focused tests, the repository check/build/test suite, migration and rollback checks, and independent review pass. The original record remains pending and no generated canonical model may rely on branch-only behavior.
The release pipeline then:
1. merges through the normal protected-branch path;
2. deploys to staging and verifies migrations, health, editor round trips, and one representative generation without canonical production writes;
3. deploys to production and verifies health and the installed mechanic contract version;
4. resumes the original generation run from its stored checkpoint.
A failed check, review, merge, migration, or health verification stops the pipeline. The agent preserves the prior database and deployed application, marks the release failure on the capability result, and leaves affected records pending. It must not downgrade them to `captured_only` or save partial models.
The capability gap itself may report resolved by its verified branch reference. The parent modeling record becomes successful only after deployment and resumed persistence succeed.
## Completion boundary
A record is fully modeled only when all canonical prerequisites exist, the deployed runtime supports the program, the source fingerprint still matches, the owning action persists a current immutable model revision, and post-save validation reads it back successfully. Tests or a branch alone do not make the record modeled.
## Acceptance checks
- Classification tests distinguish missing evidence, Scenario Inputs, missing Attributes, and capability gaps.
- Prerequisite creation uses canonical actions, permissions, moderation, duplicate detection, and append-only audit events.
- Retries reuse prior prerequisites and do not duplicate records.
- Unsupported behavior cannot enter storage as an approximation or empty captured placeholder.
- Capability branches exercise compiler, persistence, runtime, editor, AI contract, and Builder integration.
- Release failures leave canonical models and the previous deployment unchanged.
- A resumed run rechecks source fingerprints before persisting any model.
Decision specification recorded above. The contract covers generation classification, canonical prerequisites, capability implementation, automated release gates, and the completion boundary. Closing as resolved.
Decision specification recorded above. The contract covers generation classification, canonical prerequisites, capability implementation, automated release gates, and the completion boundary. Closing as resolved.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #1
Question
How must a Modeling Session distinguish missing source evidence, unresolved assumptions, missing Attribute data, and unsupported runtime capability; what prerequisites may it create as canonical game data; when does “create missing mechanics automatically” require a reusable code/schema/editor/runtime change instead; and what validation, tests, review, and release boundary makes such a change fully resolved rather than best effort?
Autonomous mechanic-capability boundary
Generation classification
The agent classifies each blocked record before any canonical mutation.
clarification_required; identify the exact missing evidence and write nothingrequires_assumptionscapability_gap; do not approximate or persist a best-effort modelAn ambiguity in game behavior is missing evidence. The agent must not turn ambiguity into a Scenario Input. A Scenario Input represents an explicit variable that the authored prose leaves to the combat situation.
Canonical prerequisites
The agent may create a prerequisite when the stored descriptions determine its identity and semantics, the current schema represents it, and the normal owning action can validate and audit it. The agent uses the same permissions, duplicate checks, moderation rules, and audit path as an Operator.
Creating an Attribute is insufficient when the Builder cannot produce its authoritative loadout value. That case requires a capability change covering the value pipeline. The agent must not create aliases, placeholder Attributes, fabricated IDs, or inactive records to make validation pass.
Prerequisite creation and model persistence remain separate idempotent mutations. A retry reuses an exact prerequisite created by an earlier attempt.
Capability changes
The agent may implement a reusable capability change. The branch must cover every affected layer rather than patching generated data around an unsupported contract:
The agent records the affected source descriptions, unsupported behavior, proposed semantic contract, branch, commits, migration impact, and verification evidence. Independent code and security review must find no blocking issue.
Automated release gate
A capability gap reaches
verified_branchafter focused tests, the repository check/build/test suite, migration and rollback checks, and independent review pass. The original record remains pending and no generated canonical model may rely on branch-only behavior.The release pipeline then:
A failed check, review, merge, migration, or health verification stops the pipeline. The agent preserves the prior database and deployed application, marks the release failure on the capability result, and leaves affected records pending. It must not downgrade them to
captured_onlyor save partial models.The capability gap itself may report resolved by its verified branch reference. The parent modeling record becomes successful only after deployment and resumed persistence succeed.
Completion boundary
A record is fully modeled only when all canonical prerequisites exist, the deployed runtime supports the program, the source fingerprint still matches, the owning action persists a current immutable model revision, and post-save validation reads it back successfully. Tests or a branch alone do not make the record modeled.
Acceptance checks
Decision specification recorded above. The contract covers generation classification, canonical prerequisites, capability implementation, automated release gates, and the completion boundary. Closing as resolved.