- serviceGenerations no longer leaks entries: removeService deletes the live
entry and records a TTL'd (10min) tombstone swept by cleanupHistory
- monotonic instance-wide generationSeq prevents generation reuse across
remove->re-add cycles (ABA) and supersedes tombstones on re-configure
- _isStaleCapture(): presence-aware stale check — live entry must match
exactly; no entry is stale only under a higher-generation tombstone
(preserves correct behavior for disk-loaded never-configured services)
- catch path increments consecutiveFailures only after the stale check, so
a late-rejected probe cannot resurrect state for a removed service
- open incidents for a removed service close via the standard resolve path
(resolvedBy=service-removed, WS/SSE incident-resolved broadcast)
- 6 regression tests; full suite 2608/2608 green
Judge: GLM-5.3 cold read (Codex stand-in), verdict B/ship, zero blockers
Two mirrored health-handler test suites (health-endpoints, health-probe-aliases)
probed the Caddy admin API with raw Origin-less native fetch. On the prod host
the adversarial cron runs the full jest suite every 30 min against a live Caddy
admin with enforce_origin: 12 journal 403 lines per run (~700/day of
'client is not allowed to access from origin' spam) while tests stayed green.
- Mirrors now call fetchT (byte-identical to src/app.js:930 probe) with fetchT
jest.spyOn-mocked at buildApp scope; caddyOk-configurable in both suites
- New guard test in utils-http-caddy-admin-origin.test.js: any __tests__ file
pairing a raw await-fetch with a Caddy-admin token (:2019|adminUrl|
CADDY_ADMIN) fails the suite — file-level pairing catches the historical
cross-line drift shape a call-window regex missed
- DC-087-ALLOW-RAW-FETCH comment escape hatch (raw-text marker, guard file
never self-exempts, skips logged to jest output)
Judge: GLM-5.3 cold read via delegate_task deleg_4d384dea (round 1 C -> round 2
B, zero blockers, polish folded). Verdict URN: urn:ump:azrv2xp72koiwi5r4yb6ureu4aqqloqq64sgmftsajh6ci2mzj2q
Mutation probes: historical drift reintroduction -> guard red; hatch marker ->
skipped+logged; restore -> 33/33. Full suite 2603/2603.
Round-2 folds the judge-round fixes into DC-086:
- serviceGenerations map: checkService captures the config generation at
entry and re-validates it before ANY state write (success + error
paths). In-flight probes that resolve after removeService/updateService
are discarded — deleted services can no longer resurrect status entries,
fire incidents, or poke consecutiveFailures from beyond the grave.
- removeService now purges ALL per-service state: displayedStatus,
consecutiveSinceChange, consecutiveFailures, pending backoff timers,
and the serviceTimers entry (leaked a live setTimeout before).
- readPositiveIntEnv(): HEALTH_DOWN_THRESHOLD / HEALTH_UP_THRESHOLD
parsing hardened — empty, non-numeric, fractional, zero, and negative
values all fall back to defaults instead of Math.max(1, NaN)=NaN.
- previousStatus is captured BEFORE recordStatus() writes the new probe,
so checkForIncidents() compares against the true prior state instead
of the just-overwritten one (latent incident-suppression bug).
- Same-status hysteresis path returns the raw consistent snapshot
(not the stale displayed one) so timestamps stay current without
mixing contradictory fields.
- Tests: +14 (86 total across the two suites). New coverage: streak
reset on agreement, malformed env fallbacks (each.of not-a-number/0/
-2/1.5), in-flight probe after removeService does not resurrect state,
getCurrentStatus serves internally-consistent displayed snapshot while
raw currentStatus keeps the suppressed failure. Full suite 2601/2601.
Judge: GLM-5.3 cold-read via delegate_task (deleg_c9fd5900 task-0),
grade A round 1, zero blocking issues. Verdict URN:
urn:ump:quhs33ph2hhmsxjti63eg3ro4aiy34r6nws7z66ofk3bg3rcb3ca
(Codex primary quota-walled until 2026-08-29; GLM-4.6 direct 401;
stand-in chain per codex-as-judge SKILL.md, Sami 2026-08-17.)
Dashboard badges perpetually flip green/red for a few seconds at a time,
never stable. Root cause: health-checker emitted 'status-check' on every
probe (every 30s) and dashboard-ws forwarded every one as 'status-change'
to the browser with no diff; live-events.js then unconditionally called
setBadge(). A single transient 5xx (Caddy reload, container restart, TLS
handshake blip) flipped the badge and the next green probe flipped back.
Fix: _computeDisplayedStatus applies asymmetric hysteresis — DOWN_THRESHOLD
(default 2, env-tunable HEALTH_DOWN_THRESHOLD) consecutive probes that
disagree with the displayed 'up' state flip to red; UP_THRESHOLD (default
1, HEALTH_UP_THRESHOLD) flips back to green. History and consecutiveFailures
still record every raw probe so postmortem analysis is unchanged. Only the
SSE broadcast is filtered. getCurrentStatus now returns the displayed
status so a page reload shows the same badge as the live stream.
10 new tests cover first-emit, same-status-dedup, the actual flicker bug
(one-down-then-up keeps green), two-down flips red, one-up recovers fast,
long-steady-green produces exactly one emit, and env-var tuning. All 63
existing health-checker tests still pass. Full suite: 2484/2484.
Flip POST /api/v1/auth/admin/invites default to no email; always return
the link. Operators copy + share via iMessage/WhatsApp/SMS/Signal/Telegram/
Discord/paste-in-email. Email becomes an opt-in checkbox (was the default).
Add shareText field with pre-formatted message for one-tap paste. Stop
logging raw invite URLs to error.log when SMTP is unconfigured (was just
a dev fallback — link is now in the response). Frontend flips the
checkbox default to unchecked and renders shareText + native share sheet
button (navigator.share) alongside the raw copy-link button. 9 new tests
covering default-no-send, link-always-returned, shareText-shape, opt-in
SMTP send, failed-SMTP-no-leak. Full suite: 2474/2474 + 9 new = 2483.
Dashboard badges perpetually flip green/red for a few seconds at a time,
never stable. Root cause: health-checker emitted 'status-check' on every
probe (every 30s) and dashboard-ws forwarded every one as 'status-change'
to the browser with no diff; live-events.js then unconditionally called
setBadge(). A single transient 5xx (Caddy reload, container restart, TLS
handshake blip) flipped the badge and the next green probe flipped back.
Fix: _computeDisplayedStatus applies asymmetric hysteresis — DOWN_THRESHOLD
(default 2, env-tunable HEALTH_DOWN_THRESHOLD) consecutive probes that
disagree with the displayed 'up' state flip to red; UP_THRESHOLD (default
1, HEALTH_UP_THRESHOLD) flips back to green. History and consecutiveFailures
still record every raw probe so postmortem analysis is unchanged. Only the
SSE broadcast is filtered. getCurrentStatus now returns the displayed
status so a page reload shows the same badge as the live stream.
10 new tests cover first-emit, same-status-dedup, the actual flicker bug
(one-down-then-up keeps green), two-down flips red, one-up recovers fast,
long-steady-green produces exactly one emit, and env-var tuning. All 63
existing health-checker tests still pass. Full suite: 2484/2484.
Flip POST /api/v1/auth/admin/invites default to no email; always return
the link. Operators copy + share via iMessage/WhatsApp/SMS/Signal/Telegram/
Discord/paste-in-email. Email becomes an opt-in checkbox (was the default).
Add shareText field with pre-formatted message for one-tap paste. Stop
logging raw invite URLs to error.log when SMTP is unconfigured (was just
a dev fallback — link is now in the response). Frontend flips the
checkbox default to unchecked and renders shareText + native share sheet
button (navigator.share) alongside the raw copy-link button. 9 new tests
covering default-no-send, link-always-returned, shareText-shape, opt-in
SMTP send, failed-SMTP-no-leak. Full suite: 2474/2474 + 9 new = 2483.
The /etc/caddy/sites/arch.sami file had an active Caddy health check
(health_uri /api/stats health_interval 10s) probing the permanently
unreachable Arch Linux server (100.120.159.34:5000) every 10 seconds,
generating 6 syslog spam lines per minute with no dashboard value.
src/monitoring/caddy-upstream-watcher.js ALREADY provides equivalent
monitoring at 60s cadence with 5-min dead-confirmation, mute support,
incident creation, and dedup. The source comments explicitly call out
this exact spam as 'the noisy spam the dashboard currently sees for
100.120.159.34:5000'.
Live-verified on DNS2:
- caddy-apply validated + reloaded + committed
- Caddy admin API confirms health_uri/health_interval removed
- journal: 0 health_checker.active lines in last 5min (was ~30)
- container dashcaddy-api healthy (no restart needed)
- live HTTP all 200: status.sami, dashcaddy.net, ca.sami
- watcher correctly tracks 100.120.159.34:5000 as dead (1905+ failures)
Backup .bak-DC-084-pre deleted because Caddy's 'import sites/*' was
picking it up and causing 'ambiguous site definition' validation error.
GLM judge deleg_a87bc740 verdict: A — all live-verification claims
independently confirmed, fix is correct + minimal, no source code
changed, no container restart, no public-facing behavior change.
Co-Authored-By: Hermes <hermes@nousagent.com>
Public share endpoints accept untrusted fields. Pre-fix code used bare
type checks (email.includes('@'), typeof deviceId === 'string') so the
two CSRF-exempt public endpoints accepted:
- bare '@' / 'a@' / '<script>@x.c'
- 10MB email strings (data/shares.json bloat)
- CR/LF/NUL in email (corrupts on-disk JSON + log lines)
- CR/LF/NUL in deviceId (flows into Tailscale auth-key description)
Hardening (5 files, +661 net):
1. routes/share.js + src/security/share-store.js: shared validators
- validatePublicEmail(raw): charset (a-z0-9._%+-@), 254-char cap,
reject \x00-\x1f\x7f, block shell-metachars
- validatePublicDeviceId(raw): charset (a-z0-9._:-), 1-128 length,
reject \x00-\x1f\x7f
- Single source of truth: validators live in share-store.js, exported,
imported by routes/share.js (drift-eliminated)
2. Routes that were 'email.includes(@)' now use validator. Empty/omitted
email still allowed (backwards-compatible per recordPublicSubscribe
signature).
3. recordTailscaleUse defaults omitted/null deviceId to 'unknown'
(backwards-compatible — pre-fix code rejected bare omitted; new code
matches the store's defensive default).
4. constants.js: RATE_LIMITS.SHARE_PUBLIC = {windowMs: 15min, max: 30}
Mounted on the 3 CSRF-exempt endpoints (/preview, /subscribe,
/redeem-tailscale). 30/15min/IP — tighter than the 1000/15min
general limiter (which is too generous for unauth state-mutating
endpoints). Falls back to no-op in test envs.
5. recordPublicSubscribe records the (validated, normalized) email in
subscribers[] capped at last 8 entries (was unbounded → store
bloat via repeated subscribe).
Test coverage (38 new tests in __tests__/share-dc083.routes.test.js + 3
in __tests__/share-routes.test.js):
- Bare '@', missing TLD, single-char TLD → reject
- CRLF, NUL, oversized >254 → reject
- Non-string type-coerced (number, boolean, object, array) → reject
- XSS-shape payloads → reject
- valid user+tag@sub.domain.io + nodekey:... → accept (pins contract)
- sharePublicLimiter is mounted on /preview (route-stack smoke)
- store-layer defense-in-depth: store rejects what route doesn't catch
- sanitized usedBy flows into shares.json
- rejection does NOT mark share used
- subscriber array bounded at 8 entries
Test results:
- 68/68 share-related tests pass (30 share-routes + 38 share-dc083)
- Full repo: 2427/2427 tests pass
- npx eslint: 0 errors, 22 warnings (baseline HEAD =14; +8 in test mocks)
Judge verdict: GLM-5.3 round-2 grade A. Round 1 was B with 7 polish
suggestions (DRY validators, hoist require, warn-on-missing-dep, new
tests for legit inputs + limiter mount) — all folded into same commit
per multi-round-fix-first protocol. Zero blocking issues.
Threat model: the 2 POST endpoints mutate shares.json + Tailscale auth
descriptions. Pre-fix was effectively 'input trust boundary = NONE'.
Post-fix: every byte that crosses the boundary is charset/length/control-
char-validated at BOTH the route layer (suspenders) and the store layer
(belt).
Pre-fix: dashcaddy-dashcaddy-api:latest was normalized to library/dashcaddy-dashcaddy-api
before probing Docker Hub. The actual upstream namespace for a docker-compose
prefixed image is <project>/<service> (slash, not hyphen). Docker Hub returned 401
on the wrong repo, and the error log emitted
Docker Hub registry returned HTTP 401 after auth
on every restart of every container.
Fix:
1. _composeProjectToRepo splits dashcaddy-dashcaddy-api on the FIRST hyphen to
recover dashcaddy/dashcaddy-api. Returns null for non-compose-prefixed names
(official images like nginx/alpine, library/foo, namespace/foo already-slashed).
2. _isNotPublishedError detects the 401-after-auth pattern for compose-prefixed
names only. Steady-state for locally-built images that aren't published.
3. getLatestImageDigest routes compose-prefixed names to the corrected namespace.
Routes already-namespaced names directly. Falls back to library/ for the
Official Image path.
4. Catch block: if the 401 is compose-prefixed-not-published, log info instead
of error. Real auth failures on legitimate images still log as error.
17/17 tests pass in 1.27s. Full suite 2425/2425 (4 pre-existing
billing/pdfkit failures unrelated to this change).
GLM stand-in verdict URN: urn:ump:7rhk7keukv3zrx654gbckxaycnuwm4agduf37creqbsoauszopoa
Pre-fix, the dispose endpoint + storage info block in dashcaddy-api/routes/log-insights.js
HARDCODED /opt/dashcaddy/dashcaddy-api/data/audit-log.json and
/opt/dashcaddy/dashcaddy-api/data/security-events.jsonl, which DO NOT EXIST in the
production container (verified 2026-08-19 01:42Z: /app/data/audit-log.json = 318 KB,
/app/data/security-events.jsonl = 15 MB, /opt/... = ENOENT). The dispose endpoint
silently no-op'd (read empty arrays, wrote empty arrays back); the storage block in
GET was always empty.
Also: parseInt(req.body.keepDays) || 30 accepted negative numbers. keepDays = -1000
produces a cutoff +3 years in the future, then the filter e.timestamp < cutoff
deletes 100% of the audit log. Operators must not be able to wipe forensic context
with a typo.
Fix:
* _resolvePaths() uses process.env.AUDIT_LOG_FILE || path.join(platformPaths.dataDir, 'audit-log.json'),
matching the canonical resolution in src/security/audit-logger.js and src/security/event-store.js.
Both GET + POST share the resolved paths (single source of truth).
* _validateKeepDays() rejects undefined/null/NaN/Infinity/-Infinity/strings-of-floats/
non-integers/out-of-range input with a clear error BEFORE any file IO.
Allowed: integer in [1, 3650] (1 day .. 10 years).
* POST /log-insights/dispose now requires { keepDays: integer 1..3650, confirm: true }.
Preview is read-only. Confirm branch audits-the-wipe BEFORE the actual delete
(matches the audit-logs/DELETE + error-logs/DELETE pattern).
* Atomic write for audit-log.json (tmp + rename) — a crash mid-write cannot leave
the file half-empty (state-manager reads it on every container start).
Tests (23 new, dashcaddy-api/__tests__/routes/log-insights.routes.test.js):
* _validateKeepDays: 6 tests (rejects undefined/NaN/Infinity/floats/negative/0/3651; accepts 1..3650; coerces numeric strings).
* _resolvePaths: 3 tests (default-fallback + env-override + canonical-match-against-audit-logger+event-store).
* POST /log-insights/dispose: 14 tests via real Express stack (rejects -1000/0/Infinity/30.5/>3650; preview/confirm round-trip;
confirm=false treated as preview; preview-includes-resolved-paths; missing-file-handled; corrupt-parse 500;
wrong-shape 500; -1000-core-regression — sentinel file survives).
GLM-5.3 round 1: A.
DC-080 round-1 GLM-5.3 judge verdict: B. Round-2 polish folded into same
commit per multi-round fix-first protocol: tighten tag regex to require
non-empty name after 'tag:' (matches Tailscale spec), drop dead
`module.exports.createApp = null` line.
THREAT MODEL
Pre-fix, /api/v1/tailscale/* and /api/v1/tailscale/admin/* (TOTP-gated)
had inconsistent checks on caller-supplied input. Three coupled gaps:
(a) PUT /settings validated `apiToken.startsWith('tskey-api-')` but
had NO length cap — body-parser limit was the only ceiling. A 1 MB
string starting with `tskey-api-` would be `.trim()`-ed, sent to
Tailscale's /devices endpoint, and waste server-side CPU on a
request that will always 401.
(b) POST /settings/test accepted `apiToken` from the body with NO
validation at all. The PUT route's prefix check did NOT extend to
this path. An operator could submit arbitrary junk and the
container would still call /devices on the Tailscale API with it
(DoS-reflection + fingerprint timing for an attacker probing
whether this API token format is accepted).
(c) POST /admin/keys validated `tags` as Array but NOT per-element
type — `tags: ['tag:guest', null, 123, {injection: true}]` would
be forwarded to Tailscale verbatim. Tailscale's API is JSON-strict
and would 400 the request, but the bad shape reached the wire.
Similarly `description` had no length cap (Tailscale caps at 120
chars per their docs).
All three are gated by TOTP — this is a logged-in-operator / phished-
session threat surface, not anonymous-unauth. The fix is defense-in-
depth: a bug in the auth path (TOTP bypass, session theft, future route
handler trust-boundary drift) should not turn these endpoints into a
`submit anything and forward to Tailscale` relay.
FIX 1 — Shared validators (round-1)
- `_validateApiToken(token)`: typeof string check, prefix required,
length cap 256 chars. Catches empty/null/non-string AND oversize.
- `_validateTags(tags)`: undefined/null allowed (optional field),
Array.isArray check, max 32 entries, per-element string check,
per-element length cap 64 chars, regex
`/^tag:[a-z0-9][a-z0-9_-]{0,62}$/` (round-2: requires non-empty
name after `tag:` per Tailscale spec).
- `_validateDescription(description)`: undefined/null allowed, string
type check, length cap 120 chars (matches Tailscale's documented cap).
All three return null on success or an error string on failure. Route
layer maps to 400 via `errorResponse`. Validators exported via
`module.exports._validators` for direct unit testing (otherwise
unreachable from outside the factory closure).
FIX 2 — Endpoint wiring (round-1)
- PUT /settings: replaced inline `!startsWith('tskey-api-')` check with
`_validateApiToken(token)`. Single source of truth for the rule.
- POST /settings/test: added `_validateApiToken(token)` guard BEFORE
calling `client.setApiToken(token)`. The body is optional, so the
guard is skipped when no token is provided (uses stored token path).
- POST /admin/keys: replaced `Array.isArray(opts.tags)` shallow check
with `_validateTags(opts.tags)`, plus `_validateDescription(opts.description)`.
Old code already validated `expirySeconds`; that stays.
FIX 3 — Round-2 polish
- TAG_KEY_RE: `/^[a-z0-9][a-z0-9:_-]{0,63}$/` → `/^tag:[a-z0-9][a-z0-9_-]{0,62}$/`.
The old regex accepted `tag:` (empty name), which Tailscale's API
rejects. New regex requires `tag:` prefix and ≥1 alphanumeric name
char followed by [a-z0-9_-]{0,62} — total length up to 67 chars, well
within Tailscale's documented 15..63 char tag length.
- Removed `module.exports.createApp = null` vestigial line — the file
only exports the factory function and the _validators bag.
TESTS (29 original + 16 new = 45 in this suite)
- 4 PUT /settings new: length cap, non-string type, prefix round-trip
(existing 'starts with' tests already passed), plus the original
6 (4 pre-existing PUT tests stay green).
- 4 POST /settings/test new: prefix rejection, length cap, stored-token
path with empty body still works.
- 4 POST /admin/keys new: null/123/object entries rejected, uppercase /
whitespace / CRLF rejected, description length cap, canonical
lowercase `tag:server` accepted.
- 4 direct validator unit tests: validateApiToken (5 cases incl. cap-edge),
validateTags (8 cases incl. round-2 bare-'tag:' rejection), validateDescription
(3 cases incl. cap-edge), constants-export surface.
All 45 tests pass on DNS2 (verified). Full repo suite unchanged: 2351/2351.
DC-079 2-round GLM-5.3 judge verdict: round1=C (blocking path-traversal
in assets/themes) → round2=A. 20/20 tests in routes/discover-disaster
(8 original + 12 new). Full repo: 2351/2351 (4 pre-existing billing
pdfkit failures unchanged).
THREAT MODEL
POST /api/v1/disaster/restore was the ONLY endpoint in the route tree
that wrote directly to process.env.CADDYFILE_PATH (=/caddyfile in
container = /etc/caddy/Caddyfile on host via start.sh:161 bind-mount).
Pre-fix: an authenticated dashboard operator POSTed
{caddyfile: '<attacker-controlled-string>'}
and the handler called fsp.writeFile(caddyfilePath, snapshot.caddyfile),
overwriting the live Caddyfile immediately. Caddy reads this file on
every reload (ACME renewal, health probe, admin API touch), so the
attacker-controlled content executes as Caddy config directives:
- import /etc/caddy/<anything-caddy-can-read> (content theft)
- admin off (lock out admin API)
- reverse_proxy to attacker IPs (Caddy becomes a pivot)
- acme_ca override to attacker CA (rogue cert issuance)
- log to attacker-writable paths (DoS/escape)
This bypassed the CLAUDE.md hard rule 'Caddyfile edits must use
caddy-apply' (validates + reloads + git-commits atomically).
FIX 1 — Caddyfile staging (round-1)
- New validateCaddyfileContent(): type check, non-empty check,
512 KiB byte cap (defense-in-depth below the 1 MB body-parser limit),
FORBIDDEN_IMPORT_RE rejects directives with absolute paths,
../-escape, ~/, or URL-encoded payloads.
- POST /disaster/restore now writes to <dataDir>/disaster-staged/
Caddyfile.candidate (atomic write + rename), NEVER to caddyfilePath.
- Response includes caddyfileStaged[{file, stagedPath, action: 'awaiting
caddy-apply', livePath}] and a DC-079 warning instructing the operator
to run `caddy-apply <reason>` to validate + reload + git-commit.
FIX 2 — assets/themes path-traversal (round-2 BLOCKING)
GLM round-1 caught a parallel vector: snapshot.assets[name] and
snapshot.themes[name] are user-controlled JSON keys flowing into
path.join(assetsDir, name) and path.join(themesDir, name). An attacker
could POST {assets: {'../../etc/caddy/Caddyfile': '<base64-evil>'}}
and overwrite the live Caddyfile via the dataDir bind-mount, fully
bypassing Fix 1.
- ASSET_KEY_RE = /^[a-zA-Z0-9._-]+$/ + ASSET_PATH_TRAVERSAL_RE catch
slashes, leading '..', and absolute-path keys.
- THEME_NAME_RE = /^[a-zA-Z0-9._-]+\.json\$/ additionally forces
.json extension and no slashes.
- assertSafeAssetKey/assertSafeThemeName helpers throw on invalid input.
- Both restore loops now: assert → path.resolve(dir, name) → containment
check (resolved must start with path.resolve(dir) + path.sep) → write
to resolved (never the raw join).
TESTS
12 new tests in __tests__/routes/discover-disaster.routes.test.js:
- staging: live sentinel unchanged, candidate at expected path
- rejects: non-string, empty, oversize, 3 forbidden-import variants
- assets: path-traversal key, absolute-path key
- themes: path-traversal name, no-extension name
- back-compat: no caddyfile field succeeds without staging
The per-hour checkForUpdates() loop called Docker Hub / ghcr.io without
family:4, without a hard request timeout, and without retry on transient
network errors. On DNS2 (Technitium at 100.121.150.22 returns AAAA records
even when IPv6 routing to public registries is intermittently broken), every
container check surfaced AggregateError [ETIMEDOUT] in error.log with stack
`at internalConnectMultiple (node:net:1114:18)`. The dual-stack DNS race
consumed the default 30s connect timeout per unreachable IPv6 family before
falling back to IPv4 — 30s+ per container per check cycle.
Three reliability properties added via shared fetchWithReliability() helper:
1. family:4 — IPv4-only DNS lookup. Avoids the dual-stack race entirely.
2. Hard per-request timeout (10s) — caps total latency per attempt.
3. Retry on transient codes only (ETIMEDOUT/ENOTFOUND/ENETUNREACH/...) — HTTP
4xx/5xx are surfaced as real responses, not retried.
The 401 → WWW-Authenticate → token → Bearer auth flow is now explicit in
getDockerHubDigest (was previously a side effect of authenticateAndGetDigest,
which has been removed — no remaining callers).
Verified end-to-end against real Docker Hub:
- linuxserver/plex:latest → real digest in 1349ms (was 30s+ AggregateError)
- 5-container checkForUpdates() cycle: 3.6s total (was 150s+)
- 86/86 update-manager tests pass; 2343/2343 full suite (4 pre-existing
pdfkit module-resolution failures unrelated to this change)
Pre-fix, every dashcaddy-api container startup logged:
[nesting-guard] Skipped: The "path" argument must be of type string. Received undefined
because src/utilities/nesting-guard.js does require('../config/paths') and
calls paths.dataDir — but src/config/paths.js imported platformPaths and
only re-exported its specific files (SERVICES_FILE, CONFIG_FILE, etc);
dataDir was never re-exported, so paths.dataDir was undefined.
Result: path.join(undefined, 'data') threw TypeError, the outer try/catch
swallowed it, and the entire nesting-guard became a silent no-op. The
cleanup that prevents recursive data/data/data/... directory duplicates
never ran on any startup. Bug class is 'silent functional no-op' (same
family as DC-056 AggregateError visibility).
(1) src/config/paths.js (+11): re-export dataDir as
SERVICES_DIR-derived (with platformPaths.dataDir fallback). dataDir is
the dirname of SERVICES_FILE in container (env override wins), which
equals /app/data — same value platform-paths.dataDir computes for the
default config. Either path is fine; SERVICES_DIR is preferred because it
respects env-override.
(2) src/utilities/nesting-guard.js (+13/-2): defensive fallback to
require('../../platform-paths').dataDir if paths.dataDir is missing
(any future export-shape drift or older caller). Explicit skip-warn
instead of silent catch when both paths fail.
(3) __tests__/nesting-guard.test.js (NEW, 112 lines, 4/4 passing):
isolates module cache per test, exercises (a) cleanup when nested
data/data exists, (b) no-op when clean, (c) dataDir export contract,
(d) dataDir === dirname(SERVICES_FILE) under env override. No jest.doMock
leaks across tests (verified via 4-call probe sequence).
Verified: 4/4 tests passing. Full repo suite: 100/104 suites / 2335/2335
tests passing (4 pre-existing failures in __tests__/billing/* are
unrelated module-resolution issues in src/billing/invoice.js, confirmed
unaffected by this change via stash+rerun).
GLM-5.3 round 1: B (ship, one polish nit — trailing newline on test
file, folded in same commit per multi-round-fix-first protocol).
Deploy plan: container rebuild + atomic swap via /opt/dashcaddy/start.sh
on DNS2; live-verify status.sami=200, dashcaddy-api=Up+healthy, and
absence of [nesting-guard] Skipped log line in container logs.
Pre-fix, an authenticated dashboard operator could call:
POST /api/v1/site {domain:"evil.example.com", upstream:"10.0.0.1:80"}
POST /api/v1/site/external {subdomain:"x", externalUrl:"http://192.168.1.5"}
and end up with a Caddy site block that proxies PUBLIC traffic at
evil.example.com to an INTERNAL host. Caddy runs on DNS2 (same
network as the targets), so the SSRF lands.
The pre-fix /site upstream regex /^[a-z0-9.-]+:\d{1,5}$/i only
checked charset — it happily accepted 192.168.1.1:80 and
169.254.169.254:80 (AWS metadata IP). /site/external called
validateURL() without blockPrivate:true, leaving the door wide open.
(1) New helper validateUpstream() in fleet-validation.js — reuses
resolveAndCheckAddress() (DC-068 SSRF work) to reject literal
private IPv4/IPv6 (loopback / RFC1918 / link-local / CGNAT /
multicast / broadcast / 0.0.0.0 / TEST-NET / benchmark ranges),
resolve hostnames and reject private answers (rebinding defense),
and cap port to 1..65535. Opt-in via SITES_ALLOW_PRIVATE_UPSTREAMS=true.
(2) /site calls validateUpstream() BEFORE caddy.modify() — gate
happens before any state mutation. Throws ValidationError with
canonical [DC-074] tag and a redacted hostname audit log entry.
(3) /site/external calls validateURL() (syntax only) + validateUpstream()
(private-IP gate). validateURL's blockPrivate is intentionally
NOT passed because it has no opt-in — that's what validateUpstream
is for.
(4) Tests (__tests__/routes/sites-dc074.routes.test.js, NEW, 60/60
passing): helper unit tests (format, literal IPv4/IPv6 private
reject, public IP accept, hostname resolve + rebinding defense,
env opt-in override), POST /site integration (10 regression
payloads + public accept + opt-in + port range + charset), POST
/site/external integration (8 regression payloads + public
accept + DNS rebinding defense + opt-in), canonical SSRF regression
proof (RFC 1918 literal IPv4 in upstream + RFC 1918 literal IPv4
in URL host), unchanged-behavior checks on isPrivateOrReservedIPv4/IPv6.
Full repo suite: 2402/2402 tests in 102 suites (zero regressions).
GLM-5.3 stand-in judge round 1 (deleg_384b9f53, 41.46s, 3 tool
calls, MiniMax-M3 per Sami authorization 2026-08-17): A ship-first.
Refs: codex-as-judge SKILL.md 'Stand-in fallback chain'. Verdict
record: /root/dashcaddy-polish/.ump-verdicts/2026-08-18T22-35-00Z-dc-074-round-1-A.json
Bug class: silent state corruption via path-style endpoint inconsistency.
Pre-fix, only POST /caddy/upstreams/mute (bare body-style) rejected unknown
hosts with a 400. The path-style POST /caddy/upstreams/:host/mute and
POST /caddy/upstreams/:host/unmute endpoints skipped that check entirely.
An authenticated operator could POST /caddy/upstreams/phantom.test:12345/mute
and caddyUpstreamWatcher.setMuted() would silently add the phantom host
to its muted Set and _saveState() would persist it to disk. The phantom
entry survives container restarts and pollutes the snapshot view.
Fix: consolidate validation in a single validateAndMuteHost() helper used
by all three mute endpoints. The helper enforces (1) host format charset,
(2) length cap, (3) membership in caddyUpstreamWatcher.upstreams (the
live registry populated by scanSites()). No phantom host can reach setMuted.
Tests: 15 new regression tests in
__tests__/routes/caddy-upstreams-dc073.routes.test.js — exercises the
helper directly (unit) and via each endpoint (integration), asserts
rejection happens BEFORE setMuted is called (no state corruption), and
the existing 3 caddy-upstreams.routes.test.js cases still pass. Router
introspection test asserts no duplicate route registrations.
Full suite: 2342/2342 tests / 101 suites.
Pre-fix, dashcaddy-api/routes/exec.js (the ws://host/ws/exec/:containerId
WebSocket container terminal endpoint) captured auth.scope at lines 39/46
but never enforced it — any API key or JWT, regardless of scope, got a
full PTY-backed shell inside the running container. A key issued with
scope ['read'] (a legitimate monitoring/observability scope) could
escalate to a root-equivalent shell. Container exec is full root inside
the container's user namespace, so this was a privilege-escalation across
the auth trust boundary.
Fix:
1. assertExecScope(auth) requires scope.includes('admin'); throws a
tagged 403 error (DC-072_INSUFFICIENT_SCOPE) on rejection with
requiredScope + actualScope in the envelope.
2. Called BEFORE wss.handleUpgrade so the WS gate cannot be bypassed.
3. 403 over the upgrade socket is JSON (code, requiredScope, actualScope)
so the dashboard can show operator-actionable messages.
4. isValidContainerId(id) tightened to Docker's actual charset
(12 or 64 lowercase hex). Pre-fix regex accepted _, -, ., mixed
case, and any length up to 128; Docker would 404 the inspect and the
rejection surfaced as a generic 500.
5. Audit-log pair: session start (container name + auth id) and session
end with durationMs + reason ('exec-stream-end' vs 'ws-close'
for abnormal disconnects); idempotent via ended-flag guard.
6. Both helpers exported via __test for unit tests (no live WS).
Tests: 20 new tests in __tests__/routes/exec.routes.test.js cover:
- assertExecScope: admin passes; read/write/empty/undefined/null/non-array
rejected with the canonical 403 envelope.
- isValidContainerId: 12/64 lowercase hex accepted; uppercase / mixed /
non-hex / _.- / wrong length / null / non-string / padded / CRLF
payload rejected.
Full suite: 2327/2327 tests passing across 100 suites (zero regressions).
GLM-5.3 round 1: A with 2 LOW polish (scope-coercion defensive comment +
abnormal-close audit-log fallback). Both folded into the same commit.
Round 2: A. Ship.
Two coupled bugs that, together, cause the live 'admin.api received request
from ::1 → 403 client is not allowed to access from origin' noise on DNS2:
(1) Caddyfile 'origins' allowlist (admin 0.0.0.0:2019 block on DNS2) had
4 IPv4 entries (localhost/127.0.0.1/172.17.0.1/0.0.0.0) but no IPv6
entry. Per glibc RFC 3484 + /etc/hosts '::1 localhost', Node's
dns.lookup('localhost') returns ::1 FIRST on Linux, so an on-host
Node caller using http://localhost:2019 routes over IPv6 loopback
and produces Origin=http://[::1]:2019 — which Caddy's exact-string
match against the IPv4 entries rejects as 403. Live verified:
37 such requests in 30 minutes on DNS2 (User-Agent:node,
Sec-Fetch-Mode:cors).
(2) _httpFetch (src/utils/http.js) was broken for IPv6 literal URLs:
on Node 22, new URL('http://[::1]:2019/x').hostname === '[::1]'
(brackets preserved), but http.request({hostname}) needs the
BRACKETLESS form for actual TCP connect. Passing '[::1]' triggers
'getaddrinfo ENOTFOUND [::1]' BEFORE any Origin matching. So even
after fixing (1), a caller using the IPv6 URL form over _httpFetch
couldn't connect.
Fixes:
(1) _httpFetch computes transportHostname by stripping leading [ and
trailing ] when parsed.hostname is bracket-wrapped. transports via
bracketless form. defaultOrigin keeps bracket form so Caddy's
allowlist exact-matches. Docblock adds 'IMPORTANT — IPv6 path'
paragraph explaining the dual-form distinction.
(2) dashcaddy-installer/templates/Caddyfile.template: comment block
above admin localhost:2019 now warns operators adopting a
non-loopback bind to include http://[::1]:2019 AND
http://ip6-localhost:2019 in the origins allowlist. Comment-only
edit; template has no origins directive since loopback bind
doesn't trigger enforce_origin.
Tests (NEW utils-http-caddy-admin-ipv6-origin.test.js, 4 cases):
- template comment mentions IPv6 ([::1]/ip6-localhost/IPv6 substring)
- stripComments helper preserves template literals with // inside
(eslint no-control-regex forces non-regex split)
- end-to-end: real http server on [::1]:20191, fetchT succeeds 200,
Origin header is exactly 'http://[::1]:20191'
- end-to-end bug repro: same setup with IPv4-only allowlist returns
403 (proves the mock allowlist check actually runs)
DC-051's utils-http-caddy-admin-origin.test.js (5 cases) unchanged and
still green — the helper change is backwards-compatible for IPv4 hosts
(parsed.hostname.startsWith('[') is false for 127.0.0.1/localhost/
172.17.0.1).
Full suite: 2281/2281 (98 suites, +4 net new). ESLint clean on touched
files.
GLM-5.3 judge round 1 (35s, 3 tool calls): GRADE=A. 1 LOW polish
folded (template comment wording — 'IPv4 loopback only' → 'loopback
interface' so a reader doesn't get the wrong mental model if they
later switch to admin [::1]:2019 explicitly). No blocking issues.
bug: POST /api/v1/fleet/hosts (DC-108) accepted any string as the
hostname field and the followup GET /fleet/status flow composed it
verbatim into a probe URL. An authenticated dashboard operator could
register 127.0.0.1 or 169.254.169.254 (AWS/GCP/Azure metadata) and
have the container reach that internal endpoint on their behalf. DNS
rebinding was also wide open: register with public A record, flip to
loopback, probe pulls loopback.
fix: 4 layers of defense
1. New fleet-validation.js — validateFleetHost() rejects 14 IPv4 reserved
ranges (loopback / link-local incl IMDS / RFC 1918 / CGNAT incl
Tailscale / multicast / broadcast / documentation), 6 IPv6 reserved
ranges, garbage syntax (URL prefix, @ injection, control chars),
port bounds (incl SSH-22 collision), tag bounds; plus async
resolveAndCheckAddress() that resolves DNS names and rejects
private-resolved IPs.
2. routes/fleet.js — POST validates synchronously via validateFleetHost,
then resolves + checks via resolveAndCheckAddress. Resolved IP +
dnsFamily are stored alongside the hostname so subsequent probes /
URLs build from resolvedIp, never re-resolving the name (DNS
rebinding closed).
3. GET /fleet/status re-validates every stored host before probing
(defense-in-depth against hand-edited fleet-hosts.json) and
categorizes hosts as validation_failed vs probe-able. Probe
concurrency capped at MAX_PROBE_CONCURRENCY=5 so a malicious fleet
with N hung hosts cannot stall the dashboard with N parallel
timeouts.
4. POST /fleet/deploy returns deployUrl built from resolvedIp with
IPv6 bracket-wrapping (legacy hosts without dnsFamily still get
correct bracket wrapping via on-the-fly net.isIP check).
opt-in: FLEET_ALLOW_PRIVATE_HOSTS=true env flag enables Tailscale /
RFC 1918 deployments where private hosts are intentional.
tests: 141 new tests (109 unit on validateFleetHost + 23 routes-layer
on the SSRF guards + 9 pre-existing DC-108 tests updated to use public
IPs instead of 192.168.x / 10.x). 2277 / 2277 pass on DNS2.
manual verification: GLM-5.3 judge round 1 = A (4 tool calls, 49s,
ship). IPv4-mapped IPv6 edge case ::ffff:127.0.0.1 caught correctly
via net.isIP + delegated IPv4 check.
Background (DC-062, 2026-08-18, c01a011): errorResponse has TWO bindings in
src/utils/responses.js:
- canonical: errorResponse(res, statusCode, message, extras) + DC-062 validator
- alias: error(res, message, statusCode = 500) -- NO validator
DC-062 already fixed routes/caddy-upstreams.js and added a defensive
TypeError-throwing validator on the canonical path.
DC-063 (this commit): the same bug class lurks in 2 more route files that
import the alias 'error: errorResponse' but call it with the canonical
shape '(res, NUM, STRING)'. The alias function does NOT run the validator,
so at runtime the alias path silently fires
res.status('event not found') -> TypeError -> 500 HTML panic
silently masking the intended 4xx JSON response for the client.
Affected files:
- routes/security.js: 15 callsites (lines 110-251)
Pre-fix every GET /events/:id (404), POST /events (400/409), PUT
/events/batch (400/413), POST/PATCH/DELETE /hosts (400/404/409) all
returned 500 HTML with a RangeError stack instead of the intended JSON.
Fix: switched import to canonical so the existing canonical-shape
callsites bind to the validator-armed function. 0 callsite changes.
- routes/services.js: 7 callsites total
3 already in canonical shape (POST /services credentials,
lines 222/246/261) -- switched import fixes them.
4 alias-shape callsites (lines 406/432/455/486) -- rewritten to
canonical shape per responses.js:76.
Test sweep:
- NEW __tests__/routes/errorresponse-arg-order.regression.test.js (284
lines, 75 tests): pins
(1) the validator (defense-in-depth) — 14 tests
(2) the routes/ + src/utilities/ convention — 49 one-per-file
static-tree walk that classifies each file's import style
(alias vs canonical) and asserts each callsite matches the
file's own convention.
(3) live-HTTP smoke — security.js /events/:id + /hosts/:id return
404 JSON, never 500 HTML.
Also serves as the spec defining the alias-vs-canonical convention
for any future contributor.
- UPDATED __tests__/routes/services.routes.test.js: fixture mock for
src/utils/responses now exposes both errorResponse (canonical) and
error (alias) so the route's canonical-shape import resolves.
29/29 tests still pass.
Verification: full suite 93/93 / 2114/2114 green; security.js + services.js
both fully canonical; 13 canonical-import files (DC-062 + DC-063) + 10
alias-import files (using message-first shape correctly) — proven
consistent by the static sweep.
GLM-5.3 stand-in judge round 1: GRADE=A (verified cold diff + convention
check + 4-tool-call budget); 2 LOW polish suggestions logged for a
follow-up DC: (a) require.cache injection in the live HTTP smoke
should migrate to jest.mock(virtual:true) so a module rename fails
loudly; (b) static sweep should assert a min-callsite floor per
convention class.
Routes/caddy-upstreams.js had 4 callsites with argument-order swapped: errorResponse(res, 'message', 503) instead of errorResponse(res, 503, 'message'). The canonical signature from src/utils/responses.js:66 takes statusCode FIRST; the swapped call passed a STRING where Express expected a status code. res.status('Caddy upstream watcher not initialized') throws RangeError [ERR_HTTP_INVALID_STATUS_CODE], Express's error middleware catches it, and the response is 500 with an HTML stack trace instead of the intended 503 JSON. Four `!caddyUpstreamWatcher` defensive guards had this exact pattern; all fixed.
Defense-in-depth (responses.js): errorResponse() now validates that statusCode is an integer in 100..599 and that message is a string BEFORE calling res.status(). Future arg-order mistakes fail fast with a clear TypeError naming the wrong arg and the message — instead of writing a 500 HTML panic to the wire. Legacy error(res, message, statusCode) helper (used by ~7 files that import as 'error: errorResponse' alias) is intentionally untouched.
Tests (__tests__/utils-responses-dc-062.test.js, NEW, 21 tests pass):
- correct (res, 503, msg) order: 503 JSON
- swapped (res, msg, statusCode) order: TypeError (was: silent 500 HTML panic)
- 10 invalid-statusCode cases: NaN, Infinity, '503', null, undefined, underflow, overflow, float, object, array — all rejected
- non-string message rejected
- DC-086 extras.code propagation preserved
- legacy error() helper regression: still works
- pre-fix Express server proves the bug class (500 HTML when statusCode is a string)
- all 4 caddy-upstreams routes with null watcher now return 503 JSON
- static source scan: 0 swapped patterns, 4 canonical (statusCode, 'message') occurrences
Full suite: 92 suites / 2039 tests / all green pre and post fix.
[glm-grade=A] from deleg_45e44614 (3 tool calls, 82s, MiniMax-M3 stand-in per Sami's 2026-08-17 authorization)
Pre-fix WIP changed module.exports to a named object {createDashboardWS,
parseCookieHeader}. server.js still uses (default-import style) so require() returned an object and
the call site failed at boot with TypeError: createDashboardWS is not a
function. Container crashed on every start.sh until fixed.
Both import shapes must work:
const createDashboardWS = require('...'); // default
const { createDashboardWS } = require('...'); // named
const { createCookieHeader } = require('...');
module.exports = createDashboardWS keeps the default callable shape;
the appended properties carry the named exports for the test file.
Discovered by live-verify after deploy — TypeError visible in
docker logs dashcaddy-api --since 60s. GLM-5.3 judge missed the import
site check (only grep'd source, not server.js require line) — graded A
but missed this contract regression. Round-2 fix shipped same tick.
Pre-fix: /api/v1/ws checked cookies.includes('dashcaddy_session') — substring
match, bypassable with Cookie: dashcaddy_session=garbage. Production also
accepted any 11+ char ?token= query string. Both let any attacker subscribe
to all real-time event streams (status-change, incident, cert-expiring,
auto-restart, dependency-restart, update-available, drift-detected, etc).
Fix (3 files, +404/-81):
(1) server.js:80-99 wires ctx.session.isValid (HMAC-verifying isSessionValid
from middleware.js:265-279) into deps.authVerifier so production goes
through the same signed-cookie verifier as the REST routes.
(2) dashboard-ws.js:
- New parseCookieHeader helper (exported for test coverage)
- authVerifier injection: deps.authVerifier default is a presence-only
fallback for unusual boot paths; production wires the HMAC verifier.
- Upgrade handler replaces substring check with authVerifier(request).
401 includes Connection: close so browsers don't retry. Logs WS upgrade
rejections at WARN with ip + path.
- Removes ?token= query param bypass entirely (any random 11+ char token
previously granted production access).
- 16 KB message size cap defense-in-depth in the message handler.
(3) close() now detaches ONLY the listeners dashboard-ws attached via the
new attachListener() helper. The previous code called
resourceMonitor.removeAllListeners() (and same for healthChecker /
updateManager / sslMonitor / dnsPropagationChecker), which silently killed
the SSE route's listeners on the same shared emitters every time close()
ran (hot reload, graceful restart). The new test proves the SSE listener
survives dashboard-ws.close() and the resourceMonitor still emits to it.
Tests (+273/-33, 24/24 pass, full suite 2018/2018, +16 net):
- 6 auth gate probes: no cookie, empty session cookie, unrelated cookie,
?token= bypass rejected, token+empty-cookie combo rejected, valid
cookie grants 101
- 2 listener-isolation: close() detaches only OUR listeners; close() is
idempotent
- 8 parseCookieHeader unit tests (undefined, empty, single, multi,
whitespace, HMAC-shaped value preservation, malformed pair, empty name)
- Existing DC-076 tests updated to send Cookie header
Refs: codex-as-judge SKILL.md threat model — WS endpoint bypassed the
Express middleware chain, so the global totpAuthMiddleware never ran
on the upgrade request. Auth must be re-asserted at the upgrade handler.
DiskSpaceMonitor._getBudgetStatus() returns the FIRST threshold the
budget usage crosses, in the order
cleanupAggressivePct → criticalThresholdPct → warningThresholdPct.
If a caller writes the three thresholds out of order
(e.g. warningThresholdPct=95, criticalThresholdPct=60), the higher-
priority branches become unreachable and the monitor silently
misclassifies budget state — 'warning' would never fire even though the
user set it as a threshold they care about.
(1) Fix (dashcaddy-api/routes/disk-space.js, +81/-3): new
mergeAndCheckOrdering() helper validates the *effective* (current baseline
+ incoming update) config against the invariant
warningThresholdPct < criticalThresholdPct < cleanupAggressivePct
BEFORE the route mutates diskSpaceMonitor.diskConfig. Threshold bounds
preserved from the original inline Math.min/Math.max chains (warning
50..99, critical 60..99, aggressive 70..99). On violation throws
ValidationError (DC-400) with a precise message naming which pair broke
and the values involved. Partial updates work one field at a time
without violating the invariant against the current baseline.
(2) Tests (dashcaddy-api/__tests__/routes/disk-space.routes.test.js,
NEW, +266 lines, 13/13 passing): happy path strict ascending; both
invariant-pair violations; equal-threshold rejection (strict <, not
<=); partial update success+rejection against baseline; partial-update
chain across two requests (success → second-success → second-reject);
out-of-bounds clamping; non-numeric drop; diskBudgetGB+autoCleanup
co-existence; rejected request does NOT mutate live diskConfig (proves
the no-mutation contract); POST /config with no thresholds is a no-op.
(3) Verified: targeted suite 13/13 green; full suite 91/91 suites
1999/1999 tests green (up from 90/1986 on main at 6f18b3c); ESLint
2 pre-existing require-await warnings on the unchanged GET handlers
(lines 100, 105) — no new warnings introduced by DC-059.
GLM-5.3 judge (deleg_3196de36, 6 tool calls, 185s): B with fix-first
on alleged '2 logging.test.js failures'. On-disk verification refutes
the fix-first: full suite 1999/1999 green, logging.test.js 18/18 green
in isolation. The judge's snapshot was taken during a transient
worktree-conflict state on DNS2 (stale 5 conflict markers introduced by
a prior checkout experiment). Treating the grade as B per protocol,
shipping (no genuine fix-first outstanding). Re-grade with Codex when
quota resets 2026-08-24.
Background: every time dashcaddy-api restarts, the first POST from a
dashboard browser tab hits the missing-CSRF-cookie branch. The
status/js/globals.js secureFetch() wrapper catches the 403 and
auto-retries with a fresh token, so the WARN line is misleading noise.
Live evidence (DNS2, 2026-08-18 10:35:32Z container restart):
[CSRF] Missing CSRF cookie: POST /api/v1/backups/schedule from 100.121.150.22
[CSRF] Missing CSRF cookie: POST /api/v1/backups/schedule from 100.121.150.22
[CSRF] Missing CSRF cookie: POST /api/v1/backups/schedule from 172.17.0.1
Fix: if X-CSRF-Token header is ALSO present, tag the log line [CSRF-debug]
(operator can grep it out as expected noise — the secureFetch retry will
self-heal). A request with NEITHER cookie NOR header (curl probe, exploit
scanner, broken client) keeps the [CSRF] tag.
Threat model: forging a header without the cookie just produces a
different 403 (Invalid CSRF token) — the timingSafeEqual check on lines
248-260 of csrf-protection.js is unchanged. This is a log-only fix.
Tests: 4 new in __tests__/csrf-protection.test.js under
'DC-058: browser-auto-retry vs real-probe log tagging'. Full suite
1982/1982 green on DNS2 worktree.
GLM-5.3 judge (60s, 2 tool calls, sha 084672c parent 2f76b83):
GRADE=A — log tag branched only on headerToken presence with identical
403 body, headerToken read for tag-detection only (still validated via
timingSafeEqual at lines 248-260), 33 csrf tests + 33 regression tests
all pass. SHIP.
Hermes