Was an ALEX zuletzt fertig wurde

Roadmap 6.1 erledigt: Orchestrator / Capability Router

Der Capability Router für Roadmap-Punkt 6.1 ist gebaut und live geprüft. Er wählt das Profil deterministisch, ohne LLM- oder Tool-Aufruf, und protokolliert die Entscheidung als Lebenszyklus-Knoten.

• Aufträge mit fremdem Text über Repo-Metadaten hinaus (Issue/Kommentar oder Kunden-Anhang) laufen als analyse_then_code, sonst als code_only; CLI-Engines laufen als code_only.
• routeAndRecordDevTask() wird in delegate() aufgerufen und schreibt die Entscheidung als Knoten.
• Analyst-Stufen laufen über den agent_talk-Handler mit verengtem Werkzeugsatz; die Analyse geht als markierter Abschnitt in den Coding-Prompt. Rollen sind getrennt, aber nicht isoliert: Der Coding-Agent sieht den Issue-Text selbst.
• Live-Test am 25.10.2026 mit einem echten Produktionsauftrag gegen ein Demo-Repo mit verlinktem Issue #2: Routing analyse_then_code, Stufen analyst->coder, Coding-Agent nach 9 Turns CLEAN_COMPLETE, 2 Dateien (+26), Zustand Freigabe.
• Kosten: 0,0049 USD gesamt gegenüber 0,0042 USD für den Coding-Agenten allein.
• Status 6.1: erledigt. Spezial-Profile 6.2–6.8 bleiben offen; Verhalten unter Angriff nicht geprüft.

Roadmap erledigt: Erledigt N — Lockfile-Hash im Work-Contract (work-contract@1.1)

Der Work-Contract erfasst jetzt einen Hash der Lockfiles des Workspace. Dafür kommt eine neue Spalte dev_tasks.lockfile_hash per additiver Migration hinzu, befüllt über eine neue reine Berechnungsfunktion. Die Schema-Version steigt additiv auf work-contract@1.1.

• delegate() befüllt das Feld direkt nach gitExec("rev-parse HEAD", wsDir), also zum selben Zeitpunkt wie execution_base_commit.
• computeLockfileHash() in adapters/lockfileHash.server.ts wertet package-lock.json und requirements.txt aus, dieselben zwei Ökosysteme wie der Dependency-Vuln-Scan.
• buildContractSnapshot() bleibt eine reine Funktion ohne I/O und liest row.lockfile_hash wie jedes andere Feld. hashContractSnapshot() bleibt unverändert und erfasst das neue Feld über JSON.stringify.
• Alte 1.0-Snapshots bleiben gültig. Der Operator-Canary-Pfad braucht keine Änderung, lockfileHash bleibt dort null, da kein echter Checkout stattfindet.
• Tests: tests/dev-workflow/lockfile-hash.test.ts neu, contract-snapshot-hash.test.ts um Hash-Diskriminierung und einen delegate()-Integrationstest erweitert. 70 Tests grün, npm run lint grün.

Roadmap erledigt: Erledigt M — Secret-Exfiltration-Deny-Canary: dritte oeffentliche Negativ-Akte

Der Secret-Exfiltration-Deny-Canary ist umgesetzt und am 24.10.2026 live verifiziert. Er ist die dritte öffentliche Negativ-Akte neben Selbstreplikation und Netzwerk-Egress und deckt die benannte Lücke Secret-/Credential-Diebstahl ab.

