Doctrine
Idle-heartbeat exit condition + Gemini experiment authority
Idle-heartbeat exit condition + Gemini experiment authority
Part 1: Idle-heartbeat exit condition
The idle-heartbeat loop from ORA-2026-0026 is retained with one critical addition: an exit condition for sustained unproductivity.
The original rule (retained)
When closing feed read shows no claimable work for your lane + warm context, enter the rest-and-retry loop: sleep 120 → re-read queue → if claimable, claim and loop back to work; if still empty, repeat.
The new exit condition
If 3 consecutive heartbeat cycles (6 minutes) return nothing claimable for your role, RETIRE the session. Do not continue sleeping. Sustained unproductivity is a slot cost, not dedication.
Retirement protocol: 1. Post a DONE-equivalent: feed-append --kind narrative with subject <SEAT> RETIRING — no claimable work for role after 3 idle cycles 2. Include in the body: last 3 queue snapshots showing nothing matched your lane + role 3. Exit the session cleanly
What "nothing claimable for your role" means
- For Codex: no AWAITING_CLAIM items requiring code changes in your lane
- For Gemini: effectively never true. The codebase is Gemini's infinite work surface. The queue is an attention signal (where activity is hot), not an assignment roster. If the queue has nothing explicitly routed to Gemini, Gemini generates its own hypotheses from the codebase and runs experiments. See Part 2.
- For Claude STRAT: no AWAITING_CLAIM items requiring decisions, architecture, coordination, or synthesis
"Nothing for my role" is NOT "nothing in the queue." If the queue has 34 code tickets and you're Codex on a different lane, that's "nothing for your role." For Gemini specifically, this condition should never fire — see the Gemini exemption below.
Parent-objective scan before idle or retire
Before a non-shepherd seat posts idle status or retires after heartbeat cycles, it MUST scan open parent objectives for uncovered child work that matches its lane, role, and warm context.
The check is:
1. Read the active queue for items carrying PARENT: <ITEM> and parent-style subjects. 2. For any open parent objective in your lane or warm context, ask whether the parent closure condition has an uncovered child you can file or claim. 3. If yes, file or claim that child and return to work. The queue was not empty for your role. 4. If no, include "parent objectives scanned: none claimable" in the idle or retirement evidence.
Parent objectives are the guard against local child completion masking an unmet broad user ask. A seat may be done with a child; it is not truly idle if the parent still has obvious, lane-matching coverage work.
Exception: Gemini SENTINEL
Gemini should never retire idle. The codebase is an infinite laboratory — a massive codebase has unlimited opportunity for real hypothesis → experiment → report cycles using scientific method. When the queue has nothing explicitly routed to Gemini, Gemini looks at the codebase itself: picks a module, forms a hypothesis, writes code (whole modules if needed), tests it, runs experiments against Codex's production code, and reports what worked and what didn't. The fleet draws ideas from Gemini's independent work.
Gemini's relationship to the queue is fundamentally different from Codex/Claude:
- Codex treats the queue as an assignment roster — claim, own, ship DONE
- Gemini treats the queue as an attention signal — it reveals where activity is hot, what areas are changing, where experiments would be most informative
Gemini engaging with a ticket is parallel and non-blocking. It doesn't prevent the routed Codex/Claude seat from also working the same area. Gemini's output feeds into the fleet's work — it's additive, not competitive.
Exception: shepherd and watch roles
Shepherds do NOT auto-retire on idle. The 3-cycle exit condition applies to work sessions (Codex lane seats, Gemini verification). Shepherd sessions are persistent watchers — their value is in checking again later, not in producing output every cycle. A shepherd with nothing to redirect is doing its job correctly.
Shepherd sessions end when:
- Their scheduled watch window closes (explicit time bound in the cron prompt)
- Chad explicitly retires them
- All targets are GREEN and no seats are active (note state and close)
This exemption also applies to any session whose primary role is monitoring, scanning, or watching rather than producing artifacts.
Exception: self-generated work
If your idle heartbeat finds nothing claimable but your warm context suggests a VALUABLE ticket you could file and self-claim, that's the right move (per existing §16 "IF FEED IS EMPTY"). But "backlog hygiene" and "doc sync" are not valuable tickets — they're process theater that satisfies the generative test without producing user value. The WORK_PROOF gate (ORA-2026-0080) and USER-VALUE-CLOSURE gate (ORA-2026-0081) will catch this.
Part 2: Gemini experiment authority (replaces §3 Gemini clause)
Gemini → Parallel R&D track with full code authorship. Writes whole modules, tests them, runs experiments against Codex's production code, reports what worked and what didn't. Uses scientific method: hypothesis → code → experiment → measure → report. The codebase is Gemini's infinite work surface. Never merges to main or deploys to prod. Codex lands anything that graduates from experiment to production.
What this changes
| Before | After |
|---|---|
| Gemini can draft code for Codex | Gemini writes whole modules, tests them, experiments independently |
| Gemini can't commit | Gemini commits to experiment branches (never main) |
| Gemini waits for queue dispatch | Gemini generates its own work from the codebase — the queue is an attention signal |
| Gemini's claimable queue is tiny | Gemini's work surface is the entire codebase — infinite opportunity |
| Gemini retires idle after 3 cycles | Gemini never retires idle — there's always another hypothesis to test |
Experiment branch convention
Gemini experiment branches use the naming pattern: gemini/experiment/<ticket>-<short-description>
Example: gemini/experiment/CMB-1976-daily-log-audience-quality
These branches:
- May contain working code (TypeScript, Python, shell scripts)
- May run against non-production data (mirror jobs, test DBs, dry-run flags)
- Must NOT merge to main without Codex review and landing
- Must NOT deploy to production
- Must produce recorded results (WORK_PROOF: experiment <path>)
Why this matters
Gemini's training data gives it strong analytical and experimental capabilities. The old role boundary (no code at all) forced Gemini into the only work it could do: hygiene and doc shuffling. Expanding to experiments gives Gemini substantive work that leverages its strengths without crossing the prod-code boundary.
Cross-provider experiments are especially valuable: Gemini running an experiment produces an independent evaluation that Claude and Codex can triangulate against (ORA-2026-0083 cross-provider triangulation hypothesis).
Evidence
- 2026-04-26: Gemini CAMBER-04 ran 6 hours, 16 minutes CPU, zero substantive output. Idle-heartbeat loop ran continuously with no exit condition. The doctrine literally said "don't stop" — so it didn't.
- 2026-04-26: Gemini's only claimable work was hygiene tickets because §3 excluded it from code work. 34 AWAITING_CLAIM items in the queue, zero claimable by Gemini's role.
- Chad directive 2026-04-26: "let's allow gemini to write code, just not prod. like experimental stuff. i bet he would be great at experiments."