mcp server

living-context-driven-development

Documentation dies. Specifications drift. Knowledge changes. Yet AI keeps coding as if nothing happened. LCDD treats context as a living artifact: versioned, governed, enforced, and evolved.

lelianto/living-context-driven-developmentcommunitylistedunreviewed

Use tool

Set up

Runs on your computer. Pick your agent and operating system.

This project does not publish an install method we can turn into a config. Follow the README instead.

README

synced Oct 26, 2026

■ What is Living Context Driven Development?
▶ The Problem
◈ The LCDD Way
◆ The Context — First-Class Governance Artifact
↻ The Context Lifecycle
→ The Discovery Pipeline
◉ Governance by Rate of Change
◈ Context Health
◈ AI Agent Integration
☰ Quick Start — Reading the Specification
⊞ Repository Map
⇔ Comparison with Related Approaches
※ Core Philosophy
☗ Roadmap
✎ Contributing
▤ Learn More
✉ Support
♥ Acknowledgements
⚖ License

■ What is Living Context Driven Development?

The problem is not that AI needs context. The problem is that context decays.

Your README says PostgreSQL 14. You migrated to 16 last year. Your AI agent just generated a migration script for 14. Your architecture decisions are in a Slack thread from March. Your compliance requirements changed in June. Nobody updated anything.

This is Context Debt — the accumulated cost of outdated knowledge. Just as Technical Debt degrades code quality, Context Debt degrades decision quality. Every line of code generated against stale context is a liability.

Context is a first-class artifact. LCDD treats every rule, constraint, policy, and piece of governance knowledge as a living artifact with structure, versioning, lifecycle, enforcement, and observability. Not static documentation. Not tribal knowledge. Not "someone mentioned this once."

Question	LCDD's Answer
What happens when context decays?	Context Debt. Stale rules. Wrong AI output. LCDD measures it with a Context Health Score.
How do you prevent it?	The Context Lifecycle — six stages from Draft to Archived, each with defined enforcement, review cycles, and observability.
Can AI agents bypass it?	Hardened Contexts cannot be auto-modified. Static violations can be blocked today; code-to-Context drift detection is planned for v0.6.0.

▶ The Problem

Context decays. Every README, every architecture decision, every compliance document, every coding standard — all of it becomes outdated the moment it's written. But your AI agents keep operating on it as if nothing changed.

This decay has two consequences:

1. Context Debt

Your codebase has Technical Debt. Your knowledge base has Context Debt. The Postgres version you document is not the one you run. The regulation you cite was amended last month. The architectural pattern you enforce is the one you decided to replace two sprints ago. Nobody measures this debt. Nobody pays it down. Over time, every decision made against stale context becomes a liability.

2. Specification Drift

AI agents optimize for "all tests pass." When context is absent or outdated, they fill the gap — rewriting tests, relaxing schemas, removing validation. The specification silently drifts to match the code, not the other way around.

        Context Debt                    Specification Drift
        ────────────                    ───────────────────
  "We migrated to Postgres 16     "The AI changed the test to match
   last year. Our README still     the broken code because nobody
   says 14. And so does our AI."   told it the constraint exists."

                  └────────┬───────┘
                           │
                  ┌────────▼───────┐
                  │  LCDD treats   │
                  │  context as a  │
                  │  living artifact│
                  └────────────────┘

◈ The LCDD Way

The Four Values

Value	What It Means
Living Evolution over Static Specification	Contexts decay. They must be continuously observed and deliberately evolved. Tested daily, not written once and forgotten.
Explicit Governance over Implicit Trust	Every context answers: who says this is a rule, why, and who can change it?
Context Discovery over Constraint Enforcement	Finding what rules to follow matters more than perfectly enforcing rules you already know.
Machine-Readable Context over Human-Only Documentation	If an AI agent cannot consume it, it will be ignored at scale.

The Twelve Principles

Context is a first-class artifact — versioned, structured, machine-readable.
Contexts are discovered, not assumed — continuous discovery from any source.
Every context has provenance — who says this is a rule, and why trust them?
Contexts have a lifecycle — Draft → Candidate → Approved → Active → Deprecated → Archived.
Governance matches rate of change — Hardened for regulations, Local for preferences.
Sources are heterogeneous — the model is unified — one schema for all constraint origins.
AI agents consume and respect contexts — injected as structured constraints, not vague prompts.
Enforcement is pluggable — CI, IDE, API gateway, pre-commit; the what is LCDD, the where is plugins.
Observability closes the feedback loop — violations tracked, trends analyzed, contexts improved.
Conflicting contexts must be resolved, not hidden — surfaced explicitly for human judgment.
Contexts are composable — Context Packs enable sharing across teams and community.
The methodology applies to itself — LCDD is governed using LCDD principles.

