spec-driven-development 1.43.0 → 1.43.3

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/README.md CHANGED
@@ -1,631 +1,192 @@
1
- # ContractSpec
1
+ # Spec-Driven Development (SDD)
2
2
 
3
- Website: https://contractspec.io/
3
+ **Spec-Driven Development** is a way to build software where the **specification is the source of truth**, not a “documentation artifact we promise to update later”.
4
4
 
5
+ If you’ve ever shipped something that *looked right* in code review and still broke production because the DB, API, client, docs, and policies drifted apart… welcome. SDD is what you do when you’re tired of reality diverging from your repo.
5
6
 
6
- **Stabilize your AI-generated code** Define contracts once, generate consistent code across API, DB, UI, and events. Safe regeneration. No lock-in.
7
+ This package provides a practical SDD toolchain (currently powered by **ContractSpec**) while keeping the README focused on the **method**, not just the tooling.
7
8
 
8
- CLI tool for creating, building, and validating contract specifications.
9
+ ---
9
10
 
10
- ## Installation
11
+ ## What “Spec-Driven” actually means
11
12
 
12
- ```bash
13
- bun add -D contractspec
14
- ```
15
-
16
- ## Quick Start
17
-
18
- ```bash
19
- # Create a new contract spec interactively
20
- contractspec create
21
-
22
- # Create with AI assistance
23
- contractspec create --ai
24
-
25
- # Build implementation from spec
26
- contractspec build src/contracts/mySpec.ts
27
-
28
- # Validate a spec
29
- contractspec validate src/contracts/mySpec.ts
30
- ```
31
-
32
- ## Commands
33
-
34
- ### `contractspec list`
35
-
36
- List all contract specifications in the project with filtering options.
37
-
38
- **Options:**
39
- - `--pattern <pattern>` - File pattern to search (glob)
40
- - `--deep` - Load spec modules to extract richer metadata (executes spec modules)
41
- - `--type <type>` - Filter by spec type (operation, event, presentation, etc.)
42
- - `--owner <owner>` - Filter by owner
43
- - `--tag <tag>` - Filter by tag
44
- - `--stability <level>` - Filter by stability (experimental, beta, stable, deprecated)
45
- - `--json` - Output as JSON for scripting
46
-
47
- **Examples:**
48
-
49
- ```bash
50
- # List all specs
51
- contractspec list
52
-
53
- # Filter by type and stability
54
- contractspec list --type operation --stability stable
55
-
56
- # Find specs by owner
57
- contractspec list --owner @team-platform
58
-
59
- # JSON output for scripting
60
- contractspec list --json
61
- ```
62
-
63
- ### `contractspec watch`
64
-
65
- Watch contract specifications and auto-regenerate on changes.
66
-
67
- **Options:**
68
- - `--pattern <pattern>` - File pattern to watch (default: `**/*.contracts.ts`)
69
- - `--build` - Auto-run build command on changes
70
- - `--validate` - Auto-run validate command on changes
71
- - `--on-start <mode>` - Run action on startup: none|validate|build|both (default: none)
72
- - `--continue-on-error` - Do not exit on build/validate errors
73
- - `--debounce <ms>` - Debounce delay in milliseconds (default: 500)
74
-
75
- **Examples:**
76
-
77
- ```bash
78
- # Watch for changes and auto-build
79
- contractspec watch --build
80
-
81
- # Watch and auto-validate
82
- contractspec watch --validate
83
-
84
- # Custom pattern and debounce
85
- contractspec watch --pattern 'src/**/*.ts' --debounce 1000
86
- ```
87
-
88
- ### `contractspec sync`
89
-
90
- Sync contracts by building all discovered specs.
91
-
92
- **Options:**
93
- - `--pattern <pattern>` - File pattern to search (glob)
94
- - `--buckets <buckets>` - Optional output buckets (comma-separated). Builds repeat into `./generated/<bucket>/`
95
- - `--surfaces <surfaces>` - (deprecated) Alias for `--buckets`
96
- - `--validate` - Validate each spec before building (spec-only)
97
- - `--dry-run` - Show what would be synced without making changes
98
-
99
- **Examples:**
100
-
101
- ```bash
102
- # Sync all surfaces
103
- contractspec sync
104
-
105
- # Sync specific surfaces
106
- contractspec sync --surfaces api,ui
107
-
108
- # Preview changes
109
- contractspec sync --dry-run
110
- ```
111
-
112
- ### `contractspec clean`
113
-
114
- Clean generated files and build artifacts.
115
-
116
- **Options:**
117
- - `--dry-run` - Show what would be deleted without deleting
118
- - `--generated-only` - Only clean generated directories (generated/, dist/, .turbo/, outputDir artifacts)
119
- - `--older-than <days>` - Only clean files older than specified days
120
- - `--force` - Skip confirmation prompts
121
- - `--git-clean` - Use `git clean -fdx` for comprehensive cleanup (requires confirmation or `--force`)
122
-
123
- **Examples:**
124
-
125
- ```bash
126
- # Clean all generated files
127
- contractspec clean
128
-
129
- # Preview cleanup
130
- contractspec clean --dry-run
131
-
132
- # Clean only old files
133
- contractspec clean --older-than 30
134
-
135
- # Use git clean
136
- contractspec clean --git-clean
137
- ```
138
-
139
- ### `contractspec deps`
140
-
141
- Analyze contract dependencies and relationships.
142
-
143
- **Options:**
144
- - `--pattern <pattern>` - File pattern to search (glob)
145
- - `--entry <name>` - Focus on a specific contract name
146
- - `--format <format>` - text|json|dot (default: text)
147
- - `--graph` - (deprecated) Same as `--format dot`
148
- - `--circular` - Find circular dependencies
149
- - `--missing` - Find missing dependencies
150
- - `--json` - (deprecated) Same as `--format json`
151
-
152
- **Examples:**
153
-
154
- ```bash
155
- # Show dependency overview
156
- contractspec deps
157
-
158
- # Analyze specific contract
159
- contractspec deps --entry user.signup
160
-
161
- # Find circular dependencies
162
- contractspec deps --circular
163
-
164
- # Generate graphviz graph
165
- contractspec deps --format dot > deps.dot
166
- ```
167
-
168
- ### `contractspec diff`
169
-
170
- Compare contract specifications and show differences.
171
-
172
- **Arguments:**
173
- - `<spec1> <spec2>` - Two spec files to compare
174
-
175
- **Options:**
176
- - `--breaking` - Only show breaking changes
177
- - `--semantic` - Show semantic differences (not just text)
178
- - `--json` - Output as JSON for scripting
179
- - `--baseline <ref>` - Compare with git reference (branch/commit)
180
-
181
- **Examples:**
182
-
183
- ```bash
184
- # Compare two specs
185
- contractspec diff spec1.ts spec2.ts
186
-
187
- # Compare with git branch
188
- contractspec diff spec.ts spec.ts --baseline main
189
-
190
- # Show only breaking changes
191
- contractspec diff spec1.ts spec2.ts --breaking
192
-
193
- # Semantic comparison
194
- contractspec diff spec1.ts spec2.ts --semantic
195
- ```
196
-
197
- ### `contractspec create`
198
-
199
- Interactive wizard to create contract specifications.
200
-
201
- **Options:**
202
- - `--type <type>` - Spec type: operation, event, presentation, form, feature
203
- - `--ai` - Use AI to generate spec from description
204
- - `--provider <provider>` - AI provider: claude, openai, ollama, custom
205
- - `--model <model>` - AI model to use
206
-
207
- **Examples:**
13
+ SDD is **not** “we wrote an OpenAPI file once”.
14
+ SDD is:
208
15
 
