Milestone studio

538. Lesson identity

Module

1.micro-loop — The Playable Micro-Loop

Lesson

Milestone studio

Academic type

Integration

Schema type

Practical

Order

3 of 3 in this module

Estimated time

45–90 minutes; the external review may be completed asynchronously

Purpose

Assemble the evidence packet.

Primary concept

Proof, not polish.

Capability

Run the loop, show the criteria, and present AI and Git evidence.

539. Learning objective

After this lesson, you can assemble and defend an evidence packet that demonstrates a working micro-loop, maps observed behavior to explicit criteria, distinguishes the responsibilities of input, rule, presentation, and feedback, and records the checkpoint and decisions behind the change.

540. Why this matters

A playable result is only one part of a credible milestone. You must also show what was supposed to happen, what you tested, which state changed, who was responsible for changing it, and which implementation change produced the result. Runtime observations prove runtime behavior. AI records explain how the work was directed, while Git makes its history and scope inspectable.

A runnable check by someone who did not build the change tests whether the instructions and evidence are reproducible. That reviewer may be an instructor, peer, asynchronous reviewer, or another person available later. Lack of immediate access to a reviewer is not a capability failure; record the check as pending and submit usable instructions for later review.

541. Prior knowledge

Before this milestone, you should be able to define a small player-facing action, distinguish a mechanic from its presentation, describe the cycle INPUT → RULE → PRESENTATION → FEEDBACK, state a bounded change with acceptance criteria and exclusions, direct a small implementation, run the project from a known state, and identify relevant files. You should also have the AI exchange and Git history produced during the previous implementation lesson.

542. Core concept

Proof, not polish means evaluating a milestone through observable acceptance criteria rather than visual finish. A proof packet connects four elements:

1. Intent: the bounded behavior requested.
2. Implementation: the project change that was made.
3. Observation: the behavior reproduced at runtime.
4. Evidence: artifacts that let another person inspect the claim.

Before making a further correction, preserve a recoverable checkpoint. Keep a change only when the criteria still pass and the diff remains within scope. Otherwise, revert it and record the reason.

543. Canonical loop responsibilities

Use the canonical labels directly:

• INPUT: detects the player action. It does not decide the outcome.
• RULE: evaluates conditions and changes the state it owns or manages.
• PRESENTATION: represents the resulting state so it can be perceived. It does not own the rule's state change.
• FEEDBACK: confirms the result through an immediate signal.

Whether the loop is ready for another input is recorded separately as repeat readiness. Feedback may help the player understand the result, but it is not responsible for scheduling or accepting the next input unless the implementation explicitly assigns that separate responsibility to it.

544. Mental model

Use Claim → Checkpoint → Run → Record → Inspect:

This studio model packages the result for evaluation; it does not replace the canonical loop.

545. Concrete example

Suppose the bounded change is: “When the existing control is used, the active state changes color; do not alter input handling, the underlying rule, feedback, or unrelated files.”

The evidence distinguishes responsibilities:

• INPUT: the existing control detects one activation.
• RULE: the existing rule changes the active state.
• PRESENTATION: the displayed color represents that state.
• FEEDBACK: an immediate signal confirms the result.
• Repeat readiness: after reset or restart, the same action can be tested again.

Before attempting a correction, record the current commit and baseline behavior. Make only the proposed correction. Keep it if the criteria pass and the diff remains in scope; revert it if it breaks the loop or introduces unrelated work. The packet needs enough evidence to support the claim and disclose limitations, not a visual redesign.

546. AI-native workflow

1. Preserve the bounded request, acceptance test, and exclusions from the previous lesson.
2. Select the useful AI exchange: the request, proposed change, and any correction or verification direction.
3. Make exactly one explicit accept or refuse decision about an AI proposal.
4. Tie the reason to acceptance criteria, scope, or maintainability.
5. If you accept a change, verify it at runtime. If you refuse it, identify the criterion or boundary it would violate and leave that proposal unapplied.
6. Label AI evidence as direction and trace, not proof that runtime behavior works.

547. Git workflow

1. Inspect the working tree and current diff.
2. Identify the files relevant to the bounded change.
3. Before a new correction, create or identify a checkpoint commit, branch point, or equivalent recoverable state.
4. Record its identifier and baseline behavior.
5. Make the smallest necessary change and inspect the new diff.
6. Record a keep-or-revert decision tied to criteria and scope.
7. Record the branch, checkpoint, final commit, relevant files, and any unrelated work or limitation.

Git proves change history and scope, not runtime behavior. Do not treat a clean working tree as proof that the loop works.

548. Common mistakes

• Treating a screenshot or polished screen as proof of the full milestone.
• Letting PRESENTATION appear to perform the state change owned by RULE.
• Combining FEEDBACK with readiness for the next input instead of recording them separately.
• Changing the project before preserving a checkpoint.
• Submitting an entire AI conversation without selecting the evidence that explains the decision.
• Assuming your own successful run proves that another person can follow the instructions.

549. Guided practice

Create an evidence packet for the micro-loop change from the previous lesson. Follow this sequence:

