inkcheck

Mechanische QA für ink-Geschichten. Kompilierungsprüfungen, begrenzte systematische Verzweigungserkundung, Reproduktionspfade für Laufzeitfehler und Erkennung toter Inhalte – als eigenständiges CLI für Autoren und Teams, mit optionalen CI- und MCP-Integrationen.

Agenten starten hier → SKILL.md – wann dieses Tool aufgerufen werden sollte, ausgearbeitete Beispiele, MUSS/MUSS-NICHT-Regeln. Familienvertrag: FAMILY.md.

inkcheck ist ein QA-Tool, kein Schreibwerkzeug. Es erzeugt, überarbeitet oder sendet kein einziges Wort Prosa weg. Es existiert, damit die Geschichte, die du geschrieben hast, mechanisch geprüft werden kann: Kompiliere sie mit dem offiziellen ink-Compiler, erkunde Auswahlpfade innerhalb expliziter Grenzen und reproduziere Fehler, bevor ein Spieler sie findet.

Verwendet es KI?

Nein. inkcheck selbst verwendet keine KI, kein maschinelles Lernen, keine LLMs oder generative Modelle, um Geschichten zu testen. Es trainiert nicht mit deinem Quellcode, leitet keine Prosaänderungen ab, schreibt Geschichtstext um oder sendet Geschichtsinhalte an einen KI-Dienst.

Es ist so konzipiert, dass Menschen, CI-Systeme und optionale KI-Agenten dieselben mechanischen QA-Prüfungen steuern können. Die eigentliche Prüfung ist deterministischer Code: der offizielle ink-Compiler, die ink-Laufzeit, begrenzte Verzweigungserkundung und strukturierte Berichte.

Related MCP server: RenForge MCP

Probier es in zwei Minuten aus

Mit Node.js 18 oder neuer:

npx -y inkcheck path/to/main.ink

Möchtest du den Fehlerpfad-Bericht sehen, bevor du deine eigene Geschichte testest? Führe die Zwei-Minuten-Synthese-Demo aus.

Produktversprechen

Inkcheck ist begrenzte mechanische QA für ink-Geschichten. Es beweist nicht, dass jeder Pfad in einer großen Geschichte funktioniert. Es erkundet deterministisch erreichbare Geschichtszustände innerhalb expliziter Grenzen, meldet exakte Reproduktionspfade für die gefundenen Probleme und zeigt, wo – und warum – die Abdeckung unvollständig war, damit Autoren es als kostengünstige, wiederholbare Regressionsabsicherung nutzen können.

Inkcheck wird nicht beweisen, dass eine große interaktive Geschichte keine Fehler hat. Kombinatorische Explosion ist real: Schleifen, Variablen, Zufälligkeit und Host-Spiel-Code können mehr mögliche Zustände erzeugen, als ein Tool erschöpfend besuchen kann.

Das Versprechen ist enger und nützlicher: mechanische Story-QA kostengünstig, wiederholbar und umsetzbar machen. Inkcheck durchläuft reale erreichbare Auswahlzustände innerhalb expliziter Grenzen, teilt dir mit, wenn der Lauf unvollständig war, und verwandelt Fehler in Reproduktionspfade, die du nach einer Korrektur erneut ausführen kannst. Wenn es heute einen defekten Pfad findet, sollte dieselbe konfigurierte Prüfung morgen in der Lage sein, diesen Pfad erneut zu suchen.

Dies ist ein Open-Source-QA-Projekt, weil diese Grenze wichtig ist. Wenn ein Bericht übermäßige Behauptungen aufstellt, ein offensichtliches Muster übersieht, eine bessere Traversierungsstrategie benötigt oder bei einer Geschichtsform scheitert, die du sicher teilen kannst, bring bitte ein Fixture oder ein Issue ein. Die Roadmap zielt darauf ab, partielle Abdeckung transparenter und wertvoller zu machen, nicht so zu tun, als würde partielle Abdeckung zum Beweis.

Produktrichtung und Selbstbewertung

Der zukünftige Wert von inkcheck soll aus einem reproduzierbaren Hybrid entstehen: breite gesäte Sonden, systematische lokale Inspektion, begrenzte Diversitätssuche und Ink-bewusste Spezialisten für Gates, Schleifen, Assertions und Storylet-Berechtigungen. Spezialisten müssen begrenzt bleiben und sich mehr Arbeit durch portfolio-neue Beweise verdienen, da auch sie Budgetfallen werden können.

Derselbe Handel gilt für Hardware. Lokale CLI- und One-Shot-MCP-Portfolioprüfungen verwenden standardmäßig einen deterministischen 1.024-Zustands-Live-Pilot, der kleine, tiefenbegrenzte und autorenfrontier-gesättigte Jobs sequenziell hält und nur für eine offene anhaltende Frontier begrenzte Worker aktiviert. Jeder Pilotzustand zählt unter der ursprünglichen globalen Obergrenze; die Suche wird nicht neu gestartet, um die Entscheidung zu treffen. Die abgeglichene Auswertung behielt exakte Beweise und verbesserte einen 5M-Zustands-, Tiefe-100-The-Intercept-Lauf um 25,6 %, während eingeschränkte und gehostete Jobs explizite sequenzielle Obergrenzen behalten. Siehe die Nebenläufigkeitsauswertung.

Dies sind separate Bewertungen, kein Durchschnitt. Eine hohe Vertrauensbewertung kann einen verlorenen Laufzeitfehler nicht ausgleichen. Die detaillierte Produkt- und Engineering-Wahrheiten-Scorecard definiert jedes 10/10-Ziel, aktuelle Beweise, technische Einschränkungen und das Neubewertungsprotokoll, das bei jedem Epic oder Release verwendet wird. Die erste vollständige Policy-v2-Promotionsauswertung hält dynamische Allokation experimentell, anstatt gemischte Beweise in eine Startbehauptung zu verwandeln.

Inkcheck 0.6 Umfang

Inkcheck 0.6 liefert das Anytime-QA-Fundament, ohne eine universell bessere dynamische Suchrichtlinie zu behaupten. Das etablierte begrenzte Portfolio bleibt der Suchstandard. Arbeitslastbewusste Nebenläufigkeit kann Ergebnisse nach links verschieben, wenn ein Live-Pilot genügend anhaltende Arbeit zeigt; langlebige Kampagnen können zurückkehren, fortgesetzt werden und quellgebundene Ergebniszeitfenster inspizieren; Menschen und Agenten können benannte Zeit-/Ressourcenhaltungen wählen; und jede automatische Entscheidung bleibt zurechenbar. Langschwanz-Expansion, Rotation und Stoppen bleiben nur Schatten, da das Drei-Familien-Promotionsgate keinen breiten autorenbezogenen Wert etablierte, um sie live zu schalten.

Dies ist ein abgeschlossener Release-Vertrag, keine Behauptung, dass das größere Forschungsproblem gelöst ist. Dynamische Erste-Fenster-Größenanpassung, kompakte große Checkpoints, anbieterzugeschriebene Kosten, breitere Agentenauswertung und begrenzte Spezialisten-Explorer bleiben separat verfolgte Roadmap-Arbeit. Ein zukünftiges Release kann das feste Portfolio nur ersetzen, nachdem geprüfte Beweise dieselben kritischen Retentions-, Wiedergabe-, Ressourcen- und Ehrlichkeitsgates bestehen.

Inkcheck 0.7: Regeln, die zählen

Inkcheck 0.7 macht autoren-deklarierte Invarianten erstklassig im gehosteten Checker sowie in lokaler Konfiguration, CI und MCP. Ein Autor kann eine optionale numerische Regel wie gold >= 0 im Web-Flow hinzufügen; sie wird in einfacher Sprache und generierter typisierter Konfiguration vor dem Lauf angezeigt, während der gewöhnlichen begrenzten QA geprüft und bei Verletzung mit einem exakten Wiedergabezeugen gemeldet. Der Web-Flow erkennt deklarierte Ink-Variablen zur Auswahlhilfe, aber der Server bleibt maßgeblich: unbekannte Variablen, ungültige Typen und nicht unterstützte Grammatik schlagen vor der Erkundung fehl; temporäre Regelkonfiguration wird mit dem Upload gelöscht. Agenten können typisierte Regelvorschläge entwerfen, dürfen sie jedoch nicht stillschweigend autorisieren. Version 0.7.2 fügt auch private QA-Beweis-Pins hinzu: Ein genehmigter Laufzeit-, Assertions- oder Zielzeuge kann nach einer Bearbeitung ohne erneute Suche überprüft werden, während ein frischer begrenzter Lauf für eine breite Verifizierung weiterhin erforderlich ist.

Ein separater assertionsgerichteter Spezialist bleibt opt-in und experimentell. Er erhält kein Standardbudget, ändert die Scorecard nicht und beansprucht keine bessere Abdeckung, bis er sein vorregistriertes Beweisgate besteht. Der Vertrag „Regeln, die zählen“ definiert beide Grenzen.

Agentenkampagnen-Richtlinien

MCP-Agenten können eine langlebige Kampagne mit einem hochrangigen quick, balanced, deep, overnight- oder campaign-Modus starten, anstatt Explorer-Gewichte zu erfinden. balanced ist der Standard für neue Agenten; fixed bewahrt explizite Legacy-Kontrollen. Begrenzte Überschreibungen können Zustands-/Fenster-/Zeit-/Speicher-/Festplatten-/Frist-Haltung, knappe/ausgewogene/reichliche Ressourcen, bevorzugten Wert (broad_qa, runtime_assertions, outcomes oder approved_goals), geschützte Langschwanzarbeit und ceilings- versus knee-Stopp ändern. Exakte Basisfenster bleiben assertions-/zielfrei und fortsetzbar. Geschützte Langschwanz-Allokationen starten jetzt deterministische wurzelgestartete Portfolio-Kinder mit einem alternativen Such-Seed und tieferer Grenze, während sie den exakten Basis-Checkpoint bewahren. Eine runtime_assertions-Kampagne kann validierte Assertionsfenster mit add_assertions hinzufügen; eine approved_goals-Kampagne kann ein validiertes Ziel mit add_goal hinzufügen. Jedes Kind verwendet eine explizite Zuteilung, speichert einen separaten Beweisbericht und erhält nur Anerkennung für kampagnen-neue kritische, Absichts-, Autorenknoten- oder Terminalbeweise.

