project_loop_round_bug_already_fixed.md 2.43 KB

name: project-loop-round-bug-already-fixed description: The canonical self-hosting demo bug ("loop_round > 3 should be >= 3") is already fixed in src/org_loop_route.py with regression coverage, AND the REQ-05/REQ-09 explanatory comment above _LOOP_LIMIT is also already present — don't plan either as an open item without re-verifying first metadata:

type: project

As of 2026-08-02, src/org_loop_route.py:102 already reads if task["loop_round"] >= _LOOP_LIMIT: (correct), not > _LOOP_LIMIT. There is also an existing regression test covering exactly the loop_round=3 boundary: src/test_org_loop_route.py::LoopLimitTest::test_third_route_attempt_at_limit_blocks_and_raises.

As of 2026-08-03 (re-verified), the line directly above _LOOP_LIMIT = 3 (currently line 38) also already reads: # REQ-05/REQ-09 (docs/sdd/06-验收与测试锚点.md) loop_round boundary: loop_round >= _LOOP_LIMIT forces task.status -> blocked_pending_human. i.e. a follow-up request to "add a one-line clarifying comment above _LOOP_LIMIT = 3 citing REQ-05/REQ-09" is also already satisfied verbatim in substance. Two independent asks about this same three-line region of the file have both turned out to be already-done on inspection.

Why: docs/self-development-feasibility.md §"场景" uses "fix the loop_round off-by-one (loop_round > 3 should be loop_round >= 3)" as the canonical illustrative example goal for graphlemon's self-hosting/self-modification demo, and this exact string is hardcoded as the goal text in supervisor/test_self_hosting_e2e.py's RealSelfHostingClosedLoopTest (gated behind RUN_REAL_SELF_HOSTING_E2E=1, not yet executed). It reads as a live, reproducible bug on first glance, but it is a fixture/example string, not a currently-true bug report — the underlying code was written already-correct.

How to apply: If asked again to plan/fix/investigate this specific goal text (or anything that cites docs/self-development-feasibility.md's example scenario), re-verify current state of src/org_loop_route.py and src/test_org_loop_route.py first rather than assuming the bug is still open — it may have been fixed between conversations, or the request may actually be testing the planning process (e.g. via the self-hosting E2E harness) rather than asking for a real code change. Surface "already fixed, has regression coverage" as a first-class BRD finding rather than silently manufacturing a fix for a non-existent defect.