PRD: unify MCTS search control plane across research lanes

[proerror77]

Problem

Monday currently has three overlapping search-control implementations:

1. alpha-harness/engine runs a real Formula MCTS loop with budget, observation, checkpoint, and resume.
2. ploy-research/prediction_loop.rs owns a second mission budget/checkpoint/feedback loop, but its candidates are proposed by an LLM rather than selected by MCTS.
3. ploy-research/alpha_search.rs builds a separate MCTS-shaped state and expansion plan, but the official monday-prediction-research runner does not restore that state into its next iteration.

This creates the appearance of one MCTS research architecture while the production research entrypoints actually use different controllers. New evaluator features such as the BTC 5m Markov report can compile without being reachable from the official runner.

Outcome

Create one domain-neutral MCTS search kernel for both continuous-contract and prediction-market research. The kernel owns deterministic UCT selection/backpropagation, budgets, checkpoint/resume, iteration ledger, and terminal outcomes. Each research lane supplies a domain adapter for candidate expansion and evaluation.

The continuous lane keeps Formula candidates and purged walk-forward IC/return evaluation. The prediction lane keeps event episodes, official settlement labels, event-disjoint folds, separate Up/Down execution evidence, and prediction-specific metrics. These evaluators must not be merged.

Target interface

The shared module exposes one small search interface:

• stable candidate identity and serialized candidate payload;
• root candidate and bounded expansion actions;
• finite scalar search reward derived by the domain adapter from typed evaluation evidence;
• deterministic budget and checkpoint inputs;
• immutable search outcome and checkpoint outputs.

The kernel must not know Formula AST fields, Polymarket market IDs, labels, Brier score, IC, trading fees, OSS, LLM providers, or execution authority.

Two real adapters satisfy the seam:

• Continuous Formula adapter: Formula grammar plus the existing causal time-series evaluator.
• Prediction adapter: typed probability/model candidates plus the existing event-disjoint settlement evaluator and separate token-side execution evidence.

An LLM may propose bounded expansion candidates, but MCTS owns selection, backpropagation, budget, checkpoint, and resume. Markov is an evaluator/model choice, not a search controller.

Migration rules

• Preserve existing continuous Formula MCTS behavior and checkpoints before migrating prediction research.
• Keep alpha-harness as the Monday research entrypoint and outer transport/evidence owner.
• Convert monday-prediction-research into the prediction adapter/runner behind the shared search contract.
• Retire the duplicate prediction LoopRun state machine only after checkpoint parity is proven.
• Convert alpha_search.rs into a read-only artifact projection of the shared checkpoint, then remove its private UCT/backprop state.
• Do not change collectors, evidence compilation, cohort construction, ResearchSnapshot semantics, evaluator metrics, promotion, runtime, or execution.
• Existing Compile matched BTC 5m LOB and reference evidence for snapshot input #173 and BTC 5m cohort to sealed ResearchSnapshot #169 continue independently. The first BTC 5m baseline E2E may run with zero search budget and must not wait for this migration.

Acceptance criteria

• One shared MCTS checkpoint schema is used by continuous and prediction adapters.
• Deterministic replay from the same checkpoint produces the same next candidate in both lanes.
• Continuous Formula results remain byte/evidence compatible or have an explicit versioned migration proof.
• Prediction MCTS selection and backprop consume training cohorts only; holdout evidence cannot mutate search state.
• LLM responses can add bounded expansion choices but cannot mutate checkpoint, reward, budget, or terminal state directly.
• Settlement, Up execution, and Down execution remain separate typed evidence.
• The official cloud research entrypoint runs the shared kernel; no second active prediction search controller remains.
• Legacy prediction and Alpha Search checkpoints either migrate fail-closed or are rejected with a versioned diagnostic.

Out of scope

• Collector deployment and raw artifact repair.
• BTC 5m cohort/snapshot correctness work in Compile matched BTC 5m LOB and reference evidence for snapshot input #173/BTC 5m cohort to sealed ResearchSnapshot #169.
• Combining time-series and event-settlement evaluators.
• 15m/1h coverage, full-tick microstructure, Paper/Live, OMS, RiskGate, or promotion.
• Merging the two Cargo workspaces as part of this change.

Rollout

Migrate in independently revertible PRs. Each PR must stay below the repository scope guardrail unless an explicitly reviewed atomic exception is documented. The old controller remains read-only during parity and is deleted only after the new path produces equivalent checkpoint and result evidence.

[proerror77]

Implementation order is strictly serialized because these issues share one dependency lane and write ownership: #185 -> #186 -> #187 -> #188 -> #189. Existing BTC 5m evidence/snapshot work #173 -> #169 continues independently. #170 remains the cloud result-publication owner; a baseline-only zero-search run may proceed before the MCTS migration, while MCTS search evidence waits for #187. The stale codex/btc-5m-markov-trial branch is not an implementation base for this PRD.

[proerror77]

Implementation order corrected after code review: #185 -> #186 -> #187; then #202 (prediction checkpoint projection) and #203 (Formula Alpha Search migration) are independent domain-specific lanes; #189 follows both plus parity evidence. #188 is closed as superseded because it mixed those two contracts.