dic-workflow-kit 1.1.3 → 1.1.4

package/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dic-workflow-kit",
-  "version": "1.1.3",
-  "description": "Design-implementation consistency workflow with OpenSpec obligations, BDD knowledge, Skills, and Subagents.",
+  "version": "1.1.4",
+  "description": "QIHENG 候选版本约束的设计、开发、测试、证据与准入交付保障执行框架。",
   "author": {
     "name": "TonyClaw"
   },
@@ -16,21 +16,25 @@
   ],
   "skills": "./skills/",
   "interface": {
-    "displayName": "DIC Workflow Kit",
-    "shortDescription": "Design-to-code consistency workflow",
-    "longDescription": "Auditable OpenSpec intake, obligation extraction, implementation inspection, repair planning, validation, Skills, and bounded Subagent handoffs.",
+    "displayName": "契衡 QIHENG",
+    "shortDescription": "候选版本约束的交付保障执行框架",
+    "longDescription": "冻结密码学候选版本身份，执行设计到交付门禁图，修复设计与实现不一致，审计证据完整性，并通过高层交付保障驾驶舱展示仓库准入结论。",
     "developerName": "TonyClaw",
     "category": "Developer Tools",
     "capabilities": [
       "Read",
       "Write",
-      "Validation",
-      "Subagents"
+      "验证",
+      "质量评审",
+      "交付保障",
+      "子智能体"
     ],
     "defaultPrompt": [
-      "Check this OpenSpec change against implementation and tests.",
-      "Build an obligation matrix for this design change.",
-      "Repair design-to-code inconsistencies with evidence."
+      "检查当前 OpenSpec 变更与实现和测试是否一致。",
+      "为当前设计变更建立实现义务矩阵。",
+      "依据证据修复设计与代码不一致问题。",
+      "执行并重跑受影响的质量门禁，然后决定提交前准入。",
+      "为当前候选版本生成 QIHENG 高层交付保障驾驶舱。"
     ],
     "brandColor": "#C7000B"
   }

package/CHANGELOG.md

@@ -1,11 +1,66 @@
 # Changelog
 
