Full development lifecycle. Human + AI
>by Roman Tsyupryk
|
>
This text is just my thoughts out loud. I'm only a human being trying to analyze current information and imagine what might happen in the future. My thoughts could be completely wrong or might be just "noise" or they could be food for brainstorming about "what if..." scenarios.
Stay tuned for the second part → Full Development Lifecycle: AI-Only, as a Living System
Roles
| Abbrev | Role | AI Agent | AI Agent Role |
|---|---|---|---|
| PM | Product Manager | PMAIA | PM AI Agent |
| TLA | Tech Lead / Architect | TLAAIA | TLA AI Agent |
| SWE | Software Engineer | SWEAIA | SWE AI Agent |
| QAE | QA Engineer | QAAIA | QA AI Agent |
| SEC | Security Engineer | SECAIA | Security AI Agent |
| DE | DevOps Engineer | DEAIA | DevOps AI Agent |
| SRE | Site Reliability Eng. | SREAIA | SRE AI Agent |
Concepts & Artifacts
| Term | Full Name | Description |
|---|---|---|
| SDD | Spec-Driven Development | The methodology this workflow follows at the spec-anchored maturity level: the Spec is written before code and kept in sync with the implementation throughout the feature's life (Böckeler's model: spec-first / spec-anchored / spec-as-source; spec-as-source deliberately not adopted). |
| Constitution | — | Persistent, project-level engineering principles and constraints, owned by TLA. References the pattern library, carries the anti-pattern denylist, and is periodically re-reviewed. Every Spec and ADR must comply with it. |
| Spec | Specification | The unified artifact from the Specify step — what/why (formerly PRD) + how (formerly TDD/SDD) in one structured, testable document. Single source of truth for ADRs, Tasks, and Code. |
| Micro-Spec | — | One-paragraph spec (what + why + acceptance criteria) for SMALL changes on the fast path. |
| ADR | Architecture Decision Record | A recorded significant decision. v7 uses three weight tiers — see Y-statement, Nygard, MADR below. Statuses: rfc → proposed → accepted / rejected / deprecated / superseded by ADR-NNNN. Numbered NNNN-title-with-dashes.md in docs/decisions/; numbers never reused; superseded records preserved. |
| Y-statement | — | Zimmermann's compact one-paragraph decision record (context, concern, chosen option, alternatives, consequences, accepted downsides). The smallest ADR tier; may live inline in the Spec or in a code comment. |
| Nygard ADR | — | Five-section template: Title / Context / Decision ("We will…") / Status / Consequences. The mid-weight ADR tier. |
| MADR | Markdown Any Decision Records (v4.0) | The heavyweight ADR tier: YAML front matter (status, date, decision-makers, consulted, informed), Decision Drivers, Considered Options with "Good/Bad/Neutral, because…" analysis, and a Confirmation section defining how compliance is verified. |
| RFC | Request for Comments | The open-comment sub-status a mid/major ADR starts in, with an explicit response-by deadline, before narrow approval. |
| Data Model / API Spec | data-model.md / api-spec.json |
Machine-readable Plan-step artifacts (OpenAPI-style contract + entity model) that the Spec Compliance Check can diff automatically. |
| Implementation Plan (Tasks) | — | Ordered, component-by-component build plan from Final Spec + ADRs. In v7, each task maps to one reviewable PR (≤ ~105 changed lines, < 24h branch). |
| Spec Compliance Check | — | CI/CD gate verifying the implementation still satisfies the Spec's acceptance criteria and Plan artifacts (api-spec.json, data-model.md); drift raised as a Finding, never auto-fixed. Checks behavior. |
| Architecture Compliance Check | — | CI/CD gate running ArchUnit / ArchUnitTS-style structural rules derived from the Constitution and ADR Confirmation sections (layering, banned imports, cyclic deps, coupling metrics). Checks structure. |
| Finding | — | Structured ticket raised by any workflow for an issue it can't resolve locally; routed via the Cross-Workflow Feedback Protocol. |
| SAST / DAST | Static / Dynamic Application Security Testing | Code-level vs. running-app security scanning. |
| IaC | Infrastructure as Code | Versioned, code-defined infrastructure. |
| SLO | Service Level Objective | Target reliability/performance threshold monitored by SRE post-deploy. |
| CVE | Common Vulnerabilities and Exposures | Publicly catalogued vulnerability, typically in a dependency. |
| KPI | Key Performance Indicator | Business metric tracked post-deploy to catch regressions invisible to technical metrics. |
Workflow Map
(Constitution is a one-time prerequisite, not part of the per-feature flow — see Development Workflow. Graph = Variant A; see note at top.)
┌─────────────┐
│ Development │ ← primary source of truth
│ Workflow │ for all other workflows
└──────┬──────┘
│ PR merged → Deployed to Staging
↓
┌───────────────────────┐
│ CI/CD Workflow │
└───────────┬───────────┘
│ staging build passes
↓
┌────────────────┼────────────────┐
↓ ↓ ↓
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ QA Workflow │ │ Sec Workflow │ │DevOps Workflow│
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
↓ passes ↓ passes ↓ ready
└────────────────┼────────────────┘
↓ all three signed off
┌───────────────────┐
│ SRE Workflow │
└─────────┬─────────┘
↓ clears monitoring window
Released to Production ✅
⚠ If any workflow detects an issue:
- Cross-Workflow Feedback Protocol fires (see bottom)
- Finding routed back to Development Workflow
- Fix propagates forward through all downstream workflows again
Development Workflow
Steps: Constitution (one-time prerequisite) → Change-Size Triage → Specify → Plan (ADRs) → Tasks (Implementation Plan) → Implement (Code) → Pull Request
Constitution *(one-time, periodically re-reviewed)*
TLA drafts Constitution with TLAAIA:
- core architectural principles
(SOLID / GRASP / DRY / KISS / YAGNI / LoD)
- non-negotiable constraints (security, compliance, style)
- technology choices and standards
- DEFAULT PATTERN CHOICES, citing the pattern library
(information-technology/patterns/) — e.g. "all
cross-service calls use Retry + Circuit Breaker"
- ANTI-PATTERN DENYLIST (God Object, Golden Hammer,
Boat Anchor, Lava Flow, Retry Storm, ...)
- the structural rules that seed the Architecture
Compliance Check (layering, banned imports,
coupling thresholds)
↓
PM + SEC + DE + SRE review
(cross-functional, since principles are cross-cutting)
↓
Constitution approved ✅
↓
── PERIODIC REVIEW (e.g. quarterly, or when a 3rd ADR
in a row overrides the same default): TLA re-examines
whether default pattern choices still fit — the
Constitution's own guard against becoming a
Golden Hammer ──
↓
Referenced by every Spec and ADR from here on
Change-Size Triage
PM + TLA classify the incoming change
↓
┌─────────────────────────────────────┐
│ SMALL │
│ - bug fix, copy change, minor │
│ tweak, no new architectural │
│ decisions expected │
│ → Micro-Spec fast path │
│ (skip Specify/Plan ceremony) │
│ │
│ STANDARD │
│ - new feature, behavior change, │
│ or anything with unclear scope │
│ → full Specify → Plan → Tasks │
└─────────────────────────────────────┘
↓
If SMALL, but TLAAIA later flags an architectural
implication during Micro-Spec review:
→ escalate to STANDARD
↓
Triage complete ✅
Micro-Spec (SMALL changes only)
SWE + SWEAIA draft a one-paragraph Micro-Spec:
- what is changing
- why
- acceptance criteria
↓
TLAAIA reviews against the Constitution
↓
Architectural implication found?
↓ YES ↓ NO
escalate to STANDARD Micro-Spec approved ✅
→ go to Specify ↓
→ Tasks step (Plan/ADRs
skipped; a decision worth
recording still gets a
Y-statement inline)
Specify
PMAIA + TLAAIA draft the PROBLEM STATEMENT only
(what hurts, for whom, why now — no solutions yet)
↓
PM validates the problem with Stakeholders / user research
── features are NOT drafted until the problem is
confirmed real and worth solving ──
↓
PMAIA + TLAAIA extend the Spec with the solution half
(from the validated problem + Constitution)
↓
┌─────────────────────────────────────┐
│ PM + TLA brainstorm with │
│ PMAIA + TLAAIA to discover: │
│ - gaps, ambiguities │
│ - missing edge cases │
│ - contradictions (incl. with │
│ the Constitution) │
│ - unstated assumptions │
│ - unclear success metrics │
│ - architectural gaps / concerns │
└─────────────────────────────────────┘
↓
PM + TLA talk to Stakeholders to fill
missing information
↓
Spec updated
↓
── repeat until PMAIA, TLAAIA, PM, TLA, or
Stakeholders find nothing ──
── escalate to Stakeholders after 3 unresolved loops ──
↓
Final Spec ✅
Plan (ADRs)
TLAAIA scans the Final Spec and identifies
all decision points that need a record
↓
┌─────────────────────────────────────────────┐
│ TLAAIA proposes a WEIGHT TIER per decision: │
│ │
│ Y-STATEMENT — small but real decision; │
│ one structured paragraph, may live │
│ inline in the Spec │
│ NYGARD — mid-weight; own numbered file │
│ (Title/Context/Decision/Status/ │
│ Consequences) │
│ MADR-FULL — major decision; YAML front │
│ matter (decision-makers / consulted / │
│ informed), Decision Drivers, options │
│ with Good/Bad/Neutral-because analysis, │
│ and a CONFIRMATION section stating how │
│ compliance will be verified (feeds the │
│ Architecture Compliance Check) │
└─────────────────────────────────────────────┘
↓
TLA reviews and validates the list + tiers
↓
── one refinement loop per decision point ──
↓
TLAAIA drafts the record from Spec context
↓
Mid/major tiers open as RFC:
- published for open comment, anyone may respond
- explicit response-by deadline
↓
┌─────────────────────────────────────┐
│ TLA brainstorms │
│ with TLAAIA to discover: │
│ - are all options considered? │
│ - are trade-offs complete? │
│ - is the context well defined? │
│ - are consequences realistic? │
│ - does it contradict other ADRs? │
│ - does it comply with the │
│ Constitution? │
│ - does it cite the pattern library │
│ where a known pattern applies? │
│ - are assumptions explicit? │
│ - is the rationale strong enough? │
└─────────────────────────────────────┘
↓
TLA filters TLAAIA findings + RFC comments
↓
TLA + TLAAIA improve the record
↓
If new information is needed:
communicate with PM or Stakeholders
↓
Record updated
↓
── repeat until resolved ──
── escalate to Stakeholders after 3 unresolved loops ──
↓
NARROW APPROVAL — not full-team:
TLA + the role owning the affected domain
(e.g. SEC for a security-relevant ADR,
DE/SRE for an infra-relevant one)
↓
ADR accepted ✅
(rejected RFCs are kept with status "rejected" —
a documented no is institutional memory too)
↓
── repeat for next decision point until all done ──
↓
SWEAIA + TLAAIA derive machine-readable artifacts:
- data-model.md (entities, relationships)
- api-spec.json (OpenAPI-style contract)
↓
┌──────────────────────────────────────────────┐
│ TLAAIA runs CROSS-ARTIFACT consistency check │
│ (Spec ↔ ADRs ↔ api-spec/data-model): │
│ - do any decisions contradict each other? │
│ - or contradict the Spec? │
│ - circular dependencies? │
│ - invalidated assumptions? │
│ - still compliant with Constitution? │
└──────────────────────────────────────────────┘
↓
TLA resolves any conflicts found
↓
Plan consistent ✅
Tasks (Implementation Plan)
SWEAIA generates implementation plan
from Final Spec + ADRs + api-spec.json + data-model.md
↓
┌─────────────────────────────────────────────┐
│ SIZE RULE — every task maps to ONE │
│ reviewable PR: │
│ - guideline ≤ ~105 changed lines │
│ - branch lifetime < 24h │
│ Larger work is decomposed via: │
│ - stacked PRs (chained dependent branches) │
│ - refactor-PR then feature-PR │
│ - shippable steps behind a feature flag │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ SWE brainstorms │
│ with SWEAIA to discover: │
│ - are all components covered? │
│ - correct implementation order? │
│ - missing integration points? │
│ - test coverage gaps? │
│ - contradictions with ADRs? │
│ - any task too big for one PR? │
│ - deployment / infra concerns? │
└─────────────────────────────────────┘
↓
SWE filters SWEAIA findings
↓
SWE + SWEAIA improve implementation plan
↓
If new information is needed:
communicate with TLA, PM, or Stakeholders
↓
Implementation plan updated
↓
── repeat until resolved ──
── escalate to TLA after 3 unresolved loops ──
↓
Final Implementation Plan ✅
Implement (Code)
SWEAIA writes code following
Final Implementation Plan + Spec + ADRs
↓
┌─────────────────────────────────────────────┐
│ SWEAIA + TLAAIA review code: │
│ - matches Spec / api-spec.json contracts? │
│ - respects all ADR decisions? │
│ - complies with the Constitution? │
│ - ANTI-PATTERN CHECK against the denylist: │
│ God Object, Golden Hammer, Boat Anchor, │
│ Lava Flow, Spaghetti Code, Retry Storm... │
│ - test coverage sufficient? │
│ - no logic gaps or edge cases? │
│ - naming clarity? │
│ - comment quality? │
│ - style-guide compliance? │
│ - documentation updated? │
└─────────────────────────────────────────────┘
↓
SWEAIA fixes findings
↓
── repeat until SWEAIA and TLAAIA find nothing more to resolve ──
↓
Did implementation reveal a flaw in an upstream document?
↓
┌────YES─────────────────────┐
↓ ↓
Flaw in ADR? Flaw in Spec?
↓ ↓
TLA + TLAAIA amend the TLA + PM (with their AIAs)
ADR; old ADR → resolve it and update
"superseded"; new ADR the Spec
created (number never
reused)
↓ ↓
└──── upstream doc updated ✅ ────┘
↓
re-validate impacted ADRs,
api-spec/data-model, and
implementation plan steps
↓
resume coding
↓ (no upstream flaw)
Code complete ✅
Pull Request
SWEAIA opens Pull Request
(one task = one PR; oversized PRs are
sent back to the Tasks step for decomposition)
↓
SWE performs human peer review
(reads the diff, checks logic correctness,
catches blind spots shared by AI agents —
tractable because PRs are small by rule)
↓
SWE approves or requests changes from SWEAIA
↓
TLAAIA reviews PR against Spec + ADRs
↓
PMAIA validates PR against Spec acceptance criteria
↓
TLA approves (technical sign-off) ✅
↓
PM approves (business sign-off) ✅
↓
PR merged → Deployed to Staging ✅
↓
→ CI/CD Workflow begins
Sign-off withheld (TLA or PM)?
→ raise a Finding against the relevant
Spec / Plan / Tasks step
→ same bounded-loop pattern as other Development
sub-steps (escalate after 3 unresolved loops)
→ re-enter this step once resolved
CI/CD Workflow
Steps: Build → Architecture Compliance Check → Automated Tests → Spec Compliance Check → Deploy to Staging
DEAIA triggers pipeline on PR merge
↓
┌─────────────────────────────────────┐
│ Build step │
│ - compile / lint / type-check │
│ - dependency audit │
│ - container image build │
└─────────────────────────────────────┘
↓
Build fails?
→ DEAIA + SWEAIA diagnose
→ SWE fixes, new commit, pipeline re-runs
→ if not resolved in 2 cycles: escalate to TLA
↓
┌─────────────────────────────────────┐
│ Architecture Compliance Check │
│ (STRUCTURE — ArchUnit/ArchUnitTS) │
│ - layering / dependency direction │
│ - banned imports │
│ - cyclic dependencies │
│ - coupling / cohesion thresholds │
│ Rules come from the Constitution │
│ + ADR Confirmation sections │
│ (cheap static checks → run early) │
└─────────────────────────────────────┘
↓
Structural violation?
→ TLAAIA classifies:
- code violates an accepted rule
→ SWE fixes (like a failing test)
- the rule itself is outdated
→ Finding to Plan (ADR) step —
supersede the ADR, then update the rule
↓
┌─────────────────────────────────────┐
│ Automated Tests │
│ - unit, integration, contract │
│ - regression suite │
│ - performance baseline check │
└─────────────────────────────────────┘
↓
Test failures?
→ DEAIA classifies failure:
- flaky test → retry once, then flag to QAE
- regression → Cross-Workflow Feedback to Development
- env/infra issue → DevOps Workflow
↓
┌─────────────────────────────────────┐
│ Spec Compliance Check │
│ (BEHAVIOR) │
│ - implementation still satisfies │
│ the Spec's acceptance criteria? │
│ - live API diffed against │
│ api-spec.json (automatable); │
│ schema against data-model.md │
│ - flags drift, does NOT auto-fix │
│ or regenerate code │
└─────────────────────────────────────┘
↓
Drift detected?
→ DEAIA + TLAAIA classify:
- Spec/Plan artifact is stale (code is right)
→ Cross-Workflow Feedback to
Development (Specify or Plan step)
- code diverged from Spec (code is wrong)
→ Cross-Workflow Feedback to
Development (Implement step)
↓
┌─────────────────────────────────────┐
│ Deploy to Staging │
│ - blue/green or canary deploy │
│ - smoke tests post-deploy │
│ - health checks │
└─────────────────────────────────────┘
↓
Staging deploy fails?
→ DEAIA + SREAIA diagnose
→ if infra: DevOps Workflow
→ if code: Cross-Workflow Feedback to Development
↓
Staging deployment healthy ✅
↓
→ QA, Security, and DevOps Workflows begin (in parallel)
QA Workflow
Steps: Test Plan → Test Execution → Bug Triage
QAAIA generates test plan from the Spec + api-spec.json
↓
QAE reviews and enriches test plan
(covers happy paths, edge cases, regression)
↓
Test plan approved ✅
↓
┌─────────────────────────────────────┐
│ QAAIA executes tests: │
│ - functional testing │
│ - exploratory testing │
│ - performance / load tests │
│ - accessibility checks │
│ - regression suite │
└─────────────────────────────────────┘
↓
QAE reviews QAAIA test results
↓
Issues found?
↓ YES
┌─────────────────────────────────────────────────────┐
│ QAAIA classifies each finding by severity: │
│ │
│ CRITICAL / HIGH → defect in logic or design │
│ MEDIUM → unexpected behaviour, UX issue │
│ LOW → cosmetic, minor edge case │
└─────────────────────────────────────────────────────┘
↓
QAE validates classification
↓
┌─────────────────────────────────────────────────────┐
│ Route finding by severity: │
│ │
│ CRITICAL / HIGH │
│ → Cross-Workflow Feedback to Development │
│ (see protocol below) │
│ → Development re-entry point depends on root: │
│ - code bug → Implement step │
│ - design flaw → Spec or Plan (ADR) step │
│ - requirements gap → Specify step │
│ │
│ MEDIUM │
│ → SWEAIA fixes, SWE reviews, new PR │
│ → QA re-tests the specific area │
│ │
│ LOW │
│ → logged as tech-debt ticket │
│ → no workflow re-entry required │
└─────────────────────────────────────────────────────┘
↓
(MEDIUM-severity fix PRs re-enter the CI/CD Workflow
like any other PR before QA re-tests the area)
↓
All issues resolved or accepted ✅
↓
QA sign-off ✅
↓
recorded — SRE Workflow begins once QA + Security + DevOps
have all signed off (see Workflow Map)
Security Workflow
Steps: Threat Model Review → SAST/DAST → Pen Test Triage
SECAIA loads the Spec + ADRs to review threat model
↓
┌─────────────────────────────────────┐
│ SECAIA surfaces: │
│ - attack surface changes │
│ - missing auth / authz controls │
│ - data exposure risks │
│ - dependency CVEs │
│ - insecure design patterns │
└─────────────────────────────────────┘
↓
SEC reviews SECAIA findings
↓
SAST / DAST scans run on staging build
↓
SEC + SECAIA triage scan results
↓
Vulnerabilities found?
↓ YES
┌─────────────────────────────────────────────────────┐
│ SECAIA classifies each finding: │
│ │
│ CRITICAL / HIGH → exploitable, data at risk │
│ MEDIUM → hardening gap, best-practice │
│ LOW / INFO → acceptable risk or false pos. │
└─────────────────────────────────────────────────────┘
↓
SEC validates classification
↓
┌─────────────────────────────────────────────────────┐
│ Route finding by severity: │
│ │
│ CRITICAL / HIGH │
│ → Cross-Workflow Feedback to Development │
│ (see protocol below) │
│ → Development re-entry point depends on root: │
│ - code-level vuln → Implement step │
│ - insecure design → Spec or Plan (ADR) step │
│ - requirements gap → Specify step │
│ → staging deploy BLOCKED until resolved │
│ │
│ MEDIUM │
│ → SWEAIA applies fix, SWE reviews, new PR │
│ → SEC re-scans the affected area │
│ │
│ LOW / INFO │
│ → documented in security log │
│ → accepted risk recorded in an ADR (MADR tier, │
│ since accepted risks need decision-makers │
│ named) if architectural │
└─────────────────────────────────────────────────────┘
↓
(MEDIUM-severity fix PRs re-enter the CI/CD Workflow
like any other PR before SEC re-scans the area)
↓
All critical / high findings resolved ✅
↓
Security sign-off ✅
↓
recorded — SRE Workflow begins once QA + Security + DevOps
have all signed off (see Workflow Map)
DevOps Workflow
Steps: Infrastructure Provisioning → Config Management → Observability
(runs in parallel with QA and Security, or triggered by CI/CD issues)
DEAIA provisions / updates infrastructure
from Spec + ADRs
↓
DE reviews infra plan
↓
┌─────────────────────────────────────┐
│ Config management: │
│ - environment variables │
│ - secrets management │
│ - feature flags (incl. those │
│ created by the Tasks-step │
│ PR-size rule — tracked for │
│ retirement, not left forever) │
│ - service dependencies │
└─────────────────────────────────────┘
↓
DEAIA runs infra validation (IaC linting, plan diff)
↓
DE approves and applies
↓
┌─────────────────────────────────────┐
│ Observability setup / update: │
│ - dashboards │
│ - alerts and thresholds │
│ - log aggregation │
│ - distributed tracing │
└─────────────────────────────────────┘
↓
Infra issue found that requires design change?
→ Cross-Workflow Feedback to Development
(re-entry: Spec or Plan (ADR) step)
↓
DevOps ready ✅
↓
recorded — SRE Workflow begins once QA + Security + DevOps
have all signed off (see Workflow Map)
SRE Workflow
Steps: SLO Validation → Production Deploy → Post-Deploy Monitoring
(begins after QA ✅ + Security ✅ + DevOps ✅)
SREAIA checks SLOs and error budgets are defined and aligned
↓
SRE reviews SLO definitions with TLA
↓
Production deploy (rolling / canary / blue-green)
↓
┌─────────────────────────────────────┐
│ Post-deploy monitoring window: │
│ - error rate vs baseline │
│ - latency percentiles │
│ - saturation metrics │
│ - business KPIs (conversion, etc.) │
└─────────────────────────────────────┘
↓
SLO breach or anomaly detected?
↓ YES
SREAIA classifies:
- regression in this change
→ rollback immediately
→ Cross-Workflow Feedback to Development (Implement step)
- infra / capacity issue
→ DevOps Workflow
- known acceptable degradation
→ document, continue monitoring
↓
Monitoring window clear ✅
↓
Released to Production ✅
Cross-Workflow Feedback Protocol
Triggered by: QA, Security, CI/CD, DevOps, or SRE — when a finding cannot be resolved within that workflow alone.
Step 1 — Finding ticket created
Originating workflow creates a Finding ticket containing:
- source workflow and step (e.g. "Security / SAST scan")
- severity (CRITICAL / HIGH / MEDIUM)
- description of the issue
- evidence (logs, scan output, reproduction steps)
- proposed root cause (code / design / requirements)
Step 2 — Root cause classification
TLAAIA + SWEAIA jointly analyse the Finding ticket
(PMAIA joins if a requirements flaw is suspected)
↓
┌─────────────────────────────────────────────────────────┐
│ Classify root cause → determines re-entry point: │
│ │
│ Requirements / design flaw → re-enter Development │
│ at Specify step │
│ Architectural decision flaw → re-enter Development │
│ at Plan (ADR) step │
│ Implementation bug → re-enter Development │
│ at Implement (Code) step│
└─────────────────────────────────────────────────────────┘
↓
TLA confirms classification
(PM also confirms if classified as a requirements flaw)
↓
TLA decides which downstream workflows must re-validate
once the fix lands (default: only the originating workflow —
see Step 4)
Step 3 — Development Workflow re-entry
Finding ticket attached to the relevant Development step
↓
PM / TLA / SWE (whichever owns that step) is notified
↓
┌─────────────────────────────────────────────────────────┐
│ At the re-entry step, the human + their AIA: │
│ - review the Finding ticket │
│ - update the document (Spec / ADR / code) │
│ - re-check compliance with the Constitution │
│ - update api-spec.json / data-model.md if contracts │
│ changed │
│ - propagate changes to all downstream documents │
│ - re-run the cross-artifact consistency check if │
│ ADRs or Plan artifacts changed │
└─────────────────────────────────────────────────────────┘
↓
Fix verified by TLA (and PM if the Spec changed)
Step 4 — Forward propagation
New PR opened with the fix
(subject to the same one-task-one-PR size rule)
↓
Development Workflow resumes from Implement / Pull Request step
↓
CI/CD Workflow re-runs
(incl. Architecture + Spec Compliance Checks)
↓
Originating workflow re-validates the finding area.
Other workflows that already passed are NOT fully re-run
unless TLA's Step 2 domain call says the fix scope
touches them too.
↓
Originating workflow closes the Finding ticket ✅
↓
If the SAME finding area reopens a 3rd time:
→ escalate to TLA + PM before attempting another fix
→ re-examine whether the root cause was misclassified
in Step 2
↓
If all workflows sign off:
→ pipeline continues toward Released to Production ✅
Stay tuned for the second part → Full Development Lifecycle: AI-Only, as a Living System