dic-workflow-kit 1.1.3 → 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.
- package/.codex-plugin/plugin.json +14 -10
- package/CHANGELOG.md +56 -1
- package/INSTRUCTION.md +108 -29
- package/README.md +234 -134
- package/README.zh-CN.md +280 -194
- package/adapters/bitfun/README.md +2 -2
- package/agents/adversarial-challenger.md +23 -0
- package/agents/code-repairer.md +1 -1
- package/agents/contract-oracle.md +1 -1
- package/agents/evidence-auditor.md +23 -0
- package/agents/final-reviewer.md +13 -2
- package/agents/flow-auditor.md +1 -1
- package/agents/impact-analyst.md +21 -0
- package/agents/impl-inspector.md +1 -1
- package/agents/profile-builder.md +7 -3
- package/agents/repair-planner.md +1 -1
- package/agents/semantic-conflict-auditor.md +21 -0
- package/agents/spec-reader.md +1 -1
- package/agents/validation-runner.md +1 -1
- package/dist/dic-workflow-kit.mjs +17 -13
- package/package.json +5 -2
- package/schemas/final-result.schema.json +16 -1
- package/schemas/harness-plan.schema.json +143 -0
- package/schemas/harness-run.schema.json +75 -0
- package/schemas/ontology-action.schema.json +9 -1
- package/schemas/ontology-snapshot.schema.json +75 -1
- package/schemas/project-profile.schema.json +42 -0
- package/skills/knowledge-bdd/SKILL.md +1 -1
- package/skills/knowledge-change-impact/SKILL.md +43 -0
- package/skills/knowledge-change-impact/agents/openai.yaml +4 -0
- package/skills/knowledge-openspec/SKILL.md +1 -1
- package/skills/knowledge-repair-distill/SKILL.md +1 -1
- package/skills/quality-adversarial-challenge/SKILL.md +42 -0
- package/skills/quality-adversarial-challenge/agents/openai.yaml +4 -0
- package/skills/quality-ci-gate/SKILL.md +45 -0
- package/skills/quality-ci-gate/agents/openai.yaml +4 -0
- package/skills/quality-ci-gate/references/ci-gate.md +22 -0
- package/skills/quality-code-review/SKILL.md +32 -0
- package/skills/quality-code-review/agents/openai.yaml +4 -0
- package/skills/quality-code-review/references/code-review.md +13 -0
- package/skills/quality-cross-spec-consistency/SKILL.md +45 -0
- package/skills/quality-cross-spec-consistency/agents/openai.yaml +4 -0
- package/skills/quality-dt-review/SKILL.md +32 -0
- package/skills/quality-dt-review/agents/openai.yaml +4 -0
- package/skills/quality-dt-review/references/dt-review.md +14 -0
- package/skills/quality-evidence-audit/SKILL.md +41 -0
- package/skills/quality-evidence-audit/agents/openai.yaml +4 -0
- package/skills/quality-repository-gate/SKILL.md +38 -0
- package/skills/quality-repository-gate/agents/openai.yaml +4 -0
- package/skills/quality-repository-gate/references/repository-gate.md +13 -0
- package/skills/quality-review-orchestrator/SKILL.md +100 -0
- package/skills/quality-review-orchestrator/agents/openai.yaml +4 -0
- package/skills/quality-review-orchestrator/references/quality-model.md +73 -0
- package/skills/quality-spec-review/SKILL.md +40 -0
- package/skills/quality-spec-review/agents/openai.yaml +4 -0
- package/skills/quality-spec-review/references/spec-review.md +14 -0
- package/skills/quality-sr-ar-review/SKILL.md +32 -0
- package/skills/quality-sr-ar-review/agents/openai.yaml +4 -0
- package/skills/quality-sr-ar-review/references/sr-ar-review.md +14 -0
- package/skills/workflow-core/SKILL.md +49 -2
- package/skills/workflow-harness/SKILL.md +73 -0
- package/skills/workflow-harness/agents/openai.yaml +4 -0
- package/skills/workflow-intake/SKILL.md +8 -2
- package/skills/workflow-profile/SKILL.md +16 -1
- package/skills/workflow-repair/SKILL.md +7 -4
|
@@ -0,0 +1,143 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
3
|
+
"$id": "https://dicworkflowkit.local/schemas/harness-plan.schema.json",
|
|
4
|
+
"title": "QIHENG Candidate-Bound Harness Plan",
|
|
5
|
+
"type": "object",
|
|
6
|
+
"required": [
|
|
7
|
+
"schema",
|
|
8
|
+
"planId",
|
|
9
|
+
"generatedAt",
|
|
10
|
+
"profileHash",
|
|
11
|
+
"candidate",
|
|
12
|
+
"gates"
|
|
13
|
+
],
|
|
14
|
+
"properties": {
|
|
15
|
+
"schema": { "const": "dic.harness-plan.v1" },
|
|
16
|
+
"planId": {
|
|
17
|
+
"type": "string",
|
|
18
|
+
"pattern": "^hplan-[a-f0-9]{16}$"
|
|
19
|
+
},
|
|
20
|
+
"generatedAt": { "type": "string", "format": "date-time" },
|
|
21
|
+
"profileHash": {
|
|
22
|
+
"type": "string",
|
|
23
|
+
"pattern": "^[a-f0-9]{64}$"
|
|
24
|
+
},
|
|
25
|
+
"candidate": { "$ref": "#/$defs/candidate" },
|
|
26
|
+
"gates": {
|
|
27
|
+
"type": "array",
|
|
28
|
+
"minItems": 1,
|
|
29
|
+
"items": { "$ref": "#/$defs/gate" }
|
|
30
|
+
}
|
|
31
|
+
},
|
|
32
|
+
"additionalProperties": false,
|
|
33
|
+
"$defs": {
|
|
34
|
+
"candidate": {
|
|
35
|
+
"type": "object",
|
|
36
|
+
"required": [
|
|
37
|
+
"id",
|
|
38
|
+
"ref",
|
|
39
|
+
"contentHash",
|
|
40
|
+
"head",
|
|
41
|
+
"clean",
|
|
42
|
+
"trackedDiffHash",
|
|
43
|
+
"untracked"
|
|
44
|
+
],
|
|
45
|
+
"properties": {
|
|
46
|
+
"id": {
|
|
47
|
+
"type": "string",
|
|
48
|
+
"pattern": "^candidate-[a-f0-9]{16}$"
|
|
49
|
+
},
|
|
50
|
+
"ref": { "type": "string", "minLength": 1 },
|
|
51
|
+
"contentHash": {
|
|
52
|
+
"type": "string",
|
|
53
|
+
"pattern": "^[a-f0-9]{64}$"
|
|
54
|
+
},
|
|
55
|
+
"head": { "type": "string", "minLength": 1 },
|
|
56
|
+
"clean": { "type": "boolean" },
|
|
57
|
+
"trackedDiffHash": {
|
|
58
|
+
"type": "string",
|
|
59
|
+
"pattern": "^[a-f0-9]{64}$"
|
|
60
|
+
},
|
|
61
|
+
"untracked": {
|
|
62
|
+
"type": "array",
|
|
63
|
+
"items": {
|
|
64
|
+
"type": "object",
|
|
65
|
+
"required": ["path", "contentHash"],
|
|
66
|
+
"properties": {
|
|
67
|
+
"path": { "type": "string", "minLength": 1 },
|
|
68
|
+
"contentHash": {
|
|
69
|
+
"type": "string",
|
|
70
|
+
"pattern": "^[a-f0-9]{64}$"
|
|
71
|
+
}
|
|
72
|
+
},
|
|
73
|
+
"additionalProperties": false
|
|
74
|
+
}
|
|
75
|
+
}
|
|
76
|
+
},
|
|
77
|
+
"additionalProperties": false
|
|
78
|
+
},
|
|
79
|
+
"gate": {
|
|
80
|
+
"type": "object",
|
|
81
|
+
"required": [
|
|
82
|
+
"id",
|
|
83
|
+
"domain",
|
|
84
|
+
"skill",
|
|
85
|
+
"agent",
|
|
86
|
+
"applicability",
|
|
87
|
+
"defaultDisposition",
|
|
88
|
+
"reason",
|
|
89
|
+
"dependsOn",
|
|
90
|
+
"invalidatedBy",
|
|
91
|
+
"requiredEvidence"
|
|
92
|
+
],
|
|
93
|
+
"properties": {
|
|
94
|
+
"id": {
|
|
95
|
+
"type": "string",
|
|
96
|
+
"pattern": "^[a-z][a-z0-9.-]+$"
|
|
97
|
+
},
|
|
98
|
+
"domain": {
|
|
99
|
+
"enum": [
|
|
100
|
+
"DESIGN",
|
|
101
|
+
"DELIVERY",
|
|
102
|
+
"DEVELOPMENT",
|
|
103
|
+
"TEST",
|
|
104
|
+
"ASSURANCE",
|
|
105
|
+
"ADMISSION"
|
|
106
|
+
]
|
|
107
|
+
},
|
|
108
|
+
"skill": { "type": "string", "minLength": 1 },
|
|
109
|
+
"agent": { "type": "string" },
|
|
110
|
+
"applicability": { "enum": ["REQUIRED", "CONDITIONAL"] },
|
|
111
|
+
"defaultDisposition": { "enum": ["RUN", "ASSESS"] },
|
|
112
|
+
"reason": { "type": "string", "minLength": 1 },
|
|
113
|
+
"dependsOn": {
|
|
114
|
+
"type": "array",
|
|
115
|
+
"items": { "type": "string" },
|
|
116
|
+
"uniqueItems": true
|
|
117
|
+
},
|
|
118
|
+
"invalidatedBy": {
|
|
119
|
+
"type": "array",
|
|
120
|
+
"items": {
|
|
121
|
+
"enum": [
|
|
122
|
+
"DESIGN",
|
|
123
|
+
"POLICY",
|
|
124
|
+
"IMPLEMENTATION",
|
|
125
|
+
"TEST",
|
|
126
|
+
"FIXTURE",
|
|
127
|
+
"PIPELINE",
|
|
128
|
+
"CANDIDATE"
|
|
129
|
+
]
|
|
130
|
+
},
|
|
131
|
+
"uniqueItems": true
|
|
132
|
+
},
|
|
133
|
+
"requiredEvidence": {
|
|
134
|
+
"type": "array",
|
|
135
|
+
"minItems": 1,
|
|
136
|
+
"items": { "type": "string", "minLength": 1 },
|
|
137
|
+
"uniqueItems": true
|
|
138
|
+
}
|
|
139
|
+
},
|
|
140
|
+
"additionalProperties": false
|
|
141
|
+
}
|
|
142
|
+
}
|
|
143
|
+
}
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
3
|
+
"$id": "https://dicworkflowkit.local/schemas/harness-run.schema.json",
|
|
4
|
+
"title": "QIHENG Harness Run",
|
|
5
|
+
"type": "object",
|
|
6
|
+
"required": [
|
|
7
|
+
"schema",
|
|
8
|
+
"runId",
|
|
9
|
+
"planId",
|
|
10
|
+
"candidateHash",
|
|
11
|
+
"createdAt",
|
|
12
|
+
"updatedAt",
|
|
13
|
+
"gates"
|
|
14
|
+
],
|
|
15
|
+
"properties": {
|
|
16
|
+
"schema": { "const": "dic.harness-run.v1" },
|
|
17
|
+
"runId": {
|
|
18
|
+
"type": "string",
|
|
19
|
+
"pattern": "^hrun-[a-f0-9]{16}$"
|
|
20
|
+
},
|
|
21
|
+
"planId": {
|
|
22
|
+
"type": "string",
|
|
23
|
+
"pattern": "^hplan-[a-f0-9]{16}$"
|
|
24
|
+
},
|
|
25
|
+
"candidateHash": {
|
|
26
|
+
"type": "string",
|
|
27
|
+
"pattern": "^[a-f0-9]{64}$"
|
|
28
|
+
},
|
|
29
|
+
"createdAt": { "type": "string", "format": "date-time" },
|
|
30
|
+
"updatedAt": { "type": "string", "format": "date-time" },
|
|
31
|
+
"gates": {
|
|
32
|
+
"type": "array",
|
|
33
|
+
"minItems": 1,
|
|
34
|
+
"items": {
|
|
35
|
+
"type": "object",
|
|
36
|
+
"required": ["gateId", "status", "summary", "evidence"],
|
|
37
|
+
"properties": {
|
|
38
|
+
"gateId": { "type": "string", "minLength": 1 },
|
|
39
|
+
"status": {
|
|
40
|
+
"enum": [
|
|
41
|
+
"NOT_RUN",
|
|
42
|
+
"RUNNING",
|
|
43
|
+
"PASS",
|
|
44
|
+
"PASS_WITH_FOLLOW_UP",
|
|
45
|
+
"BLOCKED",
|
|
46
|
+
"FAIL",
|
|
47
|
+
"SKIPPED",
|
|
48
|
+
"STALE"
|
|
49
|
+
]
|
|
50
|
+
},
|
|
51
|
+
"summary": { "type": "string" },
|
|
52
|
+
"startedAt": { "type": "string", "format": "date-time" },
|
|
53
|
+
"completedAt": { "type": "string", "format": "date-time" },
|
|
54
|
+
"evidence": {
|
|
55
|
+
"type": "array",
|
|
56
|
+
"items": {
|
|
57
|
+
"type": "object",
|
|
58
|
+
"required": ["path", "contentHash"],
|
|
59
|
+
"properties": {
|
|
60
|
+
"path": { "type": "string", "minLength": 1 },
|
|
61
|
+
"contentHash": {
|
|
62
|
+
"type": "string",
|
|
63
|
+
"pattern": "^[a-f0-9]{64}$"
|
|
64
|
+
}
|
|
65
|
+
},
|
|
66
|
+
"additionalProperties": false
|
|
67
|
+
}
|
|
68
|
+
}
|
|
69
|
+
},
|
|
70
|
+
"additionalProperties": false
|
|
71
|
+
}
|
|
72
|
+
}
|
|
73
|
+
},
|
|
74
|
+
"additionalProperties": false
|
|
75
|
+
}
|
|
@@ -34,7 +34,15 @@
|
|
|
34
34
|
"AttachEvidence",
|
|
35
35
|
"CloseGap",
|
|
36
36
|
"MarkBlocked",
|
|
37
|
-
"SupersedeSource"
|
|
37
|
+
"SupersedeSource",
|
|
38
|
+
"RegisterCandidate",
|
|
39
|
+
"RecordGateRun",
|
|
40
|
+
"AssertClaim",
|
|
41
|
+
"ChallengeClaim",
|
|
42
|
+
"RecordCounterexample",
|
|
43
|
+
"RecordDecision",
|
|
44
|
+
"RecordWaiver",
|
|
45
|
+
"RegisterPolicy"
|
|
38
46
|
]
|
|
39
47
|
},
|
|
40
48
|
"actor": { "type": "string", "minLength": 1 },
|
|
@@ -98,7 +98,14 @@
|
|
|
98
98
|
"Evidence",
|
|
99
99
|
"AgentRun",
|
|
100
100
|
"Decision",
|
|
101
|
-
"Risk"
|
|
101
|
+
"Risk",
|
|
102
|
+
"Candidate",
|
|
103
|
+
"GateRun",
|
|
104
|
+
"Claim",
|
|
105
|
+
"Challenge",
|
|
106
|
+
"Counterexample",
|
|
107
|
+
"Waiver",
|
|
108
|
+
"Policy"
|
|
102
109
|
]
|
|
103
110
|
},
|
|
104
111
|
"lifecycle": { "$ref": "#/$defs/lifecycle" },
|
|
@@ -186,6 +193,65 @@
|
|
|
186
193
|
}
|
|
187
194
|
}
|
|
188
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
|
+
}
|
|
189
255
|
}
|
|
190
256
|
],
|
|
191
257
|
"additionalProperties": false
|
|
@@ -221,6 +287,14 @@
|
|
|
221
287
|
"SUPPORTS",
|
|
222
288
|
"CONTRADICTS",
|
|
223
289
|
"REMAINS_AFTER",
|
|
290
|
+
"EVALUATES",
|
|
291
|
+
"DECIDES",
|
|
292
|
+
"ASSERTS",
|
|
293
|
+
"CHALLENGES",
|
|
294
|
+
"REFUTES",
|
|
295
|
+
"SUPPORTED_BY",
|
|
296
|
+
"WAIVES",
|
|
297
|
+
"GOVERNS",
|
|
224
298
|
"SUPERSEDES"
|
|
225
299
|
]
|
|
226
300
|
},
|
|
@@ -12,6 +12,22 @@
|
|
|
12
12
|
"adapters": { "type": "array", "items": { "type": "string" } },
|
|
13
13
|
"bddSources": { "type": "array", "items": { "type": "string" } },
|
|
14
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
|
+
},
|
|
15
31
|
"designEntry": {
|
|
16
32
|
"type": "object",
|
|
17
33
|
"required": ["type", "changeId", "lifecycle", "changeRoot", "documents", "deltaSpecs", "baselineSpecs"],
|
|
@@ -40,6 +56,32 @@
|
|
|
40
56
|
},
|
|
41
57
|
"deltaSpecs": { "type": "array", "items": { "type": "string" } },
|
|
42
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
|
+
},
|
|
43
85
|
"designSources": { "type": "array", "items": { "type": "string" } },
|
|
44
86
|
"implementationRoots": { "type": "array", "items": { "type": "string" } },
|
|
45
87
|
"testRoots": { "type": "array", "items": { "type": "string" } },
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: knowledge-bdd
|
|
3
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
4
|
metadata:
|
|
5
|
-
version: 1.1.
|
|
5
|
+
version: 1.1.4
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
# Knowledge: BDD
|
|
@@ -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.
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: knowledge-repair-distill
|
|
3
3
|
description: Generic repair convergence guidance, gap taxonomy, model steering hints, and validation gates for design-implementation consistency work.
|
|
4
4
|
metadata:
|
|
5
|
-
version: 1.1.
|
|
5
|
+
version: 1.1.4
|
|
6
6
|
---
|
|
7
7
|
|
|
8
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,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,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.
|