Reproduce a lifecycle failure

1174. Lesson identity

Module

3.8 — Memory and lifecycle

Lesson

Reproduce a lifecycle failure

Academic type

Debugging Lab

Schema type

practical

Order

2 in the module

Estimated time

60–75 minutes

1175. Learning objective

After this lesson, you can reproduce one lifecycle failure—either an observable failure in the current project or the deterministic fallback scenario—and document it with repeatable steps, boundary instrumentation, and observable evidence.

1176. Why this matters

A report such as “the object sometimes breaks after restarting” is not yet production debugging evidence. A useful record separates the trigger, lifecycle boundary, observed state, and expected state. This makes an AI-generated hypothesis testable instead of allowing it to become an unverified patch.

A failure that cannot be observed must be reported honestly. Do not manufacture one by changing the reproduction procedure until something breaks.

1177. Prior knowledge

You should be able to:

• identify an acquired resource and its owner;
• explain why cleanup belongs to the resource lifecycle;
• distinguish normal completion from an interrupted or repeated lifecycle path;
• use the project’s existing logging or diagnostic output.

This lesson depends directly on Dispose is a lifecycle operation.

1178. Core concept

A lifecycle failure becomes actionable when three elements are connected:

1. Reproduction: a bounded sequence of actions that triggers the failure;
2. Instrumentation: observations placed at lifecycle boundaries such as acquire, use, release, and invalid reuse;
3. Evidence: a record comparing expected behavior with actual behavior.

Do not begin by changing production behavior. First establish whether the failure can be repeated and which boundary may violate the ownership contract. If the project has no observable lifecycle failure, use the deterministic fallback below. The fallback is a controlled test scenario, not a claim about the project’s history.

1179. Mental model: Boundary Evidence Chain

A hypothesis is not evidence. “The object was probably released twice” remains a hypothesis until boundary observations support or reject it.

1180. Concrete example

Imagine a temporary interaction handle used while a player inspects an object. Its intended contract is to be acquired when inspection begins, used only during the active session, released when inspection ends, and never reused after release.

A bounded reproduction record might state:

1. Start with the interaction handle inactive.
2. Begin inspection.
3. End inspection.
4. Begin inspection again without reloading the scene.
5. Repeat the cycle three times.
6. On the third cycle, observe an invalid-use error.

Boundary markers might show acquire, release, acquire, release, followed by a use attempt carrying the previous handle identity. That evidence narrows the investigation to ownership and reuse across the inspection boundary, but it does not yet prove a root cause or a fix.

1181. AI-native workflow

Use AI to organize evidence and generate testable hypotheses, not as a substitute for reproduction.

1. Provide the lifecycle contract, reproduction steps, and observed markers. Do not ask for a fix first.
2. Request three competing explanations, each connected to an observation that could support or reject it.
3. Ask for the smallest instrumentation additions at acquire, use, and release boundaries.
4. Apply only instrumentation you can explain and inspect, then run the scenario yourself.
5. Return the captured output and ask AI to revise the hypotheses. Classify each statement as observed, inferred, or untested.

You remain responsible for deciding whether the observed behavior matches the defined scenario and whether the instrumentation changed timing or behavior.

1182. Git workflow

Before applying lifecycle instrumentation, create a recovery checkpoint in the existing repository. Record its identifier so you can return to the pre-instrumentation state if a diagnostic change affects behavior or timing.

When practical, keep instrumentation separate from any later permanent fix. Do not combine diagnostic markers with a correction in this exercise. If no later fix is made, record that only the instrumentation state was preserved.

1183. Common mistake

Do not treat a non-reproduction as proof that a reported failure never existed, and do not alter the steps merely to force a failure. A clean run records only one outcome. Likewise, a deterministic fallback must be labeled as a controlled test scenario and must not be presented as an incident observed in the project.

1184. Guided practice

Work in the existing project and choose one resource or stateful object with a visible lifecycle. There are two permitted routes. Capability completion requires a reproduced lifecycle failure: either a project failure or the clearly labeled deterministic fallback.

Part A — Define the contract

Write four short statements:

• Owner: who or what controls the resource;
• Acquisition: when the resource becomes valid;
• End of valid use: when consumers must stop using it;
• Cleanup: what releases, resets, or invalidates it.

Part B — Attempt an honest project reproduction

Write a numbered procedure containing a defined starting state, exact player or test actions, repetition or timing conditions, expected behavior, and actual behavior when the failure occurs.

Run the same procedure at least three times. Record each outcome as reproduced, not reproduced, or intermittent. For an intermittent result, record what conditions differed between runs. Do not change the procedure merely to force a failure.

• If the project failure is reproduced, continue with Part D using that failure.
• If it is not reproduced or no observable failure exists, record that outcome and continue to Part C, the deterministic fallback. Honest non-reproduction alone does not complete the capability.

Part C — Deterministic fallback, only for projects without an observable failure

Use this controlled scenario only when Part B produced no observable lifecycle failure. Select a disposable test resource or stateful test object whose lifecycle contract you can inspect. In a test scene, test harness, or isolated diagnostic path, perform this sequence:

1. Create or acquire a fresh test resource.
2. Record its identity and valid state.
3. Release, dispose, reset, or invalidate it through its normal cleanup path.
4. Record its released or invalid state.
5. Invoke one operation that its contract explicitly forbids after release.
6. Repeat the complete sequence at least three times with a fresh resource each time.

The expected result is that the invalid operation is rejected, safely ignored with an explicit diagnostic, or produces the project’s defined failure signal. If no invalid-reuse diagnostic exists, add the smallest temporary assertion or boundary marker needed to expose the contract violation.

Do not call this a production incident or claim that the project previously exhibited it. Label the evidence deterministic fallback scenario and identify the deliberately exercised invalid transition.

If the chosen resource cannot be exercised safely after cleanup, do not guess. Choose another disposable test resource, or document that the fallback could not be run and do not claim capability completion.

Part D — Instrument the boundaries

Before adding or enabling instrumentation, create and record a Git recovery checkpoint. Add or enable minimal diagnostic markers for the relevant lifecycle transitions. Each marker should include, when available:

• transition name;
• resource or object identity;
• owner or session identity;
• run or cycle number;
• relevant state, such as valid, released, or already released.

Do not log every frame. Keep diagnostic changes separate from any later permanent fix when practical, and do not implement a permanent fix as part of this exercise.

Part E — Make one debugging decision

Choose one decision and justify it in two or three sentences:

• the project reproduction is sufficiently bounded to investigate;
• the deterministic fallback reproduced the contract violation and is clearly labeled;
• the instrumentation is at the wrong boundary and must move;
• the evidence rejects the initial hypothesis, so another hypothesis is required;
• the failure remains non-reproducible, so capability completion cannot yet be claimed and a controlled variation is needed.

Part F — Capture the evidence record

Complete this record:

Failure label:
Scenario source: project reproduction / deterministic fallback / non-reproduction only
Starting state:
Recovery checkpoint before instrumentation:
Reproduction steps:
Expected behavior:
Actual behavior:
Runs and outcomes:
Lifecycle boundary under examination:
Observed markers:
Initial hypothesis:
Evidence for or against the hypothesis:
Instrumentation kept separate from a later final fix:
Next smallest experiment:
Capability completion: yes / no

A project non-reproduction must remain recorded as such. A fallback record must state that the invalid transition was deliberately exercised in a controlled test. Do not implement a permanent fix in this exercise.

1185. Validation and evidence

The completed reproduction record, boundary evidence, and debugging decision constitute the practical capability assessment. The quiz is only a low-stakes knowledge check.

Capability completion requires one of the following:

• a lifecycle failure reproduced in the current project across the defined runs, with observable evidence; or
• the deterministic fallback reproduced across the defined runs, explicitly labeled as a fallback and identifying the deliberate invalid transition.

Retain or submit:

• a numbered procedure with a defined starting state;
• results from at least three runs;
• boundary instrumentation or existing diagnostic output;
• an expected-versus-actual comparison;
• one explicit hypothesis connected to observed evidence;
• one justified next experiment;
• the recovery checkpoint created before instrumentation;
• a statement indicating whether instrumentation remained separate from a later final fix;
• the scenario source and capability-completion decision.

If the project failure is not reproduced and the fallback is not completed successfully, mark capability completion no. Honest non-reproduction is valid debugging evidence, but it does not satisfy this lesson’s capability. Do not convert it into a reproduced incident or present the fallback as project history.

1186. Key takeaways

• Reproduction turns a vague symptom into a repeatable test condition.
• Boundary instrumentation exposes transitions and ownership without indiscriminate logging.
• A deterministic fallback can demonstrate the capability when no project failure is observable, but it must remain clearly labeled as a controlled scenario.
• Honest non-reproduction is evidence, but it does not complete a capability requiring a reproduced failure.
• Hypotheses must be compared with observable evidence.
• Diagnostic instrumentation should remain separate from a later permanent fix when practical.

1187. Next lesson

Next: 3.9 — Assets. You will carry this evidence discipline into the next module when evaluating asset acquisition, use, and release.

1188. Knowledge check