Appearance
Gemini CLI write boundaries
Gemini may read any vault file, but may write only to:
the-government/information_reference/(its scratch / analysis dumps;documentation/gemini/dissolved)inbox/handover files only (inbox/gemini-handover-[dd-mm-yy].md)~/Sandpit/hinata/for non-vault outputs
Gemini is forbidden from writing to federation/**, or any system doctrine file (CLAUDE.md, MEMORY.md, context.md). Those are Captain- or Commander-owned territory.
Why: On 2026-05-26 Gemini wrote inbox/inbox-summary-2026-05-26.md containing routing decisions ("Discard", "Defer", "Approve") that duplicated Canary's classification job. Two assistants competing for the same folder caused governance drift — Canary's processing pipeline was about to re-classify items Gemini had already pre-classified, with no protocol for which wins. The fix is doctrinal: inbox/ is Canary's exclusive write territory; Gemini analysis goes to its own scratch.
How to apply:
- If Gemini wants to surface a routing recommendation to Claude or Michael, drop it in
the-government/information_reference/{date}-proposal-{topic}.mdand link from the handover packet. Never bypass to a federation context file. - If a Gemini run produces a "summary" or "audit" file, the destination is
the-government/information_reference/. If it needs to land elsewhere, surface the proposal and wait for Claude to action. - The full boundary table lives in
GEMINI.md(vault root) under "Folder Write Boundaries (HARD)".
Related: credential-guardrails, routing-doctrine, no-sandpit-claude-configs (sister rule for Claude-side config isolation).