209
- ```bash
210
- # Interactive wizard
211
- contractspec create
16
+ - You express **intent** in a structured, reviewable spec
17
+ - The spec is **executable** (it can generate or validate artifacts)
18
+ - Changes are managed through **contract diffs**, not vibes
19
+ - The spec sits **above** implementations and keeps them coherent over time
212
20
 
213
- # Create operation spec with AI
214
- contractspec create --type operation --ai
21
+ A good spec is:
22
+ - **Typed** (or at least structurally constrained)
23
+ - **Diffable** (PR review works)
24
+ - **Enforceable** (CI can fail you)
25
+ - **Composable** (small specs > giant documents)
215
26
 
216
- # Use local Ollama model
217
- contractspec create --ai --provider ollama --model codellama
218
- ```
27
+ ---
219
28
 
220
- ### `contractspec build`
29
+ ## Why this exists
221
30
 
222
- Generate implementation code from contract specs using AI agents with automatic fallbacks.
31
+ Traditional workflow (a.k.a. “drift by design”):
223
32
 
224
- **Options:**
225
- - `--output-dir <dir>` - Output directory (default: ./generated)
226
- - `--provider <provider>` - AI provider: claude, openai, ollama, custom
227
- - `--model <model>` - AI model to use
228
- - `--agent-mode <mode>` - Agent mode: simple, cursor, claude-code, openai-codex
229
- - `--no-tests` - Skip test generation
230
- - `--no-agent` - Disable AI (use basic templates)
33
+ 1. Implement code
34
+ 2. Update docs “later”
35
+ 3. Ship
36
+ 4. Debug why clients don’t match the backend
37
+ 5. Repeat until burnout
231
38
 
