dic-workflow-kit 1.1.2 → 1.1.4

package/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dic-workflow-kit",
-  "version": "1.1.2",
-  "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,9 +1,132 @@
 # 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
+
+- Added a portable ontology snapshot schema for typed objects, links, lifecycle, provenance, and invariant results.
+- Added an auditable ontology action schema with role, scope, precondition, postcondition, evidence, and rollback fields.
+- Added automatic OpenSpec-to-ontology snapshot generation and an `ontology-check` source helper command.
+- Added computed PASS gates for source coverage, implementation disposition, validation coverage, and open blocking gaps.
+- Added bundled `ontology-check`, `action-check`, and `action-record` runtime commands without publishing runtime source.
+- Added append-only, SHA-256-addressed action audit records with idempotency and collision rejection.
+- Added generic-project ontology initialization with candidate design sources.
+- Added action-specific ontology patches for controlled object, link, and lifecycle effects.
+- Added hash-verified, idempotent `ontology-reconcile` ledger replay with invariant-safe snapshot replacement.
+- Added `ontology-query` views for uncovered obligations, open gaps, unevidenced validations, and bounded impact analysis.
+- Added `ontology-drift` for content-hash change detection and incremental impact roots.
+- Added canonical snapshot revisions and an integrity invariant for detecting direct semantic edits.
+- Added optimistic concurrency protection for snapshot replacement during reconciliation.
+- Added `ontology-plan` to map design-source drift and impact neighborhoods to minimal Agent-stage reruns.
+- Added first-class English and Chinese Gherkin ingestion for Feature, Background, Scenario, Scenario Outline, Examples, tags, and source anchors.
+- Added `ontology-explain` for object provenance, direct relations, and bounded evidence-chain inspection.
+- Added a BDD adapter and strengthened the `knowledge-bdd` operating contract.
+- Added `ontology-report` for a generated, high-density Markdown view of current semantic state.
+- Added content-addressed ontology attestations bound to snapshot revision, action ledger, source hashes, and gate results.
+- Added `ontology-attestation-check` to reject stale or tampered final evidence.
+- Added sequence-numbered v2 action-ledger hash chains with v1-prefix compatibility.
+- Added Snapshot-revision binding for newly recorded actions and optional authored `expectedSnapshotRevision` checks.
+- Added `ontology-ledger-check` for chain head, record counts, and full-ledger digest inspection.
+- Added external Attestation anchoring through `ontology-attestation-check --expected-hash`.
+- Added `ontology-evidence-check` for content-addressed validation artifact verification.
+- Added Evidence artifact hashes to final Attestations and generated ontology reports.
+- Added `ObserveImplementation` to distinguish existing-code observation from repair output.
+- Added `ontology-implementation-check` for content-addressed implementation verification.
+- Added Validation input causality: each run binds its consumed DesignSource and ImplementationUnit hashes.
+- Added `ontology-validation-check`; stale or incomplete validation inputs now block PASS and invalidate Attestations.
+- Added ImplementationUnit hashes to final Attestations and generated ontology reports.
+- Added an installation manifest with SHA-256 hashes for every managed file.
+- Added `doctor` to verify installed files and Codex marketplace registration.
+- Added safe `uninstall` for every supported host.
+- Added `--json` output for installation lifecycle automation.
+- Added collision, tamper detection, forced recovery, and Codex unregister tests.
+
+### Changed
+
+- Moved Skill version markers into standards-compliant `metadata.version` while preserving release synchronization and legacy-install recognition.
+- Reframed Subagent responsibilities as bounded ontology reads, proposals, actions, and evidence attachments.
+- Added the ontology snapshot to the required workflow evidence and final artifacts.
+- Added role/action, target type, terminal condition, evidence, and protected-path enforcement.
+- Completed actions now require a non-empty, action-authorized ontology patch instead of direct snapshot edits.
+- PASS now rejects changed, missing, or out-of-project tracked design sources.
+- PASS now also rejects untracked design sources that lack a recorded content hash.
+- Final review now treats prose as a generated ontology view and requires attestation verification before publication.
+- New actions must be reconciled before another action can be recorded, preventing ambiguous multi-action base revisions.
+- `VERIFIED_BY` now counts only current Validation objects whose status is `PASS`.
+- `AttachEvidence` now requires a real project-relative artifact, SHA-256 provenance, and the `ContentAddressed` interface.
+- PASS now rejects missing, changed, untracked, inactive, or out-of-project required Evidence artifacts.
+- Ontology commands now separate the workflow evidence root from `snapshot.projectRoot`.
+- Content checks now resolve real paths and reject symlink escapes and non-file artifacts.
+- `IMPLEMENTED_BY` now counts only current ImplementationUnit objects.
+- `ObserveImplementation` and `ApplyRepair` now require real, content-addressed implementation files.
+- PASS now rejects missing, changed, untracked, inactive, invalid, or out-of-project required implementation artifacts.
+- `ontology-plan` now selects different minimal recovery stages for design, implementation, and Evidence drift.
+- Install now refuses to overwrite unmanaged or locally modified files unless `--force` is explicitly supplied.
+- Uninstall now refuses to remove modified managed files unless `--force` is explicitly supplied.
+- Install treats symbolic links and non-file targets as conflicts to prevent writes escaping managed roots.
+- Codex uninstall preserves all unrelated personal marketplace entries.
+
 ## [1.1.2] - 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.
 
