dflow-sdd-ddd 0.1.0 → 0.2.0

package/docs/release-versioning-policy.md

@@ -0,0 +1,99 @@
+# Release and Versioning Policy
+
+This document defines the lightweight release policy for Dflow while the project
+is in the `0.x` series. It is maintainer-facing; contributors can use it to
+describe expected version impact in a PR, but only maintainers publish releases.
+
+## Versioning During 0.x
+
+Dflow uses SemVer-style version numbers, with extra care in `0.x` because the
+workflow contract is still evolving.
+
+Use a patch release for:
+
+- Bug fixes.
+- Documentation corrections or clarifications.
+- Non-breaking template wording changes.
+- Release metadata fixes.
+- Internal cleanup that does not change generated output or workflow contracts.
+
+Use a minor release for:
+
+- A new CLI command.
+- A new generated file.
+- A materially changed generated file shape.
+- A new or expanded `/dflow:*` workflow contract.
+- A change that affects how Greenfield or Brownfield projects are initialized.
+- A migration-relevant template, scaffolding, or skill behavior change.
+
+Major versions are reserved for `1.0` and later. Before `1.0`, breaking changes
+may still appear in minor releases, but release notes must call them out clearly
+and describe the expected user action.
+
+## What Counts as Breaking
+
+A change is breaking when an existing Dflow user may need to adjust project
+files, scripts, AI-agent instructions, or workflow habits after upgrading.
+
+Examples:
+
+- Renaming generated paths.
+- Removing a generated file.
+- Changing required init prompts.
+- Changing the meaning of a template section.
+- Changing command behavior in a way that invalidates existing docs.
+- Replacing a workflow contract that AI agents rely on.
+
+## Release Ownership
+
+Dflow currently has four release surfaces:
+
+- Development repo: source of truth for design work, implementation, planning,
+  and release preparation.
+- Dist repo: clean public projection of selected source files.
+- npm package: executable CLI and packaged templates selected by
+  `package.json#files`.
+- GitHub Release: public release note and tag record.
+
+For now, npm publishing may remain a manual maintainer action. Release
+automation should be introduced only after the manual dist shape and release
+checklist remain stable across multiple releases.
+
+## Tags
+
+Use `v<version>` tags, for example `v0.1.1`.
+
+When both development and dist repos are maintained, tag both repos for the same
+published version after verification. The tags may point to different commits
+because the dist repo is a selected projection of the development repo.
+
+## Changelog and Release Notes
+
+Update `CHANGELOG.md` before publishing. Each release entry should state:
+
+- The version and date.
+- User-facing changes.
+- Changed files or affected areas when useful.
+- Verification performed.
+- Any breaking change or migration note.
+
+GitHub Release notes may summarize the changelog entry, but they should not be
+the only place where release history is recorded.
+
+## Greenfield and Brownfield Changes
+
+If a change touches a common SDD flow, update both Greenfield and Brownfield
+skill sources unless the release intentionally changes only one track.
+
+Common synchronized flow files include:
+
+- `init-project-flow.md`
+- `new-feature-flow.md`
+- `modify-existing-flow.md`
+- `new-phase-flow.md`
+- `finish-feature-flow.md`
+- `drift-verification.md`
+- `pr-review-checklist.md`
+- `git-integration.md`
+
+Track-specific changes should be named in the changelog and release notes.

package/docs/using-with-claude-code.md

