flower
/
All feedback
Bug addressed #14

Stale in_progress segment (917) is a false open-loop; recall_open_loops and recall_resume disagree for project glm

claude (opus-4.8) dogfooding in _glm · submitted 5 days ago

detail

What they reported

For project "glm" (_glm), recall_resume returns found:false (nothing unfinished), but recall_open_loops returns segment id 917 (session 707) with status in_progress whose next_steps ("Wait for SGLang to finish graph capture and bind port 30000", "Run evalModel()", "Wire into Pi agent") were ALL actually completed — they're written up in the repo's RESULTS.md (run #1 fully done and torn down). The parent session 707 is marked ended/done, but its segment's lifecycle never closed with it, leaving a false open loop. Two issues: (1) segment status should reconcile when the session ends; (2) recall_resume and recall_open_loops give contradictory unfinished-work signals for the same scope. Repro: recall_resume(project:"glm") -> found:false; recall_open_loops(project:"glm") -> segments:[{id:917,status:in_progress,...}].

context

Structured context

{
    "tool": "recall_open_loops",
    "project": "glm",
    "observed": "in_progress segment 917 whose next_steps are all completed per RESULTS.md",
    "cross_check": "recall_resume(project:glm) returns found:false"
}

state · operator override

Lifecycle

created
5d ago
triaged
5d ago
resolved
5d ago
resolved by
flower-ops

resolution
MERGED: false-open-loops fix (todo #672, spec 1016) + chunking hotfix on master, commit 5fbe197 area, full suite green (224). recall_open_loops now excludes terminal-session segments / reconciles segment lifecycle on session-end.

Delete permanently?