experiment(0027): add SDLC experiment with iterative waterfall diagram

0027-sdlc/HOW_TO.md

@@ -0,0 +1,18 @@
+# How to engage with this experiment
+
+This is a **conceptual reference artifact**, not a runnable experiment. There is nothing to install, configure, or execute. The deliverable is the SDLC map in [`sdlc-diagram.md`](sdlc-diagram.md).
+
+## Purpose
+
+Map the full software development life cycle so we can identify phases where fullsend agents could automate work in the future. The diagram is a shared vocabulary for "where in the SDLC does this capability fit?" conversations — not a procedure to reproduce.
+
+## How to use it
+
+1. **Read the diagram** in [`sdlc-diagram.md`](sdlc-diagram.md) (Mermaid state diagram). Render it in any Mermaid-capable viewer (GitHub, VS Code Mermaid extension, [mermaid.live](https://mermaid.live)).
+2. **Orient by phase** — top-level states (`01.Ideation` … `10.Decommission`) are the 30,000ft view. Drill into nested states for finer steps.
+
+## What this is not
+
+- Not a reproducible setup with scripts, sandboxes, or eval harnesses
+- Not a prescription of one correct SDLC model (waterfall vs agile, etc.)
+- Not an inventory of existing fullsend capabilities — only a map of where they *could* attach

0027-sdlc/README.md

@@ -0,0 +1,32 @@
+---
+title: "27. Software Development Life Cycle"
+status: Concluded
+topics:
+  - vision
+  - architecture
+---
+
+# 27. Software Development Life Cycle
+
+Date: 2026-08-10
+
+## Hypothesis
+
+What is the big picture of the SDLC process?
+
+## Approach
+
+Create a Mermaid diagram of the end-to-end SDLC (ideation through decommission) as a shared reference map. The goal is to surface phases and transitions where fullsend agents could automate work later — not to run a reproducible experiment.
+
+See [HOW_TO.md](HOW_TO.md) for how to read and engage with the diagram.
+
+## Results
+
+The diagram shows an iterative waterfall SDLC, and should cover all parts of an organization's software processes.
+
+## Conclusion
+
+1. The way the steps/transitions are connected is what makes it a waterfall process. We argue that the same steps/transitions would be needed for other SDLC models. I.e. we believe this representation is quite accurate regarding the needed skills.
+2. We can't document what we don't know. Some steps might be overly simplified because of how little experience we have with them.
+3. The graph is complex to grasp. Navigating the graph is difficult. Steps need to be grouped so it's easy to understand the 30'000ft view, and then slowly drill down.
+4. Since we don't know the particular processes of everyone, it should both be easy to replace a set of steps/transitions with a single step, or split a step into a more complex set of steps/transitions.

0027-sdlc/sdlc-diagram.md

@@ -0,0 +1,151 @@
+# Software Development Life Cycle (SDLC) Diagram
+
+```mermaid
+stateDiagram-v2
+    direction TB
+
+    state 01.Ideation {
+        direction LR
+
+        01customer: Customer feedback
+        01innovation: Innovation research
+        01market: Market research
+        01ops: Operational feedback
+        01document: Document
+
+        01customer --> 01document: Produces
+        01innovation --> 01document: Produces
+        01market --> 01document: Produces
+        01ops --> 01document: Produces
+    }
+
+    state 02.Planning {
+        direction LR
+
+        02fit: Evaluate product fit
+        02prioritization: Evaluate priority
+        02rejected: Updated product scope documentation
+        02parked: Parked
+        02scope: Refine scope
+        02feature: Feature with full description, priority and target dates
+
+        02fit --> 02rejected: Rejected
+        02fit --> 02prioritization: Approved
+        02prioritization --> 02scope: Planned
+        02prioritization --> 02parked: Delayed
+        02parked --> 02prioritization: Planning
+        02scope --> 02feature: Refined
+    }
+
+    state 03.Analysis {
+        direction LR
+
+        03scope: Scope work
+        03adrs: Update ADRs
+        03epics: Epics with full description and priority
+
+        03scope --> 03scope: Feedback
+        03scope --> 03adrs: Scope defined
+        03adrs --> 03adrs: Feedback
+        03adrs -->  03epics: Organize work
+    }
+
+    state 04.Design {
+        direction LR
+
+        04scope: Scope work
+        04research: Research
+        04stories: Stories with full description and priority
+
+        04scope --> 04research: Identify unknowns
+        04research --> 04scope: Feedback
+        04scope --> 04stories: Organize work
+    }
+
+    state 05.Implementation {
+        direction LR
+
+        state Code {
+            05code: Code
+            05test: Unit-tests
+            05doc: Documentation
+        }
+        state Quality {
+            05review: Review
+            05ci: Continuous Integration
+            05compliance: Compliance
+        }
+        05e2e: End-to-end testing in isolated environments
+        state Release {
+            05build: Build release
+            05notes: Release Notes
+            05versioning: Versioning
+        }
+
+        Code --> Quality: Submit
+        Quality --> Code: Feedback
+        Quality --> 05e2e: Merge
+        05e2e --> Code: Feedback
+        05e2e --> Release: Build release candidate
+    }
+
+    state 06.Testing {
+        direction LR
+
+        06e2e: End-to-end testing in staging environments
+        06perf: Performance testing
+        06security: Security testing
+    }
+
+    state 07.Deployment {
+        direction LR
+
+        07install: Install
+        07config: Configure
+        07update: Update
+        07bc: Business Continuity
+        07audit: Auditing
+        state Monitor {
+            Health
+            Security
+        }
+    }
+
+    state 08.Maintenance {
+        direction LR
+
+        08techdebt: Tech Debt
+        state Support {
+            08bug: Bug filed
+            08cves: CVEs
+            08backport: Backports
+        }
+    }
+
+    09.InfoSec
+
+    10.Decommission
+
+    01document --> 02fit: Submit for approval to Owners
+    02fit --> 01document: Feedback
+    02feature --> 03scope: Involve tech leads
+    03scope --> 02feature: Feedback
+    03epics --> 04scope: Involve individual contributors
+    04scope --> 03epics: Feedback
+    04scope --> 08techdebt: Feedback
+    04stories --> Code: Implement
+    05.Implementation --> 08techdebt: Feedback
+    05.Implementation --> 04stories: Feedback
+    Release --> 06.Testing: Validate
+    06.Testing --> 07.Deployment: Release
+    06.Testing --> 08bug: Feedback
+    07.Deployment --> 08.Maintenance: Feedback
+    07.Deployment --> 01ops: Feedback
+    08techdebt --> 01document: Remediate
+    Support --> 02.Planning: Remediate
+    09.InfoSec --> 05compliance: Informs
+    09.InfoSec --> 06security: Informs
+    09.InfoSec --> Security: Monitors
+    09.InfoSec --> 08cves: Tracks
+    08.Maintenance --> 10.Decommission
+```

README.md

@@ -32,6 +32,7 @@ Experiments for the fullsend platform — each tests a hypothesis about autonomo
 | 0024 | [CODEOWNERS + GitHub App approval matrix](0024-codeowners-app-matrix/) | Concluded |
 | 0025 | [Subagent process isolation via PreToolUse hooks](0025-subagent-process-isolation/) | Active |
 | 0026 | [Statistical significance for non-deterministic evals](0026-eval-statistical-significance/) | Concluded |
+| 0027 | [Software Development Life Cycle](0027-sdlc/) | Concluded |
 
 ## Conventions