---
name: project-scheduler-busy-timeout-comment-missing
description: src/scheduler.py's _BUSY_TIMEOUT_MS constant has no comment directly above it as of 2026-08-03; the rationale only lives in the module docstring, far above the constant.
metadata:
  type: project
---

As of 2026-08-03, `src/scheduler.py` line 78 (`_BUSY_TIMEOUT_MS = 30000`) has no comment
directly above it. The rationale for the 30s value ("concurrent sqlite writers on the shared
db file should retry instead of raising 'database is locked'") exists only inside the module
docstring (lines 21-28), not adjacent to the constant itself.

**Why:** A user/orchestrator request asked to verify this and, if missing, add exactly one
inline comment line above the constant. This is a source-code edit, which falls outside the
Planning Agent role (SOUL.md: "不写业务代码，不替 Code Agent 实现"). Response was to write a
BRD documenting the gap as a one-line Development Unit for a Code Agent to implement, rather
than editing `src/scheduler.py` directly — even though the change is trivial.

**How to apply:** If asked again to "check for X comment/fix and edit if missing" as part of a
"write a BRD" request, do the read-only investigation, report the fact, and package any actual
code change as a requirement/acceptance criterion for Code Agent — do not perform the Edit
myself. This mirrors [[project_loop_round_bug_already_fixed]]'s pattern of quick verification
asks embedded in planning requests; the difference here is the fact was "not yet fixed" rather
than "already fixed," so the correct BRD is a genuine (if tiny) actionable requirement instead
of a no-op report.