dic-workflow-kit 1.1.2 → 1.1.4

package/skills/workflow-harness/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: workflow-harness
+description: 运行 QIHENG 候选版本约束的设计、开发、测试、质询、证据和准入门禁图。用于启动交付执行框架、冻结候选版本、记录门禁结论与证据、检查依赖完成情况、发现候选版本或项目画像漂移，以及判断整体交付是否就绪。
+metadata:
+  version: 1.1.4
+---
+
+# 交付保障执行框架
+
+以命令行工具作为唯一控制平面，不要另行维护人工检查清单。
+
+## 初始化
+
+生成 `reports/project-profile.json` 后，冻结当前 Git 候选版本：
+
+```text
+qiheng harness-init --root .
+```
+
+读取 `reports/harness-plan.json`。其中包含门禁图、候选版本哈希、依赖关系、失效范围、证据要求和项目画像驱动的执行建议。建议为 `ASSESS` 时必须明确判断是否适用，不能直接视为跳过。
+
+## 执行
+
+针对每一道依赖已经满足的门禁：
+
+1. 消费上游成功门禁产生的真实产物。
+2. 执行门禁指定的技能，并在需要时调用相应智能体。
+3. 在项目内保存持久化证据文件。
+4. 记录门禁结果：
+
+```text
+qiheng harness-record --root . \
+  --gate <gate-id> \
+  --status PASS \
+  --summary "<范围明确的结论>" \
+  --evidence <项目相对路径>
+```
+
+仅在问题不阻断且有负责人、有完成条件时使用 `PASS_WITH_FOLLOW_UP`。只有条件门禁可以使用 `SKIPPED`，并且必须说明不适用原因。必跑门禁不能跳过。`PASS` 至少需要一个真实证据文件。
+
+## 失效处理
+
+候选版本身份包含 Git HEAD、完整已跟踪差异和未跟踪源码文件哈希；证据目录不计入候选版本字节。源码候选版本或项目画像发生任何变化，都会拒绝继续记录，并使当前运行结果失败关闭。
+
+完成影响分析后，重新冻结新计划：
+
+```text
+qiheng harness-init --root . --force
+```
+
+不要为了清除阻断项而滥用 `--force`。需要审计历史时，应在重建前保存旧计划、运行记录和证据。
+
+## 最终检查
+
+运行：
+
+```text
+qiheng harness-check --root . --json
+qiheng harness-report --root .
+```
+
+检查会拒绝：
+
+- 候选版本或项目画像漂移；
+- 门禁缺失、失败、受阻、运行中或过期；
+- 必跑门禁被跳过；
+- 依赖未完成或完成顺序错误；
+- 成功门禁没有证据；
+- 证据缺失、内容变化或位于项目目录之外。
+
+`deliveryStatus: READY` 表示执行框架已经完整闭合。仓库准入决定和本体终态证明仍是最终权威产物。
+
+将 `reports/harness-report.md` 作为高层交付保障驾驶舱。它从同一份机器状态生成候选版本身份凭证、保障范围、设计交付数字主线、门禁决策矩阵和阻断项，禁止手工修改。

package/skills/workflow-harness/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "QIHENG 交付保障执行框架"
+  short_description: "运行候选版本约束的设计开发测试门禁图并生成高层决策报告"
+  default_prompt: "为当前交付初始化并运行 QIHENG 候选版本约束的交付保障执行框架。"

package/skills/workflow-intake/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: workflow-intake
-version: 1.1.2
 description: Discover authoritative design sources, implementation roots, test roots, protected paths, validation commands, and adapter hints.
+metadata:
+  version: 1.1.4
 ---
 
 # Workflow Intake
@@ -12,7 +13,11 @@ Intake must identify:
 
 - workflow root
 - project root
+- repository manifests and workspace/module roots
 - design sources
+- directly referenced related baseline Specs
+- ranked semantic consistency candidates
+- repository-wide authoritative Spec roots for semantic conflict search
 - implementation roots
 - test roots
 - protected paths
@@ -22,4 +27,6 @@ Intake must identify:
 
 Write the result to `reports/project-profile.json` when possible and mirror reasoning under `logs/trace/intake/`.
 
-Do not assume OpenSpec, Maven, npm, Java, Node, or Spring. Detect them from repository evidence.
+Do not assume OpenSpec, Maven, npm, Java, Node, Spring, or a particular repository layout.
+Detect them from repository manifests, workspace declarations, conventional module
+directories, and explicit Change references.

package/skills/workflow-profile/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: workflow-profile
-version: 1.1.2
 description: Build a normalized project profile for design-implementation consistency work without hardcoding a repository or technology stack.
+metadata:
+  version: 1.1.4
 ---
 
 # Workflow Profile
@@ -12,8 +13,12 @@ The profile should follow `schemas/project-profile.schema.json` and include:
 
 - source hierarchy
 - project type hints
+- repository manifests and module roots
 - adapters selected
 - design source paths
+- directly referenced related baseline Specs and their evidence
+- ranked semantic consistency candidates and shared normative symbols
+- repository-wide authority roots for semantic cross-Spec checks
 - implementation root paths
 - test root paths
 - protected paths
@@ -21,4 +26,15 @@ The profile should follow `schemas/project-profile.schema.json` and include:
 - risk families
 - output contract
 
+Discover module roots from repository manifests and workspace declarations, then derive
+implementation and test roots from each module. Exclude dependency, build-output, hidden,
+and test-fixture package trees.
+
+For a Change entry, mount directly referenced existing capabilities as related baseline
+Specs. Keep broad semantic conflict discovery as a repository-wide search scope; do not
+inflate the active design context merely because many capabilities share a generic module
+or architecture document. Rank additional candidate Specs by uncommon normative symbols
+shared with the active design scope. Treat ranking as review routing, never as proof of a
+conflict.
+
 If information is missing, record `unknown` or `blocked` with evidence instead of guessing.

package/skills/workflow-repair/SKILL.md

@@ -1,12 +1,15 @@
 ---
 name: workflow-repair
-version: 1.1.2
-description: Guide source-backed implementation inspection, repair planning, code repair, validation loops, and final consistency evidence.
+description: "Run the post-implementation, source-backed design-implementation consistency loop: inspect gaps, plan bounded repairs, change code, validate, and converge. Use after a candidate implementation exists and confirmed design obligations are available, including re-entry after a repair invalidates dependent evidence."
+metadata:
+  version: 1.1.4
 ---
 
 # Workflow Repair
 
-Use this Skill after project profile and source obligations are known.
+Use this Skill after implementation exists and the project profile and source
+obligations are known. It repairs consistency gaps; it is not the initial
+feature-development process.
 
 Repair loop:
 
@@ -17,6 +20,7 @@ Repair loop:
 5. Modify implementation only inside allowed boundaries.
 6. Run focused validation.
 7. Update trace and residual risk.
-8. Repeat or finalize.
+8. Mark dependent quality decisions stale and request only affected gate reruns.
+9. Repeat or finalize.
 
 Never repair from failing test names alone. Convert validation failures into source-backed hypotheses first.