easy-coding-harness 1.0.0-beta.0 → 1.0.0-beta.2

package/CHANGELOG.md

@@ -6,6 +6,30 @@
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 1.0.0-beta.2
+
+- 核心 Java Javadoc 规则新增接口文档继承例外：接口方法已有完整、准确且可访问的
+  Javadoc，且实现没有增加该接口方法文档未说明的契约、约束、副作用或其他实现特有行为时，
+  实现方法无需重复注释，也不为
+  满足普通门禁添加空洞的 `{@inheritDoc}`。
+- 实现包含事务、幂等、缓存、重试、异常转换、线程安全、性能限制等接口未说明的特殊行为，
+  或项目硬规则明确要求时，仍必须记录实现差异；字段、构造方法与普通方法的原有规则不变。
+- 兼容旧项目的泛化 Javadoc 规则：仅有“每个核心 Java 方法都写 Javadoc”不会覆盖本例外，
+  只有项目明确要求实现方法重复接口 Javadoc 时才覆盖；`ec-init` 生成规则时使用相同边界。
+- IMPLEMENT、QUALITY、Lite 与 Claude Code、Codex、Qoder 三平台 Agent 统一使用新语义，
+  并新增安装和 `1.0.0-beta.1` 升级回归，防止执行侧合理省略后被审查侧重新误报。
+
+## 1.0.0-beta.1
+
+- ANALYSIS 的方案展示改为持久方案回执：后续仍有工具调用时，先前文本只算可能被宿主折叠的
+  过程展示；原生选择返回或迁移调用结束后，最终消息会重新包含核心方案、验收、Workflow、
+  风险与完整 Dev-Spec 链接/路径，不再被一句确认提示覆盖。
+- Guard/Confirm 的取消、超时、空结果或无效结果继续保留 `pending_transition`，并在最终回执中
+  重现完整选择；确认成功会注明接受的分支和目标阶段。Auto 不新增确认或停顿，只把完整
+  Dev-Spec 入口带入同轮下一条持久最终消息。
+- 修复只调整 Agent 展示协议与三平台模板测试，不依赖客户端字符串匹配，不改变状态机、
+  状态 API、任务文件或审批模式语义。
+
 ## 1.0.0-beta.0
 
 - 正常修改任务统一使用 `INIT → ANALYSIS → IMPLEMENT → QUALITY → MEMORY → COMPLETE`；

package/README.md

@@ -89,7 +89,8 @@ any stage --[user abort via ec-task-close]--> CLOSED
   execution plan 实际修改的 Git root 计算，用户可在机械风险下限之上调整。
 - ANALYSIS 会先通过问答闭合影响技术路线、接口、模型、状态、范围或验收的实质性问题，
   并在 Dev-Spec 中记录唯一的 `decision_status: closed`。会话只展示核心方案、验收摘要、
-  Workflow Mode 与主要风险；完整 `dev-spec.md` 通过绝对本地链接或路径按需查看。
+  Workflow Mode 与主要风险；完整 `dev-spec.md` 通过绝对本地链接或路径按需查看。原生选择
+  返回或迁移调用结束后的最终消息会重复紧凑方案回执与完整入口，避免前置过程消息折叠后丢失。
 - Java TDD 默认关闭；优先级为 session 覆盖 > 项目配置 > `false/90%`。首次开启前必须运行 `ec-tdd-init`，只建设 JUnit/JaCoCo/GitLab 增量覆盖率基础设施，不补存量业务单测；readiness 通过后才允许显式开启。开启后在 ANALYSIS → IMPLEMENT 冻结开关、baseline 与阈值，只验收本任务新增/修改生产代码行，执行 RED/GREEN/REFACTOR（纯重构使用 characterization GREEN → GREEN），并要求本地单测通过、本地差异覆盖率达到冻结阈值。GitLab TEST-stage job 仍会生成，但远程 pipeline 结果不属于 Harness 验收证据，也不会触发中间提交推送。关闭时普通任务不扫描 CI/JaCoCo、不增加命令或提高原工作流验收深度。
 - 所有修改任务都进入 QUALITY；纯对话分析、解释、报告和只读 review 保持 Ready，不创建任务。文档或配置一旦写入仓库，仍走完整状态机。
 - `QUALITY` 同时编排只读 Review Gate 与 Verification Gate。Fast 使用主 Agent 聚焦自审和最小定向验证，Standard 使用一个独立 reviewer 与受影响检查，Strict 使用至少两个独立维度并只对实际修改仓库运行完整适用检查。两个 Gate 绑定同一候选指纹和 attempt，必须完成或明确取消后才形成一次 Repair Bundle；代码/测试缺陷回 IMPLEMENT，契约歧义优先回 ANALYSIS并保留同轮其他缺陷，环境问题留在 QUALITY 重试；候选漂移会审计为 cancelled 并强制先回 IMPLEMENT。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "1.0.0-beta.0",
