spec-driven-development 3.7.6 → 3.7.10

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # spec-driven-development
 
+## 3.7.10
+
+### Patch Changes
+
+- 1a44cb6: feat: improve examples to increase coverage of Contracts type
+- Updated dependencies [1a44cb6]
+  - @contractspec/app.cli-contractspec@4.1.2
+
+## 3.7.9
+
+### Patch Changes
+
+- fix: release
+- Updated dependencies
+  - @contractspec/app.cli-contractspec@4.1.1
+
 ## 3.7.6
 
 ### Patch Changes
@@ -642,14 +658,17 @@
   feat: Contract layers support (features, examples, app-configs)
 
   ### New CLI Commands
+
   - `contractspec list layers` - List all contract layers with filtering
 
   ### Enhanced Commands
+
   - `contractspec ci` - New `layers` check category validates features/examples/config
   - `contractspec doctor` - New `layers` health checks
   - `contractspec integrity` - Now shows layer statistics
 
   ### New APIs
+
   - `discoverLayers()` - Scan workspace for all layer files
   - `scanExampleSource()` - Parse ExampleSpec from source code
   - `isExampleFile()` - Check if file is an example spec

package/README.md

@@ -1,192 +1,47 @@
-# Spec-Driven Development (SDD)
+# spec-driven-development
 
-**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”.
+Website: https://contractspec.io
 
-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.
+**npm-published CLI alias for ContractSpec under the `sdd` / `spec-driven-development` binary names. Thin wrapper that delegates to `@contractspec/app.cli-contractspec`.**
 
-This package provides a practical SDD toolchain (currently powered by **ContractSpec**) while keeping the README focused on the **method**, not just the tooling.
+## What It Does
 
----
+- **Layer**: apps-registry
+- **Consumers**: end-users installing `npx sdd` or `npx spec-driven-development`
 
-## What “Spec-Driven” actually means
+## Installation
 
-SDD is **not** “we wrote an OpenAPI file once”.
-SDD is:
+`npm install spec-driven-development`
 
-- You express **intent** in a structured, reviewable spec
-- The spec is **executable** (it can generate or validate artifacts)
-- Changes are managed through **contract diffs**, not vibes
-- The spec sits **above** implementations and keeps them coherent over time
+or
 
-A good spec is:
-- **Typed** (or at least structurally constrained)
-- **Diffable** (PR review works)
-- **Enforceable** (CI can fail you)
-- **Composable** (small specs > giant documents)
-
----
-
-## Why this exists
-
-Traditional workflow (a.k.a. “drift by design”):
-
-1. Implement code
-2. Update docs “later”
-3. Ship
-4. Debug why clients don’t match the backend
-5. Repeat until burnout
-
-SDD workflow (boring in the best way):
-
-1. Define / update spec
-2. Review spec changes (diffs + breaking-change flags)
-3. Generate / update code + SDKs + docs + tests
-4. Validate implementation against spec in CI
-5. Ship with fewer surprises
-
-This matters more when:
-- You have **multiple surfaces** (DB + API + Web + Mobile + integrations)
-- You use **AI coding** (fast output, high drift risk)
-- You need **governance** (policies, PII rules, permissions, compliance)
-
----
-
-## What belongs in a spec
-
-A spec can describe *more than endpoints*.
-
-Typical useful layers:
-
-- **Domain models**: entities, value objects, enums, invariants  
-- **Operations**: commands/queries, inputs/outputs, error shapes  
-- **Events**: event names, payloads, versioning rules  
-- **Policies**: auth rules, PII classification, access constraints  
-- **Examples**: representative requests/responses, edge cases  
-- **UI contracts (optional)**: view models, forms, display schemas
-
-The goal is **coherence**. Your system should have one “truth spine” that everything else attaches to.
-
----
-
-## What does *not* belong in a spec
-
-Specs should avoid becoming implementation fan-fiction.
-
-Usually keep out:
-- Framework choices (“use Next.js”, “use NestJS”) unless required
-- Internal function names
-- Micro-optimizations
-- Detailed component trees (unless you’re explicitly generating UI)
-
-Put those in design docs or architecture notes if you want, but don’t let them poison the contract.
-
----
-
-## The SDD loop (the part people skip)
-
-SDD is only real if you do **diffs and gates**.
-
-A healthy loop looks like:
-
-1. **Propose change**  
-   Update the spec as the first PR commit.
-
-2. **Review contract diff**  
-   Humans review *impact*, not just code.  
-   - What breaks?
-   - What needs migration?
-   - What needs versioning?
-
-3. **Regenerate artifacts**  
-   Update SDKs, stubs, docs, types, schemas, fixtures.
-
-4. **Validate implementation**  
-   CI checks that implementations match the contract (and policies).
-
-5. **Ship with intent preserved**  
-   The “why” remains attached to the system, not lost in chat logs.
-
-This is the main reason SDD pairs well with AI:
-the spec is the constraint system that prevents silent drift.
-
----
-
-## “Isn’t this just contract-first?”
-
-Adjacent, but broader.
-
-- **Contract-first** often means “API schema first”.
-- **Spec-driven** means “system intent first”, across multiple surfaces:
-  API, events, models, policies, examples, and sometimes UI boundaries.
-
-If your “contract” only covers endpoints, you’re still leaving a lot of drift vectors open.
-
----
-
-## What this package provides
-
-`spec-driven-development` is a **tooling distribution** that helps you practice SDD in real projects, including:
-
-- Keeping specs as **versioned artifacts**
-- Producing **diffs** to detect breaking changes
-- Generating / syncing artifacts to reduce manual duplication
-- Enforcing constraints in **CI** (so reality cannot “quietly” diverge)
-
-At the moment, this package is powered by **ContractSpec** (same engine, different framing).
-
----
-
-## Install
-
-```bash
-npm install spec-driven-development
-# or
-pnpm add spec-driven-development
-# or
-yarn add spec-driven-development
-# or
-bun add spec-driven-development
-````
-
----
+`bun add spec-driven-development`
 
 ## Usage
 
-This package is meant to be used as a CLI/tooling workflow inside your repo.
-
-Start here:
-
 ```bash
