easy-coding-harness 1.0.0-beta.1 → 1.0.0

package/CHANGELOG.md

@@ -6,6 +6,30 @@
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 1.0.0
+
+- 首个正式版本，固化统一的 `INIT → ANALYSIS → IMPLEMENT → QUALITY → MEMORY → COMPLETE`
+  状态机；Fast、Standard、Strict 共享状态图，仅按任务复杂度和风险调整执行深度。
+- 正式提供 Canonical Spec 精确消费、持久分析方案回执、双门 QUALITY、`ec-lite` 极简模式、
+  会话清理与用户验收后差异接受等完整能力，并保持 Claude Code、Codex、Qoder 三端一致。
+- 稳定编码约束：遵循最近邻代码风格和最小修改，避免过度设计、冗余校验、碎片方法与无意义
+  常量；接口方法已有完整文档且实现无额外语义时，不重复编写实现方法 Javadoc。
+- 正式版由 `1.0.0-beta.2` 晋升，不新增破坏性变更；默认安装命令将通过 npm `latest` 获取
+  `1.0.0`，预发布用户可直接升级。
+
+## 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 的方案展示改为持久方案回执：后续仍有工具调用时，先前文本只算可能被宿主折叠的

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "1.0.0-beta.1",
+  "version": "1.0.0",
   "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-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/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