232
- > ℹ️ The build command automatically orchestrates between the selected agent and lightweight templates. If an agent becomes unavailable (missing API key, Cursor not running, etc.) the CLI falls back to deterministic templates so the build never blocks.
39
+ SDD workflow (boring in the best way):
233
40
 
234
- **Examples:**
41
+ 1. Define / update spec
42
+ 2. Review spec changes (diffs + breaking-change flags)
43
+ 3. Generate / update code + SDKs + docs + tests
44
+ 4. Validate implementation against spec in CI
45
+ 5. Ship with fewer surprises
235
46
 
236
- ```bash
237
- # Generate handler from operation spec (default: simple agent)
238
- contractspec build src/contracts/signup.contracts.ts
47
+ This matters more when:
48
+ - You have **multiple surfaces** (DB + API + Web + Mobile + integrations)
49
+ - You use **AI coding** (fast output, high drift risk)
50
+ - You need **governance** (policies, PII rules, permissions, compliance)
239
51
 
240
- # Use Claude Code agent for high-quality production code
241
- contractspec build src/contracts/signup.contracts.ts --agent-mode claude-code
52
+ ---
242
53
 
243
- # Use OpenAI Codex for algorithmic implementations
244
- contractspec build src/contracts/optimizer.contracts.ts --agent-mode openai-codex
54
+ ## What belongs in a spec
245
55
 
246
- # Generate without AI (basic templates only)
247
- contractspec build src/contracts/simple.contracts.ts --no-agent
248
- ```
56
+ A spec can describe *more than endpoints*.
249
57
 
250
- ### `contractspec validate`
58
+ Typical useful layers:
251
59
 
252
- Validate contract specifications and optionally verify implementations against specs using AI.
60
+ - **Domain models**: entities, value objects, enums, invariants
61
+ - **Operations**: commands/queries, inputs/outputs, error shapes
62
+ - **Events**: event names, payloads, versioning rules
63
+ - **Policies**: auth rules, PII classification, access constraints
64
+ - **Examples**: representative requests/responses, edge cases
65
+ - **UI contracts (optional)**: view models, forms, display schemas
253
66
 
254
- **Options:**
255
- - `--check-implementation` - Validate implementation against spec using AI
256
- - `--implementation-path <path>` - Path to implementation (auto-detected if not specified)
257
- - `--agent-mode <mode>` - Agent mode for validation: simple, claude-code, openai-codex
258
- - `--check-handlers` - Verify handler implementations exist
259
- - `--check-tests` - Verify test coverage
260
- - `-i, --interactive` - Interactive mode - prompt for what to validate
67
+ The goal is **coherence**. Your system should have one “truth spine” that everything else attaches to.
261
68
 
262
- > ℹ️ When no validation scope is provided, the CLI prompts you to choose between spec-only validation or full spec + implementation validation. In non-interactive environments it defaults to spec-only. Use `--check-implementation` to skip the prompt.
69
+ ---
263
70
 
264
- **Examples:**
71
+ ## What does *not* belong in a spec
265
72
 
