AIJIM 1.0 Testanleitung
Das operative Handbuch fuer Tester: was AIJIM tut, was getestet wird, wie ein kompletter Pass laeuft, was als Bug zaehlt und was ausserhalb von 1.0 bleibt.
Ein gemeinsamer Demo-Space, ein persoenlicher Workspace, ein Pfad vom Erstellen zur Pruefung.
AIJIM 1.0 ist bereit, wenn ein neuer Nutzer sich einloggen kann, den gemeinsamen Demo-Workspace sieht, den persoenlichen Workspace betritt, Stories erstellt oder inspiziert, ein Trust File ueber den Core-eigenen Pfad erzeugt und oeffnet, ohne dass die App versteckte Fallback-Wahrheit erfindet.
Mehrere Tester arbeiten ueber normale Workspace-Mitgliedschaft gemeinsam im Demo-Workspace.
Jeder eingeloggte Nutzer erhaelt auch einen persoenlichen Workspace fuer Bearbeitung, die die Demo-Fläche nicht veraendern soll.
/workspaces`NamicGreen Newsroom` mit dem kanonischen Demo-Seed.
Wird pro Nutzer automatisch als isolierte Bearbeitungsflaeche erstellt.
`Müllmafia — Temporal Test (Schrottschiffe & Giftfrachter)`
Starte mit dem Zugangsmodell, dann Workflow, dann kompletter Pass.
Vor dem Start eine Tester-Einladung anfordern. Der aktuelle 1.0-Flow nutzt E-Mail-Login mit Magic Link an die eingeladene Adresse.
Nach dem Login die Workspace-Liste nutzen, um gemeinsamen Demo-Workspace und persoenlichen Workspace zu unterscheiden, bevor du eine Story erstellst oder bearbeitest.
Kann ein neuer Nutzer ohne Projektkontext das Trust File erreichen?
Fuehre diesen Test mit einer Person durch, die nicht an AIJIM gearbeitet hat. Gib ihr diese Seite, die App-URL und nur einen Satz: "Bitte pruefe, ob dieser Fall als Trust File geteilt werden kann." Erklaere keine AIJIM-Begriffe waehrend der Aufgabe. Jede Unsicherheit ist ein UX-Befund.
Startpunkt finden
Oeffne die App ueber den Doku-Link oder die bereitgestellte URL. Finde ohne Hilfe, wo du einen neuen oder bestehenden Fall starten wuerdest.
Bestehenssignal: Tester erreicht Workspace oder Work-Item-Flaeche und kann sagen, worum es im aktuellen Fall geht.
Eine Aussage erklaeren
Waehle eine sichtbare Aussage und erklaere, welche Quelle sie stuetzt oder warum sie noch nicht belegt ist.
Bestehenssignal: Tester kann Aussage, Quellenbezug und sichtbaren Status nennen, ohne technische IDs zu lesen.
Blockierten Overclaim bemerken
Finde heraus, ob der Fall einen naheliegenden, aber unbelegten Vorwurf oder Overclaim enthaelt.
Bestehenssignal: Tester erkennt, dass die unbelegte Aussage sichtbar ist und nicht still in die Story-Ausgabe aufgenommen wird.
Review-Pfad abschliessen
Entscheide, was passieren muss, bevor der Fall teilbar wird.
Bestehenssignal: Tester erkennt Review-Gates oder naechste Aktion, ohne aus verstecktem technischen Zustand raten zu muessen.
Trust File erstellen oder inspizieren
Finde die Trust-File-Aktion oder ein bestehendes Trust File. Lies das Deckblatt und erklaere, was der Empfaenger damit tun kann.
Bestehenssignal: Tester versteht, dass das Trust File das teilbare, unabhaengig pruefbare Artefakt ist, und nennt Falltext, Quellen und Pruefanleitung ohne technische IDs als Hauptinhalt.
Empfaenger-Pruefung erklaeren
Oeffne `/verify` oder beschreibe den Verifier-Schritt. Erklaere in normaler Sprache, was die Dropzone erwartet und was gruener PASS und roter FAIL bedeuten.
Bestehenssignal: Tester sagt: Trust File ablegen, Pruefung starten, unveraendertes Trust File besteht; geaendertes oder unvollstaendiges Trust File scheitert. Er sagt nicht, AIJIM garantiere Wahrheit.
Ein bestandener Stranger-Test braucht mindestens 10 von 12 Punkten und kein hartes Fail-Kriterium.
- Tester kann Quelle, Aussage, Review und Trust File nach dem Pass nicht unterscheiden.
- Tester glaubt, AIJIM garantiere Wahrheit, statt eine pruefbare Beweiskette zu bewahren.
- Tester findet nach Review oder Trust-File-Erstellung nicht, was als Naechstes zu tun ist.
- Tester sieht technische IDs, Hashes oder Commands als Hauptinhalt statt als Beweisdetails.
- Tester kann nicht erklaeren, warum eine unbelegte Aussage blockiert oder ausgeschlossen wird.
Beobachterregel
AIJIM ist ein gestuftes Quellenprotokoll, kein freier Editor mit KI obendrauf.
Rohmaterial kommt zuerst. Quellen sind das zulaessige Substrat; Story-Text steht nicht ueber ihnen.
Aussagen formalisieren Behauptungen und binden sie an Quellen plus Review-Status.
Analyse-, Render- und Trust/Stability-Runs erzeugen Manifeste und typisierte Artefakte, die inspizierbar bleiben.
Core erzeugt den Publication Record und das kanonische audit bundle hinter dem Trust File. Die App nicht.
Das Trust File paketiert den veroeffentlichten Text plus Audit-Material in einen portablen Ordner, der unabhaengig geprueft werden kann.
Operatives Modell
Was jedes Objekt in 1.0 ist und warum es wissenschaftlich zaehlt
Der operative Kollaborationscontainer. In 1.0 bekommt jeder Nutzer einen gemeinsamen Demo-Workspace und einen persoenlichen Workspace.
Das ist eine Koordinationsgrenze, keine wissenschaftliche Behauptung. Mehrere Tester koennen dasselbe Protokoll nutzen, ohne ein zweites Modell zu erfinden.
Der aktive narrative Container in 1.0. Auch wenn ein Team informell Dossier, Fall oder High-Stakes-Record sagt, ist das Runtime-Objekt heute eine Story.
Die Protokollbehauptung betrifft die Beziehung zwischen Quellen, Aussagen, Runs, Signatur und Verifikation, nicht ein domaenenspezifisches Label.
Nutzerseitiger Name fuer Rohmaterial: Dateien, Records, Links, Transkripte, extrahierter Text oder andere Primaerinputs.
Core nennt das weiter evidence. Es ist der I1-Anker. Eine Story kann nur vertrauenswuerdig werden, wenn ihre Aussagen quellengebunden bleiben.
Nutzerseitiger Name fuer eine explizite Behauptung im Entscheidungsfluss, gebunden an Quellen und Review-Status.
Core nennt das weiter claim. Aussagen sind der Ort, an dem Falsifizierbarkeit operativ wird. Sie koennen geprueft, belegt, bestritten oder offen bleiben, aber nie frei von Quellen schweben.
Eine typisierte Ausfuehrung wie ECAM-X, AEI-D, TCA oder Story Render, jeweils mit eigenem Artefaktvertrag.
Runs operationalisieren das Protokoll. Sie sind nur zulaessig, wenn sie die Artefakte ihres Run-Typs ausgeben. Im aktuellen 1.0-Test ist ECAM-X-Support der publikationskritische Pfad; AEI-D und TCA staerken Disclosure, sind aber keine universellen Publikationsvoraussetzungen.
Der Core-eigene, unveraenderbare Veroeffentlichungsakt, der Story-Revision, Render-Ergebnis und audit-bundle-Identitaet hinter dem Trust File bindet.
Das ist der reproduzierbare Wahrheitsanker fuer Runtime-Closure. Die App kann ihn nicht ehrlich selbst erzeugen.
Der portable Ordner mit veroeffentlichtem Text plus Bundle-Material fuer unabhaengige Pruefung.
Das ist die Audit-Replicability-Flaeche: Eine zweite Partei kann die Veroeffentlichung ausserhalb der App-UI pruefen.
Welche Fallarten Tester durchspielen sollten
AIJIM 1.0 ist weiter ein Runtime-Pfad, aber Tester sollten ihn ueber verschiedene High-Stakes-Formen hinweg pruefen. Das Runtime-Objekt bleibt eine Story; der Domaenenkontext aendert sich, nicht die Protokollgrammatik.
Illegale Ablagerungen, Muellschiffe, Beschaffungsunregelmaessigkeiten, quellengebundene lokale Recherchen.
Leishmaniose bei Hunden auf Mallorca, klinischer Quellenreview, strukturierte Fallinterpretation.
PFAS nahe Schulen, regulatorische Exponierung, Review von Umweltvorfaellen.
Diesen vollen Pass ausfuehren, bevor 1.0-Regressionen gemeldet werden.
1. Einloggen und Provisioning bestaetigen
Mit einem echten Tester-Account einloggen. Die erste Flaeche nach dem Login muss die Workspace-Liste sein.
Du siehst einen gemeinsamen Demo-Workspace (`NamicGreen Newsroom`) und einen persoenlichen Workspace (`Personal Workspace`).
2. Gemeinsame Kollaborationsflaeche bestaetigen
Den gemeinsamen Demo-Workspace oeffnen, zwischen Karte und Liste wechseln und die Falluebersicht pruefen, bevor etwas Neues erstellt wird.
Der kanonische Mallorca-Fall ist ueber Karte oder Liste sichtbar. Andere gemeinsame Faelle duerfen existieren, aber der Seed muss vorhanden bleiben.
3. Persoenliche Bearbeitungsflaeche bestaetigen
Den persoenlichen Workspace aus der Workspace-Liste oeffnen. Das ist der isolierte Bereich fuer freie Bearbeitung und Experimente.
Der Workspace laedt ohne Permission-Fehler. `Map`, `Stories`, `Read` und `Workspace` sind verfuegbar. Der persoenliche Workspace-Eintrag ist unter `/workspaces` mit dem Label `Personal Workspace` sichtbar.
4. Story-Huelle erstellen
Einen neuen Fall aus der Karte oder ueber den New-case-Pfad mit Titel, Ort und Basis-Metadaten erstellen. Fuer kollaborative Tests den gemeinsamen Workspace nutzen, fuer isolierte Arbeit den persoenlichen Workspace.
Ein neuer Fall wird erstellt und die kanonische Story-URL oeffnet sich. Wenn die Erstellung fehlschlaegt, darf kein stiller Fallback-Draft erscheinen.
5. Quellen hinzufuegen
Mehrere Quellen mit unterschiedlichen Formen hinzufuegen: Quellenlinks, hochgeladenes Material oder Textauszuege, wo unterstuetzt.
Quellen sind im Workflow sichtbar und spaeter referenzierbar. Der Fall kann ohne versteckte Auto-Ersetzung weiterlaufen.
6. Aussagen erstellen und pruefen
Quellen an Aussagen binden, diese explizit pruefen und Aussagen durch den sichtbaren Entscheidungsfluss bewegen.
Aussagen zeigen expliziten Review-Status. Nicht belegt, needs-review und offene Zustaende bleiben sichtbar, statt zu falschem Gruen zusammenzufallen.
7. Story-Ausgabe erzeugen und schaerfen
Story-Generierung ausfuehren, danach Reader-/Work-Flaeche nutzen und Analyse bei Bedarf aktualisieren.
Generierung endet entweder mit echtem Render-Ergebnis oder scheitert sichtbar. Die App darf lokal keinen fertigen Story-Text erfinden.
8. Trust File ueber den Core-Pfad erstellen
`Create Trust File` erst nutzen, nachdem Review-Gates erfuellt sind.
Trust-File-Erstellung gelingt nur, wenn die erforderlichen Support-Metadaten existieren. Fail-closed-Ablehnung ist korrekt, wenn erforderlicher Support fehlt.
9. Trust File oeffnen
Die Trust-File-Flaeche aus dem signierten Fall oeffnen. Vor dem Erzeugen eines Formats zuerst pruefen, ob das Deckblatt in normaler Sprache erklaert, was der Empfaenger bekommt.
Die Flaeche zeigt Trust File, Deckblatt, Falltext, Quellen und Pruefanleitung als Hauptinhalt. Workspace und Signer bleiben sichtbar; Hashes, IDs, Pfade und Commands sind nicht der Hauptinhalt.
10. Unabhaengig pruefen
Das Trust File wie ein Empfaenger pruefen: `/verify` oeffnen, Ordner oder Pruefinhalt ablegen und die drei sichtbaren Schritte lesen lassen. Wenn lokaler Checkout und Node verfuegbar sind, zusaetzlich den CLI-Verifier gegen den Trust-File-Ordner ausfuehren.
Der Empfaenger versteht ohne Login: Trust File ablegen, AIJIM prueft Integritaet und Signatur, gruen bedeutet unveraendert, rot bedeutet passt nicht mehr. Ein gueltiger Ordner liefert `AIJIM verify PASS`; fehlender Kontext muss ehrlich scheitern.
Warum jede Testphase mehr ist als einfaches UX-Klicken
| Phase | Runtime-Bedeutung | Wissenschaftliche Bedeutung |
|---|---|---|
| Provisioning und Zugang | Der richtige Nutzer landet ohne versteckte Zugangsregeln auf den richtigen Workspace-Flächen. | Das ist keine Theorem-Behauptung. Es ist die operative Voraussetzung, damit dasselbe Protokoll ueber Nutzer und Domaenen hinweg getestet werden kann. |
| Quellenaufnahme | Rohmaterial kommt vor Interpretation. Quellen existieren als inspizierbares Substrat. | Prueft I1 direkt. Interpretation ohne Quellen-Support liegt ausserhalb des Protokolls. |
| Aussagenbindung und Review | Aussagen werden explizit geprueft, mit Quellen verknuepft und in sichtbaren Entscheidungszustaenden gehalten. | Das ist die erste Falsifizierbarkeits-Schicht: Behauptungen bleiben nachvollziehbar und ruecknehmbar. |
| Runs und Render | Analyse- und Render-Pfade geben Manifeste und typisierte Artefakte aus, statt stiller UI-seitiger Schaetzungen. | Das traegt I2 und I3. Das System sagt nicht nur etwas; es gibt inspizierbare Gruende und Run-Outputs aus. |
| Signieren | Core erzeugt die kanonische Publication Identity hinter dem Trust File erst, wenn die erforderlichen Gates erfuellt sind. | Das ist der Runtime-Authority-Moment. Hier wird die Publikation zu einem reproduzierbaren, extern pruefbaren Objekt. |
| Trust File und Pruefung | Der signierte Record wird als portables Trust File paketiert und unabhaengig geprueft. | Das ist die praktische Bruecke von UI-Verhalten zu audit-replizierbarem Beweis. |
Was nach der Trust-File-Erstellung zu pruefen ist
# strikte pruefung node apps/aijim-verify/bin/aijim-verify.mjs <trust-file-folder> # optionaler disclosure report node apps/aijim-verify/bin/aijim-verify.mjs <trust-file-folder> --quality-report
Wohin Tester als Naechstes gehen
Was waehrend des Tests wahr bleiben muss
Wenn UI-Verhalten den Invarianten widerspricht, gewinnen die Invarianten. Testing ist nicht nur Feature-Klicken; es prueft, ob die Runtime das Quellen- und Audit-Protokoll weiter respektiert.
Jede nutzerseitige Aussage muss auf Quellenmaterial zurueckfuehren. Core-Records nennen das weiter evidence; es wird unveraenderbar erfasst und per Content Hash referenziert, nie in-place mutiert.
Jeder Analyse- oder Verifikationsrun erzeugt auditierbare Artefakte, die auf ihre Inputs zurueckfuehren. Runs ohne Artefakte sind ungueltig und duerfen downstream nicht referenziert werden.
Die Verifikationskette von Aussage zu Quelle muss navigierbar und vollstaendig sein. Intern ist das der claim -> evidence contract. Binding ist content-referenziert, nie ueber mutable Identifier.
Aktionen mit Governance-Wirkung - Signer Registration, Revocation, Rotation, Key Binding, Key Rotation, Key Revocation - brauchen menschliche Aufsicht. Confirmation Gates sind eine Auspraegung dieser Invariante, nicht die einzige.
Runs sind replaybar: Identische Inputs und Evidence Hashes reproduzieren dieselben Outputs. Idempotency Keys und append-only Audit Chains machen Replay zu einer Eigenschaft erster Klasse. Resolver sind pure Funktionen.
Gueltige Fail-closed- und Honest-Absence-Zustaende
- Eine fail-closed-Ablehnung der Trust-File-Erstellung, wenn erforderliche Support-Metadaten fehlen.
- `cannot-verify`-Zustaende, wenn Verifier oder Trust-File-Fläche den erforderlichen Kontext noch nicht haben.
- Offene wissenschaftliche Grenzen wie noch ungeloeste T.2- und T.4-Punkte.
- Die geparkte Universe-Fläche ist nicht Teil des aktiven Runtime-Pfads.
Was dieses Release noch nicht verspricht
- Wissenschaftlicher Abschluss von T.2 und T.4.
- Eine Tenant-/Team-Hierarchie. Kollaboration basiert in 1.0 weiter auf Workspace-Mitgliedschaft.
- Eine zweite Verifier-Implementierung in einer anderen Sprache. TypeScript/Node ist heute der kanonische Verifier.
- Die geparkte Future-Work-Linie fuer Tenant -> Team -> Workspace -> Case Profile.
Was nach der Testphase besser werden soll
Scope-Disziplin