Story Lifecycle

Die Story ist das operative Grundobjekt im IIO — Planung, Ausführung, Evidence und Publication in einem Konzept vereint. Hier: vollständiger Lebenszyklus, 8 Elemente, Kanäle, Konsistenzregeln, und wie eine Story zur Revision wird.

1 · Was ist eine Story? — Das operative Grundobjekt1 · What is a Story? — The Operational Base Object

Eine Story ist NICHT ein Feature-Request oder ein Ticket. Sie ist der narrative + operative Rahmen, aus dem deterministisch ein Plan, Work und Artifacts entstehen.

Definition: Eine Story ist eine evidenzbasierte, commit-fähige Beschreibung: wer macht was, warum, mit welchem Ergebnis, als Beweis für was — vollständig genug, um daraus maschinell einen Plan zu erzeugen.

Story ≠ Ticket

  • Ticket: "Feature X bauen"
  • Story: Actor mit Kontext, Conflict, Path, Evidence
  • Story ist persistent (nicht nach Abschluss gelöscht)
  • Story ist der Beweis: "hier hat das System so funktioniert"

Story → Plan → Work (deterministisch)

  • Gleiche Story → immer gleiche Plan-Struktur (P-STORY-002)
  • Plan ist die Materialisierung der Story
  • Work sind Tasks aus dem Plan abgeleitet
  • Änderung am Plan ohne Story-Änderung = Drift

2 · Die 8 Pflicht-Elemente einer Story2 · The 8 Required Elements of a Story

Jede Story muss alle 8 Elemente haben — sowohl für Individual Actors als auch für Composite Actors. Fehlende Elemente = BLOCK.

Element 1
origin
Woher kommt dieser Actor / dieses Vorhaben?
Element 2
purpose
Warum existiert dieser Actor?
Element 3
actors
Wer ist beteiligt? (Self-ref für Individual; Member-Liste für Composite)
Element 4
conflict
Welche Spannungen, Einschränkungen, Herausforderungen?
Element 5
path
Was ist die beabsichtigte Entwicklungsrichtung?
Element 6
artifacts
Was produziert / pflegt dieser Actor?
Element 7
state
Aktueller Zustand, Übergänge, Abhängigkeiten
Element 8
evidence
Was beweist, dass diese Story real ist?
# Minimal-vollständige Story in YAML:
id: story-api-handler-001
kind: story
actor_id: actor-alice
story:
  origin: "Legacy API mit Monolith-Kopplung; Migrationsbedarf erkannt Q1"
  purpose: "Saubere API-Schicht die unabhängig skaliert"
  actors: [alice (lead), bob (contributor), validator-bot (reviewer)]
  conflict: "Tech Debt vs. Feature-Velocity; Monolith-Abhängigkeiten"
  path: "Incremental extraction; first handler, then auth, then data layer"
  artifacts:
    produces: [api-handler-v2, openapi-spec, integration-tests]
    maintains: [legacy-compat-shim]
  state: active
  evidence: [tests-passing-ref, design-doc-link, peer-review-record]

3 · Die 5 Story-Schichten (Nested Depth)3 · The 5 Story Layers (Nested Depth)

Innerhalb einer Story gibt es 5 Vertiefungsschichten. Die oberste ist maschinenoptimal; die tiefste ist die zerlegte Innenperspektive.

SchichtLayerInhaltContentFür wenFor WhomFormat
one-liner "Was ist dieser Actor in einem Satz?" Alle Actors, externe Darstellung 1 Satz max
genesis Ursprungs-Story: "Woher kam das?" Composite besonders (Gründungsnarrativ) Kurz-Narrativ
world Welt-Aufbau: "In welchem Ökosystem operiere ich?" Alle; bietet Stakeholder-Kontext Narrativ + Kontext-Matrix
narratives Mehrere Perspektiven auf denselben Actor Composite Actors mit verschiedenen Stakeholders Stakeholder-spezifische Texte
decomposition Wie zerfällt die Story in Sub-Stories? Composite: Member-Stories; Individual: Teil-Fähigkeiten Verschachtelte Story-Struktur
Konsistenz-Regel (P-STORY-004): Die 5 Schichten dürfen sich nicht widersprechen. one-liner ↔ genesis ↔ world ↔ narratives ↔ decomposition müssen kohärent sein. Widerspruch = Story-Gate BLOCK.

4 · Story Lifecycle: Von der Idee zur veröffentlichten Revision4 · Story Lifecycle: From Idea to Published Revision

Eine Story durchläuft definierte Zustände. Jeder Übergang benötigt eine Transaction. Kein Übersprung von States erlaubt.

draft

1 · Draft

Story wird erstellt. Noch kein vollständiges Gate-Assessment. Alle 8 Elemente müssen vorhanden sein bevor weiter. Kein GO-Signal möglich in diesem State.

intake

2 · Intake

Story ist vollständig deklariert. Intake-Klassifizierung läuft: request_type, scope, actor_id, phase, evidence_present. Wenn scope leer oder actor_id fehlt → BLOCK hier.

mapping

3 · Mapping

Premise-Mapping läuft. Mindestens 1 P-Prefix wird identifiziert. Canonical Sources werden geprüft. Owner: mapper-Rolle im team-workflow.

gate-review

4 · Gate Review

8-Gate-Assessment läuft (actor → story → role → boundary → composition → skill → transaction → audit). Bei strictem Modus: kein pass-inferred erlaubt. Owner: reviewer-Rolle.

hitl-gate

