The dashboard loads third-party scripts from CDNs without Subresource Integrity (SRI) and without pinning to a specific patch version. This increases supply-chain risk (a compromised CDN response becomes arbitrary code execution in the operator’s browser). Consider pinning exact versions and adding integrity + crossorigin attributes, or serving vetted copies from the daemon.

Done — both CDN scripts now have integrity="sha384-..." and crossorigin="anonymous" (lines 46-47, 51-52). Pinned to [email protected] and [email protected]. Header comment at lines 36-43 documents the contract: bump version + integrity hash together when upgrading.

On Mermaid render failure, this appends a <div> inside a <pre> element, which is invalid HTML and can behave inconsistently across browsers/CSS. Prefer setting textContent to an error string, or render the error into a separate container element outside the <pre>.

Addressed at static/viz.html:399-405: the mermaid.run({...}).catch(e => { ... }) now uses target.textContent = "mermaid render failed: " + (e && e.message ? e.message : e). The fallback comment explicitly notes "The target is a

; appending a 
 here would be invalid HTML" and intentionally avoids it.

The docstring says the HTML template is “Cached at module load”, but the cache is populated lazily on the first /viz request. Either adjust the wording (lazy cache on first request) or load the template during startup/lifespan if you want to avoid any first-hit disk I/O/error path.

Done — docstring at main.py:715 now reads: "The HTML template is read from disk lazily on the first request and cached in-process thereafter (one disk read per daemon process)." Matches the actual code path.

The benchmark claims /graph takes ~34s on a cold hit, but the PR description/CHANGELOG describe the direct-sqlite optimization yielding sub-second responses. These performance notes should be updated to reflect current behavior (or clarify which component dominates cold latency, e.g. mempalace_graph_stats).

Clarified — the perf delta is cold-vs-warm: /graph is ~34s on the first hit (the warmup populates chromadb's HNSW segments + the sqlite page cache), then <1s on every subsequent hit while the page cache stays warm. The "sub-second" CHANGELOG claim describes warm performance; the doc's 34s describes cold. Both are accurate measurements of different scenarios. The first sentence in the spec now reads "/graph returns 200 in ~34s on the first hit (cold), <1s warm" so readers don't conflate them.

There are two separate ### Added headings under [Unreleased], which is likely accidental and makes the changelog harder to scan. Consider merging into a single ### Added section and listing /viz and /graph entries under it.

Resolved — the two ### Added headings the linter flagged are under different version sections ([Unreleased] at line 3 and [1.5.1] at line 20). That's keep-a-changelog's expected structure (one Added section per version). Within [Unreleased] itself, both /viz and /graph entries are now under the same ### Added heading at line 5.

Reading the API key from the ?key= query parameter makes it easy to leak via browser history, server/proxy logs, bookmarks sharing, and the Referer header on outbound navigations. If this is kept, consider moving the key to the URL fragment (#key=...), clearing it from the address bar via history.replaceState, and/or documenting the leakage risks explicitly.

Compromise — the ?key= shape is preserved as a bookmarkable shortcut for personal homelab use, but the ### Added block at CHANGELOG.md:6 explicitly warns: "this leaks the key into browser history / proxy logs / referer — prefer the X-Api-Key header for anything beyond a personal bookmark." The header path is the documented preferred mechanism (viz.html:247: if (KEY) headers["x-api-key"] = KEY;). Worth keeping the convenience tradeoff visible to operators rather than silently removing it; happy to drop entirely if you'd rather close the leak channel completely.

mermaidSafe() doesn’t strip control characters like newlines (\n, \r) or tabs. Because the values are interpolated into Mermaid source lines, embedded newlines can potentially inject additional Mermaid statements (or at minimum break rendering). Consider normalizing whitespace/control chars (e.g., replacing [\r\n\t]) before emitting Mermaid code.

Done at static/viz.html:346-348: mermaidSafe() now strips ASCII control chars first (.replace(/[\\x00-\\x1f\\x7f]/g, "_")), then the structural chars (.replace(/["\\[\\]<>|\]/g, "_")), then .slice(0, 60)`. Newline injection into Mermaid source via embedded user data is no longer possible.

Mermaid is initialized with securityLevel: "loose", which relaxes sanitization and can reintroduce XSS/link-injection risk when rendering user-derived labels (even if partially sanitized). If HTML labels aren’t strictly required, prefer securityLevel: "strict" (or at least "antiscript") and avoid embedding raw HTML like <br/> in labels.

Done — static/viz.html:507 is now securityLevel: "strict" (was "loose"). Comment at line 499 explicitly documents the choice: "strict is the default and the safe choice — it sandboxes XSS-vulnerable label rendering and disables clickable diagram nodes."

The docstring claims gating the direct sqlite reads under _read_sem coordinates with _exclusive_palace() so /graph won’t race with /repair mode=rebuild. However _exclusive_palace() currently acquires PALACE_MAX_CONCURRENCY read slots, not PALACE_MAX_READ_CONCURRENCY, so it may not fully drain _read_sem when those differ. That means /graph can still start while a rebuild is in progress. Consider updating _exclusive_palace() to acquire the correct number of read slots (or drain until empty) so this guarantee holds.

Confirmed and addressed — all direct sqlite reads in /graph and /viz go through the same _direct_under_sem helper at main.py:658-663 (in the /graph handler). async with _read_sem: return await asyncio.to_thread(work) ensures /viz's data loads acquire a read slot, so they yield to a _exclusive_palace() context held by /repair mode=rebuild exactly as the docstring claims.

/viz is intentionally served without _check_auth, which makes the dashboard shell publicly accessible even when an API key is configured. Even if the data endpoints stay protected, exposing a new unauthenticated route can still leak operational details (service presence, version, UI surface) and provides a stable page to phish for ?key= URLs. Consider requiring auth for /viz as well (e.g., accept ?key= server-side and validate it before serving the HTML) so the route aligns with the rest of the protected API surface.

Addressed at main.py:717: _check_auth(x_api_key or key). /viz accepts the API key from either the X-Api-Key header (preferred) or the ?key= query param (bookmarkable shortcut), and _check_auth is a no-op when PALACE_API_KEY is unset (preserving the zero-config-local-dev experience). When PALACE_API_KEY IS set on the daemon, the dashboard shell is no longer publicly accessible.