+  "version": "1.0.0-beta.2",
   "description": "CLI scaffold for installing Easy Coding harness files into agent-native directories.",
   "repository": {
     "type": "git",

package/templates/claude/agents/ec-implementer.md

@@ -25,6 +25,14 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 - Every method and field in a new core Java class, and every added or materially modified method
   or field in an existing core Java class, must have meaningful multiline Javadoc; use `//` for
   ordinary one-line notes and comment complex logic where intent or constraints are not obvious.
+  An implementation method may omit repeated Javadoc only when its interface method has
+  meaningful, accurate, accessible Javadoc and it adds no implementation-specific contract,
+  constraint, side effect, or other behavior beyond that documented interface method's contract.
+  Document implementation-specific behavior and explicit project hard rules. Do not add an empty
+  `{@inheritDoc}` block solely to satisfy the normal rule. A generic project rule requiring
+  Javadoc on every core Java method does not by itself override the documented interface method
+  exception. Only an explicit project rule requiring implementation methods to repeat interface
+  Javadoc does.
 - Do not change unrelated comments, formatting, imports, names, or code. Keep one blank line
   between coherent logic sections and revert formatter spillover outside the requested scope.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.

package/templates/claude/agents/ec-reviewer.md

@@ -20,7 +20,13 @@ dimension named in your task card. Your reply IS the return value.
   cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
   layers, fragmented one-use micro-methods, constants created only for a getter return, and
   missing multiline Javadoc on any method/field in a new core Java class or any added/materially
-  modified method/field in an existing core Java class.
+  modified method/field in an existing core Java class. Do not flag an implementation method when
+  the interface method it implements has meaningful, accurate, accessible Javadoc and it adds no
+  implementation-specific contract, constraint, side effect, or other behavior beyond that
+  documented interface method's contract; require Javadoc for implementation-specific behavior
+  or an explicit project hard rule. A generic project rule requiring Javadoc on every core Java
+  method does not by itself override the documented interface method exception. Only an explicit
+  project rule requiring implementation methods to repeat interface Javadoc does.
 - Treat unrelated comment, formatting, import, naming, or refactor changes as minimum-diff
   violations. Do not ask to clean up untouched legacy code.
 - On the first pass, report the complete in-scope finding set. On a repair pass, review only the

package/templates/codex/agents/ec-implementer.toml

@@ -24,6 +24,13 @@ Hard constraints:
 - Every method and field in a new core Java class, and every added or materially modified method
   or field in an existing core Java class, must have meaningful multiline Javadoc; use // for
   ordinary one-line notes and comment complex logic where intent or constraints are not obvious.
+  An implementation method may omit repeated Javadoc only when its interface method has
+  meaningful, accurate, accessible Javadoc and it adds no implementation-specific contract,
+  constraint, side effect, or other behavior beyond that documented interface method's contract.
+  Document implementation-specific behavior and explicit project hard rules. Do not add an empty
+  {@inheritDoc} block solely to satisfy the normal rule. A generic project rule requiring Javadoc
+  on every core Java method does not by itself override the documented interface method exception.
+  Only an explicit project rule requiring implementation methods to repeat interface Javadoc does.
 - Do not change unrelated comments, formatting, imports, names, or code. Keep one blank line
   between coherent logic sections and revert formatter spillover outside the requested scope.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.

package/templates/codex/agents/ec-reviewer.toml

@@ -19,7 +19,13 @@ Stance:
   cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
   layers, fragmented one-use micro-methods, constants created only for a getter return, and
   missing multiline Javadoc on any method/field in a new core Java class or any added/materially
-  modified method/field in an existing core Java class.
+  modified method/field in an existing core Java class. Do not flag an implementation method when
+  the interface method it implements has meaningful, accurate, accessible Javadoc and it adds no
+  implementation-specific contract, constraint, side effect, or other behavior beyond that
+  documented interface method's contract; require Javadoc for implementation-specific behavior
+  or an explicit project hard rule. A generic project rule requiring Javadoc on every core Java
+  method does not by itself override the documented interface method exception. Only an explicit
+  project rule requiring implementation methods to repeat interface Javadoc does.
 - Treat unrelated comment, formatting, import, naming, or refactor changes as minimum-diff
   violations. Do not ask to clean up untouched legacy code.
 - On the first pass, report the complete in-scope finding set. On a repair pass, review only the

package/templates/common/bundled-skills/ec-init/SKILL.md

@@ -153,7 +153,10 @@ agent must be able to see what was generated and on what evidence.
      preference for single responsibility into a generic demand for many one-use helpers
    - Literal and constant conventions, including when local magic values are accepted and when
      a stable domain/config/protocol value is promoted to a named constant
-   - Javadoc/doc-comment coverage for core code and the inline-comment style used for complex logic
+   - Javadoc/doc-comment coverage for core code and the inline-comment style used for complex
+     logic. A generic project rule requiring Javadoc on every core Java method does not by itself
+     override the documented interface method exception. Only project evidence explicitly
+     requiring implementation methods to repeat interface Javadoc does
    - Import ordering and formatter/linter in use (read their configs)
    Structure as one section per language plus a General section. Every rule must be
    mechanically checkable — "be clean" is not a rule; "exported functions carry explicit

package/templates/common/skills/ec-analysis/SKILL.md

@@ -262,8 +262,8 @@ while still in ANALYSIS.
 
 ## User presentation and transition
 
-After decision closure and before the boundary, present a concise session summary instead of
-pasting the full `dev-spec.md`. The summary must contain:
+After decision closure and before the boundary, prepare a concise proposal receipt instead of
+pasting the full `dev-spec.md`. The receipt must contain:
 
 - the core solution and affected scope/units;
 - acceptance and test-strategy highlights;
@@ -278,9 +278,19 @@ copyable absolute path. Do not dump the full artifact merely because the client
 If the user asks to inspect the full plan, open or read that stored file on demand using the
 current Agent's supported file capability.
 
-Then request or auto-apply ANALYSIS -> IMPLEMENT according to `effective_approval_mode`.
-The state API atomically freezes the proposal when the transition is applied. `approval_mode`
-controls waiting; it never changes the selected execution depth.
+The proposal receipt must survive the client boundary. Assistant text emitted before a later
+tool call is only a process presentation: a host may group or collapse it, so it does not satisfy
+the durable receipt requirement. For a confirmation-required ANALYSIS -> IMPLEMENT edge, the last
+assistant response after a native choice returns or a matching transition call completes must be
+self-contained. Repeat the compact receipt and full Dev-Spec link/path even when the same content
+was visible before the tool call. If the edge remains pending, also repeat the complete choices;
+if it was confirmed, identify the accepted branch and target stage. Never reduce this response to
+only a confirmation prompt or transition result.
+
+For an automatic edge, do not add a pause or turn it into a confirmation gate. Apply the edge and
+carry the full Dev-Spec link/path into the next durable final response in the same turn. The state
+API atomically freezes the proposal when the transition is applied. `approval_mode` controls
+waiting; it never changes the selected execution depth.
 
 ## Gates
 

package/templates/common/skills/ec-implementing/SKILL.md

@@ -63,6 +63,15 @@ Communicate with the user in the user's language.
     a getter.
 12. In a newly added core Java class, every method and field requires meaningful Javadoc. In an
     existing core Java class, every added or materially modified method and field requires it.
+    An implementation method may omit its own Javadoc when the interface method it implements has
+    meaningful, accurate, accessible Javadoc and the implementation adds no implementation-specific
+    contract, constraint, side effect, or other behavior beyond that documented interface method's
+    contract. Do not add an empty `{@inheritDoc}` block solely to satisfy this normal rule. Add
+    implementation Javadoc for any implementation-specific behavior or when an explicit project
+    hard rule requires it. A generic project rule requiring Javadoc on every core Java method
+    does not by itself override the
+    documented interface method exception. Only an explicit project rule requiring implementation
+    methods to repeat interface Javadoc does.
     Add focused inline comments to core or complex logic to explain intent, constraints, or
     non-obvious tradeoffs. Do not mass-retrofit untouched legacy code, and for non-Java code
     follow the language's doc-comment form plus the evidenced project convention. Java Javadoc
@@ -136,8 +145,9 @@ checks:[], issues:[], needs_attention:[]
    hard/contract dependencies are ready; do not batch-start dependent tasks at the initial
    IMPLEMENT boundary.
    Populate `Code Comments` on every code task card with the resolved user-facing host Agent
-   author value, the field/member/constant rules, and the core Java Javadoc rule above. Populate
-   `Local Baseline` from the Unit's analyzed evidence; sub-agents do not read this Skill.
+   author value, the field/member/constant rules, and the core Java Javadoc rule above, including
+   its documented-interface exception. Populate `Local Baseline` from the Unit's analyzed
+   evidence; sub-agents do not read this Skill.
 2. Execute according to dependency order and selected owner.
 3. For non-TDD work, do not run tests; self-audit scope, contracts, TODOs, and introduced warnings.
    For TDD, run only the lifecycle commands required by RED/GREEN/REFACTOR. Also audit new author
@@ -183,5 +193,6 @@ conversation overhead while keeping work observable.
 - [ ] New author attributions use the user-facing host `<Current Agent Name> with Easy Coding`.
 - [ ] Every new model field and every non-obvious documented member follows the local comment rule.
 - [ ] Every method/field in a new core Java class, and every added or materially modified one in
-      an existing core Java class, has Javadoc.
+      an existing core Java class, has Javadoc unless it qualifies for the documented-interface
+      implementation exception.
 - [ ] The task enters QUALITY, regardless of workflow mode.

package/templates/common/skills/ec-lite/SKILL.md

@@ -63,8 +63,15 @@ For an explicit repository mutation:
    cannot be a target. Then implement only those files.
 5. If scope expands, stop, replace the proposal, and confirm again.
 6. Apply local style, core Java Javadoc, logical blank lines, and minimum modification exactly as
-   normal Easy Coding. Do not run tests by default; run only a command explicitly requested by
-   the user or mandated by a project/global hard rule.
+   normal Easy Coding. This includes the implementation exception for a documented interface method:
+   omit repeated Javadoc only when the interface method has meaningful, accurate, accessible
+   Javadoc and the implementation adds no implementation-specific contract, constraint, side
+   effect, or other behavior beyond that documented interface method's contract.
+   Document implementation-specific behavior and obey explicit project hard rules. A generic
+   project rule requiring Javadoc on every core Java method does not by itself override the
+   documented interface method exception. Only an explicit project rule requiring implementation
+   methods to repeat interface Javadoc does. Do not run tests by default; run only a command
+   explicitly requested by the user or mandated by a project/global hard rule.
 7. Report changed files and any command actually run, then call
    `complete-lite-proposal --digest <digest>`. Completion fails if no confirmed target changed,
    another file changed after confirmation, or Git HEAD moved. Re-present the proposal rather

package/templates/common/skills/ec-quality/SKILL.md

@@ -59,6 +59,16 @@ Review only the confirmed diff and its direct interactions. Check acceptance beh
 compatibility, security/correctness, test design, nearest local style, required core Java
 Javadoc, logical blank-line grouping, and minimum modification.
 
+Do not report missing Javadoc on an implementation method when its interface method has
+meaningful, accurate, accessible Javadoc and the implementation adds no implementation-specific
+contract, constraint, side effect, or other behavior beyond that documented interface method's
+contract. Require implementation Javadoc for implementation-specific behavior or when an explicit
+project hard rule requires it.
+
+A generic project rule requiring Javadoc on every core Java method does not by itself override the
+documented interface method exception. Only an explicit project rule requiring implementation
+methods to repeat interface Javadoc does.
+
 Do not demand defensive null checks, constant extraction, abstractions, method splitting,
 comments, formatting, or cleanup solely as generic best practice. Do not report unrelated legacy
 issues as task findings. The first review must report the complete in-scope finding set; after a

package/templates/common/skills/ec-workflow/SKILL.md

@@ -167,9 +167,18 @@ choice set before invoking the platform's native choice UI:
 Preserve `pending_transition` on cancellation, timeout, or invalid UI output. A later ordinary
 reply may consume it. Use `confirm-transition` only for a matching stored edge.
 
+Text emitted before a later tool call is a non-durable process presentation because the host may
+group or collapse it. For ANALYSIS -> IMPLEMENT, preserve the compact proposal receipt produced by
+`ec-analysis`. After a native choice returns or a matching transition call completes, the last
+assistant response in that turn must repeat the receipt and full Dev-Spec link/path even if they
+were already visible. When the edge remains pending, include the complete numbered fallback;
+when confirmed, name the accepted branch and target stage. An empty, cancelled, timed-out, or
+invalid native result is not grounds to omit this final receipt.
+
 Use `auto-transition` only when the state API says the edge is automatic. Mechanical gates
 (analysis artifacts and proposal, review fingerprint, verification fingerprint, memory
-completion) apply in every approval mode.
+completion) apply in every approval mode. An automatic ANALYSIS -> IMPLEMENT edge must not pause;
+carry its full Dev-Spec link/path into the next durable final response in the same turn.
 
 `[easy-coding:acceptance-drift-confirmation-required]` is a narrow exception to automatic-edge
 handling. Call `inspect-transition-drift`, present every returned patch/binary/mode change and the

