Bedienung ohne GUI

Ausfuehrlicher Betriebsleitfaden fuer Teams, die mit den neuen grossen Architekturen arbeiten, bevor fertige GUI-Workflows vorhanden sind.

1. Was ist hier anders als in klassischen Tools?

In IIO steuerst du nicht nur Dateien, sondern einen Agentic Cooperation Space mit Story-, Rollen-, Boundary- und Transaction-Logik. Bedienung ohne GUI bedeutet daher: klarer Ablauf, saubere Rollen, reproduzierbare Skriptpfade und Checklisten statt Ad-hoc-Klickfolgen.

Story-first Role-based fail-closed TX-auditierbar HITL-gated

2. Einstieg in 30 Minuten (Onboarding-Checkliste)

0-10 Min: Orientierung

  • Manual Home oeffnen und Kapitelstruktur verstehen.
  • Space, Actor, Role, Story, Transaction als Kernbegriffe klären.
  • Rollenpakete fuer Daily Ops lesen.

10-20 Min: Operativer Zugriff

  • Script Console aufrufen.
  • Web-Stack lokal starten und Status pruefen.
  • Ersten Validierungsskript-Lauf machen.

20-30 Min: Erstes echtes Objekt

  • Einen Test-Kunden als private anlegen.
  • Ein Test-Projekt mit Story+Plan+State erzeugen.
  • TX-Record + Evidence eintragen.
# Schnellstart im Terminal
bash specs/scripts/start-dev-web-stack.sh 8000 /home/zolo/space
bash specs/scripts/status-single-webserver.sh 8000
bash iio/specs/scripts/validate-workspace-root-cleanliness.sh /home/zolo/space/iio strict

3. Typische Betriebsablaeufe (Standard-Runs)

A) Tagesstart-Run

1. Workspace und Web-Stack starten
2. Root/Policy/Capability validieren
3. Offene Stories + Gate-Bedarf sichten
4. Tagesprioritaeten durch Delivery Lead setzen

B) Kunden-Onboarding-Run

1. Kunde als private anlegen (Default)
2. Boundary + Rollenpaket zuweisen
3. Erstes Projekt (Story/Plan/State) starten
4. Registry/Relation + TX dokumentieren

C) Release-Go/No-Go-Run

1. Full Stack Audit starten
2. Reviewer prueft Evidence + Risiken
3. HITL GO/NO-GO (RG-004)
4. Nur bei GO: Publish + Revision

D) Incident-Run

1. Incident klassifizieren (Scope, Impact, Boundary)
2. Sofortmassnahme + sichere Reproduktion
3. Fix als Story/Plan/Work behandeln
4. Root Cause + Learnings (local-only/seed-relevant)

4. Checklisten pro Betriebsphase

Tagesstart

  • Serverstatus gruen?
  • Validierung erfolgreich?
  • Heute relevante Gates identifiziert?
  • Rollen und Verantwortliche eindeutig?

Vor kundenrelevanter Aenderung

  • public/private Boundary korrekt?
  • Owner + Reviewer benannt?
  • Legal/IP-Risiko geprueft?
  • Rollback-Option vorhanden?

Vor Release

  • Audit-Evidence aktuell?
  • RG-004 Signal korrekt gesetzt?
  • Keine offenen BLOCK-Trigger?
  • State-Transition + TX vorbereitet?

Nach Abschluss

  • Transaction und Artefakte verknuepft?
  • Revision protokolliert?
  • Learning klassifiziert (local-only / seed-relevant)?
  • Naechster Betriebsschritt klar?

5. Kommandopfad (ohne GUI)

ZweckKommandoErwartung
Dev-Stack starten bash specs/scripts/start-dev-web-stack.sh 8000 /home/zolo/space Manual/Public Seiten lokal erreichbar
Serverstatus pruefen bash specs/scripts/status-single-webserver.sh 8000 Ein Listener, HTTP ok
Root Hygiene validieren bash iio/specs/scripts/validate-workspace-root-cleanliness.sh /home/zolo/space/iio strict Kein unerlaubter Root-Drift
Capability Profiles validieren bash iio/specs/scripts/validate-capability-profiles.sh /home/zolo/space/iio strict P-CAP Regeln konsistent
Full Stack Audit bash iio/specs/scripts/run-full-stack-audit.sh /home/zolo/space /home/zolo/space/iio /home/zolo/space/intelego GO/NO-GO Evidence Paket

6. Haeufige Fehler bei neuen Teams

FehlerSymptomKorrektur
Zu frueh auf GUI-Denken wechseln Unklare Verantwortlichkeiten, fehlende TXs Erst Rollenpakete und Checklisten stabilisieren
Projekt ohne Story Arbeit ohne klares Ziel und Scope Story/Plan Pflicht vor Work-Start
Boundary-Verwechslung public/private Datenfreigabe-Risiko Default private + explizites Review fuer public
Gate-Bypass Schneller Push ohne RG-Evidence fail-closed: BLOCK und sauberer Gate-Run
Kein Owner = BLOCK Kein Reviewer = BLOCK Kein TX = BLOCK Checkliste zuerst = stabiler Betrieb

7. Verknuepfte Kapitel