pilotspace-add 1.0.0__tar.gz

pilotspace_add-1.0.0/GETTING-STARTED.md

@@ -0,0 +1,238 @@
+# Getting started with ADD — your first feature in ~10 minutes
+
+This is a runnable walkthrough. Follow it top to bottom and you'll take one real
+feature — *transfer money between a user's own accounts* (the book's worked
+example) — from nothing to a verified, passing result, using the ADD method.
+
+You'll learn the whole loop by doing it once:
+
+> **Specify → Scenarios → Contract → Tests → Build → Verify → Observe**
+
+ADD is **AI-first**: you talk to the agent and it drives the method — you don't
+hand-type the commands. The commands below are the agent's hands (and your escape
+hatch); the rest of this guide shows both so you can see what the agent does.
+
+---
+
+## The fast path — talk to the agent
+
+After installing (step 1 below), the whole on-ramp is one move:
+
+```
+in Claude Code:  /add
+you:             "I want to let users transfer money between their own accounts."
+```
+
+From there the agent runs the **on-ramp** for you:
+
+1. **Orient** — it reads `add.py status` (the resume point), never re-reading your repo.
+2. **Intake** — it sizes your request into versioned scope and proposes a **milestone**
+   (goal · scope · breadth-first tasks · exit criteria). *You confirm the shape.*
+3. **One-approval front** — for each task it drafts Spec + Scenarios + Contract + Tests
+   as one bundle. *You give one approval at the frozen contract.*
+4. **Self-driving run** — build→verify runs to green; a security finding always stops
+   back to you.
+
+So a milestone-sized feature is: **describe it → confirm the milestone → approve each
+contract → review the result.** Everything between is the agent.
+
+> New term: **On-ramp** — the install→first-milestone path. See `docs/appendix-c-glossary.md`.
+
+---
+
+## 0 · Prerequisites
+
+- **Node.js ≥ 18** (to install) and **Python 3.10+** (the tool is stdlib-only).
+- A project folder. It can be empty or an existing repo.
+
+---
+
+## 1 · Install
+
+From your project root:
+
+```bash
+npx @pilotspace/add init --name "My App" --stage prototype
+```
+
+This creates `.add/` (your runtime), drops the `add` skill into
+`.claude/skills/add/`, and bundles the book into `.add/docs/`. Pick the stage that
+matches your intent — `prototype`, `poc`, `mvp`, or `production`. You can change it
+later with `python3 .add/tooling/add.py stage mvp`.
+
+> Why stages exist: the steps never change, only how *deeply* you run them.
+> See `.add/docs/10-setup-and-stages.md`.
+
+---
+
+## 2 · Orient — the command you'll use most
+
+```bash
+python3 .add/tooling/add.py status
+```
+
+`add.py status` is your home base. It reads `.add/state.json` and tells you the
+project stage, the active task, and which phase you're in. **Start every session
+with it** — that's how ADD resumes work without re-reading your whole repo.
+
+> Tip: shorten typing with an alias — `alias add="python3 .add/tooling/add.py"` —
+> then you can run `add status`, `add advance`, etc. The rest of this guide writes
+> the full `python3 .add/tooling/add.py ...` form so copy-paste always works.
+
+And when you're mid-task and unsure what the current phase needs, ask:
+
+```bash
+python3 .add/tooling/add.py guide
+```
+
+`status` tells you *where* you are; `guide` tells you *what to do next* — the active
+task's phase, the one concrete next action, the chapter to read, and the exact command
+to run once that phase is done.
+
+---
+
+## 3 · Start your first feature
+
+```bash
+python3 .add/tooling/add.py new-task transfer --title "Transfer money between my accounts"
+```
+
+This scaffolds `.add/tasks/transfer/TASK.md` — **one file holding all seven phase
+sections** — plus empty `tests/` and `src/` folders, and makes it the active task
+at phase `specify`.
+
+Open `.add/tasks/transfer/TASK.md` in your editor. You'll fill it top to bottom.
+
+---
+
+## Under the hood — the seven phases by hand (escape hatch)
+
+Everything above is what the agent drives for you through the one-approval front. This
+section is the **escape hatch**: the same seven phases run by hand, so you can see what
+each one produces and step in manually whenever you want to. You never *have* to type
+these — they are the agent's hands, and yours when you take the wheel.
+
+The rhythm is always: **fill the section → run `python3 .add/tooling/add.py advance`.**
+The tool keeps the `phase:` marker at the top of TASK.md in sync.
+
+### Phase 1 — Specify (`docs/03-step-1-specify.md`)
+
+Write the rules in **§1**. State what it *must* do, what it must *reject* (each
+with a named error code), and what's true after success:
+
+```
+Must:
+  - move an amount from one of my accounts to another of mine
+  - amount > 0 ; source ≠ destination ; source has enough balance
+After:
+  - source balance -= amount, destination balance += amount
+Reject:
+  - amount <= 0           -> "amount_invalid"
+  - source == destination -> "same_account"
+  - balance < amount      -> "insufficient_funds"
+  - account not mine      -> "forbidden"
+```
+
+Confirm every assumption (no FX, no daily limit in v1). Then:
+
+```bash
+python3 .add/tooling/add.py advance
+```
+
+### Phase 2 — Scenarios (`docs/04-step-2-scenarios.md`)
+
+In **§2**, turn each rule into a Given/When/Then. For every rejection, assert what
+must stay **unchanged**:
+
+```gherkin
+Scenario: insufficient funds
+  Given A has 20, mine
+  When I transfer 50 from A to B
+  Then it is rejected "insufficient_funds"
+  And no balance changes
+```
+
+Then `python3 .add/tooling/add.py advance`.
+
+### Phase 3 — Contract (`docs/05-step-3-contract.md`)
+
+In **§3**, fix the external shape and **freeze** it (`Status: FROZEN @ v1`):
+
+```
+POST /transfers  body: { fromAccountId, toAccountId, amount }
+  200 -> { transferId, fromBalance, toBalance }
+  400 -> { error: "amount_invalid" | "same_account" | "insufficient_funds" }
+  403 -> { error: "forbidden" }
+```
+
+A frozen contract is the seam that makes the AI build safe. Then advance.
+
+### Phase 4 — Tests, red first (`docs/06-step-4-tests.md`)
+
+Write one test per scenario into `.add/tasks/transfer/tests/`, then **run them and
+confirm they FAIL** — there's no code yet. A test that passes now is testing
+nothing. This is red/green TDD: red before green. Then advance.
+
+### Phase 5 — Build (`docs/07-step-5-build.md`)
+
+Now let the AI write code into `.add/tasks/transfer/src/` until **every test
+passes** — without changing any test or the frozen contract. Honor the safety rule
+(here: debit + credit in one atomic transaction). Then advance.
+
+### Phase 6 — Verify (`docs/08-step-6-verify.md`)
+
+In **§6**, confirm the evidence (all green, nothing weakened) and check what tests
+miss: concurrency, security, architecture. Record the gate — and close the task:
+
+```bash
+python3 .add/tooling/add.py gate PASS
+```
+
+`gate PASS` marks the task `done`. (Use `gate HARD-STOP` to send it back to Build,
+or `gate RISK-ACCEPTED` for a signed, non-security waiver.)
+
+### Phase 7 — Observe (`docs/09-the-loop.md`)
+
+In **§7**, note what to watch in production and the next spec delta. Every learning
+becomes the next `new-task`. The flow is a loop, not a finish line.
+
+---
+
+## 5 · Self-check
+
+Confirm your project is internally consistent at any time:
+
+```bash
+python3 .add/tooling/add.py check
+```
+
+It verifies state is valid, every task has its TASK.md, and markers match. Exit
+code 0 means healthy — handy as a CI gate.
+
+---
+
+## 6 · Resume next session
+
+Close your laptop, come back tomorrow, run:
+
+```bash
+python3 .add/tooling/add.py status
+```
+
+It tells you exactly where you left off and what to do next. No context rot — the
+state lives on disk, not in a chat window.
+
+---
+
+## 7 · Where to read more
+
+You just ran the method; now read *why* it's shaped this way:
+
+- The shift & principles — `.add/docs/00-introduction.md`, `.add/docs/01-principles.md`
+- The flow end to end — `.add/docs/02-the-flow.md`
+- Each step in depth — `.add/docs/03..09`
+- Operating it on a team — `.add/docs/11-governance.md`, `.add/docs/12-roles.md`
+- A fully worked example — `.add/docs/appendix-d-worked-example.md`
+
+The rule to remember: **build the right thing (direction), prove it's right
+(verification), and let the AI do the building in between.**