package/templates/main-constraint/AGENTS.md.tpl

@@ -72,10 +72,15 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   explicitly guarantees an indefinite wait; disable or omit automatic timeout/resolution in that
   case. Otherwise pre-render the matching numbered fallback before invoking native choice once,
   so timeout cannot remove the user's path forward. Empty, dismissed, timed-out, or unparseable
-  native results preserve the pending edge; show the fallback when control returns only if it is
-  not already visible, and never retry native choice in that turn. On resume, consume a matching
+  native results preserve the pending edge; never retry native choice in that turn. On resume,
+  consume a matching
   numbered reply against the stored edge before re-presenting the gate. Never degrade to only
-  "reply confirm".
+  "reply confirm". Text shown before a later tool call is non-durable because the
+  host may group or collapse it. For ANALYSIS -> IMPLEMENT, the last assistant response after a
+  native choice or transition call must repeat a compact core-solution, acceptance, workflow,
+  and risk receipt plus the full Dev-Spec link/path, even if already visible. Repeat the complete
+  fallback while the edge is pending; after confirmation, identify the accepted branch and target
+  stage. Auto adds no pause and carries the Dev-Spec link/path into the next durable final response.
 - When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
   only Easy Coding workflow/stage orchestration for this session. Continue honoring every
   non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
