@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,639 @@
|
|
|
1
|
+
# CodeDNA-IL: Universal Intent Language Specification
|
|
2
|
+
|
|
3
|
+
**Version:** 2.0.0-draft
|
|
4
|
+
**Date:** 2026-01-02
|
|
5
|
+
**Status:** Extended for Full Universality
|
|
6
|
+
|
|
7
|
+
## Executive Summary
|
|
8
|
+
|
|
9
|
+
CodeDNA-IL is a **universal standard language** for AI-driven code generation across ALL code types - not just web applications, but game engines, shaders, physics simulations, ML models, compilers, embedded systems, and literally anything that can be coded.
|
|
10
|
+
|
|
11
|
+
### Why a New Language?
|
|
12
|
+
|
|
13
|
+
1. **Current Entity DSL is too narrow** - Only describes data structures, can't express algorithms, flows, or transformations
|
|
14
|
+
2. **No existing DSL is universal** - Every DSL is domain-specific (Prisma for DBs, GraphQL for APIs, Terraform for infra)
|
|
15
|
+
3. **Different code requires different paradigms** - Sequential steps don't work for shaders, game loops, or physics
|
|
16
|
+
4. **Token efficiency requires purpose-built syntax** - JSON/YAML are 10x more verbose than necessary
|
|
17
|
+
5. **AI agents need structured intent, not code** - Natural language is ambiguous; formal languages are too syntactic
|
|
18
|
+
|
|
19
|
+
### Research Foundation
|
|
20
|
+
|
|
21
|
+
This specification is informed by:
|
|
22
|
+
- [IRCoder research](https://arxiv.org/abs/2407.05411): "Natural language consistently emerges as the most effective intermediate representation"
|
|
23
|
+
- [CrossTL architecture](https://arxiv.org/abs/2508.21256): Universal IR enabling bidirectional translation
|
|
24
|
+
- [OpenRewrite's LST](https://www.moderne.ai/blog/automated-javascript-refactoring-at-enterprise-scale): Lossless Semantic Trees for cross-language refactoring
|
|
25
|
+
- [IBM AI Refactoring](https://www.ibm.com/think/topics/ai-code-refactoring): Semantic-level code transformation patterns
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## Three Dimensions of Code
|
|
30
|
+
|
|
31
|
+
CodeDNA-IL addresses code across three orthogonal dimensions:
|
|
32
|
+
|
|
33
|
+
### 1. DOMAIN (What are we building?)
|
|
34
|
+
The `type:` field indicates the problem domain:
|
|
35
|
+
|
|
36
|
+
| Type | Domain | Examples |
|
|
37
|
+
|------|--------|----------|
|
|
38
|
+
| `api` | Web services | REST, GraphQL, gRPC |
|
|
39
|
+
| `service` | Business logic | Auth, payments, notifications |
|
|
40
|
+
| `component` | UI elements | React, Vue, Svelte components |
|
|
41
|
+
| `model` | Data structures | Entities, DTOs, schemas |
|
|
42
|
+
| `shader` | GPU programs | Vertex, fragment, compute |
|
|
43
|
+
| `layer` | ML building blocks | Attention, convolution, normalization |
|
|
44
|
+
| `scene` | 3D/2D worlds | Game scenes, VR environments |
|
|
45
|
+
| `physics` | Simulations | Rigid body, fluid, cloth |
|
|
46
|
+
| `engine` | Game/app engines | Game loops, state machines |
|
|
47
|
+
| `pipeline` | Data processing | ETL, streaming, batch |
|
|
48
|
+
| `infrastructure` | Cloud resources | AWS, GCP, Kubernetes |
|
|
49
|
+
| `protocol` | Network protocols | TCP handlers, WebSocket, custom |
|
|
50
|
+
| `compiler` | Language tools | Lexers, parsers, code gen |
|
|
51
|
+
| `embedded` | Hardware/IoT | Firmware, drivers, sensors |
|
|
52
|
+
| `cli` | Command-line tools | Commands, flags, prompts |
|
|
53
|
+
| `library` | Reusable modules | SDKs, utilities, frameworks |
|
|
54
|
+
|
|
55
|
+
### 2. PARADIGM (How does it execute?)
|
|
56
|
+
Different code requires different expression modes:
|
|
57
|
+
|
|
58
|
+
| Keyword | Paradigm | Use Case |
|
|
59
|
+
|---------|----------|----------|
|
|
60
|
+
| `step:` | Sequential | Do A, then B, then C (APIs, scripts) |
|
|
61
|
+
| `formula:` | Mathematical | Compute relationships (shaders, ML) |
|
|
62
|
+
| `on:` | Event-driven | React to events (games, UI) |
|
|
63
|
+
| `parallel:` | Concurrent | Do simultaneously (GPU, workers) |
|
|
64
|
+
| `solve:` | Constraint-based | Make this true (physics, layout) |
|
|
65
|
+
| `loop:` | Continuous | Frame-based execution (games, servers) |
|
|
66
|
+
| `stream:` | Reactive | Data flow (pipelines, observables) |
|
|
67
|
+
|
|
68
|
+
### 3. STYLE (How does it look/feel?)
|
|
69
|
+
For visual/UX code, the `style:` block captures design intent:
|
|
70
|
+
|
|
71
|
+
```
|
|
72
|
+
style: {
|
|
73
|
+
design_system: shadcn
|
|
74
|
+
palette: { primary: amber, accent: slate }
|
|
75
|
+
typography: { heading: inter, body: system }
|
|
76
|
+
motion: subtle_spring
|
|
77
|
+
art_direction: stylized_cel_shading # For games
|
|
78
|
+
}
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Design Principles
|
|
84
|
+
|
|
85
|
+
### 1. Intent-Based, Not Syntax-Based
|
|
86
|
+
CodeDNA-IL describes WHAT the code should do, not HOW it's written. The AI agent determines implementation details based on target language, framework, and constraints.
|
|
87
|
+
|
|
88
|
+
### 2. Multi-Paradigm Expression
|
|
89
|
+
Different types of code require different expression modes. A shader uses `formula:`, a game uses `loop:` + `on:`, an API uses `step:`. The language supports all paradigms natively.
|
|
90
|
+
|
|
91
|
+
### 3. Universal Domain Coverage
|
|
92
|
+
One language works for ANY code type - web apps, games, ML, infrastructure, embedded, compilers, protocols - everything.
|
|
93
|
+
|
|
94
|
+
### 4. Dual-Mode Operation
|
|
95
|
+
- **DEFINE mode**: Create new code units
|
|
96
|
+
- **TRANSFORM mode**: Modify existing code
|
|
97
|
+
|
|
98
|
+
### 5. Design-Aware
|
|
99
|
+
For visual code (games, UI, graphics), the `style:` block captures aesthetic intent alongside behavior.
|
|
100
|
+
|
|
101
|
+
### 6. Token Efficiency
|
|
102
|
+
Every token must carry meaning. No redundant syntax, no verbose delimiters.
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
## Core Syntax
|
|
107
|
+
|
|
108
|
+
### Unit Block (Universal Building Block)
|
|
109
|
+
|
|
110
|
+
```
|
|
111
|
+
unit <name> {
|
|
112
|
+
type: <unit_type>
|
|
113
|
+
purpose: "<description>"
|
|
114
|
+
|
|
115
|
+
<attributes>
|
|
116
|
+
<operations>
|
|
117
|
+
<constraints>
|
|
118
|
+
}
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
**Unit Types:**
|
|
122
|
+
- `api` - REST/GraphQL endpoint
|
|
123
|
+
- `service` - Business logic component
|
|
124
|
+
- `model` - Data model/entity
|
|
125
|
+
- `component` - UI component
|
|
126
|
+
- `function` - Standalone function
|
|
127
|
+
- `pipeline` - Data processing pipeline
|
|
128
|
+
- `ml_model` - Machine learning model
|
|
129
|
+
- `infrastructure` - Cloud resources
|
|
130
|
+
- `cli` - Command-line tool
|
|
131
|
+
- `library` - Reusable module
|
|
132
|
+
|
|
133
|
+
### Inputs and Outputs
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
inputs: (name:type, name:type:modifier)
|
|
137
|
+
outputs: (name:type)
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
**Type Shortcuts:**
|
|
141
|
+
- `str` = string
|
|
142
|
+
- `int` = integer
|
|
143
|
+
- `dec` = decimal
|
|
144
|
+
- `bool` = boolean
|
|
145
|
+
- `dt` = datetime
|
|
146
|
+
- `[]` suffix = array
|
|
147
|
+
- `?` suffix = optional
|
|
148
|
+
|
|
149
|
+
**Modifiers:**
|
|
150
|
+
- `unique` - Must be unique
|
|
151
|
+
- `required` - Cannot be null
|
|
152
|
+
- `hashed` - Should be hashed
|
|
153
|
+
- `email` - Email format
|
|
154
|
+
- `min(n)` / `max(n)` - Value constraints
|
|
155
|
+
- `default(v)` - Default value
|
|
156
|
+
|
|
157
|
+
### Operations
|
|
158
|
+
|
|
159
|
+
```
|
|
160
|
+
op <name> {
|
|
161
|
+
step: <natural language description>
|
|
162
|
+
step: <natural language description>
|
|
163
|
+
return: <value>
|
|
164
|
+
}
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
Steps use natural language that AI understands semantically. Multiple steps indicate sequence.
|
|
168
|
+
|
|
169
|
+
### Constraints
|
|
170
|
+
|
|
171
|
+
```
|
|
172
|
+
constraint: <requirement>
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
Constraints are domain-specific requirements that the generated code must satisfy.
|
|
176
|
+
|
|
177
|
+
---
|
|
178
|
+
|
|
179
|
+
## Examples by Domain
|
|
180
|
+
|
|
181
|
+
### Web Application (API Service)
|
|
182
|
+
|
|
183
|
+
```
|
|
184
|
+
unit UserService {
|
|
185
|
+
type: service
|
|
186
|
+
purpose: "Handle user authentication and session management"
|
|
187
|
+
|
|
188
|
+
inputs: (email:str:email, password:str)
|
|
189
|
+
outputs: (token:str, user:User)
|
|
190
|
+
|
|
191
|
+
op authenticate {
|
|
192
|
+
step: validate credentials against database
|
|
193
|
+
step: generate JWT with user claims, 24h expiry
|
|
194
|
+
step: record login timestamp
|
|
195
|
+
return: token, user
|
|
196
|
+
}
|
|
197
|
+
|
|
198
|
+
op logout {
|
|
199
|
+
step: invalidate token in blacklist
|
|
200
|
+
step: clear user session
|
|
201
|
+
}
|
|
202
|
+
|
|
203
|
+
op refresh {
|
|
204
|
+
step: verify refresh token validity
|
|
205
|
+
step: generate new access token
|
|
206
|
+
return: token
|
|
207
|
+
}
|
|
208
|
+
|
|
209
|
+
constraint: bcrypt(12) for password hashing
|
|
210
|
+
constraint: rate_limit(5/min) on authenticate
|
|
211
|
+
constraint: https_only
|
|
212
|
+
}
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
### Systems Programming (Rust TCP Handler)
|
|
216
|
+
|
|
217
|
+
```
|
|
218
|
+
unit tcp_handler {
|
|
219
|
+
type: function
|
|
220
|
+
purpose: "Handle incoming TCP connections with HTTP parsing"
|
|
221
|
+
language_hint: rust
|
|
222
|
+
|
|
223
|
+
inputs: (stream:TcpStream)
|
|
224
|
+
outputs: (Result<Response, IoError>)
|
|
225
|
+
|
|
226
|
+
lifecycle: async, owned
|
|
227
|
+
|
|
228
|
+
op handle {
|
|
229
|
+
step: read request bytes from stream with timeout
|
|
230
|
+
step: parse HTTP method and headers
|
|
231
|
+
step: route to appropriate handler based on path
|
|
232
|
+
step: serialize response and write to stream
|
|
233
|
+
return: response
|
|
234
|
+
}
|
|
235
|
+
|
|
236
|
+
constraint: timeout(30s)
|
|
237
|
+
constraint: max_request_size(10mb)
|
|
238
|
+
constraint: graceful_shutdown_aware
|
|
239
|
+
}
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
### Data Pipeline (ETL)
|
|
243
|
+
|
|
244
|
+
```
|
|
245
|
+
unit user_analytics_pipeline {
|
|
246
|
+
type: pipeline
|
|
247
|
+
purpose: "Extract user data, compute metrics, load to analytics warehouse"
|
|
248
|
+
|
|
249
|
+
source: postgres.public.users
|
|
250
|
+
sink: bigquery.analytics.user_metrics
|
|
251
|
+
schedule: daily(02:00 UTC)
|
|
252
|
+
|
|
253
|
+
stage extract {
|
|
254
|
+
select: id, email, created_at, last_login_at
|
|
255
|
+
filter: created_at > {7_days_ago}
|
|
256
|
+
}
|
|
257
|
+
|
|
258
|
+
stage transform {
|
|
259
|
+
derive: days_active = count_distinct(activity_dates)
|
|
260
|
+
derive: engagement_score = days_active / days_since_signup
|
|
261
|
+
normalize: email -> lowercase
|
|
262
|
+
drop: created_at
|
|
263
|
+
}
|
|
264
|
+
|
|
265
|
+
stage load {
|
|
266
|
+
mode: upsert
|
|
267
|
+
key: id
|
|
268
|
+
partition_by: date(loaded_at)
|
|
269
|
+
}
|
|
270
|
+
|
|
271
|
+
constraint: idempotent
|
|
272
|
+
constraint: retry(3, exponential_backoff)
|
|
273
|
+
}
|
|
274
|
+
```
|
|
275
|
+
|
|
276
|
+
### Machine Learning (Model Definition)
|
|
277
|
+
|
|
278
|
+
```
|
|
279
|
+
unit image_classifier {
|
|
280
|
+
type: ml_model
|
|
281
|
+
purpose: "Classify images into 10 categories"
|
|
282
|
+
framework_hint: pytorch
|
|
283
|
+
|
|
284
|
+
architecture: cnn {
|
|
285
|
+
layer: conv2d(in:3, out:64, kernel:3, padding:1)
|
|
286
|
+
layer: batch_norm(64)
|
|
287
|
+
layer: relu
|
|
288
|
+
layer: max_pool(2)
|
|
289
|
+
layer: conv2d(in:64, out:128, kernel:3)
|
|
290
|
+
layer: relu
|
|
291
|
+
layer: adaptive_avg_pool(1)
|
|
292
|
+
layer: flatten
|
|
293
|
+
layer: linear(128, 10)
|
|
294
|
+
}
|
|
295
|
+
|
|
296
|
+
training {
|
|
297
|
+
loss: cross_entropy
|
|
298
|
+
optimizer: adamw(lr:0.001, weight_decay:0.01)
|
|
299
|
+
scheduler: cosine_annealing(T_max:100)
|
|
300
|
+
epochs: 100
|
|
301
|
+
batch_size: 64
|
|
302
|
+
}
|
|
303
|
+
|
|
304
|
+
data {
|
|
305
|
+
source: imagenet_subset
|
|
306
|
+
split: train(0.8), val(0.1), test(0.1)
|
|
307
|
+
augment: random_crop(224), horizontal_flip, color_jitter
|
|
308
|
+
normalize: imagenet_stats
|
|
309
|
+
}
|
|
310
|
+
|
|
311
|
+
constraint: mixed_precision(fp16)
|
|
312
|
+
constraint: gradient_clipping(1.0)
|
|
313
|
+
}
|
|
314
|
+
```
|
|
315
|
+
|
|
316
|
+
### Infrastructure (Cloud Resources)
|
|
317
|
+
|
|
318
|
+
```
|
|
319
|
+
unit production_cluster {
|
|
320
|
+
type: infrastructure
|
|
321
|
+
purpose: "Scalable web application infrastructure on AWS"
|
|
322
|
+
provider: aws
|
|
323
|
+
region: us-east-1
|
|
324
|
+
|
|
325
|
+
resource vpc:main {
|
|
326
|
+
cidr: 10.0.0.0/16
|
|
327
|
+
availability_zones: 3
|
|
328
|
+
enable_dns_hostnames: true
|
|
329
|
+
}
|
|
330
|
+
|
|
331
|
+
resource ecs_cluster:app {
|
|
332
|
+
name: "production"
|
|
333
|
+
capacity_providers: [fargate, fargate_spot]
|
|
334
|
+
default_provider: fargate_spot(weight:80)
|
|
335
|
+
}
|
|
336
|
+
|
|
337
|
+
resource service:web {
|
|
338
|
+
cluster: ecs_cluster:app
|
|
339
|
+
task_definition: web_task
|
|
340
|
+
desired_count: 3
|
|
341
|
+
deployment: rolling(max_percent:200, min_healthy:100)
|
|
342
|
+
}
|
|
343
|
+
|
|
344
|
+
resource alb:public {
|
|
345
|
+
subnets: vpc:main.public_subnets
|
|
346
|
+
security_group: allow_https
|
|
347
|
+
}
|
|
348
|
+
|
|
349
|
+
scaling web {
|
|
350
|
+
metric: cpu_utilization
|
|
351
|
+
target: 70%
|
|
352
|
+
scale_in_cooldown: 300s
|
|
353
|
+
scale_out_cooldown: 60s
|
|
354
|
+
min_capacity: 2
|
|
355
|
+
max_capacity: 20
|
|
356
|
+
}
|
|
357
|
+
|
|
358
|
+
constraint: encrypted_at_rest
|
|
359
|
+
constraint: private_subnets_only(for:ecs)
|
|
360
|
+
constraint: waf_enabled
|
|
361
|
+
}
|
|
362
|
+
```
|
|
363
|
+
|
|
364
|
+
### CLI Tool
|
|
365
|
+
|
|
366
|
+
```
|
|
367
|
+
unit backup_cli {
|
|
368
|
+
type: cli
|
|
369
|
+
purpose: "Backup and restore files with incremental support"
|
|
370
|
+
|
|
371
|
+
command backup {
|
|
372
|
+
args: (source:path:required, destination:path:required)
|
|
373
|
+
flags: {
|
|
374
|
+
--compress: "Enable gzip compression"
|
|
375
|
+
--incremental: "Only backup changed files"
|
|
376
|
+
--exclude: "Glob patterns to exclude":str[]
|
|
377
|
+
}
|
|
378
|
+
|
|
379
|
+
op run {
|
|
380
|
+
step: validate source path exists
|
|
381
|
+
step: scan source directory for files
|
|
382
|
+
step: if incremental, load previous manifest and diff
|
|
383
|
+
step: copy files to destination, compressing if enabled
|
|
384
|
+
step: generate new manifest with checksums
|
|
385
|
+
step: write manifest to destination
|
|
386
|
+
}
|
|
387
|
+
}
|
|
388
|
+
|
|
389
|
+
command restore {
|
|
390
|
+
args: (backup:path:required, target:path:required)
|
|
391
|
+
flags: {
|
|
392
|
+
--verify: "Verify checksums after restore"
|
|
393
|
+
--dry-run: "Show what would be restored"
|
|
394
|
+
}
|
|
395
|
+
|
|
396
|
+
op run {
|
|
397
|
+
step: read and validate manifest
|
|
398
|
+
step: if dry-run, print file list and exit
|
|
399
|
+
step: decompress and copy files to target
|
|
400
|
+
step: if verify, check all checksums
|
|
401
|
+
}
|
|
402
|
+
}
|
|
403
|
+
|
|
404
|
+
constraint: cross_platform(linux, macos, windows)
|
|
405
|
+
constraint: progress_bar
|
|
406
|
+
}
|
|
407
|
+
```
|
|
408
|
+
|
|
409
|
+
---
|
|
410
|
+
|
|
411
|
+
## Transform Mode (Modifications)
|
|
412
|
+
|
|
413
|
+
Transform mode allows modifying existing code without redefining everything.
|
|
414
|
+
|
|
415
|
+
### Syntax
|
|
416
|
+
|
|
417
|
+
```
|
|
418
|
+
transform @<unit_reference> {
|
|
419
|
+
<operations>
|
|
420
|
+
}
|
|
421
|
+
```
|
|
422
|
+
|
|
423
|
+
### Operations
|
|
424
|
+
|
|
425
|
+
| Operation | Description |
|
|
426
|
+
|-----------|-------------|
|
|
427
|
+
| `add field: name:type` | Add a new field/property |
|
|
428
|
+
| `remove field: name` | Remove a field/property |
|
|
429
|
+
| `rename field: old -> new` | Rename a field/property |
|
|
430
|
+
| `change field: name -> type` | Change field type |
|
|
431
|
+
| `add op: name { ... }` | Add new operation |
|
|
432
|
+
| `remove op: name` | Remove operation |
|
|
433
|
+
| `modify op: name { ... }` | Modify existing operation |
|
|
434
|
+
| `add constraint: ...` | Add constraint |
|
|
435
|
+
| `remove constraint: ...` | Remove constraint |
|
|
436
|
+
|
|
437
|
+
### Examples
|
|
438
|
+
|
|
439
|
+
```
|
|
440
|
+
# Add email verification to UserService
|
|
441
|
+
transform @UserService {
|
|
442
|
+
add field: emailVerified:bool:default(false)
|
|
443
|
+
add field: verificationToken:str?
|
|
444
|
+
|
|
445
|
+
add op: sendVerificationEmail {
|
|
446
|
+
step: generate random verification token
|
|
447
|
+
step: save token to user record
|
|
448
|
+
step: send email with verification link
|
|
449
|
+
}
|
|
450
|
+
|
|
451
|
+
add op: verifyEmail {
|
|
452
|
+
inputs: (token:str)
|
|
453
|
+
step: find user by verification token
|
|
454
|
+
step: set emailVerified to true
|
|
455
|
+
step: clear verification token
|
|
456
|
+
}
|
|
457
|
+
|
|
458
|
+
modify op: authenticate {
|
|
459
|
+
after "validate credentials": check emailVerified is true
|
|
460
|
+
}
|
|
461
|
+
}
|
|
462
|
+
|
|
463
|
+
# Optimize database queries
|
|
464
|
+
transform @UserRepository {
|
|
465
|
+
add constraint: index(email)
|
|
466
|
+
add constraint: index(created_at)
|
|
467
|
+
|
|
468
|
+
modify op: findByEmail {
|
|
469
|
+
add: use prepared statement
|
|
470
|
+
add: connection pooling
|
|
471
|
+
}
|
|
472
|
+
}
|
|
473
|
+
|
|
474
|
+
# Add caching layer
|
|
475
|
+
transform @ProductService {
|
|
476
|
+
add field: cache:RedisCache
|
|
477
|
+
|
|
478
|
+
modify op: getById {
|
|
479
|
+
before: check cache for product
|
|
480
|
+
after "fetch from database": store in cache(ttl:1h)
|
|
481
|
+
}
|
|
482
|
+
}
|
|
483
|
+
```
|
|
484
|
+
|
|
485
|
+
---
|
|
486
|
+
|
|
487
|
+
## Compose Mode (Combining Units)
|
|
488
|
+
|
|
489
|
+
For building larger systems from smaller units.
|
|
490
|
+
|
|
491
|
+
```
|
|
492
|
+
compose OrderSystem {
|
|
493
|
+
units: [
|
|
494
|
+
UserService,
|
|
495
|
+
ProductService,
|
|
496
|
+
CartService,
|
|
497
|
+
PaymentService,
|
|
498
|
+
OrderService
|
|
499
|
+
]
|
|
500
|
+
|
|
501
|
+
flow: checkout {
|
|
502
|
+
step: CartService.getItems -> items
|
|
503
|
+
step: PaymentService.charge(items.total) -> payment
|
|
504
|
+
step: OrderService.create(items, payment) -> order
|
|
505
|
+
step: notify(UserService.current, order)
|
|
506
|
+
}
|
|
507
|
+
|
|
508
|
+
integration: {
|
|
509
|
+
UserService -> ProductService: share user context
|
|
510
|
+
CartService -> ProductService: lookup prices
|
|
511
|
+
OrderService -> PaymentService: payment webhooks
|
|
512
|
+
}
|
|
513
|
+
}
|
|
514
|
+
```
|
|
515
|
+
|
|
516
|
+
---
|
|
517
|
+
|
|
518
|
+
## Token Efficiency Analysis
|
|
519
|
+
|
|
520
|
+
| Representation | UserService Example | Token Count |
|
|
521
|
+
|----------------|---------------------|-------------|
|
|
522
|
+
| Natural language | "Create a user authentication service with JWT..." | ~150 tokens |
|
|
523
|
+
| TypeScript code | Full implementation with types, error handling | ~400 tokens |
|
|
524
|
+
| JSON Schema | Detailed API schema | ~300 tokens |
|
|
525
|
+
| Entity DSL (current) | `User(email:str, password:str:hashed)` | ~30 tokens |
|
|
526
|
+
| CodeDNA-IL | Full spec with operations and constraints | ~80 tokens |
|
|
527
|
+
|
|
528
|
+
**CodeDNA-IL is 5x more efficient than generated code while capturing 10x more semantic information than Entity DSL.**
|
|
529
|
+
|
|
530
|
+
---
|
|
531
|
+
|
|
532
|
+
## Language Hints and Target Mapping
|
|
533
|
+
|
|
534
|
+
The `language_hint` and `framework_hint` attributes guide code generation:
|
|
535
|
+
|
|
536
|
+
```
|
|
537
|
+
unit UserController {
|
|
538
|
+
type: api
|
|
539
|
+
framework_hint: express # Generates Express.js
|
|
540
|
+
# OR
|
|
541
|
+
framework_hint: fastapi # Generates FastAPI Python
|
|
542
|
+
# OR
|
|
543
|
+
framework_hint: hono # Generates Hono TypeScript
|
|
544
|
+
}
|
|
545
|
+
```
|
|
546
|
+
|
|
547
|
+
Without hints, the AI infers from project context or asks.
|
|
548
|
+
|
|
549
|
+
---
|
|
550
|
+
|
|
551
|
+
## Implementation Roadmap
|
|
552
|
+
|
|
553
|
+
### Phase 1: Parser
|
|
554
|
+
- [ ] Define formal grammar (PEG or similar)
|
|
555
|
+
- [ ] Build parser to AST
|
|
556
|
+
- [ ] Validate semantic correctness
|
|
557
|
+
|
|
558
|
+
### Phase 2: Code Generators
|
|
559
|
+
- [ ] Extend existing 20+ generators to accept CodeDNA-IL
|
|
560
|
+
- [ ] Add transform support to generators
|
|
561
|
+
- [ ] Add compose support
|
|
562
|
+
|
|
563
|
+
### Phase 3: IDE Integration
|
|
564
|
+
- [ ] Syntax highlighting
|
|
565
|
+
- [ ] Autocomplete
|
|
566
|
+
- [ ] Validation
|
|
567
|
+
|
|
568
|
+
### Phase 4: AI Training
|
|
569
|
+
- [ ] Create CodeDNA-IL ↔ code pairs dataset
|
|
570
|
+
- [ ] Fine-tune on generation tasks
|
|
571
|
+
- [ ] Benchmark token efficiency
|
|
572
|
+
|
|
573
|
+
---
|
|
574
|
+
|
|
575
|
+
## Comparison with Alternatives
|
|
576
|
+
|
|
577
|
+
| Feature | Entity DSL | GraphQL | Prisma | CodeDNA-IL |
|
|
578
|
+
|---------|------------|---------|--------|------------|
|
|
579
|
+
| Data models | ✓ | ✓ | ✓ | ✓ |
|
|
580
|
+
| Operations/behavior | ✗ | Partial | ✗ | ✓ |
|
|
581
|
+
| Constraints | Limited | ✗ | ✓ | ✓ |
|
|
582
|
+
| Transformations | ✗ | ✗ | ✗ | ✓ |
|
|
583
|
+
| Systems code | ✗ | ✗ | ✗ | ✓ |
|
|
584
|
+
| ML models | ✗ | ✗ | ✗ | ✓ |
|
|
585
|
+
| Infrastructure | ✗ | ✗ | ✗ | ✓ |
|
|
586
|
+
| Token efficient | ✓ | ✗ | ✗ | ✓ |
|
|
587
|
+
|
|
588
|
+
---
|
|
589
|
+
|
|
590
|
+
## Conclusion
|
|
591
|
+
|
|
592
|
+
CodeDNA-IL represents a fundamental shift from describing DATA to describing INTENT. By combining:
|
|
593
|
+
|
|
594
|
+
1. **Structured blocks** for clarity
|
|
595
|
+
2. **Natural language steps** for AI comprehension
|
|
596
|
+
3. **Universal type system** for any domain
|
|
597
|
+
4. **Transform operations** for modifications
|
|
598
|
+
5. **Token-minimal syntax** for efficiency
|
|
599
|
+
|
|
600
|
+
We create a specification language that can handle ANY code type, not just web applications.
|
|
601
|
+
|
|
602
|
+
The key insight is that AI agents don't need a programming language - they need a SEMANTIC INTENT FORMAT that clearly expresses what to build, with enough structure to be unambiguous but enough flexibility to work across all domains.
|
|
603
|
+
|
|
604
|
+
---
|
|
605
|
+
|
|
606
|
+
## Appendix: Formal Grammar (Draft)
|
|
607
|
+
|
|
608
|
+
```
|
|
609
|
+
program = unit* | transform* | compose*
|
|
610
|
+
|
|
611
|
+
unit = "unit" IDENT "{" unit_body "}"
|
|
612
|
+
unit_body = type_decl? purpose? hints* ios* op* constraint*
|
|
613
|
+
|
|
614
|
+
type_decl = "type:" UNIT_TYPE
|
|
615
|
+
purpose = "purpose:" STRING
|
|
616
|
+
hints = ("language_hint:" | "framework_hint:") IDENT
|
|
617
|
+
ios = ("inputs:" | "outputs:") "(" param_list ")"
|
|
618
|
+
param_list = param ("," param)*
|
|
619
|
+
param = IDENT ":" type_expr modifiers?
|
|
620
|
+
type_expr = BASE_TYPE | IDENT | type_expr "[]" | type_expr "?"
|
|
621
|
+
modifiers = (":" MODIFIER)+
|
|
622
|
+
|
|
623
|
+
op = "op" IDENT "{" op_body "}"
|
|
624
|
+
op_body = step* return?
|
|
625
|
+
step = "step:" TEXT
|
|
626
|
+
return = "return:" IDENT ("," IDENT)*
|
|
627
|
+
|
|
628
|
+
constraint = "constraint:" TEXT
|
|
629
|
+
|
|
630
|
+
transform = "transform" "@" IDENT "{" transform_op* "}"
|
|
631
|
+
transform_op = add_op | remove_op | rename_op | modify_op
|
|
632
|
+
|
|
633
|
+
compose = "compose" IDENT "{" compose_body "}"
|
|
634
|
+
compose_body = "units:" "[" IDENT* "]" flow* integration?
|
|
635
|
+
```
|
|
636
|
+
|
|
637
|
+
---
|
|
638
|
+
|
|
639
|
+
*This specification is ready for implementation review. Feedback welcomed.*
|