Skip to content

fix(OperationsCenter): guard every execute backend in ensure_executor_backends - #489

Open
ProtocolWarden wants to merge 1 commit into
mainfrom
fix/ensure-executor-backends-critique
Open

fix(OperationsCenter): guard every execute backend in ensure_executor_backends#489
ProtocolWarden wants to merge 1 commit into
mainfrom
fix/ensure-executor-backends-critique

Conversation

@ProtocolWarden

Copy link
Copy Markdown
Owner

Problem

ensure_executor_backends() self-heals missing execute backends by reinstalling them editable from sibling checkouts. It covered two of the three backends src/ imports:

if "${VENV_DIR}/bin/python" -c "import team_executor, dag_executor" 2>/dev/null; then
  return 0
fi
...
for _sib in TeamExecutor DAGExecutor; do

But src/ also imports critique_executor.executor, .models, plus a full adapter at src/operations_center/backends/critique_executor/.

A dropped CritiqueExecutor therefore left the guard passing, so the self-heal never fired and the critique lane stalled with exactly the "no obvious cause" symptom the function's own comment warns about for its other two backends. It is the failure mode the function exists to prevent, reproduced in the one case it did not cover.

Root cause is structural rather than a typo: the guard enumerates backends independently of what src/ actually imports, so the two drift silently.

Change

  • add critique_executor to the import guard
  • add CritiqueExecutor to the reinstall loop
  • state the invariant in the comment — the guard must import every backend src/ imports — so the next backend added does not repeat the drift

Verification

Tested end to end against a live venv:

Step Result
bash -n on the edited script pass
Baseline, all three present guard short-circuits — no needless reinstall
Old guard vs missing critique_executor passes despite the missing backend — the bug, reproduced
New guard, same condition fires, reinstalls all three siblings
After self-heal critique_executor restored
Capabilities plane intact

That last row matters: sibling installs bypass the [tool.uv] override-dependencies pin, so a transitive dep could have regressed repograph to the planeless build and silently killed CapabilityRegistry. It did not, but it was checked rather than assumed.

Full unit suite green — 8530 passed, 0 failed. The count rose by one against baseline (8529, with skips 5 → 4): a previously-skipped test unlocks once the executor backends are importable. Custodian pre-push gate clean.

Review note

scripts/operations-center.sh is on the council's guardrail_paths §G1 set, so this gets the K=3 cross-family panel rather than single self-review. Expected for this file — flagging it so the heavier review on a 15-line diff is not a surprise.

Related

Independent of, but thematically adjacent to, fix/executor-install-ref and ProtocolWarden/TeamExecutor#19, which fix the other executor wiring defect (the team-executor CLI path). Kept on a separate branch so each is reviewable on its own.

🤖 Generated with Claude Code

…_backends

The self-heal covered only two of the three backends src/ imports. The guard
was `import team_executor, dag_executor` and the loop `for _sib in TeamExecutor
DAGExecutor`, but src/ also imports critique_executor (.executor, .models, and
a full adapter at backends/critique_executor/).

A dropped CritiqueExecutor therefore left the guard passing, so the self-heal
never fired and the critique lane stalled with exactly the "no obvious cause"
symptom the function's own comment warns about for its other two backends.

Add critique_executor to the guard and CritiqueExecutor to the loop, and state
the invariant in the comment — the guard must import every backend src/ imports
— so the next backend added does not repeat the drift.

Verified against a live venv: with all three present the guard short-circuits;
after uninstalling critique-executor the old guard still passes while the new
guard fires and restores all three; capabilities plane intact afterward.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant