dic-workflow-kit 1.1.2 → 1.1.4

package/skills/quality-cross-spec-consistency/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: quality-cross-spec-consistency
+description: Detect semantic conflicts, incompatible obligations, stale baseline rules, and authority ambiguity across related specifications, schemas, configuration contracts, and design sources. Use during Spec intake, design review, archived-Change audits, or whenever project-profile consistencyScope requires repository-wide cross-Spec analysis.
+metadata:
+  version: 1.1.4
+---
+
+# Cross-Spec Consistency
+
+Audit authoritative sources; do not rewrite them unless explicitly asked.
+
+## Workflow
+
+1. Read `reports/project-profile.json`.
+2. Start with `baselineSpecs` and `relatedBaselineSpecs`.
+3. Inspect ranked `semanticConsistencyCandidates`; treat them as search hints,
+   not proven conflicts.
+4. Search every `consistencyScope.authorityRoots` entry for the exact normative
+   symbols, states, fields, interfaces, and ownership terms in scope.
+5. Compare authority, lifecycle, modality, allowed inputs, defaults, ownership,
+   state transitions, and failure behavior.
+6. Classify each candidate as `CONSISTENT`, `REFINEMENT`, `CONFLICT`, or
+   `UNKNOWN`.
+7. Bind findings to exact source locations and hashes. A strict syntax
+   validation does not close a semantic finding.
+
+## Conflict rules
+
+- Report a conflict when two current authoritative sources require
+  incompatible outcomes for the same condition.
+- Report a refinement only when the narrower rule preserves the broader
+  contract and its authority is established.
+- Report stale baseline when a later promoted rule changed behavior without
+  reconciling another current source.
+- Do not infer precedence from file modification time, implementation behavior,
+  or passing tests.
+- Block when authority is ambiguous and the difference changes implementation
+  or acceptance.
+
+## Output
+
+Produce findings first with ID, severity, symbol, source A, source B, conflicting
+clauses, authority analysis, implementation impact, and required resolution.
+Finish with scope coverage, unknowns, and `PASS`, `PASS WITH FOLLOW-UP`, or
+`BLOCKED`.

package/skills/quality-cross-spec-consistency/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Cross-Spec Consistency"
+  short_description: "Find semantic conflicts across authoritative specifications"
+  default_prompt: "Use $quality-cross-spec-consistency to inspect the project-profile consistency scope and report source-backed cross-Spec conflicts."

package/skills/quality-dt-review/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: quality-dt-review
+description: Evaluate candidate-bound developer-test effectiveness through requirement and risk coverage, negative paths, assertion strength, isolation, determinism, mutation sensitivity, and production relevance. Use when implementation or test risk changes during development, DIC repair, or pre-admission; re-run when affected code, tests, fixtures, or requirements change.
+metadata:
+  version: 1.1.4
+---
+
+# Quality DT Review
+
+Judge whether tests can detect important defects, not whether test counts or line coverage look high.
+
+## Workflow
+
+1. Read `references/dt-review.md`.
+2. Map requirements and risks to executable tests and negative cases.
+3. Inspect assertions, fixtures, mocks, data variation, concurrency, failure injection, and environment assumptions.
+4. Run relevant tests and, where proportionate, targeted mutation or fault seeding.
+5. Detect tests that merely mirror implementation, pass without product behavior, or hide flaky outcomes.
+6. Bind the decision to requirement, implementation, test, and fixture hashes.
+   Mark it stale when any consumed input changes.
+7. Report effective coverage, gaps, and stale or non-reproducible evidence.
+
+## Profile-driven rules
+
+Use project-profile module and test roots plus repository instructions to select
+the exact affected commands. Require characterization, contract, architecture,
+negative-path, or frontend evidence only when the detected change surface and
+risk make them applicable.
+
+## Output
+
+Use `PASS`, `PASS WITH FOLLOW-UP`, or `BLOCKED`. Include a risk-to-test matrix, ineffective-test findings, executed commands, reproducibility, flake status, mutation/fault evidence when used, and residual untested risks.

