---
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/done/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/done/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.