@neikyun/ciel 6.11.0 → 6.11.2
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/assets/.claude/hooks/memory-engine.py +29 -4
- package/assets/.claude/settings.json +8 -8
- package/assets/commands/ciel-create-skill.md +2 -2
- package/assets/commands/ciel-status.md +1 -1
- package/assets/platforms/opencode/.opencode/agents/ciel-improver.md +2 -2
- package/assets/platforms/opencode/.opencode/commands/ciel-create-skill.md +2 -2
- package/assets/platforms/opencode/.opencode/commands/ciel-memory-bootstrap.md +195 -0
- package/assets/skills/workflow/adr-auto/SKILL.md +88 -0
- package/assets/skills/workflow/ai-failure-modes-detector/SKILL.md +180 -0
- package/assets/skills/workflow/ask-window/SKILL.md +119 -0
- package/assets/skills/workflow/avec-quoi-versioner/SKILL.md +111 -0
- package/assets/skills/workflow/ci-watcher/SKILL.md +194 -0
- package/assets/skills/workflow/critiquer-auditor/SKILL.md +135 -0
- package/assets/skills/workflow/critiquer-auditor/reference.md +134 -0
- package/assets/skills/workflow/debug-reasoning-rca/SKILL.md +174 -0
- package/assets/skills/workflow/depth-classifier/SKILL.md +118 -0
- package/assets/skills/workflow/diverge/SKILL.md +91 -0
- package/assets/skills/workflow/doc-validator-official/SKILL.md +196 -0
- package/assets/skills/workflow/evaluer-sizer/SKILL.md +112 -0
- package/assets/skills/workflow/faire-gatekeeper/SKILL.md +99 -0
- package/assets/skills/workflow/flux-narrator/SKILL.md +93 -0
- package/assets/skills/workflow/memoire/SKILL.md +198 -0
- package/assets/skills/workflow/memoire-consolidator/SKILL.md +91 -0
- package/assets/skills/workflow/meta-critiquer/SKILL.md +112 -0
- package/assets/skills/workflow/modern-patterns-checker/SKILL.md +166 -0
- package/assets/skills/workflow/pattern-fitness-check/SKILL.md +108 -0
- package/assets/skills/workflow/playwright-visual-critic/SKILL.md +98 -0
- package/assets/skills/workflow/pr-review-responder/SKILL.md +214 -0
- package/assets/skills/workflow/prouver-verifier/SKILL.md +184 -0
- package/assets/skills/workflow/prouver-verifier/reference.md +152 -0
- package/assets/skills/workflow/quoi-framer/SKILL.md +91 -0
- package/assets/skills/workflow/relire-critic/SKILL.md +99 -0
- package/assets/skills/workflow/security-regression-check/SKILL.md +86 -0
- package/assets/skills/workflow/self-consistency-verifier/SKILL.md +85 -0
- package/assets/skills/workflow/spike-mode/SKILL.md +101 -0
- package/assets/skills/workflow/stride-analyzer/SKILL.md +96 -0
- package/assets/skills/workflow/stride-analyzer/reference.md +144 -0
- package/assets/skills/workflow/test-strategy-vitest-playwright/SKILL.md +119 -0
- package/package.json +1 -1
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: evaluer-sizer
|
|
3
|
+
description: How to size and assess risk before coding — back-of-envelope sizing, pre-mortem (2 failure modes), recent-churn check, diverged alternatives (v5), and counterfactual ("what if we do nothing?"). For Ciel v5 pipeline step 9 (EVALUER). Use after DIVERGE and RECHERCHE, before ASK2.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Pre-Implementation Sizing — 5 Cheap Gates (Ciel v5)
|
|
7
|
+
|
|
8
|
+
## What this covers
|
|
9
|
+
|
|
10
|
+
How to sanity-check an approach before committing to it. In v5, this step follows DIVERGE (etape 5) which explored 2-3 approaches. Here we evaluate the selected approach. These 5 gates take 2 minutes and prevent hours of wasted work.
|
|
11
|
+
|
|
12
|
+
## Core principle
|
|
13
|
+
|
|
14
|
+
**Quantify before coding.** "Small memory footprint" is not sizing. "~2 MB × 10k entries = 20 MB" is.
|
|
15
|
+
|
|
16
|
+
## Gate 1: Back-of-envelope sizing
|
|
17
|
+
|
|
18
|
+
Compute rough estimates:
|
|
19
|
+
- Memory: bytes per row × row count
|
|
20
|
+
- Connections: concurrent users × connections per user
|
|
21
|
+
- Throughput: req/s × processing time per req
|
|
22
|
+
- Storage: items × avg size × retention
|
|
23
|
+
|
|
24
|
+
Does the solution fit in the budget? If caching requires 10 GB and the server has 2 GB -> wrong solution, don't start.
|
|
25
|
+
|
|
26
|
+
## Gate 2: Pre-mortem
|
|
27
|
+
|
|
28
|
+
State explicitly: "In production, this could fail in these 2 ways:"
|
|
29
|
+
1. <failure mode 1>
|
|
30
|
+
2. <failure mode 2>
|
|
31
|
+
|
|
32
|
+
Can't imagine 2 failure modes -> don't understand the system well enough.
|
|
33
|
+
|
|
34
|
+
## Gate 3: Recent churn
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
git log --oneline --since="7 days" -- <impacted files>
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
If 2+ commits in the last week touched the same module:
|
|
41
|
+
- Read those commits BEFORE proposing your fix
|
|
42
|
+
- Someone already fixed this area twice this week -> incomplete mental model
|
|
43
|
+
- Your "fix" might be the 3rd attempt at the same bug
|
|
44
|
+
|
|
45
|
+
## Gate 4: Diverged approach comparison (v5)
|
|
46
|
+
|
|
47
|
+
Compare the approaches explored during DIVERGE (etape 5):
|
|
48
|
+
- Approach A (from DIVERGE): <summary>
|
|
49
|
+
- Approach B (from DIVERGE): <summary>
|
|
50
|
+
- Selected: <A or B> because <reason>
|
|
51
|
+
- Why NOT the other: <specific limitation, not "it's worse">
|
|
52
|
+
|
|
53
|
+
If only 1 approach was explored -> DIVERGE was incomplete.
|
|
54
|
+
|
|
55
|
+
## Gate 5: Counterfactual
|
|
56
|
+
|
|
57
|
+
**Counterfactual**: "What if we do NOTHING?" If doing nothing solves 80% of the problem with 0 risk -> reconsider scope.
|
|
58
|
+
|
|
59
|
+
## Output format
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
## EVALUER
|
|
63
|
+
|
|
64
|
+
### Sizing
|
|
65
|
+
- Memory: <estimate>
|
|
66
|
+
- Connections: <estimate>
|
|
67
|
+
- Throughput: <estimate>
|
|
68
|
+
- Fit: <yes -- within budget | no -- what breaks>
|
|
69
|
+
|
|
70
|
+
### Pre-mortem (2 ways this could fail)
|
|
71
|
+
1. <failure mode>
|
|
72
|
+
2. <failure mode>
|
|
73
|
+
|
|
74
|
+
### Recent churn
|
|
75
|
+
- Commits in last 7 days: <N>
|
|
76
|
+
- Relevant: <list>
|
|
77
|
+
- Read them? <yes -- findings>
|
|
78
|
+
|
|
79
|
+
### Diverged approach comparison (v5)
|
|
80
|
+
- A: <summary>
|
|
81
|
+
- B: <summary>
|
|
82
|
+
- Selected: <A/B> because <reason>
|
|
83
|
+
|
|
84
|
+
### Counterfactual
|
|
85
|
+
- What if nothing? <consequence>
|
|
86
|
+
- 80% solve with 0 risk? <yes -> reconsider | no -> proceed>
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## How to verify
|
|
90
|
+
|
|
91
|
+
- [ ] Sizing has concrete numbers (request rate, data volume, latency budget)?
|
|
92
|
+
- [ ] Pre-mortem identifies >= 2 specific failure modes?
|
|
93
|
+
- [ ] Recent churn checked (git log for affected files)?
|
|
94
|
+
- [ ] >= 2 approaches compared from DIVERGE?
|
|
95
|
+
- [ ] Counterfactual stated ("what if we don't do this")?
|
|
96
|
+
- [ ] Selected approach justified with specific reason?
|
|
97
|
+
|
|
98
|
+
## Common rationalizations
|
|
99
|
+
|
|
100
|
+
| Rationalization | Reality |
|
|
101
|
+
|---|---|
|
|
102
|
+
| "I'll size it as I go" | Sizing after coding is guessing. Sizing before prevents committing to the wrong approach. |
|
|
103
|
+
| "I can't estimate without coding" | Back-of-envelope takes 2 minutes. 2 minutes of thinking saves 2 hours of coding the wrong thing. |
|
|
104
|
+
| "Pre-mortem is pessimistic" | Pre-mortem is the cheapest bug fix you'll ever write. Imagining failure costs nothing. Production failure costs everything. |
|
|
105
|
+
| "Diverging is a waste of time, the first approach is fine" | The first approach is rarely the best. It's just the first. Generating 2-3 approaches takes 5 minutes. Committing to the wrong one takes days. |
|
|
106
|
+
|
|
107
|
+
## Common mistakes
|
|
108
|
+
|
|
109
|
+
- **Hand-waving sizing**: "small footprint" without numbers
|
|
110
|
+
- **Pre-mortem = tests**: "might have bugs" is useless. "Query times out at > 10k notifications" is useful.
|
|
111
|
+
- **Fake alternatives**: "React over Assembly" is not real. "Page vs cursor pagination because API is public" is real.
|
|
112
|
+
- **Single-approach bias (v5)**: if DIVERGE was skipped, EVALUER cannot compare alternatives. Go back to DIVERGE.
|
|
@@ -0,0 +1,99 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: faire-gatekeeper
|
|
3
|
+
description: How to implement code safely — 6 quality gates for Ciel v5 (test-first, alternatives, idiomatic, quality, removal, boy-scout). SPIKE mode relaxes gates. A checklist for implementation discipline during FAIRE (etape 11).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Implementation Safety — 6 Quality Gates (Ciel v5)
|
|
7
|
+
|
|
8
|
+
## What this covers
|
|
9
|
+
|
|
10
|
+
How to implement code with discipline during Ciel v5 FAIRE phase (etape 11). These gates run during coding and are enforced by the plugin or hooks. SPIKE mode relaxes some gates.
|
|
11
|
+
|
|
12
|
+
## Core principle
|
|
13
|
+
|
|
14
|
+
**Check gates per-file, not per-task.** Each write/edit gets its own gate check. In SPIKE mode, gates 1 and 6 are optional but the code must be marked FIXME/TODO.
|
|
15
|
+
|
|
16
|
+
## The 6 gates (v5)
|
|
17
|
+
|
|
18
|
+
### Gate 1: Test-first (RED)
|
|
19
|
+
|
|
20
|
+
Do not write source code before the test exists. If no `*.test.*` file exists:
|
|
21
|
+
- OpenCode: plugin blocks via tool.execute.before
|
|
22
|
+
- Claude Code: hook blocks via exit 2
|
|
23
|
+
|
|
24
|
+
**SPIKE mode**: relaxed. Exploration code may be written without tests, but must be marked FIXME/TODO.
|
|
25
|
+
|
|
26
|
+
### Gate 2: Alternatives
|
|
27
|
+
|
|
28
|
+
"I chose X over Y because [reason]." No Y named -> research alternatives first.
|
|
29
|
+
|
|
30
|
+
### Gate 3: Idiomatic
|
|
31
|
+
|
|
32
|
+
Common bypass signals that need justification:
|
|
33
|
+
- `window.*` / `document.*` in React -> why not hook/ref/router?
|
|
34
|
+
- `for` + raw SQL -> why not batch/ORM?
|
|
35
|
+
- `catch(e) { return null }` -> why not Result/sealed class?
|
|
36
|
+
- `as X` without type guard -> why not `is X`?
|
|
37
|
+
- Copying a block for the 3rd+ time -> why not extract a helper?
|
|
38
|
+
|
|
39
|
+
### Gate 4: Quality
|
|
40
|
+
|
|
41
|
+
- Complexity: < 15 (cyclomatic)
|
|
42
|
+
- Nesting: < 4 levels
|
|
43
|
+
- Function length: < 50 lines
|
|
44
|
+
- File length: < 400 lines
|
|
45
|
+
|
|
46
|
+
**SPIKE mode**: relaxed. Exploration code may be longer or complex, but must be marked FIXME/TODO.
|
|
47
|
+
|
|
48
|
+
### Gate 5: Removal safety
|
|
49
|
+
|
|
50
|
+
If you are DELETING code:
|
|
51
|
+
- Who uses it? (grep for imports/references)
|
|
52
|
+
- What replaces it?
|
|
53
|
+
- What degrades if not replaced?
|
|
54
|
+
- Is there a migration path?
|
|
55
|
+
|
|
56
|
+
### Gate 6: Boy-scout (v5)
|
|
57
|
+
|
|
58
|
+
After the change: is the code better than before?
|
|
59
|
+
- Minor improvements count: better naming, removed dead code, added missing test
|
|
60
|
+
- If the file was already touched, leaving it better is cheap
|
|
61
|
+
- If nothing to improve, note "status quo" explicitly
|
|
62
|
+
|
|
63
|
+
## Output format
|
|
64
|
+
|
|
65
|
+
```
|
|
66
|
+
## FAIRE gates
|
|
67
|
+
|
|
68
|
+
Gate 1 (test-first): <PASS | BLOCKED | SPIKE>
|
|
69
|
+
Gate 2 (alternatives): <X > Y because ...>
|
|
70
|
+
Gate 3 (idiomatic): <PASS | bypass justified: ...>
|
|
71
|
+
Gate 4 (quality): <complexity N, nesting N, length N | PASS>
|
|
72
|
+
Gate 5 (removal): <no removal | safe: ...>
|
|
73
|
+
Gate 6 (boy-scout): <improved: ... | status quo>
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
## How to verify
|
|
77
|
+
|
|
78
|
+
- [ ] Test exists (or spike mode active)?
|
|
79
|
+
- [ ] Alternative considered and documented?
|
|
80
|
+
- [ ] No unjustified framework bypass?
|
|
81
|
+
- [ ] Complexity < 15, nesting < 4, function < 50 lines?
|
|
82
|
+
- [ ] Removals checked for dependents?
|
|
83
|
+
- [ ] Code better than before?
|
|
84
|
+
|
|
85
|
+
## SPIKE mode behavior
|
|
86
|
+
|
|
87
|
+
When `.ciel/exploration.active` exists:
|
|
88
|
+
- Gate 1 (test-first): relaxed
|
|
89
|
+
- Gate 4 (quality): relaxed
|
|
90
|
+
- Gates 2, 3, 5: always active
|
|
91
|
+
- Gate 6 (boy-scout): recommended but not blocking
|
|
92
|
+
- Exploration code MUST be marked FIXME or TODO
|
|
93
|
+
|
|
94
|
+
## Key rules
|
|
95
|
+
|
|
96
|
+
- **Gates are non-negotiable in Standard/Critical mode**: plugin/hooks enforce them
|
|
97
|
+
- **SPIKE mode is for exploration only**: gates are relaxed, but code must be refactored properly after
|
|
98
|
+
- **Gate 5 matters most**: deleting code without checking dependents is the fastest way to break production
|
|
99
|
+
- **Boy-scout is the cheapest improvement**: if you already read the file, clean it up
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: flux-narrator
|
|
3
|
+
description: How to trace data flow through a system — trigger → handler → service → state → output, with boundaries, assumptions, and break points called out. Essential before implementation or test writing.
|
|
4
|
+
allowed-tools: Read, Grep
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Data Flow Tracing — Narrate Before You Code
|
|
8
|
+
|
|
9
|
+
## What this covers
|
|
10
|
+
|
|
11
|
+
How to trace and narrate data flow through a system. If you can't narrate the flow, you don't understand the system — read more code before implementing.
|
|
12
|
+
|
|
13
|
+
## Core narration
|
|
14
|
+
|
|
15
|
+
Format: `"When [trigger] → [handler fires] → [function calls] → [data flows] → [output]"`
|
|
16
|
+
|
|
17
|
+
Example:
|
|
18
|
+
```
|
|
19
|
+
When user clicks "Save" on ProfileForm →
|
|
20
|
+
→ ProfileForm.tsx:handleSubmit (component boundary)
|
|
21
|
+
→ useUpdateProfile hook fires (state boundary)
|
|
22
|
+
→ fetch('/api/users/:id/profile', {method: 'PATCH'}) (network boundary)
|
|
23
|
+
→ Ktor Route at routes/UserRoute.kt:PATCH /:id/profile
|
|
24
|
+
→ UserService.updateProfile (service layer)
|
|
25
|
+
→ UserRepository.save (DB layer)
|
|
26
|
+
→ return HTTP 200 with updated user
|
|
27
|
+
→ UI optimistically updates via React Query
|
|
28
|
+
→ Toast notification: "Profile saved"
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## 3 cross-cutting dimensions
|
|
32
|
+
|
|
33
|
+
### BOUNDARIES
|
|
34
|
+
Where does control pass between layers? Each boundary is a place where contracts can break.
|
|
35
|
+
|
|
36
|
+
### ASSUMPTIONS
|
|
37
|
+
What must be true for this flow to work? E.g. "assumes user is authenticated", "assumes DB connection is not exhausted".
|
|
38
|
+
|
|
39
|
+
### BREAK POINTS
|
|
40
|
+
Where can the flow fail WITHOUT visible error? E.g. silent swallowed exceptions, network retries that mask failures, caching that hides stale data.
|
|
41
|
+
|
|
42
|
+
**Break points ≠ assumptions**: an assumption is "must be true"; a break point is "how it fails silently even when all assumptions hold".
|
|
43
|
+
|
|
44
|
+
## Test-specific items (when writing tests)
|
|
45
|
+
|
|
46
|
+
When the task involves writing tests, also determine:
|
|
47
|
+
|
|
48
|
+
- **Test level**: unit / integration / E2E — justify the choice
|
|
49
|
+
- **URL routing**: request `host:port` vs handler `host:port` — match or mismatch? (CI often differs from local)
|
|
50
|
+
- **Mock lifecycle**: fires at module load? function call? render cycle?
|
|
51
|
+
- **Timing**: expected delay in ms / CI runner capabilities (fake timers? timeout?)
|
|
52
|
+
|
|
53
|
+
## Output format
|
|
54
|
+
|
|
55
|
+
```
|
|
56
|
+
## FLUX
|
|
57
|
+
|
|
58
|
+
When <trigger>
|
|
59
|
+
→ <layer 1: component/handler — file:function>
|
|
60
|
+
→ <layer 2: service/function — file:function>
|
|
61
|
+
→ <layer 3: DB/API/store>
|
|
62
|
+
→ <output: state change / HTTP response / side effect>
|
|
63
|
+
|
|
64
|
+
### Boundaries
|
|
65
|
+
- <list: where control crosses layers>
|
|
66
|
+
|
|
67
|
+
### Assumptions
|
|
68
|
+
- <list: what must be true>
|
|
69
|
+
|
|
70
|
+
### Break points (silent failures)
|
|
71
|
+
- <list: how the flow fails without visible error>
|
|
72
|
+
|
|
73
|
+
[If writing tests:]
|
|
74
|
+
### Test-specific
|
|
75
|
+
- Test level: <unit | integration | E2E> — <justification>
|
|
76
|
+
- URL routing: MATCH ✓ | MISMATCH ⚠️
|
|
77
|
+
- Mock lifecycle: <module load | function call | render>
|
|
78
|
+
- Timing: <X ms>, CI: <capable | insufficient ⚠️>
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## How to verify
|
|
82
|
+
|
|
83
|
+
- [ ] ≥ 3 layers in the flow (trigger → middle → output)?
|
|
84
|
+
- [ ] BOUNDARIES identified?
|
|
85
|
+
- [ ] ASSUMPTIONS listed (what must be true)?
|
|
86
|
+
- [ ] BREAK POINTS identified (silent failures)?
|
|
87
|
+
- [ ] Narration based on grep (not memory)?
|
|
88
|
+
|
|
89
|
+
## Key rules
|
|
90
|
+
|
|
91
|
+
- **Minimum 3 layers**: trigger → middle → output. Only 2 = don't understand the flow.
|
|
92
|
+
- **Don't narrate from memory**: grep the actual call graph. Pattern-matching produces plausible but wrong narrations.
|
|
93
|
+
- **Test items mandatory when writing tests**: skipping any one risks CI/local mismatch or flaky tests.
|
|
@@ -0,0 +1,198 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memoire
|
|
3
|
+
description: Persists project knowledge in Ciel via cued-recall memory (etape 15 MEMOIRE). Captures interventions and decisions into .ciel/memory/{episodes,concepts,guards}/ with index.json mapping cues (paths, symbols, intents) to memories. Replayed automatically when matching cues fire. Replaces the legacy free-recall .ciel/learnings.md blob.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Persist Project Knowledge — Cued-Recall Memory (Ciel v6.5+)
|
|
7
|
+
|
|
8
|
+
## What this covers
|
|
9
|
+
|
|
10
|
+
How to save and retrieve project knowledge using **cued recall**: memories tagged with mechanical cues (file paths, symbols, intents) that fire automatically when those cues appear in the next task's context. The model never has to "remember to search" — the system surfaces relevant memory by mechanical match.
|
|
11
|
+
|
|
12
|
+
See `docs/adrs/0001-cued-recall-memory.md` for the full design rationale.
|
|
13
|
+
|
|
14
|
+
## Core principle
|
|
15
|
+
|
|
16
|
+
**Cued recall over free recall.** Don't ask the model "is there relevant memory?" — surface memory automatically when the context cue (file, symbol, intent) matches.
|
|
17
|
+
|
|
18
|
+
## Three persistence targets
|
|
19
|
+
|
|
20
|
+
### 1. Episodes — `.ciel/memory/episodes/<YYYY-MM-DD>-<slug>.md`
|
|
21
|
+
|
|
22
|
+
Dated events: human corrections, incidents, decisions discovered during a task.
|
|
23
|
+
|
|
24
|
+
Frontmatter:
|
|
25
|
+
```yaml
|
|
26
|
+
---
|
|
27
|
+
id: mem_012
|
|
28
|
+
title: Admin routes use admin-guard wrapper
|
|
29
|
+
languages: [typescript]
|
|
30
|
+
path_patterns:
|
|
31
|
+
- src/admin/**
|
|
32
|
+
- src/pages/admin/**
|
|
33
|
+
symbols: [AdminGuard, useAdminGuard]
|
|
34
|
+
intents: [new-route, admin]
|
|
35
|
+
captured_at: 2026-05-08T14:32:00Z
|
|
36
|
+
captured_from: user-intervention # or: incident, decision, bootstrap
|
|
37
|
+
trigger_count: 0
|
|
38
|
+
last_triggered: null
|
|
39
|
+
stale_after_days: 90
|
|
40
|
+
stale: false
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
# Admin routes use admin-guard wrapper
|
|
44
|
+
|
|
45
|
+
**Context:** when adding a route under `/admin/*`, do not use the standard
|
|
46
|
+
auth middleware. Use the project's `admin-guard` wrapper, which adds
|
|
47
|
+
audit logging and role-based checks.
|
|
48
|
+
|
|
49
|
+
**Why:** captured 2026-05-08 after the third incident where standard
|
|
50
|
+
middleware allowed read access without role check.
|
|
51
|
+
|
|
52
|
+
**How to apply:** import from `src/lib/auth/admin-guard.ts`. Wrap the
|
|
53
|
+
route handler. See `src/admin/users/page.tsx` for canonical usage.
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Capture when:
|
|
57
|
+
- User corrects the model ("non, on utilise X ici")
|
|
58
|
+
- An incident is documented (build broke, prod paged, test flaked for non-obvious reason)
|
|
59
|
+
- A non-obvious decision is made (chose lib A over B because constraint C)
|
|
60
|
+
|
|
61
|
+
### 2. Concepts — `.ciel/memory/concepts/<topic>.md`
|
|
62
|
+
|
|
63
|
+
Stable conventions promoted from episodes that triggered ≥ N times. Same frontmatter, but with `captured_from: consolidation` and `promoted_from: [mem_012, mem_018]`.
|
|
64
|
+
|
|
65
|
+
Promotion rule (handled by `memoire-consolidator` skill):
|
|
66
|
+
- Episode triggered ≥ 5 times in last 60 days → candidate for promotion
|
|
67
|
+
- ≥ 2 episodes share ≥ 80% of tags + similar lesson → candidate for merge
|
|
68
|
+
|
|
69
|
+
### 3. Guards — `.ciel/memory/guards/<scope>.md`
|
|
70
|
+
|
|
71
|
+
Vigilance rules with narrow trigger scope and high-severity warnings. Same frontmatter, but with `severity: critical`. Used for:
|
|
72
|
+
- Foot-guns (commands that destroy prod)
|
|
73
|
+
- Forbidden patterns (editing a deployed migration)
|
|
74
|
+
- Mandatory checks before specific actions
|
|
75
|
+
|
|
76
|
+
## Index — `.ciel/memory/index.json`
|
|
77
|
+
|
|
78
|
+
The cue → memory mapping. Always loaded by `session-start.sh` at SessionStart.
|
|
79
|
+
|
|
80
|
+
```json
|
|
81
|
+
{
|
|
82
|
+
"version": 2,
|
|
83
|
+
"memories": {
|
|
84
|
+
"mem_012": { "title": "...", "file": "...", "languages": [...], "..." : "..." }
|
|
85
|
+
},
|
|
86
|
+
"by_path": { "src/admin/**": ["mem_012"] },
|
|
87
|
+
"by_symbol": { "AdminGuard": ["mem_012"] },
|
|
88
|
+
"by_intent": { "new-route": ["mem_012"] },
|
|
89
|
+
"by_language": { "typescript": ["mem_012"] }
|
|
90
|
+
}
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
The index is rebuilt from frontmatter scans by `memoire-consolidator` whenever a memory is added/updated.
|
|
94
|
+
|
|
95
|
+
## Capture flow
|
|
96
|
+
|
|
97
|
+
1. User submits prompt
|
|
98
|
+
2. `user-prompt-submit.sh` hook scans for intervention patterns: "tu as oublié", "non en fait", "attention que", "rappelle-toi", "n'oublie pas", "wait", "stop", "non on fait plutôt", "ici on fait plutôt"
|
|
99
|
+
3. If matched → emits a context message: "INTERVENTION DETECTED — propose capture"
|
|
100
|
+
4. Model surfaces an `AskUserQuestion`: "Capture this correction as memory? [Title / Tags suggested / Skip]"
|
|
101
|
+
5. User confirms or skips
|
|
102
|
+
6. On confirm → write `.ciel/memory/episodes/<date>-<slug>.md`, update `index.json`
|
|
103
|
+
|
|
104
|
+
**Never auto-silent.** The user is the filter against cargo-cult capture.
|
|
105
|
+
|
|
106
|
+
## Recall flow
|
|
107
|
+
|
|
108
|
+
1. SessionStart or new task begins
|
|
109
|
+
2. `session-start.sh` hook reads:
|
|
110
|
+
- The user's prompt (extract keywords → intent cues)
|
|
111
|
+
- `.ciel/map.json` (current focus modules → path cues)
|
|
112
|
+
- Recently tracked files (`.ciel/tracked-files.json`) → path + symbol cues
|
|
113
|
+
3. Queries `index.json`: cues ∩ memories → candidate set
|
|
114
|
+
4. Scores by: `recency × trigger_count × tag-overlap`
|
|
115
|
+
5. Selects top-K under depth budget (Trivial 1K / Standard 3K / Critical 5K tokens)
|
|
116
|
+
6. Injects one-line previews:
|
|
117
|
+
```
|
|
118
|
+
[mem_012, fired 7×] Admin routes use admin-guard wrapper
|
|
119
|
+
[mem_007, fired 3×] Migration files are checksum-locked
|
|
120
|
+
```
|
|
121
|
+
7. Model can `Read` full content if relevant (cued exploration, not blanket dump)
|
|
122
|
+
|
|
123
|
+
## Bootstrap from existing docs
|
|
124
|
+
|
|
125
|
+
On first run, the slash command `/ciel-memory-bootstrap` ingests:
|
|
126
|
+
|
|
127
|
+
| Source | Format expected |
|
|
128
|
+
|---|---|
|
|
129
|
+
| `.ciel/learnings.md` | Legacy Ciel format with `[date] MISTAKE/RULE` entries |
|
|
130
|
+
| `.claude/lessons.md` or `lessons.md` | Same as above |
|
|
131
|
+
| `ciel-overlay.md` | "Key Lessons" section |
|
|
132
|
+
| `.claude/rules/*.md` | Each file = one rule |
|
|
133
|
+
| `AGENTS.md` | Rules sections |
|
|
134
|
+
|
|
135
|
+
Each ingested item becomes an episode with `captured_from: bootstrap`. Tags are inferred from content (file paths mentioned, symbols mentioned, language detected from imports).
|
|
136
|
+
|
|
137
|
+
If no source is found, the system reports it and waits for organic capture via interventions.
|
|
138
|
+
|
|
139
|
+
## Decay
|
|
140
|
+
|
|
141
|
+
- `last_triggered` is updated by `session-start.sh` whenever a memory is matched and injected
|
|
142
|
+
- After `stale_after_days` (default 90) without trigger → `stale: true`
|
|
143
|
+
- Stale memories excluded from auto-injection but kept on disk
|
|
144
|
+
- Skill `memoire-consolidator` periodically suggests purge or refresh
|
|
145
|
+
|
|
146
|
+
## Token budget (hard caps)
|
|
147
|
+
|
|
148
|
+
| Depth | Cap |
|
|
149
|
+
|---|---|
|
|
150
|
+
| Trivial | 1K tokens injected |
|
|
151
|
+
| Standard | 3K tokens injected |
|
|
152
|
+
| Critical | 5K tokens injected |
|
|
153
|
+
|
|
154
|
+
If candidate set exceeds cap, drop lowest-scoring entries first. Index itself is small (~50 tokens per entry); the cap concerns content previews and any auto-loaded full content.
|
|
155
|
+
|
|
156
|
+
## Common rationalizations
|
|
157
|
+
|
|
158
|
+
| Rationalization | Reality |
|
|
159
|
+
|---|---|
|
|
160
|
+
| "I'll remember this next session" | You won't. Even if you do, the next agent session won't. Capture or it's gone. |
|
|
161
|
+
| "The user corrected me, but it was obvious" | The fact that you missed it makes it non-obvious. Capture. |
|
|
162
|
+
| "All this is in CLAUDE.md already" | CLAUDE.md is loaded once and diluted by lost-in-the-middle (Liu 2023). Cued memory bypasses that. |
|
|
163
|
+
| "Capturing slows the user down" | One confirmation now vs. the same intervention next month. The math favors capture. |
|
|
164
|
+
|
|
165
|
+
## What to persist vs what to skip
|
|
166
|
+
|
|
167
|
+
PERSIST (becomes a memory):
|
|
168
|
+
- User corrections that aren't obvious from reading the code
|
|
169
|
+
- Incidents (what broke, root cause, fix that worked)
|
|
170
|
+
- Architecture decisions with their motivation
|
|
171
|
+
- Foot-guns (commands/patterns to avoid in this project)
|
|
172
|
+
- Wrappers / conventions that override library defaults
|
|
173
|
+
|
|
174
|
+
SKIP (don't pollute the corpus):
|
|
175
|
+
- The code itself (it's in git)
|
|
176
|
+
- Routine task completion ("I added a button")
|
|
177
|
+
- Anything trivially derivable by reading the file
|
|
178
|
+
- Personal style preferences (those go in `ciel-overlay.md`)
|
|
179
|
+
|
|
180
|
+
## How to verify (etape MEMOIRE)
|
|
181
|
+
|
|
182
|
+
- [ ] Did this session contain a user intervention/correction? If yes, was it captured?
|
|
183
|
+
- [ ] Did this session document a new pattern, foot-gun, or convention? If yes, episode created?
|
|
184
|
+
- [ ] Was the index.json updated by the capture flow?
|
|
185
|
+
- [ ] Are tags reasonable (paths actually exist, symbols are real)?
|
|
186
|
+
- [ ] If the same correction came up next month, would the cued recall fire? (Mental dry-run.)
|
|
187
|
+
|
|
188
|
+
## Migration from legacy `.ciel/learnings.md`
|
|
189
|
+
|
|
190
|
+
The legacy single-blob `learnings.md` is kept for backward compatibility but **deprecated**. New writes should go to `.ciel/memory/episodes/` via the capture flow. Run `/ciel-memory-bootstrap` to migrate existing entries — it parses the dated entries and converts each into an episode with inferred tags.
|
|
191
|
+
|
|
192
|
+
## Related
|
|
193
|
+
|
|
194
|
+
- `docs/adrs/0001-cued-recall-memory.md` — full design rationale and binding principles
|
|
195
|
+
- `skills/workflow/memoire-consolidator` — periodic maintenance: promote, merge, decay
|
|
196
|
+
- `commands/ciel-memory-bootstrap.md` — first-run scan + ingestion
|
|
197
|
+
- `hooks/user-prompt-submit.sh` — detects intervention patterns and proposes capture
|
|
198
|
+
- `hooks/session-start.sh` — injects matching memories at session start
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memoire-consolidator
|
|
3
|
+
description: Periodic maintenance of .ciel/memory/ — promotes high-frequency episodes to concepts, merges duplicates, marks stale entries, rebuilds index.json. Run manually or via /ciel-improve. Keeps the cued-recall corpus from accumulating noise as projects age.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Consolidate Cued-Recall Memory
|
|
7
|
+
|
|
8
|
+
## What this covers
|
|
9
|
+
|
|
10
|
+
The corpus under `.ciel/memory/` grows over time. Without maintenance it accumulates duplicates, stale entries, and episodes that should have been promoted to stable concepts long ago. This skill is the maintenance pass.
|
|
11
|
+
|
|
12
|
+
See `skills/workflow/memoire/SKILL.md` for the capture/recall flow and `docs/adrs/0001-cued-recall-memory.md` for the full design.
|
|
13
|
+
|
|
14
|
+
## When to run
|
|
15
|
+
|
|
16
|
+
- Manually via `/ciel-improve` or direct invocation
|
|
17
|
+
- When `index.json` shows ≥ 50 episodes
|
|
18
|
+
- Quarterly on long-lived projects
|
|
19
|
+
- After any large bootstrap import (existing tribal docs ingested at once)
|
|
20
|
+
|
|
21
|
+
## Five operations
|
|
22
|
+
|
|
23
|
+
### 1. Promote frequent episodes → concepts
|
|
24
|
+
|
|
25
|
+
Criterion: episode with `trigger_count ≥ 5` AND `last_triggered` within 60 days.
|
|
26
|
+
|
|
27
|
+
Action: copy episode content to `.ciel/memory/concepts/<slug>.md`, set `captured_from: consolidation` and `promoted_from: [original_id]`. Mark original episode `superseded_by: <new_id>` and exclude from active index.
|
|
28
|
+
|
|
29
|
+
Why: concepts are stable conventions. Frequent triggers prove the rule has crystallized.
|
|
30
|
+
|
|
31
|
+
### 2. Merge similar episodes
|
|
32
|
+
|
|
33
|
+
Criterion: two or more episodes share ≥ 80% of tags AND describe the same lesson (semantic similarity, judged by reading content).
|
|
34
|
+
|
|
35
|
+
Action: create a new concept that subsumes them, mark all originals `merged_into: <concept_id>`.
|
|
36
|
+
|
|
37
|
+
Why: bootstrap or rapid capture often produces near-duplicates ("admin routes use admin-guard" + "always wrap admin in admin-guard"). Merging reduces noise without losing the signal.
|
|
38
|
+
|
|
39
|
+
### 3. Mark stale entries
|
|
40
|
+
|
|
41
|
+
Criterion: `last_triggered` is older than `stale_after_days` (default 90) OR null + `captured_at` older than 90 days.
|
|
42
|
+
|
|
43
|
+
Action: set `stale: true` in frontmatter and in `index.json`. Stale entries are excluded from auto-injection but remain on disk.
|
|
44
|
+
|
|
45
|
+
Why: untriggered memories may be obsolete (the file no longer exists, the convention changed). Auto-injecting them produces false positives.
|
|
46
|
+
|
|
47
|
+
### 4. Detect dead anchors
|
|
48
|
+
|
|
49
|
+
Criterion: a memory's `path_patterns` no longer match any file in the repo (deleted module, renamed convention).
|
|
50
|
+
|
|
51
|
+
Action: flag for human review in `.ciel/memory/review-queue.md`. Don't auto-delete — the user should decide whether the memory is obsolete or needs updated paths.
|
|
52
|
+
|
|
53
|
+
### 5. Rebuild `index.json`
|
|
54
|
+
|
|
55
|
+
Always done last. Scans all `*.md` under `.ciel/memory/{episodes,concepts,guards}/`, parses frontmatter, regenerates the cue indices (`by_path`, `by_symbol`, `by_intent`, `by_language`).
|
|
56
|
+
|
|
57
|
+
This guarantees the index never drifts from source-of-truth (the markdown files).
|
|
58
|
+
|
|
59
|
+
## Output report
|
|
60
|
+
|
|
61
|
+
After running, emit a summary:
|
|
62
|
+
|
|
63
|
+
```
|
|
64
|
+
[memoire-consolidator] 2026-05-08
|
|
65
|
+
Promoted: 3 episodes → concepts
|
|
66
|
+
Merged: 2 episode pairs → 2 concepts
|
|
67
|
+
Stale: 7 entries flagged
|
|
68
|
+
Dead: 1 anchor needs review (see .ciel/memory/review-queue.md)
|
|
69
|
+
Index: rebuilt — 42 active memories, 9 stale, 51 total
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## Anti-patterns to avoid
|
|
73
|
+
|
|
74
|
+
| Anti-pattern | Reason |
|
|
75
|
+
|---|---|
|
|
76
|
+
| Auto-deleting stale entries | User may want to revive; deletion is irreversible. Always flag, never delete. |
|
|
77
|
+
| Promoting on first trigger | One trigger isn't crystallization. Wait for repetition. |
|
|
78
|
+
| Merging without reading content | Tags may overlap by accident (two different `auth/**` rules). Read before merge. |
|
|
79
|
+
| Skipping index rebuild | Drift between index and markdown is worse than missing data — silent corruption. |
|
|
80
|
+
|
|
81
|
+
## Design principles inherited from ADR-0001
|
|
82
|
+
|
|
83
|
+
- Markdown is source of truth; index is derived
|
|
84
|
+
- User is the filter for irreversible actions (deletion, merge with conflict)
|
|
85
|
+
- Decay over accumulation: stale flag is automatic, but action on it is human
|
|
86
|
+
|
|
87
|
+
## Related skills
|
|
88
|
+
|
|
89
|
+
- `memoire` — capture/recall flow (writes the inputs this skill consumes)
|
|
90
|
+
- `meta-critiquer` — post-task reflection that may trigger consolidation if many captures occurred
|
|
91
|
+
- `learnings-capture` — older format, superseded by cued-recall memoire
|