Tägliche Administration: Objekte, Kunden, Projekte

Praxiskapitel für den Tagesbetrieb: Wie du Objekte korrekt anlegst, Kunden in öffentlich/privat trennst und Projekte sauber in der Layer-Logik führst. Mit SOPs und aufgesplittetem Objektbaum.

Objekte anlegen Kunden public/private Projekt-SOP TX-auditierbar Fail-Closed

1. Kurzantwort: Gibt es dafür einen Layer?

Ja, aber nicht nur einen. Kunde/Projekt ist in IIO kein "Sonderobjekt", sondern ein Zusammenspiel aus mehreren Schichten:

Was du anlegstKernmodellHaupt-LayerWarum
Kunde (öffentlich sichtbar) Actor + Domain + Boundary(public) Ontology, Boundary, Publishing Sichtbarkeit und Kanaltrennung (DE/EN/AGT) sind zentral
Kunde (privat) Actor + Domain + Boundary(internal/semi) Boundary, Role, Transaction Zugriff, Rollen und Audit-Trail müssen strict sein
Projekt Story + Plan + Work + Artifact + State Story, Composition, Transaction Projekt ist ein operativer Flow, kein reines Label
Objekt allgemein Artifact mit Owner/Relation/State Placement, Transaction, Registry Verortung + Nachweisbarkeit sind Pflicht
Actor-agnostisch fail-closed Story-getrieben TX-auditierbar

2. Objektbaum (aufgesplittet) für den Admin-Alltag

Damit der Baum nicht vermischt wird, trennst du immer in öffentlich, privat und projekthaft.

  • Space: organisation/<name>
    • customers/
      • public/<customer-id>/
      • private/<customer-id>/
    • projects/
      • active/<project-id>/
      • archive/<project-id>/
    • shared/
      • templates/
      • relations/
# Minimal naming rules
customer-id: customer-<slug>
project-id:  project-<slug>
visibility:  public | private
state:       draft | active | paused | archived

3. SOP: Neuen Kunden anlegen (öffentlich oder privat)

1. Intake: Kunden-ID, Sichtbarkeit, Owner, Domain, Zweck
2. Placement: Q1–Q9 prüfen (Ownership, Sensitivität, Legal-Impact)
3. Boundary setzen: public oder private mit Access-Regeln
4. Rollen binden: contributor/reviewer/owner für den Kundenkontext
5. Transaction schreiben: create_customer mit pre/post-state
6. Registry/Relation: node + domain + solution Links erfassen

Beispiel-Record

id: customer-acme
kind: customer
visibility: private
owner_actor: human-ops-01
domain: consulting
boundary_type: internal
state: active
relations:
  - type: served_by
    target: composition-delivery
  - type: has_project
    target: project-acme-rollout
private: Default für neue Kunden public nur mit Review + Publishing-Check

4. SOP: Neues Projekt anlegen

Projektanlage folgt immer Story → Plan → Work → Artifact → State. Ohne Story kein Projektstart.

SchrittPflichtfeldBLOCK wenn fehlt
Story definieren purpose, outcome, scope Kein klarer Outcome
Plan festlegen milestones, owner_role, due window Kein Owner oder unrealistischer Plan
Work starten assigned_actor, skill evidence Keine Skill-Abdeckung
Artifacts erzeugen docs/code/records mit Pfad Unversionierte oder unplatzierte Artefakte
State wechseln draft→active etc. als TX State-Sprung ohne TX 
id: project-acme-rollout
kind: project
customer_ref: customer-acme
story_ref: story-acme-rollout-001
plan_ref: plan-acme-rollout-v1
state: active
visibility: private

5. Tagesroutine für Admin (Checkliste)

P-ROOT P-BOUND P-STORY P-TXN P-LANG
Merksatz: Jede Aktion am Objekt, die den State ändert, muss als Transaction vorliegen. Kein State-Sprung ohne TX — sonst ist der Audit-Trail gebrochen.

6. Theme- und UI-Check für den Betrieb

Für den Alltag muss das Manual unter mehreren Themes lesbar bleiben. Nutze diesen Quick-Test nach größeren Content-Änderungen:

1. Seite mit Theme-Switcher laden
2. Mindestens Core-Theme + ein alternatives Theme wählen
3. Überschriften, Tabellen, Code-Blöcke, Chips visuell prüfen
4. Mobil-Breite prüfen (kein horizontaler Inhaltsschnitt)
5. Ergebnis als kurze TX/Notiz dokumentieren
theme-switcher source: iio/theme/theme-switcher.js
families config:      iio/theme/theme-families.json
manual shell:         iio/theme/_shell.js

7. Quellen für dieses Kapitel