-All notable changes to DIC Workflow Kit are documented in this file.
+All notable changes to QIHENG are documented in this file.
 
 The project follows [Semantic Versioning](https://semver.org/). Both npm packages, `dic-workflow-kit` and `@tonyclaw/dic-workflow-kit`, always use the same version and runtime payload.
 
 ## [Unreleased]
 
+## [1.1.4] - 2026-07-28
+
+### Added
+
+- Added an executable candidate-bound Delivery Assurance Harness with
+  `harness-init`, `harness-record`, `harness-check`, and `harness-report`.
+- Added cryptographic candidate passports over Git HEAD, tracked binary diff,
+  untracked source hashes, and the project-profile hash.
+- Added a 12-gate core design-to-delivery graph spanning authority, Spec,
+  architecture, CI planning, DIC convergence, code, developer test,
+  adversarial challenge, evidence audit, verification, and admission, plus
+  profile-driven security, performance, reliability, concurrency,
+  data-integrity, migration, and compatibility overlay gates.
+- Added an executive Assurance Cockpit with coverage, blockers, Candidate
+  Passport, Digital Thread visualization, and gate decision matrix.
+- Added the `workflow-harness` Skill plus machine schemas for Harness Plans and
+  Runs.
+- Introduced the public brand **契衡 QIHENG**, positioned as a Design Integrity
+  Control Plane with the promise “Every design promise, proven in code.”
+- Added the preferred `qiheng` CLI while retaining `dic-workflow-kit` as a
+  backward-compatible command, npm distribution name, and plugin identity.
+- Added profile-driven semantic consistency candidate ranking, the
+  `semantic-conflict-auditor` and `impact-analyst` Subagents, and the
+  `quality-cross-spec-consistency` and `knowledge-change-impact` Skills.
+- Added seven risk-selective delivery quality Skills for specification, SR/AR, code, developer-test, CI, repository-admission, and unified quality review.
+- Added candidate-bound governance objects (`Candidate`, `GateRun`, `Claim`,
+  `Challenge`, `Counterexample`, `Waiver`, and `Policy`), typed relations,
+  authorized Actions, and fail-closed PASS invariants.
+- Added the read-only `adversarial-challenger` and `evidence-auditor` Subagents
+  with risk-selective adversarial challenge and mandatory terminal evidence
+  audit Skills.
+
+### Changed
+
+- Localized the Chinese README, plugin interface, command help, runtime errors,
+  Harness Skill, and generated executive report with concise Chinese terms
+  while preserving machine-facing commands, identifiers, and status codes.
+- Made the version synchronization script tolerate READMEs that do not expose
+  maintainer-only release command examples.
+- Reorganized both READMEs around the ontology-governed evidence chain, a three-minute quick start, and task-oriented documentation navigation.
+- Moved maintainer-only dual npm release procedures into `docs/RELEASING.md`.
+- Reframed quality orchestration as a candidate-bound gate graph: imported
+  Spec clearance, implementation, post-implementation DIC repair, affected-gate
+  reruns, and pre-commit admission.
+- Added explicit gate invalidation and repeatability semantics so a changed
+  Spec, architecture, implementation, test, pipeline, or candidate cannot reuse
+  stale decisions.
+- Distinguished DIC consistency, specialist quality, and repository admission,
+  with applicability, run history, invalidation reasons, and current evidence
+  retained under `reports/quality/`.
+- Removed named-project branches from reusable Quality Skills; repository-local
+  policy is now discovered through the project profile and repository evidence.
+- Organized roles into Lens, Forge, and Tribunal evidence responsibilities;
+  orchestration selects a minimal panel rather than maximizing Agent count.
+
 ## [1.1.3] - 2026-07-28
 
 ### Added

package/INSTRUCTION.md

@@ -1,4 +1,8 @@
-# Design-Implementation Consistency Workflow
+# QIHENG Design Integrity Workflow
+
+QIHENG (契衡) is the Design Integrity Control Plane: every design promise,
+proven in code. DIC remains the technical consistency protocol used by the
+workflow.
 
 Use this workflow when a Coding Agent must check or repair whether implementation matches design intent.
 
@@ -47,18 +51,18 @@ Agents may only perform actions within their role:
 - planners propose repair actions without editing code
 - repairers execute approved, path-bounded actions
 - validators attach validation and evidence objects
-- final reviewers evaluate invariants and transition final status
+- final reviewers evaluate DIC invariants and transition consistency status
 
 Before executing or recording a mutation, validate it with the installed runtime:
 
 ```text
-dic-workflow-kit action-check --root <project> --action <action.json>
-dic-workflow-kit action-record --root <project> --action <action.json>
-dic-workflow-kit ontology-reconcile --root <project>
-dic-workflow-kit ontology-ledger-check --root <project>
-dic-workflow-kit ontology-evidence-check --root <project>
-dic-workflow-kit ontology-validation-check --root <project>
-dic-workflow-kit ontology-implementation-check --root <project>
+qiheng action-check --root <project> --action <action.json>
+qiheng action-record --root <project> --action <action.json>
+qiheng ontology-reconcile --root <project>
+qiheng ontology-ledger-check --root <project>
+qiheng ontology-evidence-check --root <project>
+qiheng ontology-validation-check --root <project>
+qiheng ontology-implementation-check --root <project>
 ```
 
 `action-record` appends an immutable, content-hashed entry to
@@ -79,14 +83,14 @@ rules.
 Useful machine-readable queries:
 
 ```text
-dic-workflow-kit ontology-query --root <project> --query uncovered
-dic-workflow-kit ontology-query --root <project> --query gaps
-dic-workflow-kit ontology-query --root <project> --query unevidenced
-dic-workflow-kit ontology-query --root <project> --query impact --id <object-id>
-dic-workflow-kit ontology-drift --root <project>
-dic-workflow-kit ontology-plan --root <project> --json
-dic-workflow-kit ontology-explain --root <project> --id <object-id> --json
-dic-workflow-kit ontology-report --root <project> --status <status>
+qiheng ontology-query --root <project> --query uncovered
+qiheng ontology-query --root <project> --query gaps
+qiheng ontology-query --root <project> --query unevidenced
+qiheng ontology-query --root <project> --query impact --id <object-id>
+qiheng ontology-drift --root <project>
+qiheng ontology-plan --root <project> --json
+qiheng ontology-explain --root <project> --id <object-id> --json
+qiheng ontology-report --root <project> --status <status>
 ```
 
 Snapshots carry a canonical `snapshotRevision`. Direct semantic edits invalidate
@@ -120,28 +124,100 @@ schemas/ontology-action-record.schema.json
 schemas/ontology-attestation.schema.json
 ```
 
-## Default Stages
+## Quality Review Boundaries
+
+Use `quality-review-orchestrator` to maintain a candidate-bound gate graph. It
+selects only the specialist quality Skills justified by the imported Spec,
+architecture, implementation, test, pipeline, and admission risk. The graph may
+contain repeated gates and feedback edges; it is not a one-pass checklist.
+
+Operate through these lifecycle boundaries:
+
+1. **Import and design clearance.** Intake resolves the imported Spec/change
+   and governing baseline. Run `quality-cross-spec-consistency` when the
+   profile requires semantic cross-Spec search, then run `quality-spec-review`
+   before implementation.
+   Add `quality-sr-ar-review` when architecture or realization is affected.
+2. **Gate planning.** Run `quality-ci-gate` with `phase: PLAN` to declare the
+   checks, evidence, runtime budgets, and failure policy expected for the
+   planned change surface.
+3. **Implementation.** Advance implementation only from confirmed obligations.
+   Trigger code, DT, security, performance, and other specialist gates when
+   their risk becomes applicable; do not assume one fixed invocation.
+4. **DIC consistency repair.** After implementation, compare the current
+   candidate with confirmed design, repair source-backed inconsistencies,
+   validate them, and repeat until invariants converge or a blocker is recorded.
+5. **Affected-gate re-entry.** Any Spec, architecture, code, test, fixture,
+   pipeline, policy, or candidate change marks its dependent decisions `STALE`.
+   Run `knowledge-change-impact` and re-run only those affected gates against
+   the new candidate.
+6. **Pre-commit admission.** Freeze the candidate, run `quality-ci-gate` with
+   `phase: VERIFY`. When high-risk claims apply, run
+   `quality-adversarial-challenge`; always audit terminal claim freshness with
+   `quality-evidence-audit`. Let `final-reviewer` compute DIC consistency and
+   verify the Attestation, then run `quality-repository-gate`.
+
+Skipped specialist reviews require an applicability reason. `STALE` and
+`SKIPPED` are lifecycle states, not successful quality decisions. Quality
+findings must reference existing ontology objects and Evidence where possible
+instead of creating a parallel truth model.
+
+DIC consistency, specialist quality, and repository admission are separate
+outcomes. DIC `PASS` proves design-implementation consistency; it does not by
+itself prove all quality domains or grant admission. Preserve the applicability
+plan, run history, invalidation reasons, and specialist outputs under
+`reports/quality/` so the Repository Gate consumes only current evidence for
+the same frozen candidate.
+
+## Default Lifecycle
 
 ```text
-workflow-intake
+quality-review-orchestrator [OPEN]
+-> workflow-core
+-> workflow-intake
 -> workflow-profile
--> spec-reader
 -> profile-builder
+-> workflow-harness [freeze candidate + materialize gate graph]
+-> spec-reader
+-> semantic-conflict-auditor
+-> quality-cross-spec-consistency
+-> quality-spec-review
 -> contract-oracle
+-> impact-analyst
+-> knowledge-change-impact
+-> quality-sr-ar-review [when architecture/realization is affected]
+-> quality-ci-gate [PLAN required gates]
+-> IMPLEMENT FROM CONFIRMED OBLIGATIONS
 -> flow-auditor
 -> impl-inspector
--> repair-planner
--> code-repairer
--> validation-runner
--> final-reviewer
+-> [repair-planner -> code-repairer -> validation-runner]*
+-> [quality-code-review / quality-dt-review / affected specialist gates]*
+-> impact-analyst [after drift or repair]
+-> [invalidate and re-enter earliest affected gate]*
+-> quality-ci-gate [VERIFY frozen candidate]
+-> adversarial-challenger [risk-selected; independent]
+-> quality-adversarial-challenge [when material challenge hypotheses apply]
+-> evidence-auditor
+-> quality-evidence-audit
+-> final-reviewer [DIC consistency + Attestation]
+-> quality-repository-gate [PRE-COMMIT ADMISSION]
+-> workflow-harness [check READY + generate executive cockpit]
+-> quality-review-orchestrator [CLOSE]
 ```
 
+`*` means zero or more risk-driven iterations. Dependencies constrain execution;
+the textual layout does not require every conditional gate or force unrelated
+gates into serial execution.
+
 ## Required Evidence
 
 At minimum, produce:
 
 ```text
 reports/project-profile.json
+reports/harness-plan.json
+reports/harness-run.json
+reports/harness-report.md
 reports/contract-obligations.json
 reports/contract-obligations.md
 reports/ontology-snapshot.json
@@ -150,6 +226,7 @@ reports/ontology-report.md
 reports/ontology-attestation.json
 reports/final-consistency-report.md
 reports/FINAL_RESULT.json
+reports/quality/
 result/output.md
 logs/trace/
 ```
@@ -186,7 +263,7 @@ Background, Scenario, Scenario Outline, Examples, tags, normalized steps, and
 source lines. BDD acceptance contracts become ontology obligations, but they do
 not become validation evidence until current executable checks are recorded.
 
-## Final Status
+## DIC Consistency Status
 
 Use one of:
 
@@ -195,7 +272,9 @@ Use one of:
 - `BLOCKED`
 - `FAIL`
 
-Do not use `SUCCESS`, `DONE`, or informal status labels in final machine-readable output.
+Do not use `SUCCESS`, `DONE`, or informal labels for machine-readable DIC
+consistency. Record specialist quality and repository admission in their
+separate fields.
 
 `PASS` is valid only when ontology invariants pass. At minimum:
 
@@ -214,9 +293,9 @@ content-addressed attestation, and verify it against the current snapshot,
 action ledger, design sources, and gate:
 
 ```text
-dic-workflow-kit ontology-report --root <project> --status <status>
-dic-workflow-kit ontology-attest --root <project> --status <status> --summary "<summary>"
-dic-workflow-kit ontology-attestation-check --root <project>
+qiheng ontology-report --root <project> --status <status>
+qiheng ontology-attest --root <project> --status <status> --summary "<summary>"
+qiheng ontology-attestation-check --root <project>
 ```
 
 If the final verification fails, the result is stale and must not be published.