harden MCPHub deployer credential boundary

platform/hermes/skills/mcphub-deployer/SKILL.md

@@ -17,15 +17,21 @@ Use these paths directly. Do not search the filesystem for alternatives.
 - Container: `MCPHub`
 - UI/base URL: `http://192.168.1.2:8787`
 - Operational source/build tree: `/mnt/nvme-storage/appdata/MCPHub/build/repo`
-- Dockerfile: `platform/mcphub/Dockerfile` below that tree
-- Single server and client registry: `config/mcp-registry.json`
-- Registry renderer: `platform/mcphub/configure-settings.py` (normally unchanged)
-- Unraid template: `config/unraid-templates/my-MCPHub.xml`
+- Dockerfile: `/mnt/nvme-storage/appdata/MCPHub/build/repo/platform/mcphub/Dockerfile`
+- Single server and client registry: `/mnt/nvme-storage/appdata/MCPHub/build/repo/config/mcp-registry.json`
+- Registry renderer: `/mnt/nvme-storage/appdata/MCPHub/build/repo/platform/mcphub/configure-settings.py` (normally unchanged)
+- Versioned Unraid-template source: `/mnt/nvme-storage/appdata/MCPHub/build/repo/config/unraid-templates/my-MCPHub.xml`
+- Live DockerMan template: `/boot/config/plugins/dockerMan/templates-user/my-MCPHub.xml`
 - Persistent state: `/mnt/nvme-storage/appdata/MCPHub`
 - Secrets: `/mnt/nvme-storage/appdata/MCPHub/secrets/<server>.env`, mode `0600`
 - Client bearer token: `/mnt/nvme-storage/appdata/MCPHub/client-token`
 - Individual route: `http://192.168.1.2:8787/mcp/<server>`
 
+The versioned template and the live DockerMan template are different files.
+Keep their image tag and required mounts aligned. If the versioned template is
+missing, copy the live template to that exact versioned path once; do not search
+for another template and do not infer a replacement from unrelated containers.
+
 The operational build tree is persistent and covered by the normal Unraid
 Appdata backup. The checkout below is legacy and MUST NOT be used or inspected
 for MCPHub work:
@@ -47,14 +53,35 @@ restart discovery after a phase has completed.
 Check only:
 
 1. `MCPHub` container state, image tag, mounts, and network.
-2. The four fixed production files listed above.
+2. The fixed Dockerfile, registry, renderer, and both template paths above.
 3. Existing MCPHub server names to avoid duplication.
 4. Target service reachability or the upstream release.
 5. Required secret-file presence; never print its values.
 6. Current Git availability, if any.
 
-Never run a filesystem-wide `find`. Never read unrelated Compose stacks,
-repositories, documentation trees, or all container logs.
+Never run `find` to rediscover a listed path. Never read unrelated Compose
+stacks, repositories, documentation trees, container logs, container
+environments, application configs, home directories, or secret stores.
+
+### Credential boundary — mandatory stop
+
+Credentials and account configuration are user-supplied inputs, not discovery
+targets. This rule overrides the desire to complete a deployment or live test.
+
+- Never inspect another container, service, environment, mount, config file,
+  mailbox, shell history, password manager, or secret directory to obtain or
+  infer credentials.
+- Never reuse credentials found in an existing mail server or another app
+  unless the user explicitly names that exact source and authorizes reuse.
+- Check only whether the dedicated fixed secret file for this server exists;
+  do not read its values during preflight.
+- If the MCP needs credentials or account settings and the dedicated file is
+  absent or incomplete, finish all credential-independent build work, install
+  the server disabled, and stop before live authentication. Ask the user for
+  the missing fields and state the exact secret-file path.
+- Do not substitute inspection of an existing service for that question.
+- A missing credential may reduce verification to build plus MCP handshake; it
+  is never permission to investigate the user's infrastructure.
 
 ### 2. Classify once
 
@@ -83,6 +110,11 @@ contradicts it.
 Ask only for information that cannot be derived safely: credentials, a
 material license decision, or an ambiguous destructive permission.
 
+For mail-related MCPs, repository inspection may determine which field names
+are required, but the IMAP/SMTP host, user, password/token, sender identity, and
+TLS choices must come from the user or the dedicated secret file. The presence
+of a Docker mail server does not answer those questions.
+
 ### 4. Implement the smallest change
 
 Modify only the necessary fixed production files. Rules:
@@ -96,7 +128,8 @@ Modify only the necessary fixed production files. Rules:
 - Preserve existing users, bearer keys, prompts, resources, enabled states,
   and per-tool toggles.
 - Build a new image tag. Never overwrite the tag currently running.
-- Update the Unraid template to the exact new tag.
+- Update both the versioned template source and the live DockerMan template to
+  the exact new tag. Do not rebuild `template.xml` inside an upstream image.
 
 For servers exposing many tools, install disabled first. After a successful
 local test, enable only the required tool groups in MCPHub. Do not publish an
@@ -111,6 +144,11 @@ Preserve all Appdata and mounts.
 Never restart Athena, Router, Qwen, Hermes, OpenWebUI, WireGuard, Unraid, or
 unrelated containers for an MCPHub deployment.
 
+Do not use unrestricted host shell access during repository analysis,
+classification, or credential preflight. Use it only after the exact file
+changes, new image tag, verification steps, and rollback tag are known. Its
+scope is then limited to those declared paths and the `MCPHub` container.
+
 ### 6. Prove the result
 
 Verify, in this order:
@@ -123,6 +161,9 @@ Verify, in this order:
 6. No test download, queue item, write, or second backend remains.
 7. If installed disabled, return it to disabled after the temporary test.
 
+If credentials are unavailable, steps 3 and 5 may be recorded as blocked.
+Never weaken the credential boundary merely to make the live probe pass.
+
 A running container alone is not success. Never claim install, test,
 registration, Git push, or backup without observing its result.