package/skills/quality-dt-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Quality DT Review"
+  short_description: "Assess developer-test effectiveness against delivery risks"
+  default_prompt: "Use $quality-dt-review to evaluate whether current candidate-bound developer tests provide effective risk-based evidence."

package/skills/quality-dt-review/references/dt-review.md

@@ -0,0 +1,14 @@
+# Developer-test effectiveness
+
+Assess:
+
+- requirement and risk coverage, not only files or lines;
+- normal, boundary, negative, invalid-state, authorization, concurrency, timeout, cancellation, dependency-failure, degradation, recovery, and compatibility paths;
+- assertions on observable contract outcomes and side effects;
+- ability to fail after a plausible fault is seeded;
+- deterministic setup, isolated ownership, realistic schemas/data, controlled time/randomness, and cleanup;
+- mock fidelity and whether excessive mocking bypasses integration risk;
+- reproducible commands, environment, seed, candidate ref, duration, and artifacts;
+- flakes, retries, quarantine duration, owner, and restoration criteria.
+
+Classify tests as effective, partial, ineffective, missing, or not applicable. Coverage percentage alone never proves effectiveness.

package/skills/quality-evidence-audit/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: quality-evidence-audit
+description: Audit whether quality and consistency claims are supported by current, content-addressed, candidate-bound evidence with reproducible provenance. Use before final DIC review or repository admission, after candidate changes, when gates reuse prior results, or whenever evidence completeness, freshness, causality, or scope is uncertain.
+metadata:
+  version: 1.1.4
+---
+
+# Evidence Audit
+
+Audit the proof chain independently. Remain read-only.
+
+## Workflow
+
+1. Freeze and verify the `Candidate` identity before evaluating evidence.
+2. Enumerate every active `Claim`, its supporting `Evidence`, producing
+   `Validation` or `GateRun`, consumed inputs, and applicable `Policy`.
+3. Verify paths, SHA-256 hashes, timestamps, commands, target IDs, environment,
+   and candidate identity.
+4. Check that evidence covers the exact claim scope and negative paths; a
+   nearby passing test does not support a broader assertion.
+5. Run `ontology-evidence-check`, `ontology-validation-check`,
+   `ontology-implementation-check`, and `ontology-drift`.
+6. Run `qiheng harness-check --root . --json`; audit Harness evidence hashes,
+   dependency closure, candidate identity, and project-profile identity.
+7. Classify each claim as `SUPPORTED`, `PARTIAL`, `STALE`, `CONTRADICTED`, or
+   `UNSUPPORTED`.
+8. Record supported assertions as `Claim` objects linked to durable Evidence
+   with `SUPPORTED_BY`. Open a blocking finding for every terminal claim that
+   lacks a current proof chain.
+
+## Freshness rule
+
+Any mutation to a consumed source, implementation unit, configuration,
+generated artifact, test fixture, or policy invalidates dependent claims until
+the relevant gate reruns against the new candidate.
+
+## Output
+
+Produce a claim-to-evidence matrix with candidate hash, gate run, claim,
+evidence IDs, coverage boundary, freshness, reproducibility, status, and
+required action. Do not infer `PASS` from agent confidence or prose summaries.

package/skills/quality-evidence-audit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Evidence Audit"
+  short_description: "Audit whether gate claims are current and evidence-backed"
+  default_prompt: "Audit gate claims against current content-addressed evidence and report unsupported assertions."

