Reformulate tasks as observable goals

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Fix old sessions remaining active after password change. The teaching app requires the same account’s old session rejected while new login works: old access 200→401, new access 200. Check this contract rather than vaguely improving auth.

Mechanism

Translate request into observable inputs/action/results with identity/revision. Reproduce old-session behavior, change invalidation and verify old rejection/new login plus related checks. Bind stages to evidence and retain unfinished states instead of measuring activity.

Bad example

Refactor names across authentication and claim improved safety without inspecting the same old session or new login.

Good example

Use the teaching oracle: retain a synthetic account's old session, change password and expect 200→401; new login remains 200. Observe original failure, repair the affected path and rerun those identity-matched checks with revision/output. Do not infer universal auth security from refactoring.

Why the change matters

An observable goal separates completion from activity. Same-session and normal-path checks tie repair to the reported symptom rather than an unrelated passing assertion.

Observable expectation

Compare matched old rejection and new-login success. Another account, response wording only or ignored new-login failure is insufficient.

Record passes after execution only; no real credentials are changed here.

Limits

Session policy follows the app, not a universal rule. Oracles must inspect required identities/relationships; counts/scores alone cannot establish ordering or corresponding behavior.