Configure milestone outcome prompts

[OwenTanzer]

Summary

• let instructors enable outcome prompts per milestone and choose the allowed outcomes
• preserve existing completion values and repeatable-attempt history when configuration changes
• reject future disallowed outcomes in the data layer while retaining historical display and undo behavior
• backfill legacy milestones to the existing all-outcomes behavior

User impact

Milestones can now match the real evaluation workflow without erasing prior dog records when the curriculum changes. Repeatable attempts remain visible even if the prompt is later disabled.

Validation

• npm test (14/14)
• npm run build
• npx tsc -b
• npm run lint (only three pre-existing warnings)
• npm --prefix worker run typecheck
• git diff --check

Closes #33

[OwenTanzer]

Multiple outcome-enabled milestones corrupt “final outcome” semantics

The feature is supposed to work on arbitrary milestones, and the store explicitly permits more than one milestone to carry the outcome flag.

Trainer History, however, aggregates every completion and attempt from every currently flagged milestone into one bar, while telling the user it represents each dog’s most recent final decision. A dog with an outcome on Grounds and another on Advanced Final Blindfold is therefore counted twice.

The release behavior has the same hidden assumption. Any Fail releases the dog, but clearing one milestone’s previous Fail automatically reactivates the dog without checking whether another outcome-enabled milestone still has a current Fail.

This needs an architectural distinction:

Generic outcome prompt: allowed on any milestone.
Analytics/terminal outcome designation: either one explicitly selected milestone, or statistics grouped per milestone.
Release state must either track its cause or be recomputed against all relevant current outcomes rather than assuming one milestone owns it.

At present, the interface says “outcome prompt,” but the data model still treats every enabled prompt as the terminal evaluation.

[OwenTanzer]

Turning Repeatable off hides the preserved attempt history

The ledger is not deleted, but it becomes inaccessible:

A currently repeatable outcome milestone displays its attempts.
A disabled prompt displays preserved attempts only when m.repeatable is still true.
A prompt that remains enabled but is switched from Repeatable to Off renders the single-decision picker and no history.
A prompt disabled after Repeatable is switched off also renders no history.

That contradicts the PR’s preservation guarantee. Changing future behavior should not make past attempts vanish from the dog profile.

Fix: render historical attempts whenever ledger rows exist, independent of the milestone’s current prompt/repeatable configuration. The current flag should control future recording behavior, not historical visibility.

[OwenTanzer]

CI is green across tests, lint, build, and Worker type-checking. But the new tests cover canonicalization and pure permission checks, not multi-milestone statistics, release interactions, or configuration transitions around existing attempts.

The underlying allowed-outcome implementation is good. These are boundary failures produced by attaching a general feature to machinery that still assumes one terminal outcome milestone.

[OwenTanzer]

Addressed all requested changes in dd44aad:

• Split generic per-milestone outcome prompts from a single explicit terminal analytics/release designation. Trainer History now counts only that terminal milestone, so generic prompted milestones cannot double-count a dog.
• Added release-cause tracking and terminal-state reconciliation. Generic Fail outcomes do not release dogs, changing the terminal designation evaluates all current terminal state, and manually released dogs are never automatically reactivated.
• Historical attempt rows now render whenever they exist, independent of the milestone’s current Prompt or Repeatable settings.
• Added regression coverage for multi-milestone analytics and release boundaries. The full suite is 15/15; production build, app/Worker typechecks, lint, and diff checks pass.