• Kein neuer Kernel-Code: evaluateToolCallWithBindings({runId, capabilityId: secret_env}) ohne Bind liefert decision: deny, reason: capability_not_bound.
• Kein Sandbox-Lauf nötig; die Evidence-Funktion nutzt dasselbe reduzierte Spaltenset wie die Cline-ACP-Canary (ohne sandbox_attestation), aber ohne deren Identitätscheck; Vorlage war die Selbstreplikations-Canary (nur reason-Wert).
• Realer Lauf: capability_bind/secret_env/capability_not_bound, Vor-Wirkung-Observer-Receipt (leaf_index 4095) vor dem Blockversuch, finaler Receipt (leaf_index 4096), signiertes Evidence Package; unabhängige Verifikation bestätigt non_verified_outcome:failed.
• Nebenbefund: devtask_contract_bound zeigt contract_schema_version work-contract@1.1; der Lockfile-Hash-Schema-Sprung ist live bestätigt, auch für Operator-Canary-Läufe (lockfileHash:null).
• Öffentlich auf alexproof.de: /akte/secret-exfiltration-deny-canary, verlinkt von /beweis und risiko-einordnung.html, dazu ein rohes Verify-Bundle. 4 fokussierte Tests und npm run lint grün.

Roadmap 7.17 erledigt: Garantien-Grenzen-Matrix

Die Roadmap-Position 7.17 ist abgeschlossen: Die Garantien-Grenzen-Matrix liegt als reine Dokumentation vor, ohne Codeänderungen. Grundlage sind die 16 öffentlichen HTML-Seiten sowie assurance-claims.json, positioning.md und relevante core-Server-Dateien. Eine Korrektur ändert das Ergebnis: Vier zunächst vermutete Lücken sind nach Code-Prüfung keine.

• Abschnitt 1 listet 17 öffentliche Garantien, darunter drei Lücken-Details, die in assurance-claims.json fehlten (etwa der Passkey/L2-Drift zwischen pilot.html und evidence-beweiskraft.html).
• Abschnitt 2 übernimmt 3 interne Claims unverändert; Abschnitt 4 nennt 3 real gebaute, öffentlich unbenannte Fähigkeiten mit drei Spalten (Agent Passport, Cross-Agent Intent Graph, Claim-Zerlegung).
• Korrektur 23.10.2026: Engine-Routing, Schutzschicht-Badge, Security-Override-Gate und BYOK-Speicherung sind im Code belegt (Wilson-Score auf Lauf-Historie, AND-Logik über 4 Probes, Pre-Merge-Gate, AES-256-GCM fail-closed). Sie stehen als Zeilen 18–21 in Abschnitt 1; Abschnitt 5 heißt „Korrektur: vier vermutete Lücken, nach Code-Prüfung keine“. Keine Matrixzeile bleibt ohne Code-Beleg.
• Vorab-Korrektur: Von 7 genannten Bausteinen hatten nur 3 Inhalt; 5 sind todo ohne result und beschreiben nur eine künftige Grenze, daher bewusst keine Matrixzeile (Abschnitt 3).
• Ein veralteter Kommentar in core/agentPassportHistory.server.ts behauptete „nicht verdrahtet“, obwohl host/alexWorkflowCore.server.ts die Funktion aufruft; der Kommentar wurde korrigiert. Nicht umgesetzt: neue Non-Claim-Formulierungen, Automatisierung, Migration von assurance-claims.json; die öffentliche Übersetzung der Mechanismen ist eine Positionierungsentscheidung und wurde ohne Rücksprache zu pilot.html nicht umgesetzt.

Roadmap 7.15 erledigt: Claim-to-Code-Matrix

Die Claim-to-Code-Matrix aus Roadmap 7.15 ist abgeschlossen. Die 16 öffentlichen HTML-Seiten unter public/ und die drei PyPI-READMEs wurden gelesen und auf Sicherheitsbehauptungen geprüft.

• Sieben neue Claims in docs/vnext/assurance-claims.json, jeweils mit im Code gegengeprüften Code- und Testverweisen; das Schema bleibt unverändert.
• Die drei bestehenden Claims aus 7.16/7.18 werden öffentlich nicht unter diesem Namen oder dieser Reichweite behauptet; sie sind interne Adversarial-Hardening-Claims. Die scope-Felder wurden entsprechend ergänzt.
• claim-event-hash-chain-tamper-evident hat Status 'partial': Der Hash-Ketten-Vergleich in evidenceBundle.server.ts:2065-2067 ist unbewiesener Code, bestehende Tamper-Tests scheitern über invalid_signature, bevor der Vergleich greift.
• claim-key-rotation-no-silent-gap ist implemented, die Umgebungsvariablen für den Vorwärts-Fix sind aber nicht technisch erzwungen und als Annahme benannt.
• tests/vnext/assuranceClaims.test.ts prüft die 10 Claims gegen die bestehende Buchhaltungsregel; 16/16 Tests in tests/vnext/ grün.

