Below is the real shape of an AI SDLC run, shown on a single task: PRJ-1042 — audit events on session expiry. Including the moment when verification sends the work back — because that is exactly when you can see the process working. The names are examples; the mechanics are real.
Everything starts with a need expressed in plain human terms — no specification, no jargon. The process assigns it an identifier, and from that moment on every artifact will be linked to PRJ-1042.
“The auditor asked whether our logs show the moment a user session expired on its own. Today they don't. We need an audit event on every session expiry — with the reason.”
The Analyst Agent turns the need into verifiable acceptance criteria. The analysis gate lets through only requirements that can be verified.
Acceptance criteria:
The change is small, but it touches the audit path — so the architect marks it with a security flag: at the end of verification an additional verdict from the Security Agent will be required.
Decision: we extend the existing audit event emitter with two new event types — no schema changes, no new dependencies. The change touches the audit component → adding the sec-verify-required requirement.
Before the first line of code is written, a plan is produced: which files, which tests, what is out of scope. The plan is a contract — if it stops matching reality during the work, the work returns to this stage.
Plan: 2 production files (audit emitter, session lifecycle handling), 1 test file. Tests: unit tests for both expiry reasons + an audit stream integration test. Out of scope: log retention, export, UI.
Implementation on an isolated branch. The proof of completion is not the agent's claim, but green tests and a PR bound to the exact code revision.
The QA Agent tests the edge cases from the acceptance criteria — and finds a gap: a session extended just before the maximum lifetime limit expires without an audit event. The verdict is pinned to the exact revision and the work returns to development. There is no arguing with the gate.
Scenario: session extended 5 s before reaching the maximum lifetime limit → the session expires via the max_lifetime path, and the audit event is not emitted. Violates criterion 2.
The fix lands on the same branch — a new revision is created, so all verdicts must be issued again for the new revision. Old evidence does not carry over. This time: a complete set.
All 4 criteria met, including the extension-before-limit scenario. Tests: 218 passing, 0 failing.
Events contain no sensitive data; format consistent with the audit stream; no new dependencies.
This is the complete evidence bundle the merge gate will see in the next step — every line pinned to the same revision:
Every one of those lines follows the same single rule. Let us take it apart:
The merge is executed exclusively by the gate script — no agent is allowed to merge the PR manually. The script checks the complete evidence set for the exact revision and only then merges.
The result comes back to the human in the language of the goal, not the technology. Only the operator's acceptance closes the task — and the retrospective turns the return from step 06 into a lasting process improvement.
“I checked on the environment: expirations are visible in the audit with reasons. The auditor has what they asked for. Accepted.”
Lesson: “just before the limit” scenarios added to the standing QA checklist for session lifecycle changes.
A verification return is not a process failure — it is the process working. The gap was found by a machine before deployment, fixed within hours, and the knowledge from it stayed in the process. Without gates, the same gap would have surfaced in an audit.