1. Write one sentence naming the behavior that must be true and one sentence naming what must not change.
2. Convert the statement into two to four observable acceptance criteria. Each criterion must be testable at runtime or through inspection of the change.
3. Add a canonical loop map:

Canonical loop map:
- INPUT: [player action and how it is detected]
- RULE: [condition evaluated, state changed, and resulting value]
- PRESENTATION: [how the resulting state is represented]
- FEEDBACK: [immediate signal confirming the result]
- Repeat readiness: [how you know the loop can accept or begin the next attempt]

4. Add a state-ownership note:

State-ownership note:
- Managed state: [state or value that changes]
- State owner: [rule, component, or function responsible for changing it]
- Read by: [presentation or feedback responsibility that observes or represents it]
- Boundary: [what presentation and feedback must not change]

5. Inspect the working tree and record the baseline. Before making a new change, create or identify a recoverable checkpoint and record its identifier and baseline behavior.
6. Run the loop at least twice from a known starting state. For each run, record INPUT, RULE result, PRESENTATION, FEEDBACK, and repeat readiness.
7. If a correction is necessary, make only that bounded change. Decide whether to keep or revert it and give a reason tied to a criterion or scope boundary.
8. Review the AI exchange and make exactly one accept/refuse decision about an AI proposal. Record the decision and reason.
9. Map every acceptance criterion to a specific piece of evidence. Mark any criterion that was not tested.
10. Inspect the Git diff and record the branch, checkpoint, final commit, relevant files, and any scope concern.
11. Give the packet and run instructions to an instructor, peer, asynchronous reviewer, or another person who did not build the change. Ask them to perform the test without verbal assistance. If nobody is available during this sitting, mark the external check pending, submit the instructions, and schedule or request a later review.
12. Assemble the packet with this template:

Milestone: [short name]
Claim: [behavior that must be true]
Exclusions: [behavior or files intentionally outside scope]

Acceptance criteria and evidence map:
- Criterion: [observable criterion]
  Evidence: [runtime record, diff, or other relevant artifact]
  Result: pass / fail / not tested
- Criterion: [observable criterion]
  Evidence: [artifact]
  Result: pass / fail / not tested

Canonical loop map:
- INPUT: [player action and detection]
- RULE: [condition, managed state, and resulting value]
- PRESENTATION: [representation of the resulting state]
- FEEDBACK: [immediate confirmation]
- Repeat readiness: [evidence that another attempt can begin]

State-ownership note:
- Managed state:
- State owner:
- Read by:
- Boundary:

Checkpoint before change:
- Baseline branch:
- Checkpoint commit or recoverable state:
- Baseline behavior:

Runtime test:
- Starting state:
- INPUT:
- RULE result:
- PRESENTATION:
- FEEDBACK:
- Repeat readiness:
- First-run result:
- Second-run result:

Change decision:
- Change attempted:
- Decision: keep / revert
- Reason:
- Evidence before and after:

AI evidence:
- Bounded request:
- Relevant direction or correction:
- AI proposal:
- Decision: accept / refuse
- Reason:

Git evidence:
- Branch:
- Checkpoint:
- Final commit:
- Relevant files:
- Scope review:

External runnable check:
- Reviewer type: instructor / peer / asynchronous reviewer / other / pending
- Status: completed / pending
- Could the reviewer run it from these instructions? yes / no / pending
- Observed result:
- Clarification needed:
- Planned review step if pending:

Limitations or follow-up:
[honest note, or “None identified”]

550. Validation / evidence

The packet is adequate when it contains:

• A bounded claim and explicit exclusions.
• Two to four observable acceptance criteria, each mapped to evidence and marked pass, fail, or not tested.
• A canonical loop map that distinguishes INPUT, RULE, PRESENTATION, and FEEDBACK.
• A separate repeat-readiness field.
• A state-ownership note showing that RULE changes the managed state while PRESENTATION and FEEDBACK only read or represent it unless another responsibility is explicitly documented.
• A checkpoint recorded before any new change.
• Two runtime attempts from a known starting state.
• A justified keep-or-revert decision.
• One justified AI accept/refuse decision and a selected AI trace.
• An inspectable Git diff, checkpoint, final commit, relevant-file list, and scope review.
• A completed external runnable check or usable instructions with that check clearly marked pending.
• An honest limitation note.

If a criterion was not tested, mark it not tested and state the next verification step. If the external check identifies ambiguity, revise the instructions before claiming that another person can reproduce the test.

551. Key takeaways

• A milestone proves a bounded claim; it does not need to look finished.
• RULE owns or manages state change; PRESENTATION represents state and FEEDBACK confirms the result.
• Repeat readiness is recorded separately from feedback.
• Runtime evidence proves behavior, AI evidence explains direction and decisions, and Git evidence makes scope and history inspectable.
• An external check may be synchronous or asynchronous and must not be treated as failed solely because a reviewer was unavailable during the studio sitting.

552. Next lesson

The verified packet becomes the baseline for Stage 2. The next lesson will turn the loop into an explicit system contract covering actors, inputs, rules, outcomes, and neighboring behavior that must remain protected.

553. Knowledge check