Die erste Auswertung von autorenbasierten Kampagnen-Kindern fand einen glaubwürdigen Lead zur Überprüfung veralteter Variablen und eine abgelehnte Assertionshypothese bei The Intercept. Ihr gestuftes Ziel verfehlte, beide Hochbudget-Kinder stoppten vor 5M wegen Speicher, und eine 500K geteilte Basis überschritt die Obergrenze für dauerhafte Checkpoints. Das ist vielversprechender Assertionswert plus eine klare Warnung: Von Agenten verfasste Regeln benötigen menschliche Validierung, Spezialisten benötigen Sonden-zu-Expansions-Ökonomie, und kompakte Checkpoints sind erforderlich, bevor große Kampagnen Routine werden.

Die abgeglichene unabhängige Langschwanz-Auswertung verglich dann eine wachsende gemeinsame Frontier mit geschützten wurzelgestarteten Portfolio-Partitionen. Bei einer 5M-Intercept-Kampagne stoppte der gemeinsame Arm wegen Speicher bei 786.559 Gesamtzuständen; neun unabhängige Kinder schlossen alle 5M bei niedrigerem Spitzen-Heap ab und schrieben 3.558 kampagnen-neue Terminalvarianten gegenüber 407 gut. Sie fanden kein neues kritisches Problem, keinen Autorenknoten und kein sichtbares Ende. Dies ist ein Beweis für ressourceneffiziente Diversität und messbare abnehmende Erträge, keine universelle QA-Wertbehauptung.

Das anschließende Drei-Familien-0.6-Promotionsgate hat dynamisches Stoppen oder Expansion nicht befördert. Dog Ink Adventure und Heresy II erreichten beide eine Ressourcengrenze, bevor ihre 500K-Basis einen fortsetzbaren Checkpoint produzierte, sodass keine Langschwanz-Richtlinie handeln konnte. Bei The Intercept erreichten unabhängige Partitionen 4,66M Zustände bei 1,40 GiB Spitzen-Heap, während die wachsende Frontier bei 787K Zuständen und 3,70 GiB stoppte; Terminal-Wiederentdeckung stieg von 34 % auf 94 %, ohne neues kritisches Problem, Autorenknoten oder sichtbares Ergebnis. Inkcheck behält diese Empfehlungen nur als Schatten und behandelt dynamische Erste-Fenster-Größenanpassung als die stärkere nächste Produktanforderung.

Jedes Ergebniszeitfenster gibt eine stabile Policy-ID, Allokationsgrund, gemessene bevorzugte Ausbeute, Durchsatz-/Ressourcenbeweise, ein unsicherheitsgekennzeichnetes empirisches Bereich für ein weiteres Fenster, jede bindende Einschränkung und die Berichts-ID zurück, die zur Inspektion vollständiger Kurven oder Ergebnisse verwendet wird. Kompakte Inspektion nennt auch den Zweck, die Partition und die marginale Ausbeute des neuesten Fensters. Ein Knie erfordert drei aufeinanderfolgende Fenster ohne bevorzugte Ausbeute und kann geschützte Sonden nicht verbrauchen. Es bleibt eine begrenzte Beobachtung über die tatsächlich ausgeführten Trajektorien, keine Behauptung, dass die Geschichte abgedeckt ist oder dass spätere Entdeckungen nicht existieren. Siehe den Kampagnenrichtlinien-Vertrag und den MCP-Ergebniszeitfenster-Leitfaden.

Nachdem unabhängige Kinderläufe abgeschlossen sind, umfasst die kompakte Entscheidung auch eine versionierte nur-Schatten-Langzeit-Empfehlung: dieselbe Familie erweitern, zu einer anderen Partition wechseln oder nach der geschützten Untergrenze stoppen. Sie verwendet den Kampagnen-Neu-Wert unter der ausgewählten Präferenz, meldet den aktuellen Ertrag pro Zustand und Sekunde, erfordert progressiv mehr Trocken-Sonden für knappe/ausgewogene/reichliche Haltungen und legt die kompakte Neuentdeckung des ausgewählten Werts sowie faktische berichtsbezogene Entdeckungslücken offen. Ältere Journale markieren diese Signale als nicht verfügbar. Neuentdeckung ist Identitätsüberlappung mit früheren Kampagnenberichten, nicht rohe Duplikat-Zustandsarbeit; wachsende Lücken sind Beobachtungen, kein Beweis für ein Plateau. liveEffect: false bedeutet, dass diese Evidenz die Zuteilung noch nicht ändern kann.

Menschen können dieselbe dauerhafte Richtlinie nutzen, ohne ihre Steuerungen zu lernen: inkcheck campaign story.ink führt die ausgewogene Absicht aus, während --mode quick, deep oder overnight eine Ergebnis-und-Zeit-Haltung wählt. Es gibt unveränderliche quellgebundene Ergebnisfenster zurück, während die Arbeit fortschreitet, bewahrt den neuesten Teilbericht bei einer Frist oder einem Abbruch zwischen Fenstern und hält technische Zustands-/Zeit-/Speicher-/Plattenobergrenzen als Experten-Overrides verfügbar. Ergebnisfenster trennen aufgewendete Arbeit, verwertbaren Ertrag, Prognoseunsicherheit und ob die Suche fortgesetzt werden kann. Ein ruhiges Entdeckungsintervall oder ein beobachteter Knick wird nie als vollständige Abdeckung beschrieben.

Schnellstart

Mit Node.js 18 oder neuer:

npx -y inkcheck path/to/main.ink

Keine globale Installation erforderlich. Der erste Lauf lädt den festgelegten offiziellen Ink-Compiler herunter, verifiziert seinen SHA-256-Hash und verarbeitet die Geschichte lokal.

Projektkonfiguration

Committen Sie eine inkcheck.yml, wenn ein Projekt für jede menschliche oder Agenten-Sitzung denselben Einstiegspunkt und dieselben begrenzten CI-Einstellungen verwenden soll:

schemaVersion: 1
entrypoint: story.ink
ci:
  maxDepth: 100
  maxStates: 1000000
  goalMaxStates: 250000
  seed: 1
  storySeed: 1
  search: portfolio
  concurrency: auto
  strict: true
assertions:
  - id: gold_nonnegative
    description: Gold never goes negative
    when: always
    condition:
      left: { variable: gold }
      operator: ">="
      right: { literal: 0 }
goals:
  - id: depleted_gold
    description: Seek paths where the player runs out of gold
    condition:
      left: { variable: gold }
      operator: "<="
      right: { literal: 0 }

Führen Sie inkcheck validate-config aus, um sie zu prüfen. Von diesem Verzeichnis aus verwendet inkcheck den konfigurierten Einstiegspunkt und die Standardwerte; explizite CLI-Flags haben weiterhin Vorrang. Unbekannte Schlüssel führen zu einem Validierungsfehler, sodass nicht unterstütztes externes Verhalten und Bearbeitungsrichtlinienfelder nicht als implementiert erscheinen können. Der veröffentlichte Vertrag ist Konfigurationsschema v1.

Assertions sind typisierte Daten, niemals JavaScript oder beliebige Ink-Ausdrücke. Operanden sind Variablen oder skalare Literale; Vergleiche verwenden ==, !=, <, <=, > oder >=, und Bedingungen können mit all, any und not zusammengesetzt werden. Regeln laufen immer, bei Endzuständen oder beim Betreten eines benannten Knotens. Unbekannte Variablen/Knoten und ungültige typrübergreifende Vergleiche schlagen fehl, bevor die Erkundung ihr Zustandsbudget verbraucht. Eine Verletzung führt immer zu einem CI-Fehler und enthält die beobachteten Werte plus einen exakten indizierten Wiederholungszeugen. Ein begrenzter sauberer Lauf bedeutet nur „keine Verletzung beobachtet“; nur ein erschöpfender Lauf meldet die Regel als erschöpfend verifiziert.

Ziele verwenden dieselbe nicht ausführbare Bedingungsgrammatik, leiten aber die Erkundung, anstatt CI fehlschlagen zu lassen. Die allgemeine Erkundung erhält immer das volle maxStates-Budget. Setzen Sie goalMaxStates in der Konfiguration oder --goal-states in der CLI, um eine explizite deterministische Zielnähe-Scheibe hinzuzufügen; der Standardwert ist null, und das kombinierte Budget darf 100.000.000 Zustände nicht überschreiten. Ziele werden auch während der gewöhnlichen Erkundung beobachtet, wenn keine zusätzliche Scheibe angefordert wird. Ein erreichtes Ziel enthält exakte Auswahlindizes; ein Fehlschlag sagt not_reached_within_limits, es sei denn, die erschöpfende Erkundung beweist tatsächlich, dass es unerreichbar ist. Berichte legen Basis-, Ziel- und Gesamtbudgets getrennt offen, sodass Steuerung nicht stillschweigend allgemeine QA-Ergebnisse verdrängen kann. Siehe die Vergleichsevidenz in Suchexperimenten.

Für eine späte zusammengesetzte Abhängigkeit ersetzen Sie condition durch zwei oder mehr geordnete stages. Jede Stufe verwendet dieselbe typisierte Grammatik. Inkcheck sucht den ersten unerfüllten kumulativen Meilenstein, sodass eine spätere Stufe nur auf einem Pfad erreicht wird, dessen Zustand auch jede frühere Stufe erfüllt. Ein verpasstes Voraussetzungsziel lässt spätere Stufen blocked_by_stage; es nennt sie nicht unerreichbar. Dieser erste gestufte Vertrag verwendet ein gemeinsames zusätzliches Zielbudget und startet deterministisch von der Geschichtenwurzel neu, anstatt Laufzeit-Checkpoints zu serialisieren.

Für ein neues Projekt mit einer .ink-Datei erstellt inkcheck init diese Konfiguration. Mehrdatei-Projekte müssen die Wurzel mit --entrypoint benennen. inkcheck agent-kit --format codex fügt die Konfiguration bei Bedarf hinzu, ein festgelegtes GitHub-Actions-Beispiel, .inkcheck/-Artefakt-Ignorierregeln und kompakte versionsabgestimmte Agentenanweisungen. Beide Befehle sind idempotent und prüfen jedes Ziel vorab; sie verweigern die gesamte Operation, anstatt vorhandene erstellte Dateien zu überschreiben oder teilweise zu ändern. Das npm-Artefakt enthält auch die kanonische skills/inkcheck/SKILL.md, progressive Ink-/Workflow-Referenzen und zehn ausführbare goldene Übungen. inkcheck capabilities --json bewirbt dies als features.bundledAgentSkill und bleibt die Autorität für den installierten Schemavertrag.

--save-report speichert atomar einen versionierten Bericht unter .inkcheck/reports/ und gibt seine stabile, aus Inhalt und Einstiegspunkt abgeleitete ID zurück. Eine spätere Sitzung kann inkcheck artifacts list --json und inkcheck artifacts show <report-id> --json verwenden; das erneute Öffnen meldet, ob die gespeicherte Evidenz current, stale oder path_changed gegenüber dem aktuellen Einstiegspunkt ist. Berichte können Geschichtentext, Variablen und exakte Zeugen enthalten, daher ignoriert das Agenten-Kit sie standardmäßig. Siehe lokale Berichtsartefakte für den Vertrauens-, Datenschutz- und Kompatibilitätsvertrag.

Lange basisgeteilte Läufe können auch ihre exakte Live-Frontier lokal persistieren. Starten Sie mit --search=shared --no-min-repro --save-checkpoint und setzen Sie später mit inkcheck resume <checkpoint-id> --max-states N fort; N ist die größere Gesamtbewilligung, nicht zusätzliche versteckte Arbeit. inkcheck checkpoints list/show meldet begrenzte Metadaten, dauerhafte komprimierte Größe, Speicherkodierung und Quellfrische. Neue Checkpoint-Dateien werden als gestreamte gzip-Artefakte geschrieben; ältere einfache Schema-v1-JSON bleibt lesbar. Checkpoints sind privat, atomar, quell-/konfigurationsgebunden, standardmäßig ignoriert und aufbewahrungsbegrenzt; sie können erstellten Text und Laufzeitzustand enthalten. Siehe lokale fortsetzbare Checkpoints. Geteilte Läufe legen auch ein begrenztes Ressourcen-/Ertrags-Beobachtbarkeitsjournal offen, das deterministische logische Buchführung von Live-Heap-/RSS-Beobachtungen getrennt hält. MCP-Agenten können dieselbe exakte Grundlage durch dauerhafte start_search / inspect_search / continue_search / cancel_search-Ergebnisfenster nutzen. Sie können auch add_goal für eine explizite additive gerichtete Sonde verwenden, die von der Geschichtenwurzel startet und diese exakte Basisfrontier unberührt lässt. Portfolio, gemeinsame Variablen, Assertions, gerichtete Frontier-Fortsetzung und gehostete Aufträge verwenden diesen Checkpoint-Vertrag noch nicht.

Gehosteter Prüfer

Das Repository enthält jetzt eine selbst gehostete Weboberfläche für Autoren, die kein Terminal verwenden möchten. Der gehostete Modus lädt vorübergehend autorisierte .ink-Quellen hoch, bietet Quick (früheres 250K-Zustands-Ergebnis) und Balanced (tieferes 1M-Zustands-Ergebnis) Absichten, erstellt einen kurzlebigen privaten Auftrag, streamt echte Arbeit, Ertrag und Unsicherheitssignale und löscht das temporäre Auftragsverzeichnis nach Abschluss, Abbruch oder Fehler. Abgeschlossene gehostete Prüfungen geben eine quellgebundene Ergebnisfenster-Identität und stabile Befund-IDs zurück. Es macht Berichte nicht öffentlich und behält keinen Geschichtentext in Anwendungsprotokollen. Optionale Erstanbieter-Nutzungsmetriken behalten tägliche Aggregatzahlen plus eine datenschutzerhaltende, ungefähre tägliche Einzelbrowser-Schätzung: Keine IPs, Benutzeragenten, Browser-Token oder Besucherprofile werden gespeichert.

Die lokale CLI bleibt die datenschutzfreundlichste Option, da kein Geschichten-Upload erfolgt. Siehe Gehosteter Prüfer-Bereitstellung für das Bedrohungsmodell, Docker-Bereitstellung, Betriebsgrenzen und ein aktuelles Budget unter 50 $/Monat.

Was es erkennt

• Kompilierungsfehler und Warnungen — defekte Diverts, unaufgelöste Variablen, lose Enden, mit Datei- und Zeilennummern (über inklecate, den offiziellen Compiler)

• Laufzeitfehler mit Reproduktionspfad — die exakte Abfolge von Entscheidungen, die eine Division durch Null, einen schlechten externen Aufruf oder Out-of-Content auslöst, z. B. repro: [Enter in darkness → Descend to the cellar]

• Mögliche nicht terminierende erzwungene Entscheidungszyklen — ein konservativer Überprüfungshinweis, wenn die einzige verfügbare Wahl zum selben Kontrollzustand mit denselben autor-sichtbaren Variablen zurückkehrt; optionale Ausgänge, Zufallsverhalten, Zugzähler, Besuchszähler und EXTERNAL-Aufrufe sind absichtlich ausgeschlossen

• Nicht besuchter Inhalt, triagiert — Knoten, die kein erkundeter Pfad innerhalb der konfigurierten Grenzen besucht, jeweils klassifiziert mit einem eingehenden Divert-Scan: „keine autorisierten Divert-Punkte hier — mögliches Waisenkind“ versus „hat eingehende Diverts — wahrscheinlich jenseits der Grenzen dieses Laufs“

• Unterschiedliche Endzustände — mit einer Entscheidungsspur, die jeden erreicht; unterschiedliche Endvariablen werden als unterschiedliche Ergebnisse beibehalten

vs. die Alternativen

Der Compiler sagt Ihnen, dass die Geschichte gültig ist. Durchklicken sagt Ihnen, dass die Pfade, die Sie zufällig geklickt haben, funktionieren. Ink-Tester sampelt wiederholt zufällige Durchspielungen und meldet zeilenweise Häufigkeit; inkcheck geht stattdessen systematisch Entscheidungszustände durch und gibt kurze Fehlerpfade zurück. Der Hauptunterschied ist Wiederholbarkeit: Nachdem Sie einen gemeldeten Pfad behoben haben, kann derselbe konfigurierte Lauf diesen Pfad erneut prüfen. Die Ansätze sind komplementär, besonders für Geschichten mit Zufall oder Engine-Integrationen.

Beispiel

$ inkcheck examples/manor.ink
✓ compiled — 92 words, 7 knots, 6 choices
✓ explored 18050 states within limits (depth 100, 10000000 states, seed 1) — exhaustive (every reachable state visited) — 5 distinct terminal state(s)
    terminal via [Enter in darkness → Search the study → Leave with your loot]: "You slip out the servant door, heavier by half a purse."
    ...
✗ 1 runtime error(s):
    obj is null or undefined (at cellar.3)
      repro: [Enter in darkness → Descend to the cellar] (found by dfs:last)
⚠ 1 knot(s) never visited on any explored path — unreached is not necessarily unreachable:
    treasure_vault (manor.ink line 35) — no authored divert points here — possible orphan

Wenn ein Lauf vorzeitig beendet wird, nennt der Bericht die Grenze, die ihn tatsächlich begrenzt hat — zum Beispiel ⚠ Abdeckung ist teilweise, kein Beweis — Pfade wurden bei 30 Entscheidungen Tiefe abgeschnitten; erhöhen Sie --max-depth, um längere Spuren zu verfolgen. Tiefe und Zustandsbudget sind getrennte Achsen: In lokalen Läufen von The Intercept erreichte die Erhöhung von --max-depth von 30 auf 100 mehr späten Geschichteninhalt mit einem Budget von 1.000.000 Zuständen als ein 10× größeres Budget bei Tiefe 30.

Der Exit-Code ist bei Kompilierungs- oder Laufzeitfehlern ungleich null. Fügen Sie --strict hinzu, um auch bei Warnungen, nicht besuchten Knoten, Abschneidungen oder externen Stubs fehlzuschlagen, sodass partielle Abdeckung nicht stillschweigend CI bestehen kann.

Eine Geschichte muss nicht lang sein, um das Standardbudget zu überschreiten. Inkle's veröffentlichtes The Intercept wird von der Community als relativ kleine Quelldatei angesehen, dennoch meldet Inkcheck sie bei 5.000.000 Zuständen als teilweise: Verzweigung plus persistente Variablen erzeugt einen erreichbaren Zustandsgraphen, der weit größer ist, als die sichtbare Entscheidungsanzahl vermuten lässt. Erschöpfung ist ein beobachteter Beweis, keine aus der Quelldateigröße abgeleitete Erwartung. Eine endlichwertige Geschichte kann prinzipiell erschöpfbar, aber unpraktisch aufzuzählen sein; Zug-, Zufalls- oder unbegrenzte Variablenzustände können den semantischen Graphen unbegrenzt machen. Ein begrenzter Lauf stoppt bei dem, was zuerst eintritt — Zustand, Tiefe, Zeit oder Speicher — und sagt, welches. Der gehostete Prüfer begrenzt gemeinsame Aufträge auf 1.000.000 Zustände; größere Aufträge (bis zur CLI-Obergrenze von 100M) gehören lokal. Siehe Leistung und Speicher für Größenrichtlinien.

Innerhalb eines einzelnen Laufs verteilt inkcheck sein Zustandsbudget auf komplementäre Suchdurchläufe, anstatt alles auf eine einzige Traversierungsreihenfolge zu setzen. Das aktuelle CLI-Portfolio erkundet Last-Choice-First-, First-Choice-First- und Inside-Out-DFS-Slices, fügt eine geseedete Zufallsstichproben-Slice hinzu, die frühe Choice-Präfixe variiert, die die deterministischen Durchläufe tendenziell wiederholen, fügt einen Frontier-begrenzten Diversity-Beam hinzu, der sich wie BFS Ebene für Ebene vorarbeitet, während er einen Zustand pro Variablen-Signatur-Linie behält, und reserviert dann eine kleine Breitensuche-Slice, um Repro-Pfade zu verkürzen. Die Zufalls-Slice verwendet einen festen Standard-Seed und der Beam benötigt überhaupt keinen Seed, sodass Läufe in CI reproduzierbar bleiben; jeder gemeldete Endzustand und Laufzeitfehler benennt den Durchlauf (und Seed), der ihn gefunden hat. Dies findet oft mehr Endzustände und erreichbare Knoten bei demselben --max-states-Limit, aber es ist immer noch begrenzte QA: Ein abgeschnittener Bericht ist nützlicher Beweis, kein erschöpfender Beweis.

--search=shared aktiviert eine experimentelle Alternative: Tiefe, Neuheit-zuerst- und geseedete Ansichten beziehen aus einer deduplizierten Frontier, und jeder erreichbare Zustand wird höchstens einmal expandiert. Dies kann ein knappes Budget effizienter ausgeben, wenn mehrere Strategien sonst denselben Zustand wiederentdecken würden. JSON-Telemetrie trennt ausstehende und aktive Checkpoint-JSON/Variablen, beibehaltene Witness-Abstammung, Dedupe- und semantische Indizes, Frontier-Referenzen und Befunde; sie meldet auch freigegebene Abstammung und Kompaktionen veralteter Ansichten. Dies sind deterministische, verbuchte Payload-/Strukturschätzungen, nicht exakte V8-Heap-Nutzung. Es ist noch nicht der Standard: Einige frühe Choice-Strukturen könnten weiterhin die unabhängigen Zufalls- und Beam-Durchläufe des Portfolios bevorzugen.

Bibliothekskonsumenten, die langlaufende Shared-Jobs evaluieren, können exploreSharedResumable(...) verwenden. Wenn Budget übrig bleibt, gibt es einen quellgebundenen, versionierten JSON-Checkpoint zurück, der die exakte Live-Base-Shared-Frontier enthält; ein späterer Aufruf erhöht die Gesamtzuteilung (z. B. von 100k auf 1m) und fährt fort, ohne die ersten 100k erneut abzuspielen. Die Äquivalenz von geteilten Läufen wird gegen einen ununterbrochenen Lauf regressionstestet. Dies ist ein Engine-Fundament, noch keine CLI-Persistenzfunktion: Checkpoints können verfassten Text, Variablen, Laufzeitzustand und Witness-Pfade enthalten, und Schema v1 schließt bewusst Assertions, Ziele und variablen-/zielbewusste Shared-Modi aus. Siehe Shared-Checkpoint-Schema v1.

--search=shared-variable ist ein engeres Experiment, das 12,5 % der Shared-Frontier-Auswahlen an Zustände vergibt, die über ungewöhnliche Variablen-Snapshots oder Übergänge erreicht werden. Der Boost ist begrenzt, und die tiefen, Neuheit- und geseedeten Ansichten bleiben aktiv. Es kann mechanisch getriebenen Storylet-Graphen helfen, ist aber nicht gleichmäßig besser; die eingecheckte Vergleichstabelle enthält sowohl Gewinne als auch Regressionen.

Das adaptive Portfolio bleibt der allgemeine Standard. Experimentelle Modi ändern weder seine Gewichte noch sein Verhalten. Die Suchstrategie-Richtlinie von inkcheck definiert die Benchmark-Breite und Regressions-Gates, die vor jeder zukünftigen Standardänderung erforderlich sind.

Begrenzte Suche vs. Zufallsstichprobe

Inkcheck ist kein Versprechen, jeden möglichen Zustand in einer nicht-trivialen Geschichte zu besuchen. Verzweigungen, Schleifen, Variablen, Zufallsverhalten und Host-Spiel-Integrationen können eine erschöpfende Abdeckung physisch unpraktisch machen. Sein praktischer Vorteil gegenüber Zufallsstichproben ist Reproduzierbarkeit: Bei derselben Geschichte und denselben Limits durchläuft inkcheck den Choice-Graphen systematisch, gibt exakte Choice-Pfade für Fehler zurück, meldet Hinweise auf unbesuchte Knoten und sagt explizit, wenn der Lauf partiell war.

Zufallsstichproben bleiben nützlich, besonders für Geschichten mit Zufälligkeit oder riesigen Zustandsräumen. Behandeln Sie die Ansätze als komplementär: Zufälliges Spielen kann in überraschende Pfade stolpern, während inkcheck deterministische, CI-freundliche Beweise innerhalb eines deklarierten Budgets liefert.

In einem lokalen Test von The Intercept bei einem Tiefenlimit von 30 fanden höhere Budgets mehr terminale Zustände, bewiesen aber immer noch keine vollständige Abdeckung. Zeitmessungen stammen von einer lokalen Entwicklungsmaschine und sollten als Skalenbeweis gelesen werden, nicht als universeller Benchmark:

Das ist die beabsichtigte Interpretation: Jeder Lauf testet echte erreichbare Zustände und kann echte defekte Pfade aufdecken, aber ein abgeschnittener Bericht ist Beweis für das, was besucht wurde, nicht Beweis dafür, dass alles erreichbar oder korrekt war.

Leistung und Speicher

Das Standardbudget beträgt 10.000.000 Zustände und die Obergrenze liegt bei 100.000.000, daher lohnt es sich zu wissen, was ein großer Lauf kostet. Zwei Ressourcen begrenzen einen Lauf: Zeit und Speicher. Kleine oder erschöpfbare Geschichten berühren keines von beiden – das Portfolio bricht früh ab, sobald ein systematischer Durchlauf den erreichbaren Raum als vollständig beweist, sodass inkcheck small.ink in den wenigen Zuständen, die es hat, fertig wird, unabhängig vom Standard. Die Zahlen unten sind nur für große, nicht erschöpfende Geschichten relevant.

Zeit skaliert ungefähr linear mit den erkundeten Zuständen. Auf einer Entwicklungsmaschine lief The Intercept etwa 200 Sekunden pro Million Zustände (siehe Tabelle oben), also dauert ein 10M-Zustands-Lauf zig Minuten und ein 100M-Lauf Stunden. Es gibt kein Wanduhr-Limit für das lokale CLI, daher für CI oder interaktive Nutzung --max-states auf die Abdeckung festlegen, die Sie tatsächlich benötigen, anstatt sich auf den Standard zu verlassen – oder den Standard mit --progress ausführen (standardmäßig in einem interaktiven Terminal aktiv), damit Sie zuschauen und unterbrechen können.

Speicher ist eine Summe von Termen mit unterschiedlichem Wachstum, und das ist der Grund, warum die Obergrenze hoch statt gefährlich ist:

Zwei praktische Faustregeln daraus:

• Heap budgetieren, nicht nur Zustände. Als Worst-Case-Schätzung (ohne Zustandsdeduplizierung) planen Sie etwa 2 GB Heap pro 10M verschiedenen Zuständen. Geschichten mit Schleifen deduplizieren stark und verbrauchen viel weniger; eine Geschichte mit geringer Deduplizierung kommt nahe an den Worst Case. Ein 10M-Zustands-Lauf im Worst Case (~2 GB) liegt also nahe am Standard-Heap-Limit von Node: Eine schleifenlastige Geschichte bleibt deutlich darunter, aber eine große mit geringer Deduplizierung kann die Speichergrenze erreichen, bevor sie selbst beim Standardbudget fertig ist. Ein 100M-Zustands-Lauf überschreitet einen normalen Standard-Heap und stoppt an der Grenze, es sei denn, Sie erhöhen --max-old-space-size. In beiden Fällen stoppt es sauber mit einem partiellen Bericht – die Grenze ist das, was die hohe Obergrenze sicher macht, nicht ein Versprechen, dass der Lauf abgeschlossen wird.

• Die Speichergrenze ist der eigentliche Begrenzer, nicht die Obergrenze. Ein Lauf stoppt sauber bei 85 % des V8-Heaps (oder Ihrem --max-memory) und gibt einen partiellen Bericht mit truncatedBy.memory zurück, anstatt abzustürzen. --max-states 100000000 zu setzen ist also nicht leichtsinnig – auf einer normalen Maschine entscheidet die Grenze, nicht die Obergrenze, wo es stoppt. Um weiter zu gehen, geben Sie Node mehr Heap: NODE_OPTIONS=--max-old-space-size=8192 inkcheck big.ink --max-states 100000000.

• Sicherheitslimits sind keine Effizienzentscheidungen. Zustands-, Zeit- und Speichergrenzen beantworten „Wie weit darf dieser Job gehen?“ Sie behaupten nicht, dass die Nutzung der gesamten Maschine wertvoll ist oder dass ein scheinbares Plateau vollständig ist. Der 0.6-Forschungspfad misst Portfolio-neue Befunde über die Zeit, Durchsatz, Erholungslücken, Spitzen-RSS und beibehaltene Frontier-Bytes, damit zukünftige Schnell-/Ausgewogen-/Tief-Richtlinien nützliche Ergebniszeitfenster wählen können, während sie weiterhin Long-Tail-Sonden reservieren. Feste Limits bleiben für CI und Audit verfügbar.

Hebel, in der Reihenfolge ihrer Wirkung, wenn eine Geschichte zu groß zum Beenden ist: --max-old-space-size erhöhen (mehr Spielraum), --no-min-repro übergeben (entfernt die superlineare BFS-Frontier), --max-states senken (begrenzt sowohl Zeit als auch Speicher) oder die Geschichte aufteilen und Teile separat prüfen. Im experimentellen Shared-Modus setzen Sie --max-frontier-memory oder --max-frontier-states, wenn die Warteschlange ausstehender Checkpoints selbst eine engere Grenze benötigt, und erhöhen Sie diesen Envelope nur, wenn sein Bericht zeigt, dass weiterhin nützliche Beweise eintreffen. Das nextRun-Urteil benennt nach jedem Lauf das bindende Limit, damit Sie wissen, welcher Hebel gilt.

Die gemessene ressourcensichere Tiefenlauf-Evaluierung dokumentiert, wie sich die Grenzen bei verfassten 5M-Obergrenzen-Jobs verhalten, einschließlich Shared-Frontier-Ausstehend-Zustands- und serialisierter Byte-Hochwassermarken.

MCP-Server

Werkzeuge für KI-Agenten, die an Ink-Geschichten arbeiten:

Zu Claude Code hinzufügen:

claude mcp add inkcheck -- npx -y inkcheck mcp

oder zu einer beliebigen MCP-Client-Konfiguration:

{
  "mcpServers": {
    "inkcheck": { "command": "npx", "args": ["-y", "inkcheck", "mcp"] }
  }
}

Das Standard-MCP-Profil stellt fünf Tools bereit: inkcheck_capabilities, inspect_story, compile_story, start_search und inkcheck_workflow. Dadurch bleibt der Bootstrap-Kontext für neue Agents klein; capabilities listet die logischen Operationen und Anforderungsfelder des Routers auf. Setzen Sie INKCHECK_MCP_PROFILE=full nur für Clients, die jede Operation als separates benanntes Tool benötigen.

Die kompakte Agent-Schleife ist inkcheck_capabilities -> inspect_story -> compile_story -> start_search -> Befund-/Replay-/Regressionsoperationen über inkcheck_workflow routen -> beheben -> kompilieren und verifizieren. Ergebnis-Fenster-Sitzungen sind der Standard-Agent-Pfad, da sie dauerhaft, begrenzt, paginiert und quellgebunden sind. Logische start_campaign-/continue_campaign-Operationen fügen eine aggregierte Richtlinie und gemessene Ausgaben/Provenienz um dieselbe exakte gemeinsame Grenze hinzu; gewöhnliche start_search-/continue_search-Operationen behalten explizite kumulative Zuteilungskontrolle. Aufrufe sind synchron, daher ist der Abbruch an zurückgegebenen dauerhaften Grenzen vertrauenswürdig, nicht als Präemption mitten im Fenster. inspect_search bleibt datenschutzminimal; add_goal kann ein separat gemeldetes gerichtetes Budget ausgeben, ohne die exakte Basissuche zu schwächen, und replay_witness ist die explizite Grenze, die ein aktuelles Transkript, einen Auswahlpfad und einen Variablenzustand zurückgibt. Bei Laufzeitfehlern, Assertionsverletzungen und genehmigten Ziel-Witnesses führen Sie pin_regression vor dem Bearbeiten und check_regression danach aus, um einen exakten privaten Witness ohne weiteren Suchlauf wiederzugeben. Ein Pin ist keine breite Neuverifizierung; führen Sie nach sinnvollen Änderungen eine neue begrenzte Suche aus. Siehe QA-Evidenz-Pins, das gebündelte Skill und MCP-Ergebnis-Fenster-Sitzungen.

Wenn ein Autor oder Agent Story-Regeln vorschlägt, kann inkcheck_workflow zuerst review_contract ausführen. Die Überprüfung validiert typisierte Assertions und Ziele gegen die kompilierte Story, inventarisiert bestehende Contracts, erfordert Autorenfreigabe und empfiehlt standardmäßig breite QA mit null gerichtetem Budget. Sie ist schreibgeschützt: Sie kann keine Konfiguration bearbeiten, Suchbudget ausgeben oder einen Ziel-Probe stillschweigend befördern. Siehe Agent-gerichtete QA-Contracts.

CLI

inkcheck capabilities [--json]
inkcheck inspect <story.ink> [--json]
inkcheck <story.ink> [--max-depth N] [--max-states N] [--seed N] [--story-seed N] [--search=portfolio|shared|shared-variable] [--concurrency auto|N] [--max-frontier-states N] [--max-frontier-memory MB] [--auto] [--profile] [--next] [--no-min-repro] [--strict] [--save-report] [--save-checkpoint] [--progress=auto|human|ndjson|off] [--human|--json|--json-stream|--markdown]
inkcheck artifacts list [--json]
inkcheck artifacts show <report-id> [--json]
inkcheck artifacts findings <report-id> [--limit N] [--cursor C] [--json]
inkcheck artifacts finding <report-id> <finding-id> [--json]
inkcheck artifacts replay <report-id> <finding-id> [--json]
inkcheck artifacts delete <report-id> [--apply] [--json]
inkcheck artifacts prune --keep N [--apply] [--json]
inkcheck checkpoints list [--json]
inkcheck checkpoints show <checkpoint-id> [--json]
inkcheck resume <checkpoint-id> --max-states N [--json]
inkcheck mcp    # start the MCP server on stdio

inkcheck capabilities --json ermöglicht Agents, Schema-Versionen, Limits, Suchmodi und explizit unterstützte oder nicht verfügbare Funktionen zu prüfen, bevor sie sich darauf verlassen. inkcheck inspect story.ink --json führt eine deterministische Nur-Quellcode-Erkennung ohne Kompilieren oder Erkunden durch: Es folgt projektlokalen Includes und gibt eine begrenzte Karte von Story-Form, Semantik, Externals, Knoten/Funktionen, Variablendeklarationen/-lesungen/-schreibungen und statischen Bedingungsgates mit faktischen Zuweisungsstellen zurück. Eine dauerhafte MCP-Sitzung kann ein explizit ausgewähltes unterstütztes Gate in einen separaten begrenzten probe_gate-Ziellauf umwandeln; dieser wurzelgestartete Probe bewahrt die exakte Basisgrenze und meldet einen Witness oder einen begrenzten Fehlschlag. Gate-Inspektion und Zuweisungsstellen sind Voraussetzungshinweise, niemals Erreichbarkeitsbeweis oder eine Änderung der Standard-Suchzuteilung. Siehe den Vertrag zur Inspektion zusammengesetzter Gates und den Agent-Erkennungsvertrag.

Das Gate-Probe-Bewertungsprotokoll vergleicht gewöhnliche gemeinsame Suche mit dem expliziten Probe mit gleichem Budget an einem Kombinationsschloss mit früher Entscheidung und einer Opt-in-5M-The-Intercept-Zelle. Es ist Evidenz dafür, ob weitere Voraussetzungssteuerung lohnenswert ist, keine Abdeckungs- oder Beförderungsbehauptung.

JSON-Prüfungen verwenden das versionierte Berichtsschema. Befunde haben stabile IDs und normalisierte Arten; End- und Laufzeitfehler-Witnesses tragen sowohl menschlichen Auswahltext als auch nullbasierte Auswahlindizes, sodass doppelte Beschriftungen durch playtest_story exakt wiederholbar bleiben. Der Umschlag zeichnet die Inkcheck-Version, den kompilierten Story-Fingerabdruck, die effektive Konfiguration, das Bindungslimit und eine beobachtungsnur shadowDecision auf, während die etablierten Abschnitte compile, stats, explore und nextRun beibehalten werden.

--concurrency auto ist der Standard für das lokale Portfolio. Es setzt eine Obergrenze von vier Bahnen, nicht vier unbedingte Worker: Ein Innen-Außen-DFS-Durchlauf läuft für höchstens 1.024 Zustände, dann bleibt der versionierte Klassifikator sequenziell, wenn die Story erschöpft ist, die Tiefe bindet, verfasste Knoten bereits gesättigt sind, die Hardware einen Kern hat oder der Speicher Worker nicht sicher finanzieren kann. Eine offene anhaltende Grenze hält diesen Live-Durchlauf im Elternprozess, während unberührte Durchläufe in persistenten Workern beginnen. --concurrency 1 ist ein harter sequenzieller Opt-out; explizite Werte 2–16 bewahren eine feste Worker-Obergrenze ohne Workload-Klassifikation. Gemeinsame Suche und additive Zielläufe bleiben automatisch sequenziell, sofern nicht explizit ein inkompatibler fester Wert angefordert wurde.

Berichte legen concurrencyMode, die aufgelöste Obergrenze, die Aktivierungsrichtlinie/-entscheidung/-grund, Pilotarbeit, effektive Worker, den aggregierten Heap-Plan und doppelte Auswertungen (null für die Produktionsrichtlinie) offen. Worker-Fehler behält die neueste abgeschlossene Evidenz bei und meldet truncatedBy.worker; er tarnt sich nie als Zustandsbudget-Stopp. Gehostete Bereitstellungen übergeben ihre eigene explizite Obergrenze pro Job, standardmäßig eins auf dem Produktionscontainer, und echte Kind-Abbrüche bereinigen temporäre Uploads. Der Spitzen-RSS kann höher sein, da V8-/Laufzeit-Overhead kein Heap ist; der Klassifikator schätzt die Workload-Form, nicht die Abdeckungsvollständigkeit.

MCP verwendet standardmäßig kompakte Maschinenausgabe: Inspektion ist auf 16 KiB begrenzt und Kompilierung, Statistiken, einmalige Erkundung und Ergebnis-Fenster-Antworten auf 32 KiB. Auslassung von Ausgabe wird getrennt von begrenzter Suchtrunkierung gemeldet. Vollständige storytragende Berichte bleiben nur über explizite Detail- oder Drill-down-Aufrufe verfügbar.

Gespeicherte Berichte unterstützen begrenztes Befund-Drill-down ohne Laden des vollständigen Berichts. artifacts findings gibt standardmäßig höchstens 20 datenschutzminimale Zusammenfassungen zurück (Maximum 100) und einen berichtsgebundenen Cursor; Zusammenfassungen lassen Story-Prosa, Variablen, Auswahltext und Witness-Pfade aus. artifacts finding ruft einen vollständigen stabilen Befund ab. artifacts replay kompiliert den gespeicherten Einstiegspunkt neu und folgt den indizierten Auswahlen dieses Befunds mit seinem gespeicherten Story-Seed, jedoch nur, solange die Artefakt-Frische current ist; veraltete oder verschobene Quelle schlägt geschlossen fehl.

Die Berichtsspeicherung ist privat und begrenzt: Ein Bericht darf höchstens 256 MiB verwenden und alle Berichte in einem Projekt höchstens 1 GiB. Ein Speichern über einer der beiden Obergrenzen schlägt fehl, ohne alte Evidenz zu löschen. artifacts delete und artifacts prune --keep N zeigen standardmäßig eine Vorschau und mutieren nur mit --apply; prune behält die neuesten N Berichte für jeden Einstiegspunkt und entfernt höchstens 100 pro Aufruf. Dieser explizite Lebenszyklus verhindert, dass eine stabile Berichts-ID verschwindet, nur weil ein anderer Lauf beendet wurde.