Roadmap 5.3 erledigt: Kernel-Evidence-Klasse

21.10.2026: Blindstellen gemessen (Diff-Beobachtung ist TOCTOU-blind, linuxWriteDenyObserver in Produktion mangels ALEX_LINUX_WRITE_DENY_OBSERVER=1 aus; nftables-Egress-Log hat keinen harten Drop-Zaehler). PoC fuer beide Surfaces real gebaut und auf einem dafuer angelegten, wieder geloeschten Hetzner-Wegwerfserver Ende-zu-Ende verifiziert (core/kernelEvidenceSensors.server.ts, ebpf/fs_write_effects.bpf.c, ebpf/network_egress.bpf.c, ebpf/sensorRunner.c, scripts/buildEbpfSensors.sh). Echter Fund dabei: ein BPF-LSM-Hook (security_file_open) laedt/attacht ohne Fehlermeldung, feuert aber NIE ohne 'bpf' zusaetzlich in der Kernel-LSM-Kette per GRUB-Bootparameter + Reboot -- fuer den Produktionshost (bewusstki.de) eine eingeplante Downtime. Deshalb Tracepoint-Paare statt LSM-Hook fuer Surface A (ohne Reboot live bestaetigt), TC-BPF-Classifier am bestehenden Veth-Egress-Hook fuer Surface B (echter BPF-Ringbuffer-Drop-Zaehler statt der bisherigen journalctl-Textheuristik). Rot-Tests erfuellt: isKernelEvidenceComplete()/isKernelNetworkEgressEvidenceTrustworthy() (tests/core/kernel-evidence-sensors.test.ts, 36/36 gruen) lassen Sensor-Ausfall/Event-Drop/Cgroup-Mismatch/unbekannten Egress nie als vollstaendig/vertrauenswuerdig durch. Additiv auf SandboxAttestationV2 (kernel_file_write_evidence/kernel_network_egress_evidence) -- bewusst NICHT in deriveDevTaskV2Outcome() verdrahtet, Korrelation mit semantischer Evidence ist ein eigener, spaeterer Claim. Produktionsverdrahtung jetzt real: adapters/agentAdapter.customer.ts startet/stoppt beide Sensoren fuer jeden echten Kundenlauf (core/agentSandbox.server.ts, maybeStartKernelFileWriteSensor()/maybeStartKernelNetworkEgressSensor() + Gegenstuecke), opt-in per ALEX_KERNEL_EVIDENCE_SENSORS=1 (gleicher Vorsichtsgrad wie ALEX_LINUX_WRITE_DENY_OBSERVER -- erstes eBPF-Kernel-Code ueberhaupt in diesem Repo, laeuft als root). Netzwerk-Sensor bekommt die real im nftables-Set aufgeloesten erlaubten Ziele als expectedDestinations fuer hasUnexpectedEgress() (readEnforcedAllowedDestinations()). Bewusste Teil-Luecke, offen dokumentiert: expectedCgroupId wird aktuell als null uebergeben (die systemd-Scope-Cgroup-ID eines Laufs wird von runBwrapUnderSystemdScope() nicht nach aussen gereicht) -- cgroup_mismatch_detected bleibt dadurch in der Produktion strukturell false, der Mechanismus selbst ist fertig+getestet (tests/core/kernel-evidence-sensors.test.ts), nur dieser eine Input noch nicht live verdrahtet. Wiring-Tests tests/core/kernel-evidence-sensors-wiring.test.ts (4/4 gruen) plus alle bestehenden Nachbartests (cli-agent-customer-sandbox/buzz-customer-sandbox-wiring/cline-synthetic-home-guard/cli-effect-boundary-tampered-binary-denied, 30/30 gruen) unveraendert gruen.

