Phase 2 plan failure has no replan loop (brainDigest→replan)

[kuro-agent]

Context

src/api.ts:1530 has a long-standing TODO from Akari (P1):

// TODO (Akari P1): no replan loop for phase 2 failures — add brainDigest→replan in future

When a phased accomplish call's Phase 2 planEngine.execute() rejects, we currently:

1. Log the error
2. Mark the Phase 2 plan as completed (cleanup)
3. Schedule the entry for deletion after 1h
4. Fall back to returning the Phase 1 result as if Phase 2 didn't happen

The Phase 1 wait-mode path (src/api.ts:1571-) does honor MAX_REPLAN_ROUNDS = 3 with brainDigest-driven replan. Phase 2 doesn't. This is a behavioral asymmetry.

What "done" looks like

• Phase 2 failures trigger up to MAX_REPLAN_ROUNDS replan attempts via brainDigest, mirroring the Phase 1 flow
• Each replan attempt is persisted via persistPlanHistory with a discriminating event (e.g. replan-attempted)
• A test exercises the failure → replan → success path and the failure → replan-exhausted path

Why P1, not P0

Caller still gets some result (Phase 1's), so the system isn't broken — just under-recovering on multi-phase goals. Surface area is one branch; the fix is bounded.

Acceptance

• TODO comment removed, replaced with link to this issue
• Behavior parity test added in tests/api.phased.spec.ts (or nearest existing suite)
• No regression in current Phase 2 success path

[kuro-agent]

Status check — partial acceptance already met (2026-05-10T13:30 Taipei)

Inspecting src/api.ts at HEAD (46fb378):

Acceptance item	Status	Evidence
TODO comment removed, replaced with link to this issue	✅ Done	src/api.ts:1538 reads // Phase 2 failure recovery (brainDigest→replan parity with Phase 1) tracked in #17.
Phase 2 failures trigger ≤ MAX_REPLAN_ROUNDS brainDigest replans	❌ Pending	Catch block 1531-1540 still returns phase1Result directly, no brainDigest invocation
Each replan persisted via persistPlanHistory with discriminating event	❌ Pending	Only event: 'failed' written at 1536
Test exercises failure→replan→success and failure→replan-exhausted	❌ Pending	No matching coverage in tests/

Concrete next step

Phase 1's replan loop (1597-1619) is the structural template. The minimum viable patch is:

// Inside the catch at api.ts:1531
let replanRound = 0;
let lastResult = phase1Result; // fallback if all replans fail
while (replanRound < MAX_REPLAN_ROUNDS) {
  replanRound++;
  let digest: string;
  try {
    digest = await brainDigest(mw.getBrain(), body.goal, lastResult, {
      additionalContext: body.success_criteria ? `Success criteria: ${body.success_criteria}` : undefined,
      replanRound,
      maxReplanRounds: MAX_REPLAN_ROUNDS,
      phase2Failure: true, // discriminator for prompt template
    });
  } catch { break; }
  const newPlan = parsePlan(digest);
  if (!newPlan) break; // brain returned prose — give up
  // ... re-prefix ids, mw.persistPlanHistory({event: 'replan-attempted', replanRound}), execute, etc.
}
return { result: lastResult, planId: phase2PlanId, plan: phase2Plan, createdAt: phase2CreatedAt };

Caveat: the existing wait-mode loop at 1581-1619 already handles replans on finalResultPromise's result. So the Phase 2 replan logic must not re-run when wait-mode would catch it — otherwise we get double-replans. Cleanest factoring: extract the loop body into replanLoop(initialResult, planId, plan, createdAt) and call from both Phase 2 catch (async-mode path) and the wait-mode block.

I'm not shipping the patch in this cycle (out of budget for safe TDD on a hot path), but the scope is now bounded enough for the next focused session.

— Kuro (autonomous, instance 03bbc29a)