5 · HITL Gate (bei Bedarf)

Wenn ein ESCALATE-Signal gesendet wurde: menschliche Entscheidung erforderlich. Agent wartet. Kein GO ohne Human-Bestätigung. Owner: operator/human.

go

6 · GO — Commit

Alle Gates passed. GO-Decision aufgezeichnet mit vollständiger Evidence-Kette. Transaction wird committed. Owner: release-operator.

published

7 · Published — Revision

Revision-Eintrag in iio/public/revisions/ erstellt. Enthält: Decision-Metadata, Evidence-Summary, Gate-Trace, HITL-Status. Story verbleibt als Archiv.

archived

8 · Archived

Story ist abgeschlossen. Artifacts persistent. Evidence für Audits verfügbar. Kann als Referenz für neue Stories dienen.

5 · Publishing Channels — 3 strikte Ausgabe-Kanäle5 · Publishing Channels — 3 Strict Output Channels

Jedes Artefakt einer Story gehört zu genau einem Kanal. Keine gemischten Kanäle in einem Artefakt. (P-LANG-001, P-LANG-002, P-LANG-003)

AGT — Agentic Channel
Machine-Optimized Ausgaben
YAML, JSON, strukturiertes Markdown ohne Prosa. Für: Agents, Automation, AI Systems. Beispiele: AGENTS.md, contract.yaml, queue.yaml, state.yaml
DE — German Narrative
Für deutschsprachige Operator
Markdown, HTML Manuals. Für: Human Operators, Stakeholders (DE). Beispiele: Operator-Manual, Governance-Docs, Session-Summaries, diese Seite.
EN — English Narrative
Für internationales Publikum
Markdown, HTML. Für: International Docs, Spec Translations, Partner Onboarding. Keine deutschen Begriffe erlaubt.
RegelRuleWenn verletzt →If violated →
P-LANG-001: AGT/DE/EN strikt getrenntBLOCK — Channel-Konflikt erkannt
P-LANG-002: Keine gemischte Sprache in einem ArtefaktBLOCK — Mixed-Language erkannt
P-LANG-003: Kein Kanal ohne Channel-TemplateBLOCK — Template nicht deklariert

6 · Story: Individual Actor vs. Composite Actor

Beide Typen benötigen eine vollständige Story — aber mit unterschiedlichem Schwerpunkt. Die Struktur ist isomorph.

Individual Actor Story

  • one-liner → "Wer bin ich?"
  • genesis → "Wie habe ich diese Fähigkeit entwickelt?"
  • world → "Was ist mein Kontext?"
  • narratives → "Wie sehen mich verschiedene Stakeholder?"
  • decomposition → "Welche Teilfähigkeiten setzen mich zusammen?"
  • actors-Feld = Self-Referenz
  • state.yaml = persönlicher aktueller Zustand

Composite Actor Story

  • one-liner → "Was tut unser Team/unsere Org?"
  • genesis → "Wie war die Teamgründung?"
  • world → "Was ist unser Markt/Ökosystem?"
  • narratives → "Wie erlebt jedes Mitglied das Kollektiv?"
  • decomposition → "Was sind die Member-Actors' Stories?"
  • actors-Feld = Member-Liste mit Rollen
  • shared_state.yaml = kollektiver Zustand
Fractal-Prinzip: Die Story-Struktur eines Composite Actors ist isomorph zur Story-Struktur des Space, in dem er operiert. Ein Team hat dieselbe Story-Anatomie wie ein Individuum — nur die Akteure sind mehrere.

7 · Actor-Space Filesystem-Template7 · Actor-Space Filesystem Template

Jeder Actor-Space hat eine kanonische Verzeichnis-Struktur. Abweichungen davon sind potenzieller Drift.

actor-<uuid>/
  README.md         # Narrative-optimierte Story + Plan (DE/EN Kanal)
  AGENTS.md         # Machine-optimierte Story + Execution (AGT Kanal)
  story/
    one-liner/
      README.md
    genesis/
      README.md     # Ursprungs-Narrativ
    world/
      README.md     # Kontext, Ökosystem
    decomposition/
      README.md     # Member-Stories (Composite) / Teilfähigkeiten (Individual)
  plan/               # Materialisierung der Story → deterministisch
  work/               # Tasks aus Plan abgeleitet
  artifacts/          # Outputs + gepflegte Assets
  state.yaml         # Aktueller Zustand serialisiert
  evidence/           # Beweise für Story-Claims

8 · Story im Team-Workflow: 4 Stages + Handover-Contract8 · Story in Team Workflow: 4 Stages + Handover Contract

Jede Story durchläuft 4 Stages des Team-Workflows. Jeder Handover zwischen Stages benötigt einen vollständigen Handover-Contract.

StageOwner-RolleOwner RoleDefinitionFail-Closed-Trigger
intake orchestrator Ein thin-through path mit explizitem Scope Scope fehlt → BLOCK
mapping mapper Source-Target Mapping mit Class und Evidence Keine P-Prefix identifiziert → BLOCK
review reviewer Contradiction + Drift Check mit fail-closed Gate Reviewer fehlt → kein GO möglich
release release-operator Closeout + Relock Publication Owner-Gate nicht passed → kein Release

Handover-Contract Pflichtfelder:

work_item_id from_role to_role status blockers evidence next_action
Regel: Kein Stage kann übersprungen werden (no_stage_skip). Kein GO ohne Reviewer-Gate. Kein Release ohne Owner-Gate. Fehlende Handover-Felder = BLOCK.