Implement Incoming Jumps feature end-to-end#185
Conversation
- Implement updateIncomingJumpsForLabel service function - Integrate into syncLabelsInTransaction - Add Incoming Jumps section to LabelPropertiesPanel - Show count badge, source labels, choice text, and conditions - Design and implementation plan docs
… incoming jumps update logic
|
Warning Review limit reached
More reviews will be available in 56 minutes and 34 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds persistent IncomingJump metadata and UI: shared type, DB migration and schema, backend batched recompute and UUID-aware resolution integrated into label sync, seed updates to populate test data, and frontend incoming/outgoing jump panels. ChangesIncoming Jumps Feature
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (2)
docs/superpowers/specs/2026-06-02-incoming-jumps-design.md (1)
62-98: 💤 Low valueMinor doc drift vs. the shipped implementation.
A few details in this draft don't match what landed and could mislead future readers:
- Line 65: the function is implemented as the batch
updateIncomingJumpsForLabels(context, labelIds, projectId), not a per-labelupdateIncomingJumpsForLabel.- Line 98: the shared type/DB field is
incomingJumps(camelCase), notincoming_jumps.Optionally update or add a "as-built" note. Fine to defer since this is a dated design spec.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/superpowers/specs/2026-06-02-incoming-jumps-design.md` around lines 62 - 98, Update the spec to match the shipped implementation: replace references to the per-label function `updateIncomingJumpsForLabel(tx, labelId, projectId)` with the actual batch function `updateIncomingJumpsForLabels(context, labelIds, projectId)` (use the exact symbol `updateIncomingJumpsForLabels`) and change the documented shared/DB field `incoming_jumps` to the camelCase `incomingJumps` as implemented on `PublicLabel`; optionally add an "as-built" note summarizing these two diffs so readers aren't misled by the dated draft.apps/backend/scripts/seed-technical-badges.ts (1)
733-754: 💤 Low valueFabricated automatic jumps don't correspond to real jump lines.
The extra
AUTOMATICentries derived fromlabel_gold/label_gem/label_nothingclaim those labels jump tochapter_two_scene_one, but none of the seeded label lines contain such jumps (only the main label's Line 5 does). This diverges from whatupdateIncomingJumpsForLabelswould actually compute, so the seeded display won't match a real sync. Acceptable if the intent is purely to exercise multi-source rendering, but consider a brief comment so future readers don't treat it as representative.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/backend/scripts/seed-technical-badges.ts` around lines 733 - 754, The seeded extra AUTOMATIC entries in the chapter_two_scene_one array (created from label_gold/label_gem/label_nothing) do not reflect real jump lines and will diverge from what updateIncomingJumpsForLabels computes; either remove these fabricated entries or add a clear inline comment next to the chapter_two_scene_one construction explaining they are artificial test-only multi-source rendering fixtures (and not representative of real incoming jumps), referencing the createdTargetLabels/map logic and the label names (label_gold, label_gem, label_nothing) so future readers know why they are present.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/backend/src/services/labels.service.ts`:
- Around line 2533-2540: The code collects menu option targets into targetNames
and then resolves them via labels.labelName, which causes UUID-like
targetLabelId values to fail resolution and be dropped; update the logic around
targetLabelId (used in the allLines loop and where incoming jumps are computed)
to preserve raw UUID targets: when a targetLabelId is present, if it is not
resolvable via labels.labelName (or matches a UUID pattern) treat it as a direct
label ID and add the raw targetLabelId to targetNames and to the incoming-jumps
mapping (incomingJumps/incomingMenuJumps) instead of attempting to look it up by
name; ensure subsequent comparisons handle both resolved label names and raw IDs
so incoming menu jumps referencing UUIDs are not dropped.
- Around line 991-993: The recompute step currently calls
updateIncomingJumpsForLabels(tx, affectedLabelIds, projectId) which restricts
incoming-jump recalculation to only affectedLabelIds; you must expand the scope
to include any labels that are jump targets referenced by the changed/synced
files (or all project labels if target discovery isn’t available). Modify the
code that builds affectedLabelIds and the call-site for
updateIncomingJumpsForLabels to compute a union: affectedLabelIds ∪
referencedTargetLabelIdsForFiles(projectId, changedFileIds), then pass that full
set into updateIncomingJumpsForLabels(tx, expandedLabelIds, projectId); also
update the places that filter writes to only affectedLabelIds (the write/filter
logic that checks membership) to use expandedLabelIds so incomingJumps for
cross-file targets are updated too.
In `@apps/frontend/src/components/write-mode/LabelPropertiesPanel.tsx`:
- Around line 116-126: The loop that builds the jumps array is including menu
options even when they don't actually jump; modify the logic in the block that
iterates line.menuOptions so you only push entries for options with a real jump
target (e.g., check opt.targetLabelId or another definitive target field before
creating the jump object). Update the code that pushes into jumps (the object
with targetLabelId, targetLabelName, jumpType, choiceText, conditionFlags,
effects) to be guarded by this truthy-target check so outgoingJumps no longer
counts non-jumping menu rows.
- Around line 523-525: The UI renders jump.choiceText directly but
IncomingJump.choiceText is nullable, causing empty labels; update the rendering
in LabelPropertiesPanel (where jump.choiceText is used) to provide a safe
fallback when null/empty (e.g., use a default string like "Untitled choice" or
localized fallback via i18n) so the row always shows a visible label; locate the
span that displays jump.choiceText and replace the direct value with a
nullish/empty check and the chosen fallback.
---
Nitpick comments:
In `@apps/backend/scripts/seed-technical-badges.ts`:
- Around line 733-754: The seeded extra AUTOMATIC entries in the
chapter_two_scene_one array (created from label_gold/label_gem/label_nothing) do
not reflect real jump lines and will diverge from what
updateIncomingJumpsForLabels computes; either remove these fabricated entries or
add a clear inline comment next to the chapter_two_scene_one construction
explaining they are artificial test-only multi-source rendering fixtures (and
not representative of real incoming jumps), referencing the
createdTargetLabels/map logic and the label names (label_gold, label_gem,
label_nothing) so future readers know why they are present.
In `@docs/superpowers/specs/2026-06-02-incoming-jumps-design.md`:
- Around line 62-98: Update the spec to match the shipped implementation:
replace references to the per-label function `updateIncomingJumpsForLabel(tx,
labelId, projectId)` with the actual batch function
`updateIncomingJumpsForLabels(context, labelIds, projectId)` (use the exact
symbol `updateIncomingJumpsForLabels`) and change the documented shared/DB field
`incoming_jumps` to the camelCase `incomingJumps` as implemented on
`PublicLabel`; optionally add an "as-built" note summarizing these two diffs so
readers aren't misled by the dated draft.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: cc056114-f4de-402f-9a55-79a465c2e0d6
📒 Files selected for processing (9)
apps/backend/scripts/seed-technical-badges.tsapps/backend/src/db/migrations/0042_right_fabian_cortez.sqlapps/backend/src/db/migrations/meta/0042_snapshot.jsonapps/backend/src/db/migrations/meta/_journal.jsonapps/backend/src/db/schema/tables/labels.tsapps/backend/src/services/labels.service.tsapps/frontend/src/components/write-mode/LabelPropertiesPanel.tsxdocs/superpowers/specs/2026-06-02-incoming-jumps-design.mdpackages/shared/src/index.ts
Summary by CodeRabbit
New Features
Documentation