Hermes
c9015b59ad
Judge r1 (grade D) blockers, each fixed and tested:
1. TRANSPORT: custom POST-only JSON-RPC → MCP 2025-03-10 Streamable HTTP
(spec-canonical; replaced HTTP+SSE). POST answers application/json for
requests; valid notifications -> 202 empty; malformed notifications ->
no reply (204); batching removed in this revision -> arrays rejected
-32600. GET (server->client stream) and DELETE (session termination)
answer 405 + Allow: POST — the spec's explicit allowance for stateless
request/response servers; documented in /info + modal + OpenAPI.
Origin header validated when present (DNS-rebinding MUST); Accept
negotiation (json required, else 406); MCP-Protocol-Version header
checked when sent. Clients needing server-initiated streams use the
stdio bridge (unchanged, shares mcp-core).
2. CREDENTIAL TYPE PRESERVATION: routes/mcp.js now forwards the SAME
scheme the caller authenticated with (req.auth.type from
middleware.js:549-586): apikey -> x-api-key, jwt -> Authorization
Bearer (NOT dk_-coerced-x-api-key as r1 did). mcp-core createToolHandler
accepts explicit headers. Tests assert BOTH shapes downstream
(apikey carries x-api-key & no Authorization; jwt carries Bearer & no
x-api-key; zero downstream calls for session denial).
3. JSON-RPC VALIDATION: validateJsonRpc — jsonrpc:'2.0', non-empty string
method, params object-or-omitted, id string|number|null. Invalid
Request -32600 (empty body, empty array, batch); tools/call without
string params.name -> -32602; unknown method -> -32601; error envelopes
carry id null when unpairable. Transport primitives rejected by the
app-wide strict JSON parser (400; asserted).
4. REPRODUCIBILITY: status/dist/features.js + sw.js regenerated and
committed IN THE PATCH (repo convention: DC-130/131 committed bundle
rebuilds). Verifier greps the built bundle for aiconn- (23),
mcp/connections (1), httpConfig (2) so a clean `git am` checkout serves
the real frontend.
Judge r1 polish, all applied:
- verifier accepts 0_PATCH.diff / PATCH.diff naming (indexed artifact);
- connections list filtered server-side to "AI connection (...)" keys
(new GET /mcp/connections, session-only; modal switched to it);
- URL-encoded tool path params (serviceId, containerId, action,
templateId, category, zone) in mcp-core.
Config shape: POST /mcp/config (session-only; apikey 403) returns the
standard Streamable-HTTP card {url, transport: streamable-http, headers:
{x-api-key}, mcpProtocolVersion} + per-client note (ChatGPT note states
the public-https requirement honestly; no fabricated connector claims).
Tests: 57 green (34 route incl. auth matrix/type-preservation/transport
rules/JSON-RPC errors + 23 core). Composition-root e2e (8) boots the real
createApp with the mount. eslint 0 errors. Full suite: only the
pre-existing pdf-parse billing family red (unchanged since base 470dfaa).
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.