@dzhechkov/keysarium 1.1.1 → 1.2.0
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/package.json +10 -2
- package/src/commands/init.js +1 -1
- package/templates/.claude/commands/dream.md +101 -0
- package/templates/.claude/commands/feature-adr.md +92 -0
- package/templates/.claude/commands/init-platform.md +161 -0
- package/templates/.claude/commands/learning-stats.md +130 -0
- package/templates/.claude/commands/workers.md +140 -0
- package/templates/.claude/rules/background-workers.md +72 -0
- package/templates/.claude/rules/dream-cycles.md +90 -0
- package/templates/.claude/rules/feature-adr-conventions.md +82 -0
- package/templates/.claude/rules/reward-learning.md +124 -0
- package/templates/.claude/shards/feature-adr.shard.md +98 -0
- package/templates/.claude/skills/feature-adr/SKILL.md +252 -0
- package/templates/.claude/skills/feature-adr/examples/sample-feature-output.md +257 -0
- package/templates/.claude/skills/feature-adr/modules/00-complexity-router.md +114 -0
- package/templates/.claude/skills/feature-adr/modules/01-requirements.md +113 -0
- package/templates/.claude/skills/feature-adr/modules/02-research.md +92 -0
- package/templates/.claude/skills/feature-adr/modules/03-adr.md +135 -0
- package/templates/.claude/skills/feature-adr/modules/04-ddd.md +114 -0
- package/templates/.claude/skills/feature-adr/modules/05-architecture.md +149 -0
- package/templates/.claude/skills/feature-adr/modules/06-implementation-plan.md +129 -0
- package/templates/.claude/skills/feature-adr/modules/07-code.md +126 -0
- package/templates/.claude/skills/feature-adr/modules/08-qe.md +167 -0
- package/templates/.claude/skills/feature-adr/references/adr-template.md +102 -0
- package/templates/.claude/skills/feature-adr/references/c4-template.md +120 -0
- package/templates/.claude/skills/feature-adr/references/complexity-matrix.md +139 -0
- package/templates/.claude/skills/feature-adr/references/qe-checklist.md +86 -0
- package/templates/CLAUDE.md +124 -3
- package/templates/docs/improvement-directions.md +16 -16
- package/templates/docs/keysarium/01-deployment-guide.md +21 -12
- package/templates/docs/keysarium/02-admin-guide.md +204 -3
- package/templates/docs/keysarium/03-user-guide.md +224 -0
- package/templates/docs/keysarium/05-architecture.md +181 -0
- package/templates/docs/keysarium/06-user-flows.md +235 -0
- package/templates/lib/background-workers.md +278 -0
- package/templates/lib/dream-engine.md +460 -0
- package/templates/lib/judge-attestation.md +322 -0
- package/templates/lib/memory-protocol.md +239 -0
- package/templates/lib/platform-adapters.md +100 -0
- package/templates/lib/platform-templates/copilot.md +134 -0
- package/templates/lib/platform-templates/cursor.md +95 -0
- package/templates/lib/platform-templates/opencode.md +155 -0
- package/templates/lib/reward-tracker.md +256 -0
- package/templates/lib/witness-chain.md +372 -0
- package/templates/lib/worker-templates/brain-export.md +187 -0
- package/templates/lib/worker-templates/consolidate.md +180 -0
- package/templates/lib/worker-templates/dream-cycle.md +154 -0
- package/templates/lib/worker-templates/health-check.md +255 -0
|
@@ -0,0 +1,180 @@
|
|
|
1
|
+
# Worker Template: Pattern Consolidation
|
|
2
|
+
|
|
3
|
+
> This file is loaded by the background worker agent. It contains the complete
|
|
4
|
+
> instructions for executing the consolidation task.
|
|
5
|
+
|
|
6
|
+
## Worker Identity
|
|
7
|
+
|
|
8
|
+
- **Type:** consolidate
|
|
9
|
+
- **Model:** sonnet
|
|
10
|
+
- **Purpose:** Scan completed researches for universal patterns and generate a harvest delta
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
You are a background worker agent. Your job is to analyze completed research cases
|
|
15
|
+
and extract reusable patterns. You operate in ISOLATION -- you must not modify any
|
|
16
|
+
files outside your output directory.
|
|
17
|
+
|
|
18
|
+
### Input Parameters
|
|
19
|
+
|
|
20
|
+
These will be injected by the orchestrator:
|
|
21
|
+
|
|
22
|
+
- `WORKER_ID`: Your unique worker identifier
|
|
23
|
+
- `OUTPUT_DIR`: Your output directory path (`.keysarium/workers/{WORKER_ID}/`)
|
|
24
|
+
|
|
25
|
+
### Execution Steps
|
|
26
|
+
|
|
27
|
+
#### Step 1: Initialize
|
|
28
|
+
|
|
29
|
+
Write your status file:
|
|
30
|
+
|
|
31
|
+
```json
|
|
32
|
+
// Write to {OUTPUT_DIR}/status.json
|
|
33
|
+
{
|
|
34
|
+
"worker_id": "{WORKER_ID}",
|
|
35
|
+
"type": "consolidate",
|
|
36
|
+
"status": "running",
|
|
37
|
+
"started_at": "{current ISO8601 timestamp}",
|
|
38
|
+
"completed_at": null,
|
|
39
|
+
"progress": {
|
|
40
|
+
"phase": "initializing",
|
|
41
|
+
"items_processed": 0
|
|
42
|
+
},
|
|
43
|
+
"error": null
|
|
44
|
+
}
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
#### Step 2: Scan Researches
|
|
48
|
+
|
|
49
|
+
1. List all directories under `researches/`
|
|
50
|
+
2. For each research directory, check for completion markers:
|
|
51
|
+
- File `08_executive_summary.md` exists (indicates completed case)
|
|
52
|
+
- File `README.md` exists (indicates packaging done)
|
|
53
|
+
3. Build a list of completed research slugs
|
|
54
|
+
4. Update status: `"phase": "scanning researches", "items_processed": {count}`
|
|
55
|
+
|
|
56
|
+
**IMPORTANT:** Check for `{OUTPUT_DIR}/stop-requested` file. If it exists, write
|
|
57
|
+
status as `stopped` and exit immediately.
|
|
58
|
+
|
|
59
|
+
#### Step 3: Analyze Patterns
|
|
60
|
+
|
|
61
|
+
For each completed research:
|
|
62
|
+
|
|
63
|
+
1. Read `00_product_discovery.md` -- extract domain, JTBD segments
|
|
64
|
+
2. Read `02_research_findings.md` -- extract key findings, technologies
|
|
65
|
+
3. Read `03_solution_strategy.md` -- extract solution patterns
|
|
66
|
+
4. Read `05_presentation_content.md` -- extract storytelling patterns
|
|
67
|
+
|
|
68
|
+
Look for:
|
|
69
|
+
- **Domain patterns**: Which domains appear most? What works in each?
|
|
70
|
+
- **Technology patterns**: Which technologies are recommended repeatedly?
|
|
71
|
+
- **Solution patterns**: Which problem-solving frameworks yield best results?
|
|
72
|
+
- **Anti-patterns**: Which approaches were rejected and why?
|
|
73
|
+
- **Time patterns**: Which phases tend to take longer than budgeted?
|
|
74
|
+
|
|
75
|
+
Update status: `"phase": "analyzing patterns", "items_processed": {count}`
|
|
76
|
+
|
|
77
|
+
**IMPORTANT:** Check for `stop-requested` file between each research analysis.
|
|
78
|
+
|
|
79
|
+
#### Step 4: Generate Output
|
|
80
|
+
|
|
81
|
+
Write the following files to `{OUTPUT_DIR}/output/`:
|
|
82
|
+
|
|
83
|
+
**patterns.json:**
|
|
84
|
+
```json
|
|
85
|
+
{
|
|
86
|
+
"generated_at": "{timestamp}",
|
|
87
|
+
"worker_id": "{WORKER_ID}",
|
|
88
|
+
"cases_analyzed": 5,
|
|
89
|
+
"patterns": [
|
|
90
|
+
{
|
|
91
|
+
"type": "domain",
|
|
92
|
+
"name": "Banking cases need on-premise LLM",
|
|
93
|
+
"frequency": 3,
|
|
94
|
+
"confidence": "high",
|
|
95
|
+
"source_cases": ["bank_kc_automation", "bank_risk_scoring"]
|
|
96
|
+
},
|
|
97
|
+
{
|
|
98
|
+
"type": "technology",
|
|
99
|
+
"name": "GigaChat preferred for Russian-language banking",
|
|
100
|
+
"frequency": 2,
|
|
101
|
+
"confidence": "medium",
|
|
102
|
+
"source_cases": ["bank_kc_automation"]
|
|
103
|
+
}
|
|
104
|
+
],
|
|
105
|
+
"anti_patterns": [
|
|
106
|
+
{
|
|
107
|
+
"name": "Generic GPT without architecture",
|
|
108
|
+
"occurrences": 1,
|
|
109
|
+
"fix": "Always specify concrete model + pipeline"
|
|
110
|
+
}
|
|
111
|
+
],
|
|
112
|
+
"recommendations": [
|
|
113
|
+
"Consider increasing Phase 2 time budget for banking domain (observed 2x overrun)",
|
|
114
|
+
"TRIZ framework shows higher success rate than Game Theory for retail cases"
|
|
115
|
+
]
|
|
116
|
+
}
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
**harvest-delta.md:**
|
|
120
|
+
```markdown
|
|
121
|
+
# Harvest Delta — {timestamp}
|
|
122
|
+
|
|
123
|
+
## New Patterns Discovered
|
|
124
|
+
|
|
125
|
+
### Domain Patterns
|
|
126
|
+
- [pattern description with source cases]
|
|
127
|
+
|
|
128
|
+
### Technology Patterns
|
|
129
|
+
- [pattern description with source cases]
|
|
130
|
+
|
|
131
|
+
### Solution Patterns
|
|
132
|
+
- [pattern description with source cases]
|
|
133
|
+
|
|
134
|
+
## Recommendations
|
|
135
|
+
|
|
136
|
+
- [actionable recommendation]
|
|
137
|
+
|
|
138
|
+
## Application Instructions
|
|
139
|
+
|
|
140
|
+
To apply these findings to TOOLKIT_HARVEST.md, review the patterns above and
|
|
141
|
+
manually merge the relevant ones. This worker does NOT modify TOOLKIT_HARVEST.md
|
|
142
|
+
directly to preserve isolation.
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
#### Step 5: Complete
|
|
146
|
+
|
|
147
|
+
1. Read `TOOLKIT_HARVEST.md` if it exists -- note its current content for context
|
|
148
|
+
(do NOT modify it)
|
|
149
|
+
2. Write final status:
|
|
150
|
+
|
|
151
|
+
```json
|
|
152
|
+
{
|
|
153
|
+
"worker_id": "{WORKER_ID}",
|
|
154
|
+
"type": "consolidate",
|
|
155
|
+
"status": "completed",
|
|
156
|
+
"started_at": "{start timestamp}",
|
|
157
|
+
"completed_at": "{current timestamp}",
|
|
158
|
+
"progress": {
|
|
159
|
+
"phase": "completed",
|
|
160
|
+
"items_processed": "{total cases analyzed}"
|
|
161
|
+
},
|
|
162
|
+
"error": null
|
|
163
|
+
}
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
### Error Handling
|
|
167
|
+
|
|
168
|
+
If any step fails:
|
|
169
|
+
|
|
170
|
+
1. Write error details to `{OUTPUT_DIR}/error.log`
|
|
171
|
+
2. Update status.json with status `failed` and error message
|
|
172
|
+
3. Exit
|
|
173
|
+
|
|
174
|
+
### Isolation Rules
|
|
175
|
+
|
|
176
|
+
- You MUST only write files to `{OUTPUT_DIR}/`
|
|
177
|
+
- You MUST NOT modify any file in `researches/`, `features/`, `.claude/`, or project root
|
|
178
|
+
- You MUST NOT modify `TOOLKIT_HARVEST.md` (write delta to your output dir instead)
|
|
179
|
+
- You MUST NOT spawn sub-agents
|
|
180
|
+
- You MAY read any file in the project for analysis purposes
|
|
@@ -0,0 +1,154 @@
|
|
|
1
|
+
# Worker Template: Dream Cycle
|
|
2
|
+
|
|
3
|
+
> This file is loaded by the background worker agent. It contains the complete
|
|
4
|
+
> instructions for executing a dream cycle using the DreamEngine protocol.
|
|
5
|
+
|
|
6
|
+
## Worker Identity
|
|
7
|
+
|
|
8
|
+
- **Type:** dream-cycle
|
|
9
|
+
- **Model:** sonnet
|
|
10
|
+
- **Purpose:** Build concept graph from reward records, detect cross-domain associations, generate actionable insights
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
You are a background worker agent. Your job is to analyze accumulated reward records
|
|
15
|
+
and generate higher-order insights using the DreamEngine protocol defined in
|
|
16
|
+
`lib/dream-engine.md`. You operate in ISOLATION -- you must not modify any files
|
|
17
|
+
outside your output directory and `.keysarium/insights/`.
|
|
18
|
+
|
|
19
|
+
### Input Parameters
|
|
20
|
+
|
|
21
|
+
These will be injected by the orchestrator:
|
|
22
|
+
|
|
23
|
+
- `WORKER_ID`: Your unique worker identifier
|
|
24
|
+
- `OUTPUT_DIR`: Your output directory path (`.keysarium/workers/{WORKER_ID}/`)
|
|
25
|
+
- `TRIGGER_REASON`: Why this dream was triggered (`time` | `volume` | `event` | `manual`)
|
|
26
|
+
|
|
27
|
+
### Execution Steps
|
|
28
|
+
|
|
29
|
+
#### Step 1: Initialize
|
|
30
|
+
|
|
31
|
+
Write your status file:
|
|
32
|
+
|
|
33
|
+
```json
|
|
34
|
+
// Write to {OUTPUT_DIR}/status.json
|
|
35
|
+
{
|
|
36
|
+
"worker_id": "{WORKER_ID}",
|
|
37
|
+
"type": "dream-cycle",
|
|
38
|
+
"status": "running",
|
|
39
|
+
"started_at": "{current ISO8601 timestamp}",
|
|
40
|
+
"completed_at": null,
|
|
41
|
+
"progress": {
|
|
42
|
+
"phase": "initializing",
|
|
43
|
+
"items_processed": 0
|
|
44
|
+
},
|
|
45
|
+
"error": null
|
|
46
|
+
}
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
#### Step 2: Load Data
|
|
50
|
+
|
|
51
|
+
Follow the DreamEngine Step 1 (Load Data) protocol from `lib/dream-engine.md`:
|
|
52
|
+
|
|
53
|
+
1. Check if `.keysarium/memory/` exists. If not, write status `completed` with `"phase": "no_data"` and exit.
|
|
54
|
+
2. Read `.keysarium/memory/_stats/reward-summary.json` (optional).
|
|
55
|
+
3. Read `.keysarium/memory/_patterns/domain-patterns.json` (optional).
|
|
56
|
+
4. Scan and parse all reward record JSON files under `.keysarium/memory/`.
|
|
57
|
+
5. Exclude expired records, sort by reward DESC, take top 200.
|
|
58
|
+
6. If fewer than 5 records: write status `completed` with `"phase": "insufficient_data"` and exit.
|
|
59
|
+
|
|
60
|
+
Update status: `"phase": "loading data", "items_processed": {record_count}`
|
|
61
|
+
|
|
62
|
+
**IMPORTANT:** Check for `{OUTPUT_DIR}/stop-requested` file. If it exists, write status as `stopped` and exit immediately.
|
|
63
|
+
|
|
64
|
+
#### Step 3: Build Concept Graph
|
|
65
|
+
|
|
66
|
+
Follow the DreamEngine Step 2 (Build Concept Graph) protocol:
|
|
67
|
+
|
|
68
|
+
1. Initialize empty graph.
|
|
69
|
+
2. For each record, create/update domain, phase, skill, and outcome nodes.
|
|
70
|
+
3. Create/update edges with reward weights.
|
|
71
|
+
4. Compute per-node aggregates (avg_reward, record_count, trend).
|
|
72
|
+
5. Compute per-edge aggregates (weight, record_count).
|
|
73
|
+
|
|
74
|
+
Update status: `"phase": "building concept graph", "items_processed": {node_count}`
|
|
75
|
+
|
|
76
|
+
**IMPORTANT:** Check for `stop-requested` file.
|
|
77
|
+
|
|
78
|
+
#### Step 4: Detect Associations
|
|
79
|
+
|
|
80
|
+
Follow the DreamEngine Step 3 (Detect Associations) protocol:
|
|
81
|
+
|
|
82
|
+
1. Cross-domain phase comparison (reward gap > 0.15).
|
|
83
|
+
2. Skill-domain mismatch detection (reward gap > 0.15).
|
|
84
|
+
3. Phase correlation analysis (co-occurring low rewards).
|
|
85
|
+
4. Temporal trend detection (systematic changes over time).
|
|
86
|
+
|
|
87
|
+
Update status: `"phase": "detecting associations", "items_processed": {association_count}`
|
|
88
|
+
|
|
89
|
+
**IMPORTANT:** Check for `stop-requested` file.
|
|
90
|
+
|
|
91
|
+
#### Step 5: Generate Insights
|
|
92
|
+
|
|
93
|
+
Follow the DreamEngine Step 4 (Generate Insights) protocol:
|
|
94
|
+
|
|
95
|
+
1. Convert each association to an Insight object.
|
|
96
|
+
2. Map association types to insight types.
|
|
97
|
+
3. Score confidence and impact.
|
|
98
|
+
4. Add actionable advice to descriptions.
|
|
99
|
+
5. Promote high-confidence domain patterns to insights.
|
|
100
|
+
6. Deduplicate against recent dreams (last 3 files in `.keysarium/insights/`).
|
|
101
|
+
7. Sort by rank_score DESC, take top 20.
|
|
102
|
+
|
|
103
|
+
Update status: `"phase": "generating insights", "items_processed": {insight_count}`
|
|
104
|
+
|
|
105
|
+
#### Step 6: Store Results
|
|
106
|
+
|
|
107
|
+
Follow the DreamEngine Step 5 (Store and Clean) protocol:
|
|
108
|
+
|
|
109
|
+
1. Ensure `.keysarium/insights/` directory exists.
|
|
110
|
+
2. Write dream result JSON to `.keysarium/insights/dream-{YYYYMMDD}-{HHmmss}.json`.
|
|
111
|
+
3. Apply retention: list dream files, keep newest 10, delete older.
|
|
112
|
+
4. Reset trigger state in `.keysarium/insights/trigger-state.json`.
|
|
113
|
+
5. Copy dream result to `{OUTPUT_DIR}/output/dream-{timestamp}.json`.
|
|
114
|
+
|
|
115
|
+
#### Step 7: Complete
|
|
116
|
+
|
|
117
|
+
Write final status:
|
|
118
|
+
|
|
119
|
+
```json
|
|
120
|
+
{
|
|
121
|
+
"worker_id": "{WORKER_ID}",
|
|
122
|
+
"type": "dream-cycle",
|
|
123
|
+
"status": "completed",
|
|
124
|
+
"started_at": "{start timestamp}",
|
|
125
|
+
"completed_at": "{current timestamp}",
|
|
126
|
+
"progress": {
|
|
127
|
+
"phase": "completed",
|
|
128
|
+
"records_analyzed": "{count}",
|
|
129
|
+
"insights_generated": "{count}",
|
|
130
|
+
"associations_found": "{count}"
|
|
131
|
+
},
|
|
132
|
+
"error": null
|
|
133
|
+
}
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
### Error Handling
|
|
137
|
+
|
|
138
|
+
If any step fails:
|
|
139
|
+
|
|
140
|
+
1. Write error details to `{OUTPUT_DIR}/error.log`
|
|
141
|
+
2. Update status.json with status `failed` and error message in the `error` field
|
|
142
|
+
3. Do NOT modify trigger-state.json on failure (preserve current trigger state)
|
|
143
|
+
4. Exit
|
|
144
|
+
|
|
145
|
+
### Isolation Rules
|
|
146
|
+
|
|
147
|
+
- You MUST only write files to `{OUTPUT_DIR}/` and `.keysarium/insights/`
|
|
148
|
+
- You MUST NOT modify any file in `researches/`, `features/`, `.claude/`, or project root
|
|
149
|
+
- You MUST NOT modify files in `.keysarium/memory/` (read-only access)
|
|
150
|
+
- You MUST NOT modify `TOOLKIT_HARVEST.md` or `CLAUDE.md`
|
|
151
|
+
- You MUST NOT spawn sub-agents
|
|
152
|
+
- You MAY read any file in the project for analysis purposes
|
|
153
|
+
- Exception: `.keysarium/insights/trigger-state.json` is writable (for reset on completion)
|
|
154
|
+
- Exception: `.keysarium/insights/dream-*.json` is writable (for new dream results and retention cleanup)
|
|
@@ -0,0 +1,255 @@
|
|
|
1
|
+
# Worker Template: Health Check
|
|
2
|
+
|
|
3
|
+
> This file is loaded by the background worker agent. It contains the complete
|
|
4
|
+
> instructions for executing the health check task.
|
|
5
|
+
|
|
6
|
+
## Worker Identity
|
|
7
|
+
|
|
8
|
+
- **Type:** health-check
|
|
9
|
+
- **Model:** haiku
|
|
10
|
+
- **Purpose:** Verify system health: skill trust tiers, data freshness, structural integrity
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
You are a background worker agent. Your job is to perform health checks on the
|
|
15
|
+
Keysarium system and produce a structured health report. You operate in ISOLATION --
|
|
16
|
+
you must not modify any files outside your output directory.
|
|
17
|
+
|
|
18
|
+
### Input Parameters
|
|
19
|
+
|
|
20
|
+
These will be injected by the orchestrator:
|
|
21
|
+
|
|
22
|
+
- `WORKER_ID`: Your unique worker identifier
|
|
23
|
+
- `OUTPUT_DIR`: Your output directory path (`.keysarium/workers/{WORKER_ID}/`)
|
|
24
|
+
|
|
25
|
+
### Execution Steps
|
|
26
|
+
|
|
27
|
+
#### Step 1: Initialize
|
|
28
|
+
|
|
29
|
+
Write your status file:
|
|
30
|
+
|
|
31
|
+
```json
|
|
32
|
+
{
|
|
33
|
+
"worker_id": "{WORKER_ID}",
|
|
34
|
+
"type": "health-check",
|
|
35
|
+
"status": "running",
|
|
36
|
+
"started_at": "{current ISO8601 timestamp}",
|
|
37
|
+
"completed_at": null,
|
|
38
|
+
"progress": { "phase": "initializing", "items_processed": 0 },
|
|
39
|
+
"error": null
|
|
40
|
+
}
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
#### Step 2: Check Skill Trust Tiers
|
|
44
|
+
|
|
45
|
+
For each skill directory in `.claude/skills/`:
|
|
46
|
+
|
|
47
|
+
1. Read `SKILL.md` -- check for `trust_tier` in frontmatter
|
|
48
|
+
2. Check if `references/` directory exists
|
|
49
|
+
3. Check if `modules/` directory exists
|
|
50
|
+
4. Check if `examples/` directory exists
|
|
51
|
+
5. Determine actual tier based on contents:
|
|
52
|
+
- Tier 0 (Advisory): Only SKILL.md
|
|
53
|
+
- Tier 1 (Structured): SKILL.md + references/ or modules/
|
|
54
|
+
- Tier 2 (Validated): Tier 1 + BTO test score >= 7.0 in metadata
|
|
55
|
+
- Tier 3 (Verified): Tier 2 + eval test suites
|
|
56
|
+
6. Compare claimed tier vs actual tier
|
|
57
|
+
7. Flag mismatches (claimed higher than actual)
|
|
58
|
+
|
|
59
|
+
Record results for each skill:
|
|
60
|
+
```json
|
|
61
|
+
{
|
|
62
|
+
"name": "skill-trust-tiers",
|
|
63
|
+
"status": "warn",
|
|
64
|
+
"message": "frontend-design claims Tier 0 but could be promoted to Tier 1",
|
|
65
|
+
"details": {
|
|
66
|
+
"skills": [
|
|
67
|
+
{ "name": "explore", "claimed": 1, "actual": 1, "match": true },
|
|
68
|
+
{ "name": "frontend-design", "claimed": 0, "actual": 0, "match": true, "promotion_hint": "Add references/ to reach Tier 1" }
|
|
69
|
+
]
|
|
70
|
+
}
|
|
71
|
+
}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
Update status: `"phase": "checking skill tiers", "items_processed": 1`
|
|
75
|
+
|
|
76
|
+
**Check for `stop-requested` file.**
|
|
77
|
+
|
|
78
|
+
#### Step 3: Check Governance Integrity
|
|
79
|
+
|
|
80
|
+
1. Verify all governance shards exist in `.claude/shards/`:
|
|
81
|
+
- `phase-0-discovery.shard.md`
|
|
82
|
+
- `phase-1-explore.shard.md`
|
|
83
|
+
- `phase-2-research.shard.md`
|
|
84
|
+
- `phase-25-cjm.shard.md`
|
|
85
|
+
- `phase-3-solve.shard.md`
|
|
86
|
+
- `phase-4-architecture.shard.md`
|
|
87
|
+
- `phase-5-presentation.shard.md`
|
|
88
|
+
- `bto-evaluation.shard.md`
|
|
89
|
+
- `feature-adr.shard.md`
|
|
90
|
+
2. Verify all rule files exist in `.claude/rules/`
|
|
91
|
+
3. Verify all commands exist in `.claude/commands/`
|
|
92
|
+
4. Check for any orphaned files (files not referenced in CLAUDE.md)
|
|
93
|
+
|
|
94
|
+
Record results:
|
|
95
|
+
```json
|
|
96
|
+
{
|
|
97
|
+
"name": "governance-integrity",
|
|
98
|
+
"status": "pass",
|
|
99
|
+
"message": "All 9 shards, 13 rules, and 20 commands present",
|
|
100
|
+
"details": { "shards": 9, "rules": 13, "commands": 20, "orphaned": 0 }
|
|
101
|
+
}
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
Update status: `"phase": "checking governance", "items_processed": 2`
|
|
105
|
+
|
|
106
|
+
**Check for `stop-requested` file.**
|
|
107
|
+
|
|
108
|
+
#### Step 4: Check Research Data Freshness
|
|
109
|
+
|
|
110
|
+
1. List all research directories in `researches/`
|
|
111
|
+
2. For each: check last modification date of files
|
|
112
|
+
3. Flag researches with incomplete artifact sets (missing required files)
|
|
113
|
+
4. Check if TOOLKIT_HARVEST.md has been updated recently
|
|
114
|
+
|
|
115
|
+
Record results:
|
|
116
|
+
```json
|
|
117
|
+
{
|
|
118
|
+
"name": "data-freshness",
|
|
119
|
+
"status": "pass",
|
|
120
|
+
"message": "3 completed researches, 0 stale, TOOLKIT_HARVEST.md current",
|
|
121
|
+
"details": {
|
|
122
|
+
"total_researches": 3,
|
|
123
|
+
"completed": 3,
|
|
124
|
+
"incomplete": 0,
|
|
125
|
+
"harvest_stale": false
|
|
126
|
+
}
|
|
127
|
+
}
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
Update status: `"phase": "checking data freshness", "items_processed": 3`
|
|
131
|
+
|
|
132
|
+
**Check for `stop-requested` file.**
|
|
133
|
+
|
|
134
|
+
#### Step 5: Check Witness Chain (if exists)
|
|
135
|
+
|
|
136
|
+
1. Check if `.keysarium/witness-chain/` exists
|
|
137
|
+
2. If yes, verify chain integrity (each hash links to previous)
|
|
138
|
+
3. Report any broken links
|
|
139
|
+
|
|
140
|
+
Record results:
|
|
141
|
+
```json
|
|
142
|
+
{
|
|
143
|
+
"name": "witness-chain",
|
|
144
|
+
"status": "pass",
|
|
145
|
+
"message": "Witness chain intact (12 entries, no breaks)",
|
|
146
|
+
"details": { "entries": 12, "broken_links": 0 }
|
|
147
|
+
}
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
If witness chain does not exist:
|
|
151
|
+
```json
|
|
152
|
+
{
|
|
153
|
+
"name": "witness-chain",
|
|
154
|
+
"status": "warn",
|
|
155
|
+
"message": "Witness chain not initialized (optional feature)",
|
|
156
|
+
"details": null
|
|
157
|
+
}
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
Update status: `"phase": "checking witness chain", "items_processed": 4`
|
|
161
|
+
|
|
162
|
+
#### Step 6: Check Worker System Health
|
|
163
|
+
|
|
164
|
+
1. Read `.keysarium/workers/registry.json` if it exists
|
|
165
|
+
2. Count stale entries (running but no status.json update in > 15 minutes)
|
|
166
|
+
3. Check for orphaned worker directories (no registry entry)
|
|
167
|
+
4. Report disk usage of `.keysarium/workers/` directory
|
|
168
|
+
|
|
169
|
+
Record results:
|
|
170
|
+
```json
|
|
171
|
+
{
|
|
172
|
+
"name": "worker-system",
|
|
173
|
+
"status": "pass",
|
|
174
|
+
"message": "Worker registry clean, 0 stale entries",
|
|
175
|
+
"details": { "total_entries": 5, "stale": 0, "orphaned": 0 }
|
|
176
|
+
}
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
Update status: `"phase": "checking worker system", "items_processed": 5`
|
|
180
|
+
|
|
181
|
+
#### Step 7: Check Brain/Memory State
|
|
182
|
+
|
|
183
|
+
1. Check if `keysarium-brain.json` or `.keysarium/exports/` exists
|
|
184
|
+
2. Verify brain file structure if present
|
|
185
|
+
3. Check for reward data (`.keysarium/rewards/` if exists)
|
|
186
|
+
|
|
187
|
+
Record results:
|
|
188
|
+
```json
|
|
189
|
+
{
|
|
190
|
+
"name": "brain-state",
|
|
191
|
+
"status": "pass",
|
|
192
|
+
"message": "Brain export available, last exported 2026-02-28",
|
|
193
|
+
"details": { "brain_exists": true, "last_export": "2026-02-28" }
|
|
194
|
+
}
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
Update status: `"phase": "checking brain state", "items_processed": 6`
|
|
198
|
+
|
|
199
|
+
#### Step 8: Generate Health Report
|
|
200
|
+
|
|
201
|
+
Write `{OUTPUT_DIR}/output/health-report.json`:
|
|
202
|
+
|
|
203
|
+
```json
|
|
204
|
+
{
|
|
205
|
+
"generated_at": "{timestamp}",
|
|
206
|
+
"worker_id": "{WORKER_ID}",
|
|
207
|
+
"summary": {
|
|
208
|
+
"total_checks": 6,
|
|
209
|
+
"passed": 5,
|
|
210
|
+
"warnings": 1,
|
|
211
|
+
"failures": 0,
|
|
212
|
+
"overall_status": "healthy"
|
|
213
|
+
},
|
|
214
|
+
"checks": [ /* all check results from steps 2-7 */ ],
|
|
215
|
+
"recommendations": [
|
|
216
|
+
"Run /bto-test on 'explore' skill to promote from Tier 1 to Tier 2",
|
|
217
|
+
"Consider initializing witness chain for audit trail"
|
|
218
|
+
]
|
|
219
|
+
}
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
Overall status logic:
|
|
223
|
+
- `healthy`: 0 failures, 0-2 warnings
|
|
224
|
+
- `degraded`: 0 failures, 3+ warnings
|
|
225
|
+
- `unhealthy`: 1+ failures
|
|
226
|
+
|
|
227
|
+
#### Step 9: Complete
|
|
228
|
+
|
|
229
|
+
Write final status:
|
|
230
|
+
|
|
231
|
+
```json
|
|
232
|
+
{
|
|
233
|
+
"worker_id": "{WORKER_ID}",
|
|
234
|
+
"type": "health-check",
|
|
235
|
+
"status": "completed",
|
|
236
|
+
"started_at": "{start timestamp}",
|
|
237
|
+
"completed_at": "{current timestamp}",
|
|
238
|
+
"progress": { "phase": "completed", "items_processed": 6 },
|
|
239
|
+
"error": null
|
|
240
|
+
}
|
|
241
|
+
```
|
|
242
|
+
|
|
243
|
+
### Error Handling
|
|
244
|
+
|
|
245
|
+
If any check step fails:
|
|
246
|
+
1. Record the failed check with status `fail` and error message
|
|
247
|
+
2. Continue to the next check (do not abort on individual check failure)
|
|
248
|
+
3. Only write `error.log` and set status `failed` if the entire worker crashes
|
|
249
|
+
|
|
250
|
+
### Isolation Rules
|
|
251
|
+
|
|
252
|
+
- You MUST only write files to `{OUTPUT_DIR}/`
|
|
253
|
+
- You MUST NOT modify any file in the project
|
|
254
|
+
- You MUST NOT spawn sub-agents
|
|
255
|
+
- You MAY read any file in the project for analysis purposes
|