package/skills/quality-repository-gate/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: quality-repository-gate
+description: Decide pre-commit repository admission from a frozen candidate, current required reviews, reproducible validation, unresolved findings, waivers, provenance, and policy. Use only after DIC consistency review and all applicable gate reruns, before commit, push, merge, check-in, or release admission.
+metadata:
+  version: 1.1.4
+---
+
+# Quality Repository Gate
+
+Aggregate existing evidence; do not manufacture a green result by rerating missing evidence.
+
+Require `qiheng harness-check --root .` to return `deliveryStatus: READY`.
+Generate `reports/harness-report.md` and consume its candidate passport and
+blocker list together with the ontology Attestation. A green CI job cannot
+override an incomplete, stale, or evidence-broken Harness Run.
+
+## Workflow
+
+1. Freeze candidate ref, target ref, diff, and governing policy.
+2. Read `references/repository-gate.md`.
+3. Consume the orchestrator's applicability plan; reject omitted mandatory
+   reviews instead of independently redefining the plan.
+4. Verify that DIC consistency and every required Spec, SR/AR, code, DT,
+   security, performance, and CI decision are current for the frozen candidate.
+5. Verify every claimed command result belongs to the candidate bytes and is reproducible.
+6. Validate waiver authority, scope, expiry, owner, and compensating control.
+7. Issue one admission decision and a machine-readable evidence summary when the workflow supports it.
+
+## Profile-driven rules
+
+Treat repository-required semantic reviews and module-specific gates discovered
+from the project profile as mandatory. Record omissions. Do not approve changed
+contracts, security boundaries, persistence ownership, or scope rules without
+accepted authority evidence.
+
+## Output
+
+Use `ADMIT`, `ADMIT WITH FOLLOW-UP`, or `REJECT`; map these to the suite decisions `PASS`, `PASS WITH FOLLOW-UP`, and `BLOCKED`. Record candidate identity, reviews, validations, findings, waivers, residual risk, approver/owner where known, and evidence hashes or stable paths.

package/skills/quality-repository-gate/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Quality Repository Gate"
+  short_description: "Decide pre-commit admission for a frozen candidate"
+  default_prompt: "Use $quality-repository-gate after DIC review and affected-gate reruns to decide pre-commit admission for this frozen candidate."

package/skills/quality-repository-gate/references/repository-gate.md

@@ -0,0 +1,13 @@
+# Repository admission record
+
+Freeze and record:
+
+- target and candidate identifiers plus diff scope;
+- applicable policy and artifact inventory;
+- required specialist reviews and their current decisions;
+- validation command, environment, time, result, evidence location/hash, and candidate binding;
+- unresolved findings and cumulative residual risk;
+- waiver authority, scope, expiry, owner, compensating control, and follow-up verification;
+- final decision and reason.
+
+Reject when candidate identity is ambiguous, evidence is stale/non-reproducible, mandatory review is absent, a P0/P1 remains, or a material unknown could alter the decision. Never let a successful unrelated check compensate for a failed mandatory one.