Wartende können Schattenempfehlungen über unabhängige Budgetläufe hinweg mit dem manifestgesteuerten Schattenrichtlinien-Evaluator vergleichen. Die separate Suchbeförderungs-Benchmark führt abgeglichene Basis-/Kandidatenmatrizen über ein eingechecktes 20-Familien-Korpus plus eine gepinnte einwilligungssichere Autorenprojekt-Stufe aus, meldet Ressourcenbeobachtungen und Worst-Family-/Projektverluste und erklärt nie einen Gewinner. Die erste Autorenprojekt-Bewertung fand Parität, wo Zellen abgeschlossen wurden, und aussagekräftige projektformbezogene Ressourcenlimits, keinen policy-v2-Vorteil. Kein Tool bezeichnet einen begrenzten größeren Lauf als Orakel oder ändert die Standardrichtlinie.

--max-depth akzeptiert 1–1.000 und --max-states akzeptiert 1–100.000.000, mit einem Standardbudget von 10.000.000. Diese harten Obergrenzen verhindern, dass fehlerhafte Automatisierungseingaben versehentlich die Erkundungsgrenzen deaktivieren. Der Standardwert ist bewusst ambitioniert, weil drei Dinge ein großes Budget sicher statt rücksichtslos machen: Eine vollständig erkundbare Story beendet sich vorzeitig, sobald ein systematischer Durchlauf sie als erschöpfend beweist (kleine Stories enden also weiterhin in wenigen Zuständen), die Speicherwache stoppt sauber vor einem Out-of-Memory-Absturz, und die Fortschrittsberichterstattung ermöglicht es Ihnen, einen langen Lauf zu beobachten und zu unterbrechen. Eine große, nicht erschöpfende Story wird dieses Budget daher nutzen — siehe Leistung und Speicher, bevor Sie eine in CI ausführen, und pinnen Sie dort ein kleineres --max-states, wenn eine begrenzte Laufzeit wichtiger ist als die Abdeckungstiefe.

--max-states ist ein Gesamtbudget für den Lauf, kein Versprechen, dass ein einzelner DFS-Durchlauf alle Zustände verbraucht. Standardmäßig teilt die CLI den Großteil dieses Budgets auf drei komplementäre DFS-Ansichten des Auswahlbaums plus eine gesetzte Zufallsstichproben-Scheibe auf und hält eine kleine Breitensuche-Scheibe für kürzere Fehler- und End-Wiedergabepfade. Verwenden Sie --no-min-repro, um diese Wiedergabescheibe stattdessen für das DFS-Portfolio auszugeben, wenn Breitensuche-Verkürzung weniger wichtig ist als breitere Suche.

--seed (Standard 1) steuert nur die Zufallsstichproben-Suchscheibe von Inkcheck. --story-seed (Standard 1) setzt unabhängig den anfänglichen Laufzeit-RNG-Zustand von Ink für RANDOM()- und Mischverhalten. Halten Sie beide für wiederholbares CI und exaktes Witness-Replay fest; ändern Sie --seed, um verschiedene Auswahlpfade zu stichproben, oder ändern Sie absichtlich --story-seed, um eine andere gültige Story-Zufallssequenz zu üben. Verfasste SEED_RANDOM(...)-Befehle wirken weiterhin und können den anfänglichen Story-Seed überschreiben. Inkcheck zeichnet beide Seeds auf und trägt storySeed in Wiedergabeanweisungen, aber ein Lauf zählt nicht jeden möglichen Story-Seed auf. Das foundBy-Feld jedes Befunds in der --json-Ausgabe benennt den Durchlauf, der ihn entdeckt hat, z. B. dfs:last oder random:seed=1.

--search=shared wählt die experimentelle gemeinsame Mehrfronten-Engine; --search=portfolio ist der unveränderte Standard. Der gemeinsame Modus bleibt für einen festen Seed deterministisch und respektiert weiterhin Tiefen-, Zustands-, Speicher-, Zeit-, Fortschritts- und Wiedergabe-Verkürzungssteuerungen.

--save-checkpoint ist bewusst enger als gewöhnliche gemeinsame Suche: Es erfordert --search=shared --no-min-repro und keine Assertions, Ziele, --auto, --next oder Berichtsartefakt im selben Befehl. Wenn Live-Arbeit verbleibt, enthält die JSON-Ausgabe eine quellgebundene Checkpoint-ID. inkcheck resume <id> --max-states N erfordert, dass Quelle und Suchbindungen übereinstimmen und N die vorherige Gesamtzuteilung des Checkpoints überschreitet; es speichert automatisch die nächste Generation. Abgeschlossene und ressourcengestoppte Suchen geben ihren Bericht zurück, ohne einen fortsetzbaren Checkpoint zu erfinden.

--search=shared-variable fügt der gemeinsamen Suche eine kleine Variablen-Seltenheitsgrenze hinzu. Sie priorisiert beobachtete ungewöhnliche Variablenwerte und ändert sich mechanisch; sie verwendet kein KI, versteht keine Story-Bedeutung und schließt nicht, welche Werte wünschenswert sind.

--max-frontier-states und --max-frontier-memory sind optionale Sicherheitsgrenzen für die gemeinsame Suche bezüglich aufbewahrter ausstehender Checkpoints. Keine von beiden hat einen Standardwert: Inkcheck legt keine niedrige universelle Frontier-Obergrenze fest. Wenn eine explizite Grenze greift, behält der Lauf seine Funde, meldet truncatedBy.frontier und kennzeichnet den Stopp nicht fälschlich als Erschöpfung des Zustandsbudgets. Dieselben Parameter sind auch als ci.maxFrontierStates / ci.maxFrontierMb und als Eingaben des MCP-Tools explore_story verfügbar.

--max-memory <mb> begrenzt, wie viel Heap der gesamte Lauf verwenden darf, bevor er sauber anhält. Ein V8-Heap-Out-of-Memory-Abbruch kann nicht im Nachhinein abgefangen werden; deshalb beobachtet inkcheck den Speicher während der Erkundung und hält an — bevor es abstürzen würde —, behält alles bisher Gefundene und meldet truncatedBy.memory mit einem Teilergebnis, anstatt den Lauf zu verlieren. Explizite Grenzen behalten bis zu 25 % (höchstens 1 GiB) für die endgültige Ergebniszusammenstellung und das Schreiben vor; der begrenzte Stream meldet sowohl die vollständige Obergrenze als auch die niedrigere Such-Wassermarke. Die Standardgrenze beträgt 85 % des V8-Heap-Limits (das alle von Ihnen gesetzten NODE_OPTIONS=--max-old-space-size berücksichtigt), sodass große Läufe auf bescheidener Hardware kontrolliert degradieren, anstatt abzustürzen; übergeben Sie einen expliziten Wert, um sie zu verschärfen oder zu lockern. Bei einem Speicherstopp lautet das nextRun-Urteil investigate (erhöhen Sie --max-old-space-size, senken Sie --max-states oder teilen Sie die Geschichte) — niemals broaden, da mehr Budget nur schneller an die Wand stoßen würde.

--max-time <s> ist das Gegenstück für die Gesamt-Wanduhrzeit: Die Frist beginnt vor der Kompilierung und dem Quelltext-Scan, und der Lauf behält 10 % des Kontingents (mit einem Minimum von 250 ms und einem Maximum von 60 Sekunden), um gespeicherte Funde zusammenzuführen und sein Ergebnis auszugeben. Die Erkundung stoppt mit truncatedBy.time, anstatt bis zum Zustandsbudget zu laufen. Es gibt keine Standardzeitbegrenzung für die lokale CLI. Sie ist für CI oder jeden Kontext gedacht, der eine begrenzte Laufzeit benötigt, aber dennoch die bisherigen Funde haben möchte — dieselbe Idee eines kontrollierten Teilergebnisses wie beim Speicherschutz, angewendet auf die Zeit. Der gehostete Web-Checker setzt dies automatisch, knapp unter seinem harten Timeout, sodass eine langsame Geschichte ein Teilergebnis zurückgibt, anstatt abgebrochen zu werden.

--profile gibt ein kostengünstiges statisches Formprofil der Geschichte aus — Variablen und wo sie zugewiesen werden, Wahldichte, der längste Divert-Pfad — plus das Tiefenlimit und die Durchlaufgewichte, die inkcheck für diese Form wählen würde, ohne eine Erkundung auszuführen. --auto wendet diese Vorschläge an: Es erhöht --max-depth, wenn statische Divert-Pfade den Standard überschreiten (senkt es nie, und Ihre expliziten Flags gewinnen immer) und übergibt die Durchlaufgewichte des Profils an das Portfolio. Bei einer Geschichte, deren Hauptpfad 40 Entscheidungen tief ist, findet die Standardeinstellung nichts, während --auto das Ende erreicht und die Geschichte in ~111 Zuständen als vollständig beweist.

Interaktive Terminals zeigen standardmäßig eine kompakte Live-Fortschrittszeile: aktuelle Phase, erkundete Zustände im Verhältnis zum konfigurierten Arbeitsbudget, Entdeckungen und verstrichene Zeit. --progress=human erzwingt lesbare Schnappschüsse für CI-Logs; --progress=ndjson schreibt versionierte Ereignisse für Agenten und Parser; --progress=off deaktiviert den Fortschritt. Keiner dieser Prozentsätze behauptet eine Geschichtsabdeckung. Der endgültige stdout-Bericht bleibt maßgeblich, und der Fortschritt enthält niemals Geschichtsprosa, Entscheidungen, Variablen oder Quelltextausschnitte.

Jeder Bericht trägt außerdem ein nextRun-Urteil — ein kleines geschlossenes Vokabular (stop, deepen, broaden, reseed, investigate), deterministisch aus dem Bericht selbst berechnet, mit konkreten Flags, einer Begründung, die die verwendeten Felder zitiert, und dem evidenzgestützten erwarteten Gewinn. --next setzt es um: Nach der Prüfung wendet inkcheck die empfohlene Eskalation an und führt erneut aus, bis zu dreimal, wobei es bei einem stop/investigate-Urteil, an den Flag-Obergrenzen oder dann anhält, wenn ein eskalierter Lauf nichts Neues findet (Fixpunkt). Die Spur pro Lauf landet in der --json-Ausgabe als runs; die Erzählung der Zwischenschritte geht an stderr, sodass die Maschinenausgabe sauber bleibt. Empfehlungen überschreiten niemals die dokumentierten harten Obergrenzen — wenn keine Flag-Erhöhung Evidenz hinter sich hat, degradiert das Urteil zu investigate und weist auf die Knoten hin, die eine Überprüfung wert sind.