Read the full Manifesto and First Principles.

◆ The Context — First-Class Governance Artifact

The Context is the atomic unit of governance in LCDD. It is not a comment, not a ticket, not a Slack message. It is a structured, versioned, machine-readable artifact with:

id: "ctx-api-input-validation"
version: 1
title: "All API endpoints MUST validate input against an OpenAPI schema"
description: >
  Every API endpoint must have a corresponding OpenAPI 3.x schema.
  Request validation MUST be performed at the API gateway layer.

source:                           # Where did this come from?
  type: "organization"
  uri: "https://wiki.example.com/security/api-standards"

authority:                        # Who says this is a rule, and why trust them?
  source: { type: "organization", id: "ciso-office", name: "CISO Office" }
  level: 3                        # 0=Suggestion … 4=Mandate

lifecycle: "active"               # Draft → Candidate → Approved → Active → Deprecated → Archived

governance:                       # How hard is it to change this?
  classification: "hardened-standard"   # AI agents CANNOT modify hardened contexts
  approval_required: true

enforcement:                      # How is this enforced?
  mode: "block"                   # Block merge, warn, comment, or silent
  specification:
    type: "openapi-validation"    # Pluggable enforcement mechanism

evidence:                         # Why does this rule exist?
  - type: "security-incident"
    uri: "https://incidents.example.com/INC-2025-087"
    description: "SQL injection via unvalidated API input"

Each Context is a self-contained governance unit — it knows its source, its authority, its lifecycle stage, and how it should be enforced. See the full Context Schema.

↻ The Context Lifecycle

Constraints don't jump from "someone mentioned this" to "this blocks production." They move through six explicit stages:

Draft ──→ Candidate ──→ Approved ──→ Active ──→ Deprecated ──→ Archived
  │           │             │            │            │              │
  │  "Someone │  "Under     │  "Approved │  "This     │  "No longer │  "Retained
  │   mention-│   review"   │   but not  │   blocks   │   applies"  │   for audit"
  │   ed this"│             │   yet      │   merges"  │             │
  │           │             │   active"  │            │             │
  │  No       │  Comment    │  Warn      │  Block /   │  Warn with  │  No
  │  enforce- │  only       │  mode      │  Warn      │  deprecation│  enforcement
  │  ment     │             │            │            │  notice     │

Each transition is an auditable event. Contexts can be reactivated if conditions change. Emergency shortcuts exist but require post-hoc review. See the full Context Lifecycle.

→ The Discovery Pipeline

The LCDD Context Engineering Pipeline is what makes LCDD different from every other approach — it starts from unknown constraints, not known ones:

           01 ✅ Done      02 🟡 Phase A    03 🟡 Phase A    04 ✅ Done       05 ✅ Done       06 ✅ Done       07 ✅ Done       08 ✅ Done       09 ✅ Done
           ──────────     ──────────     ──────────     ──────────     ──────────     ──────────     ──────────     ──────────     ──────────
           Observe  ──→  Understand ──→  Govern   ──→  Distribute──→  Enforce  ──→  Verify   ──→  Learn    ──→  Improve
              │               │               │              │              │              │              │              │
              │ Source        │ Extract       │ Normalize    │ Review +     │ Validate     │ Metrics,     │ Trigger
              │ watch +       │ (Ollama free, │ schema map,  │ Classify     │ artifacts    │ dashboard,   │ evaluator
              │ schedule      │ OpenAI/Anthro)│ dedup        │              │              │ web, events  │ + doctor

Implementation status: Stages 01, 04–09 are fully implemented. Stages 02–03 have Phase A — lcd extract (Ollama free by default) and lcd normalize (deterministic dedup). Only Stage 02 LLM refinement and Stage 03 embedding dedup remain for v1.0+. No API key required for any stage except OpenAI/Anthropic optional backends.