package/skills/quality-review-orchestrator/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: quality-review-orchestrator
+description: Orchestrate a candidate-bound, evidence-based quality gate graph from imported specification through implementation, design-implementation consistency repair, and pre-commit admission. Use when a delivery may require multiple conditional or repeated Spec, SR/AR, code, developer-test, CI, or repository gates.
+metadata:
+  version: 1.1.4
+---
+
+# Quality Review Orchestrator
+
+Produce one auditable decision without replacing specialist review with a summary.
+
+## Workflow
+
+1. Establish the review baseline: repository, imported Spec/change, target and candidate identity, intended delivery, changed artifacts, governing sources, and commands actually available. Run `qiheng harness-init --root .` after the project profile exists and use its Plan as the only gate topology.
+2. Read `references/quality-model.md`. Classify every material statement as fact, inference, assumption, or unknown.
+3. Build an applicability plan from the current change surface and risk. Select only justified specialist Skills:
+   - `$quality-spec-review`
+   - `$quality-sr-ar-review`
+   - `$quality-code-review`
+   - `$quality-dt-review`
+   - `$quality-adversarial-challenge`
+   - `$quality-evidence-audit`
+   - `$quality-cross-spec-consistency`
+   - `$knowledge-change-impact`
+   - `$quality-repository-gate`
+   - `$quality-ci-gate`
+4. For DIC-enabled projects, reuse the current ontology snapshot and evidence chain. Do not create a parallel source of truth.
+5. Track every gate by phase, candidate identity, inputs, dependencies, status, and evidence. A gate may run more than once.
+6. When design, code, tests, pipeline policy, or candidate bytes change, mark affected decisions `STALE` and reschedule from the earliest affected boundary.
+7. Reconcile current specialist findings by evidence and scope. Never average away a blocker.
+8. Publish the unified report using the required output below.
+9. Record every terminal specialist result with `qiheng harness-record`, then
+   run `qiheng harness-check` and generate `qiheng harness-report`.
+
+## DIC gate lifecycle
+
+Use the following lifecycle. It is a dependency graph with feedback loops, not a
+one-pass linear chain:
+
+1. **Import and check the Spec.** Intake resolves the imported Spec/change and
+   governing baseline. Run `$quality-spec-review`; add `$quality-sr-ar-review`
+   when architecture or realization is affected. Do not authorize
+   implementation while a required design gate is blocked.
+2. **Plan delivery gates.** Run `$quality-ci-gate` in `PLAN` phase to declare
+   the checks, evidence, budgets, and failure policy required for the expected
+   change surface.
+3. **Implement.** Let the implementation workflow proceed within approved
+   obligations and paths. Apply code and developer-test reviews whenever their
+   risk domains become applicable; do not assume they run only once.
+4. **Repair design-implementation inconsistency.** After implementation,
+   inspect the current candidate against the confirmed design. Repair only
+   source-backed gaps, validate each repair, and repeat until DIC invariants
+   converge or a blocker is recorded.
+5. **Re-enter affected gates.** A repair that changes Spec, architecture, code,
+   tests, or pipeline policy invalidates the dependent gate decisions. Re-run
+   only the affected gates against the new candidate.
+6. **Apply the pre-commit gate.** Run `$quality-ci-gate` in `VERIFY` phase.
+   Select `$quality-adversarial-challenge` only for material, distinct failure
+   hypotheses; do not create a fixed-size review team. Run
+   `$quality-evidence-audit` before terminal review. Compute DIC consistency
+   and Attestation, then run
+   `$quality-repository-gate`. Admission consumes only current decisions bound
+   to the frozen candidate.
+7. **Close.** Publish consistency, quality, and admission as distinct outcomes,
+   plus one derived delivery decision.
+
+Skip a specialist only with an applicability reason and evidence. Do not run
+Repository Gate early, and do not let it replace a missing specialist decision.
+Persist the applicability record and specialist decisions under
+`reports/quality/`, referencing ontology IDs and Evidence paths instead of
+copying facts into an independent model.
+
+## Profile-driven specialization
+
+Use the project profile and repository instructions to load local policies,
+Skills, adapters, validation commands, and authority rules. Run cross-Spec
+consistency when semantic search is required. Run change-impact analysis after
+drift or repair before rescheduling gates. Never branch on a hardcoded
+repository name.
+
+## Decision
+
+Use `PASS`, `PASS WITH FOLLOW-UP`, or `BLOCKED`.
+
+- Any unresolved P0/P1, stale evidence, unknown governing source, or missing mandatory review makes the result `BLOCKED`.
+- P2 may yield `PASS WITH FOLLOW-UP` only with an owner, due condition, and verification route.
+- P3 cannot compensate for a missing mandatory gate.
+- `STALE` and `SKIPPED` are gate lifecycle states, not terminal quality
+  decisions. `SKIPPED` requires a recorded non-applicability reason.
+- A non-skipped `GateRun` needs an explicit `Decision`; an active `Claim` needs
+  current `SUPPORTED_BY` Evidence; an unresolved `Challenge` blocks PASS.
+
+## Output
+
+Report scope and baseline; candidate identity; applicability plan; gate
+dependencies and run history; current specialist results; stale decisions;
+findings; requirement-to-evidence gaps; commands and exact outcomes; waivers;
+residual risks; consistency status; quality status; admission status; and the
+derived delivery decision. Include evidence paths or command output references
+for every gate claim.

package/skills/quality-review-orchestrator/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Quality Review Orchestrator"
+  short_description: "Orchestrate repeatable, candidate-bound delivery gates"
+  default_prompt: "Use $quality-review-orchestrator to plan applicable gates, re-run invalidated gates after repair, and decide pre-commit readiness from current evidence."

