dic-workflow-kit 1.1.2 → 1.1.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (69) hide show
  1. package/.codex-plugin/plugin.json +14 -10
  2. package/CHANGELOG.md +124 -1
  3. package/INSTRUCTION.md +232 -10
  4. package/README.md +376 -113
  5. package/README.zh-CN.md +342 -130
  6. package/adapters/bdd/README.md +21 -0
  7. package/adapters/bitfun/README.md +12 -2
  8. package/agents/adversarial-challenger.md +23 -0
  9. package/agents/code-repairer.md +8 -1
  10. package/agents/contract-oracle.md +4 -1
  11. package/agents/evidence-auditor.md +23 -0
  12. package/agents/final-reviewer.md +26 -2
  13. package/agents/flow-auditor.md +1 -1
  14. package/agents/impact-analyst.md +21 -0
  15. package/agents/impl-inspector.md +7 -1
  16. package/agents/profile-builder.md +7 -3
  17. package/agents/repair-planner.md +10 -1
  18. package/agents/semantic-conflict-auditor.md +21 -0
  19. package/agents/spec-reader.md +4 -1
  20. package/agents/validation-runner.md +11 -1
  21. package/dist/dic-workflow-kit.mjs +18 -7
  22. package/package.json +5 -2
  23. package/schemas/final-result.schema.json +35 -2
  24. package/schemas/harness-plan.schema.json +143 -0
  25. package/schemas/harness-run.schema.json +75 -0
  26. package/schemas/ontology-action-record.schema.json +62 -0
  27. package/schemas/ontology-action.schema.json +118 -0
  28. package/schemas/ontology-attestation.schema.json +187 -0
  29. package/schemas/ontology-patch.schema.json +48 -0
  30. package/schemas/ontology-snapshot.schema.json +326 -0
  31. package/schemas/project-profile.schema.json +44 -0
  32. package/skills/knowledge-bdd/SKILL.md +14 -2
  33. package/skills/knowledge-change-impact/SKILL.md +43 -0
  34. package/skills/knowledge-change-impact/agents/openai.yaml +4 -0
  35. package/skills/knowledge-openspec/SKILL.md +2 -1
  36. package/skills/knowledge-repair-distill/SKILL.md +2 -1
  37. package/skills/quality-adversarial-challenge/SKILL.md +42 -0
  38. package/skills/quality-adversarial-challenge/agents/openai.yaml +4 -0
  39. package/skills/quality-ci-gate/SKILL.md +45 -0
  40. package/skills/quality-ci-gate/agents/openai.yaml +4 -0
  41. package/skills/quality-ci-gate/references/ci-gate.md +22 -0
  42. package/skills/quality-code-review/SKILL.md +32 -0
  43. package/skills/quality-code-review/agents/openai.yaml +4 -0
  44. package/skills/quality-code-review/references/code-review.md +13 -0
  45. package/skills/quality-cross-spec-consistency/SKILL.md +45 -0
  46. package/skills/quality-cross-spec-consistency/agents/openai.yaml +4 -0
  47. package/skills/quality-dt-review/SKILL.md +32 -0
  48. package/skills/quality-dt-review/agents/openai.yaml +4 -0
  49. package/skills/quality-dt-review/references/dt-review.md +14 -0
  50. package/skills/quality-evidence-audit/SKILL.md +41 -0
  51. package/skills/quality-evidence-audit/agents/openai.yaml +4 -0
  52. package/skills/quality-repository-gate/SKILL.md +38 -0
  53. package/skills/quality-repository-gate/agents/openai.yaml +4 -0
  54. package/skills/quality-repository-gate/references/repository-gate.md +13 -0
  55. package/skills/quality-review-orchestrator/SKILL.md +100 -0
  56. package/skills/quality-review-orchestrator/agents/openai.yaml +4 -0
  57. package/skills/quality-review-orchestrator/references/quality-model.md +73 -0
  58. package/skills/quality-spec-review/SKILL.md +40 -0
  59. package/skills/quality-spec-review/agents/openai.yaml +4 -0
  60. package/skills/quality-spec-review/references/spec-review.md +14 -0
  61. package/skills/quality-sr-ar-review/SKILL.md +32 -0
  62. package/skills/quality-sr-ar-review/agents/openai.yaml +4 -0
  63. package/skills/quality-sr-ar-review/references/sr-ar-review.md +14 -0
  64. package/skills/workflow-core/SKILL.md +109 -1
  65. package/skills/workflow-harness/SKILL.md +73 -0
  66. package/skills/workflow-harness/agents/openai.yaml +4 -0
  67. package/skills/workflow-intake/SKILL.md +9 -2
  68. package/skills/workflow-profile/SKILL.md +17 -1
  69. package/skills/workflow-repair/SKILL.md +8 -4