Example: A new regulation is published (ex. GDPR update, PCI-DSS revision) → Discover detects it → Extract parses it with an LLM → Normalize maps it to the Context Schema → Classify assigns it level 4 (Mandate) → Review routes it to the compliance team → Version commits it as Draft → Approve → Active → Block enforcement in CI. See the full Context Builder.

◉ Governance by Rate of Change

Directly inspired by AI Harness (Bunardzic, 2025), LCDD classifies every Context by how fast it should change:

Classification	Authority	Change Speed	AI Can Modify?	Default Enforcement	Example
Hardened-Mandate	4 (Mandate)	Very slow	❌ Never	Block	Regulatory requirement (ex. GDPR, PCI-DSS, HIPAA)
Hardened-Standard	3 (Standard)	Slow	❌ Never	Block	CISO security policy
Hardened-Local	2 (Guideline)	Moderate	❌ (can suggest)	Warn	Team architecture decision
Local-Standard	2 (Guideline)	Moderate	✅ With review	Warn	Recommended libraries
Local-Guideline	1 (Preference)	Fast	✅ Auto-merge	Comment	Code style conventions
Local-Experimental	0 (Suggestion)	Very fast	✅ Primary source	Silent	AI-generated suggestions

Hardened contexts require formal RFC + explicit human approval. Local contexts can evolve through AI suggestion and fitness-based optimization. See the full Governance Model.

◈ Context Health

Context Debt should be as visible as Technical Debt. lcd doctor gives you a health check:

$ lcd doctor

LCDD Context Health Report
Timestamp: 2026-08-06T22:57:29.547Z
Contexts: 3

  Overall Score: ████████████████░░░░ 78% (78/100)  Grade: B

Health Metrics
────────────────────────────────────────────────────────────
  ✓ Stale Contexts
    ████████████████████ 100% (15/15)

  ⚠ Missing Owners
    █████████████░░░░░░░ 67% (10/15)
  └─ 1 context(s) without owner: ctx-d71b89ca

  ✗ Deprecation Backlog
    ░░░░░░░░░░░░░░░░░░░░ 0% (0/10)
  └─ 1 deprecated context(s), 1 stale >180 days: ctx-7cef85e2

  ⚠ Tag Hygiene
    ████████████░░░░░░░░ 60% (6/10)
  └─ 2 context(s) without tags: ctx-7cef85e2, ctx-d71b89ca

Recommendations
────────────────────────────────────────────────────────────
  1. 1 context(s) without owner: ctx-d71b89ca
  2. 1 deprecated context(s), 1 stale >180 days: ctx-7cef85e2
  3. 2 context(s) without tags: ctx-7cef85e2, ctx-d71b89ca

  Run lcd doctor --triggers for detailed trigger analysis.

Add --triggers for six deterministic triggers (stale contexts, high violation rate, high false positives, increasing violations, AI drift, and new source detection) with specific remediation commands.

Metric	What It Measures
Stale Contexts	Active contexts with no events in 90+ days
Missing Owners	Non-archived contexts without an assigned owner
Enforcement Conflicts	Overlapping enforcement patterns with conflicting block modes
Deprecation Backlog	Deprecated contexts not yet archived (especially >180 days)
Draft Stagnation	Drafts stuck for >30 days
Authority Gaps	Active contexts with weak authority levels (0–1)
Tag Hygiene	Contexts missing tags for discoverability
Review Backlog	Contexts awaiting review (pending, in-review, needs-revision)

Context Health is available via lcd doctor, and v0.5.0 adds executable, guardrail-gated recommendations through lcd improve. No API key is required.

◈ AI Agent Integration

LCDD contexts are natively available to AI coding agents through MCP (Model Context Protocol). Any MCP-compatible agent (Claude Desktop, Cursor, Cline, etc.) can query, validate, and enforce LCDD governance:

npm install -g @lcdd/mcp

Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "lcdd": {
      "command": "npx",
      "args": ["@lcdd/mcp"],
      "env": {
        "LCDD_PROJECT_ROOT": "/path/to/your/project"
      }
    }
  }
}

What AI agents can do via MCP:

Agent asks	Tool called	What happens
"Are there security rules I should know?"	`lcdd_query_contexts`	Returns all active security contexts via CQL
"Check this file for violations"	`lcdd_validate_artifact`	Validates code against all active enforcement rules
"What's the governance health?"	`lcdd_get_health`	Context Health Score + recommendations
"Show me violation trends"	`lcdd_get_dashboard`	Enforcement metrics: trends, actor breakdown
"What needs review?"	`lcdd_list_reviews`	Pending reviews with auto-approval status
"What should governance improve?"	`lcdd_get_recommendations`	Read-only, guardrail-gated recommendations

Zero configuration beyond pointing to your project. No API key, no LLM, no cloud dependency. The MCP reads .lcdd/ directly from your filesystem.

☰ Quick Start

LCDD is in Implementation Phase (v0.7.0-alpha.1) with working Core, CLI, and MCP reference packages. This is an npm prerelease under the next tag; the methodology remains a proposal and is not yet a stable v1.0 standard.

Install the CLI (30 seconds)

npm install -g @lcdd/cli
lcd init
lcd context add
lcd validate
lcd doctor
lcd setup ci --provider github --yes

The last command creates an idempotent, least-privilege GitHub Actions workflow. Commit and push .github/workflows/lcdd.yml; after its first successful run, require the LCDD / validate check in the default-branch ruleset. Other Git hosts can already use LCDD through generic Git and CI commands, but provider-specific workflow generators are not implemented yet.

Pipeline Commands

# Source monitoring
lcd source add https://docs.example.com/standard --type website
lcd source watch --interval 60
lcd source schedule --github

# Extract constraints (Ollama default — free, no API key)
ollama pull llama3.2
lcd extract src-abc123 --auto

# Or with OpenAI/Anthropic
export OPENAI_API_KEY=sk-...
lcd extract src-abc123 --backend openai --auto

Add AI Agent Support (1 minute)

npm install -g @lcdd/mcp
# Add to claude_desktop_config.json (see section above)

Read the Specification (30 minutes)

Manifesto — the four values and twelve principles.
Problem Statement — the seven sub-problems LCDD solves.
Core Principles — ten normative principles.
Glossary — canonical vocabulary.
Introduction — gentle conceptual overview.

For Implementers (2–3 hours)

For Teams Adopting LCDD

Adoption Guide — six-level adoption path, from awareness to full platform.
Comparison — how LCDD relates to TDD, DDD, SDD, CDD tools, and more.
FAQ — common questions with concrete answers.
Examples — five domain Context Packs (Startup, Fintech/OJK, Healthcare/HIPAA, E-commerce, Hackathon).

⊞ Repository Map

