Case Study, Part 5 of 5: Operation Phase

Where we are: synth-data is built and tested. This is the phase most tutorials skip entirely — because most demos pick a scope that skips it (mvp, poc). We chose feature, so all 7 Operation stages actually run: deploying it, watching it, and closing the loop back to the next round of work.

In plain English: Building something is only half the job — Operation is the other half: actually shipping it to real users, setting up a plan for when something breaks, checking it actually meets the goals we set back in Ideation, and capturing what to improve next. Most tutorials stop right after the code works; this page is what happens after that.

Every prompt we actually type is highlighted like this.

Stage 4.1: Deployment Pipeline (pipeline-deploy agent)

Claude Code: Building on Construction's CI workflow: on a version tag push (v0.1.0), a release job builds the wheel and sdist, then publishes to PyPI using a repository secret (PYPI_API_TOKEN). Written to deployment-pipeline.md as .github/workflows/release.yml. Approve

Stage 4.2: Environment Provisioning (aws-platform agent)

Claude Code: No servers to provision — the "environment" here is entirely: the PyPI project name synth-data reserved, PYPI_API_TOKEN added as a GitHub repo secret, and CHANGELOG.md started so every release has a record. All three done manually, once, outside the CLI. Approve

Stage 4.3: Deployment Execution (pipeline-deploy agent)

Claude Code: Ready to cut the first release: tag v0.1.0, push it, let the pipeline from Stage 4.1 run.

$ git tag v0.1.0 && git push --tags
▸ Approve execution? [Yes / Request Changes]

You: Approve

release.yml: build ✓  publish to PyPI ✓
$ pip install synth-data  (clean venv)  →  installed, `synth-data --version` → 0.1.0

Stage 4.4: Observability Setup (operations agent)

Claude Code: No telemetry by default — a CLI silently phoning home is exactly the kind of thing this tool's own users would object to. Instead: every error prints the failing schema line and column, not a raw stack trace; --version and --verbose flags exist for bug reports; GitHub Issues is the stated feedback channel in README.md. Written to observability-setup.md. Approve

Stage 4.5: Incident Response (operations agent)

Claude Code: A short runbook for the one realistic failure mode — a published version silently produces malformed output for one format. Response: (1) confirm and reproduce against the reported schema, (2) yank the broken version's install eligibility from PyPI (mark it as a pre-release / yanked, which pip refuses by default) while keeping it downloadable for forensics, (3) ship a patch release, (4) note it in CHANGELOG.md. Written to RUNBOOK.md. Approve

Stage 4.6: Performance Validation (quality agent)

This closes the loop back to the success criteria we gave Claude Code all the way back in Intent Capture (Part 2):

Claude Code: Benchmarked against the MVP success criteria — "10,000 rows in under a few seconds" — on a 7-column schema: 0.8s. Also checked the NFR from Construction: memory stays flat around 40MB at 100,000 rows, confirming the batched-generator design held up under real load, not just in theory. Written to performance-validation.md. Approve

Stage 4.7: Feedback & Optimization (product agent)

The final stage. A week of real use later:

Claude Code: Two GitHub issues came in: a request for nested/repeated schema blocks, and a request for a --seed flag for reproducible output. Neither is urgent enough to reopen this intent — they're written up as candidates for the next intent, not squeezed into this one. Written to feedback-optimization.md.

▸ [Approve — Complete Workflow / Request Changes]

You: Approve

Behind the scenes: A PHASE_VERIFIED event and a verification report land in the intent's verification/ folder — a phase-boundary check that everything Operation was supposed to produce, actually exists. Then WORKFLOW_COMPLETED fires. Those two feature requests don't vanish: they're exactly the kind of input that starts the next /aidlc prompt — a new intent, in the same space, that can read this one's codekb/ and memory/ instead of starting from zero.

Workflow Complete

WORKFLOW_COMPLETED
32 of 33 stages ran · 1 skipped (Reverse Engineering — no code existed yet)
aidlc-state.md: every active stage [x]

synth-data exists, tested, published to PyPI, with a runbook and a benchmark on record. The full history — every question, answer, plan, and decision across all five phases — sits under aidlc/spaces/default/intents/260909-synthetic-data-generator/, committed to git like any other project file.

Behind the Scenes: Every Hook That Ran, In One Table

The Whole Session, Just the Prompts

1. Using AI-DLC, I want to build a synthetic data generator. Please read vision.md and technical-environment.md, then begin the AI-DLC workflow.
2. Yes (scope confirmation)
3. 1 (Guide Me)
4. (answers to whatever it asks, inline)
5. We've answered your questions. Please re-read the file and continue. (repeated per questions file)
6. Approve (repeated at every gate — roughly 30 times across all 5 phases)
7. Approve Plan (once, before Code Generation)

Almost the entire session is five kinds of prompt, repeated across all five phases. The actual work — reading what comes back before typing "Approve" — is where the thinking happens; typing is not.

What's Next

That's the real engine, end to end, all five phases: the same two-button rhythm from Lesson 05's "Working With It, Day to Day," but now backed by real stage files, real hooks, and a real audit trail — including the Operation phase most walkthroughs never show.

‹ Back to: Part 4 — Construction Phase Restart from: Part 1 — Setup & Kickoff