Mission planning: Add mission library

[ArturoManzoli]

• Added a 'Mission Library' to store, organize and reuse missions and mission segments;
• Save and restore missions from the library directly to the planning map;
• Resize, rotate, drag and join multiple missions on the map before saving or uploading them to the vehicle;
• Import and export missions as .cmp files to share them between users or installations;
• Each saved mission keeps its own thumbnail, vehicle type, cruise speed and mission estimates (length, ETA, energy, coverage);
• Insert a saved mission anywhere in the existing planning: at either endpoint or between any two waypoints via the segment radial menu;
• Plan, save and reload missions fully offline (no vehicle connection required);
• Select the type of vehicle that the mission is being designed for;
• Highlighted first and last waypoints of the current mission for clearer endpoint identification;
• Context-menu actions (add waypoint, simple path, survey, mission from library) now extend the mission from whichever egde waypoint is closer to the cursor;

Mission Library:

Screenshare.-.2026-04-29.11_56_26.AM.mp4

Bidirectional element addition:

Screenshare.-.2026-04-29.1_22_22.PM.mp4

[github-actions]

Automated PR Review (Claude)

0. Summary

Verdict: MINOR SUGGESTIONS

Minor items to address: 1.1, 1.2, 1.3, 2.1, 6.1, 6.2, 6.3

This PR adds a mission library feature to the mission planning view, allowing users to save, organize, reload, import/export, and reposition missions. It introduces a MissionLibraryModal component, a library.ts helper module, new types (SavedMission, MissionEstimatesSnapshot), store additions for persistence, context-menu and segment-radial-menu integration for inserting library missions, a free-placement UI (drag/scale/rotate), endpoint-aware insertion, and highlighted first/last waypoint markers. The Leaflet zoom behaviour is also tweaked across both the planning map and the main Map widget.

---

1. Correctness & Implementation Bugs

1.1 (minor) — MissionLibraryModal.vue template line ~108: The condition mission.estimates?.length && mission.estimates.length !== '—' is checking .length on the MissionEstimatesSnapshot object, which has a property called length (a string like "1.26 km"). This works at runtime, but it is confusing and fragile because it looks like an array .length check. The truthiness check (&& mission.estimates.length) would be false for the empty string "" but not for the dash "—", so the logic is technically correct, but the naming collision with Array.prototype.length makes the template misleading. Consider renaming the length property on MissionEstimatesSnapshot to something like totalLength or pathLength to avoid this ambiguity.

1.2 (minor) — MissionPlanningView.vue (diff line ~1569): When pendingSimplePathInsertIndex.value !== null, the anchor for the live-measure line is wps[0]. However, if the user clicks multiple times in simple-path mode with insertIndex = 0, each new waypoint is spliced at index 0. The anchor (wps[0]) then becomes the waypoint the user just placed (not the original first waypoint). This is likely the intended chained-extension behaviour, but if the array somehow becomes empty in an edge case (e.g. undo during simple-path mode), accessing wps[0] would be undefined, leading to a runtime error. A guard like if (!anchor) return null would be safer in currentMeasureAnchor.

1.3 (minor) — insertMissionIntoSegment: The bounds check segmentIndex >= planning.length - 1 prevents inserting after the last waypoint. This means the function cannot append after the final waypoint via segmentIndex = planning.length - 1. This seems intentional (append uses a different code path), but the combination of -1 as "insert at start" and the separate bounds logic may surprise future callers. A brief inline comment clarifying this constraint would help.

---

2. AGENTS.md Adherence

2.1 (minor) — Comment policy ("why" not "what"): Several added comments describe what the code does rather than why:

• // Waypoint connecting line (diff ~2599)
• // Survey polygons (diff ~2572)
• // Waypoint markers (start = green, end = red, middle = white) (diff ~2611)
• // Bounding polygon (rotates and scales with the mission)… (diff ~2627)

Per AGENTS.md: "No new comments unless explaining 'why', never 'what'."

2.2 (nit) — JSDoc: The new types and functions are thoroughly documented. No issues with empty @param/@returns entries. Good adherence here.

2.3 (nit) — Local-storage keys: New keys cockpit-planned-vehicle-type, cockpit-mission-library, and cockpit-mission-library-thumbnails all start with cockpit-. ✓

2.4 (nit) — Dependency usage: uuid and date-fns are already in package.json. No new dependencies added. ✓

---

3. Security

3.1 No obfuscated or intentionally unreadable code found.

3.2 The btoa() calls in generateMissionThumbnail produce base64-encoded SVG from locally constructed strings. The SVG content is derived entirely from numeric coordinate data — no user-supplied text is injected into SVG elements without sanitisation. However, the SVG is rendered via <img :src="..."> which naturally sandboxes script execution. Acceptable.

3.3 No hidden Unicode, zero-width characters, RTL overrides, or homoglyph attacks detected.

3.4 No unexpected network calls. The only external URL constructed is the Google Earth link (earth.google.com) which is rendered as a plain <a> tag with target="_blank" rel="noopener". Acceptable.

