<img src="banner.png" width="100%" alt="dev-cycle banner">

Deutsch — Offizielle Deutsch-Version / Documento Oficial en Deutsch.

Development Cycle (Dev Cycle) (Deutsch)

Goal: Structured process from feature request to validated system. Every development goes through these 8 phases.

📐 Beilage: SCHALTPLAN-SOFTWAREENTWICKLUNG.html — menschlich lesbarer „Schaltplan der Softwareentwicklung" (HTML, im Browser öffnen): recherchierte Gesamtkarte aus Phasen, Regelkreisen, Rollen, Prozessketten und Test-Gates (Webrecherche 08/2026), in die sich dieser 8-Phasen-Zyklus einordnet.

---

Übersicht & Zweck

  +--------------------------------------------------------------+
  |                    DEVELOPMENT CYCLE                           |
  +--------------------------------------------------------------+
  |                                                                |
  |  Phase 1   Feature Requests (functional requirements)          |
  |     |                                                          |
  |     v                                                          |
  |  Phase 2   Check Current State (What already exists?)          |
  |     |                                                          |
  |     v                                                          |
  |  Phase 3   Functional Planning                                 |
  |            (Workflows, Agents, Experts, Skills, Services)      |
  |     |                                                          |
  |     v                                                          |
  |  Phase 4   Implement Functional Frontend                       |
  |            (Skill files, workflow markdown, agent profiles)     |
  |     |                                                          |
  |     v                                                          |
  |  Phase 5   Plan and Align Backend                              |
  |            (CLI handlers, DB schema, API endpoints)            |
  |     |                                                          |
  |     v                                                          |
  |  Phase 6   Implement Backend Tasks                             |
  |            (Python code, tools, DB migrations)                 |
  |     |                                                          |
  |     v                                                          |
  |  Phase 7   Test Execution, Review Gate and Bugfixes           |
  |            (B/O/E tests, bugfix protocol, code review)          |
  |     |                                                          |
  |     v                                                          |
  |  Phase 8   Functional and Feature Test: USE CASES              |
  |            (End-to-end validation from user perspective)        |
  |                                                                |
  +--------------------------------------------------------------+

  Core principles throughout:
  - Functional description first (before code)
  - CLI First (everything controllable via terminal)
  - Clear separation of user data and system data
  - Shift-Left: tests are DESIGNED early (phases 1/3/5) and WRITTEN
    with the code (phase 6) - phase 7 only EXECUTES them

---

Phase 1: Feature Requests (Functional Requirements)

What: Collect and formulate functional requirements.

Input:

• User wishes, ideas, problems
• Partner suggestions (LLM assistants)
• Insights from use cases (feedback loop!)

Output:

• Tasks in the task system (e.g., as issue, ticket, or TODO list)
• Requirements describe WHAT is desired, not HOW
• Each requirement carries testable acceptance criteria (Shift-Left: they become the use cases of Phase 8 and the acceptance checklist)

Rules:

• Always formulate requirements functionally ("User can do X")
• Not technically ("Implement REST endpoint for X")
• Use use cases as requirement source (Phase 8 -> Phase 1)

---

Phase 2: Check Current State

What: Inventory existing functionality.

Checklist:

  [ ] Search existing tools/scripts
  [ ] Check documentation/help on the topic
  [ ] Check existing skills/agents/services
  [ ] Check DB schema (if relevant)
  [ ] Check use cases - has something similar been tested?

Output:

• Documentation of what exists, what's missing, what needs extension
• Avoidance of duplicates

---

Phase 3: Functional Planning

What: Plan at the functional level - do NOT write code immediately.

Planning Levels:

Level	Question	Artifact
Workflow	WHEN/HOW is coordination done?	workflows/*.md
Agent	WHO executes?	agents/*.txt
Expert	WHO has domain knowledge?	experts/*/
Skill	WHAT is done?	skills/*.md
Service	HOW is it done technically?	services/*/

Rules:

• Think functionally first, then technically
• Shift-Left: for every planning level, plan its CHECK as well — requirement → acceptance criterion, service/interface → integration test, unit → unit test (test-level and technique selection: software-testing)
• Workflows describe processes, not implementation details
• Every agent needs a clear profile
• Services must work without user data

---

Phase 4: Implement Functional Frontend

What: Create skill files, workflow markdown, agent profiles.

The "frontend" here is the functional description layer:

• Workflow files (.md)
• Agent profiles (.txt)
• Expert knowledge
• Service descriptions
• Help files

Output:

• All functional descriptions exist
• An LLM partner could read and understand the workflow
• The functional layer is fully documented

---

Phase 5: Plan and Align Backend

What: Align technical architecture to the functional frontend.

Planning Areas:

