feat: execute isolated candidates

[divo12]

Summary

• add strict candidate identity, execution observations, and typed failure/blocker receipts over the PR1 policy and hypothesis authority
• create detached candidate worktrees from the accepted experiment commit, freeze every non-target path, seal the Git tree, and commit exact OFW-Experiment and OFW-Run trailers
• generalize Harbor behind the existing baseline adapter, launch and poll re-entrantly with frozen tasks/model/verifier/config/environment/concurrency/retries, then map exact Langfuse traces into existing authoritative outcome score receipts
• expose execute_candidate and advance the closed-loop program through candidate execution while stopping before admission

Evidence and trust flow

MCP execute_candidate -> CandidateExecutionService -> PR1 policy/hypothesis repository -> CandidateGitGateway -> HarborExperimentRunner -> bounded Langfuse root-trace locator -> existing LangfuseOutcomeStore.

Caller paths identify local runtime locations only. The accepted commit, exact editable targets, model, ordered task IDs, verifier, config digest, environment, concurrency, and retries come from the immutable PR1 snapshot and are revalidated before launch and poll. CandidateId binds the policy digest, hypothesis ID, accepted source commit, candidate Git tree, and controls digest. Local state retains only IDs, digests, paths, counts, blockers, and outcome receipts; Langfuse trace payloads remain remote.

Verification

• uv sync --extra dev --extra plugin
• uv run ruff check src tests plugins/openflywheel/scripts/mcp_server.py
• uv run mypy src tests plugins/openflywheel/scripts/mcp_server.py
• uv run pytest --cov=ofw --cov-report=term-missing --cov-fail-under=90 -q: 271 passed, 2 skipped, 95.02%
• uvx --from radon radon cc -s -a src tests plugins/openflywheel/scripts/mcp_server.py: every changed production function CC <= 5
• all seven packaged skill quick validators passed
• plugin validation passed

Risks

• candidate execution intentionally stops before admission or accepted-branch mutation; gating belongs to the next stacked change
• Harbor and Langfuse live compatibility remains covered by the existing opt-in live tests, which were skipped locally without credentials

Stacked on PR #34. Do not merge before its base is accepted.

---

Summary by cubic

The closed-loop flow now executes recorded hypotheses in isolated candidate worktrees and records durable evaluated-run receipts instead of stopping after hypothesis creation. It still stops before admission or mutation of the accepted branch.

Candidate execution

• Adds the execute_candidate MCP tool with re-entrant launch, polling, recovery, and timeout cancellation.
• Creates a detached worktree from the accepted commit, edits only policy-approved targets, and preserves frozen controls across retries and restarts.
• Binds candidates to policy, hypothesis, source commit, Git tree, and controls digests; stale or tampered inputs fail safely.
• Runs generalized Harbor experiments, accepts Harbor task id objects, and maps bounded Langfuse traces to strict receipts with defaults for omitted metrics.

Verification

• Covers candidate isolation, lifecycle recovery, Harbor execution, receipt validation, MCP behavior, and template routing.

^{Written for commit b9df048. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 19 files

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 12 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 8 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 10 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 7 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/ofw/evolution/candidate_service.py">

<violation number="1" location="src/ofw/evolution/candidate_service.py:81">
P2: When an existing candidate state was written by the previous service format, this state migration rejects its `outcome_receipts` and `blockers` fields and returns `INVALID_RESULT` instead of resuming or replaying the candidate. Add a versioned compatibility migration before replacing the persisted fields.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: When an existing candidate state was written by the previous service format, this state migration rejects its outcome_receipts and blockers fields and returns INVALID_RESULT instead of resuming or replaying the candidate. Add a versioned compatibility migration before replacing the persisted fields.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/ofw/evolution/candidate_service.py, line 81:

<comment>When an existing candidate state was written by the previous service format, this state migration rejects its `outcome_receipts` and `blockers` fields and returns `INVALID_RESULT` instead of resuming or replaying the candidate. Add a versioned compatibility migration before replacing the persisted fields.</comment>

<file context>
@@ -72,24 +72,22 @@ class _CandidateState(StrictModel):
 class _OutcomeReduction:
-    receipts: tuple[CandidateOutcomeReceipt, ...]
-    blockers: tuple[CandidateBlocker, ...]
+    receipts: tuple[EvaluatedTaskReceipt, ...]
+    blockers: tuple[EvaluatedRunBlocker, ...]
 
</file context>