GitHub Actions:

- uses: actions/setup-node@v4
  with: { node-version: 22 }
- name: Check the story and publish a readable summary
  shell: bash
  run: |
    set -o pipefail
    npx -y inkcheck story/main.ink --strict --markdown --max-states 500000 | tee -a "$GITHUB_STEP_SUMMARY"

Das Beispiel fixiert --max-states 500000, damit der Job eine vorhersehbare Laufzeit hat; das Standardbudget beträgt 10.000.000, das eine große, nicht erschöpfende Geschichte tatsächlich verbrauchen würde (siehe Leistung und Speicher). Legen Sie in CI ein Budget fest, wenn eine begrenzte Wanduhrzeit wichtiger ist als maximale Abdeckung.

--strict schlägt nicht nur bei Warnungen und unbesuchten Knoten fehl, sondern auch, wenn die Erkundung abgebrochen wurde oder eine EXTERNAL-Funktion durch einen Stub ersetzt werden musste. Dies verhindert, dass eine Teilprüfung ein grünes „vollständig“-Abzeichen trägt.

Siehe den InkJam-QA-Leitfaden für eine autorenfreundliche Einrichtung und Hilfe bei der Interpretation des Berichts.

Ein irreführendes Ergebnis gefunden? Nutzen Sie die öffentlichen Issue-Formulare, um ein falsches oder übersehenes Ergebnis zu melden, ein lizenziertes Minimal-Fixture anzubieten oder eine optionale QA-Klinik-Prüfung anzufordern. Hängen Sie niemals privates, unter Embargo stehendes oder Jam-beschränktes Geschichtsmaterial an ein öffentliches Issue.

Für Menschen, CI und Agenten

inkcheck kann von einem Menschen an einem Terminal, einem CI-Job oder einem optionalen KI-Codierungsagenten bedient werden. Das Tool selbst verwendet weiterhin keine KI; Agenten sind nur ein weiterer Aufrufer der CLI oder des MCP-Servers.

• Maschinenlesbare Schnittstelle: tool.json im Repository-Stammverzeichnis beschreibt die CLI-Flags, MCP-Tools, Exit-Codes und die Ausgabeformen von --json / --json-stream in einer Datei.

• --json gibt den gesamten Bericht als ein einzelnes JSON-Objekt ({ compile, stats, explore }) auf stdout aus — parsen Sie das, anstatt die hübsche Ausgabe zu scrapen. explore.passes enthält eine begrenzte, pass-lokale discoveryCurve („was dieser Explorer gefunden hat“) plus eine nur für das Portfolio bestimmte portfolioMarginalCurve („was dieser Explorer zuerst hinzugefügt hat“), wobei exakte Terminals, sichtbare Ergebnisse, Laufzeitfehler, Assertions, Ziele/Stufen, Knoten und vergleichbare Neuheit getrennt werden. Zusammenfassungen bewahren erste/letzte Entdeckungszustände und Fakten zu Trockenlücken trotz Kompaktierung. Portfolio-Berichte enthalten außerdem eine den gesamten Lauf umspannende Kurve in tatsächlicher verschachtelter Ausführungsreihenfolge; die Wanduhrzeit bleibt in Fortschrittsereignissen rein beobachtend. explore.schedule zeigt, wie adaptive Runden das Budget ausgegeben haben. Die versionierte shadowDecision zeigt, was die zukünftige Anytime-Richtlinie empfehlen würde und warum, einschließlich geschützter Mindestgrenzen pro Durchlauf und Unsicherheit. Sie ist rein beobachtend (applied: false): Sie ändert niemals die heutige Suche und behauptet nicht, dass begrenzte Abdeckung ein Beweis ist.

• --json-stream gibt reproduzierbare numerische Fund-Zeugen als NDJSON aus, sobald sie aufbewahrt werden, dann eine begrenzte Abschlusszusammenfassung, anstatt den vollständigen angereicherten Bericht oder einen berichtsgroßen JSON-String zu materialisieren. Es erfordert derzeit --concurrency 1, unterstützt einen einzigen Erkundungslauf (kein --next oder --profile) und kann nicht mit --save-report kombiniert werden. Ein reservierter numerischer Tag-Modus unterstützt die orakelneutrale Bewertung von InkBench, ohne Orakelvariablen der Suche auszusetzen oder jedes gewöhnliche Ende zu streamen. Verwenden Sie den Stream für lange Bewertungen externer Prozesse, bei denen Teilevidenz eine harte Wrapper-Grenze überstehen muss. Siehe den Vertrag für begrenzte Evidenz-Streams.

• --progress=ndjson gibt versionierte Lebenszyklus- und Arbeitsfortschrittsereignisse auf stderr für einen Agenten oder CI-Log-Parser aus. statesExplored / stateBudget ist Budgetverbrauch, keine Geschichtsabdeckung; der endgültige stdout-Bericht bleibt maßgeblich. Siehe den NDJSON-Fortschrittsvertrag.

• --human gibt eine priorisierte Korrekturliste aus, gruppiert nach Fehlern, Warnungen und Hinweisen, mit Datei/Zeilen-Positionen, wo verfügbar, Wahlpfaden für Laufzeitfehler und einem nächsten Schritt für jeden Fund.

• --markdown gibt einen GitHub-Step-Summary-freundlichen Bericht für Menschen aus, die CI überprüfen.

• Deterministische Exit-Codes: 0 sauber · 1 Kompilierungs-/Laufzeitfehler (oder, unter --strict, Warnungen, unbesuchte Knoten, Abbruch oder externe Stubs) · 2 Verwendungsfehler. Verzweigen Sie anhand des Exit-Codes; durchsuchen Sie nicht den Text.

• MCP: claude mcp add inkcheck -- npx -y inkcheck mcp stellt das kompakte Fünf-Tool-Agentenprofil bereit. Verwenden Sie INKCHECK_MCP_PROFILE=full für den Kompatibilitätskatalog.

• Der Kreislauf: .ink bearbeiten -> compile_story -> start_search -> die nächste Evidenzaktion über inkcheck_workflow leiten -> korrigieren -> kompilieren und verifizieren. inkcheck ist eine wiederholbare mechanische Prüfung für einen Story-Graphen, den Sie erzeugt oder bearbeitet haben; verwenden Sie sie, um Ihre eigene Arbeit zu verifizieren, bevor Sie sie zurückgeben.

• Der Abdeckungskreislauf: explore_story (und die CLI --json) gibt nextRun zurück — verzweigen Sie anhand von dessen recommendation (stop / deepen / broaden / reseed / investigate) und führen Sie mit nextRun.flags erneut aus, bis stop: true ist. Oder lassen Sie die CLI es steuern: inkcheck story.ink --next.

llms.txt im Repository-Stammverzeichnis ist eine kompakte, modellfreundliche Zusammenfassung von all dem oben Genannten.

So funktioniert es

• Kompilierung verwendet inklecate, den kanonischen Compiler – gefunden über $INKLECATE_PATH, dann PATH, dann automatisch heruntergeladen aus dem festgepinnten offiziellen ink-1.2.1-Release in ~/.cache/inkcheck beim ersten Lauf. Heruntergeladene Archive werden vor dem Extrahieren gegen festgepinnte SHA-256-Hashes verifiziert. Geschichten werden mit -c kompiliert, sodass alle Knotenbesuche gezählt werden.

• Erkundung führt die kompilierte Geschichte in inkjs aus (dem offiziellen JS-Runtime-Port), wobei gepoolte Story-Instanzen wiederverwendet werden, sodass das kompilierte JSON einmal pro Durchlauf geparst wird und Zustände über LoadJson zurückgespult werden. Inkcheck initialisiert die Story-Zufälligkeit aus --story-seed (Standard 1) und bewahrt dann den RNG-Zustand von Ink in jedem gespeicherten Zweig; autorisiertes SEED_RANDOM(...) bleibt maßgeblich, wenn es ausgeführt wird. Zustände werden nach Inhalts-Hash dedupliziert. INCLUDEs werden verfolgt.

• Die CLI verwendet eine begrenzte, adaptive Portfolio-Suche. Komplementäre Durchläufe – letzte-Wahl-zuerst, erste-Wahl-zuerst und Innen-nach-außen-DFS, ein Diversitäts-zuerst-Beam und geseedete Zufallsläufe – laufen verschachtelt in zehn deterministischen Runden. Anfangsgewichte (etwa 20/20/26/15/20 %, oder ein Formprofil-Vorschlag unter --auto) werden jede Runde zugunsten von Durchläufen neu zugewiesen, deren Erkenntnisse noch wachsen, mit einer beabsichtigten Bruchteils-Untergrenze von 8 % pro aktivem Durchlauf. Research-only-Policy-Replay verwandelt diese Absicht in überprüfbare kumulative Ganzzahl-Services und normalisiert die Aktualität auf die beobachteten Ausführungsfenster jedes Durchlaufs statt auf eine globale Zustandszählung. Es benötigt drei Fenster, bevor es den Ertrag schätzt, lässt Signale nach einem oder zwei gemessenen Fenstern ohne Erneuerung verfallen und erlaubt experimentelle Allokations-Overlays nur für erneuerte Laufzeit-/Assertions-Evidenz oder expliziten Fortschritt bei Zielen; breite Abdeckung bleibt beim etablierten Scheduler. Der Produktions-Scheduler bleibt unverändert, bis das vollständige Promotionskorpus besteht. Die Durchläufe sind komplementär: Die DFS-Reihenfolgen erschöpfen systematisch Teilbäume, der Beam verteilt das Budget über variable Zustandslinien innerhalb einer harten Frontier-Obergrenze, und Zufallsläufe würfeln jeden Entscheidungspunkt neu, sodass frühe Wahlkombinationen abgetastet statt wiederholt werden. Erkenntnisse werden in einem Bericht zusammengeführt, jeweils gekennzeichnet mit dem Durchlauf, der sie gefunden hat, und der ausgeführte Zeitplan erscheint in der --json-Ausgabe.

