Versionierte Ideen, Pflichtenhefte, Architektur, Pläne, Entscheidungen, Patch-/Testruns, Benchmarks, Ressourcen, Scheduler und CI bleiben im kanonischen TobyCode-Kern. Online liest TobyKi eine frische Projektion oder gibt einen begrenzten Auftrag weiter.
Noch keine Projektion angefordert.
Grosshirn, Kleinhirn, Rollen-/Team-Memory, TobyCode-Zustände, Receipts und HaloIndex bleiben im TobyKi-Produktpfad. Online kommt nur die begrenzte Ergebnisprojektion zurück.
Noch keine Suche angefordert.
Frische Beobachtung, Fähigkeit und Wirkung bleiben getrennt.
Dragonhost bleibt Webportal. Halunto wählt nach Auftrag, Kontextlänge und belegten Ressourcen zwischen Hunter, VivoBook, Halunto oder einem später angebundenen GPU-Worker. Modelle, Medienadapter, Quantisierung und KI-Personal laufen auf dem passenden Worker – nicht auf TobyKi-Web.
Noch keine Host-Projektion angefordert.
Vollständige Richtungen, aber keine öffentliche Generalvollmacht.
E‑Mailcode, authentifizierte Projektionen, interne Koordination und Receipt-Rückweg.
vorhandener VertragHalunto delegiert; Hunter führt TobyKi-, KI-, Git-, Memory- und Drive-Wirkungen lokal aus.
Worker-Receipt entscheidetVivoBook führt Host- und Drive-Wirkungen lokal aus und liefert Receipts zurück.
Worker-Receipt entscheidetBestehende Drive-Bridge mit Token, Owner-Gate, Einmalticket, Hash und Trash/Restore.
Route belegtLesen über den belegten Hunter-Webweg; sichere Policy ist fest aktiv.
Noch kein Drive-Aufruf.
Mutationen laufen nicht direkt durch den Webserver. TobyKi erzeugt ein gebundenes Ticket; der Zielhost prüft Policy, Hash und Einmal-ID.
In dieser Sitzung angenommene Tickets. „Angenommen“ ist kein Ausführungsbeleg.
Halunto-Projektion; Quellhost, Zeit und Hash entscheiden.
Anmeldung erforderlich.
Web und Portable bleiben zwei Oberflächen derselben TobyKi-Freigabe. Es gewinnt nur die höhere gemeinsame Release-Sequenz mit passenden Hashes und Test-Receipts – nie bloss die jüngere Uhrzeit.
Noch kein Vergleich angefordert.
TobyKi darf selbst prüfen und eine neuere Fassung stagen. Installieren bleibt getrennt: Hash, Test-Receipt, Oberflächen-Selbsttest, Owner-Gate, Restart-Smoke und Rollback.
Ist der Zielhost offline, bleibt das Ticket bei Halunto. Die UI zeigt „wartet“ oder „degraded“ und behauptet keine Wirkung.