@@ -89,9 +94,10 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   each confirmed answer and its evidence in `### 决策闭环`. Only after all material decisions are
   resolved may the agent set the single `decision_status: closed`, finalize the artifacts, and
   propose IMPLEMENT. The session presentation is a concise core-solution, acceptance, workflow,
-  and risk summary with an absolute local link/path to the full dev-spec.md; never paste the full
-  artifact by default. The final artifact contains neither `[阶段：ANALYSIS]` nor a
-  `待用户决策` section.
+  and risk receipt with an absolute local link/path to the full dev-spec.md; repeat that durable
+  receipt after a later native choice or transition call instead of relying on collapsible process
+  text; never paste the full artifact by default. The final artifact contains neither
+  `[阶段：ANALYSIS]` nor a `待用户决策` section.
 - QUALITY contains fingerprinted Review and Verification Gates. Review evidence must match the final
   implementation; verification evidence must match final implementation and config. The frozen
   workflow mode selects targeted, impacted, or full commands without weakening the green gate.

package/templates/main-constraint/CLAUDE.md.tpl

@@ -70,10 +70,15 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   explicitly guarantees an indefinite wait; disable or omit automatic timeout/resolution in that
   case. Otherwise pre-render the matching numbered fallback before invoking native choice once,
   so timeout cannot remove the user's path forward. Empty, dismissed, timed-out, or unparseable