package/skills/quality-review-orchestrator/references/quality-model.md

@@ -0,0 +1,73 @@
+# Quality evidence and decision model
+
+## Evidence classes
+
+- `FACT`: directly supported by an authoritative artifact or reproduced command.
+- `INFERENCE`: reasoned from stated facts; show the reasoning.
+- `ASSUMPTION`: temporarily accepted premise; name its owner and validation route.
+- `UNKNOWN`: missing or conflicting information. Block when it affects safety, contract, acceptance, or gate outcome.
+
+Evidence strength, from weakest to strongest:
+
+1. `E0` unverified assertion.
+2. `E1` inspected artifact with stable location.
+3. `E2` reproducible executable evidence tied to candidate bytes.
+4. `E3` independent or production-representative evidence with provenance.
+
+E0 never closes a finding. Evidence is stale when its consumed source or implementation bytes changed.
+
+## Gate lifecycle
+
+A delivery uses a dependency graph, not a one-pass checklist. Record each gate
+run with a stable ID, phase, applicability reason, candidate identity, consumed
+artifact hashes, dependencies, decision, and evidence.
+
+Gate lifecycle states:
+
+- `PLANNED`: applicable but not executed.
+- `RUNNING`: execution has started for the current candidate.
+- `PASS`, `PASS WITH FOLLOW-UP`, `BLOCKED`: current specialist decisions.
+- `STALE`: a consumed artifact, dependency, policy, or candidate changed.
+- `SKIPPED`: not applicable, with a recorded reason and evidence.
+
+`STALE` and `SKIPPED` are not successful decisions. A pre-commit admission gate
+may consume only current decisions for the frozen candidate.
+
+Invalidate from the earliest affected boundary:
+
+| Changed surface | Decisions to invalidate |
+| --- | --- |
+| Spec or acceptance rule | Spec, SR/AR when affected, DIC mapping, code/DT evidence, CI verification, admission |
+| Architecture, interface, data, or ownership | SR/AR, affected implementation and DT reviews, DIC evidence, CI verification, admission |
+| Implementation | affected code/DT reviews, DIC evidence, CI verification, admission |
+| Tests or fixtures | DT review, related validation, CI verification, admission |
+| Pipeline or gate policy | CI plan/verification and admission |
+| Candidate bytes or ref | every candidate-bound result whose recorded hash no longer matches |
+
+## Severity
+
+- `P0`: active catastrophic security, data, safety, or service risk.
+- `P1`: likely contract, isolation, availability, or delivery failure; blocks admission.
+- `P2`: material quality debt with a bounded workaround or follow-up.
+- `P3`: local maintainability or clarity improvement.
+
+## Finding record
+
+Record: ID, domain, severity, claim, exact location, evidence class and reference, failure/impact, required action, owner if known, and status.
+
+## Gate rules
+
+- `PASS`: all mandatory evidence is current; no unresolved P0/P1; no material unknown.
+- `PASS WITH FOLLOW-UP`: only bounded P2/P3 remains, with owner, due condition, and verification.
+- `BLOCKED`: mandatory evidence missing/stale, material unknown, or unresolved P0/P1.
+
+Waivers are explicit records, never erased findings. A waiver needs authority, scope, rationale, expiry, owner, compensating control, and verification.
+
+Keep three outcomes distinct:
+
+- `consistencyStatus`: whether implementation matches confirmed design.
+- `qualityStatus`: whether all applicable specialist quality gates are current.
+- `admissionStatus`: whether the frozen candidate may be submitted.
+
+Derive the delivery decision from these outcomes; never rewrite one outcome to
+make another appear green.

