didericis-claude
dee0121e8d
On a Firecracker gateway cold boot, reconcile every live agent VM against the fresh gateway: push the new mitmproxy CA into each agent's trust store, re-provision git-gate repos/creds from the persisted upstreams snapshot, and restore egress tokens. Per-bottle failures are logged and skipped so one unreachable VM does not block the rest. New modules / changes: - backend/firecracker/reconcile.py: attach_bottled_agents_to_gateway, _push_ca, _reprovision_git_gate, _guest_ip_from_config - git_gate/provision.py: write upstreams.json after key provisioning so the bring-up reconcile can reconstruct the upstream table without the manifest - backend/firecracker/infra.py: call attach_bottled_agents_to_gateway in the cold-boot branch of ensure_running() - backend/base.py: no-op default on BottleBackend - backend/firecracker/consolidated_launch.py: remove superseded _reprovision_running_bottles / _guest_ip_from_config - orchestrator: OrchestratorCore.update_agent_secret + POST /bottles/<id>/secret + client.update_agent_secret (single-secret in-place update, the reusable primitive from the 2026-07-26 hotfix) - tests: 15 new tests in test_firecracker_reconcile.py; updated test_firecracker_infra.py cold-boot cases; stale FC reprovision tests removed from test_backend_secret_reprovision.py Closes #516.
Research notes
Investigations into a question or a design space — landscape surveys,
tradeoff analyses, "should we do X or Y," assessments of an approach
before (or instead of) committing it to a PRD. A research note is where
the thinking lives; a PRD is where a decided feature lives, and a
decision record is where a settled choice lives (see
../README.md for picking between them).
Notes are opinionated. They reach a conclusion rather than dumping a neutral survey — the point is to move a decision forward and leave a durable record of why it went the way it did.
Naming
kebab-case-topic.md, named by subject and not numbered (unlike
PRDs and decision records). Pick a name that says what was
investigated: bash-vs-python-vs-go.md, pipelock-assessment.md,
issue-tracking-vs-in-repo-decision-history.md.
Shape (freeform)
There's no fixed template — use whatever structure fits the question. In practice most notes share a loose shape:
- Open with the question — a sentence or two on what's being investigated and why it came up.
- Lead with the verdict — a
## Summarynear the top stating the conclusion, so a reader gets the answer without reading the whole thing. - Then the analysis — whatever the argument needs: comparison tables, per-option sections, failure-mode walkthroughs, the axes that actually matter.
- End with a recommendation when the note exists to drive a decision.
Keep the reasoning self-contained and grounded: cite sources, link files and PRDs, and prefer concrete evidence from this repo over generic claims — a note should stand on its own without a chat log or a Gitea thread. When a note's recommendation gets acted on, capture the resulting decision in a PRD or a decision record; the note stays as the "why we looked into it," not the system of record for the choice.