pilotspace_add-1.0.0/LICENSE

@@ -0,0 +1,20 @@
+MIT License
+
+Copyright (c) 2026 Tin Dang
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
+COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

pilotspace_add-1.0.0/MANIFEST.in

@@ -0,0 +1,17 @@
+# MANIFEST.in — controls sdist (source distribution) inclusion.
+# python -m build builds the wheel FROM the sdist, so files missing here
+# can be silently absent from the wheel too. This is the primary trap to avoid.
+
+# The generated bundle — the only non-Python data this package ships.
+graft src/add_method/_bundled
+
+# Top-level prose
+include README.md
+include GETTING-STARTED.md
+include LICENSE
+
+# Global excludes — keep the distributions clean
+global-exclude __pycache__
+global-exclude *.py[co]
+global-exclude .DS_Store
+global-exclude *.egg-info

pilotspace_add-1.0.0/PKG-INFO

@@ -0,0 +1,131 @@
+Metadata-Version: 2.4
+Name: pilotspace-add
+Version: 1.0.0
+Summary: ADD (AI-Driven Development) — install the ADD skill, tooling, and AIDD book into any project
+Author-email: Tin Dang <tindang.ht97@gmail.com>
+License-Expression: MIT
+Project-URL: Homepage, https://github.com/pilotspace/ADD
+Project-URL: Repository, https://github.com/pilotspace/ADD
+Project-URL: Issues, https://github.com/pilotspace/ADD/issues
+Keywords: ai-driven-development,add,aidd,claude-code,skill,tdd,spec-driven,agent,methodology
+Classifier: Development Status :: 4 - Beta
+Classifier: Intended Audience :: Developers
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Software Development
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Dynamic: license-file
+
+# ADD — AI-Driven Development
+
+> A minimal, state-tracked Claude Code skill for building software when the AI
+> writes the code and **you** own the two things it cannot do alone: decide *what*
+> to build, and *verify* it is correct.
+
+ADD is the **orchestration engine** of the AIDD method. It sits on top of a
+context foundation (DDD → SDD → UDD) and runs as a red/green TDD ↔ AI-build loop.
+The full reasoning — *why* every rule exists — is the AIDD book bundled in
+[`docs/`](./docs/README.md). Read it once; keep it open beside you.
+
+```
+  Foundation (context):  DDD  ·  SDD  ·  UDD
+  Engine (this skill):   TDD  ⇄  ADD
+  Flow per feature:  Specify → Scenarios → Contract → Tests → Build → Verify → Observe ↻
+```
+
+## Why ADD (and why it is minimal)
+
+Heavy doc-first methods burn your time writing documents and lose the thread
+across sessions (context rot). ADD fixes both:
+
+- **One file per feature.** Spec, scenarios, contract, test-plan, and gate record
+  all live inline in a single `TASK.md`. No sprawling doc tree.
+- **State on disk, not in chat.** A Python tool tracks where you are in
+  `.add/state.json`, so a fresh session resumes with one command instead of
+  re-reading the repo.
+- **Progressive disclosure.** The skill loads only the guide for the phase you are
+  in — the context window stays lean.
+
+## Install
+
+Pick your ecosystem — both install the same skill, tooling, and book:
+
+```bash
+# Node / npm
+npx @pilotspace/add init --name "My App" --stage prototype
+```
+
+```bash
+# Python / pip
+pip install pilotspace-add
+pilotspace-add init --name "My App" --stage prototype
+```
+
+**New here?** Follow the [10-minute Quickstart](./GETTING-STARTED.md) — it walks
+your first feature end to end.
+
+This installs:
+
+| Path | What |
+|------|------|
+| `.claude/skills/add/` | the `add` skill Claude loads (thin router + per-phase guides) |
+| `.add/tooling/add.py` | scaffolder + state tracker (Python, stdlib only) |
+| `.add/docs/` | the AIDD book — the trust layer |
+| `.add/state.json` | where the project is |
+| `.add/CONVENTIONS.md`, `GLOSSARY.md`, `MODEL_REGISTRY.md`, `dependencies.allowlist` | survivor-layer files |
+
+## Use it
+
+ADD is AI-first: you talk to the agent; it drives the method. In Claude Code, run
+**`/add`** and say what you want to build:
+
+> `/add` — *"I want to let users transfer money between their own accounts."*
+
+The agent orients from `state.json`, **sizes your request into a milestone** (you
+confirm the shape), then drafts each feature's **one-approval front** — Spec +
+Scenarios + Contract + Tests as one bundle — and you give **one approval at the
+frozen contract**. A self-driving build→verify run takes it to green; security
+findings always stop back to you.
+
+Under the hood the agent runs the CLI as its hands — and you can hand-drive it too:
+
+```bash
+python3 .add/tooling/add.py status      # where am I? (resume point)
+```
+
+## The non-negotiables
+
+1. **Direction before speed** — no Build until spec, scenarios, contract, and *red*
+   tests exist.
+2. **Trust evidence, not inspection** — a feature is trusted because its tests pass
+   and the blind spots (concurrency, security, architecture) were checked.
+3. **Never weaken a test or edit a frozen contract** to make the build pass.
+4. **No silent skips** — every Verify records `PASS`, `RISK-ACCEPTED`, or
+   `HARD-STOP`. Security findings are always `HARD-STOP`.
+5. **Ask, don't guess.**
+
+## The artifacts survive; the code is disposable
+
+The durable asset is the decisions — spec, scenarios, contract, tests. The code is
+one implementation that satisfies them and can be regenerated. If the thing you'd
+be upset to lose is "the code," you're still working the old way.
+
+## Read the method
+
+Start at [`docs/README.md`](./docs/README.md) — Foundations → the six steps →
+operating it across a team → templates, prompts, and a full worked example.
+
+## Develop
+
+```bash
+npm test     # runs the Python tests for the tooling (red/green)
+```
+
+License: MIT.

