ellmos-ai 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:
- Feature indicators - What is desired? What should be possible?
- 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