3.5 No changes to build scripts, CI workflows, Dockerfiles, or Electron main-process code.

3.6 No new use of eval, Function(), v-html, or equivalent. JSON.parse is used on user-imported .cmp files but the parsed result is validated through isSavedMission / instanceOfCockpitMission type guards before use. Acceptable.

3.7 No new dependencies added.

3.8 No other suspicious patterns detected.

---

4. Performance

4.1 (nit) — currentMissionSnapshot (computed) uses JSON.parse(JSON.stringify(...)) to deep-clone waypoints and surveys on every reactive access. This is passed as a prop to MissionLibraryModal which is conditionally rendered (v-if), so it only evaluates while the modal is open. Acceptable, but could become expensive if the planning has many waypoints and surveys. Worth noting for future optimisation if performance becomes an issue.

4.2 The placement preview rebuild is properly coalesced via requestAnimationFrame. The cancelAnimationFrame cleanup in cancelFreePlacement prevents orphaned frames. Good.

4.3 Map event listeners (mousemove, mouseup) for placement, scale, and rotation handles are correctly added on mousedown and removed on mouseup. No leak concerns.

---

5. UI / UX

5.1 (nit) — The mission library modal uses a fixed width: 860px; height: 650px with max-width: 90% but no max-height percentage. On shorter viewports (<700px height), the modal may overflow. Consider adding max-height: 90vh or similar.

5.2 (nit) — The placement toolbar inputs (<input type="number">) lack aria-label attributes. Screen readers would benefit from labels like "Width scale percent" and "Rotation degrees".

5.3 The endpoint markers use !important on background-color (.endpoint-marker). This is needed to override the base marker classes and is scoped, so it's acceptable.

---

6. Code Quality & Style

6.1 (minor) — MissionLibraryModal.vue line ~393: if (friendly[type]) return friendly[type] as string — this could use optional chaining + nullish coalescing to avoid the double lookup: return friendly[type] ?? .... Per AGENTS.md: "Use optional chaining (?.) when possible in typescript."

6.2 (minor) — MissionPlanningView.vue (diff lines ~2109-2125): There are many module-level const declarations for placement constants (PLACEMENT_SCALE_MIN_PERCENT, PLACEMENT_TOOLBAR_ANCHOR_LEFT, etc.) — 11 in total. While individually fine, grouping them into a single PlacementConfig object would reduce visual noise and improve discoverability. This is a suggestion, not a requirement.

6.3 (minor) — library.ts: isSavedMission type guard checks typeof value.id === 'string' and a few top-level keys, but doesn't validate waypoints array entries (e.g., each waypoint having id, coordinates, altitude). An adversarial .cmp file could pass the guard but crash later when the app tries to read wp.coordinates[0]. Consider at minimum checking value.waypoints.length === 0 || (typeof value.waypoints[0]?.id === 'string').

6.4 (nit) — Several let variables are used at module scope with null initialization for Leaflet event handler state (placementDragStartLatLng, scaleDragInitial, rotationDragInitial, placementRebuildRafHandle). These are correct but follow the existing codebase pattern (ignoreNextClick, etc.), so no action needed.

---

7. Tests

No tests are added or modified in this PR. The mission library logic (thumbnail generation, isSavedMission type guard, computeMissionLocation, cloneMissionForPlanning) would benefit from unit tests, especially the coordinate transformation functions. Not blocking since the existing codebase has minimal test coverage for mission planning, but worth flagging.

---

8. Documentation

8.1 (nit) — The Leaflet zoom behaviour change (wheelPxPerZoomLevel, zoomSnap, etc.) is applied to both the Map widget and the planning map. This changes existing user-facing zoom behaviour and could be considered changelog-worthy. No README update is needed since this works identically in Lite and Standalone.

8.2 In-code JSDoc is thorough across all new public functions, types, and interfaces. Good.

---

9. Nitpicks / Optional

9.1 (nit) — The MissionLibraryModal.vue file is placed in src/components/ rather than src/components/mission-planning/ where all other mission-planning components live. Consider moving it for consistency.

9.2 (nit) — vehicleTypeLabel in MissionLibraryModal.vue duplicates the vehicle-type-to-label mapping that also exists in plannedVehicleTypeItems in MissionPlanningView.vue. Consider extracting a shared constant or utility.

9.3 (nit) — The .hidden CSS class in MissionLibraryModal.vue (display: none) duplicates Tailwind's built-in hidden utility which is already used elsewhere in the template. Since the <input> already has class="hidden", the scoped CSS rule is redundant and could be removed (Tailwind's hidden class applies display: none).

9.4 (nit) — The loadDraftMission function in the base code is async (returns Promise<void>), but it's called from finalizeMissionPlacement without await. The promise rejection would be unhandled if tryFetchHome throws. Consider adding .catch(...) or await.

---

Generated by Claude. This is advisory; a human reviewer must still approve.