-  native results preserve the pending edge; show the fallback when control returns only if it is
-  not already visible, and never retry native choice in that turn. On resume, consume a matching
+  native results preserve the pending edge; never retry native choice in that turn. On resume,
+  consume a matching
   numbered reply against the stored edge before re-presenting the gate. Never degrade to only
-  "reply confirm".
+  "reply confirm". Text shown before a later tool call is non-durable because the
+  host may group or collapse it. For ANALYSIS -> IMPLEMENT, the last assistant response after a
+  native choice or transition call must repeat a compact core-solution, acceptance, workflow,
+  and risk receipt plus the full Dev-Spec link/path, even if already visible. Repeat the complete
+  fallback while the edge is pending; after confirmation, identify the accepted branch and target
+  stage. Auto adds no pause and carries the Dev-Spec link/path into the next durable final response.
 - When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
   only Easy Coding workflow/stage orchestration for this session. Continue honoring every
   non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
@@ -87,9 +92,10 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   each confirmed answer and its evidence in `### 决策闭环`. Only after all material decisions are
   resolved may the agent set the single `decision_status: closed`, finalize the artifacts, and
   propose IMPLEMENT. The session presentation is a concise core-solution, acceptance, workflow,
-  and risk summary with an absolute local link/path to the full dev-spec.md; never paste the full
-  artifact by default. The final artifact contains neither `[阶段：ANALYSIS]` nor a
-  `待用户决策` section.
+  and risk receipt with an absolute local link/path to the full dev-spec.md; repeat that durable
+  receipt after a later native choice or transition call instead of relying on collapsible process
+  text; never paste the full artifact by default. The final artifact contains neither
+  `[阶段：ANALYSIS]` nor a `待用户决策` section.
 - QUALITY contains fingerprinted Review and Verification Gates. Review evidence must match the final
   implementation; verification evidence must match final implementation and config. The frozen
   workflow mode selects targeted, impacted, or full commands without weakening the green gate.

