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 — don't plan it as an open defect 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.
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.