Jira as the leading system
Ticket status, role label, history, and board state live in Jira. Files complement the work, but they do not replace the Jira process.
Rules and guardrails
Why the AI project organization needs a strict rule set
The rule set is the operational framework that turns individual AI chats into a traceable project organization. It prevents roles, decisions, and results from dissolving into fleeting chat context. In regulated or critical development environments, this is the difference between usable automation and acceleration that cannot be evidenced later.
Control model
What the rule set accomplishes
An AI role can absorb context, formulate, assess, and implement very quickly. Without guardrails, that very strength creates risk: the role may start doing work that belongs to other roles, invent missing information, or skip process logic because it feels efficient in the moment.
The rules therefore define what counts as work, where the binding status lives, when a result is complete, and which role should take over next. They do not slow AI work down, but make it sturdier: each handover becomes shorter because the structure is already in place, and every later evidence trail can refer to the same control points.
Innere Logik
The most important guardrails working together
Strikte Rollentrennung
PM, PO, DEV, QA, DOC, and specialist roles remain functionally separated. That keeps ownership and result quality reviewable.
Artifact-based handovers
Short Jira results point to concrete files, handovers, or results. Details live where they can be found again later.
Minimale Abschlussdokumentation
Closure requires Latest Result, next status, next role, and triggering role. Without this information, the process state is incomplete.
No speculative documentation
Unclear content is marked as open. DOC documents confirmed results and visibly returns missing information.
Kosten- und Kontextdisziplin
Each role reads only the necessary context and selects the smallest sufficient model and reasoning level.
Audit- und KRITIS-Tauglichkeit
Regelgebundene Statuswechsel, Freigaben und Artefaktpfade schaffen die Grundlage für belastbare Änderungs- und Entscheidungsnachweise in sicherheitsnahen Umfeldern.
Notwendigkeit
Why strict rule application is not mere formalism
Ohne Strenge
- Roles mix product decisions, implementation, review, and documentation
- Tickets wirken abgeschlossen, obwohl Pflichtschritte fehlen
- Successor roles have to reconstruct old comments and chat histories
- unclear information quietly turns into apparent facts
Mit Strenge
- Status und Rollenlabel zeigen sofort, wer als Nächstes zuständig ist
- Result Summaries liefern einen kompakten, prüfbaren Abschluss
- open points are visibly returned to PO, DEV, QA, or supporting roles
- documentation remains reliable because it is based on confirmed status
Praxisnutzen
Five examples where the rule set helps in practice
1. Falsch gelabeltes Ticket
A ticket is in `Ready for DOC` but carries a QA label. DOC does not work on it speculatively, but reports the inconsistency back to PO.
2. Fehlendes DEV-Ergebnis
A documentation task asks for a technical description, but the DEV handover is missing. DOC does not document freely, but requests DEV input.
3. QA blocks approval
A function has not yet been accepted. DOC does not write it into user documentation as final, but waits for a confirmed QA basis.
4. Review findet Qualitätslücke
A PM or executive blocker is translated by PO into a concrete improvement ticket so the correction remains reviewable.
5. Regeländerung mit Rollenwirkung
A new process rule is not silently assumed. Affected roles reread it via rollout tickets and confirm its application.
Learning effect
How the AI chats become more mature and more organizationally capable
The visible learning effect does not lie in a chat becoming ever more confident in a free-form way. It lies in the role becoming better at recognizing process boundaries: when may it act, when must it hand work back, and when is a result content-wise good but still not process-complete?
The previous rework loops made exactly this maturation visible. First came a compact overview. Then followed technical depth, better structure, design adjustments, correct language handling, and now an explicit explanation of the rules themselves. Every blocker was translated into a new, actionable ticket and not left as informal criticism beside the process.
As a result, the AI roles learn not only more content, but better work discipline: fewer assumptions, clearer handovers, cleaner status logic, and a more deliberate handling of their own area of responsibility.