generated from coulomb/repo-seed
Add Claude Code support, credential routing polish, and CYA-WP-0006
Mirror sibling-repo Claude setup (CLAUDE.md + .claude/rules/*), align AGENTS.md with fleet credential-routing template, and close housekeeping gaps (WP-0002-T05 done, WP-0005 status note). Draft CYA-WP-0006 for Profile 1 production hardening as the proposed next slice.
This commit is contained in:
65
AGENTS.md
65
AGENTS.md
@@ -126,6 +126,8 @@ During work:
|
||||
- Treat command execution safety as product behavior: explain destructive or
|
||||
broad filesystem commands and require explicit confirmation before suggesting
|
||||
execution.
|
||||
- Before requesting API keys, SSH access, login tokens, or database passwords,
|
||||
run `warden route find` / `warden route show` per **Credential and access routing**.
|
||||
- Do not commit secrets, API keys, local transcripts, private notes, or hidden
|
||||
memory contents.
|
||||
- Preserve user-controlled memory as a design principle. Prefer explicit,
|
||||
@@ -207,7 +209,68 @@ Current primary entry point: `cya` (after editable install).
|
||||
Relevant workplans:
|
||||
- `workplans/CYA-WP-0002-memory-integration-roadmap.md`
|
||||
- `workplans/CYA-WP-0003-contextual-memory-activation-and-retrospection.md`
|
||||
- `workplans/CYA-WP-0004-dev-install-and-release-packaging.md` (current)
|
||||
- `workplans/CYA-WP-0004-dev-install-and-release-packaging.md`
|
||||
- `workplans/CYA-WP-0005-agentic-memory-profiles-and-phase-memory-feedback.md`
|
||||
- `workplans/CYA-WP-0006-profile-1-production-hardening.md` (proposed — next slice)
|
||||
|
||||
---
|
||||
|
||||
## Credential and access routing
|
||||
|
||||
> Fleet template mirrored in `.claude/rules/credential-routing.md` for Claude Code.
|
||||
> Re-sync both from `~/ops-warden/wiki/CredentialRouting.md` when the catalog changes.
|
||||
|
||||
**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)
|
||||
|
||||
```bash
|
||||
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=can-you-assist` is for coordination, not secret vending |
|
||||
| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **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
|
||||
|
||||
Prefer `warden route find` for repo-specific needs. Common routes:
|
||||
|
||||
| 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 |
|
||||
| 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`
|
||||
|
||||
---
|
||||
|
||||
## Workplan Convention
|
||||
|
||||
|
||||
Reference in New Issue
Block a user