Request for Integration Hooks: Automatic Failover in Munder Difflin 0.5.5+
Context
We run Munder Difflin 0.5.5 as a multi-agent office: several lasting Claude/Codex/other-engine seats supervised by our infrastructure. We need automatic failover to a backup model or engine when a seat's provider fails, without hand-editing the installed app and without shell wrappers that leave provider-specific state attached to the wrong process after a switch.
The public repository does not contain source matching the installed 0.5.5 bundle (no commit sets package.json to 0.5.5), so we cannot patch the source ourselves. We're requesting narrow main-process hooks to enable failover instead.
What we're asking for
-
Trusted provider-failure events with generation correlation. Emit one event (main process) per provider failure and process exit, carrying the seat ID and generation counter, so we can distinguish restarts from stale events.
-
One atomic restart path. A single restart primitive, used by all four paths (failure recovery, UI restart, restore, power resume), that claims the generation before teardown, retains worktree, and prevents race conditions.
-
Provider-scoped session map with engine-independent handoff. A representation that survives engine switches (Claude → Codex) without losing in-flight context, keyed by provider rather than one engine's native format.
-
Main-process seed delivery and readiness acknowledgement. Let the main process deliver seeds and receive readiness directly, so recovery completes with no renderer window open.
-
Paid-inference gate and actual-engine receipt. A hook gating fallback routes that incur paid spend, plus a receipt of which engine/model actually ran, kept separate from configured primary so app restarts cannot silently reset active fallbacks.
What we're not asking for
- Credentials or API-key material exposed through these hooks.
- Any UI change; all five are main-process/event-level only.
- Support for our specific chain policy (we'll implement that ourselves).
What we offer in return
We'll own all application-logic integration: supervisor implementation, failover policy, chain sequencing, and local testing. If you ship these hooks, we can deploy automatic failover without your ongoing involvement.
If upstream integration isn't possible, we'll fall back to manual operator-triggered restarts rather than patching the installed app.asar. Either way, we're ready to move forward.
Request for Integration Hooks: Automatic Failover in Munder Difflin 0.5.5+
Context
We run Munder Difflin 0.5.5 as a multi-agent office: several lasting Claude/Codex/other-engine seats supervised by our infrastructure. We need automatic failover to a backup model or engine when a seat's provider fails, without hand-editing the installed app and without shell wrappers that leave provider-specific state attached to the wrong process after a switch.
The public repository does not contain source matching the installed 0.5.5 bundle (no commit sets
package.jsonto0.5.5), so we cannot patch the source ourselves. We're requesting narrow main-process hooks to enable failover instead.What we're asking for
Trusted provider-failure events with generation correlation. Emit one event (main process) per provider failure and process exit, carrying the seat ID and generation counter, so we can distinguish restarts from stale events.
One atomic restart path. A single restart primitive, used by all four paths (failure recovery, UI restart, restore, power resume), that claims the generation before teardown, retains worktree, and prevents race conditions.
Provider-scoped session map with engine-independent handoff. A representation that survives engine switches (Claude → Codex) without losing in-flight context, keyed by provider rather than one engine's native format.
Main-process seed delivery and readiness acknowledgement. Let the main process deliver seeds and receive readiness directly, so recovery completes with no renderer window open.
Paid-inference gate and actual-engine receipt. A hook gating fallback routes that incur paid spend, plus a receipt of which engine/model actually ran, kept separate from configured primary so app restarts cannot silently reset active fallbacks.
What we're not asking for
What we offer in return
We'll own all application-logic integration: supervisor implementation, failover policy, chain sequencing, and local testing. If you ship these hooks, we can deploy automatic failover without your ongoing involvement.
If upstream integration isn't possible, we'll fall back to manual operator-triggered restarts rather than patching the installed app.asar. Either way, we're ready to move forward.