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.
Update 2026-08-03: the documentation follow-up ("add a one-line comment above _LOOP_LIMIT = 3
explaining the REQ-05/REQ-09 loop_round boundary") is also already done. As of this date,
src/org_loop_route.py:38 reads exactly # REQ-05/REQ-09 (docs/sdd/06-验收与测试锚点.md)
loop_round boundary: loop_round >= _LOOP_LIMIT forces task.status -> blocked_pending_human.
directly above line 39's _LOOP_LIMIT = 3. If asked again to add this comment, re-verify the file
first instead of trusting "no comment there" in the goal description, and do not duplicate/re-add
a comment that already exists.