-npx spec-driven-development --help
+npx sdd --help
 # or
-bunx spec-driven-development --help
+bunx sdd --help
 ```
 
-If your project/team already uses the canonical tool name, you may also want:
-
-* `contractspec` (same underlying engine, more product/tooling oriented docs)
-
----
-
-## Practical tips (so SDD doesn’t become “SDD theater”)
+## Public Entry Points
 
-* **Make the spec reviewable**: small, composable files beat one mega-spec.
-* **Treat examples as tests**: if examples rot, your spec is lying.
-* **Version events** intentionally**: event drift is the silent killer of systems.
-* **Put PII + auth in the spec**: policies are part of reality, not “later work”.
-* **Gate breaking changes in CI**: humans are fallible, CI is relentless (good).
+- `sdd` -> `./bin/contractspec.mjs`
+- `spec-driven-development` -> `./bin/contractspec.mjs`
 
----
+## Local Commands
 
-## Who this is for
+- `bun run publish:pkg` — bun publish --tolerate-republish --ignore-scripts --verbose
+- `bun run publish:pkg:canary` — bun publish:pkg --tag canary
 
-* Teams shipping APIs + clients who are tired of drift
-* AI-assisted builders who want **constraints and coherence**
-* Platform/tooling folks who want safer change management
-* Anyone who hears “it’s just a rename” and flinches
+## Recent Updates
 
----
+- Replace eslint+prettier by biomejs to optimize speed
+- PublishConfig not supported by bun
 
-## License
+## Notes
 
-MIT (or see repository for details).
+- This package is a shim; all logic lives in `@contractspec/app.cli-contractspec`
+- Do not add dependencies beyond the CLI app workspace reference
+- Changes to `bin/contractspec.mjs` affect every user -- test locally before publishing

package/bin/contractspec.mjs

@@ -1,3 +1,3 @@
 #!/usr/bin/env node
 // One bin, picks the right runtime via conditional exports.
-import "@contractspec/app.cli-contractspec/run";
+import '@contractspec/app.cli-contractspec/run';

package/package.json

@@ -1,35 +1,35 @@
 {
-  "name": "spec-driven-development",
-  "version": "3.7.6",
-  "description": "CLI tool for creating, building, and validating contract specifications",
-  "bin": {
-    "sdd": "./bin/contractspec.mjs",
-    "spec-driven-development": "./bin/contractspec.mjs"
-  },
-  "dependencies": {
-    "@contractspec/app.cli-contractspec": "3.7.6"
-  },
-  "scripts": {
-    "publish:pkg": "bun publish --tolerate-republish --ignore-scripts --verbose",
-    "publish:pkg:canary": "bun publish:pkg --tag canary"
-  },
-  "keywords": [
-    "cli",
-    "contracts",
-    "code-generation",
-    "ai",
-    "typescript"
-  ],
-  "publishConfig": {
-    "name": "spec-driven-development",
-    "access": "public",
-    "registry": "https://registry.npmjs.org/"
-  },
-  "license": "MIT",
-  "repository": {
-    "type": "git",
-    "url": "https://github.com/lssm-tech/contractspec.git",
-    "directory": "packages/apps-registry/spec-driven-development"
-  },
-  "homepage": "https://contractspec.io"
+	"name": "spec-driven-development",
+	"version": "3.7.10",
+	"description": "CLI tool for creating, building, and validating contract specifications",
+	"bin": {
+		"sdd": "./bin/contractspec.mjs",
+		"spec-driven-development": "./bin/contractspec.mjs"
+	},
+	"dependencies": {
+		"@contractspec/app.cli-contractspec": "4.1.2"
+	},
+	"scripts": {
+		"publish:pkg": "bun publish --tolerate-republish --ignore-scripts --verbose",
+		"publish:pkg:canary": "bun publish:pkg --tag canary"
+	},
+	"keywords": [
+		"cli",
+		"contracts",
+		"code-generation",
+		"ai",
+		"typescript"
+	],
+	"publishConfig": {
+		"name": "spec-driven-development",
+		"access": "public",
+		"registry": "https://registry.npmjs.org/"
+	},
+	"license": "MIT",
+	"repository": {
+		"type": "git",
+		"url": "https://github.com/lssm-tech/contractspec.git",
+		"directory": "packages/apps-registry/spec-driven-development"
+	},
+	"homepage": "https://contractspec.io"
 }