coding-agent-harness 1.0.2 → 1.0.5

package/templates/ssot/Feature-SSoT.md

@@ -1,43 +0,0 @@
-# Feature SSoT
-
-## Purpose
-
-Maintain the authoritative feature queue for agent-executed work. This file answers what is planned, who owns it, what evidence is required, and whether the work is safe to close.
-
-## Status Legend
-
-| Status | Meaning | Required Next Step |
-| --- | --- | --- |
-| intake | Candidate feature is captured but not shaped. | Clarify goal, owner, and acceptance evidence. |
-| ready | Scope and acceptance criteria are clear. | Create or link the task plan. |
-| active | Implementation or review is in progress. | Keep plan, evidence, and residuals current. |
-| blocked | Feature cannot proceed. | Record blocker owner and unblock condition. |
-| verify | Work is implemented and waiting for evidence. | Run required checks and update Regression SSoT. |
-| shipped | Feature is delivered and walkthrough is complete. | Keep row until no longer operationally relevant. |
-| archived | Feature is historical. | Keep archive pointer and final evidence link. |
-
-## Active Features
-
-| ID | Feature | User Outcome | Owner | Status | Priority | Task Plan | Acceptance Evidence | Regression Gate | Walkthrough | Residual | Updated |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| F-000 | Short feature title | Observable user or operator result | owner | ready | P1 | docs/09-PLANNING/TASKS/.../task_plan.md | command, test, screenshot, or review path | RG-000 | pending | none | YYYY-MM-DD |
-
-## Intake Queue
-
-| Candidate | Source | Decision Needed | Owner | Due |
-| --- | --- | --- | --- | --- |
-| Short request title | issue, roadmap, user request, or review | accept, split, defer, or reject | owner | YYYY-MM-DD |
-
-## Routing Rules
-
-1. Add a feature row before implementation starts unless the task is a documented emergency fix.
-2. Use one row per deliverable outcome, not one row per commit.
-3. Link the task plan before moving a feature to `active`.
-4. Link regression evidence before moving a feature to `shipped`.
-5. Record `accepted-risk` explicitly; `none` means no known residual risk after verification.
-
-## Archive Rules
-
-- Keep shipped rows visible through the next release or verification cycle.
-- Move older shipped rows to the project archive with their final walkthrough and regression evidence.
-- Do not archive blocked rows until the blocker is resolved, accepted, or explicitly abandoned.

package/templates/ssot/Lessons-SSoT.md

@@ -1,44 +0,0 @@
-# Lessons SSoT
-
-## Purpose
-
-Track reusable lessons discovered during closeout and route them into standards, templates, checkers, or explicit no-action decisions.
-
-## Status Legend
-
-| Status | Meaning | Required Next Step |
-| --- | --- | --- |
-| candidate | Lesson was proposed during review or walkthrough. | Decide whether it is reusable. |
-| accepted | Lesson is valid and needs a durable change. | Assign implementation target and owner. |
-| applied | Durable change has landed. | Link changed file, checker, or template. |
-| rejected | Lesson is not reusable or not worth adopting. | Record reason. |
-| superseded | A newer lesson replaces this one. | Link replacement. |
-| archived | Lesson is historical. | Keep detail doc and final disposition. |
-
-## Active Lessons
-
-| ID | Lesson | Source | Type | Owner | Status | Target Change | Detail Doc | Evidence | Updated |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| L-YYYY-MM-DD-001 | Short lesson title | walkthrough, review, incident, or verifier | ref-change / new-doc / arch-process-change | owner | candidate | file, checker, template, or no-action | docs/01-GOVERNANCE/lessons/...md | source link | YYYY-MM-DD |
-
-## Type Routing
-
-| Type | Use When | Required Artifact |
-| --- | --- | --- |
-| ref-change | Existing standard, template, or checker needs an update. | `templates/lessons/lesson-ref-change.md` detail doc. |
-| new-doc | A missing durable reference document is needed. | `templates/lessons/lesson-new-doc.md` detail doc. |
-| arch-process-change | Operating model, phase gate, ownership, or architecture process needs to change. | `templates/lessons/lesson-arch-process-change.md` detail doc. |
-
-## Routing Rules
-
-1. Walkthrough closeout must record whether a lessons check was performed.
-2. Do not create a lesson for one-off trivia; create one only when a future agent could repeat the failure or benefit from the rule.
-3. Accepted lessons must name the durable target: reference doc, template, checker, workflow, or operating model.
-4. `applied` requires evidence of the durable change, not just agreement in chat.
-5. Rejected lessons must explain why no durable change is needed.
-
-## Archive Rules
-
-- Keep candidate and accepted lessons in this file until resolved.
-- Archive applied, rejected, or superseded lessons after the next closeout cycle.
-- Preserve the detail doc and source walkthrough link for every archived lesson.

package/templates-zh-CN/ssot/Feature-SSoT.md

