tegwick 897c62caef De-template agent instructions from the seed repo

The .claude/rules/ files still carried the seed placeholders. The
practical failure: session-protocol.md told agents to check the inbox
with to_agent="repo-seed", which returns [] regardless. Three unread
messages from gate-house and risk-nexus sat unread for days behind that
wrong query until fix-consistency's C-28 surfaced them. Replaced
repo-seed with tenant-engine throughout, and REPO-WP- with this repo's
actual TEN-WP- prefix.

Also records that no MCP server is registered (dev-hub was deregistered
2026-09-04), so the REST paths are the default rather than the fallback,
and fixes the root CLAUDE.md heading, still "Repo Seed".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HHwvAEQfmzLHtrFGhXtVjq

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 823014@bnt-lap001
Assistant-Session: 2a0786b1-efea-4c38-959b-6e86a493f259

2026-09-07 00:22:38 +02:00

2.5 KiB

Raw Blame History

Credential and access routing

Audience: Codex, Claude Code, Grok, and custodian agents that call llm-connect for inference. Run this check before requesting secrets, API keys, SSH access, login tokens, or database passwords — in any repo, not only ops-warden.

ops-warden issues SSH certificates only (warden sign, cert_command). Every other credential need belongs to another subsystem. Do not message ops-warden on State Hub expecting a secret value; the reply is a pointer, not a key.

Lookup (do this first)

warden route find "<describe your need>" --json
warden route show <catalog-id> --json

Requires the warden CLI from ~/ops-warden (uv tool install . or uv run warden).

Agent runtime	How to orient
Codex / Grok (shell, HTTP State Hub)	`warden route` commands above; inbox `to_agent=tenant-engine` is for coordination, not secret vending
Claude Code (MCP when available)	`get_domain_summary("custodian")` for workplans; still use `warden route` for credential ownership
llm-connect (inference service)	Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route`

Quick routing table

I need…	Owner	ops-warden executes?
SSH cert (`adm`/`agt`/`atm`)	ops-warden	Yes — `warden sign`
API key, DB password, provider token	OpenBao (`railiance-platform`)	No — route only
Login / OIDC / MFA	key-cape / Keycloak	No — route only
Authorization decision	flex-auth	No — route only
activity-core → issue-core emission	activity-core + issue-core	No — `warden route show activity-core-issue-sink`
SSH tunnel	ops-bridge (+ `cert_command` from warden)	No — route only

Anti-patterns (do not do these)

POST /messages/ to ops-warden asking for ISSUE_CORE_API_KEY, OPENROUTER_API_KEY, etc.
Inventing warden secret, warden login, warden bao, warden tunnel — they do not exist
Pasting secrets into Git, State Hub, workplans, logs, or chat

Other capabilities (reuse-surface)

Non-credential capabilities are usually discovered through reuse-surface federation (reuse-surface registry / capability.* indexes). Credential routing is inlined in every repo's agent instructions because it is high-frequency, high-risk, and easy to get wrong.

Canon: ~/ops-warden/wiki/CredentialRouting.md · catalog ~/ops-warden/registry/routing/catalog.yaml

2.5 KiB Raw Blame History