package/skills/quality-spec-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: quality-spec-review
+description: Review an imported product or software specification for completeness, consistency, testability, traceability, and hallucination resistance. Use before implementation for OpenSpec changes, requirement specifications, proposals, acceptance criteria, or model-authored specs, and re-run when their governing content changes.
+metadata:
+  version: 1.1.4
+---
+
+# Quality Spec Review
+
+Review specification quality; do not silently rewrite the target unless asked.
+
+## Workflow
+
+1. Identify authoritative sources and precedence. Record missing or conflicting governance instead of guessing.
+2. Read `references/spec-review.md`.
+3. Build a trace map from goal to requirement, scenario, task, implementation owner, and validation.
+4. Check completeness, consistency, feasibility against current code, and unsupported claims.
+5. Run available syntax/strict validation, but do not substitute it for semantic review.
+6. Bind the result to the reviewed source hashes. Mark an older result stale
+   when the Spec, acceptance rules, or governing baseline changes.
+7. Report findings first, then coverage and decision.
+
+## Anti-hallucination rules
+
+- Cite the exact artifact and location for every factual claim.
+- Label inference, assumption, and unknown explicitly.
+- Never invent files, APIs, owners, commands, test outcomes, architecture, or approved decisions.
+- Verify model-authored names and paths against the repository.
+- A material unknown that changes design or acceptance is blocking.
+
+## Profile-driven rules
+
+Use project-profile design entries, authority roots, adapters, related
+baselines, semantic candidates, protected paths, and repository instructions.
+Apply repository-local review Skills only when discovered and applicable; never
+hardcode a repository name, layout, or governance model.
+
+## Output
+
+Use `PASS`, `PASS WITH FOLLOW-UP`, or `BLOCKED`. List each finding with ID, severity, location, violated requirement, evidence, impact, and required correction. Include a traceability matrix and unknowns register.

package/skills/quality-spec-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Quality Spec Review"
+  short_description: "Review specifications for evidence, coverage, and consistency"
+  default_prompt: "Use $quality-spec-review to review this specification for completeness, consistency, traceability, and unsupported claims."

package/skills/quality-spec-review/references/spec-review.md

@@ -0,0 +1,14 @@
+# Specification review coverage
+
+Check:
+
+- goal, scope, non-goals, actors, trigger, preconditions, inputs, outputs, state, side effects, and ownership;
+- ordered decision rules, lifecycle, concurrency, idempotency, timeout, cancellation, failure, degradation, recovery, compatibility, migration, and rollback where applicable;
+- security, privacy, capacity, performance, reliability, observability, audit, diagnostics, maintainability, and testability;
+- normal, boundary, negative, authorization, dependency-failure, and recovery scenarios;
+- consistent terms, identifiers, defaults, units, enums, states, versions, and error semantics across proposal/design/spec/tasks/API/schema;
+- requirements that are atomic, testable, uniquely owned, and traceable to tasks and validation;
+- current-code feasibility and minimal delta for implementation specifications;
+- unsupported statements, invented repository facts, circular citations, missing source precedence, and unlabelled assumptions.
+
+A checklist row is not evidence. Cite the artifact and explain why it proves or fails the criterion.

package/skills/quality-sr-ar-review/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: quality-sr-ar-review
+description: Review Software Requirements, Architecture Review, or realization design for completeness, consistency, implementability, and architectural fitness. Use before architecture-affecting implementation and re-run when requirements, interfaces, data/state ownership, deployment, or architectural decisions change.
+metadata:
+  version: 1.1.4
+---
+
+# Quality SR/AR Review
+
+Assess whether the design is sufficient to implement, operate, test, and evolve safely.
+
+## Workflow
+
+1. Confirm what SR and AR mean in the target process and record the governing template.
+2. Read `references/sr-ar-review.md`.
+3. Trace requirements to components, owners, interfaces, data, quality attributes, failure behavior, and verification.
+4. Test architectural choices against current repository boundaries and actual integration paths.
+5. Identify contradictory views, missing decisions, hidden shared state, and speculative abstractions.
+6. Bind the decision to the reviewed design and candidate context; invalidate it
+   when a consumed requirement or architectural surface changes.
+7. Report evidence-backed findings and the smallest required correction.
+
+## Profile-driven rules
+
+Derive composition roots, module boundaries, public contracts, data/state
+ownership, deployment surfaces, and mandatory review rules from the project
+profile and repository evidence. Do not impose a package model or architecture
+that the target repository does not declare.
+
+## Output
+
+Use `PASS`, `PASS WITH FOLLOW-UP`, or `BLOCKED`. Include requirement-to-design coverage, architectural decisions and alternatives, quality-attribute scenarios, interface/data/state ownership, deployment/operations, validation, risks, and unresolved decisions.