@@ -0,0 +1,326 @@
1
+ {
2
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
3
+ "$id": "https://dicworkflowkit.local/schemas/ontology-snapshot.schema.json",
4
+ "title": "DIC Ontology Snapshot",
5
+ "description": "Portable, file-backed semantic graph for design-implementation consistency.",
6
+ "type": "object",
7
+ "required": [
8
+ "schema",
9
+ "version",
10
+ "snapshotId",
11
+ "projectRoot",
12
+ "objects",
13
+ "links",
14
+ "invariantResults"
15
+ ],
16
+ "properties": {
17
+ "schema": { "const": "dic.ontology-snapshot.v1" },
18
+ "version": { "type": "string" },
19
+ "snapshotId": { "$ref": "#/$defs/stableId" },
20
+ "snapshotRevision": {
21
+ "type": "string",
22
+ "pattern": "^[a-f0-9]{64}$"
23
+ },
24
+ "projectRoot": { "type": "string" },
25
+ "objects": {
26
+ "type": "array",
27
+ "items": { "$ref": "#/$defs/object" }
28
+ },
29
+ "links": {
30
+ "type": "array",
31
+ "items": { "$ref": "#/$defs/link" }
32
+ },
33
+ "invariantResults": {
34
+ "type": "array",
35
+ "items": { "$ref": "#/$defs/invariantResult" }
36
+ },
37
+ "appliedActionIds": {
38
+ "type": "array",
39
+ "items": {
40
+ "type": "string",
41
+ "pattern": "^act-[a-zA-Z0-9._:-]+$"
42
+ },
43
+ "uniqueItems": true
44
+ }
45
+ },
46
+ "$defs": {
47
+ "stableId": {
48
+ "type": "string",
49
+ "pattern": "^[a-z][a-z0-9-]*-[a-zA-Z0-9._:-]+$"
50
+ },
51
+ "lifecycle": {
52
+ "enum": [
53
+ "draft",
54
+ "confirmed",
55
+ "active",
56
+ "deprecated",
57
+ "superseded",
58
+ "rejected",
59
+ "open",
60
+ "approved",
61
+ "in_progress",
62
+ "resolved",
63
+ "blocked"
64
+ ]
65
+ },
66
+ "provenance": {
67
+ "type": "object",
68
+ "required": ["source", "sourceRevision", "createdBy"],
69
+ "properties": {
70
+ "source": { "type": "string", "minLength": 1 },
71
+ "sourceLocator": { "type": "string" },
72
+ "sourceRevision": { "type": "string", "minLength": 1 },
73
+ "contentHash": {
74
+ "type": "string",
75
+ "pattern": "^[a-f0-9]{64}$"
76
+ },
77
+ "createdBy": { "type": "string", "minLength": 1 },
78
+ "runId": { "type": "string" }
79
+ },
80
+ "additionalProperties": false
81
+ },
82
+ "object": {
83
+ "type": "object",
84
+ "required": ["id", "type", "lifecycle", "properties", "provenance"],
85
+ "properties": {
86
+ "id": { "$ref": "#/$defs/stableId" },
87
+ "type": {
88
+ "enum": [
89
+ "Project",
90
+ "DesignSource",
91
+ "Change",
92
+ "Requirement",
93
+ "Scenario",
94
+ "ImplementationUnit",
95
+ "Gap",
96
+ "RepairAction",
97
+ "Validation",
98
+ "Evidence",
99
+ "AgentRun",
100
+ "Decision",
101
+ "Risk",
102
+ "Candidate",
103
+ "GateRun",
104
+ "Claim",
105
+ "Challenge",
106
+ "Counterexample",
107
+ "Waiver",
108
+ "Policy"
109
+ ]
110
+ },
111
+ "lifecycle": { "$ref": "#/$defs/lifecycle" },
112
+ "interfaces": {
113
+ "type": "array",
114
+ "items": {
115
+ "enum": [
116
+ "SourceBacked",
117
+ "Verifiable",
118
+ "Versioned",
119
+ "GovernedMutation",
120
+ "ContentAddressed"
121
+ ]
122
+ },
123
+ "uniqueItems": true
124
+ },
125
+ "properties": {
126
+ "type": "object",
127
+ "additionalProperties": true
128
+ },
129
+ "provenance": { "$ref": "#/$defs/provenance" }
130
+ },
131
+ "allOf": [
132
+ {
133
+ "if": {
134
+ "properties": { "type": { "const": "Evidence" } },
135
+ "required": ["type"]
136
+ },
137
+ "then": {
138
+ "properties": {
139
+ "interfaces": {
140
+ "contains": { "const": "ContentAddressed" }
141
+ },
142
+ "properties": {
143
+ "required": ["path"],
144
+ "properties": {
145
+ "path": { "type": "string", "minLength": 1 }
146
+ }
147
+ },
148
+ "provenance": {
149
+ "required": ["contentHash"]
150
+ }
151
+ }
152
+ }
153
+ },
154
+ {
155
+ "if": {
156
+ "properties": { "type": { "const": "ImplementationUnit" } },
157
+ "required": ["type"]
158
+ },
159
+ "then": {
160
+ "properties": {
161
+ "interfaces": {
162
+ "contains": { "const": "ContentAddressed" }
163
+ },
164
+ "properties": {
165
+ "required": ["path"],
166
+ "properties": {
167
+ "path": { "type": "string", "minLength": 1 }
168
+ }
169
+ },
170
+ "provenance": {
171
+ "required": ["contentHash"]
172
+ }
173
+ }
174
+ }
175
+ },
176
+ {
177
+ "if": {
178
+ "properties": { "type": { "const": "Validation" } },
179
+ "required": ["type"]
180
+ },
181
+ "then": {
182
+ "properties": {
183
+ "properties": {
184
+ "required": ["status", "executedAt", "inputs"],
185
+ "properties": {
186
+ "status": { "enum": ["PASS", "FAIL", "BLOCKED"] },
187
+ "executedAt": { "type": "string", "format": "date-time" },
188
+ "inputs": {
189
+ "type": "array",
190
+ "items": { "$ref": "#/$defs/validationInput" }
191
+ }
192
+ }
193
+ }
194
+ }
195
+ }
196
+ },
197
+ {
198
+ "if": {
199
+ "properties": { "type": { "const": "Candidate" } },
200
+ "required": ["type"]
201
+ },
202
+ "then": {
203
+ "properties": {
204
+ "interfaces": {
205
+ "contains": { "const": "ContentAddressed" }
206
+ },
207
+ "properties": {
208
+ "required": ["ref"],
209
+ "properties": {
210
+ "ref": { "type": "string", "minLength": 1 }
211
+ }
212
+ },
213
+ "provenance": {
214
+ "required": ["contentHash"]
215
+ }
216
+ }
217
+ }
218
+ },
219
+ {
220
+ "if": {
221
+ "properties": { "type": { "const": "GateRun" } },
222
+ "required": ["type"]
223
+ },
224
+ "then": {
225
+ "properties": {
226
+ "properties": {
227
+ "required": ["status", "executedAt"],
228
+ "properties": {
229
+ "status": { "enum": ["PASS", "FAIL", "BLOCKED", "SKIPPED"] },
230
+ "executedAt": { "type": "string", "format": "date-time" }
231
+ }
232
+ }
233
+ }
234
+ }
235
+ },
236
+ {
237
+ "if": {
238
+ "properties": {
239
+ "type": {
240
+ "enum": ["Claim", "Challenge", "Counterexample", "Waiver", "Policy"]
241
+ }
242
+ },
243
+ "required": ["type"]
244
+ },
245
+ "then": {
246
+ "properties": {
247
+ "properties": {
248
+ "required": ["statement"],
249
+ "properties": {
250
+ "statement": { "type": "string", "minLength": 1 }
251
+ }
252
+ }
253
+ }
254
+ }
255
+ }
256
+ ],
257
+ "additionalProperties": false
258
+ },
259
+ "validationInput": {
260
+ "type": "object",
261
+ "required": ["objectId", "contentHash"],
262
+ "properties": {
263
+ "objectId": { "$ref": "#/$defs/stableId" },
264
+ "contentHash": {
265
+ "type": "string",
266
+ "pattern": "^[a-f0-9]{64}$"
267
+ }
268
+ },
269
+ "additionalProperties": false
270
+ },
271
+ "link": {
272
+ "type": "object",
273
+ "required": ["id", "type", "from", "to", "lifecycle", "provenance"],
274
+ "properties": {
275
+ "id": { "$ref": "#/$defs/stableId" },
276
+ "type": {
277
+ "enum": [
278
+ "CONTAINS",
279
+ "PROPOSES",
280
+ "DERIVED_FROM",
281
+ "REFINES",
282
+ "IMPLEMENTED_BY",
283
+ "VERIFIED_BY",
284
+ "VIOLATES",
285
+ "RESOLVES",
286
+ "PRODUCES",
287
+ "SUPPORTS",
288
+ "CONTRADICTS",
289
+ "REMAINS_AFTER",
290
+ "EVALUATES",
291
+ "DECIDES",
292
+ "ASSERTS",
293
+ "CHALLENGES",
294
+ "REFUTES",
295
+ "SUPPORTED_BY",
296
+ "WAIVES",
297
+ "GOVERNS",
298
+ "SUPERSEDES"
299
+ ]
300
+ },
301
+ "from": { "$ref": "#/$defs/stableId" },
302
+ "to": { "$ref": "#/$defs/stableId" },
303
+ "lifecycle": { "$ref": "#/$defs/lifecycle" },
304
+ "provenance": { "$ref": "#/$defs/provenance" }
305
+ },
306
+ "additionalProperties": false
307
+ },
308
+ "invariantResult": {
309
+ "type": "object",
310
+ "required": ["id", "status", "severity", "message", "objectIds"],
311
+ "properties": {
312
+ "id": { "type": "string", "minLength": 1 },
313
+ "status": { "enum": ["PASS", "FAIL", "NOT_APPLICABLE"] },
314
+ "severity": { "enum": ["info", "warning", "blocking"] },
315
+ "message": { "type": "string" },
316
+ "objectIds": {
317
+ "type": "array",
318
+ "items": { "$ref": "#/$defs/stableId" },
319
+ "uniqueItems": true
320
+ }
321
+ },
322
+ "additionalProperties": false
323
+ }
324
+ },
325
+ "additionalProperties": false
326
+ }
@@ -10,6 +10,24 @@
10
10
  "projectRoot": { "type": "string" },