Roadmap 4.21 erledigt: Unabhängige Observer-Bezeugung in die claim_ladder heben

Auslöser war eine externe Nutzerfrage, wie sich Agenten-Identität ohne Ausführung verifizieren lässt. verifyEvidenceBundle() war rein selbstbezüglich: ein fehlender Observer-Beleg erzeugte nur den Reason-Code independent_observer_not_attached und änderte das VERIFIED-Verdikt nicht. Die claim_ladder kannte L0–L4, deriveApprovalClaimLadder() lieferte höchstens L2.

• Additives Modul adapters/evidenceWitnessVerifier.server.ts; verifyEvidenceBundle() bleibt unverändert.
• verifyEvidenceBundleWithObserverWitness() hebt die Stufe nur nach fail-closed Live-Rückfrage beim Observer (crossCheckObserverReceipt(), Merkle-Inclusion-Proof und Anker nachgerechnet); das observer_receipt-Feld trägt keine eigene Signatur.
• Ladder bleibt monoton: L0 nicht verified, L1 verified+Token-Freigabe, L2 verified+Passkey, L3=L2+Observer live bestätigt (Anker pending), L4=L3+Bitcoin-bestätigter Anker. L3/L4 verlangen Passkey-Freigabe und live bestätigten Zeugen.
• 8 neue Rot-Tests (tests/dev-workflow/evidence-witness-verifier.test.ts): fehlender Beleg, Anker nicht bestätigt, Observer unerreichbar, manipulierter Bundle-Inhalt, Token- statt Passkey-Freigabe, L3-/L4-Erhöhung, ungültiges Basis-Bundle — in diesen Fällen keine unbelegte Erhöhung.
• Volle Suite lokal zweimal grün, npm run lint 0 Fehler.

ALEX Control Layer 0.12.0

Version 0.12.0 bringt einen MCP-Client für Werkzeuge extern konfigurierter Server über stdio und HTTP/SSE, dazu eine eigene Berechtigungsstufe und Verwaltungsbefehle.

• Neues Modul src/mcp.js: JSON-RPC-2.0-Client ohne neue npm-Dependency; Werkzeugnamen als mcp__<server>__<tool> sanitisiert und an buildToolDefs() angehängt. Discovery lazy und gecacht, ein Respawn-Versuch nach Absturz.
• Neue Stufe alex.permissions.mcp (allow/ask/deny, Standard ask): deny nimmt Werkzeuge aus dem Schema, ask/allow zeigen eine Bestätigungskarte; Aufrufe über runConfirmableTool()/applyAction() mit prepareMcp() und Canary-Check.
• Werkzeug-Ergebnisse und -Beschreibungen werden per detectInjection() geprüft; Treffer ergänzen einen „als Daten behandeln“-Hinweis und lösen eine Notice aus, bei Beschreibungen mit zusätzlicher Warnung.
• Neue Befehle alex.addMcpServer/alex.removeMcpServer/alex.reloadMcpServers, Setting alex.mcpServers (scope machine); Secrets im SecretStorage, im Setting nur die Namen (secretEnv/secretHeaders); Kachel „MCP-Server“ im Command Center.
• Smoke-Test gegen @modelcontextprotocol/server-everything per npx: nach einem Request-Timeout lief der Kindprozess verwaist weiter; McpServer.connect() disposed jetzt den vorherigen Transport. 23 neue Tests, 144/144 grün.

Roadmap 3.6 erledigt: Capability Passport

