Opt-in (config.engine='shipdeck' + SHIPDECK_BRIDGE_URL configured + template compatible): catalog installs go through the bridge's validated image-install pipeline (digest-pinned OCI image, systemd release, Caddy gate, DNS, verify) instead of Docker. Port semantics: engine is host-networked, so the app LISTEN port (container side of the mapping, protocol suffix stripped) is gated — never the Docker host port; no mapping falls back to defaultPort. Volumes: absolute binds only, :ro preserved, named volumes and placeholders skipped. Engine installs skip panel DNS + Caddy (pipeline did them), record an engine=shipdeck manifest with the Shipdeckfile path, and removal runs shipdeck rm via the registry. Failures return 502 with stage detail and never fall back to Docker. Bridge unset = Docker path unchanged. 10 new tests (gating, payload mapping, route integration); full suite 138/138 suites 2933/2933 green. Judge: C -> C -> B zero-blockers.
DashCaddy Onboarding System
This directory contains the JavaScript modules for the user onboarding tooltip system.
Files
- onboarding.js - Main entry point, initializes the onboarding system
- tour-manager.js - Orchestrates the onboarding flow and manages tour state
- progress-tracker.js - Manages persistent storage of user progress
- tooltip-definitions.js - Defines all tooltip content and positioning
- dns-template-selector.js - Presents DNS server template options
- theme-adapter.js - Ensures tooltips match the current dashboard theme
Load Order
The scripts are loaded in the following order (as defined in status/index.html):
- progress-tracker.js
- theme-adapter.js
- tooltip-definitions.js
- dns-template-selector.js
- tour-manager.js
- onboarding.js (main initialization)
Dependencies
- Driver.js - Loaded from CDN (https://cdn.jsdelivr.net/npm/driver.js@1.3.1/)
- Dashboard CSS variables (for theming)
- Browser localStorage API (for progress tracking)
Integration
The onboarding system integrates with:
- Dashboard theme system (via CSS variables)
- App template selector (for DNS server deployment)
- Local storage (for progress persistence)
Development
Each module is wrapped in an IIFE (Immediately Invoked Function Expression) to avoid global namespace pollution. Modules communicate through well-defined interfaces and the window object where necessary.