f41c22d0ac
- CLAUDE.md: add "Question the question" and "One clarifying question" rules to Tone and Interaction — XY problem detection, false premise checks, and explicit reframe pattern before answering - Add claude/ detail-file directory (topic docs referenced from CLAUDE.md) - Add ABOUT.md, FUTURE.md - Update memory/, scripts/, settings.yaml with accumulated session changes Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
4.4 KiB
4.4 KiB
Future Ideas — claude-foundations
Backlog of improvement ideas not on the active roadmap.
Standing Deployment Authorization in CLAUDE.md
- Problem: Claude has all the tooling needed to run deployment steps (sops, ansible-playbook, kubectl, docker, git push) but must ask for confirmation every time because these are irreversible, shared-infrastructure operations. This makes multi-step milestone deployments slow and interactive.
- Idea: Add explicit standing authorization in CLAUDE.md for deployment operations — scoped to verified milestone changes (e.g., "Claude may run Ansible playbooks against VPS and bootstrap VM when deploying verified milestone changes"). Define the scope clearly so it doesn't become a blank cheque.
- Open questions: Should authorization be per-project or global? Should it require a passing verification script first? Should it be limited to specific Ansible tags or playbooks?
- Depends on: Pre-deployment checklist script (see below)
Pre-Deployment Checklist Script
- Problem: Before deploying infrastructure changes, there's no automated way to validate that the repo is in a clean, deployable state. Claude needs a safety gate to run before taking irreversible deployment actions.
- Idea: A
scripts/pre-deploy-check.shin cluster-bootstrap that validates: clean git status, all secrets SOPS-encrypted (no plaintext in tracked files), kustomize builds cleanly for all overlays, Ansible syntax checks pass, no placeholder values in inventory. Returns non-zero on any failure. - Open questions: Should it also check that the target services are healthy before deploying (kubectl health checks)? Should it produce a deployment plan summary (like terraform plan)?
- Depends on: Nothing — can be built anytime
Milestone Deployment Orchestration Script
- Problem: Deploying a milestone involves 6-8 manual steps in a specific order (SOPS encrypt, git push, Ansible playbooks, kubectl operations, container builds). Each step is straightforward but the sequencing is error-prone and tedious.
- Idea: A
scripts/deploy-milestone.shin cluster-bootstrap that sequences all deployment steps: pre-deploy checks → SOPS encrypt → git commit + push → Ansible playbooks (with --diff) → wait for ArgoCD sync → S3/kubectl operations → container builds → post-deploy verification. Support--dry-runmode that prints what it would do without executing. - Open questions: Should it be a single script or a Makefile with targets? Should it poll ArgoCD sync status or just wait a fixed time? How to handle partial failures (resume from last successful step)?
- Depends on: Pre-deployment checklist script, standing deployment authorization
Rollback Documentation Per Deployment Target
- Problem: When Claude takes deployment actions, it needs to understand how to revert each one if something goes wrong. Currently rollback procedures are tribal knowledge.
- Idea: Document rollback procedures for each deployment target in cluster-bootstrap (e.g., "VPS: re-run Ansible with previous commit", "ArgoCD: kubectl rollout undo or git revert + push", "S3: delete bucket via garage CLI"). Could live in
docs/rollback.mdor per-service README files. - Open questions: Should rollback be automated (rollback script) or just documented? Should the deploy script automatically create git tags as rollback points?
- Depends on: Nothing — can be written anytime
CacheAligner pattern for API-metered agent pipelines
- Problem: When dispatching many sub-agent API calls (e.g. agent-runtimes), dynamic content in system prompts (dates, session IDs, UUIDs) defeats Anthropic's prompt cache. Cached prefixes get a 90% token cost discount, but any prefix change invalidates the cache.
- Idea: Extract volatile values (timestamps, session tokens, request IDs) from system prompts and relocate them to message endings. Keep the system prompt prefix stable across calls so the provider KV cache hits consistently. This is a design pattern, not a dependency — inspired by Headroom's CacheAligner (chopratejas/headroom).
- Open questions: How much of our agent prompt content is actually stable vs dynamic? What's the realistic cache hit rate improvement? Does Anthropic's cache window (5 min TTL) align with our dispatch cadence?
- Depends on: agent-runtimes reaching API-metered multi-agent workloads (M5+)