Area	Question	Location
CLI Handlers	Which commands?	handlers/*.py
DB Schema	Which tables/columns?	schema/*.sql
API Endpoints	Which GUI endpoints?	server.py
Tools	Which Python scripts?	tools/*.py

Output:

• Technical plan aligned with the functional frontend
• DB schema design
• CLI command structure

---

Phase 6: Implement Backend Tasks

What: Write Python code, DB migrations, CLI handlers.

Checklist (per task):

  [ ] Unit tests written (TDD: test before code) and green locally?
  [ ] Works without user data (empty DB)?
  [ ] CLI command available?
  [ ] Input can come from files/folders?
  [ ] Output goes to structured DB?
  [ ] Scan/import is repeatable (idempotent)?
  [ ] No hardcoded path?
  [ ] Tool registered and documented?
  [ ] Help file created?

---

Phase 7: Test Execution, Review Gate and Bugfixes

What: Ensure technical correctness. Tests were DESIGNED in phases 1/3/5 and WRITTEN in phase 6 (Shift-Left) — phase 7 EXECUTES them in staged, blocking gates: fast tests on every commit, expensive tests (full regression, E2E, load) nightly or pre-release. Gate mapping and test selection: software-testing.

Test Types (B/O/E):

Type	Perspective	Description
B-Tests	External/Automated	Automated tests, CI/CD
O-Tests	Functional (Input->Output)	Manual functional verification
E-Tests	Subjective/Experience	UX evaluation, ergonomics

Review Gate (before Phase 8):

• Code review by a second pair of eyes (peer, reviewer agent, or advisor)
• Nothing enters use-case validation unreviewed
• Review findings loop back to Phase 6 as change requests

On bugs:

• Apply the bugfix protocol
• Observe the 20-minute rule (change approach after 20 min)
• Document lessons learned

---

Phase 8: Functional and Feature Test - USE CASES

What: End-to-end validation from user perspective.

Use cases serve BOTH purposes:

1. Feature indicators - What is desired? What should be possible?
2. Test scenarios - Does it actually work from A to Z?

Use Case Format:

  USECASE_NNN: Short Title

  PRECONDITION: What must be in place?
  INPUT:        What does the user enter / what data?
  EXPECTED:     What should the result be?
  TESTS:        Which components are tested?

Feedback Loop:

• Failed use cases -> new tasks in Phase 1
• Successful use cases -> validated features
• New use case ideas -> capture as tasks

---

Summary: The Cycle

  Phase 8 (Use Cases)
       |
       | New requirements / bugs
       v
  Phase 1 (Feature Requests)  -->  Phase 2 (Current State)
       ^                                    |
       |                                    v
  Phase 7 (Tests/Bugs)         Phase 3 (Functional Planning)
       ^                                    |
       |                                    v
  Phase 6 (Backend Code)       Phase 4 (Functional Frontend)
       ^                                    |
       |                                    v
       +──────────────────── Phase 5 (Backend Planning)

The cycle is a loop: Use cases validate features and simultaneously generate new requirements.

---

Control Loops (Regelkreise)

The 8-phase cycle is the OUTER control loop. Inside it, faster loops run concurrently — the further in a loop sits, the faster its takt and the cheaper the fix:

Loop	Takt	Where in the cycle
TDD (Red–Green–Refactor)	seconds–minutes	inside Phase 6
Test execution / CI gates	< 10 min per commit	Phase 7 → Phase 6 on red
Review gate (4 eyes)	hours	between Phase 7 and Phase 8
Bugfix loop	hours	Phase 7 → Phase 6 (bugfix protocol)
Use-case loop	per cycle	Phase 8 → Phase 1
Operations feedback	continuous	monitoring/incidents → Phase 1

Rule of thumb: keep commit-to-feedback under 10 minutes — a slow loop gets bypassed. Visual map of all loops with timings: enclosed SCHALTPLAN-SOFTWAREENTWICKLUNG.html, sheet BL-2.

---

Phase-specific skills

Phase	Specialized skill	Trigger
Phases 1-3	Project bootstrapper (if available)	Create a new project (greenfield)
Phase 2	project-onboarding	Take on an existing project
Phases 2-3	docs-analysis	Check requirement documents against code
Phases 5-6	pipeline-optimizer	Renovate existing structures
Phase 7	bugfix-protocol	Systematic 6-phase debugging
Phases 7-8	bugsweep	Converging bug sweep before a release
Phases 1, 3, 7	software-testing	Choose test levels, types and design techniques; CI/CD gate mapping
After Phase 8	github-repo-care	Release: publish and maintain the repository

If your skill collection has a skill index, search it for further phase-specific skills.

---

Änderungsprotokoll

1.2.0 (2026-08-22)

• Shift-Left verankert (Rechercheabgleich mit Beilage-Schaltplan): Abnahmekriterien als Phase-1-Output, Testentwurf je Planungsebene in Phase 3, Unit-Tests (TDD) als erster Punkt der Phase-6-Checkliste; Phase 7 umbenannt in „Test Execution, Review Gate and Bugfixes" — Tests werden dort ausgeführt, nicht erst geschrieben
• Review-Gate (4-Augen-Prinzip) als expliziter Schritt vor Phase 8
• Neuer Abschnitt „Control Loops (Regelkreise)" mit Taktzeiten (TDD, CI, Review, Bugfix, Use-Case, Betrieb)
• Phasen-Skill-Tabelle erweitert: software-testing (Phasen 1/3/7), github-repo-care (nach Phase 8); Verweise auf software-testing in Phase 3 und Phase 7

1.1.1 (2026-08-22)

• Beilage SCHALTPLAN-SOFTWAREENTWICKLUNG.html (menschlich lesbare Gesamtkarte: Phasen, Regelkreise, Rollen, Prozessketten, Test-Gates — Synthese einer Webrecherche 08/2026) plus Verweis im Kopf der Datei

1.1.0 (2026-06-13)

• New "Phase-specific skills" table with references to project-onboarding, docs-analysis, pipeline-optimizer, bugfix-protocol, and bugsweep

1.0.0 (2026-03-12)

• Ported from BACH (dev-zyklus v1.0.0)

---

Created: 2026-01-28 | Ported: 2026-03-12