docs(system-prompting): methodology corpus + leaks analysis + hermes register case study

[todie]

What

New docs/system-prompting/ directory (sibling to docs/eval, docs/specs) collating the estate's system- and user-prompt methodology.

• methodology synthesis — grounds the house agent-prompting-manual.md (unsigned-paas) in empirical structure and adds the user-prompt half the manual omits.
• leaks-corpus analysis — 7 findings from todie/system_prompts_leaks (438 prompts, 18 vendors). Analysed against current upstream because the todie fork is ~1yr stale.
• hermes ops-register case study — the methodology applied to the cerebral-agent (hermes) register, including a live-pod finding: no kubectl/helm/MCP wired, so the broad-RBAC ops mission is currently latent (charter/tool mismatch per manual Principle 7).

Scope

Reference docs only, no code. The register text itself is delivered out-of-band (OpenBao → Secret) per Principle 9 and is not reproduced here.

Related

Part of the hermes/cerebral-agent system-prompt work: fork cerebral-work/cerebral-agent (rebrand) + unsigned-paas chart wiring (SOUL.md via Secret). Follow-up filed: wire kubectl/helm + grafana-MCP or narrow hermes' stated mission.

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[todie]

Jury verdict: APPROVE (0.85) on code quality — but I am not merging, and the reason is not the code.

The diff is clean: 4 markdown files, 311 additions, 0 deletions, no code, no credentials, gitleaks green. Claims verify against the diff.

P2 — this is a public repo, and the case study publishes live infra posture. 2026-07-18-hermes-ops-register-casestudy.md documents: the hermes-agent namespace on Cygnus, that its ServiceAccount carries the broad D5 ClusterRole, that the only thing preventing that ClusterRole being exercised is kubectl/helm being absent from the image, that the K8s API is reachable via curl with the mounted SA token, and the OpenBao path secret/hermes-agent property soul-md.

No credential is leaked. But read together that is a targeting map for a known-broad-RBAC workload, including the specific reason it is currently un-exploited — which is a build-time accident, not a control. Publishing it is an outward-facing, irreversible act (it is public the moment it merges, and git history keeps it), so it is an operator call rather than a jury call.

Three smaller accuracy items, all P3:

• "18 vendors" claimed, 17 enumerated.
• Corpus size disagrees across files: methodology says "380+", analysis and README say 438.
• Dangling cross-reference: the leaks doc points at "the case-study doc's operator-gated list"; no such list exists in the case study.

Held for an operator decision on the P2. The P3s are worth fixing in the same pass either way.