11
11
  "projectTypes": { "type": "array", "items": { "type": "string" } },
12
12
  "adapters": { "type": "array", "items": { "type": "string" } },
13
+ "bddSources": { "type": "array", "items": { "type": "string" } },
14
+ "availableBddSources": { "type": "array", "items": { "type": "string" } },
15
+ "repositoryLayout": {
16
+ "type": "object",
17
+ "properties": {
18
+ "manifests": { "type": "array", "items": { "type": "string" } },
19
+ "moduleRoots": { "type": "array", "items": { "type": "string" } },
20
+ "discovery": { "type": "string" }
21
+ }
22
+ },
23
+ "consistencyScope": {
24
+ "type": "object",
25
+ "properties": {
26
+ "authorityRoots": { "type": "array", "items": { "type": "string" } },
27
+ "relationStrategies": { "type": "array", "items": { "type": "string" } },
28
+ "semanticCrossSpecSearchRequired": { "type": "boolean" }
29
+ }
30
+ },
13
31
  "designEntry": {
14
32
  "type": "object",
15
33
  "required": ["type", "changeId", "lifecycle", "changeRoot", "documents", "deltaSpecs", "baselineSpecs"],
@@ -38,6 +56,32 @@
38
56
  },
39
57
  "deltaSpecs": { "type": "array", "items": { "type": "string" } },