@@ -14,33 +18,215 @@ This instruction is generic. It must not assume a contest, language, framework,
 - Do not edit protected design sources unless explicitly instructed.
 - Write intermediate evidence under `logs/trace/`.
 - Write final evidence under `reports/` and `result/`.
+- Treat `reports/ontology-snapshot.json` as the machine-readable semantic state.
+- Change semantic state through typed, evidence-backed actions rather than untracked prose.
+
+When workflow evidence is stored outside the repository, use the workflow root
+to locate `reports/` and the Snapshot `projectRoot` to resolve design,
+implementation, and Evidence paths. Do not conflate these roots.
+
+## Ontology Contract
+
+The workflow models design consistency as typed objects and links:
+
+```text
+Change -> PROPOSES -> Requirement
+Requirement -> DERIVED_FROM -> DesignSource
+Scenario -> REFINES -> Requirement
+Requirement -> IMPLEMENTED_BY -> ImplementationUnit
+Requirement/Scenario -> VERIFIED_BY -> Validation
+Gap -> VIOLATES -> Requirement
+RepairAction -> RESOLVES -> Gap
+Validation -> PRODUCES -> Evidence
+```
+
+Every object must have a stable ID, lifecycle, properties, and provenance. Every
+link endpoint must resolve. Reports are views over this semantic state; they are
+not independent sources of truth.
+
+Agents may only perform actions within their role:
+
+- readers propose or confirm source-backed objects
+- inspectors add observed implementation and gap links
+- planners propose repair actions without editing code
+- repairers execute approved, path-bounded actions
+- validators attach validation and evidence objects
+- final reviewers evaluate DIC invariants and transition consistency status
+
+Before executing or recording a mutation, validate it with the installed runtime:
+
+```text
+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
+`reports/ontology-actions.jsonl`. Reusing an action ID with different content is
+an error. `ontology-reconcile` replays authorized `ontologyPatch` effects and
+atomically replaces the snapshot only when structural invariants still pass.
+Use `ontology-check --status PASS` before producing a terminal PASS.
 
-## Default Stages
+Set `expectedSnapshotRevision` on authored actions. Newly recorded ledger
+entries bind the current Snapshot revision and form a sequence-numbered hash
+chain. Reconcile before recording the next action; otherwise recording fails.
+
+A completed action must declare `parameters.ontologyPatch`. Its permitted
+object types, link types, and lifecycle transitions are derived from the action
+type. Agents must not edit `ontology-snapshot.json` directly to bypass these
+rules.
+
+Useful machine-readable queries:
 
 ```text
-workflow-intake
+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
+the revision and must fail structural review. Reconciliation uses optimistic
+concurrency and refuses to replace a snapshot that changed after replay began.
+
+A PASS gate includes source-drift evaluation. A changed, missing, or
+out-of-project tracked source blocks PASS even when older implementation and
+validation links are still present.
+
+A `VERIFIED_BY` relation counts only when its Validation has a current lifecycle
+and `properties.status: PASS`. The Validation must record `executedAt` and bind
+every consumed DesignSource and ImplementationUnit as
+`properties.inputs[] = { objectId, contentHash }`; otherwise an earlier run
+could incorrectly approve newer design or code. Every Evidence produced by such a Validation
+must reference a project-relative artifact, record its SHA-256
+`provenance.contentHash`, and implement `ContentAddressed`.
+
+An `IMPLEMENTED_BY` relation counts only when its ImplementationUnit has a
+current lifecycle. The implementation must reference a project-relative regular
+file, record its SHA-256 `provenance.contentHash`, and implement
+`ContentAddressed`. Use `ObserveImplementation` for existing code and
+`ApplyRepair` for approved repair output.
+
+The portable schemas are:
+
+```text
+schemas/ontology-snapshot.schema.json
+schemas/ontology-action.schema.json
+schemas/ontology-action-record.schema.json
+schemas/ontology-attestation.schema.json
+```
+
+## 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
+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
+reports/ontology-actions.jsonl
+reports/ontology-report.md
+reports/ontology-attestation.json
 reports/final-consistency-report.md
 reports/FINAL_RESULT.json
+reports/quality/
 result/output.md
 logs/trace/
 ```
@@ -70,7 +256,14 @@ If OpenSpec files are present, use `knowledge-openspec` before repair planning.
 - archived specs do not override current specs
 - implementation does not silently exceed or contradict the accepted design
 
-## Final Status
+## BDD Rule
+
+If `.feature` files are present, use `knowledge-bdd`. Preserve Feature,
+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.
+
+## DIC Consistency Status
 
 Use one of:
 
@@ -79,4 +272,33 @@ 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:
+
+- every active obligation has a source
+- every active scenario refines a requirement
+- every active requirement has an implementation disposition
+- every required ImplementationUnit exists and matches its recorded SHA-256
+- every active obligation is linked to validation
+- every referenced Validation is current and successful
+- every referenced Validation binds the current design and implementation hashes
+- every required Evidence artifact exists and matches its recorded SHA-256
+- no blocking gap remains open
+
+Before publishing any terminal status, generate the ontology report, create a
+content-addressed attestation, and verify it against the current snapshot,
+action ledger, design sources, and gate:
+
+```text
+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.
+Persist the emitted Attestation `contentHash` in external CI or release
+metadata when available, then verify it with
+`ontology-attestation-check --expected-hash <sha256>`.