266
- ```bash
267
- # Validate spec structure only
268
- contractspec validate src/contracts/signup.contracts.ts
73
+ Specs should avoid becoming implementation fan-fiction.
269
74
 
270
- # Validate implementation against spec with AI
271
- contractspec validate src/contracts/signup.contracts.ts --check-implementation
75
+ Usually keep out:
76
+ - Framework choices (“use Next.js”, “use NestJS”) unless required
77
+ - Internal function names
78
+ - Micro-optimizations
79
+ - Detailed component trees (unless you’re explicitly generating UI)
272
80
 
273
- # Interactive validation with Claude Code agent
274
- contractspec validate src/contracts/signup.contracts.ts -i --agent-mode claude-code
81
+ Put those in design docs or architecture notes if you want, but don’t let them poison the contract.
275
82
 
276
- # Validate specific implementation file
277
- contractspec validate src/contracts/signup.contracts.ts \
278
- --check-implementation \
279
- --implementation-path src/handlers/signup.handler.ts \
280
- --agent-mode claude-code
281
- ```
83
+ ---
282
84
 
283
- ### `contractspec ci`
85
+ ## The SDD loop (the part people skip)
284
86
 
285
- Run all validation checks for CI/CD pipelines with machine-readable output formats.
87
+ SDD is only real if you do **diffs and gates**.
286
88
 
287
- **Options:**
288
- - `--pattern <glob>` - Glob pattern for spec discovery
289
- - `--format <format>` - Output format: text, json, sarif (default: text)
290
- - `--output <file>` - Write results to file
291
- - `--fail-on-warnings` - Exit with code 2 on warnings
292
- - `--skip <checks>` - Skip specific checks (comma-separated)
293
- - `--checks <checks>` - Only run specific checks (comma-separated)
294
- - `--check-handlers` - Include handler implementation checks
295
- - `--check-tests` - Include test coverage checks
296
- - `--verbose` - Verbose output
89
+ A healthy loop looks like:
297
90
 
298
- **Available Checks:**
299
- - `structure` - Spec structure validation (meta, io, policy)
300
- - `integrity` - Contract integrity (orphaned specs, broken refs)
301
- - `deps` - Dependency analysis (circular deps, missing refs)
302
- - `doctor` - Installation health (skips AI in CI)
303
- - `handlers` - Handler implementation existence
304
- - `tests` - Test file existence
91
+ 1. **Propose change**
92
+ Update the spec as the first PR commit.
305
93
 
306
- **Exit Codes:**
307
- - `0` - All checks passed
308
- - `1` - Errors found
309
- - `2` - Warnings found (with `--fail-on-warnings`)
94
+ 2. **Review contract diff**
95
+ Humans review *impact*, not just code.
96
+ - What breaks?
97
+ - What needs migration?
98
+ - What needs versioning?
310
99
 
311
- **Examples:**
100
+ 3. **Regenerate artifacts**
101
+ Update SDKs, stubs, docs, types, schemas, fixtures.
312
102
 
313
- ```bash
314
- # Run all CI checks
315
- contractspec ci
103
+ 4. **Validate implementation**
104
+ CI checks that implementations match the contract (and policies).
316
105
 
317
- # Output as JSON for parsing
318
- contractspec ci --format json
106
+ 5. **Ship with intent preserved**
107
+ The “why” remains attached to the system, not lost in chat logs.
319
108
 
320
- # Output SARIF for GitHub Code Scanning
321
- contractspec ci --format sarif --output results.sarif
109
+ This is the main reason SDD pairs well with AI:
110
+ the spec is the constraint system that prevents silent drift.
322
111
 
323
- # Skip doctor checks
324
- contractspec ci --skip doctor
112
+ ---
325
113
 
326
- # Run only structure and integrity checks
327
- contractspec ci --checks structure,integrity
114
+ ## “Isn’t this just contract-first?”
328
115
 
329
- # Fail on warnings
330
- contractspec ci --fail-on-warnings
331
- ```
116
+ Adjacent, but broader.
332
117
 