living-context-driven-development/
│
├── 📜 README.md                         # You are here
├── 📜 LICENSE                           # Apache 2.0
├── 📜 GOVERNANCE.md                     # How this project is governed
├── 📜 ROADMAP.md                        # Six-milestone roadmap
├── 📜 CHANGELOG.md                      # Version history
├── 📜 CONTRIBUTING.md                   # How to contribute
├── 📜 CODE_OF_CONDUCT.md                # Contributor Covenant
├── 📜 SECURITY.md                       # Security policy
├── 📜 SUPPORT.md                        # Support guidelines
├── 📜 AGENTS.md                         # Instructions for AI agents
├── 📜 lcdd-methodology.md               # Comprehensive methodology guide
│
├── 📂 manifesto/                        # The LCDD Manifesto
│   ├── manifesto.md                     # Four Values + Twelve Principles
│   ├── first-principles.md              # Five Axioms of LCDD
│   └── vision.md                        # Long-term vision (5 phases)
│
├── 📂 specification/                    # Core Specification (RFC-style)
│   ├── 0000-problem.md                  # Problem Statement
│   ├── 0001-core-principles.md          # Core Principles
│   ├── 0002-context-lifecycle.md        # Context Lifecycle
│   ├── 0003-authority-model.md          # Authority Model
│   ├── 0004-governance.md               # Governance Model
│   ├── 0005-context-registry.md         # Context Registry
│   ├── 0006-context-builder.md          # Context Engineering Pipeline
│   ├── 0007-context-engineering.md      # Context Engineering Patterns
│   ├── 0008-verification.md             # Verification
│   ├── 0009-observability.md            # Observability
│   ├── 0010-ai-agents.md                # AI Agent Governance
│   ├── 0011-context-query-language.md   # CQL Specification
│   ├── 0012-context-schema.md           # Context Schema
│   ├── 0013-context-protocol.md         # Context Protocol
│   ├── 0014-security.md                 # Security Model
│   ├── 0015-reference-architecture.md   # Reference Architecture
│   ├── 0016-roadmap.md                  # Detailed Roadmap
│   ├── 0017-pipeline-automation-plan.md # Pipeline Automation Plan
│   └── 0018-identity-ownership-and-change-governance.md # Identity and ownership governance
│
├── 📂 docs/                             # Companion Documentation
│   ├── research.md                      # Literature Review (v0.2.0)
│   ├── glossary.md                      # Canonical Vocabulary
│   ├── introduction.md                  # Gentle Introduction
│   ├── philosophy.md                    # Philosophical Foundations
│   ├── comparison.md                    # Comparison with Other Approaches
│   ├── adoption.md                      # Adoption Guide (6 levels)
│   ├── faq.md                           # Frequently Asked Questions
│   ├── adoption-bootstrap-enhancement.md # Adoption bootstrap proposal
│   ├── lcdd-developer-workflow-implementation-plan.md # Primary developer workflow plan
│   └── lcdd-workflow-contracts.md       # Implementation contracts
│
├── 📂 reference/                        # Reference Artifacts
│   ├── schema/context-schema.json       # JSON Schema for Context
│   ├── schema/project-config-schema.json # JSON Schema for project configuration
│   ├── schema/trust-schema.json         # JSON Schema for trust and identity
│   ├── schema/ownership-schema.json     # JSON Schema for ownership boundaries
│   ├── yaml/example-context.yaml        # Example Context (YAML)
│   ├── yaml/project-config.yaml         # Example project configuration
│   ├── yaml/trust.yaml                  # Example trust and identity registry
│   ├── yaml/ownership.yaml              # Example ownership boundaries
│   ├── json/example-context.json        # Example Context (JSON)
│   └── architecture/diagrams.md         # Architecture Diagrams
│
├── 📂 examples/                         # Example Context Packs
│   ├── startup/                         # Startup Best Practices
│   ├── fintech/                         # OJK Fintech Compliance
│   ├── healthcare/                      # HIPAA Compliance
│   ├── ecommerce/                       # E-commerce Best Practices
│   └── education/                       # Hackathon Competition Rubric
│
├── 📂 .lcdd/                            # Tracked self-governance Registry and Context Pack
│   ├── contexts/hardened/               # Human-controlled development invariants
│   ├── contexts/local/                  # Automatable repository constraints
│   └── pack.yaml                        # lcdd-development pack manifest
│
├── 📂 media/                            # Visual Identity
│   └── logo.png                         # LCDD Logo
│
└── 📂 implementation/                   # Reference Implementation (v0.7.0-alpha.1)
    ├── packages/core/                   # @lcdd/core — TypeScript SDK
    ├── packages/cli/                    # @lcdd/cli — Command-line tool
    ├── packages/mcp/                    # @lcdd/mcp — MCP Server for AI agents
    └── .github/workflows/               # CI/CD enforcement

⇔ Comparison with Related Approaches

Feature	TDD	DDD	AGENTS.md	CDD Tools	AI Harness	LCDD
Governs	Code behavior	Domain model	Agent prompts	AI workflow	Arch. integrity	All sources
Context as artifact	❌	❌	❌ unstructured	❌ informal	❌	✅ Structured schema
Lifecycle	❌	❌	❌	❌	Binary	✅ Full (6-stage)
Context Debt	❌	❌	❌	❌	❌	✅ Measurable
AI-Aware	❌	❌	✅ one-way	✅ workflow	✅	✅ Built-in + enforced
Observability	Test results	❌	❌	❌	❌	✅ Full
Spec Drift Prevention	❌	❌	❌	❌	✅	🟡 Partial; code drift planned
Community Sharing	Test suites	❌	❌	❌	❌	✅ Context Packs
MCP / Agent Protocol	❌	❌	❌	❌	❌	✅ 8 native tools

AGENTS.md vs LCDD: AGENTS.md files give AI agents instructions — but they're unstructured, unversioned, ungoverned, and unenforced. Nothing prevents the agent from ignoring them. Nothing measures whether they're being followed. LCDD takes the same idea and makes it structured, versioned, governed, and enforced. Context is a first-class artifact, not a text file.

CDD Tools (Conductor, PAW): Manage AI agent workflow (Spec → Plan → Implement). LCDD manages AI agent governance (what rules must be obeyed). Complementary — use both.