Am 17.10.2026 wurde der Capability Passport in Roadmap 3.6 abgeschlossen: agent_talk steht jetzt in CUSTOMER_DEV_TASK_TOOLS (core/customerToolCatalog.server.ts). Damit erreicht der echte Kunden-Dev-Task-Pfad (adapters/repoContributionPipeline.server.ts:runCodingAgentAndCommit()) evaluateDelegation() real und nicht mehr nur als Design.

• Vor dem Scharfschalten zeigte ein echter Testlauf, nicht nur Code-Lektüre: Der agent_talk-Sub-Agent wurde ohne beforeToolCall, beforeFileWriteCommit und onFileWriteVerified konstruiert.
• Right-Amplification bei Tools, Daten und Laufzeit war dadurch verhindert. Ohne die Hooks hätte der Sub-Agent für eigene Tool-Calls den Policy-Kernel-Gate umgangen: BIND-Bindings, Shell-Change-Gate (no-sed/no-git-push), AEGIS-Shadow-Scan und Witness-Chain.
• Die Sandbox-Grenze sandboxDir/bwrap galt wie beim Parent, die Pro-Call-Prüfungen fehlten jedoch.
• Die drei Hooks werden jetzt im agent_talk-Handler (host/agentLoop.server.ts) an den Sub-Agenten durchgereicht.
• 17/17 Tests grün (int-pass-no-right-amplification, erweitert um Source-Pattern- und real ausgeführte Gate-Weiterreichungs-Tests), volle Suite 1266/1272 grün (6 bewusste Skips), tsc sauber.

Roadmap 3.1 erledigt: agent_messages + Baseline

Block 3.1 ergänzt eine Tabelle agent_messages als reinen Mitschnitt; ghost.db hatte kein passendes Schema. Die Tabelle liegt in host/db/agentMessages.ts.

• Felder: id, task_id, sender_agent_id, receiver_agent_id (nullable), channel als TEXT ohne Enum, created_at, raw_content (auf 4000 Zeichen gekürzt), token_count (Näherung über Zeichen), embedding_hash (SHA-256 über raw_content, Platzhalter, kein echtes Embedding).
• ghostbus_emit erkennt der Policy Kernel als Agent-Kollaboration und sperrt sie im Collaboration-Budget, ein ausführender Tool-Handler fehlt. Ein Mitschnitt dort wäre eine Attrappe und wurde nicht gesetzt.
• Andockpunkt ist der agent_talk-Handler. Neu: optionales clientConfig.taskId (Default: agentId), durchgereicht bis zu rekursiven Unteragenten.
• recordAgentMessage() läuft in try/catch und beeinflusst den Nachrichtenfluss nicht; geloggt wird nach dem evaluateDelegation()-Deny-Frühausstieg, blockierte Delegationen erzeugen keine Zeile.
• Drei Testfälle grün im ersten Lauf; volle Suite 1287/1294, 6 bekannte Windows-Symlink-Skips, ein umgebungsbedingter Fehlschlag (roadmapTracker, core.autocrlf unter Windows), CI unter Linux unberührt, Lint sauber.
• Grenze: nur benannte Chat-Kanäle, aktuell agent_talk; andere Kanäle bleiben unsichtbar. Baseline folgt in 3.2ff.

Roadmap 3.3 erledigt: Geheimsprache-Score + Rekonstruktion

Roadmap-Punkt 3.3 ist umgesetzt: ein deterministischer Geheimsprache-Score und eine Rekonstruktion für auffällige Nachrichten. Die Baseline ist eine eigene, geschlossene Unigramm-Frequenztabelle; der Score ist ladeordnungsunabhängig. Geheimsprache zu übersetzen wird nicht behauptet.

