Case Study, Part 3 of 5: Inception Phase

Where we are: synth-data's Ideation is complete and approved — we know what we're building and why. Inception now turns that into requirements, a domain model, and a concrete delivery plan, before any code gets written.

In plain English: This phase turns "what we want" into "exactly what we'll build and how." It writes down the precise rules (requirements), sketches how the data fits together (domain design), and decides what order things get built in (delivery plan) — all before a single line of real code exists.

Every prompt we actually type is highlighted like this.

Stage 2.1: Reverse Engineering — Skipped

This stage only runs on brownfield projects, to scan and document existing code before changing it. Workspace Detection already classified this project as greenfield back in Part 1, so it's pre-marked [S] Skipped — nothing to reverse-engineer on a project that doesn't exist yet.

Stage 2.2: Requirements Analysis (product agent)

Claude Code writes aidlc/spaces/default/intents/260909-synthetic-data-generator/inception/requirements-analysis/requirements-questions.md:

## Question 1: Schema format
How should we define a schema?
A) YAML file
B) JSON file
X) Other
[Answer]:

## Question 2: Constraint types
Which constraints must the MVP support?
A) type + nullable only
B) type + nullable + min/max + regex pattern
X) Other
[Answer]:

We fill it in directly in the file, in our own editor:

[Answer]: A — YAML, easiest to hand-edit.
[Answer]: B — type, nullable, min/max, and regex. Covers most real schemas.

You: We've answered your questions. Please re-read the file and continue.

Claude Code writes requirements.md from it — functional requirements (parse a YAML schema, generate N constraint-compliant rows, export to 4 formats) and a couple of non-functional notes — then opens the gate.

You: Approve

Behind the scenes: Answering in the file, then telling Claude Code to re-read it, matters — it forces the agent to load our actual, current answers off disk rather than trust its memory of the conversation. aidlc-run-sensors checks requirements.md against this stage's declared sensors (e.g. required-sections, traceability back to the Ideation scope document) before the gate is allowed to open.

Stage 2.3: User Stories (mob pattern)

This stage runs as a mob: several collaborator personas contribute stories in parallel, rather than one agent working alone — like several people talking through a whiteboard together instead of one person writing it all solo.

Claude Code: - As a developer, I want to define a schema in YAML so I can version it alongside my test suite. - As a developer, I want CSV and JSON output so I can feed either into my existing test fixtures. - As a developer, I want a clear error on an invalid schema so I don't debug garbage output instead.

Written to user-stories.md. Approve

Stage 2.4: Practices Discovery (subagent hub-and-spoke)

This one has a distinctive shape — "hub-and-spoke" means one central agent (the hub) sends work out to several others (the spokes) and then collects their answers back, like a manager assigning pieces of a task and gathering the results: a lead agent drafts, three other personas independently and blindly review that draft, then a human interview happens before final integration.

─── Stage 2.5: Practices Discovery (hub-and-spoke) ────────────────
Lead (developer) drafting practices.md...
Delegating to 3 reviewers for blind review (mutually invisible)...
✓ 3 reviews returned. Integrating.

Claude Code: Practices for this project: full type hints, black formatting, pytest fixtures over setup/teardown methods, one module per concern (schema.py, generate.py, exporters.py, cli.py). Do you want to affirm these as team-wide practice, or is anything wrong here? You: Affirm as-is.

Behind the scenes: "Blind" means the three reviewers can't see each other's feedback while drafting theirs — it avoids review-of-a-review groupthink. Affirmed practices get written to aidlc/spaces/default/memory/team.md, so the next intent in this space starts with these conventions already loaded — this is the "learning loop" the methodology keeps referring to.

Stage 2.5: Domain Design (architect agent)

Claude Code: The domain model: ```python @dataclass class Constraint: min: float | None = None max: float | None = None pattern: str | None = None

@dataclass class Column: name: str type: Literal["string", "int", "float", "date", "email", "name"] nullable: bool = False constraint: Constraint | None = None

@dataclass class Schema: columns: list[Column] `` Written todomain-design.md`. Approve

Stage 2.6: Contract Design (architect agent)

Claude Code: The CLI's contract: text synth-data generate --schema PATH --rows N --format {csv,json,parquet,sql} --out PATH [--table NAME] --table is only required for --format sql. Written to contract-design.md. Approve

Stage 2.7: Refined Mockups (design agent)

Claude Code: Final --help text, matching the contract above exactly. Written to refined-mockups.md. Approve

Stage 2.8: Units Generation (architect agent)

Claude Code: This is small enough to stay one unit: synth-data-cli, covering the schema parser, generator, all four exporters, and the CLI wiring. No separate services or components to split out. Approve

Stage 2.9: Delivery Planning (delivery agent)

Claude Code: One Bolt, one Unit. The walking skeleton — the first slice we'll build and gate — is: parse a schema, generate rows, export CSV only. JSON, Parquet, and SQL export follow as the rest of the same Bolt, once the skeleton proves the core path works end to end. Written to delivery-planning.md. Approve

Behind the scenes: Progress: 16/33 overall | 8/8 INCEPTION stages complete (Reverse Engineering excluded from scope). Everything above now lives under aidlc/spaces/default/intents/260909-synthetic-data-generator/inception/. Construction starts from exactly this plan — it doesn't re-derive the unit or the walking skeleton, it builds what Delivery Planning just described.

‹ Back to: Part 2 — Ideation Phase Continue to: Part 4 — Construction Phase