What a change must not do

101. Learning objective

After this lesson, you can write one primary allowed mutation and two independent invariants for a mechanic, distinguish protected rules from preferences, and reject a proposed mutation that exceeds the requested scope.

102. Why this matters

A requested behavior can appear to work while changing another rule. A useful change boundary states both what may change and what must remain true. It lets you inspect a proposal before authorizing an edit.

103. Prior knowledge

You should be able to write an observable invariant for a mechanic. This lesson does not require you to edit a project or interpret a file-level diff.

104. Core concept: the change boundary

A change boundary has four parts:

• Primary allowed mutation: the one behavior or value that may change.
• Invariants: independent protected conditions that must remain true.
• Forbidden mutations: proposed changes that violate an invariant or alter an unrelated rule.
• Preferences: harmless implementation or presentation choices that are not gameplay rules.

Two invariants are independently informative when either one could be violated while the other still holds.

Consider this hypothetical health-pickup request:

Change the pickup so that it restores 15 health instead of 10. The existing maximum health is 100.

A useful boundary is:

• Allowed mutation: change the healing amount from 10 to 15.
• Invariant 1 — Maximum-health setting: maximum health remains 100.
• Invariant 2 — Health cap: settled player health never exceeds the current maximum health.

These rules protect different properties. Maximum health could be raised to 120 while health still remained at or below the maximum, violating Invariant 1 but not Invariant 2. Conversely, maximum health could remain 100 while a faulty pickup left settled health at 105, violating Invariant 2 but not Invariant 1.

Using the pickup at full health is therefore an edge-case test of the health-cap invariant, not a separate invariant. If health begins at 100, the settled post-action value must not exceed 100.

105. Observable checkpoints

Use only checkpoints that are available without internal instrumentation:

1. Pre-action state: the visible or otherwise inspectable state before the action.
2. Immediate displayed response: the response shown when the action occurs.
3. Settled post-action state: the state after the action has completed.
4. Repeated edge-case state: the settled result after repeating a relevant boundary case.

Do not claim to inspect a hidden transient state “during” resolution in this lesson. Internal execution inspection belongs to later technical work.

Apply the Stage 1 loop:

ACT → RESPOND → CHANGE → AGAIN

• ACT: use the pickup.
• RESPOND: observe the immediate displayed response.
• CHANGE: inspect the settled health value and any other protected value.
• AGAIN: repeat with an edge case, such as starting at maximum health.

106. Worked example

For the hypothetical pickup request, a complete boundary artifact could read:

Requested change: restore 15 health instead of 10.

Primary allowed mutation: change only the healing amount from 10 to 15.

Invariant 1 — Maximum-health setting: maximum health remains 100. Evidence: compare the visible or provided maximum-health value before and after the proposal.

Invariant 2 — Health cap: settled health never exceeds maximum health. Evidence: use the pickup near maximum health and at full health; inspect the settled post-action value after each attempt.

Forbidden mutations: do not raise maximum health or change unrelated damage values.

Preference: a clearer name for the healing value is acceptable if it does not change behavior.

The full-health check supplies evidence for Invariant 2. It does not duplicate the invariant as another protected rule.

107. Fixed proposal to inspect

Use this proposal rather than relying on an uncontrolled AI response:

Mock proposal

1. Change the pickup healing amount from 10 to 15.
2. Raise maximum health from 100 to 120 so the larger pickup feels more useful.
3. Rename the healing value from heal to healingAmount for clarity.

Classify each item before comparing your answer with an AI:

If an implementation preference is ambiguous or could conceal behavior, request clarification rather than accepting it automatically.

108. AI-native workflow

Use AI as support for clarification and inspection, not as a project editor:

1. State the requested change.
2. Name exactly one primary allowed mutation.
3. Write two independent invariants and explain the distinct property protected by each.
4. Attach observable evidence to each invariant.
5. Classify each fixed proposal item yourself.
6. Optionally ask an AI to classify the same items and explain its reasoning.
7. Compare its classification with your boundary. Do not treat the AI response as proof.

Use this brief:

Mechanic:
Requested change:
Primary allowed mutation:
Invariant 1 and protected property:
Invariant 2 and protected property:
Observable evidence:
Forbidden mutations:
Preferences:
Out of scope:

109. Optional Git context

Git is contextual only in this lesson. If an instructor provides a repository transcript, record the branch and latest commit summary from that transcript. If you already have a repository available, you may optionally run:

git status --short --branch
git log -1 --oneline

Do not edit files, stage changes, create commits, switch branches, reset, merge, or push. Do not perform path-level diff interpretation here. If no repository or transcript is available, write: “Repository context unavailable.” This does not prevent completion of the lesson.

110. Guided practice

Using the fixed proposal:

1. Copy the requested change into the brief.
2. Write exactly one primary allowed mutation.
3. Write the maximum-health-setting invariant and the health-cap invariant.
4. Explain in one sentence why they protect different properties.
5. For each invariant, name an observable checkpoint and the evidence you would record.
6. Classify proposal items 1–3 as accept, reject, or request clarification. You may mark an accepted preference as optional.
7. Justify why item 2 must be rejected rather than added to the brief.
8. Identify the full-health scenario as an edge-case test of the health-cap invariant.
9. Optionally record the lightweight Git context described above.

111. Scored practical item

Submit one boundary artifact for the fixed proposal. It is complete when it includes:

• the requested change;
• exactly one primary allowed mutation;
• two independent named invariants;
• a distinct-property explanation for each invariant;
• observable evidence using pre-action, immediate displayed response, settled post-action, or repeated edge-case checkpoints;
• a decision for all three proposal items;
• a justification for rejecting the maximum-health mutation; and
• one preference clearly separated from gameplay rules.

Score one point for each requirement. A complete artifact earns 8 out of 8. Revise any missing or conflated requirement before continuing.

112. Common mistakes

• Treating full-health use as a second invariant rather than as a test of the health cap.
• Accepting an out-of-scope mutation because the requested change is also present.
• Presenting a naming preference as a gameplay rule.
• Claiming evidence from an unobservable internal state.
• Treating repository status or an AI explanation as proof that runtime rules hold.

113. Key takeaways

• Define one allowed mutation before evaluating a proposal.
• Use independent invariants that protect distinct mechanic properties.
• Test an invariant with observable checkpoints and relevant edge cases.
• Reject unrelated gameplay mutations instead of expanding the brief to include them.
• Keep harmless preferences separate from required behavior.

114. Next lesson

Next, you will inspect a small diff and describe what it did in plain language. Committing and reverting appear later in the checkpoint sequence.

115. Knowledge check