• Drei Signale: OOV-Ratio, Surprisal-Abweichung (Proxy, keine echte LM-Perplexity) und wiederkehrendes Paar-Muster; Letzteres braucht keine reife Baseline und reicht allein.
• Cold-Start-Wache: ohne reife Baseline kein Alarm. score und matched_signals liegen additiv auf agent_messages, nicht auf dev_tasks.
• Evidence-Package additiv per Live-Query angebunden; der Lifecycle-Graph-Pfad wurde verworfen, weil er AegisFinding-Stages nicht zurückliest.
• Batch-Rekonstruktion über Owner-only HTTP-Routen: GET für Cluster, POST für einzelne Nachrichten.
• Korrektur serverseitig erzwungen: reviewerType agent mit claimedOutcome reconstruction_matches wird nicht akzeptiert, sondern auf not_verifiable herabgestuft. Ein Mensch muss einen Fund als harmlos schließen; severity fällt auf info, bleibt sichtbar statt gelöscht.
• Tests grün (9 und 15), volle Suite und tsc sauber.

Roadmap 3.2 erledigt: Scope Drift

Block 3.2 ist abgeschlossen: Scope Drift wird deterministisch vor dem Tool-Aufruf geprüft. Die Prüfung nutzt bestehende Quellen und ist in die echte Pipeline verdrahtet, nicht nur im Lifecycle-Graph sichtbar.

• core/scopeDrift.server.ts neu: FrozenScopeV1 leitet erlaubte Tools aus CapabilityPassportV1.tool_manifest/CUSTOMER_DEV_TASK_TOOLS und Ziel-IDs/Aktionstypen aus ImpactTargetPolicy.targets/.allowlist ab, beides bestehende Quellen.
• Eigener Klassifikator scanMarketingText(), bewusst getrennt von GrifterRadar: dessen 11 Muster erkennen Social-Engineering-Pitches an Menschen, nicht Produktprosa.
• In runCodingAgentAndCommit() prüft beforeToolCall write_file/patch_file-Calls gegen frozenScope und hängt bei einem bereits vom Kernel erkannten Deny (collab_violation/write_despite_read_contract, C1/C3) ein Signal an, ohne neu zu erkennen oder decision zu ändern.
• Befunde laufen über AgentCommitResult in die neue Spalte dev_tasks.scope_drift_findings und additiv in DevTaskControllerEvidenceV2.scope_drift_findings, damit ins signierte Evidence Package ("evidence-package@2.3").
• runCliAgentAndCommit() bleibt bewusst unverdrahtet: Der externe CLI-Agent läuft in eigenem bwrap-Prozess ohne Per-Call-Content-Hook, Inhalte werden erst im fertigen Diff sichtbar.
• Pflichttest int-drift-coding-agent-writes-marketing.test.ts: 18/18 grün, volle Suite und tsc sauber.

Roadmap 2.6 erledigt: HumanCheckpoint + Why

Roadmap 2.6 ist abgeschlossen. Der HumanCheckpoint für sensitivity:"protected"-Ziele und die Why-Kette sind umgesetzt. Freigaben nutzen den bestehenden Mechanismus, ohne zweiten Weg.

• reason:"awaiting_human" hat einen echten Kernel-Produzenten: geschützte fs_path-Ziele (write_file, patch_file, shell-rm) ohne Write-Grant liefern "awaiting_human" statt target_not_allowlisted, eine Stufe schwächer als "destructive".
• Why-Kette: buildAegisAskWhy()/buildAegisAskFromDecision() liefern Hops und Policy-IDs aus beobachteten Entscheidungen, nicht aus Modellangaben; ASK wird in der Evidence aufgezeichnet.
• Tenant-Self-Service: neue Routen zum Blockieren und einmaligen Erlauben; einmal erlauben bindet die Attestation an den konkreten Aufruf und schaltet kein anderes Ziel desselben Auftrags frei.
• Blockieren ändert keinen Task-Zustand, sondern blendet die Rückfrage aus; sie erscheint beim nächsten Versuch wieder.
• Zusatzfehler behoben: retract_destructive_deny entfernte nur einen passenden blocked_attempt; mit filter() werden auch mehrere passende Einträge entfernt.
• Pflichttests grün. Nicht in dieser Runde: sensitivity-Prüfung für account_create/social_action/network_host sowie AgentGuard-Hop-Ketten-ASK.