40
58
  "baselineSpecs": { "type": "array", "items": { "type": "string" } },
59
+ "relatedBaselineSpecs": { "type": "array", "items": { "type": "string" } },
60
+ "relatedBaselineReasons": {
61
+ "type": "object",
62
+ "additionalProperties": {
63
+ "type": "array",
64
+ "items": { "type": "string" }
65
+ }
66
+ },
67
+ "semanticConsistencyCandidates": {
68
+ "type": "array",
69
+ "items": {
70
+ "type": "object",
71
+ "required": ["spec", "score", "sharedSymbols", "reason"],
72
+ "properties": {
73
+ "spec": { "type": "string" },
74
+ "score": { "type": "number", "minimum": 0 },
75
+ "sharedSymbols": {
76
+ "type": "array",
77
+ "items": { "type": "string" },
78
+ "minItems": 2
79
+ },
80
+ "reason": { "const": "shared-normative-symbols" }
81
+ },
82
+ "additionalProperties": false
83
+ }
84
+ },
41
85
  "designSources": { "type": "array", "items": { "type": "string" } },
42
86
  "implementationRoots": { "type": "array", "items": { "type": "string" } },
43
87
  "testRoots": { "type": "array", "items": { "type": "string" } },
@@ -1,7 +1,8 @@
1
1
  ---
