Repository navigation
fix(#2889): key isTrackComplete off the highest-order checkpoint - #2892
Merged
Merged
Conversation
App Space `isTrackComplete` marked a segmented track complete when ANY checkpoint unlocked (`checkpoints.some(isSegmentItemUnlocked)`). For a hypothetical track with a non-terminal plain CHECKPOINT (authored at a lower order than later tutorials), that early checkpoint unlocking would flag the whole track complete while downstream work remained. Make the rule prize-aware instead of a naive highest-order restriction: - lane-prize checkpoints (prizeId set) are authored to earn the reward the moment their single lane finishes → ANY unlocked one completes the track (keeps `some` semantics); - plain downstream checkpoints (no prizeId) are joins → only the TERMINAL (highest-order) one completes the track. Add client unit tests for isTrackComplete/progressPercent over fork payloads (the aggregate rule was previously only exercised indirectly via the barcode tests): the non-terminal-checkpoint bug guard fails against the old `some()` rule, and a lane-prize-only payload guards against an over-eager highest-order-only regression. Follow-up to #2887 (PR #2888), finding M1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2889. Follow-up to #2887 (PR #2888), finding M1.
Problem
AppSpace.vueisTrackCompletemarked a segmented track complete when any checkpoint unlocked (checkpoints.some(c => isSegmentItemUnlocked(c))). For every track shape authored today this agrees with the old flat rule, but a track with a non-terminal plain CHECKPOINT (authored at a lowerorderthan later tutorials) would be flagged complete as soon as that early checkpoint unlocked — while downstream tutorials remained incomplete.Fix
Prize-aware restriction rather than a naive highest-order-only rule (which would have regressed the authored lane-prize case):
prizeIdset) are authored to earn the reward the moment their single lane finishes → any unlocked one completes the track (keepssomesemantics);prizeId) are joins → only the terminal (highest-order) one completes the track.allSegmentItemsflattens segments in authored ascending-orderorder, so the last non-prize checkpoint is the highest-order one.Tests
New
describe('AppSpace track completion aggregate (#2889)')block inAppSpace.segments.test.tsexercisingisTrackComplete/progressPercentover fork payloads (previously only covered indirectly via the barcode tests):some()rule — verified by temporarily reverting);8/8 tests pass locally (
npx vitest run hugo-apps/src/app-space/__tests__/AppSpace.segments.test.ts).Severity
Minor / latent — not reachable under current authoring conventions; safe follow-up to #2888.
🤖 Generated with Claude Code