333
- For comprehensive CI/CD integration guides (GitHub Actions, GitLab CI, Jenkins, AWS CodeBuild, etc.), see [docs/ci-cd.md](./docs/ci-cd.md).
334
-
335
- ## Configuration
336
-
337
- Create a `.contractsrc.json` file in your project root:
338
-
339
- ```json
340
- {
341
- "aiProvider": "claude",
342
- "aiModel": "claude-3-7-sonnet-20250219",
343
- "agentMode": "claude-code",
344
- "outputDir": "./src",
345
- "conventions": {
346
- "operations": "interactions/commands|queries",
347
- "events": "events",
348
- "presentations": "presentations",
349
- "forms": "forms"
350
- },
351
- "defaultOwners": ["@team"],
352
- "defaultTags": ["auto-generated"]
353
- }
354
- ```
118
+ - **Contract-first** often means “API schema first”.
119
+ - **Spec-driven** means “system intent first”, across multiple surfaces:
120
+ API, events, models, policies, examples, and sometimes UI boundaries.
355
121
 
356
- ### Agent Modes
122
+ If your “contract” only covers endpoints, you’re still leaving a lot of drift vectors open.
357
123
 
358
- The CLI supports multiple AI agent modes for different use cases:
124
+ ---
359
125
 
360
- - **simple** (default) - Direct LLM API calls, fast and straightforward
361
- - **cursor** - Leverages Windsurf/Cursor agentic capabilities (requires Cursor environment)
362
- - **claude-code** - Uses Claude with extended thinking, best for production code and validation
363
- - **openai-codex** - Uses GPT-4o/o1 models, excellent for algorithms and optimization
126
+ ## What this package provides
364
127
 
365
- See [AGENT_MODES.md](./AGENT_MODES.md) for detailed comparison and usage guide.
128
+ `spec-driven-development` is a **tooling distribution** that helps you practice SDD in real projects, including:
366
129
 
367
- ### AI Providers
130
+ - Keeping specs as **versioned artifacts**
131
+ - Producing **diffs** to detect breaking changes
132
+ - Generating / syncing artifacts to reduce manual duplication
133
+ - Enforcing constraints in **CI** (so reality cannot “quietly” diverge)
368
134
 
369
- #### Claude (Anthropic)
135
+ At the moment, this package is powered by **ContractSpec** (same engine, different framing).
370
136
 
371
- ```bash
372
- export ANTHROPIC_API_KEY=your-key-here
373
- contractspec create --ai --provider claude
374
- ```
137
+ ---
375
138
 
376
- #### OpenAI
139
+ ## Install
377
140
 
378
141
  ```bash
379
- export OPENAI_API_KEY=your-key-here
380
- contractspec create --ai --provider openai --model gpt-4o
381
- ```
142
+ npm install spec-driven-development
143
+ # or
144
+ pnpm add spec-driven-development
145
+ # or
146
+ yarn add spec-driven-development
147
+ # or
148
+ bun add spec-driven-development
149
+ ````
382
150
 
383
- #### Ollama (Local)
151
+ ---
384
152
 
385
- Install Ollama and pull a model:
153
+ ## Usage
386
154
 
387
- ```bash
388
- ollama pull codellama
389
- contractspec create --ai --provider ollama --model codellama
390
- ```
155
+ This package is meant to be used as a CLI/tooling workflow inside your repo.
391
156
 
392
- #### Custom OpenAI-Compatible Endpoint
157
+ Start here:
393
158
 
394
159
  ```bash
395
- contractspec create --ai --provider custom \
396
- --endpoint https://your-llm.com/v1 \
397
- --model your-model-name
160
+ npx spec-driven-development --help
161
+ # or
162
+ bunx spec-driven-development --help
398
163
  ```
399
164
 
400
- Set via environment:
165
+ If your project/team already uses the canonical tool name, you may also want:
401
166
 
402
- ```bash
403
- export CONTRACTSPEC_LLM_ENDPOINT=https://your-llm.com/v1
404
- export CONTRACTSPEC_LLM_API_KEY=your-key
405
- export CONTRACTSPEC_LLM_MODEL=your-model
406
- ```
167
+ * `contractspec` (same underlying engine, more product/tooling oriented docs)
407
168
 