package/skills/quality-sr-ar-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Quality SR/AR Review"
+  short_description: "Review SR and AR documents for architecture fitness"
+  default_prompt: "Use $quality-sr-ar-review to assess these SR and AR design documents with evidence."

package/skills/quality-sr-ar-review/references/sr-ar-review.md

@@ -0,0 +1,14 @@
+# SR and AR review coverage
+
+Require, where applicable:
+
+- business/system context, stakeholders, scope, constraints, assumptions, and terminology;
+- functional requirements and measurable quality-attribute scenarios;
+- current state, target state, minimal delta, component ownership, and dependency direction;
+- runtime, data, interface, state, sequence, deployment, trust-boundary, and failure/recovery views;
+- API/schema compatibility, persistence ownership, transactions, idempotency, migration, and rollback;
+- capacity model, latency/throughput budgets, availability, resilience, observability, audit, security, privacy, and operations;
+- architectural decisions with considered alternatives, trade-offs, and rejection reasons;
+- implementation slices, test strategy, acceptance evidence, risks, and unresolved decisions.
+
+Cross-check all views. The same fact must retain one owner, vocabulary, lifecycle, and failure policy. Diagrams without corresponding contracts and verification are explanatory, not sufficient design evidence.

package/skills/workflow-core/SKILL.md

@@ -1,7 +1,8 @@
 ---
 name: workflow-core
-version: 1.1.2
 description: Core Design-Implementation Consistency workflow contract, evidence model, handoff rules, and final output expectations.
+metadata:
+  version: 1.1.4
 ---
 
 # Workflow Core
@@ -15,11 +16,118 @@ Principles:
 - Every repair must trace to a source-backed obligation.
 - Subagents are useful only when they produce consumed evidence.
 - Final success requires validation evidence, residual-risk classification, and final artifacts.
