Hermes
6c9f9e59a3
NEW powerdns.js adapter: PowerDNS Authoritative HTTP API (X-API-Key). Full parity (zones + native RRset enumeration — no AXFR needed): listZones/listRecords, additive create that merges with existing rrset contents and FAILS CLOSED when the rrset cannot be read (blind REPLACE would erase values), content-level delete with positive value-presence proof (absent rrset/value → not-found with ZERO writes; empty/null value rejected; only genuine whole-rrset intent issues DELETE), TTL preserved in REPLACE payloads and on additive creates, cross-zone qualification via the server-resolved zone id/name, case-insensitive rrset matching, dig-based resolve against the DNS listener (distinct from the API port), error guidance naming the exact pdns.conf prerequisite. WIZARD SERIALISATION EXTRACTED to shared js/dns-provider-config.js (browser global + module.exports): per-provider port defaults (PowerDNS 8081, RFC2136 53, legacy Technitium 5380), strict port validation (full-string digits, 1-65535), provider-specific aliases (server/apiPort/dnsPort/apiToken). The backend tests now execute the EXACT shipped wizard code, joined through the real createProviderDnsContext factory to adapter authentication (X-API-Key asserted). provider-dns.js dual-accepts generic wizard keys and provider-specific fields and normalises ports to integers (fixes the same latent gap for rfc2136). Also fixed: rfc2136 parity-matrix rows now exact-sorted-equality across all five adapters; wizard confirmation summary uses the provider default. Judge: 7 rounds — r1 C (silent-erase on failed read, cross-zone bug, missing resolve tests) → r2 C (deleteRecord positive-proof semantics) → r3 C (TTL in REPLACE, count honesty) → r4 C (empty-value fall-through) → r5 C (wizard ip/port/token vs builder field mismatch) → r6 C (5380 default defeating provider ports, untested serialisation) → r7 B zero blockers (urn:ump:ez33fpgyydl3nyjnwaaplisz7slunupcf5dnr42pdblwx7chfcma). Post-grade polish applied: strict port validation + range, summary uses provider defaults, joined serialisation→factory→adapter test, invalid port table tests. Suite: backend 176 suites / 3791 tests, frontend 68/68.
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.