[grade=B urn:ump:35dpnggtxsqrxvlqm2d2buqkbnggw3acflbccnkqpqyiiijcxx3q] fix(DC-170): MCP truth batch — 6 dead tools fixed, full-catalog drift gate

Audit P0-5 + deploy_app truth (batch 5 of the 2026-10-27 sweep, AUDIT-2026-10-27.md committed here):

ROUTE ADDITIONS:
- routes/containers.js GET / — container list (dockerode listContainers);
  the router had NO list route, so dashcaddy_list_containers 404'd always
- routes/dns.js GET /records — record list via active provider with a
  list-records capability guard (501 + guidance for push-only providers
  like RFC2136); dashcaddy_list_dns called GET /dns, never existed

HANDLER FIXES (src/mcp/mcp-core.js):
- get_service resolves from GET /services by id/name (single-service GET
  never existed) with a known-ids 404
- check_health + diagnose -> /health/service/:id and /health/services
  (both previously hit nonexistent routes)
- container_action remove -> DELETE /containers/:id (was /:id/remove)
- system_health/system_metrics via apiCall error envelope (metrics text
  capped at 64KB)
- search_catalog applies category filter client-side (/catalog/search
  has no category param — constraint was silently dropped)
- generate_caddyfile defaults authService=status when auth:true (auth
  flag alone silently produced UNGATED Caddyfiles)
- deploy_app honest re-contract: registers service + generates
  Caddyfile, does NOT claim image pull/container creation/deployed:true;
  base domain read from /config (hardcoded owner .sami TLD removed);
  caddy-code failure now surfaces as caddyfileError + FAILED message
- list_fleet description gains Premium hint

VERIFIER (audit #40): EXPECTED table 12 -> 34 rows covering EVERY tool's
(method,path); NEW Layer-3 handler-derived test drives the real
createToolHandler for all 28 tools and strictly resolves every captured
call mount-aware (a vacuous first draft of this gate was caught and
fixed pre-grade); extractRoutes regex extended to apiRouter.get inline
decls; Bearer credential-passthrough test added (DC-162 coverage gap)
NEW TESTS: dns-records.routes.test.js (5 route-level cases incl. 501
capability behavior); deploy_app partial-failure + no-.sami tests

HOST RELIABILITY (same sweep, evidenced here): jest maxWorkers 50% —
default 5-worker runs repeatedly OOM-killed this host's gateway
(dmesg 2026-10-29 00:58:40; swap was 4G/4G full). Gateway protected
separately via systemd OOMScoreAdjust=-500 drop-in + /swapfile2 (host
ops, graded B urn:ump:35dpnggtxsqrxvlqm2d2buqkbnggw3acflbccnkqpqyiiijcxx3q).
DC-171 DNS provider-parity ticket (Sami, plug-in-directly) appended to
backlog.

Full suite: 173/173 suites, 3740/3740 tests. Judge B r1
(urn:ump:jsobkg2t2omzvpinel2fufk7sspoy3vubsrth3e6lat3ygolvffq) blockers
all fixed: dns.js 501 arg order (the file aliases error() message-first
— the sweep's 'reversed-arg' finding was a false positive for its 7
sites; lesson #14), deploy_app partial-failure honesty, handler-derived
verifier.
This commit is contained in:
Hermes committed 2026-10-29 01:30:42 -07:00
1 parent 94ee76e9de
commit f4f2c26de3
9 files changed
+529 -40

No files matched your search

+21
View File
@@ -418,3 +418,24 @@
| P5 | 8 (DC-101–108) | ~29 hr | Product vision: self-hosting platform |
| P6 | 11 (DC-109–119) | ~49 hr | Shipdeck era: cross-platform & barrier removal |
| **Total** | **58** | **~159.5 hr** | |
---
## DC-171 (P1) — DNS provider plug-in parity (Sami, 2026-10-28)
> "DashCaddy should work with any DNS server that is offered with the software — whatever one you choose it should be able to plug in directly."
- **status:** pending
- **current matrix:** technitium + cloudflare = full (create/delete/resolve/list-records/credentials/zones); **rfc2136 = push-only protocol — create/delete/resolve/credentials, NO list-records/zones/logs** (RFC 2136 has no query operation); manual = instructions only.
- **problem:** provider choice silently degrades the product: `dashcaddy_list_dns` → 501 and the DNS records UI shows nothing for RFC2136/manual users, discovered at call time instead of choice time.
- **fix shape:**
1. Protocol-possible parity for cloudflare/technitium verified method-for-method against the capability list (tests).
2. Capability reporting at CHOICE time: DNS provider selector shows per-provider capability badges; setup wizard warns before selecting a provider that can't list records.
3. MCP `tools/list` annotates DNS tools with the active provider's capabilities; handlers return actionable messages ("RFC2136 is push-only — records can be created and resolved, not listed; verify with dashcaddy_dns_remove_record + dig") instead of bare 501s.
4. Product-decision atomic sync: this ticket + code + tests + changelog land together.
- **provider expansion (Sami 2026-10-28: "What about bind 9 and could we add others"):**
- **BIND 9 (near-parity TODAY):** the existing rfc2136 adapter already speaks BIND's native dynamic-update protocol (nsupdate) — with a TSIG key + `allow-update` in named.conf, create/delete/resolve work on a BIND server immediately. `list-records` upgrade: BIND serves AXFR zone transfers when `allow-transfer` is configured — implement listRecords via AXFR (dnspython or `dig AXFR`) and the rfc2136 adapter becomes a genuine "BIND 9 provider". Optional deeper: local zone-file provider (edit /etc/bind/zones + `rndc reload`) when DashCaddy shares a host with named.
- **Straightforward full-parity adds (REST APIs, one adapter class each on the 9-capability interface):** PowerDNS Authoritative (excellent REST API — highest value), deSEC.io (free public REST), AdGuard Home (REST, rewrite rules), Acme DNS (REST), DuckDNS (simple REST).
- **Fundamentally limited (honest-report-only):** dnsmasq (hosts-file, no API), Windows DNS Server (PowerShell/RPC — separate windows-desktop-apps lane), CoreDNS (no record API; usually behind etcd/zone files).
- **Registry mechanics:** every new adapter = one class in src/dns/dns-providers/ implementing the capability subset it can support + registration in registry.js; tools/list, wizard, and DNS UI read capability metadata from registry.getProviderMeta() — no per-provider UI work needed.
- **impact:** choosing any shipped DNS provider gives a working product, with honest limits where the protocol itself forbids more; new providers plug in by writing one adapter class.