@claudetools/tools 0.8.10 → 0.9.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/dist/codedna/generators/astro.d.ts +18 -0
- package/dist/codedna/generators/astro.js +91 -0
- package/dist/codedna/generators/authjs.d.ts +18 -0
- package/dist/codedna/generators/authjs.js +68 -0
- package/dist/codedna/generators/better-auth.d.ts +18 -0
- package/dist/codedna/generators/better-auth.js +62 -0
- package/dist/codedna/generators/drizzle-orm.d.ts +18 -0
- package/dist/codedna/generators/drizzle-orm.js +65 -0
- package/dist/codedna/generators/elysia-api.d.ts +12 -0
- package/dist/codedna/generators/elysia-api.js +64 -0
- package/dist/codedna/generators/hono-api.d.ts +12 -0
- package/dist/codedna/generators/hono-api.js +64 -0
- package/dist/codedna/generators/lucia-auth.d.ts +18 -0
- package/dist/codedna/generators/lucia-auth.js +69 -0
- package/dist/codedna/generators/prisma.d.ts +18 -0
- package/dist/codedna/generators/prisma.js +64 -0
- package/dist/codedna/generators/react-router-v7.d.ts +18 -0
- package/dist/codedna/generators/react-router-v7.js +77 -0
- package/dist/codedna/generators/react19-shadcn.d.ts +21 -0
- package/dist/codedna/generators/react19-shadcn.js +367 -0
- package/dist/codedna/generators/sveltekit.d.ts +18 -0
- package/dist/codedna/generators/sveltekit.js +73 -0
- package/dist/codedna/generators/tanstack-start-drizzle.d.ts +92 -0
- package/dist/codedna/generators/tanstack-start-drizzle.js +824 -0
- package/dist/codedna/generators/trpc-api.d.ts +12 -0
- package/dist/codedna/generators/trpc-api.js +64 -0
- package/dist/codedna/index.d.ts +31 -0
- package/dist/codedna/index.js +39 -0
- package/dist/codedna/kappa-api-generator.d.ts +89 -0
- package/dist/codedna/kappa-api-generator.js +493 -0
- package/dist/codedna/kappa-ast.d.ts +552 -0
- package/dist/codedna/kappa-ast.js +141 -0
- package/dist/codedna/kappa-cli.d.ts +2 -0
- package/dist/codedna/kappa-cli.js +302 -0
- package/dist/codedna/kappa-component-generator.d.ts +47 -0
- package/dist/codedna/kappa-component-generator.js +295 -0
- package/dist/codedna/kappa-design-generator.d.ts +52 -0
- package/dist/codedna/kappa-design-generator.js +365 -0
- package/dist/codedna/kappa-drizzle-generator.d.ts +45 -0
- package/dist/codedna/kappa-drizzle-generator.js +355 -0
- package/dist/codedna/kappa-form-generator.d.ts +51 -0
- package/dist/codedna/kappa-form-generator.js +319 -0
- package/dist/codedna/kappa-lexer.d.ts +268 -0
- package/dist/codedna/kappa-lexer.js +757 -0
- package/dist/codedna/kappa-page-generator.d.ts +57 -0
- package/dist/codedna/kappa-page-generator.js +338 -0
- package/dist/codedna/kappa-parser.d.ts +261 -0
- package/dist/codedna/kappa-parser.js +2547 -0
- package/dist/codedna/kappa-provenance.d.ts +101 -0
- package/dist/codedna/kappa-provenance.js +199 -0
- package/dist/codedna/kappa-types-generator.d.ts +37 -0
- package/dist/codedna/kappa-types-generator.js +159 -0
- package/dist/codedna/kappa-validator.d.ts +86 -0
- package/dist/codedna/kappa-validator.js +638 -0
- package/dist/codedna/kappa-zod-generator.d.ts +32 -0
- package/dist/codedna/kappa-zod-generator.js +216 -0
- package/dist/handlers/codedna-handlers.d.ts +1 -1
- package/dist/handlers/kappa-handlers.d.ts +116 -0
- package/dist/handlers/kappa-handlers.js +465 -0
- package/dist/handlers/tool-handlers.js +121 -0
- package/dist/templates/claude-md.d.ts +1 -1
- package/dist/templates/claude-md.js +166 -9
- package/dist/tools.js +199 -0
- package/docs/research/2026-01-02-codedna-il-specification.md +639 -0
- package/docs/research/2026-01-02-codedna-v2-research.md +943 -0
- package/docs/research/2026-01-02-computation-foundations.md +564 -0
- package/docs/research/2026-01-02-hardware-description.md +814 -0
- package/docs/research/2026-01-02-kappa-specification.md +697 -0
- package/docs/research/2026-01-02-kappa-tanstack-example.md +527 -0
- package/docs/research/2026-01-02-kappa-v2-synthesis.md +406 -0
- package/docs/research/2026-01-02-kappa-v2.5-specification.md +1218 -0
- package/docs/research/2026-01-02-kappa-v3-specification.md +1864 -0
- package/docs/research/2026-01-02-kappa-whitepaper.md +662 -0
- package/docs/research/2026-01-02-logic-constraint.md +731 -0
- package/docs/research/2026-01-02-quantum-computation.md +635 -0
- package/package.json +4 -2
|
@@ -0,0 +1,635 @@
|
|
|
1
|
+
# Quantum Computation Models and Type Systems
|
|
2
|
+
|
|
3
|
+
**Research Date:** 2 January 2026
|
|
4
|
+
**Task:** Understanding quantum computation models and their relationship to classical type systems
|
|
5
|
+
**Key Question:** Can quantum and classical computation be unified in one type system?
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Executive Summary
|
|
10
|
+
|
|
11
|
+
Quantum computation cannot be trivially unified with classical computation in a single type system due to fundamental physical constraints (no-cloning theorem) and mathematical structure differences (linear vs. Cartesian). However, significant theoretical progress has been made through:
|
|
12
|
+
|
|
13
|
+
1. **Linear Type Theory** - Enforces no-cloning at the type level
|
|
14
|
+
2. **Categorical Quantum Mechanics** - Dagger compact closed categories provide mathematical foundation
|
|
15
|
+
3. **Hybrid Classical-Quantum Languages** - Proto-Quipper, Q#, Qiskit manage the boundary explicitly
|
|
16
|
+
4. **Graphical Calculi** - ZX-calculus enables equational reasoning about quantum processes
|
|
17
|
+
|
|
18
|
+
The quantum-classical boundary is managed through careful type system design, not eliminated entirely.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 1. Quantum Lambda Calculus
|
|
23
|
+
|
|
24
|
+
### Overview
|
|
25
|
+
|
|
26
|
+
Quantum lambda calculus extends classical lambda calculus to model quantum computation by integrating linear types, quantum operations, and classical control. Multiple variants exist, each addressing different aspects of quantum programming.
|
|
27
|
+
|
|
28
|
+
### Historical Development
|
|
29
|
+
|
|
30
|
+
**Foundational Work (2003-2006):**
|
|
31
|
+
- [Van Tonder (2003)](https://arxiv.org/abs/quant-ph/0307150) introduced the first quantum lambda calculus
|
|
32
|
+
- [Selinger & Valiron (2004-2006)](https://arxiv.org/abs/cs/0404056) developed a lambda calculus for quantum computation with classical control
|
|
33
|
+
- Both use affine intuitionistic linear logic for type systems
|
|
34
|
+
|
|
35
|
+
**Recent Advances (2024-2025):**
|
|
36
|
+
|
|
37
|
+
1. **Lambda-SX (2025)** - [Presented at APLAS 2025](https://link.springer.com/chapter/10.1007/978-981-95-3585-9_8), supports multiple measurement bases in a typed quantum lambda-calculus (LNCS vol 16201)
|
|
38
|
+
|
|
39
|
+
2. **Qurts (2025)** - "Qurts: Automatic Quantum Uncomputation by Affine Types with Lifetime" published in [POPL 2025](https://dl.acm.org/doi/10.1145/3373718.3394765), introduces automatic resource management
|
|
40
|
+
|
|
41
|
+
3. **IMALL with Mixed-State Modality (2025)** - "IMALL with a Mixed-State Modality: A Logical Approach to Quantum Computation" (June 2025) provides logical foundations
|
|
42
|
+
|
|
43
|
+
4. **Review Paper (2024-2025)** - [Comprehensive survey](https://publications.eai.eu/index.php/casa/article/view/9668) of quantum lambda calculi covering QΛ, QLC, Proto-Quipper, and QML
|
|
44
|
+
|
|
45
|
+
### Key Design Principles
|
|
46
|
+
|
|
47
|
+
**Call-by-Value Semantics:**
|
|
48
|
+
- Quantum operations must be evaluated eagerly (no lazy evaluation of quantum states)
|
|
49
|
+
- Prevents unintended superposition of classical control flow
|
|
50
|
+
|
|
51
|
+
**Linear Type Systems:**
|
|
52
|
+
- Enforce "use exactly once" for quantum data
|
|
53
|
+
- Prevents duplication (no-cloning) and deletion (no-deleting) at compile time
|
|
54
|
+
- Based on affine/linear intuitionistic logic
|
|
55
|
+
|
|
56
|
+
**Classical Control Flow:**
|
|
57
|
+
- Classical data can be duplicated and deleted freely
|
|
58
|
+
- Measurement converts quantum → classical (irreversible)
|
|
59
|
+
- Enables hybrid quantum-classical algorithms
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## 2. ZX-Calculus: Graphical Quantum Reasoning
|
|
64
|
+
|
|
65
|
+
### Mathematical Foundation
|
|
66
|
+
|
|
67
|
+
The [ZX-calculus](https://en.wikipedia.org/wiki/ZX-calculus) is a rigorous graphical language for reasoning about linear maps between qubits, represented as string diagrams called ZX-diagrams.
|
|
68
|
+
|
|
69
|
+
**Categorical Structure:**
|
|
70
|
+
- ZX-diagrams form a **dagger compact category**
|
|
71
|
+
- Built freely from generators via composition and monoidal product
|
|
72
|
+
- Spiders represent specific tensors connected to form tensor networks
|
|
73
|
+
|
|
74
|
+
**Generators:**
|
|
75
|
+
- **Green spiders** and **red spiders** arise from complementary observables
|
|
76
|
+
- Each corresponds to a commutative Frobenius algebra in a dagger symmetric monoidal category
|
|
77
|
+
- Their interaction follows Hopf-like laws
|
|
78
|
+
|
|
79
|
+
### Completeness and Soundness
|
|
80
|
+
|
|
81
|
+
[Proven complete](https://link.aps.org/doi/10.1103/PhysRevResearch.7.033141): Two ZX-diagrams represent the same linear map if and only if they can be transformed into each other using ZX-calculus rewrite rules.
|
|
82
|
+
|
|
83
|
+
**Historical Milestone:**
|
|
84
|
+
- Introduced by Bob Coecke and Ross Duncan (2009)
|
|
85
|
+
- Miriam Backens proved completeness for Clifford fragment (2013) - stabiliser quantum mechanics
|
|
86
|
+
- Enables full graphical reasoning for stabiliser circuits without matrices
|
|
87
|
+
|
|
88
|
+
### Applications
|
|
89
|
+
|
|
90
|
+
1. **Measurement-Based Quantum Computing** - Describes graph states and MBQC protocols
|
|
91
|
+
2. **Quantum Error Correction** - [Finding and verifying](https://ar5iv.labs.arxiv.org/html/0906.4725) error correcting codes
|
|
92
|
+
3. **Circuit Optimisation** - Automated quantum circuit simplification
|
|
93
|
+
4. **Lattice Surgery** - Language for surface code operations
|
|
94
|
+
|
|
95
|
+
### Recent Developments (2024-2025)
|
|
96
|
+
|
|
97
|
+
- [ZX graphical calculus for continuous-variable quantum processes](https://journals.aps.org/prresearch/abstract/10.1103/PhysRevResearch.7.033141) (Physical Review Research, 2025)
|
|
98
|
+
- Extension to infinite-dimensional systems
|
|
99
|
+
- Integration with categorical quantum mechanics
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## 3. Linear Types and the No-Cloning Theorem
|
|
104
|
+
|
|
105
|
+
### The Physical Constraint
|
|
106
|
+
|
|
107
|
+
The [no-cloning theorem](https://en.wikipedia.org/wiki/No-cloning_theorem) states that it is impossible to create an independent and identical copy of an arbitrary unknown quantum state.
|
|
108
|
+
|
|
109
|
+
**Mathematical Basis:**
|
|
110
|
+
- Quantum operations are unitary linear transformations
|
|
111
|
+
- Cloning would require a non-linear operation
|
|
112
|
+
- Fundamental to quantum physics, not a technical limitation
|
|
113
|
+
|
|
114
|
+
### Type-Theoretic Enforcement
|
|
115
|
+
|
|
116
|
+
**Key Insight:** [From nLab](https://ncatlab.org/nlab/show/no-cloning+theorem)
|
|
117
|
+
> "When quantum physics is axiomatised by quantum logic in the guise of linear logic/linear type theory, the content of 'no-cloning' and 'no-deleting' is the very 'linearity' of this logic, the absence of a diagonal map and of a projection map for the non-cartesian tensor product."
|
|
118
|
+
|
|
119
|
+
**Implementation Approaches:**
|
|
120
|
+
|
|
121
|
+
1. **Linear Types (QML, Qimaera, QWIRE):**
|
|
122
|
+
- Every function must use each parameter **exactly once**
|
|
123
|
+
- Prevents state copying at compile time
|
|
124
|
+
- Inspired by Linear Lambda Calculus
|
|
125
|
+
|
|
126
|
+
2. **Affine Types (Proto-Quipper):**
|
|
127
|
+
- Use each parameter **at most once**
|
|
128
|
+
- Allows deliberate discarding (with caution)
|
|
129
|
+
- More flexible than pure linear types
|
|
130
|
+
|
|
131
|
+
3. **Type-Level Programming ([Haskell model](https://sol.sbc.org.br/index.php/sblp/article/view/36952)):**
|
|
132
|
+
- Enforces no-cloning via memory access patterns
|
|
133
|
+
- Compile-time prevention of invalid operations
|
|
134
|
+
- Uses monadic composition for expressiveness
|
|
135
|
+
|
|
136
|
+
### Linear Dependent Type Theory
|
|
137
|
+
|
|
138
|
+
**Problem:** High-level quantum languages need:
|
|
139
|
+
- Linear types (no-cloning)
|
|
140
|
+
- Dependent types (circuit families indexed by classical parameters)
|
|
141
|
+
- First-class quantum circuits
|
|
142
|
+
|
|
143
|
+
**Solution:** [Proto-Quipper-D](https://arxiv.org/abs/2004.13472) (Linear Dependent Type Theory)
|
|
144
|
+
- Combines linear types with dependent types
|
|
145
|
+
- Semantic structure via fibrations of monoidal categories
|
|
146
|
+
- Enables type-safe uncomputation of garbage qubits
|
|
147
|
+
- Supports families like `Vec Qubit n` where `n : Nat`
|
|
148
|
+
|
|
149
|
+
---
|
|
150
|
+
|
|
151
|
+
## 4. Practical Quantum Programming Languages
|
|
152
|
+
|
|
153
|
+
### Quipper: Functional Quantum Programming
|
|
154
|
+
|
|
155
|
+
[Quipper](https://arxiv.org/abs/1304.3390) is a scalable, expressive, functional, higher-order quantum programming language embedded in Haskell.
|
|
156
|
+
|
|
157
|
+
**Key Features:**
|
|
158
|
+
- **Embedded DSL** - Implemented as Haskell library, uses Haskell compiler
|
|
159
|
+
- **Scalability** - Has generated circuits with trillions of gates
|
|
160
|
+
- **Automatic Reversibility** - `build_circuit` keyword converts classical functions to reversible circuits
|
|
161
|
+
- **Monadic Semantics** - `Circ` monad for quantum circuits with formal foundations
|
|
162
|
+
- **Well-Founded** - Based on Quantum Lambda Calculus
|
|
163
|
+
|
|
164
|
+
**Design Philosophy:**
|
|
165
|
+
- High-level, concise representation of quantum algorithms
|
|
166
|
+
- Classical computer controls quantum device
|
|
167
|
+
- Hardware-agnostic (not tied to specific quantum hardware model)
|
|
168
|
+
|
|
169
|
+
**Proto-Quipper Family:**
|
|
170
|
+
- Proto-Quipper-S (simple)
|
|
171
|
+
- Proto-Quipper-M (monadic)
|
|
172
|
+
- [Proto-Quipper-D](https://dl.acm.org/doi/10.1145/3373718.3394765) (dependent types) - LICS 2020
|
|
173
|
+
- Proto-Quipper with Reversing and Control (EPTCS 2025)
|
|
174
|
+
|
|
175
|
+
**Current Status:**
|
|
176
|
+
- Release 0.9.0.0 (Dec 2019) - installable via Cabal
|
|
177
|
+
- Active research on formal foundations
|
|
178
|
+
|
|
179
|
+
### Q#, Qiskit, and Cirq: Industry Frameworks
|
|
180
|
+
|
|
181
|
+
#### [Q# (Microsoft)](https://www.bluequbit.io/quantum-programming-languages)
|
|
182
|
+
- **High-level domain-specific language** for quantum computing
|
|
183
|
+
- **Hybrid workflows** - Integrates quantum algorithms into classical workflows
|
|
184
|
+
- **Quantum Development Kit (QDK)** - Test on classical and quantum hardware
|
|
185
|
+
- **Type system** - Aims for user-friendliness, manages entanglement and types
|
|
186
|
+
- **Integration** - Works with C#, F#, Python for host programs
|
|
187
|
+
|
|
188
|
+
#### [Qiskit (IBM)](https://blog.mlq.ai/quantum-programming-with-qiskit/)
|
|
189
|
+
- **Open-source framework** - Python-based, easy-to-use interface
|
|
190
|
+
- **Architecture** - Divided into Terra, Aer, Ignis, and Aqua elements
|
|
191
|
+
- **Focus** - Pulses, circuits, and algorithms for IBM quantum hardware
|
|
192
|
+
- **Abstraction level** - Low-level operations, granular control
|
|
193
|
+
|
|
194
|
+
#### [Cirq (Google)](https://quantumai.google/cirq)
|
|
195
|
+
- **NISQ-focused** - Designed for Noisy Intermediate-Scale Quantum computers
|
|
196
|
+
- **Noise modeling** - Accurately models quantum noise (crucial for real hardware)
|
|
197
|
+
- **Python library** - Writing, manipulating, optimising quantum circuits
|
|
198
|
+
- **Control** - Hardware details matter for state-of-the-art results
|
|
199
|
+
|
|
200
|
+
### The Classical-Quantum Boundary
|
|
201
|
+
|
|
202
|
+
**Hybrid Quantum-Classical Workflows:**
|
|
203
|
+
- [NISQ algorithms](https://quantumzeitgeist.com/cirq-vs-qiskit-vs-q-3-quantum-programming-languages-which-should-you-choose/) iterate between quantum and classical processors
|
|
204
|
+
- Variational algorithms: quantum circuit → measurement → classical optimiser → repeat
|
|
205
|
+
- Quantum device as subroutine called by classical code
|
|
206
|
+
|
|
207
|
+
**Type Promotion and Conversion ([Qutes](https://arxiv.org/html/2503.13084v1)):**
|
|
208
|
+
- Type promotion between classical and quantum types
|
|
209
|
+
- Quantum → classical via measurement (irreversible)
|
|
210
|
+
- Classical → quantum via state preparation
|
|
211
|
+
|
|
212
|
+
**Noise and Decoherence:**
|
|
213
|
+
- NISQ devices encounter errors from noise, decoherence, complexity
|
|
214
|
+
- Short circuit depths required
|
|
215
|
+
- Hybrid workflows combine quantum runs with classical postprocessing
|
|
216
|
+
|
|
217
|
+
---
|
|
218
|
+
|
|
219
|
+
## 5. Categorical Quantum Mechanics
|
|
220
|
+
|
|
221
|
+
### Dagger Compact Closed Categories
|
|
222
|
+
|
|
223
|
+
[Categorical quantum mechanics](https://en.wikipedia.org/wiki/Categorical_quantum_mechanics) takes dagger compact categories as background structure for defining quantum observables and complementarity.
|
|
224
|
+
|
|
225
|
+
**Definition:**
|
|
226
|
+
- First appeared in Doplicher & Roberts (1989) - reconstruction of compact topological groups
|
|
227
|
+
- Introduced for quantum mechanics by Abramsky & Coecke (2004) as "strongly compact closed categories"
|
|
228
|
+
- Axiomatises quantum mechanics categorically
|
|
229
|
+
|
|
230
|
+
**Key Properties:**
|
|
231
|
+
|
|
232
|
+
1. **Compact Closed:**
|
|
233
|
+
- Related to Choi-Jamiołkowski isomorphism (process-state duality)
|
|
234
|
+
- Allows wires to be bent in diagrams
|
|
235
|
+
- Enables entangled states and measurements
|
|
236
|
+
- Distinguishes "input" vs "output" of processes
|
|
237
|
+
|
|
238
|
+
2. **Dagger Structure:**
|
|
239
|
+
- Captures ability to take adjoints of linear maps
|
|
240
|
+
- Models quantum conjugation
|
|
241
|
+
- `f†` reverses direction and conjugates
|
|
242
|
+
|
|
243
|
+
**Graphical Calculus:**
|
|
244
|
+
- [Complete for equational reasoning](https://www.mscs.dal.ca/~selinger/papers/dagger.pdf) (Selinger 2006)
|
|
245
|
+
- Equality of morphisms provable in finite-dimensional Hilbert spaces ⟺ provable in graphical language
|
|
246
|
+
- String diagrams represent morphisms visually
|
|
247
|
+
|
|
248
|
+
### Expressiveness
|
|
249
|
+
|
|
250
|
+
**Can Express:**
|
|
251
|
+
- Unitarity
|
|
252
|
+
- Inner products
|
|
253
|
+
- Trace
|
|
254
|
+
- Choi-Jamiolkowsky duality
|
|
255
|
+
- Complete positivity
|
|
256
|
+
- Bell states
|
|
257
|
+
- Teleportation protocol
|
|
258
|
+
- Logic gate teleportation
|
|
259
|
+
- Entanglement swapping
|
|
260
|
+
|
|
261
|
+
**CPM Construction:**
|
|
262
|
+
- Associates to each dagger compact closed category its "category of completely positive maps"
|
|
263
|
+
- Resulting category is again dagger compact closed
|
|
264
|
+
- Models open quantum systems
|
|
265
|
+
|
|
266
|
+
### Limitations and Extensions
|
|
267
|
+
|
|
268
|
+
**Finite vs Infinite Dimensions:**
|
|
269
|
+
- Dagger compact closed structure works for **finite-dimensional** Hilbert spaces
|
|
270
|
+
- Infinite-dimensional spaces require **dagger symmetric monoidal categories** (not compact)
|
|
271
|
+
- Significant portion of quantum physics involves infinite dimensions
|
|
272
|
+
|
|
273
|
+
**Connection to Linear Logic:**
|
|
274
|
+
- †-compact categories have as internal logic a **fragment of linear logic**
|
|
275
|
+
- Type theory flavour is **linear type theory**
|
|
276
|
+
- Everything about quantum mechanics in †-compact categories has equivalent expression in formal logic/type theory
|
|
277
|
+
|
|
278
|
+
---
|
|
279
|
+
|
|
280
|
+
## 6. Can Quantum and Classical Be Unified?
|
|
281
|
+
|
|
282
|
+
### The Fundamental Differences
|
|
283
|
+
|
|
284
|
+
#### 1. **Structural Differences**
|
|
285
|
+
|
|
286
|
+
**Classical Computing:**
|
|
287
|
+
- Cartesian monoidal categories
|
|
288
|
+
- Diagonal map exists: `Δ : A → A ⊗ A` (duplication)
|
|
289
|
+
- Projection map exists: `! : A → 1` (deletion)
|
|
290
|
+
- Classical data can be freely copied and discarded
|
|
291
|
+
|
|
292
|
+
**Quantum Computing:**
|
|
293
|
+
- Non-Cartesian monoidal categories (linear)
|
|
294
|
+
- No diagonal map (no-cloning theorem)
|
|
295
|
+
- No projection map (no-deleting theorem)
|
|
296
|
+
- Quantum data must be used exactly once
|
|
297
|
+
|
|
298
|
+
#### 2. **The Measurement Problem**
|
|
299
|
+
|
|
300
|
+
The [measurement problem](https://en.wikipedia.org/wiki/Measurement_problem) represents a fundamental discontinuity:
|
|
301
|
+
|
|
302
|
+
**Before Measurement (Quantum):**
|
|
303
|
+
- System in superposition: `|ψ⟩ = α|0⟩ + β|1⟩`
|
|
304
|
+
- Evolution via Schrödinger equation (linear, deterministic)
|
|
305
|
+
- Pure state, quantum information
|
|
306
|
+
|
|
307
|
+
**After Measurement (Classical):**
|
|
308
|
+
- [Wave function collapse](https://en.wikipedia.org/wiki/Wave_function_collapse) to single eigenstate
|
|
309
|
+
- Nonlinear, stochastic process
|
|
310
|
+
- Mixed state, classical information
|
|
311
|
+
- Irreversible
|
|
312
|
+
|
|
313
|
+
**The Boundary Question:**
|
|
314
|
+
> "How can one establish a correspondence between quantum reality and classical reality?" - Measurement Problem Wikipedia
|
|
315
|
+
|
|
316
|
+
No consensus exists on where the quantum-classical divide precisely lies. This is not a technical detail but a foundational issue in quantum mechanics interpretation.
|
|
317
|
+
|
|
318
|
+
#### 3. **Decoherence vs Collapse**
|
|
319
|
+
|
|
320
|
+
[Quantum decoherence](https://en.wikipedia.org/wiki/Quantum_decoherence):
|
|
321
|
+
- Explains transition from pure state (superpositions) to mixed state (classical alternatives)
|
|
322
|
+
- System + environment interaction
|
|
323
|
+
- Major challenge for quantum computing
|
|
324
|
+
- **But does not explain wave function collapse** - all alternatives still present
|
|
325
|
+
|
|
326
|
+
### Approaches to Unification
|
|
327
|
+
|
|
328
|
+
#### 1. **Type System Stratification**
|
|
329
|
+
|
|
330
|
+
**Modern Approach:** Don't unify - manage the boundary explicitly
|
|
331
|
+
|
|
332
|
+
**Example: [Typing Quantum Superpositions](https://link.springer.com/chapter/10.1007/978-3-319-71069-3_22)**
|
|
333
|
+
- Quantum extension of first-order simply-typed lambda calculus
|
|
334
|
+
- Type is **linear on superposition**
|
|
335
|
+
- Allows **cloning of base vectors** (classical data)
|
|
336
|
+
- Interpretation: superposed types = vector spaces, non-superposed = basis
|
|
337
|
+
|
|
338
|
+
**Example: [qACP Process Algebra](https://ar5iv.labs.arxiv.org/html/1311.2960)**
|
|
339
|
+
- Axiomatisation unifying quantum and classical processes
|
|
340
|
+
- Quantum and classical information can be mixed
|
|
341
|
+
- Unified under quantum process configuration framework
|
|
342
|
+
|
|
343
|
+
#### 2. **Categorical Approach**
|
|
344
|
+
|
|
345
|
+
**Special Commutative Dagger Frobenius Algebras:**
|
|
346
|
+
- Model processes yielding **classical information**
|
|
347
|
+
- Classical data can be cloned or deleted
|
|
348
|
+
- Captures classical communication within quantum framework
|
|
349
|
+
|
|
350
|
+
**Dagger Biproducts:**
|
|
351
|
+
- Used to study classical communication
|
|
352
|
+
- Capture superposition principle
|
|
353
|
+
- Provide categorical semantics for hybrid systems
|
|
354
|
+
|
|
355
|
+
#### 3. **Linear Homotopy Type Theory**
|
|
356
|
+
|
|
357
|
+
[HoTT and Computing Conference 2024](https://nyuad.nyu.edu/en/events/2024/april/homotopy-type-theory-and-computing.html):
|
|
358
|
+
- **Linear HoTT** can specify linear quantum circuits parameterised by non-linear classical data
|
|
359
|
+
- Similar to Proto-Quipper family
|
|
360
|
+
- Brings theoretical progress into contact with practical quantum computing
|
|
361
|
+
|
|
362
|
+
### The Answer: Partial Unification
|
|
363
|
+
|
|
364
|
+
**What Can Be Unified:**
|
|
365
|
+
1. **Categorical framework** - Monoidal categories encompass both
|
|
366
|
+
2. **Type discipline** - Linear + non-linear types coexist
|
|
367
|
+
3. **Graphical calculi** - String diagrams for both quantum and classical processes
|
|
368
|
+
4. **Dependent types** - Classical parameters index quantum circuit families
|
|
369
|
+
|
|
370
|
+
**What Cannot Be Unified:**
|
|
371
|
+
1. **Copying semantics** - Classical allows duplication, quantum forbids it
|
|
372
|
+
2. **Measurement** - Irreversible quantum → classical transition
|
|
373
|
+
3. **Superposition** - Quantum states exist in superposition, classical states don't
|
|
374
|
+
4. **Information theory** - Quantum information fundamentally different from classical
|
|
375
|
+
|
|
376
|
+
**Best Practice:**
|
|
377
|
+
- Use **stratified type systems** (e.g., Proto-Quipper-D)
|
|
378
|
+
- Classical types: Cartesian (can duplicate/delete)
|
|
379
|
+
- Quantum types: Linear (must use exactly once)
|
|
380
|
+
- Explicit conversion via measurement
|
|
381
|
+
- Manage the boundary, don't erase it
|
|
382
|
+
|
|
383
|
+
---
|
|
384
|
+
|
|
385
|
+
## 7. What Makes Quantum Fundamentally Different?
|
|
386
|
+
|
|
387
|
+
### Physical Constraints
|
|
388
|
+
|
|
389
|
+
1. **No-Cloning Theorem**
|
|
390
|
+
- Cannot copy arbitrary unknown quantum state
|
|
391
|
+
- Consequence of linearity of quantum mechanics
|
|
392
|
+
- [Not a technical limitation](https://www.quantiki.org/wiki/no-cloning-theorem), but physical law
|
|
393
|
+
|
|
394
|
+
2. **No-Deleting Theorem**
|
|
395
|
+
- Cannot delete quantum information
|
|
396
|
+
- Dual to no-cloning
|
|
397
|
+
- Required by unitarity
|
|
398
|
+
|
|
399
|
+
3. **Superposition**
|
|
400
|
+
- [Quantum system exists in multiple states simultaneously](https://postquantum.com/quantum-computing/quantum-superposition/)
|
|
401
|
+
- Not "unknown classical state" but genuinely both states
|
|
402
|
+
- `|ψ⟩ = α|0⟩ + β|1⟩` where `|α|² + |β|² = 1`
|
|
403
|
+
|
|
404
|
+
4. **Entanglement**
|
|
405
|
+
- Correlations stronger than classical physics allows
|
|
406
|
+
- Cannot be created classically
|
|
407
|
+
- Resource for quantum computation
|
|
408
|
+
|
|
409
|
+
### Type-Theoretic Consequences
|
|
410
|
+
|
|
411
|
+
1. **Linearity Required**
|
|
412
|
+
- Type system must prevent duplication
|
|
413
|
+
- Affine or linear types enforce this
|
|
414
|
+
- Classical type systems inadequate
|
|
415
|
+
|
|
416
|
+
2. **Measurement as Type Conversion**
|
|
417
|
+
- `Quantum a → Classical a` (via measurement)
|
|
418
|
+
- Irreversible operation
|
|
419
|
+
- Information loss (`|α|²`, `|β|²` probabilities, not `α`, `β` amplitudes)
|
|
420
|
+
|
|
421
|
+
3. **Circuit Families Need Dependent Types**
|
|
422
|
+
- `Vec Qubit n` where `n : Nat`
|
|
423
|
+
- Classical parameter indexes quantum data structure
|
|
424
|
+
- Proto-Quipper-D solution: linear dependent types
|
|
425
|
+
|
|
426
|
+
---
|
|
427
|
+
|
|
428
|
+
## 8. Existing Quantum Languages: Handling the Boundary
|
|
429
|
+
|
|
430
|
+
### Summary Table
|
|
431
|
+
|
|
432
|
+
| Language | Classical-Quantum Boundary | Type System | Key Innovation |
|
|
433
|
+
|----------|---------------------------|-------------|----------------|
|
|
434
|
+
| **Quipper** | Haskell host controls quantum device | Embedded DSL, `Circ` monad | Automatic reversibility via `build_circuit` |
|
|
435
|
+
| **Proto-Quipper-D** | Linear dependent types | Linear + dependent | Circuit families, type-safe uncomputation |
|
|
436
|
+
| **Q#** | Integrated hybrid workflows | Domain-specific | Seamless classical-quantum integration |
|
|
437
|
+
| **Qiskit** | Python orchestrates quantum circuits | Python + quantum gates | IBM hardware focus, modular architecture |
|
|
438
|
+
| **Cirq** | Python controls NISQ devices | Python + quantum ops | Noise modeling for real hardware |
|
|
439
|
+
| **QML** | Linear types for quantum data | Linear types | Academic, type-safe |
|
|
440
|
+
| **Silq** | Automatic uncomputation | High-level, automatic | Implicit classical handling |
|
|
441
|
+
| **Twist** | Entanglement types | Entanglement tracking | Purity and entanglement constraints |
|
|
442
|
+
| **Qutes (2025)** | Type promotion | Classical ↔ quantum conversion | Simplified quantum programming |
|
|
443
|
+
|
|
444
|
+
### Design Patterns
|
|
445
|
+
|
|
446
|
+
1. **Embedded DSL in Classical Language**
|
|
447
|
+
- Quipper (Haskell), Qiskit/Cirq (Python)
|
|
448
|
+
- Classical language orchestrates quantum operations
|
|
449
|
+
- Leverages existing ecosystem
|
|
450
|
+
|
|
451
|
+
2. **Monadic Quantum Operations**
|
|
452
|
+
- `Circ` monad (Quipper)
|
|
453
|
+
- Sequence quantum operations
|
|
454
|
+
- Maintains referential transparency
|
|
455
|
+
|
|
456
|
+
3. **Linear Type Discipline**
|
|
457
|
+
- Proto-Quipper, QML, QWIRE
|
|
458
|
+
- Compile-time enforcement of no-cloning
|
|
459
|
+
- Explicit resource management
|
|
460
|
+
|
|
461
|
+
4. **Automatic Resource Management**
|
|
462
|
+
- Silq: automatic uncomputation
|
|
463
|
+
- Qurts (2025): affine types with lifetime
|
|
464
|
+
- Reduces programmer burden
|
|
465
|
+
|
|
466
|
+
---
|
|
467
|
+
|
|
468
|
+
## 9. Conclusions
|
|
469
|
+
|
|
470
|
+
### Key Findings
|
|
471
|
+
|
|
472
|
+
1. **Quantum and classical computation cannot be trivially unified**
|
|
473
|
+
- Different categorical structures (Cartesian vs non-Cartesian)
|
|
474
|
+
- No-cloning theorem is fundamental, not technical
|
|
475
|
+
- Measurement boundary is physical, not just semantic
|
|
476
|
+
|
|
477
|
+
2. **Linear type theory is essential**
|
|
478
|
+
- Enforces no-cloning at compile time
|
|
479
|
+
- Affine/linear types mirror physical constraints
|
|
480
|
+
- "Linearity" of quantum logic captures no-cloning/no-deleting
|
|
481
|
+
|
|
482
|
+
3. **Categorical quantum mechanics provides rigorous foundation**
|
|
483
|
+
- Dagger compact closed categories axiomatise quantum mechanics
|
|
484
|
+
- String diagrams enable equational reasoning
|
|
485
|
+
- Complete graphical calculus (ZX-calculus)
|
|
486
|
+
|
|
487
|
+
4. **Successful unification requires stratification**
|
|
488
|
+
- Classical types: Cartesian (copyable)
|
|
489
|
+
- Quantum types: Linear (non-copyable)
|
|
490
|
+
- Explicit boundary management via measurement
|
|
491
|
+
- Proto-Quipper-D as exemplar: linear dependent types
|
|
492
|
+
|
|
493
|
+
5. **The measurement problem remains fundamental**
|
|
494
|
+
- Quantum (superposition, linear) → Classical (definite, nonlinear)
|
|
495
|
+
- No consensus on where boundary lies
|
|
496
|
+
- Type systems manage, not eliminate, this boundary
|
|
497
|
+
|
|
498
|
+
### Implications for Type System Design
|
|
499
|
+
|
|
500
|
+
**If designing a unified computational type system:**
|
|
501
|
+
|
|
502
|
+
1. **Stratify** classical and quantum types
|
|
503
|
+
- Classical: standard typing rules (Cartesian structure)
|
|
504
|
+
- Quantum: linear typing rules (no duplication/deletion)
|
|
505
|
+
|
|
506
|
+
2. **Dependent types** for circuit families
|
|
507
|
+
- Classical parameters index quantum data
|
|
508
|
+
- Proto-Quipper-D as reference
|
|
509
|
+
|
|
510
|
+
3. **Categorical semantics**
|
|
511
|
+
- Ground in monoidal category theory
|
|
512
|
+
- Dagger structure for quantum adjoint
|
|
513
|
+
- String diagrams as syntax
|
|
514
|
+
|
|
515
|
+
4. **Explicit measurement**
|
|
516
|
+
- Type: `Quantum a → M (Classical a)` (monadic)
|
|
517
|
+
- Or: `measure : Quantum a → Classical a` (side-effecting)
|
|
518
|
+
- No implicit conversions
|
|
519
|
+
|
|
520
|
+
5. **Superposition not directly expressible in classical types**
|
|
521
|
+
- `|ψ⟩ = α|0⟩ + β|1⟩` requires quantum type
|
|
522
|
+
- Classical types see only measurement outcomes
|
|
523
|
+
- Amplitude information invisible to classical types
|
|
524
|
+
|
|
525
|
+
### Open Questions
|
|
526
|
+
|
|
527
|
+
1. **Where exactly is the quantum-classical boundary?**
|
|
528
|
+
- Measurement problem unresolved
|
|
529
|
+
- Many-worlds vs collapse interpretations
|
|
530
|
+
- Decoherence helps but doesn't fully explain collapse
|
|
531
|
+
|
|
532
|
+
2. **Can we do better than linear dependent types?**
|
|
533
|
+
- Are there more expressive type systems?
|
|
534
|
+
- Can we capture more quantum properties?
|
|
535
|
+
- What about error correction at type level?
|
|
536
|
+
|
|
537
|
+
3. **Infinite-dimensional quantum systems?**
|
|
538
|
+
- Dagger compact categories insufficient
|
|
539
|
+
- Need dagger symmetric monoidal categories
|
|
540
|
+
- How to handle continuous variables?
|
|
541
|
+
|
|
542
|
+
4. **Automated reasoning and verification?**
|
|
543
|
+
- ZX-calculus enables automated circuit optimisation
|
|
544
|
+
- Can we prove quantum algorithms correct?
|
|
545
|
+
- Type-level verification of quantum properties?
|
|
546
|
+
|
|
547
|
+
---
|
|
548
|
+
|
|
549
|
+
## References
|
|
550
|
+
|
|
551
|
+
### Quantum Lambda Calculus
|
|
552
|
+
- Van Tonder, A. (2003). [A Lambda Calculus for Quantum Computation](https://arxiv.org/abs/quant-ph/0307150). arXiv:quant-ph/0307150.
|
|
553
|
+
- Selinger, P., & Valiron, B. (2006). [A lambda calculus for quantum computation with classical control](https://arxiv.org/abs/cs/0404056). Mathematical Structures in Computer Science.
|
|
554
|
+
- Review Paper (2024). [A Review of Quantum Lambda Calculi: Linearity, Semantics, and Programming Models](https://publications.eai.eu/index.php/casa/article/view/9668). EAI Transactions.
|
|
555
|
+
- Lambda-SX (2025). [A Quantum-Control Lambda-Calculus with Multiple Measurement Bases](https://link.springer.com/chapter/10.1007/978-981-95-3585-9_8). APLAS 2025.
|
|
556
|
+
- Qurts (2025). Qurts: Automatic Quantum Uncomputation by Affine Types with Lifetime. POPL 2025.
|
|
557
|
+
|
|
558
|
+
### ZX-Calculus
|
|
559
|
+
- Coecke, B., & Duncan, R. (2011). [Interacting Quantum Observables: Categorical Algebra and Diagrammatics](https://ar5iv.labs.arxiv.org/html/0906.4725). New Journal of Physics.
|
|
560
|
+
- [ZX-Calculus Wikipedia](https://en.wikipedia.org/wiki/ZX-calculus)
|
|
561
|
+
- [ZX graphical calculus for continuous-variable quantum processes](https://journals.aps.org/prresearch/abstract/10.1103/PhysRevResearch.7.033141) (2025). Physical Review Research.
|
|
562
|
+
- Backens, M. (2013). The ZX-Calculus for Stabilizer Quantum Mechanics. [n-Category Café](https://golem.ph.utexas.edu/category/2019/04/the_zxcalculus_for_stabilizer.html).
|
|
563
|
+
|
|
564
|
+
### Linear Types and No-Cloning
|
|
565
|
+
- [No-cloning theorem](https://ncatlab.org/nlab/show/no-cloning+theorem). nLab.
|
|
566
|
+
- [No-cloning theorem](https://en.wikipedia.org/wiki/No-cloning_theorem). Wikipedia.
|
|
567
|
+
- [Modeling Quantum Computing Constraints: No-Cloning Theorem and Monadic Expressiveness](https://sol.sbc.org.br/index.php/sblp/article/view/36952) (2024). SBLP.
|
|
568
|
+
|
|
569
|
+
### Proto-Quipper and Linear Dependent Types
|
|
570
|
+
- Fu, P., Kishida, K., & Selinger, P. (2020). [Linear Dependent Type Theory for Quantum Programming Languages](https://arxiv.org/abs/2004.13472). LICS 2020.
|
|
571
|
+
- Fu, P., & Kishida, K. (2020). [A Tutorial Introduction to Quantum Circuit Programming in Dependently Typed Proto-Quipper](https://link.springer.com/chapter/10.1007/978-3-030-52482-1_9). Springer LNCS.
|
|
572
|
+
- Proto-Quipper with Reversing and Control (2025). EPTCS.
|
|
573
|
+
|
|
574
|
+
### Practical Quantum Languages
|
|
575
|
+
- Green, A. S., et al. (2013). [Quipper: A Scalable Quantum Programming Language](https://arxiv.org/abs/1304.3390). PLDI 2013.
|
|
576
|
+
- [The Quipper Language](https://www.mathstat.dal.ca/~selinger/quipper/). Official documentation.
|
|
577
|
+
- [Quantum Programming Languages: A Beginner's Guide for 2025](https://www.bluequbit.io/quantum-programming-languages). BlueQubit.
|
|
578
|
+
- [Cirq vs Qiskit vs Q#](https://quantumzeitgeist.com/cirq-vs-qiskit-vs-q-3-quantum-programming-languages-which-should-you-choose/). Quantum Zeitgeist.
|
|
579
|
+
- [Introduction to Quantum Programming with Qiskit](https://blog.mlq.ai/quantum-programming-with-qiskit/). MLQ.ai.
|
|
580
|
+
- Qutes (2025). [Qutes: A High-Level Quantum Programming Language](https://arxiv.org/html/2503.13084v1). arXiv.
|
|
581
|
+
|
|
582
|
+
### Categorical Quantum Mechanics
|
|
583
|
+
- Abramsky, S., & Coecke, B. (2004). [Categorical quantum mechanics](https://en.wikipedia.org/wiki/Categorical_quantum_mechanics). Handbook of Quantum Logic and Quantum Structures.
|
|
584
|
+
- Selinger, P. (2007). [Dagger Compact Closed Categories and Completely Positive Maps](https://www.mscs.dal.ca/~selinger/papers/dagger.pdf). ENTCS.
|
|
585
|
+
- [Dagger compact category](https://en.wikipedia.org/wiki/Dagger_compact_category). Wikipedia.
|
|
586
|
+
- [Quantum information theory via dagger-compact categories](https://ncatlab.org/nlab/show/quantum+information+theory+via+dagger-compact+categories). nLab.
|
|
587
|
+
- Duncan, R., & Perdrix, S. (2018). [Dagger linear logic for categorical quantum mechanics](https://arxiv.org/abs/1809.00275). arXiv.
|
|
588
|
+
|
|
589
|
+
### Measurement and Quantum-Classical Boundary
|
|
590
|
+
- [Measurement problem](https://en.wikipedia.org/wiki/Measurement_problem). Wikipedia.
|
|
591
|
+
- [Wave function collapse](https://en.wikipedia.org/wiki/Wave_function_collapse). Wikipedia.
|
|
592
|
+
- [Quantum decoherence](https://en.wikipedia.org/wiki/Quantum_decoherence). Wikipedia.
|
|
593
|
+
- Bassi, A., et al. (2023). [Collapse Models: A Theoretical, Experimental and Philosophical Review](https://www.mdpi.com/1099-4300/25/4/645). Entropy.
|
|
594
|
+
|
|
595
|
+
### Unification Approaches
|
|
596
|
+
- [Typing Quantum Superpositions and Measurement](https://link.springer.com/chapter/10.1007/978-3-319-71069-3_22) (2017). Springer LNCS.
|
|
597
|
+
- Feng, Y. (2013). [An Axiomatization for Quantum Processes to Unifying Quantum and Classical Computing](https://ar5iv.labs.arxiv.org/html/1311.2960). arXiv.
|
|
598
|
+
- [Homotopy Type Theory and Computing — Classical and Quantum](https://nyuad.nyu.edu/en/events/2024/april/homotopy-type-theory-and-computing.html) (2024). NYU Abu Dhabi Conference.
|
|
599
|
+
|
|
600
|
+
### Quantum Superposition and Computing Basics
|
|
601
|
+
- [Quantum Superposition](https://postquantum.com/quantum-computing/quantum-superposition/). PostQuantum.
|
|
602
|
+
- [Microsoft Quantum: Superposition](https://quantum.microsoft.com/en-us/insights/education/concepts/superposition). Microsoft.
|
|
603
|
+
- [Quantum computing](https://en.wikipedia.org/wiki/Quantum_computing). Wikipedia.
|
|
604
|
+
|
|
605
|
+
---
|
|
606
|
+
|
|
607
|
+
## Appendix: Key Concepts Glossary
|
|
608
|
+
|
|
609
|
+
**Affine Types:** Types that must be used **at most once** (can be discarded, not duplicated).
|
|
610
|
+
|
|
611
|
+
**Bell States:** Maximally entangled quantum states of two qubits.
|
|
612
|
+
|
|
613
|
+
**Choi-Jamiołkowski Isomorphism:** Process-state duality - correspondence between quantum channels and density matrices.
|
|
614
|
+
|
|
615
|
+
**Clifford Fragment:** Subset of quantum operations generated by Hadamard, CNOT, and phase gates (stabiliser operations).
|
|
616
|
+
|
|
617
|
+
**Compact Closed Category:** Monoidal category where every object has a dual, enabling "bending wires" in diagrams.
|
|
618
|
+
|
|
619
|
+
**Dagger Category:** Category with a contravariant functor †: C^op → C that is identity on objects and involutive.
|
|
620
|
+
|
|
621
|
+
**Dagger Compact Category:** Category that is both dagger and compact closed.
|
|
622
|
+
|
|
623
|
+
**Frobenius Algebra:** Algebraic structure with compatible multiplication and comultiplication satisfying Frobenius law.
|
|
624
|
+
|
|
625
|
+
**Linear Types:** Types that must be used **exactly once** (neither duplicated nor discarded).
|
|
626
|
+
|
|
627
|
+
**Monoidal Category:** Category with tensor product ⊗ and unit object satisfying coherence axioms.
|
|
628
|
+
|
|
629
|
+
**NISQ:** Noisy Intermediate-Scale Quantum - current era of quantum computers (50-1000 qubits, significant noise).
|
|
630
|
+
|
|
631
|
+
**String Diagrams:** Graphical notation for morphisms in monoidal categories, read compositionally.
|
|
632
|
+
|
|
633
|
+
**Unitary Operation:** Quantum operation U where U†U = UU† = I (preserves inner products, reversible).
|
|
634
|
+
|
|
635
|
+
**ZX-Spider:** Generator in ZX-calculus representing a multi-input, multi-output node with a phase.
|
package/package.json
CHANGED
|
@@ -1,11 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@claudetools/tools",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.9.0",
|
|
4
4
|
"description": "Persistent AI memory, task management, and codebase intelligence for Claude Code",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|
|
7
7
|
"bin": {
|
|
8
|
-
"claudetools": "dist/cli.js"
|
|
8
|
+
"claudetools": "dist/cli.js",
|
|
9
|
+
"kappa": "dist/codedna/kappa-cli.js"
|
|
9
10
|
},
|
|
10
11
|
"files": [
|
|
11
12
|
"dist",
|
|
@@ -60,6 +61,7 @@
|
|
|
60
61
|
"@modelcontextprotocol/sdk": "^1.0.0",
|
|
61
62
|
"better-sqlite3": "^12.5.0",
|
|
62
63
|
"chalk": "^5.6.2",
|
|
64
|
+
"chevrotain": "^11.0.3",
|
|
63
65
|
"nunjucks": "^3.2.4",
|
|
64
66
|
"ora": "^9.0.0",
|
|
65
67
|
"prompts": "^2.4.2",
|