2
2
  name: knowledge-bdd
3
- version: 1.1.2
4
- description: Derive Given-When-Then acceptance scenarios from confirmed design rules and flow contracts.
3
+ description: Interpret or derive Gherkin/BDD Feature, Background, Scenario, Scenario Outline, Examples, and Given-When-Then acceptance contracts when .feature files or confirmed behavioral rules are in scope.
4
+ metadata:
5
+ version: 1.1.4
5
6
  ---
6
7
 
7
8
  # Knowledge: BDD
@@ -20,3 +21,14 @@ For every confirmed rule, consider:
20
21
  - concurrency or ordering
21
22
 
22
23
  BDD scenarios are acceptance criteria. They are not a license to invent behavior outside source truth.
24
+
25
+ When `.feature` files are mounted in the ontology:
26
+
27
+ - treat `Feature` as the parent Requirement
28
+ - preserve inherited Background clauses
29
+ - preserve Scenario Outline Examples without expanding invented cases
30
+ - use `DERIVED_FROM` and `REFINES` for source and parent traceability
31
+ - add `VERIFIED_BY` only after current executable validation produces evidence
32
+
33
+ Use `ontology-explain --id <scenario-id>` when a scenario's source, parent,
34
+ implementation, validation, or evidence chain is unclear.
@@ -0,0 +1,43 @@
1
+ ---
2
+ name: knowledge-change-impact
3
+ description: Trace a design, code, test, policy, or evidence change through project-profile roots and ontology relations to determine affected obligations, implementation units, validations, gates, and decisions. Use before planning work, after drift, and after repairs to invalidate and rerun only the evidence that is no longer current.
4
+ metadata:
5
+ version: 1.1.4
6
+ ---
7
+
8
+ # Change Impact
9
+
10
+ Build a bounded, evidence-backed impact set. Do not equate filename proximity
11
+ with semantic dependency.
12
+
13
+ ## Workflow
14
+
15
+ 1. Identify changed artifacts and their current hashes.
16
+ 2. Read `reports/project-profile.json` for module, implementation, test, design,
17
+ and authority roots.
18
+ 3. Use ontology `ontology-drift`, `ontology-query --query impact`, and
19
+ `ontology-plan` when a current snapshot exists.
20
+ 4. Traverse from changed sources or implementation units through obligations,
21
+ scenarios, validations, evidence, risks, and decisions.
22
+ 5. Add repository dependencies supported by imports, public contracts, build
23
+ manifests, design maps, or explicit references.
24
+ 6. Mark dependent gate decisions `STALE` from the earliest affected boundary.
25
+ 7. Produce the minimal safe rerun plan and name excluded gates with evidence.
26
+
27
+ ## Boundaries
28
+
29
+ - A Spec or acceptance change invalidates downstream design, implementation,
30
+ test, consistency, CI, and admission evidence.
31
+ - An architecture or interface change invalidates affected ownership and
32
+ integration evidence.
33
+ - An implementation change invalidates affected code, developer-test,
34
+ consistency, CI, and admission evidence.
35
+ - A test, fixture, pipeline, policy, or candidate change invalidates only the
36
+ decisions that consumed it, unless authority evidence shows wider impact.
37
+ - Unknown dependency direction is blocking when it could hide a required gate.
38
+
39
+ ## Output
40
+
41
+ Record changed roots, impacted object IDs and paths, invalidated decisions,
42
+ required reruns, unaffected decisions with justification, and residual
43
+ unknowns. Keep facts, inferences, and assumptions distinct.
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: "Change Impact"
3
+ short_description: "Trace semantic change impact and invalidated evidence"
4
+ default_prompt: "Use $knowledge-change-impact to trace this change through obligations, implementation, validation, and gates."
@@ -1,7 +1,8 @@
1
1
  ---