See the full Comparison and Literature Review.

※ Core Philosophy

Living Context Driven Development is built on five axioms:

All software is governed by constraints, whether acknowledged or not. Making them visible is always better than leaving them implicit.
In the age of AI-assisted development, constraint governance is the bottleneck, not code production.
Constraints exist on a spectrum of authority, from individual preference to legal mandate. A unified methodology must accommodate the full spectrum.
The sources of constraints are heterogeneous and evolving. A methodology that cannot ingest from arbitrary sources is incomplete.
Observability without enforcement is documentation; enforcement without observability is dogma. The feedback loop makes a constraint living.

Read the full First Principles and Philosophy.

☗ Roadmap

Milestone	Version	Status	Focus
Foundation	v0.1.0	✅ Complete	Specification foundation, manifesto, examples, reference schema
Reference Implementation	v0.2.1	✅ Complete	`@lcdd/core` SDK + `@lcdd/cli` CLI — published to npm
Pipeline Automation	v0.4.0	✅ Complete	Deterministic pipeline: `lcd doctor`, rule engine, `lcd review`, source connector, trigger evaluator, `lcd extract` + `lcd normalize`
MCP Server	v0.3.0+	✅ Complete	AI agent integration — 8 tools via Model Context Protocol
Self-Healing Phase A	v0.5.0	✅ Complete	Executable recommendations, snapshots, health verification, rollback, and guardrails
Drift & Retrieval	v0.6.0	🟡 In Progress	Self-governance baseline complete; change-scoped validation, Context Bundles, local discovery, and drift remain
Stabilization	v1.0.0	🔴 Planned	Stable contracts, migration policy, conformance, evidence, and external adoption

Pipeline Stage Status

Stage	Status	Available In
01 Observe	✅ Done	v0.4.0 — Deterministic source monitoring: `lcd source watch`, `lcd source schedule` (cron + GitHub Actions)
02 Extract	🟡 Phase A	v0.4.0 — `lcd extract <id>`: Ollama (default, free), OpenAI, Anthropic. No API key needed for Ollama.
03 Normalize	🟡 Phase A	v0.4.0 — `lcd normalize`: schema mapping, Jaccard dedup, validation, draft context creation
04 Classify	✅ Done	v0.3.0 — Deterministic rule engine: source type → authority, keyword → severity, domain → tags
05 Review	✅ Done	v0.3.0 — `lcd review list/show/approve/reject/revision`, auto-approval for Local contexts
06 Enforce	✅ Done	v0.2.1 — `lcd validate`, `ContextVerifier`, CI integration
07 Verify	✅ Done	v0.2.1 — Schema validation, semantic rules, lifecycle checks
08 Learn	✅ Done	v0.3.0 — `lcd dashboard` (terminal + web), enforcement metrics, violation trends
09 Improve	✅ Done	v0.5.0 — `lcd doctor`, six-trigger evaluator, `lcd improve check/apply/rollback`, snapshots and guardrails

Install

npm install -g @lcdd/cli
lcd init
lcd context add
lcd validate
lcd setup ci --provider github --yes

See the full Roadmap and Vision.

✎ Contributing

LCDD is an open specification. Contributions of all kinds are welcome:

Critique — open an issue challenging a principle or specification.
RFC — propose a significant change following the RFC process.
Context Packs — contribute domain-specific packs for your industry.
Documentation — improve clarity, fix typos, add examples.

See CONTRIBUTING.md for the full process.

✉ Support

For questions, bug reports, or feature requests, please open a GitHub issue. See SUPPORT.md for support guidelines.

♥ Acknowledgements

LCDD builds on the foundational work of:

GrayBeam Technology — Constraint-Driven Development
Alex Bunardzic — AI Harness: Governing Change by Rate of Evolution
Google / Gemini CLI Extensions — Conductor
Rob Emanuele — Phased Agent Workflow (PAW)
Microsoft — Agentic SDLC Starter
Eric Evans — Domain-Driven Design
Kent Beck — Test-Driven Development
Cyrille Martraire — Living Documentation
Open Policy Agent — Policy-as-Code

LCDD does not replace these works; it stands on their shoulders and addresses gaps they were not designed to fill.

⚖ License

Living Context Driven Development Specification is licensed under the Apache License 2.0. See LICENSE.