pilotspace_add-1.0.0/README.md

@@ -0,0 +1,106 @@
+# ADD — AI-Driven Development
+
+> A minimal, state-tracked Claude Code skill for building software when the AI
+> writes the code and **you** own the two things it cannot do alone: decide *what*
+> to build, and *verify* it is correct.
+
+ADD is the **orchestration engine** of the AIDD method. It sits on top of a
+context foundation (DDD → SDD → UDD) and runs as a red/green TDD ↔ AI-build loop.
+The full reasoning — *why* every rule exists — is the AIDD book bundled in
+[`docs/`](./docs/README.md). Read it once; keep it open beside you.
+
+```
+  Foundation (context):  DDD  ·  SDD  ·  UDD
+  Engine (this skill):   TDD  ⇄  ADD
+  Flow per feature:  Specify → Scenarios → Contract → Tests → Build → Verify → Observe ↻
+```
+
+## Why ADD (and why it is minimal)
+
+Heavy doc-first methods burn your time writing documents and lose the thread
+across sessions (context rot). ADD fixes both:
+
+- **One file per feature.** Spec, scenarios, contract, test-plan, and gate record
+  all live inline in a single `TASK.md`. No sprawling doc tree.
+- **State on disk, not in chat.** A Python tool tracks where you are in
+  `.add/state.json`, so a fresh session resumes with one command instead of
+  re-reading the repo.
+- **Progressive disclosure.** The skill loads only the guide for the phase you are
+  in — the context window stays lean.
+
+## Install
+
+Pick your ecosystem — both install the same skill, tooling, and book:
+
+```bash
+# Node / npm
+npx @pilotspace/add init --name "My App" --stage prototype
+```
+
+```bash
+# Python / pip
+pip install pilotspace-add
+pilotspace-add init --name "My App" --stage prototype
+```
+
+**New here?** Follow the [10-minute Quickstart](./GETTING-STARTED.md) — it walks
+your first feature end to end.
+
+This installs:
+
+| Path | What |
+|------|------|
+| `.claude/skills/add/` | the `add` skill Claude loads (thin router + per-phase guides) |
+| `.add/tooling/add.py` | scaffolder + state tracker (Python, stdlib only) |
+| `.add/docs/` | the AIDD book — the trust layer |
+| `.add/state.json` | where the project is |
+| `.add/CONVENTIONS.md`, `GLOSSARY.md`, `MODEL_REGISTRY.md`, `dependencies.allowlist` | survivor-layer files |
+
+## Use it
+
+ADD is AI-first: you talk to the agent; it drives the method. In Claude Code, run
+**`/add`** and say what you want to build:
+
+> `/add` — *"I want to let users transfer money between their own accounts."*
+
+The agent orients from `state.json`, **sizes your request into a milestone** (you
+confirm the shape), then drafts each feature's **one-approval front** — Spec +
+Scenarios + Contract + Tests as one bundle — and you give **one approval at the
+frozen contract**. A self-driving build→verify run takes it to green; security
+findings always stop back to you.
+
+Under the hood the agent runs the CLI as its hands — and you can hand-drive it too:
+
+```bash
+python3 .add/tooling/add.py status      # where am I? (resume point)
+```
+
+## The non-negotiables
+
+1. **Direction before speed** — no Build until spec, scenarios, contract, and *red*
+   tests exist.
+2. **Trust evidence, not inspection** — a feature is trusted because its tests pass
+   and the blind spots (concurrency, security, architecture) were checked.
+3. **Never weaken a test or edit a frozen contract** to make the build pass.
+4. **No silent skips** — every Verify records `PASS`, `RISK-ACCEPTED`, or
+   `HARD-STOP`. Security findings are always `HARD-STOP`.
+5. **Ask, don't guess.**
+
+## The artifacts survive; the code is disposable
+
+The durable asset is the decisions — spec, scenarios, contract, tests. The code is
+one implementation that satisfies them and can be regenerated. If the thing you'd
+be upset to lose is "the code," you're still working the old way.
+
+## Read the method
+
+Start at [`docs/README.md`](./docs/README.md) — Foundations → the six steps →
+operating it across a team → templates, prompts, and a full worked example.
+
+## Develop
+
+```bash
+npm test     # runs the Python tests for the tooling (red/green)
+```
+
+License: MIT.