package/templates/qoder/agents/ec-implementer.md

@@ -27,6 +27,14 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 - Every method and field in a new core Java class, and every added or materially modified method
   or field in an existing core Java class, must have meaningful multiline Javadoc; use `//` for
   ordinary one-line notes and comment complex logic where intent or constraints are not obvious.
+  An implementation method may omit repeated Javadoc only when its interface method has
+  meaningful, accurate, accessible Javadoc and it adds no implementation-specific contract,
+  constraint, side effect, or other behavior beyond that documented interface method's contract.
+  Document implementation-specific behavior and explicit project hard rules. Do not add an empty
+  `{@inheritDoc}` block solely to satisfy the normal rule. A generic project rule requiring
+  Javadoc on every core Java method does not by itself override the documented interface method
+  exception. Only an explicit project rule requiring implementation methods to repeat interface
+  Javadoc does.
 - Do not change unrelated comments, formatting, imports, names, or code. Keep one blank line
   between coherent logic sections and revert formatter spillover outside the requested scope.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.

package/templates/qoder/agents/ec-reviewer.md

@@ -22,7 +22,13 @@ dimension named in your task card. Your reply IS the return value.
   cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
   layers, fragmented one-use micro-methods, constants created only for a getter return, and
   missing multiline Javadoc on any method/field in a new core Java class or any added/materially
-  modified method/field in an existing core Java class.
+  modified method/field in an existing core Java class. Do not flag an implementation method when
+  the interface method it implements has meaningful, accurate, accessible Javadoc and it adds no
+  implementation-specific contract, constraint, side effect, or other behavior beyond that
+  documented interface method's contract; require Javadoc for implementation-specific behavior
+  or an explicit project hard rule. A generic project rule requiring Javadoc on every core Java
+  method does not by itself override the documented interface method exception. Only an explicit
+  project rule requiring implementation methods to repeat interface Javadoc does.
 - Treat unrelated comment, formatting, import, naming, or refactor changes as minimum-diff
   violations. Do not ask to clean up untouched legacy code.
 - On the first pass, report the complete in-scope finding set. On a repair pass, review only the