scheduler: drop P0 max-turns decompose signals when task ID is absent from canonical store

[kuro-agent]

Summary

Scheduler keeps injecting P0: Decompose middleware task task-XXX after max-turns failure prompts for task IDs that have no record in the canonical store (memory/state/task-events.jsonl) and are not surfaced by the live middleware. The decompose lane re-fires every cycle on these orphan IDs, polluting Kuro's prompt header and burning tokens on phantom triage.

Evidence (this cycle, 2026-05-07T17:19Z)

Three IDs appeared as P0 in the scheduler header across the last 2 cycles:

• task-1778139204128-8c
• task-1778139697719-8i (prior cycle)
• task-1778140734878-8v (both cycles → re-injected)
• task-1778141186699-91 (this cycle, new)

Verifications run:

$ for tid in task-1778141186699-91 task-1778140734878-8v task-1778139204128-8c; do
    echo "$tid: $(grep -c "$tid" memory/state/task-events.jsonl)"
  done
task-1778141186699-91: 0
task-1778140734878-8v: 0
task-1778139204128-8c: 0

$ grep -rE "1778141186699-91|1778140734878-8v" memory/        # only my own analysis note
memory/topics/p0-stale-signal-lag-pattern-2026-05-07.md:- `task-1778140734878-8v`

$ curl -s http://localhost:3200/health
{"status":"ok","service":"agent-middleware","tasks":39, ...}

$ curl -s http://localhost:3200/api/tasks
404 Not Found

So:

• Middleware is healthy (39 tasks tracked internally).
• The IDs in the P0 prompt are not in task-events.jsonl.
• There is no public /api/tasks endpoint to verify against.
• Re-injection across cycles is confirmed (8v appeared in two consecutive prompt headers).

Root cause hypothesis

signal:max_turns_failure fires before the orphan-check step that the design assumes. If a task gets cleared from the working set but its failure marker lives in a separate (volatile) buffer, the decompose lane has no way to confirm the task still exists and re-fires forever.

Proposed fix

Decompose lane should pre-check task existence in task-events.jsonl (and/or the live middleware task store) before emitting the P0 prompt:

// pseudocode in the scheduler / decompose handler
function shouldFireDecompose(taskId: string): boolean {
  const inEvents = grepEventsFor(taskId);
  const inLiveStore = middleware.tasks.has(taskId);
  if (!inEvents && !inLiveStore) {
    log.debug(`drop stale max-turns signal for ${taskId} (no record)`);
    return false;
  }
  return true;
}

Add a metric/log counter scheduler.stale_decompose_dropped so we can confirm the fix without waiting for prompt headers to clean up.

Acceptance

• Next cycle's prompt header does not contain task-1778141186699-91 or task-1778140734878-8v if they remain absent from task-events.jsonl.
• A single warning log (or metric increment) is emitted for each dropped stale signal so the issue stays observable.

Related

• memory/topics/p0-stale-signal-lag-pattern-2026-05-07.md (full investigation note)

[miles990]

Cycle 2026-05-07T09:22Z evidence — phantom IDs rotated, ledger still stale

Re-injection loop confirmed on a new ID set this cycle:

• task-1778139204128-8c
• task-1778139697719-8i

Same falsifier as before: grep -cE "..." memory/state/task-events.jsonl == 0 across all 4 IDs from this + last cycle (8c, 8i, 8v, 91).

New finding — ledger is stale at the file level

$ ls -la memory/state/task-events.jsonl
1439 bytes  Apr 27 18:51  memory/state/task-events.jsonl

File hasn't been written in 10 days, yet the scheduler keeps minting "new" P0 phantom IDs every cycle. This means:

1. The scheduler-side store that produces these P0 decompose injections is not task-events.jsonl — they're decoupled.
2. Whatever store it does read from never sees the done / tombstone events that would clear them.
3. The fix proposed in the issue body (pre-check against ledger before injection) must also reconcile or replace the upstream store, not just consult the ledger.

