Software lifecycle
The whole lifecycle, one phase at a time
A coding agent given a brief will start writing code within the minute. What it skips is everything that makes the code correct later: who the actors are, which use cases exist, what the calculations actually specify, where the subsystem boundaries sit, and which of those decisions a person was supposed to make. This package puts that work back in, as ten numbered phases the engine runs in order and will not let the agent jump over.
Each phase reads the files the previous one wrote and ends in a document you sign off. Requirements become use cases with ids; the ids get allocated to subsystems; the subsystems get built in dependency order, each behind a 95% branch-coverage gate and a test matrix that checks every allocated requirement is actually covered; the built subsystems get composed into one runnable application and proven by system tests. Afterwards, changes go through a change workflow that re-runs only the phases the change touches — so the documentation still describes the system a year later.
It works from both ends. A codebase that already exists starts at phase 0, which reconstructs the same baseline from the code with a file and line behind every record and a confidence level on each one — and stops for your answers on everything it could only assume.
Full SDLC
Included
Pro and up · included with your license
Teams who want an agent to build a system they will still be able to change in a year, and anyone inheriting a codebase with no documentation who needs a baseline before touching it. It is the largest package: it needs python3 3.8+ and git on the agent's machine, and it expects a person at the sign-off gates.
What runs
The workflows inside
Each heading links to the documentation for those workflows: how to start one, what it takes as input, where it stops for you, and what it leaves behind.
SDLC 1 Requirements
Brief to baseline: system boundary, actors, domains, then one child run per actor writing that actor's use cases, a conceptual data model, business rules — including every calculation, with units, algorithm, rounding and a worked example — derived functional requirements, NFRs and a consistency check. Bounded at two clarification rounds; ends in human sign-off.
SDLC 2 Solution Design and SDLC 3 Style Guide
A numbered, justified technology choice for every layer the system actually needs, recorded with the alternatives it rejected. Then the style guide — tone, colour, typography, layout, iconography, components — backed by a design-tokens.json that a Python helper validates for WCAG contrast and scale sanity, and rendered as live examples on the documentation site.
SDLC 4 System Decomposition
Divides the system completely into subsystems, as many levels as it needs, allocating every domain, use case and requirement to a leaf — and nothing more: no interfaces, no schemas, no per-subsystem technology choices. Reports anything allocated nowhere, and any dependency cycle between leaves.
SDLC 5 Development and Test
Builds every leaf subsystem in dependency order — UX specification, code against the binding architecture, unit tests behind a 95% branch-coverage gate, subsystem tests checked as a matrix against the full allocation, and a UI inspection of the built interface. Then the composition root, then system tests over every use case end to end, with bounded fix rounds per failing subsystem.
SDLC 0 Reverse Engineer and SDLC Test Retrofit
For code that already ships: recovers the whole baseline from the source — use cases, conceptual model, business rules, as-built requirements, architecture and decomposition — with file and line evidence and a confidence level per record, mechanically verified. Then retrofits tests: characterization tests that pin current behaviour, risk-ordered by churn and size, under a ratchet that raises coverage every pass instead of failing an unreachable threshold.
SDLC 6 Change Request and SDLC Bug Fix
A change is assessed through the traceability chain, gated on its impact, and then re-runs only the phases it touches before rebuilding only the subsystems it affects. A bug is reproduced by a failing test before any code is edited, then triaged: a true defect is fixed here, a spec gap is routed to the change workflow instead of being decided silently in code.
SDLC 7, 8 and 9 — Deployment
A complete local environment for human testing, with each external service stubbed or wired live per run; the hosting environments as infrastructure-as-code behind a plan and a monthly-cost gate; and versioned releases promoted staging to production with health checks, a smoke proof, a human production gate and a first-class rollback path.
How a run goes
Step by step, in the order the engine enforces
- 1
Start at phase 1 — or phase 0
A new system starts from a brief. An existing one starts from its code, and phase 0 reconstructs the same baseline before the forward phases touch anything. The source tree is never modified.
- 2
Documentation and development stay apart
Every phase takes a documentation workspace and, from phase 5, a development root that must not sit inside it. Documentation is written by phases 0 to 4 and only read afterwards.
- 3
Sign off, phase by phase
Each phase ends in an agent review that loops on findings, then a human gate. The engine stops and waits; your agent puts the question to you in your own session. There is no separate approval screen.
- 4
Build in dependency order, prove at every level
One subsystem at a time: unit coverage at 95% of branches, a subsystem test matrix over its allocated use cases and requirements, then the composition root and the system suite. Coverage figures come from the project's own reports, not from a claim.
- 5
Review the documentation like a document
The generated site carries a comment toolbar. Comments export to a file, get triaged into content changes, stakeholder questions or declined notes, are applied to the sources with their ids intact, and the site is regenerated.
- 6
Change it through the change workflow
After the first build, changes and bugs enter through their own workflows. They re-run the impacted phases only, and close a numbered change or bug record — which is also what the release notes are built from.
What you get
At the end of a run
- ✓A documentation workspace: requirements, use cases, conceptual model, business rules, NFRs, solution architecture, style guide and decomposition, cross-linked by stable ids
- ✓A generated documentation site with every id linked to where it is defined, mermaid diagrams, rendered style examples and a comment toolbar for review
- ✓A composed, runnable application with per-subsystem unit and subsystem suites, a system-level suite over every use case, and the coverage figures from the project's own reports
- ✓Numbered change, bug and release records — and release notes built from them rather than from the git log
Read next
Related packages
- Boy Scout Coding →
A code change by your coding agent: scoped, designed, approved at two human gates, reviewed from three angles, covered by tests — and the code left cleaner.
- Code Quality →
Run a full ISO/IEC 5055 and Clean Code assessment of any codebase with your coding agent, every check its own verified step. Included with every license.