sqlew 5.1.0 → 5.2.1
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/CHANGELOG.md +2140 -2081
- package/LICENSE +190 -190
- package/NOTICE +24 -24
- package/README.md +204 -190
- package/dist/adapters/mysql-adapter.js +3 -3
- package/dist/adapters/postgresql-adapter.js +3 -3
- package/dist/cli/db-export.js +32 -32
- package/dist/cli/db-import.js +30 -30
- package/dist/cli/hooks/codex-transcript.d.ts +23 -0
- package/dist/cli/hooks/codex-transcript.d.ts.map +1 -0
- package/dist/cli/hooks/codex-transcript.js +134 -0
- package/dist/cli/hooks/codex-transcript.js.map +1 -0
- package/dist/cli/hooks/on-exit-plan.d.ts.map +1 -1
- package/dist/cli/hooks/on-exit-plan.js +72 -4
- package/dist/cli/hooks/on-exit-plan.js.map +1 -1
- package/dist/cli/hooks/on-prompt.d.ts.map +1 -1
- package/dist/cli/hooks/on-prompt.js +38 -16
- package/dist/cli/hooks/on-prompt.js.map +1 -1
- package/dist/cli/hooks/plan-processor.d.ts.map +1 -1
- package/dist/cli/hooks/plan-processor.js +16 -2
- package/dist/cli/hooks/plan-processor.js.map +1 -1
- package/dist/cli/hooks/pr-adr.js +5 -5
- package/dist/cli/hooks/stdin-parser.d.ts +43 -0
- package/dist/cli/hooks/stdin-parser.d.ts.map +1 -1
- package/dist/cli/hooks/stdin-parser.js +212 -6
- package/dist/cli/hooks/stdin-parser.js.map +1 -1
- package/dist/cli/hooks/track-plan.d.ts +13 -0
- package/dist/cli/hooks/track-plan.d.ts.map +1 -1
- package/dist/cli/hooks/track-plan.js +73 -18
- package/dist/cli/hooks/track-plan.js.map +1 -1
- package/dist/cli.js +48 -48
- package/dist/config/global-config.d.ts +7 -1
- package/dist/config/global-config.d.ts.map +1 -1
- package/dist/config/global-config.js +5 -26
- package/dist/config/global-config.js.map +1 -1
- package/dist/database/migrations/v4/20251126000000_v4_bootstrap.js +32 -32
- package/dist/database/migrations/v4/20251126000001_v4_migrate_data.d.ts.map +1 -1
- package/dist/database/migrations/v4/20251126000001_v4_migrate_data.js +2 -1
- package/dist/database/migrations/v4/20251126000001_v4_migrate_data.js.map +1 -1
- package/dist/database/migrations/v4/20260102204000_v4_fix_decision_set_example.js +3 -3
- package/dist/help-data/constraint.toml +259 -259
- package/dist/help-data/decision.toml +845 -845
- package/dist/help-data/queue.toml +134 -134
- package/dist/server/tool-schemas.js +30 -30
- package/dist/tests/docker/native/db-init.js +9 -9
- package/dist/tests/unit/hooks/codex-hook-normalization.test.d.ts +7 -0
- package/dist/tests/unit/hooks/codex-hook-normalization.test.d.ts.map +1 -0
- package/dist/tests/unit/hooks/codex-hook-normalization.test.js +112 -0
- package/dist/tests/unit/hooks/codex-hook-normalization.test.js.map +1 -0
- package/dist/tests/unit/hooks/grok-hook-normalization.test.d.ts +9 -0
- package/dist/tests/unit/hooks/grok-hook-normalization.test.d.ts.map +1 -0
- package/dist/tests/unit/hooks/grok-hook-normalization.test.js +136 -0
- package/dist/tests/unit/hooks/grok-hook-normalization.test.js.map +1 -0
- package/dist/tests/unit/hooks/grok-plan-template-injection.test.d.ts +7 -0
- package/dist/tests/unit/hooks/grok-plan-template-injection.test.d.ts.map +1 -0
- package/dist/tests/unit/hooks/grok-plan-template-injection.test.js +55 -0
- package/dist/tests/unit/hooks/grok-plan-template-injection.test.js.map +1 -0
- package/dist/tests/utils/db-schema.js +48 -48
- package/dist/tests/utils/test-helpers.js +48 -48
- package/dist/tools/constraints/actions/get.js +5 -5
- package/dist/utils/path-normalize.d.ts +23 -0
- package/dist/utils/path-normalize.d.ts.map +1 -0
- package/dist/utils/path-normalize.js +38 -0
- package/dist/utils/path-normalize.js.map +1 -0
- package/dist/utils/project-root.d.ts +7 -3
- package/dist/utils/project-root.d.ts.map +1 -1
- package/dist/utils/project-root.js +17 -3
- package/dist/utils/project-root.js.map +1 -1
- package/dist/watcher/base-watcher.d.ts +0 -4
- package/dist/watcher/base-watcher.d.ts.map +1 -1
- package/dist/watcher/base-watcher.js +11 -22
- package/dist/watcher/base-watcher.js.map +1 -1
- package/docs/ADR_CONCEPTS.md +152 -152
- package/docs/CLI_USAGE.md +392 -392
- package/docs/CONFIGURATION.md +157 -157
- package/docs/CROSS_DATABASE.md +66 -66
- package/docs/DATABASE_AUTH.md +135 -135
- package/docs/HOOKS_GUIDE.md +116 -67
- package/docs/MIGRATION_TO_SAAS.md +176 -176
- package/docs/SHARED_DATABASE.md +108 -108
- package/package.json +88 -88
- package/scripts/copy-help-data.js +19 -19
- package/scripts/filter-test-output.js +78 -78
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"base-watcher.js","sourceRoot":"","sources":["../../src/watcher/base-watcher.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,OAAO,QAAuB,MAAM,UAAU,CAAC;AAC/C,OAAO,EAAE,
|
|
1
|
+
{"version":3,"file":"base-watcher.js","sourceRoot":"","sources":["../../src/watcher/base-watcher.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,OAAO,QAAuB,MAAM,UAAU,CAAC;AAC/C,OAAO,EAAE,iBAAiB,EAAE,MAAM,kCAAkC,CAAC;AACrE,OAAO,EAAE,QAAQ,EAAE,MAAM,0BAA0B,CAAC;AAoBpD;;GAEG;AACH,MAAM,OAAgB,WAAW;IACrB,OAAO,GAAqB,IAAI,CAAC;IACjC,SAAS,GAAY,KAAK,CAAC;IAC3B,cAAc,GAAgC,IAAI,GAAG,EAAE,CAAC;IAC/C,UAAU,CAAS;IACnB,WAAW,CAAS;IAEvC,YAAY,IAAY,EAAE,aAAqB,IAAI;QACjD,IAAI,CAAC,WAAW,GAAG,IAAI,CAAC;QACxB,IAAI,CAAC,UAAU,GAAG,UAAU,CAAC;IAC/B,CAAC;IAED;;OAEG;IACO,iBAAiB,CAAC,OAAuB;QACjD,MAAM,GAAG,GAAG,iBAAiB,EAAE,CAAC;QAChC,MAAM,KAAK,GAAG,GAAG,KAAK,KAAK,CAAC;QAC5B,IAAI,KAAK,EAAE,CAAC;YACV,QAAQ,CAAC,MAAM,EAAE,GAAG,IAAI,CAAC,WAAW,gBAAgB,CAAC,CAAC;QACxD,CAAC;QAED,0EAA0E;QAC1E,MAAM,KAAK,GAAG,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;QAC7E,MAAM,YAAY,GAAG,KAAK,IAAI,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,CAAC;QACrE,MAAM,UAAU,GAAG,OAAO,CAAC,UAAU,IAAI,YAAY,CAAC;QAEtD,IAAI,YAAY,IAAI,OAAO,CAAC,UAAU,KAAK,SAAS,EAAE,CAAC;YACrD,QAAQ,CAAC,MAAM,EAAE,GAAG,IAAI,CAAC,WAAW,6CAA6C,CAAC,CAAC;QACrF,CAAC;QAED,MAAM,aAAa,GAAyC;YAC1D,UAAU,EAAE,IAAI;YAChB,aAAa,EAAE,OAAO,CAAC,aAAa,IAAI,IAAI;YAC5C,gBAAgB,EAAE;gBAChB,oFAAoF;gBACpF,kBAAkB,EAAE,IAAI,CAAC,GAAG,CAAC,OAAO,CAAC,UAAU,IAAI,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC;gBACzE,YAAY,EAAE,GAAG,EAAG,sDAAsD;aAC3E;YACD,UAAU;YACV,QAAQ,EAAE,OAAO,CAAC,YAAY,IAAI,GAAG,EAAG,yBAAyB;SAClE,CAAC;QAEF,IAAI,OAAO,CAAC,OAAO,IAAI,aAAa,EAAE,CAAC;YACrC,aAAa,CAAC,OAAO,GAAG,OAAO,CAAC,OAAO,CAAC;QAC1C,CAAC;QAED,OAAO,QAAQ,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,EAAE,aAAa,CAAC,CAAC;IACtD,CAAC;IAED;;OAEG;IACO,QAAQ,CAAC,GAAW,EAAE,OAAmC;QACjE,oCAAoC;QACpC,MAAM,aAAa,GAAG,IAAI,CAAC,cAAc,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;QACnD,IAAI,aAAa,EAAE,CAAC;YAClB,YAAY,CAAC,aAAa,CAAC,CAAC;QAC9B,CAAC;QAED,gBAAgB;QAChB,MAAM,KAAK,GAAG,UAAU,CAAC,KAAK,IAAI,EAAE;YAClC,IAAI,CAAC,cAAc,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;YAChC,IAAI,CAAC;gBACH,MAAM,OAAO,EAAE,CAAC;YAClB,CAAC;YAAC,OAAO,KAAK,EAAE,CAAC;gBACf,QAAQ,CAAC,OAAO,EAAE,GAAG,IAAI,CAAC,WAAW,8BAA8B,EAAE;oBACnE,KAAK;iBACN,CAAC,CAAC;YACL,CAAC;QACH,CAAC,EAAE,IAAI,CAAC,UAAU,CAAC,CAAC;QAEpB,IAAI,CAAC,cAAc,CAAC,GAAG,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;IACtC,CAAC;IAOD;;OAEG;IACI,KAAK,CAAC,IAAI;QACf,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,CAAC;YACpB,OAAO;QACT,CAAC;QAED,IAAI,CAAC;YACH,4BAA4B;YAC5B,IAAI,CAAC,cAAc,CAAC,OAAO,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,YAAY,CAAC,KAAK,CAAC,CAAC,CAAC;YAC5D,IAAI,CAAC,cAAc,CAAC,KAAK,EAAE,CAAC;YAE5B,gBAAgB;YAChB,IAAI,IAAI,CAAC,OAAO,EAAE,CAAC;gBACjB,MAAM,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,CAAC;gBAC3B,IAAI,CAAC,OAAO,GAAG,IAAI,CAAC;YACtB,CAAC;YAED,IAAI,CAAC,SAAS,GAAG,KAAK,CAAC;YACvB,QAAQ,CAAC,MAAM,EAAE,GAAG,IAAI,CAAC,WAAW,WAAW,CAAC,CAAC;QACnD,CAAC;QAAC,OAAO,KAAK,EAAE,CAAC;YACf,QAAQ,CAAC,OAAO,EAAE,GAAG,IAAI,CAAC,WAAW,kBAAkB,EAAE,EAAE,KAAK,EAAE,CAAC,CAAC;YACpE,MAAM,KAAK,CAAC;QACd,CAAC;IACH,CAAC;IAED;;OAEG;IACI,YAAY;QACjB,OAAO,IAAI,CAAC,SAAS,CAAC;IACxB,CAAC;IAED;;OAEG;IACI,OAAO;QACZ,OAAO,IAAI,CAAC,WAAW,CAAC;IAC1B,CAAC;CACF"}
|
package/docs/ADR_CONCEPTS.md
CHANGED
|
@@ -1,152 +1,152 @@
|
|
|
1
|
-
# Decisions & Constraints for AI Development
|
|
2
|
-
|
|
3
|
-
Persistent design context — decisions and constraints recorded as structured data — gives AI agents architectural memory across sessions. sqlew makes this zero-effort: plan normally, and hooks capture your decisions automatically.
|
|
4
|
-
|
|
5
|
-
## Why Persistent Design Context Matters
|
|
6
|
-
|
|
7
|
-
Research shows that recording design intent dramatically improves LLM code generation:
|
|
8
|
-
|
|
9
|
-
- **22.4% reduction** in overall development time
|
|
10
|
-
- **80% of tasks** completed faster with design intent available
|
|
11
|
-
- **50%+ improvement** in feature-addition and architectural-change tasks
|
|
12
|
-
- **137% increase** in design decision references by final tasks — AI learns to leverage past context more over time
|
|
13
|
-
|
|
14
|
-
> Kitayama, S. (2026). *Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation*. [DOI](https://doi.org/10.36227/techrxiv.177205025.54351571/v1)
|
|
15
|
-
>
|
|
16
|
-
> Blog post: [Recording Design Intent for AI Efficiency](https://blog.sqlew.io/recording-design-intent-for-ai-efficiency)
|
|
17
|
-
|
|
18
|
-
## Key Benefits for AI-Driven Development
|
|
19
|
-
|
|
20
|
-
### Persistent Architectural Memory
|
|
21
|
-
- **Zero context loss** – AI agents remember every architectural decision across sessions
|
|
22
|
-
- **Rationale preservation** – Never forget WHY a decision was made, not just WHAT
|
|
23
|
-
- **Alternative tracking** – Document rejected options to prevent circular debates
|
|
24
|
-
- **Evolution history** – See how decisions changed over time with full version history
|
|
25
|
-
|
|
26
|
-
### Prevent Architectural Drift
|
|
27
|
-
- **Constraint enforcement** – Define architectural rules once, AI follows them forever
|
|
28
|
-
- **Pattern consistency** – AI generates code matching established patterns automatically
|
|
29
|
-
- **Anti-pattern prevention** – Document "what NOT to do" as enforceable constraints
|
|
30
|
-
- **Regression prevention** – AI won't reintroduce previously rejected approaches
|
|
31
|
-
|
|
32
|
-
### Intelligent Decision Discovery
|
|
33
|
-
- **Three-tier duplicate detection** – Gentle nudge (35-44), hard block (45-59), or auto-update (60+) based on similarity score
|
|
34
|
-
- **Similarity detection** – AI identifies duplicate or related decisions before creating new ones
|
|
35
|
-
- **Context-aware search** – Query by layer, tags, or relationships to find relevant decisions
|
|
36
|
-
- **Conflict detection** – Find decisions that contradict or supersede each other
|
|
37
|
-
|
|
38
|
-
### Extreme Efficiency
|
|
39
|
-
- **60-75% token reduction** – Query only relevant decisions instead of reading full files
|
|
40
|
-
- **Millisecond queries** – 2-50ms response times even with thousands of decisions
|
|
41
|
-
- **Scalable architecture** – Perform well with large decision histories
|
|
42
|
-
|
|
43
|
-
## How sqlew Works
|
|
44
|
-
|
|
45
|
-
```mermaid
|
|
46
|
-
flowchart LR
|
|
47
|
-
subgraph Claude Code
|
|
48
|
-
A[Plan Mode] -->|Create Plan| B[User Approval]
|
|
49
|
-
B -->|ExitPlanMode| C[Hook Triggered]
|
|
50
|
-
end
|
|
51
|
-
|
|
52
|
-
subgraph sqlew
|
|
53
|
-
C -->|Enqueue| D[Queue File]
|
|
54
|
-
D -->|QueueWatcher| E[(SQL Database)]
|
|
55
|
-
end
|
|
56
|
-
|
|
57
|
-
subgraph Next Session
|
|
58
|
-
F[AI Agent] -->|Query| E
|
|
59
|
-
E -->|Past Decisions| F
|
|
60
|
-
end
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
**Zero-effort knowledge accumulation:**
|
|
64
|
-
1. You plan your work normally in Claude Code
|
|
65
|
-
2. Hooks automatically capture decisions
|
|
66
|
-
3. Next session, AI queries past decisions via SQL
|
|
67
|
-
|
|
68
|
-
## Core Concepts
|
|
69
|
-
|
|
70
|
-
**Decisions** capture architectural choices with full context:
|
|
71
|
-
- **What** was decided (the decision itself)
|
|
72
|
-
- **Why** it was chosen (rationale, trade-offs)
|
|
73
|
-
- **What else** was considered (alternatives rejected)
|
|
74
|
-
- **Impact** on the system (consequences, affected components)
|
|
75
|
-
|
|
76
|
-
**Constraints** define architectural principles and rules:
|
|
77
|
-
- **Performance requirements** (response time limits, throughput goals)
|
|
78
|
-
- **Technology choices** ("must use PostgreSQL", "avoid microservices")
|
|
79
|
-
- **Coding standards** ("async/await only", "no any types")
|
|
80
|
-
- **Security policies** (authentication patterns, data handling rules)
|
|
81
|
-
|
|
82
|
-
**Lifecycle tracking:**
|
|
83
|
-
- **Status evolution** tracks decision lifecycle (draft → active → deprecated)
|
|
84
|
-
- **Auto-capture via Hooks** records decisions automatically from Plan Mode
|
|
85
|
-
|
|
86
|
-
```mermaid
|
|
87
|
-
erDiagram
|
|
88
|
-
DECISION ||--o{ TAG : has
|
|
89
|
-
DECISION {
|
|
90
|
-
string key
|
|
91
|
-
string value
|
|
92
|
-
string layer
|
|
93
|
-
string status
|
|
94
|
-
timestamp updated
|
|
95
|
-
}
|
|
96
|
-
CONSTRAINT ||--o{ TAG : has
|
|
97
|
-
CONSTRAINT {
|
|
98
|
-
string text
|
|
99
|
-
string category
|
|
100
|
-
int priority
|
|
101
|
-
}
|
|
102
|
-
TAG {
|
|
103
|
-
string name
|
|
104
|
-
}
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
## SQL vs Markdown
|
|
108
|
-
|
|
109
|
-
| Traditional approach (Markdown) | sqlew approach (SQL) |
|
|
110
|
-
|--------------------------------|---------------------|
|
|
111
|
-
| Read entire files | Query specific decisions |
|
|
112
|
-
| Manual duplicate checking | Automatic similarity detection |
|
|
113
|
-
| Text parsing required | Structured, typed data |
|
|
114
|
-
| Linear token scaling | Constant-time lookups |
|
|
115
|
-
| File-based organization | Relational queries with JOINs |
|
|
116
|
-
|
|
117
|
-
### Why SQL?
|
|
118
|
-
|
|
119
|
-
Traditional text-based records force AI to:
|
|
120
|
-
- Read complete files even for simple queries
|
|
121
|
-
- Parse unstructured text to find relationships
|
|
122
|
-
- Manually detect duplicate or conflicting decisions
|
|
123
|
-
|
|
124
|
-
sqlew's **SQL-backed decision repository** enables AI to:
|
|
125
|
-
- Query by layer, tags, status in milliseconds (2-50ms)
|
|
126
|
-
- Join decisions with constraints
|
|
127
|
-
- Leverage similarity algorithms to prevent duplicates
|
|
128
|
-
- Scale to thousands of decisions without context explosion
|
|
129
|
-
|
|
130
|
-
**Token efficiency**: 60-75% reduction compared to reading Markdown files
|
|
131
|
-
|
|
132
|
-
### Why RDBMS + MCP?
|
|
133
|
-
|
|
134
|
-
**RDBMS (Relational Database)** provides efficient structured queries:
|
|
135
|
-
- **Indexed searches** – Find decisions by tags/layers in milliseconds, not seconds
|
|
136
|
-
- **JOIN operations** – Query related decisions and constraints in a single operation
|
|
137
|
-
- **Transaction support** – ACID guarantees ensure data integrity across concurrent AI agents
|
|
138
|
-
- **Scalability** – Handle thousands of decisions without performance degradation
|
|
139
|
-
|
|
140
|
-
**MCP (Model Context Protocol)** enables seamless AI integration:
|
|
141
|
-
- **Seamless DB connection** – AI agents access the database through a standardized protocol without direct DB setup
|
|
142
|
-
- **Self-documenting tools** – Tool descriptions teach AI how to use each operation, no manual onboarding needed
|
|
143
|
-
- **Type safety** – Structured parameters prevent errors and guide correct usage
|
|
144
|
-
- **Cross-session persistence** – Decisions survive beyond individual chat sessions
|
|
145
|
-
|
|
146
|
-
**Together**: AI agents gain SQL-powered decision capabilities without managing databases directly.
|
|
147
|
-
|
|
148
|
-
## References
|
|
149
|
-
|
|
150
|
-
- Kitayama, S. (2026). *Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation*. [DOI](https://doi.org/10.36227/techrxiv.177205025.54351571/v1)
|
|
151
|
-
- Blog: [Recording Design Intent for AI Efficiency](https://blog.sqlew.io/recording-design-intent-for-ai-efficiency)
|
|
152
|
-
- The concept of Architecture Decision Records was originally proposed by Michael Nygard in 2011.
|
|
1
|
+
# Decisions & Constraints for AI Development
|
|
2
|
+
|
|
3
|
+
Persistent design context — decisions and constraints recorded as structured data — gives AI agents architectural memory across sessions. sqlew makes this zero-effort: plan normally, and hooks capture your decisions automatically.
|
|
4
|
+
|
|
5
|
+
## Why Persistent Design Context Matters
|
|
6
|
+
|
|
7
|
+
Research shows that recording design intent dramatically improves LLM code generation:
|
|
8
|
+
|
|
9
|
+
- **22.4% reduction** in overall development time
|
|
10
|
+
- **80% of tasks** completed faster with design intent available
|
|
11
|
+
- **50%+ improvement** in feature-addition and architectural-change tasks
|
|
12
|
+
- **137% increase** in design decision references by final tasks — AI learns to leverage past context more over time
|
|
13
|
+
|
|
14
|
+
> Kitayama, S. (2026). *Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation*. [DOI](https://doi.org/10.36227/techrxiv.177205025.54351571/v1)
|
|
15
|
+
>
|
|
16
|
+
> Blog post: [Recording Design Intent for AI Efficiency](https://blog.sqlew.io/recording-design-intent-for-ai-efficiency)
|
|
17
|
+
|
|
18
|
+
## Key Benefits for AI-Driven Development
|
|
19
|
+
|
|
20
|
+
### Persistent Architectural Memory
|
|
21
|
+
- **Zero context loss** – AI agents remember every architectural decision across sessions
|
|
22
|
+
- **Rationale preservation** – Never forget WHY a decision was made, not just WHAT
|
|
23
|
+
- **Alternative tracking** – Document rejected options to prevent circular debates
|
|
24
|
+
- **Evolution history** – See how decisions changed over time with full version history
|
|
25
|
+
|
|
26
|
+
### Prevent Architectural Drift
|
|
27
|
+
- **Constraint enforcement** – Define architectural rules once, AI follows them forever
|
|
28
|
+
- **Pattern consistency** – AI generates code matching established patterns automatically
|
|
29
|
+
- **Anti-pattern prevention** – Document "what NOT to do" as enforceable constraints
|
|
30
|
+
- **Regression prevention** – AI won't reintroduce previously rejected approaches
|
|
31
|
+
|
|
32
|
+
### Intelligent Decision Discovery
|
|
33
|
+
- **Three-tier duplicate detection** – Gentle nudge (35-44), hard block (45-59), or auto-update (60+) based on similarity score
|
|
34
|
+
- **Similarity detection** – AI identifies duplicate or related decisions before creating new ones
|
|
35
|
+
- **Context-aware search** – Query by layer, tags, or relationships to find relevant decisions
|
|
36
|
+
- **Conflict detection** – Find decisions that contradict or supersede each other
|
|
37
|
+
|
|
38
|
+
### Extreme Efficiency
|
|
39
|
+
- **60-75% token reduction** – Query only relevant decisions instead of reading full files
|
|
40
|
+
- **Millisecond queries** – 2-50ms response times even with thousands of decisions
|
|
41
|
+
- **Scalable architecture** – Perform well with large decision histories
|
|
42
|
+
|
|
43
|
+
## How sqlew Works
|
|
44
|
+
|
|
45
|
+
```mermaid
|
|
46
|
+
flowchart LR
|
|
47
|
+
subgraph Claude Code
|
|
48
|
+
A[Plan Mode] -->|Create Plan| B[User Approval]
|
|
49
|
+
B -->|ExitPlanMode| C[Hook Triggered]
|
|
50
|
+
end
|
|
51
|
+
|
|
52
|
+
subgraph sqlew
|
|
53
|
+
C -->|Enqueue| D[Queue File]
|
|
54
|
+
D -->|QueueWatcher| E[(SQL Database)]
|
|
55
|
+
end
|
|
56
|
+
|
|
57
|
+
subgraph Next Session
|
|
58
|
+
F[AI Agent] -->|Query| E
|
|
59
|
+
E -->|Past Decisions| F
|
|
60
|
+
end
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
**Zero-effort knowledge accumulation:**
|
|
64
|
+
1. You plan your work normally in Claude Code
|
|
65
|
+
2. Hooks automatically capture decisions
|
|
66
|
+
3. Next session, AI queries past decisions via SQL
|
|
67
|
+
|
|
68
|
+
## Core Concepts
|
|
69
|
+
|
|
70
|
+
**Decisions** capture architectural choices with full context:
|
|
71
|
+
- **What** was decided (the decision itself)
|
|
72
|
+
- **Why** it was chosen (rationale, trade-offs)
|
|
73
|
+
- **What else** was considered (alternatives rejected)
|
|
74
|
+
- **Impact** on the system (consequences, affected components)
|
|
75
|
+
|
|
76
|
+
**Constraints** define architectural principles and rules:
|
|
77
|
+
- **Performance requirements** (response time limits, throughput goals)
|
|
78
|
+
- **Technology choices** ("must use PostgreSQL", "avoid microservices")
|
|
79
|
+
- **Coding standards** ("async/await only", "no any types")
|
|
80
|
+
- **Security policies** (authentication patterns, data handling rules)
|
|
81
|
+
|
|
82
|
+
**Lifecycle tracking:**
|
|
83
|
+
- **Status evolution** tracks decision lifecycle (draft → active → deprecated)
|
|
84
|
+
- **Auto-capture via Hooks** records decisions automatically from Plan Mode
|
|
85
|
+
|
|
86
|
+
```mermaid
|
|
87
|
+
erDiagram
|
|
88
|
+
DECISION ||--o{ TAG : has
|
|
89
|
+
DECISION {
|
|
90
|
+
string key
|
|
91
|
+
string value
|
|
92
|
+
string layer
|
|
93
|
+
string status
|
|
94
|
+
timestamp updated
|
|
95
|
+
}
|
|
96
|
+
CONSTRAINT ||--o{ TAG : has
|
|
97
|
+
CONSTRAINT {
|
|
98
|
+
string text
|
|
99
|
+
string category
|
|
100
|
+
int priority
|
|
101
|
+
}
|
|
102
|
+
TAG {
|
|
103
|
+
string name
|
|
104
|
+
}
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
## SQL vs Markdown
|
|
108
|
+
|
|
109
|
+
| Traditional approach (Markdown) | sqlew approach (SQL) |
|
|
110
|
+
|--------------------------------|---------------------|
|
|
111
|
+
| Read entire files | Query specific decisions |
|
|
112
|
+
| Manual duplicate checking | Automatic similarity detection |
|
|
113
|
+
| Text parsing required | Structured, typed data |
|
|
114
|
+
| Linear token scaling | Constant-time lookups |
|
|
115
|
+
| File-based organization | Relational queries with JOINs |
|
|
116
|
+
|
|
117
|
+
### Why SQL?
|
|
118
|
+
|
|
119
|
+
Traditional text-based records force AI to:
|
|
120
|
+
- Read complete files even for simple queries
|
|
121
|
+
- Parse unstructured text to find relationships
|
|
122
|
+
- Manually detect duplicate or conflicting decisions
|
|
123
|
+
|
|
124
|
+
sqlew's **SQL-backed decision repository** enables AI to:
|
|
125
|
+
- Query by layer, tags, status in milliseconds (2-50ms)
|
|
126
|
+
- Join decisions with constraints
|
|
127
|
+
- Leverage similarity algorithms to prevent duplicates
|
|
128
|
+
- Scale to thousands of decisions without context explosion
|
|
129
|
+
|
|
130
|
+
**Token efficiency**: 60-75% reduction compared to reading Markdown files
|
|
131
|
+
|
|
132
|
+
### Why RDBMS + MCP?
|
|
133
|
+
|
|
134
|
+
**RDBMS (Relational Database)** provides efficient structured queries:
|
|
135
|
+
- **Indexed searches** – Find decisions by tags/layers in milliseconds, not seconds
|
|
136
|
+
- **JOIN operations** – Query related decisions and constraints in a single operation
|
|
137
|
+
- **Transaction support** – ACID guarantees ensure data integrity across concurrent AI agents
|
|
138
|
+
- **Scalability** – Handle thousands of decisions without performance degradation
|
|
139
|
+
|
|
140
|
+
**MCP (Model Context Protocol)** enables seamless AI integration:
|
|
141
|
+
- **Seamless DB connection** – AI agents access the database through a standardized protocol without direct DB setup
|
|
142
|
+
- **Self-documenting tools** – Tool descriptions teach AI how to use each operation, no manual onboarding needed
|
|
143
|
+
- **Type safety** – Structured parameters prevent errors and guide correct usage
|
|
144
|
+
- **Cross-session persistence** – Decisions survive beyond individual chat sessions
|
|
145
|
+
|
|
146
|
+
**Together**: AI agents gain SQL-powered decision capabilities without managing databases directly.
|
|
147
|
+
|
|
148
|
+
## References
|
|
149
|
+
|
|
150
|
+
- Kitayama, S. (2026). *Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation*. [DOI](https://doi.org/10.36227/techrxiv.177205025.54351571/v1)
|
|
151
|
+
- Blog: [Recording Design Intent for AI Efficiency](https://blog.sqlew.io/recording-design-intent-for-ai-efficiency)
|
|
152
|
+
- The concept of Architecture Decision Records was originally proposed by Michael Nygard in 2011.
|