pilotspace_add-1.0.0/pyproject.toml

@@ -0,0 +1,54 @@
+[build-system]
+requires = ["setuptools>=77"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "pilotspace-add"
+version = "1.0.0"
+description = "ADD (AI-Driven Development) — install the ADD skill, tooling, and AIDD book into any project"
+readme = "README.md"
+license = "MIT"
+license-files = ["LICENSE"]
+authors = [
+  { name = "Tin Dang", email = "tindang.ht97@gmail.com" },
+]
+keywords = [
+  "ai-driven-development", "add", "aidd", "claude-code",
+  "skill", "tdd", "spec-driven", "agent", "methodology",
+]
+classifiers = [
+  "Development Status :: 4 - Beta",
+  "Intended Audience :: Developers",
+  "Operating System :: OS Independent",
+  "Programming Language :: Python :: 3",
+  "Programming Language :: Python :: 3.10",
+  "Programming Language :: Python :: 3.11",
+  "Programming Language :: Python :: 3.12",
+  "Programming Language :: Python :: 3.13",
+  "Programming Language :: Python :: 3.14",
+  "Topic :: Software Development",
+]
+requires-python = ">=3.10"
+dependencies = []
+
+[project.urls]
+Homepage = "https://github.com/pilotspace/ADD"
+Repository = "https://github.com/pilotspace/ADD"
+Issues = "https://github.com/pilotspace/ADD/issues"
+
+[project.scripts]
+pilotspace-add = "add_method._cli:main"
+
+[tool.setuptools]
+package-dir = { "" = "src" }
+include-package-data = true
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.setuptools.package-data]
+# Belt-and-suspenders: declare explicitly so the wheel always ships _bundled/
+# regardless of whether files are git-tracked or MANIFEST.in is processed.
+add_method = [
+  "_bundled/**/*",
+]