408
- ### Supported Local Models (Ollama)
169
+ ---
409
170
 
410
- - `codellama` - Code generation (recommended)
411
- - `llama3.1` - General purpose
412
- - `mistral` - Fast, good quality
413
- - `deepseek-coder` - Specialized for code
171
+ ## Practical tips (so SDD doesn’t become “SDD theater”)
414
172
 
415
- ## Examples
173
+ * **Make the spec reviewable**: small, composable files beat one mega-spec.
174
+ * **Treat examples as tests**: if examples rot, your spec is lying.
175
+ * **Version events** intentionally**: event drift is the silent killer of systems.
176
+ * **Put PII + auth in the spec**: policies are part of reality, not “later work”.
177
+ * **Gate breaking changes in CI**: humans are fallible, CI is relentless (good).
416
178
 
417
- ### Create a Command Spec
179
+ ---
418
180
 
419
- ```bash
420
- contractspec create --type operation
421
- # Follow prompts:
422
- # - Name: user.signup
423
- # - Kind: command
424
- # - Description: Start user signup flow
425
- # etc.
426
- ```
181
+ ## Who this is for
427
182
 
428
- ### Build Handler from Spec
183
+ * Teams shipping APIs + clients who are tired of drift
184
+ * AI-assisted builders who want **constraints and coherence**
185
+ * Platform/tooling folks who want safer change management
186
+ * Anyone who hears “it’s just a rename” and flinches
429
187
 