2
2
  name: knowledge-openspec
3
- version: 1.1.2
4
3
  description: OpenSpec knowledge pack for proposals, specs, scenarios, tasks, changes, archived capabilities, validation, and design-to-implementation mapping.
4
+ metadata:
5
+ version: 1.1.4
5
6
  ---
6
7
 
7
8
  # Knowledge: OpenSpec
@@ -1,7 +1,8 @@
1
1
  ---
2
2
  name: knowledge-repair-distill
3
- version: 1.1.2
4
3
  description: Generic repair convergence guidance, gap taxonomy, model steering hints, and validation gates for design-implementation consistency work.
4
+ metadata:
5
+ version: 1.1.4
5
6
  ---
6
7
 
7
8
  # Knowledge: Repair Distill
@@ -0,0 +1,42 @@
1
+ ---
2
+ name: quality-adversarial-challenge
3
+ description: Stress-test high-risk design, implementation, validation, and admission claims by constructing falsifiable challenges and reproducible counterexamples. Use after ordinary review when the project profile exposes high blast radius, security or lifecycle risk, cross-Spec ambiguity, weak negative-path coverage, or a high-confidence PASS claim that needs independent challenge.
4
+ metadata:
5
+ version: 1.1.4
6
+ ---
7
+
8
+ # Adversarial Challenge
9
+
10
+ Challenge claims, not people. Remain read-only.
11
+
12
+ ## Workflow
13
+
14
+ 1. Read the frozen `Candidate`, applicable `Policy`, current `GateRun`, and its
15
+ evidence-backed `Claim` objects.
16
+ 2. Select only high-value attack surfaces from the project profile, impact
17
+ analysis, semantic conflicts, changed boundaries, and residual risks.
18
+ 3. State each challenge as a falsifiable condition: claim, attack premise,
19
+ minimal experiment, expected observation, and disconfirming observation.
20
+ 4. Prefer boundary values, invalid sequences, stale state, concurrency,
21
+ partial failure, rollback, authority conflicts, and evidence/candidate hash
22
+ mismatches.
23
+ 5. Reproduce a successful attack with exact inputs, commands, environment,
24
+ observed output, and candidate identity.
25
+ 6. Record a `Challenge` linked by `CHALLENGES`. Record a reproducible
26
+ `Counterexample` linked by `REFUTES`; never manufacture a counterexample
27
+ from speculation.
28
+ 7. Mark a challenge resolved only after current evidence addresses the same
29
+ premise on the same candidate.
30
+
31
+ ## Selection rule
32
+
33
+ Do not launch a fixed adversarial team. Choose the smallest independent
34
+ challenge set that covers materially different failure hypotheses. Stop when
35
+ additional challenges repeat an already covered premise or have no plausible
36
+ impact on a gate decision.
37
+
38
+ ## Output
39
+
40
+ Produce a challenge ledger with IDs, target claims, premises, experiments,
41
+ results, evidence, and lifecycle. Any unresolved material challenge blocks
42
+ `PASS`; absence of a found counterexample is not proof of correctness.
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: "Adversarial Challenge"
3
+ short_description: "Challenge high-risk consistency claims with counterexamples"
4
+ default_prompt: "Stress-test the candidate consistency claims and record reproducible challenges."
@@ -0,0 +1,45 @@
1
+ ---
2
+ name: quality-ci-gate
3
+ description: Plan and verify candidate-bound continuous-integration gates for risk coverage, reliability, runtime cost, flake control, and traceable evidence. Use in PLAN phase before implementation and VERIFY phase before commit, merge, or release; repeat when the change surface, candidate, tests, pipeline, or gate policy changes.
4
+ metadata:
5
+ version: 1.1.4
6
+ ---
7
+
8
+ # Quality CI Gate
9
+
10
+ Maximize defect-detection value per unit of developer delay without weakening critical controls.
11
+
12
+ Bind both PLAN and VERIFY decisions to the current Harness gate and candidate.
13
+ Preserve the decision as durable evidence, then record `delivery.plan` or
14
+ `delivery.verify` with `qiheng harness-record`. Refuse to record after candidate
15
+ or project-profile drift.
16
+
17
+ ## Workflow
18
+
19
+ 1. Declare `phase: PLAN` or `phase: VERIFY`, candidate identity, and the change
20
+ surface. Never mix the two phases in one decision.
21
+ 2. Read `references/ci-gate.md`.
22
+ 3. In `PLAN`, inventory each required gate, defect class, trigger, owner,
23
+ runtime budget, evidence, and failure policy.
24
+ 4. In `VERIFY`, consume the exact current plan and verify that every mandatory
25
+ result belongs to the frozen candidate.
26
+ 5. Find missing controls, redundant gates, false confidence, flakes, and serial
27
+ bottlenecks.
28
+ 6. Define quarantine, retry, override, and restoration rules without turning
29
+ critical failures green.
30
+ 7. Mark verification stale when candidate bytes, tests, fixtures, pipeline, or
31
+ gate policy changes.
32
+
33
+ ## Profile-driven rules
34
+
35
+ Preserve mandatory gates discovered from repository policy, project-profile
36
+ validation commands, module manifests, and affected frontend/backend roots.
37
+ Do not substitute a root command for an affected module-specific gate unless
38
+ repository evidence proves equivalence.
39
+
40
+ ## Output
41
+
42
+ Use `PASS`, `PASS WITH FOLLOW-UP`, or `BLOCKED`. Include phase, plan ID and hash,
43
+ candidate identity, gate matrix, current result links, critical gaps, redundant
44
+ or low-value gates, runtime budget, flake policy, evidence retention, pipeline
45
+ stages, and expected quality and lead-time effects.
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: "Quality CI Gate"
3
+ short_description: "Plan or verify candidate-bound CI quality gates"
4
+ default_prompt: "Use $quality-ci-gate in PLAN or VERIFY phase to assess current candidate gates, evidence, reliability, and delivery efficiency."
@@ -0,0 +1,22 @@
1
+ # CI gate effectiveness
2
+
3
+ For every gate record:
4
+
5
+ - defect/risk class and governing requirement;
6
+ - trigger and pipeline stage;
7
+ - exact command and environment;
8
+ - owner and escalation path;
9
+ - median/P95 runtime and queue impact;
10
+ - pass rate, false-positive rate, flake rate, and retry behavior;
11
+ - produced evidence, retention, provenance, and candidate binding;
12
+ - fail-open/closed policy, override authority, and removal criteria.
13
+
14
+ Prefer:
15
+
16
+ - change-aware fast checks before merge;
17
+ - parallel independent checks;
18
+ - deterministic cache keys and fail-safe cache misses;
19
+ - expensive exhaustive checks at release or scheduled stages only when admission risk remains covered;
20
+ - explicit time budgets and a measured feedback loop.
21
+
22
+ Never optimize lead time by dropping security, contract, isolation, data-integrity, or release-critical evidence. Remove redundant gates only after proving equivalent coverage.
@@ -0,0 +1,32 @@
1
+ ---
2
+ name: quality-code-review
3
+ description: Perform candidate-bound semantic code review covering specification alignment, architecture, security, performance, reliability, observability, and maintainability. Use whenever implementation risk becomes applicable during development, DIC repair, pre-commit, pull request, or targeted audit; re-run when affected code or governing contracts change.
4
+ metadata:
5
+ version: 1.1.4
6
+ ---
7
+
8
+ # Quality Code Review
9
+
10
+ Review observable risk and contract impact, not style preference.
11
+
12
+ ## Workflow
13
+
14
+ 1. Fix the candidate and diff baseline and read governing specs, repository instructions, and affected public contracts.
15
+ 2. Read `references/code-review.md`.
16
+ 3. Inspect call paths and ownership beyond changed lines only where needed to prove impact.
17
+ 4. Run the smallest relevant build, tests, architecture checks, and security/performance probes.
18
+ 5. Separate confirmed defects from risks requiring measurement.
19
+ 6. Bind the decision to candidate and governing-source hashes. Mark it stale
20
+ after an affected implementation or contract change.
21
+ 7. Report findings first. Do not edit unless the user requests remediation.
22
+
23
+ ## Profile-driven rules
24
+
25
+ Load repository-local code-review policy when the project profile or repository
26
+ instructions identify it. Derive affected module, interface, security,
27
+ persistence, frontend, runtime, and validation boundaries from repository
28
+ evidence rather than a named project template.
29
+
30
+ ## Output
31
+
32
+ Use P0-P3 and `PASS`, `PASS WITH FOLLOW-UP`, or `BLOCKED`. Every finding needs a tight location, failure scenario, evidence, impact, and required fix. State commands run, exact results, untested areas, and residual risk.
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: "Quality Code Review"
3
+ short_description: "Review code architecture, security, performance, and clarity"
4
+ default_prompt: "Use $quality-code-review to review this candidate change for contract alignment, architecture, security, reliability, and performance."
@@ -0,0 +1,13 @@
1
+ # Semantic code review coverage
2
+
3
+ Review:
4
+
5
+ - spec and acceptance alignment; no undocumented public behavior;
6
+ - dependency direction, ownership, public boundaries, cohesion, coupling, and duplicate policy;
7
+ - clear naming, small cohesive units, explicit errors, minimal abstraction, removed task-created dead code, and tests focused on behavior;
8
+ - input validation, identity/trust source, authorization, injection, secrets, sensitive output, unsafe execution, dependency risk, and denial-of-service;
9
+ - algorithmic complexity, allocation, I/O, query shape, batching, backpressure, caching correctness, concurrency, and measurable budgets;
10
+ - timeout, cancellation, retry, idempotency, atomicity, recovery, compatibility, observability, redaction, and diagnostics;
11
+ - product-path use of new code and negative tests for forbidden paths.
12
+
13
+ Do not claim a performance defect from aesthetics alone. Provide a complexity argument, workload bound, query plan, benchmark, profile, or clearly labelled risk requiring measurement.