Files

Paul O'Reilly b6c976a00b chore: end-session — log, gac token correction in CLAUDE.md, FUTURE offload targets

Claude-Session: https://claude.ai/code/session_01Ku87DDWwbJkTx6SuV3sQDc

2026-09-11 13:56:44 +12:00

Future Ideas — claude-foundations

Backlog of improvement ideas not on the active roadmap.

Extend /explore-minimax to more modes and parallel sweeps

Problem: MiniMax-backed exploration (2026-09-11) is only wired into deep, deep-fable, and orch mode guidance, and runs one synchronous sweep at a time; quick/hybrid modes still use Anthropic subagents for all searches.
Idea: After a few weeks of real use, extend the preference to quick.md/hybrid.md if answer quality holds, and add a parallel pattern (multiple explore-minimax-run invocations via background Bash with distinct roots/questions) for dataset-wide audits.
Open questions: What's the observed false-citation rate in practice? Is 540s enough for very-thorough sweeps on large repos? Should the citation spot-check be automated (script greps each cited line)?
Depends on: Usage data from deep/deep-fable sessions

Problem: Fable/Opus sessions still burn tokens on remaining bulk work: /reflect-logs extraction, test authoring from specs, /end-session//housekeeping doc summarisation, transcript processing.
Idea: Extend the shipped 2026-09-11 pattern (wrapper materialises inputs, MiniMax gets Read,Glob,Grep,Write only, strict result gate, operator adjudicates): a /reflect-logs --minimax draft mode producing topic-file diffs for approval, and an mm-test-task-style spec→tests generator (verifiable — the tests must run).
Open questions: Observed invented-findings rate from /review-minimax in real use? Does reflect-logs drafting keep topic-file voice consistent? Where does test generation need the frozen-fixture skeleton (M27) first?
Depends on: Usage data from /review-minimax and /ci-triage-minimax on real agent branches

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)

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.sh in 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

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.sh in 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-run mode 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

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.md or 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

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+)