@@ -0,0 +1,207 @@
+# Using Dflow with Claude Code
+
+A walk-through of what Dflow looks like when your AI coding agent is
+[Claude Code](https://claude.com/claude-code). About 10 minutes to read.
+
+This guide focuses on the Claude Code experience specifically. For the
+tool-neutral evaluation flow, see
+[`docs/evaluating-dflow.md`](evaluating-dflow.md). For the full Get Started
+and feature list, see [`README.md`](../README.md).
+
+## Who This Guide Is For
+
+You are using or evaluating Dflow with Claude Code as your AI coding agent.
+This guide covers what Claude Code sees after `init`, how Dflow's slash
+commands are recognized, and the small Claude-Code-specific patterns worth
+knowing.
+
+You do not need to read this before running `init`. It is most useful after
+you have run `init` once and want to understand what Claude Code is
+actually loading.
+
+## Prerequisites
+
+- Claude Code CLI installed (see [claude.ai/code](https://claude.com/claude-code)).
+- Node.js / npx available (Dflow ships through npm).
+- A project directory you are comfortable initializing in. A branch or a
+  disposable sample project is recommended for first contact; see the
+  [evaluator guide playbook](evaluating-dflow.md#a-30-minute-evaluation-playbook).
+
+You do not need a paid Claude Code plan to read this document. Running
+`/dflow:*` workflows requires Claude Code itself; the workflows are
+text-based and do not require additional API keys beyond Claude Code's own
+auth.
+
+## What Claude Code Sees After `init`
+
+Running `npx dflow-sdd-ddd init` and selecting Claude Code as a target tool
+creates a thin shim at the project root:
+
+```markdown
+# CLAUDE.md - Dflow Project Instructions
+
+This project uses Dflow for spec-first AI-assisted development.
+
+Before planning or editing code, read and follow:
+
+- `dflow/specs/shared/AI-AGENT-GUIDE.md`
+
+Keep tool-specific instruction files small. The Dflow guide above is the
+single source of truth for project workflow rules, slash-command behavior,
+spec locations, and SDD/DDD constraints.
+
+If your tool supports Markdown imports, the canonical guide is imported
+below:
+
+@dflow/specs/shared/AI-AGENT-GUIDE.md
+```
+
+Two things happen when Claude Code starts in this project:
+
+1. Claude Code automatically loads `CLAUDE.md` from the project root into
+   its context. This is Claude Code's standard project instructions
+   mechanism.
+2. The trailing `@dflow/specs/shared/AI-AGENT-GUIDE.md` line uses Claude
+   Code's Markdown import syntax to inline the canonical Dflow guide. So
+   Claude Code effectively reads both files as one set of instructions.
+
+The canonical guide (`dflow/specs/shared/AI-AGENT-GUIDE.md`) is where the
+real workflow rules live: project context (track, tech stack, prose
+language), the `/dflow:*` workflow table, source-of-truth file paths, and
+core SDD/DDD rules. The `CLAUDE.md` shim stays small precisely so the
+canonical guide can evolve without Claude-Code-specific edits.
+
+If a `CLAUDE.md` already existed in the project, `init` does not overwrite
+it. Instead it writes a merge snippet under `dflow/specs/shared/` that you
+can paste into your existing `CLAUDE.md` manually. This avoids destroying
+custom project instructions you already had.
+
+## Using Dflow Slash Commands in Claude Code
+
+Dflow's `/dflow:*` slash commands are workflow names recognized by the AI
+through the workflow table in `AI-AGENT-GUIDE.md`, not Claude Code's
+built-in slash command system. You type them as plain chat:
+
+```text
+/dflow:new-feature
+```
+
+Claude Code treats this as input. Because it has the workflow table loaded
+via `CLAUDE.md` import, it recognizes the prefix and enters the matching
+workflow. A typical conversation looks like:
+
+```text
+You: /dflow:new-feature
+
+Claude Code: Entering new-feature workflow. Please describe the user-facing
+capability or business behavior you want to add.
+
+You: Allow expense submitters to attach a receipt image when filing an
+expense.
+
+Claude Code: I'll start by drafting a feature spec under
+dflow/specs/features/active/. Before I do, I need a short answer on:
+[clarifying questions about scope, owner, priority]
+```
+
+The workflow then walks you through spec drafting, behavior examples,
+implementation planning, and finish-feature drift checks. The exact
+sequence depends on which workflow you entered (`/dflow:new-feature`,
+`/dflow:modify-existing`, `/dflow:bug-fix`, etc.). All workflow definitions
+live under the Dflow skill source; Claude Code follows them by reading the
+skill files when needed.
+
+Available workflow entry points:
+
+| Command | Use when |
+|---|---|
+| `/dflow:new-feature` | A new user-visible capability or business behavior is requested. |
+| `/dflow:modify-existing` | Existing behavior needs to change. |
+| `/dflow:bug-fix` | A defect can be described with expected vs actual behavior. |
+| `/dflow:new-phase` | An active feature needs another implementation slice. |
+| `/dflow:finish-feature` | Implementation is complete and needs drift closure. |
+| `/dflow:verify` | Specs, domain docs, implementation, and tests need consistency checks. |
+| `/dflow:pr-review` | A change is ready for SDD/DDD review. |
+| `/dflow:report-dflow-feedback` | You found a Dflow issue or improvement and want a sanitized upstream feedback draft. |
+
+If you forget a command name, ask Claude Code "what dflow workflows are
+available?" — the answer comes from the workflow table it already has
+loaded.
+
+## Differences vs Other AI Tools
+
+The canonical guide (`dflow/specs/shared/AI-AGENT-GUIDE.md`) is identical
+across tools. Only the root-level shim differs:
+
+| Tool | Generated shim | Loads canonical guide via |
+|---|---|---|
+| Claude Code | `CLAUDE.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
+| Codex / Copilot coding agent | `AGENTS.md` | Reads file content directly when starting |
+| Gemini CLI | `GEMINI.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
+| GitHub Copilot | `.github/copilot-instructions.md` | Reads file content directly |
+
+You can run `dflow configure-agents` later to add another tool's shim
+without re-running `init`. Multiple tools can be active in the same project
+and stay synchronized via the canonical guide.
+
+If your team uses both Claude Code and Codex CLI on the same project (a
+common setup), no extra coordination is needed. Both tools read the same
+canonical guide; only the shim file differs.
+
+## Common Patterns and Gotchas
+
+**Keep `CLAUDE.md` thin.** If you find yourself adding workflow rules,
+spec locations, or SDD constraints to `CLAUDE.md`, those belong in
+`dflow/specs/shared/AI-AGENT-GUIDE.md` instead. The shim stays small so
+that other tools' shims don't drift away from it.
+
+**`/dflow:*` is not a Claude Code Skill installation.** `init` does not
+install anything into Claude Code's skill system. The slash commands are
+plain text patterns the AI recognizes from the workflow table. You can use
+them immediately after `init` without any Claude Code configuration.
+
+**Permission gates and Dflow workflow gates are separate.** Claude Code may
+ask permission to run a tool (e.g., write a file). Dflow's workflows have
+their own approval gates (e.g., "I drafted the spec — do you want me to
+proceed to implementation?"). Both can fire on the same action; this is
+expected and not a sign of misconfiguration.
+
+**The `@` import is not recursive.** `CLAUDE.md` imports
+`AI-AGENT-GUIDE.md`, but if `AI-AGENT-GUIDE.md` references other files
+(e.g., feature specs), those are not auto-loaded — Claude Code reads them
+on demand when entering the relevant workflow. This keeps context usage
+proportional to active work.
+
+**A pre-existing `CLAUDE.md` is preserved.** `init` will not overwrite your
+existing project instructions. Look under `dflow/specs/shared/` for the
+merge snippet `init` wrote and paste the relevant sections into your
+existing `CLAUDE.md` manually.
+
+**Cross-machine projects work.** `dflow/specs/` is plain Markdown checked
+into your repo. Anyone cloning the repo and using Claude Code in it will
+see the same Dflow setup automatically through the committed `CLAUDE.md`
+shim and the canonical guide.
+
+## Where to Go Next
+
+If you have not run `init` yet:
+
+- Follow the [evaluator guide playbook](evaluating-dflow.md#a-30-minute-evaluation-playbook)
+  to try it on a disposable sample project.
+
+If you have run `init` and want to see end-to-end workflow examples:
+
+- Read [`tutorial/01-greenfield/`](../tutorial/01-greenfield/00-setup.md) or
+  [`tutorial/02-brownfield/`](../tutorial/02-brownfield/00-setup.md). The
+  tutorial walk-throughs show conversation flows and the resulting
+  `dflow/specs/` outputs.
+
+If you want to understand the design rationale:
+
+- Read [`docs/why-ddd-for-ai.md`](why-ddd-for-ai.md).
+
+If something does not work as described:
+
+- File a docs feedback issue (see [`CONTRIBUTING.md`](../CONTRIBUTING.md)).
+  Per-tool documentation is new and feedback specifically about Claude Code
+  behavior is valuable.

package/docs/using-with-codex.md

@@ -0,0 +1,244 @@
+# Using Dflow with Codex CLI
+
+A walk-through of what Dflow looks like when your AI coding agent is
+[Codex CLI](https://developers.openai.com/codex/cli). About 10 minutes to
+read.
+
+This guide focuses on the Codex CLI experience specifically. For the
+tool-neutral evaluation flow, see
+[`docs/evaluating-dflow.md`](evaluating-dflow.md). For the full Get Started
+and feature list, see [`README.md`](../README.md).
+
+## Who This Guide Is For
+
+You are using or evaluating Dflow with Codex CLI as your AI coding agent.
+This guide covers what Codex sees after `init`, how the `AGENTS.md` shim
+points to the canonical Dflow guide, and the Codex-specific command and
+permission patterns worth knowing.
+
+You do not need to read this before running `init`. It is most useful after
+you have run `init` once and want to understand what Codex CLI is actually
+loading.
+
+## Prerequisites
+
+- Codex CLI installed and authenticated (see
+  [developers.openai.com/codex/cli](https://developers.openai.com/codex/cli)).
+- Node.js / npx available (Dflow ships through npm).
+- A project directory you are comfortable initializing in. A branch or a
+  disposable sample project is recommended for first contact; see the
+  [evaluator guide playbook](evaluating-dflow.md#a-30-minute-evaluation-playbook).
+- Codex started from the initialized project root, or with `codex --cd` set
+  to that root, so Codex's `AGENTS.md` discovery includes the Dflow shim.
+
+Running Dflow workflows does not require a separate Dflow service or API key.
+The workflows are Markdown-based instructions and project files.
+
+## What Codex CLI Sees After `init`
+
+Running `npx dflow-sdd-ddd init` and selecting
+`AGENTS.md - Codex / Copilot coding agent` as a target tool creates a thin
+shim at the project root:
+
+```markdown
+# AGENTS.md - Dflow Project Instructions
+
+This project uses Dflow for spec-first AI-assisted development.
+
+Before planning or editing code, read and follow:
+
+- `dflow/specs/shared/AI-AGENT-GUIDE.md`
+
+Keep tool-specific instruction files small. The Dflow guide above is the
+single source of truth for project workflow rules, slash-command behavior,
+spec locations, and SDD/DDD constraints.
+```
+
+Two things matter when Codex starts in this project:
+
+1. Codex CLI reads `AGENTS.md` as project instructions. This is Codex's
+   standard repository-instruction mechanism.
+2. The Dflow shim does not include a Markdown import line. Unlike the
+   Claude Code and Gemini shims, generated `AGENTS.md` does not contain
+   `@dflow/specs/shared/AI-AGENT-GUIDE.md`.
+
+That means Codex sees the pointer immediately, but the canonical Dflow guide
+is not auto-inlined by the shim. Before planning or editing, Codex should
+follow the pointer and read `dflow/specs/shared/AI-AGENT-GUIDE.md`. If Codex
+starts answering a Dflow request without mentioning that file, steer it
+explicitly: "Before continuing, read and follow
+`dflow/specs/shared/AI-AGENT-GUIDE.md`."
+
+The canonical guide is where the real workflow rules live: project context
+(track, tech stack, prose language), the Dflow workflow table,
+source-of-truth file paths, and core SDD/DDD rules. The `AGENTS.md` shim
+stays small so the same canonical guide can serve Codex CLI, Claude Code,
+Gemini CLI, GitHub Copilot, and other tools.
+
+If an `AGENTS.md` already existed in the project, `init` does not overwrite
+it. If the existing file does not already point to
+`dflow/specs/shared/AI-AGENT-GUIDE.md`, `init` writes a merge snippet under
+`dflow/specs/shared/AGENTS-md-snippet.md` that you can merge manually. This
+avoids destroying custom project instructions you already had.
+
+## Using Dflow Workflow Commands in Codex CLI
+
+Codex CLI has its own built-in slash command layer for controlling the CLI
+session. Commands such as `/permissions`, `/model`, `/status`, `/diff`,
+`/review`, and `/init` are Codex CLI controls, not Dflow workflows.
+
+Dflow's `/dflow:*` entries are workflow names recognized by the AI through
+`AI-AGENT-GUIDE.md`, not registered Codex CLI commands. Raw
+`/dflow:new-feature` passthrough behavior in Codex CLI should be verified
+with the maintainer for the supported Codex version. The reliable form is to
+name the workflow as a plain chat instruction:
+
+```text
+Run the Dflow /dflow:new-feature workflow.
+```
+
+If your Codex CLI version passes unknown slash-prefixed input through to the
+model, this shorter form may also work (verify with maintainer):
+
+```text
+/dflow:new-feature
+```
+
+If Codex reports an unknown slash command, re-send the request in prose:
+
+```text
+Treat /dflow:new-feature as a Dflow workflow name, not as a Codex CLI
+command. Read dflow/specs/shared/AI-AGENT-GUIDE.md and start that workflow.
+```
+
+A typical conversation looks like:
+
+```text
+You: Run the Dflow /dflow:new-feature workflow.
+
+Codex CLI: I'll read dflow/specs/shared/AI-AGENT-GUIDE.md first, then use the
+new-feature workflow. Please describe the user-visible capability or business
+behavior you want to add.
+
+You: Allow expense submitters to attach a receipt image when filing an
+expense.
+
+Codex CLI: I'll start by drafting a feature spec under
+dflow/specs/features/active/. Before I do, I have a few clarifying questions.
+```
+
+The workflow then walks you through spec drafting, behavior examples,
+implementation planning, and finish-feature drift checks. The exact
+sequence depends on which workflow you entered (`/dflow:new-feature`,
+`/dflow:modify-existing`, `/dflow:bug-fix`, etc.).
+
+Available workflow entry points:
+
+| Workflow | Use when |
+|---|---|
+| `/dflow:new-feature` | A new user-visible capability or business behavior is requested. |
+| `/dflow:modify-existing` | Existing behavior needs to change. |
+| `/dflow:bug-fix` | A defect can be described with expected vs actual behavior. |
+| `/dflow:new-phase` | An active feature needs another implementation slice. |
+| `/dflow:finish-feature` | Implementation is complete and needs drift closure. |
+| `/dflow:verify` | Specs, domain docs, implementation, and tests need consistency checks. |
+| `/dflow:pr-review` | A change is ready for SDD/DDD review. |
+| `/dflow:report-dflow-feedback` | You found a Dflow issue or improvement and want a sanitized upstream feedback draft. |
+
+If you forget a workflow name, ask Codex to read
+`dflow/specs/shared/AI-AGENT-GUIDE.md` and list the available Dflow
+workflows.
+
+## Differences vs Other AI Tools
+
+The canonical guide (`dflow/specs/shared/AI-AGENT-GUIDE.md`) is identical
+across tools. Only the root-level shim differs:
+
+| Tool | Generated shim | Loads canonical guide via |
+|---|---|---|
+| Claude Code | `CLAUDE.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
+| Codex / Copilot coding agent | `AGENTS.md` | Project instructions load the shim; Codex must follow the pointer and read the guide |
+| Gemini CLI | `GEMINI.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
+| GitHub Copilot | `.github/copilot-instructions.md` | Reads repository instructions directly |
+
+You can run `dflow configure-agents` later to add another tool's shim
+without re-running `init`. Multiple tools can be active in the same project
+and stay synchronized via the canonical guide.
+
+Codex also has its own project-instruction layering. It can read global
+instructions from Codex home and project instructions from `AGENTS.md` files
+between the project root and the current working directory. For Dflow, the
+important practical rule is simple: start Codex at the initialized project
+root, and keep the Dflow pointer in the nearest relevant `AGENTS.md`.
+
+If your team uses both Claude Code and Codex CLI on the same project, no
+extra Dflow coordination is needed. Both tools use the same canonical guide;
+only the shim file and loading mechanism differ.
+
+## Common Patterns and Gotchas
+
+**Keep `AGENTS.md` thin.** If you find yourself adding workflow rules, spec
+locations, or SDD constraints to `AGENTS.md`, those belong in
+`dflow/specs/shared/AI-AGENT-GUIDE.md` instead. The shim stays small so that
+other tools' shims do not drift away from it.
+
+**Codex does not inline the Dflow guide from `AGENTS.md`.** The generated
+Codex shim has a normal Markdown bullet pointing to the canonical guide, not
+an `@...` import. Ask Codex to read `AI-AGENT-GUIDE.md` if it appears to be
+working from the shim alone.
+
+**`/dflow:*` is not a Codex CLI built-in slash command.** Codex slash
+commands control the Codex session itself. Use Dflow workflow names as plain
+chat instructions when raw slash input is intercepted or rejected. Raw
+`/dflow:*` passthrough behavior should be verified with the maintainer for
+the supported Codex version.
+
+**Do not confuse Codex `/init` with Dflow `init`.** Codex `/init` creates a
+generic `AGENTS.md` scaffold for Codex. Dflow setup is `npx dflow-sdd-ddd
+init`, and adding later tool shims is `dflow configure-agents`.
+
+**Permission gates and Dflow workflow gates are separate.** Codex may ask
+permission to run a command, edit outside the workspace, or access network
+depending on its sandbox and approval settings. Dflow workflows have their
+own approval gates, such as confirming a spec before implementation. Both
+can appear in the same session; this is expected.
+
+**The common Codex local-work preset is workspace write plus on-request
+approvals.** In current Codex CLI terminology this is
+`--sandbox workspace-write --ask-for-approval on-request`. In that mode,
+Codex can work inside the project and asks before going beyond the sandbox,
+such as writing outside the workspace or accessing network.
+
+**Existing `AGENTS.md` files are preserved.** If Dflow cannot safely write
+the root shim because the file already exists, look under
+`dflow/specs/shared/` for the merge snippet and merge the Dflow pointer into
+your existing project instructions manually.
+
+**Nested `AGENTS.md` files can change what Codex sees.** Codex layers project
+instructions along the path to the current working directory. If a subfolder
+has its own `AGENTS.md` or `AGENTS.override.md`, make sure it does not hide
+or contradict the Dflow pointer you expect Codex to follow.
+
+## Where to Go Next
+
+If you have not run `init` yet:
+
+- Follow the [evaluator guide playbook](evaluating-dflow.md#a-30-minute-evaluation-playbook)
+  to try it on a disposable sample project.
+
+If you have run `init` and want to see end-to-end workflow examples:
+
+- Read [`tutorial/01-greenfield/`](../tutorial/01-greenfield/00-setup.md) or
+  [`tutorial/02-brownfield/`](../tutorial/02-brownfield/00-setup.md). The
+  tutorial walk-throughs show conversation flows and the resulting
+  `dflow/specs/` outputs.
+
+If you want to understand the design rationale:
+
+- Read [`docs/why-ddd-for-ai.md`](why-ddd-for-ai.md).
+
+If something does not work as described:
+
+- File a docs feedback issue (see [`CONTRIBUTING.md`](../CONTRIBUTING.md)).
+  Per-tool documentation is new and feedback specifically about Codex CLI
+  behavior is valuable.

package/docs/why-ddd-for-ai.md

@@ -0,0 +1,35 @@
+# Why DDD Matters More with AI
+
+AI-assisted development changes the failure mode of software design. The team can produce more code faster, but unclear domain meaning is also amplified faster.
+
+When a project lacks shared language and explicit boundaries, small inconsistencies spread:
+
+- the same concept appears as `Order`, `Booking`, and `Transaction`
+- APIs encode different meanings for similar actions
+- business rules live in handlers, UI code, scripts, and tests
+- nobody can confidently say which behavior is authoritative
+
+An AI coding agent does not know the business domain by default. When the prompt is incomplete, it fills the missing parts with plausible logic. That logic may compile, pass superficial tests, and still be wrong. The most dangerous AI mistakes are often not syntax errors; they are reasonable-looking domain mistakes.
+
+DDD gives the spec a semantic backbone:
+
+| DDD idea | AI-era value |
+|---|---|
+| **Ubiquitous Language** | Keeps names and meanings stable across prompts, specs, code, and reviews. |
+| **Bounded Context** | Defines where a term or rule is valid, and prevents accidental meaning leaks. |
+| **Domain Model** | Gives behavior a clear owner instead of scattering rules across technical layers. |
+| **Domain Rules** | States what is correct, allowed, forbidden, and exceptional before code generation. |
+
+The important shift is where design lives. In older workflows, much of the real design could remain implicit in code. With AI, that is too late. The model needs constraints before it generates code.
+
+```text
+Without DDD:
+Prompt -> AI fills gaps -> Code -> Hidden domain drift
+
+With DDD:
+Domain meaning -> Structured spec -> AI implementation -> Reviewable code
+```
+
+Code still matters, but it is no longer the first place where meaning should be discovered. For AI collaboration, specs become the pre-generation contract, and DDD supplies the language, boundaries, and rules that make the contract precise.
+
+Dflow is built around that idea: spec first, domain meaning explicit, AI constrained before implementation, and drift checked before the work is considered done.