Extensions — Opting Into Extra Rules
Everything so far has been the core AI-DLC workflow — the same for every project, every team, every organization. But not every project has the same needs. A banking system and a two-teacher classroom tool shouldn't be held to identical security requirements. Extensions are how AI-DLC handles that difference: optional rule packs you can layer on top of the core workflow, enforced only when you say yes to them.
How an Extension Actually Works
Each extension is two small files living together:
- A rules file (for example,
security-baseline.md) — the actual requirements. - An opt-in file (
security-baseline.opt-in.md) — one question, asked once, during Requirements Analysis.
At the very start of a workflow, Robo scans for these opt-in files — cheaply, without loading the full rules yet. Then, during Requirements Analysis, it asks you directly. Here's the real question AI-DLC asks for its built-in security extension, word for word:
## Question: Security Extensions
Should security extension rules be enforced for this project?
A) Yes — enforce all SECURITY rules as blocking constraints
(recommended for production-grade applications)
B) No — skip all SECURITY rules
(suitable for PoCs, prototypes, and experimental projects)
X) Other (please describe after [Answer]: tag below)
[Answer]:
Say yes, and the full rules file loads and applies for the rest of the project. Say no, and it's never loaded at all — not "loaded but ignored," genuinely never read, so it costs nothing. Your answer gets recorded in aidlc-state.md, so it's remembered for the whole life of the project, not just this session.
What "Enforced" Actually Means
Once an extension is on, its rules aren't suggestions. At every relevant stage, Robo checks compliance before letting you approve that stage. Here are three of the real rules from AI-DLC's built-in security extension:
SECURITY-01 — Encryption at Rest and in Transit Every data store must have encryption at rest enabled, and encryption in transit enforced (TLS 1.2+) for all data moving in and out of it.
SECURITY-02 — Access Logging on Network Intermediaries Every load balancer, API gateway, and CDN handling external traffic must have access logging enabled.
SECURITY-03 — Application-Level Logging Every deployed component must log through a structured logging framework, routed to a centralized log service — and must never log passwords, tokens, or other sensitive data.
If a design doesn't meet one of these, Robo won't offer you "Continue to Next Stage" at all — only "Request Changes," with the specific rule and what needs to change, logged in audit.md. You can't accidentally skip past it.
There's a sensible exception: if a rule genuinely doesn't apply — SECURITY-01 when a project has no data store at all — it's marked N/A, not treated as a failure.
The Built-In Extensions
Three ship with AI-DLC today:
| Extension | What It Enforces |
|---|---|
| Security Baseline | Encryption, logging, and other production security basics |
| Property-Based Testing | Testing that checks a property holds across many generated inputs, not just a handful of hand-picked examples |
| Resiliency Baseline | Retry logic, timeouts, and graceful degradation for production systems |
More get added over time — these aren't the only ones an organization could define.
Would Ms. Sharma's Project Need These?
Genuinely, no — and that's a useful example in itself. Her app runs locally on one laptop, stores no one's data but a list of book titles, and has exactly one user. Answering B to the security question isn't cutting a corner; it's an honest match between the rule's purpose (protecting real infrastructure handling real data) and a project that has neither. This is the same "adaptive, not one-size-fits-all" idea from Lesson 1, just applied to rules instead of stages — the methodology scales its own strictness up or down to match what's actually at stake.
A production system handling real students' personal information, on the other hand, is exactly the case these rules exist for — and there, saying A is the right, deliberate choice.
Building Your Own
Organizations can add their own categories the same way — a compliance extension, a performance extension, an internal API style guide — following the same two-file pattern: a rules file with numbered, verifiable rules, and a matching opt-in file. Every rule ID needs to be unique across everything loaded, since they show up together in audit.md's compliance summaries. Skip the opt-in file entirely, and the extension is simply always on, with no opt-out — appropriate for a rule your organization considers genuinely non-negotiable.
One Piece Left
Nine lessons of concepts and mechanics — the real Inception stages, brownfield, extensions, all of it. What's still missing is seeing them run together, uninterrupted, in one real tool, on one real project. That's the final lesson.
What's Next
Continue to: Case Study — Building a URL Shortener With Cursor