@@ -1,49 +0,0 @@
-# 功能 SSoT - [项目名称]
-
-> 功能、wave、用户可见改动和实现残余的单一事实源。开始非平凡功能前先读本文件，收口后必须回写。
-
-## 使用约定
-
-- 只记录当前仍需要决策、执行、验证或追踪的功能项。
-- 每个条目必须能指向任务计划、分支或 worktree、验证证据和残余负责人。
-- 不在这里记录逐行 diff；实现细节写在任务计划、review、walkthrough 或 PR 中。
-
-## 活跃功能
-
-| 功能 ID | 功能 / Wave | 负责人 | 状态 | 任务计划 | 分支 / Worktree | 验收依据 | 残余路由 | 更新时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| F-001 | [功能名称] | [负责人] | planned | `docs/09-PLANNING/TASKS/[task]/task_plan.md` | `[branch 或 worktree]` | [验收标准、Regression Gate 或证据路径] | `none` / [负责人 + 后续动作] | YYYY-MM-DD |
-
-## 已完成索引
-
-> 完成项只保留最近一批，便于冷启动。超过 20 行、release 收束或模块并行切换时，移入 `docs/09-PLANNING/_archive/Feature-SSoT-archive-YYYY-QN.md`。
-
-| 功能 ID | 功能 / Wave | 完成日期 | 收口记录 | 关联 Harness ID |
-| --- | --- | --- | --- | --- |
-| F-001 | [功能名称] | YYYY-MM-DD | `docs/10-WALKTHROUGH/[file].md` | HL-YYYY-MM-DD-001 |
-
-## 归档索引
-
-| 归档文件 | 覆盖范围 | 移入日期 | 说明 |
-| --- | --- | --- | --- |
-| `docs/09-PLANNING/_archive/Feature-SSoT-archive-YYYY-QN.md` | F-... 至 F-... | YYYY-MM-DD | [说明] |
-
-## 状态说明
-
-- `planned`：已确认进入计划，但尚未开始实现。
-- `in-progress`：正在实现或验证。
-- `blocked`：被依赖、决策、权限、环境或失败回归阻塞；残余路由必须写清。
-- `ready-for-review`：实现完成，等待审查或验证。
-- `ready-for-release`：审查和回归完成，等待合并、发布或上线。
-- `completed`：已完成并收口，保留索引用于追溯。
-- `paused`：暂缓推进，保留负责人和恢复条件。
-- `cancelled`：明确取消，说明原因和替代方案。
-- `superseded`：被其他功能项取代，必须指向新功能 ID。
-
-## 路由规则
-
-1. 新功能进入实现前，必须有任务计划或明确的轻量豁免原因。
-2. 状态进入 `completed` 前，必须有验证证据、残余路由和 closeout 记录。
-3. 回归失败或覆盖面变化写入 Regression SSoT，不只写在本表备注里。
-4. 可复用流程经验写入 Lessons SSoT，不在本表长篇展开。
-5. 多人并行时，只由功能负责人或协调者更新状态字段。

package/templates-zh-CN/ssot/Lessons-SSoT.md

@@ -1,49 +0,0 @@
-# 经验沉淀 SSoT - [项目名称]
-
-> 可复用经验、流程修正和 reference 改动建议的单一事实源。这里管理 lesson 生命周期，详情必须写在独立文档中。
-
-## 使用约定
-
-- 写新 lesson 前，先完整阅读本表，确认是否已有相同或冲突建议。
-- 表行不能单独存在；每条活跃 lesson 都必须有 `docs/01-GOVERNANCE/lessons/` 下的详情文档。
-- lesson 只记录可复用的机制性改进，不记录一次性 bug、个人偏好或聊天摘要。
-- 人批准前，pending lesson 不能被当成正式流程规则使用。
-
-## 活跃 Lessons
-
-| Lesson ID | 日期 | 来源 | 类型 | 目标 | 摘要 | 详情文档 | 状态 | 冲突 / 关联 |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| L-YYYY-MM-DD-001 | YYYY-MM-DD | `docs/10-WALKTHROUGH/[file].md` | ref-change | `docs/11-REFERENCE/[target].md` | [一句话摘要] | `docs/01-GOVERNANCE/lessons/L-YYYY-MM-DD-001-[slug].md` | pending | `none` / L-... |
-
-## 已归档 Lessons
-
-> 状态为 `merged`、`rejected`、`superseded` 的条目在阶段收口后移入 `docs/01-GOVERNANCE/_archive/Lessons-SSoT-archive-YYYY-QN.md`，本节保留索引。
-
-| Lesson ID | 日期 | 处理结果 | 处理日期 | 归档文件 |
-| --- | --- | --- | --- | --- |
-| L-YYYY-MM-DD-001 | YYYY-MM-DD | merged / rejected / superseded | YYYY-MM-DD | `docs/01-GOVERNANCE/_archive/Lessons-SSoT-archive-YYYY-QN.md` |
-
-## 状态说明
-
-- `pending`：Agent 提出建议，等待人审查。
-- `approved`：已批准，等待合入正式 reference、template 或 checker。
-- `merged`：已合入正式文件，并有 commit 或变更证据。
-- `rejected`：明确不采纳，保留原因。
-- `superseded`：被后续 lesson 取代，必须指向新 Lesson ID。
-- `needs-rework`：方向可能成立，但详情文档需要补充或重写。
-
-## 类型说明
-
-- `ref-change`：修改现有 reference、标准或规则文档。
-- `new-doc`：新增 reference、模板、检查器说明或治理文档。
-- `arch-change`：架构、模块边界、仓库结构或系统职责变化。
-- `process-change`：任务流程、审查流程、回归节奏或 closeout 规则变化。
-
-## 路由规则
-
-1. 先写详情文档，再追加本表行；不要先占表行。
-2. `详情文档` 字段必须是路径，不能写摘要。
-3. `ref-change` 的详情文档必须包含基于当前正式文件的完整副本或明确 diff。
-4. 多个 pending lesson 指向同一目标时，必须在“冲突 / 关联”中互相标记。
-5. `merged` 后必须更新目标正式文件，并在详情文档或本表记录证据。
-6. closeout 中的 Lessons 检查必须能追溯到本表行，或写明 `checked-none` 原因。