📄 补充注释规范：拒绝审计追溯标签、复述性与失效注释

AGENTS.md

@@ -45,6 +45,7 @@ These are non-negotiable and apply to every change, regardless of what `docs/dev
 - **Direct replacement over adapter sandwiches.** When swapping a backend/library, replace in place — no `interface Foo + LegacyImpl + NewImpl` unless both must coexist at runtime.
 - **Scope discipline — stay in your lane.** Bug fix ≠ cleanup PR. Touch only the files the task requires; leave unrelated files untouched (不要动和任务不相干的文件). Don't add helpers, abstractions, validation, or backwards-compat shims you don't need today. Three similar lines beats a premature abstraction.
 - **No dead code or `// removed` markers** — git remembers. Delete unused code outright.
+- **Comments explain "why", not "what".** Do not use ephemeral review labels such as `finding N` or review-round identifiers in comments or test names. Permanent issue or PR references are allowed when useful, but must supplement—not replace—the explanation. Do not restate code, duplicate enclosing documentation, or leave stale comments after code changes. See [`docs/develop.md`](docs/develop.md#comment-discipline) for the full policy.
 
 ## Architecture
 

docs/develop.md

@@ -51,6 +51,15 @@ Use strict TypeScript, React JSX runtime, 2-space indentation, semicolons, doubl
 - UI default English (global users).
 - Template literals: `${i}`, not `${i.toString()}`.
 
+### Comment Discipline
+
+A comment must tell the reader something the code cannot: an invariant, a race condition, a workaround for a specific constraint, or why something looks wrong but is correct. If deleting it would cost a future reader nothing, delete it.
+
+- **No ephemeral review labels; permanent issue/PR references are allowed when useful.** Never write review-round or audit identifiers that only made sense inside a now-gone conversation, such as `finding 5`, `round 2 fix`, or `【finding N 回归】`. A permanent issue or PR reference that is accessible to the intended maintainers can be useful, for example: `// regression test for #1234: 附件在会话删除重建后被误删`. Apply the same test to every reference: will it still help a future reader who has no memory of the conversation that added it? A relevant, accessible issue or PR usually passes; a private review label never does. In all cases, state the invariant or behavior in words first, such as `确认读失败不代表写入未落盘，只是无法证实`. The reference supplements the explanation; it does not replace it.
+- **Do not restate the next line.** A comment above code must add information the code does not already convey. Do not write `// 继续循环` above `continue;` or `// send done event` above `sendEvent({ type: "done" })`. If the comment adds no meaning beyond the code below it, delete it.
+- **Do not duplicate enclosing documentation.** If a function, class, or module doc comment already explains a behavior, do not repeat the same fact inside the implementation. State each fact once, in the place that owns it.
+- **Keep comments attached to the code they describe.** When code is moved, replaced, reordered, or deleted, move, update, or delete its comments as well. A comment that no longer describes what actually runs is worse than no comment. Check this explicitly whenever a diff changes existing code, not only when it adds new code.
+
 ## UI
 
 React 19 + shadcn/ui (Radix UI primitives, "new-york" style) + Tailwind CSS v4 + React Router. Pages in