430
- Given a spec file `src/contracts/signup.contracts.ts`:
431
-
432
- ```bash
433
- contractspec build src/contracts/signup.contracts.ts
434
- # Generates:
435
- # - src/handlers/signup.handler.ts
436
- # - src/handlers/signup.handler.test.ts
437
- ```
438
-
439
- ### Multi-Provider Workflow
440
-
441
- ```bash
442
- # Draft with free local model
443
- contractspec create --ai --provider ollama
444
-
445
- # Refine with Claude for production
446
- contractspec build src/contracts/draft.ts --provider claude
447
- ```
448
-
449
- ## Advanced Usage
450
-
451
- ### Multi-Provider and Multi-Agent Workflows
452
-
453
- Combine different providers and agents for optimal results:
454
-
455
- ```bash
456
- # Draft specs with free local model
457
- contractspec create --ai --provider ollama --model codellama
458
-
459
- # Generate production code with Claude Code agent
460
- contractspec build src/contracts/user-signup.contracts.ts \
461
- --agent-mode claude-code
462
-
463
- # Validate implementation with AI
464
- contractspec validate src/contracts/user-signup.contracts.ts \
465
- --check-implementation \
466
- --agent-mode claude-code
467
-
468
- # Use OpenAI for algorithmic code
469
- contractspec build src/contracts/search-algorithm.contracts.ts \
470
- --agent-mode openai-codex
471
- ```
472
-
473
- ### Environment Variables
474
-
475
- ```bash
476
- # API Keys
477
- export ANTHROPIC_API_KEY=your-key-here
478
- export OPENAI_API_KEY=your-key-here
479
-
480
- # Agent configuration
481
- export CONTRACTSPEC_AGENT_MODE=claude-code
482
- export CONTRACTSPEC_AI_PROVIDER=claude
483
- export CONTRACTSPEC_AI_MODEL=claude-3-7-sonnet-20250219
484
-
485
- # Custom provider
486
- export CONTRACTSPEC_LLM_ENDPOINT=https://your-llm.com/v1
487
- export CONTRACTSPEC_LLM_API_KEY=your-api-key
488
- ```
489
-
490
- ### CI/CD Integration
491
-
492
- ```yaml
493
- # .github/workflows/contracts.yml
494
- name: Validate Contracts
495
-
496
- on: [push, pull_request]
497
-
498
- jobs:
499
- validate:
500
- runs-on: ubuntu-latest
501
- steps:
502
- - uses: actions/checkout6
503
- - uses: oven-sh/setup-bun@v2
504
- - run: bun install
505
- - run: contractspec validate 'src/contracts/**/*.ts'
506
- ```
507
-
508
- ### Project Structure
509
-
510
- Recommended organization:
511
-
512
- ```
513
- src/
514
- ├── contracts/ # Contract specs
515
- │ ├── events/
516
- │ │ └── user-created.event.ts
517
- │ ├── interactions/
518
- │ │ ├── commands/
519
- │ │ │ └── user-signup.contracts.ts
520
- │ │ └── queries/
521
- │ │ └── user-get-profile.contracts.ts
522
- │ └── presentations/
523
- │ └── user-profile-card.presentation.ts
524
- ├── handlers/ # Generated handlers
525
- ├── components/ # Generated components
526
- └── forms/ # Generated forms
527
- ```
528
-
529
- ## Troubleshooting
530
-
531
- ### "Provider not available" error
532
-
533
- **Claude:**
534
- ```bash
535
- export ANTHROPIC_API_KEY=sk-ant-...
536
- ```
537
-
538
- **OpenAI:**
539
- ```bash
540
- export OPENAI_API_KEY=sk-...
541
- ```
542
-
543
- **Ollama:**
544
- ```bash
545
- # Install Ollama from https://ollama.ai
546
- ollama serve
547
- ollama pull codellama
548
- ```
549
-
550
- ### Slow generation
551
-
552
- For faster local generation, use smaller models:
553
- ```bash
554
- contractspec create --ai --provider ollama --model codellama:7b
555
- ```
556
-
557
- For cloud, use faster models:
558
- ```bash
559
- contractspec build spec.ts --provider openai --model gpt-3.5-turbo
560
- ```
561
-
562
- ### Import errors in generated code
563
-
564
- Make sure `@lssm/lib.contracts` and `@lssm/lib.schema` are installed:
565
- ```bash
566
- pnpm add @lssm/lib.contracts @lssm/lib.schema
567
- ```
568
-
569
- ## Contributing
570
-
571
- Contributions welcome! Please:
572
-
573
- 1. Follow existing code style
574
- 2. Add tests for new features
575
- 3. Update documentation
576
- 4. Ensure all tests pass: `pnpm test`
577
-
578
- ## Agent Modes Deep Dive
579
-
580
- ### When to Use Each Mode
581
-
582
- **Simple Mode** - Default, good for:
583
- - Rapid prototyping
584
- - Basic implementations
585
- - Quick iterations
586
- - CI/CD pipelines (fast)
587
-
588
- **Cursor Mode** - Best for:
589
- - Working in Windsurf/Cursor IDE
590
- - Complex, iterative development
591
- - Context-aware code generation
592
-
593
- **Claude Code Mode** - Best for:
594
- - Production-quality implementations
595
- - Critical business logic
596
- - Comprehensive code validation
597
- - Detailed code reviews
598
-
599
- **OpenAI Codex Mode** - Best for:
600
- - Algorithmic problems
601
- - Performance optimization
602
- - Mathematical computations
603
- - Complex data transformations
604
-
605
- For more details, see [AGENT_MODES.md](./AGENT_MODES.md).
606
-
607
- ## Roadmap
608
-
609
- - [x] AI-powered code generation
610
- - [x] Multiple agent modes (simple, cursor, claude-code, openai-codex)
611
- - [x] AI-powered implementation validation
612
- - [x] Contract listing and discovery (`contractspec list`)
613
- - [x] Watch mode for auto-regeneration (`contractspec watch`)
614
- - [x] Multi-surface synchronization (`contractspec sync`)
615
- - [x] Cleanup utilities (`contractspec clean`)
616
- - [x] Dependency analysis (`contractspec deps`)
617
- - [x] Contract diffing and comparison (`contractspec diff`)
618
- - [x] CI/CD integration (`contractspec ci`) with SARIF/JSON output
619
- - [x] GitHub Action for CI/CD
620
- - [ ] Form spec generation
621
- - [ ] Feature spec bundling
622
- - [ ] Handler signature checking in validation
623
- - [ ] Test coverage validation
624
- - [ ] Interactive spec editing
625
- - [ ] GraphQL schema generation
626
- - [ ] OpenAPI/Swagger export
188
+ ---
627
189
 
628
190
  ## License
629
191
 
630
- MIT
631
-
192
+ MIT (or see repository for details).