pilotspace_add-1.0.0/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

pilotspace_add-1.0.0/src/add_method/__init__.py

@@ -0,0 +1,16 @@
+"""add_method — Python installer for the ADD (AI-Driven Development) method.
+
+Published as `pilotspace-add` on PyPI. Installs the ADD skill, tooling, and
+AIDD book into a target project, then runs `add.py init`.
+
+Usage (CLI):
+    pilotspace-add init [targetDir] [--force] [--stage STAGE] [--name NAME]
+
+Usage (Python API):
+    from add_method import install
+    install("/path/to/project", stage="mvp", name="my-app")
+"""
+from add_method._installer import install
+
+__all__ = ["install"]
+__version__ = "1.0.0"

pilotspace_add-1.0.0/src/add_method/__main__.py

@@ -0,0 +1,7 @@
+"""Support `python -m add_method` as an alias for the `pilotspace-add` console script."""
+import sys
+
+from add_method._cli import main
+
+if __name__ == "__main__":
+    sys.exit(main())

pilotspace_add-1.0.0/src/add_method/_bundled/docs/00-introduction.md

@@ -0,0 +1,46 @@
+# 00 · The shift: why AIDD exists
+
+[Contents](./README.md) · Next: [01 Core principles →](./01-principles.md)
+
+---
+
+## Code became cheap
+
+For the whole history of software, writing code was the slow, expensive, central act. Methodologies — waterfall, agile, and the rest — were arrangements for managing that expensive act: how to plan it, divide it, review it, and ship it.
+
+AI changed the cost. An agent can now produce a working module in the time it takes to describe it. The marginal cost of *writing* a piece of code, and of *re-writing* it, has fallen close to zero.
+
+When the cost of one activity collapses, value moves to whatever is still scarce. Three things remain scarce:
+
+1. **Validated decisions** — knowing what should be built, and being right about it.
+2. **Stable contracts** — the agreed interfaces and data shapes that everything else depends on.
+3. **Verification capacity** — the rate at which people can confirm that what was produced is actually correct.
+
+AIDD is a development method organized around protecting those three things, because they are now where the difficulty lives.
+
+## The failure mode AIDD prevents
+
+The naïve way to use an AI agent is to describe a feature in a sentence and accept whatever it returns. This works for a throwaway script and fails for real software, for one reason: **an AI agent is fast in whatever direction it is pointed.**
+
+If the direction is vague, the agent does not slow down and ask. It produces a confident, plausible, complete-looking result that is subtly wrong — built on an assumption you never made, missing an edge case you never stated. Because it looks finished, the error survives a quick read and surfaces later, when it is expensive to fix.
+
+Speed in the wrong direction is not progress; it is faster waste. The entire purpose of AIDD is to fix the direction *before* turning on the speed.
+
+## Where value moves — and what that means for you
+
+If writing code is no longer the scarce skill, then a software person's value is no longer "can write code." It is two new things:
+
+- **Direction** — turning a fuzzy need into an unambiguous, buildable definition.
+- **Verification** — establishing, through evidence, that the result is correct and safe.
+
+This is not a smaller job than coding; it is a harder one. It is the part of engineering that was always the real work, now made explicit because the typing has been automated away.
+
+## What this book gives you
+
+The rest of the book is the practical consequence of the shift:
+
+- A **flow** (Part II) that front-loads direction and back-loads AI execution, with verification built in.
+- An **operating manual** (Part III) for running that flow across stages, roles, and risk levels.
+- **Reference material** (Part IV) — templates, prompts, and a fully worked example — so the method is concrete from day one.
+
+> **The thesis in one line.** Build the right thing (direction), prove it is right (verification), and let the AI do the building in between.