+- `reports/ontology-snapshot.json` is the semantic source of truth for objects, links, lifecycle, and provenance.
+- Reports summarize the ontology; prose must not silently create or override semantic facts.
+
+Ontology operating model:
+
+- `profile-builder` discovers repository structure, authority roots, direct
+  related baselines, and ranked semantic candidates.
+- `spec-reader`, `semantic-conflict-auditor`, and `contract-oracle` establish
+  source-backed, conflict-aware requirements and scenarios.
+- `impact-analyst` identifies invalidated decisions and the minimal safe rerun
+  plan before implementation and after drift or repair.
+- `impl-inspector` records existing code with `ObserveImplementation` or opens gaps.
+- `repair-planner` proposes typed `RepairAction` objects.
+- `code-repairer` executes only approved, path-bounded actions.
+- `validation-runner` attaches `Validation` and `Evidence`.
+- `adversarial-challenger` records falsifiable `Challenge` and reproducible
+  `Counterexample` objects against high-risk claims.
+- `evidence-auditor` verifies that `Claim` objects are current and connected to
+  durable Evidence for the frozen `Candidate`.
+- `final-reviewer` computes PASS from invariants instead of agent confidence.
+
+Quality review envelope:
+
+- `workflow-harness` freezes the candidate and owns the executable gate graph,
+  dependency state, evidence hashes, and final completeness check.
+- `quality-review-orchestrator` owns a candidate-bound gate graph from imported
+  Spec through pre-commit admission.
+- Spec and applicable SR/AR gates clear the design baseline before implementation.
+- `quality-ci-gate` plans required checks before implementation and verifies
+  their evidence at the pre-commit boundary.
+- Code and DT gates are triggered by changed risk and may repeat as the
+  implementation or tests change.
+- After implementation, the DIC loop checks and repairs design-implementation
+  inconsistency until it converges or blocks.
+- Any repair invalidates dependent decisions; only affected gates are re-run.
+- `quality-repository-gate` runs only after current DIC Attestation and all
+  mandatory quality evidence are bound to the same frozen candidate.
+
+Quality Skills are conditional gates, not decorative stages. Record why each
+specialist is applicable or skipped. Reuse ontology objects, hashes, commands,
+and Evidence; do not create a parallel source of truth.
+Preserve applicable review decisions under `reports/quality/` with candidate
+identity and evidence references so later gates consume the actual findings.
+
+DIC consistency, specialist quality, and repository admission are distinct.
+DIC `PASS` proves the current implementation is consistent with its design
+evidence. It neither proves every quality domain passed nor grants admission.
+The Orchestrator preserves all three outcomes and derives the delivery decision.
+
+Use `schemas/ontology-action.schema.json` for auditable mutations. Every action
+records actor, targets, preconditions, postconditions, allowed paths, and evidence.
+Set `expectedSnapshotRevision` when authoring an action.
+When the bundled CLI is available, run `action-check` before execution and
+`action-record` after the action reaches its recorded state. Never reuse an
+action ID with different content.
+
+Every completed action includes `parameters.ontologyPatch`. Use only the object,
+link, and lifecycle effects permitted for that action type. After recording,
+run `ontology-reconcile`; do not mutate the snapshot directly. Reconciliation is
+idempotent and must preserve all structural invariants.
+Reconcile each new record before recording the next action. New ledger entries
+form a sequence-numbered hash chain and bind the Snapshot revision used during
+recording; run `ontology-ledger-check` before final review.
+
+Treat validation as successful only when its lifecycle is current and
+`properties.status` is `PASS`. Every Validation records `executedAt` and an
+`inputs` entry containing the object ID and current SHA-256 for every consumed
+DesignSource and ImplementationUnit. Run `ontology-validation-check`; an old
+test result must never approve newer design or implementation bytes.
+Attach each required Evidence object to a real
+project-relative artifact with `provenance.contentHash` and the
+`ContentAddressed` interface. Run `ontology-evidence-check` before attestation.
+
+Treat implementation as current only when its `ImplementationUnit` has a current
+lifecycle and a real project-relative file whose SHA-256 matches provenance.
+Use `ObserveImplementation` for existing code and `ApplyRepair` only for code
+created or changed by an approved repair. Run `ontology-implementation-check`
+before attestation.
+
+Treat `snapshotRevision` as an integrity boundary. Before final review, run
+`ontology-drift`; tracked source changes block PASS. Use `ontology-plan` to
+convert design, implementation, and Evidence integrity issues into the smallest
+recommended Agent-stage rerun.
+
+Final prose is a view, not an authority. Generate `reports/ontology-report.md`
+with `ontology-report`, create `reports/ontology-attestation.json` with
+`ontology-attest`, and run `ontology-attestation-check` immediately before
+publishing the result. The attestation binds the terminal status to the exact
+snapshot revision, action-ledger hash, design-source hashes, Evidence artifact
+hashes, ImplementationUnit hashes, and evaluated invariants.
+It also binds the Validation-to-input causality inventory.
+Persist its `contentHash` outside the evidence directory, then verify it with
+`--expected-hash`.
+
+Model each delivery decision around a content-addressed `Candidate`. Record
+specialist executions as `GateRun` objects linked by `EVALUATES`; bind terminal
+`Decision` objects with `DECIDES`. Active claims require `SUPPORTED_BY`
+Evidence. Unresolved `Challenge` objects block PASS. Use `Policy`, `Waiver`,
+and `Risk` objects to make governance exceptions explicit instead of hiding
+them in prose.
 
 Required durable outputs:
 
 ```text
 reports/project-profile.json
+reports/harness-plan.json
+reports/harness-run.json
+reports/harness-report.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
 result/output.md