• Arbeitslastbewusstes --concurrency auto ist der lokale Portfolio-Standard. Sein Live-Pilot mit 1.024 Zuständen Innen-nach-außen-DFS wird zum Präfix der normalen ersten adaptiven Runde und läuft dann entweder sequenziell weiter oder überlappt unberührte Durchläufe in begrenzten persistenten Workern. Wenn Zeit oder Speicher während dieses Piloten binden – oder die Frist eintrifft, bevor ein Worker initialisiert –, wird der gültige Pilot als explizit ressourcengekürzter Teilbericht zurückgegeben, niemals fälschlich als Erschöpfung des Zustandsbudgets gekennzeichnet. Das 80-Zellen-100K-Gate behielt exakte Erkenntnisse, Beweise und adaptive Zeitpläne mit nur zwei Open-Frontier-Aktivierungen; übereinstimmende 5M-The-Intercept-Gates mit Tiefe 30/Tiefe 100 behielten exakte Evidenz, lehnten den tiefenbegrenzten Job ab und verbesserten den nachhaltigen Job von 657,7 s auf 489,0 s. Jeder Zustand bleibt innerhalb einer Obergrenze, und doppelte Pilotauswertungen sind null. Explizites 1 bewahrt die sequenzielle Ausführung; explizite 2–16-Obergrenzen bewahren feste Parallelität. Siehe die Parallelitätsauswertung.

• Experimentelles --search=shared behält eine globale Zustandsidentität und legt die anstehende Arbeit durch Tiefen-, Neuheits- und geseedete Frontier-Ansichten offen. Ein von einer beliebigen Ansicht gewählter Zustand wird einmal expandiert; expandiertes Checkpoint-JSON wird sofort freigegeben, kompakte Eltern-Links überleben nur, solange ein anstehender Nachkomme den exakten Reproduktionspfad benötigt, und veraltete Ansichts-IDs werden periodisch kompaktiert. Berichte legen Komponentenbuchhaltung und optionale explizite Checkpoint-Hüllen offen. Variablenzustands- und Variablenübergangs-Seltenheit werden als Auswertungstelemetrie erfasst.

• Experimentelles --search=shared-variable ersetzt eine von jeweils acht Shared-Frontier-Auswahlen durch eine Variablen-Seltenheits-Ansicht. Sein Score kombiniert die beobachtete Häufigkeit des Zielvariablen-Snapshots und die seltenste Änderung auf dieser Kante; es kann nicht mehr als seinen festen Anteil verbrauchen, sodass Graphen-Neuheit, Tiefe und geseedete Erkundung repräsentiert bleiben.

• In dem Moment, in dem ein systematischer Durchlauf jeden erreichbaren Zustand besucht, ohne ein Limit zu treffen, stoppt das gesamte Portfolio: Jeder weitere Zustand wäre redundant. Eine kleine, vollständig erkundbare Geschichte mit dem Standardbudget von 10.000.000 Zuständen endet trotzdem in den wenigen Zuständen, die sie tatsächlich hat – der große Standardwert kostet nichts, wenn eine Geschichte erschöpfbar ist.

• Der Beam-Durchlauf beantwortet „Was sollte ein Beam optimieren?" konkret: Überlebende werden reihum über Variablensignatur-Gruppen ausgewählt (Diversität zuerst), innerhalb jeder Gruppe nach Neuheit eingestuft – neu besuchte Knoten, dann neue Variablensignaturen, dann neue angebotene Wahlmengen. Er ist ohne Seed deterministisch und meldet den Lauf als gekürzt, wann immer er einen erreichbaren Zustand beschneiden musste, sodass ein Beam niemals stillschweigend vollständige Abdeckung beansprucht.

• Sofern nicht mit --no-min-repro übersprungen, reserviert die CLI etwa 10 % des angeforderten --max-states-Budgets für einen Breitensuche-Repro-Verkürzungsabschnitt. BFS erreicht gemeinsame Erkenntnisse über kürzere Wahlpfade, wo möglich, und kann zusätzliche flache Erkenntnisse beitragen.

• Grenzen (--max-depth, --max-states) halten die Worst-Case-Kombinatorik im Zaum; der Bericht sagt explizit, wann er gekürzt wurde.

Abdeckungsgrenzen

• Die Erkundung ist begrenzt. Ein gekürzter Bericht ist Evidenz über besuchte Zustände, kein Beweis über die gesamte Geschichte.

• Berichte geben die Grenzen an, unter denen sie liefen (Tiefe, Zustandsbudget, Such-Seed und Story-Seed), und, wenn gekürzt, welches Limit die Abdeckung tatsächlich geschnitten hat (truncatedBy in --json, einschließlich memory) mit gezielter Empfehlung, welches Flag zu erhöhen ist.

• Ein großer Lauf, der den Speicher erschöpfen würde, stoppt sauber und gibt einen Teilbericht zurück (truncatedBy.memory), statt abzustürzen – der Speicherfußabdruck wird vom Deduplizierungs-Hash-Satz dominiert (~linear in den verschiedenen Zuständen) und, bei tiefen schleifenarmen Geschichten, von der Breitensuche-Repro-Frontier, sodass --no-min-repro und ein engeres --max-states die Hebel sind, wenn eine Geschichte zu groß zum Beenden ist.

• Kleine Geschichten erhalten oft die gegenteilige Garantie: Wenn ein systematischer Durchlauf jeden erreichbaren Zustand besucht, ohne ein Limit zu treffen, sagt der Bericht dies (exhaustive), und die Erschöpfung des Sampling-Slice-Budgets zählt nicht mehr als Kürzung.

• EXTERNAL-Funktionen werden auf Null gestubbt, weil das Host-Spiel nicht verfügbar ist. Der Bericht nennt jeden Stub; der strikte Modus schlägt fehl, statt vollständige Abdeckung zu beanspruchen.

• Zufälliges Verhalten ist für den gemeldeten Story-Seed wiederholbar, aber ein Lauf zählt nicht jeden möglichen Story-Seed auf. Variieren Sie --story-seed bewusst und behalten Sie menschliches Playtesting im Prozess, wenn die Häufigkeit von Ergebnissen wichtig ist.

• Ein unbesuchter Knoten kann absichtlich ruhend, engine-eingegeben oder unerreichbar sein. Die Inbound-Divert-Triage trennt wahrscheinliche Waisen von wahrscheinlich limitgebundenem Inhalt, aber sie ist eine Überprüfungsaufforderung, keine automatische Löschungsanweisung.

Roadmap

Die Roadmap wird von der Produkt- und Engineering-Wahrheiten-Scorecard regiert. Jedes Epic sollte den gemessenen Wert verbessern, ohne die Ehrlichkeit begrenzter Abdeckung, die Aufbewahrung kritischer Evidenz, die deterministische Wiedergabe oder die Ressourcenobergrenzen zu schwächen.

• Abdeckungstransparenz: klarere Berichterstattung für Kürzung, Tiefenlimits, besuchte Enden, übersprungenen Suchraum und was erkundet wurde oder nicht.

• Berichtsqualität: bessere Quellorte, kürzere Repro-Pfade, stabile Problemidentitäten und klarere Gruppierung von Laufzeitfehlern, unbesuchten Knoten und Abdeckungsgrenzen.

• Vom Autor definierte Story-Assertions: deterministische Projektregeln wie „Gold wird nie negativ", „Gesundheit überschreitet nie das Maximum" oder „erforderliche Variablen werden vor Enden gesetzt."

• Zielgerichtete Variablensuche: Autoren und Agenten sollen genehmigte Zustände suchen können, während ein geschütztes allgemeines Suchbudget und exakte Sprache begrenzter Abdeckung erhalten bleiben.

• Optionaler gehosteter KI-Zielassistent: eine erstklassige, explizit aktivierte menschliche Schnittstelle, die nicht-technischen Autoren hilft, Variablenziele und Assertions zur Genehmigung vorzuschlagen, und dann alle Ausführung und Verifikation an Inkchecks deterministische Nicht-KI-Engine delegiert. Anbieter, Einwilligung, Quellfreigabe, Aufbewahrung, Kosten und Deaktivierungssteuerungen müssen explizit sein; generierte Regeln werden niemals stillschweigend vertraut oder angewendet.

• Repro-Persistenz: bekannte fehlschlagende Pfade merken und sicherstellen, dass zukünftige Läufe sie weiterhin prüfen, auch wenn sich Traversierungsstrategien verbessern.

• Kompakte Kampagnen-Checkpoints: nützliche Large-Story-Frontiers aufbewahren und fortsetzen, ohne dass Checkpoint-Artefakte Speicher oder Festplatte dominieren, und vor Serialisierungsgrenzen zu einem unveränderlichen Teilbericht degradieren.

• Öffentliche Kompatibilitäts-Fixtures: einwilligungssichere Beispiele und synthetische Randfälle für Regressionstests, Leistungsvergleiche und Vertrauensbildung.

• Agent-Bereitschaft: Der ausführbare Agent-Bereitschafts-Benchmark pinnt ein Protokoll ohne versteckte Hinweise, deterministische Laufzeit-/Assertions-Fixtures, Bootstrap-/Tool-/Referenz-/Sicherheits-/Beweisziele, einen Maschinen-Scorer und separate Tool-/Skill-/Modell-/Umgebungsattribution. Zwei bestehende Beobachtungsläufe von verschiedenen Agent-Implementierungen bleiben das Release-Gate (#67).

• Such-Promotions-Harness: eine breite, vorab deklarierte Scorecard über strukturelle Familien, Budgets, Tiefen und Seeds, bevor eine experimentelle Strategie den Standard ändern kann.

• Begrenzte Spezialistensuche: mechanische Formen erkennen und kleine Experten-Sonden für zusammengesetzte Gates, Schleifen/Zähler, Storylet-Berechtigung, Assertionsgrenzen und verhaltensbezogene Frontier-Diversität entsenden (#107–#112). Spezialisten verdienen Expansion durch Portfolio-neuen Wert und behalten geschützte allgemeine/Long-Tail-Arbeit.

• Leistungssteuerungen für große Geschichten: Schnell-, Standard- und Tiefprüf-Voreinstellungen mit klareren Zeit-/Abdeckungs-Kompromissen.

• Strukturelle Lint-Prüfungen: optionale Prüfungen auf fehlende Tags, inkonsistente Tag-Schemas oder projektspezifische Metadaten-Konventionen.

Lizenz

MIT