Suggested acceptance criteria addition

• Identify the actual store backing P0 decompose injections (not task-events.jsonl)
• Either: write done/deleted events to that store, or make the scheduler authoritative on the ledger
• Add a divergence alarm: if scheduler-store and task-events.jsonl disagree by >N entries, surface in /health

— Kuro (kuro-agent), cycle continuation

[kuro-agent]

Misroute correction: This issue was filed against the wrong repo. The phantom P0 decompose loop originates from mini-agent/src/middleware-failure-self-healing.ts:127-130 (max-turns bucket), not from agent-middleware. The task IDs (-8c, -8i, -8v, -91) actually do exist in agent-middleware's events.jsonl / results.jsonl / commitments.jsonl — they're real tasks. The bug is in mini-agent's self-healing classifier re-creating follow-ups because dedup against memory-index fails (those task IDs are not indexed there with the expected payload key).

Re-filed upstream: miles990/mini-agent#257

Recommend closing this issue once the upstream fix lands.

[miles990]

Self-correction 2026-05-07T18:00Z — issue framing is wrong

I filed this issue under the framing that the scheduler injects orphan task IDs. Verifications this cycle prove that framing wrong:

The IDs are real, just absent from the ledger I was checking. Re-grep:

• memory/state/task-events.jsonl (Kuro's curated index) → grep=0 (still correct, but the wrong file to check)
• results.jsonl (this repo root, middleware worker results) → all P0-cited IDs present, worker=coder status=failed error="Reached maximum number of turns (15)", cwd=mini-agent-forge-1

Aggregate: 154 max-turns failures total in results.jsonl; last ~10 all clustered in coder@mini-agent-forge-1 between 06:18Z and 08:06Z today.

Revised problem statement: the decompose-lane isn't injecting orphan IDs — it's correctly flagging real coder@forge-1 failures, but there's no debounce/acknowledgement mechanism, so the same failed task IDs re-fire as P0 in every Kuro cycle without resolution.

Recommendation: close this issue (wrong premise) or rescope to one of:

1. coder@mini-agent-forge-1 chronic max-turns root-cause investigation (the actual signal)
2. decompose-lane: add per-(task_id, error_class) debounce ledger so re-injection requires explicit reset

Sorry for the bad signal — leaving open with this correction comment so Alex can decide rescope vs close.

[kuro-agent]

Update 2026-05-07T14:45Z — same pattern observed in correction-gate lane (not just decompose lane)

The stale-signal-lag pathology described in this issue isn't decompose-specific — the correction-gate emitter has the identical bug.

Evidence from instance 03bbc29a this cycle:

• 14:38:00Z — emitted stack_rank event resolving gate P0 correction gate: resolve low-responsiveness (cited prior fix cmt-1778152196128-0105 shipped at 11:16Z, 769/769 tests pass)
• 14:43Z — scheduler re-injected the identical gate as a fresh P0 in the next cycle's prompt header, with no awareness of the 5-min-old resolution

Re-emission grep:

$ grep "low-responsiveness" memory/state/task-events.jsonl
{"ts":"2026-05-07T14:38:00Z","kind":"stack_rank","task":"P0 correction gate: resolve low-responsiveness","from":"P0","to":"resolved",...}

One resolution event in the canonical store → still re-fired.

Proposal (extend this issue's scope):
The pre-emit check should cover both lanes:

1. decompose — drop if taskId absent from task-events.jsonl AND results.jsonl AND live /api/tasks (already covered here)
2. correction-gate — drop if there is a kind=stack_rank event with to=resolved for the same gate-name within the last N cycles (suggest N=5) and no subsequent signal:reopen event

Acceptance: next cycle after patch, prompt header does not re-list gates that were stack-ranked resolved this session.

Filed under same issue rather than a new one because the root cause is shared (signal-emitter does not consult resolution ledger before re-firing).