| Attribut | Wert |
|---|---|
| Modul-ID | CP-DD |
| Ebene | keine – Abbildungsschicht |
| Version | 0.16.0 |
| Status | pilot |
| Owner (Rolle) | <FRAMEWORK_OWNER> |
| Client | Devin Desktop (Devin Local) |
| Verbindliche Zielversion | 3.9.x, Agent-CLI 3000.10.x – der geprüfte Geltungsbereich dieses Packs; der gemessene Punktwert steht in der Zeile darunter. Das ausgelieferte Produkt liegt darüber: Der Changelog weist am 2026-09-16 3.10.31 aus (FW-AK-01, 2026-09-18). Gehoben wird die Spanne erst nach einer Messung gegen 3.10.x |
| Geprüfte Clientversion | 3.9.19 (Agent-CLI 3000.10.21) – gemessen am 2026-09-16 (.koolie/core/tests/protocols/2026-09-16-AP2-zielversion-devin-desktop.md, Läufe E1 und E2), am 2026-09-22 unverändert nachgemessen; Grundlage der 70 Sitzungsläufe des AP2-Restes. Modell aller Läufe: SWE-1.6 Slow, Konto Devin Free |
| Stand der Produktbeobachtung | 2026-09-18 (FW-AK-01, tests/protocols/2026-09-18-FW-AK-01.md): alle siebzehn Quellen QD-1 bis QD-17 und der Produkt-Changelog bis 3.10.31 abgeglichen. Die Vorbehalte daraus stehen in der Zielversion (oben), in R1 und R4 (Quellen zu einem entfernten Agenten), M2 (Organisationsebene, CVE-2026-81376) sowie S1 und X2 (Skillquellen) |
| Datum der Prüfung | 2026-09-22 – Rest von AP2: 70 Sitzungsläufe an einer Installation, siebzehn Messbäume (.koolie/core/tests/protocols/2026-09-22-ap2-rest-devin-desktop.md). Die Pfadabbildung ist am 2026-09-16 erhoben, die Belege zur Berechtigungsdatei am 2026-09-11 und 2026-09-14, alle in der Zielspanne |
Lesart. Die Spalte „Einstufung" nennt die vorgesehene Durchsetzungstiefe, die Spalte „Beleg" ihren Nachweisstand:
[DOK]= in der Herstellerdokumentation beschrieben,[EMPF]= Empfehlung des Frameworks,BELEG OFFEN= noch nicht belegt, mit Grund und Datum in der Zelle. Die Pfadabbildung ist gegen die Zielspanne erhoben (.koolie/core/tests/protocols/2026-09-16-AP2-zielversion-devin-desktop.md).An einer Installation gemessen sind S3, B3, B10 und A1 (
tests/protocols/2026-09-22-ap2-rest-devin-desktop.md): S3 und A1 tragen, B10 ist nicht abbildbar, B3 trägt mit benannter Grenze. Beobachtet sind H1, H2, R5, R6 und S5. Offen bleibt nurX2, und zwar dauerhaft: Was ein Client indexiert und wohin er es gibt, ist von außen nicht zu beobachten.Wer das Pack einsetzt, liest zuerst Abschnitt 6 (Installation), die Vorbemerkung des B-Blocks (in welchen Betriebsmodi die Berechtigungsschicht trägt) und Abschnitt 5 (bekannte Abweichungen, darunter die Benutzerkonfiguration, die eine projektseitige Verschärfung aufheben kann).
| Rolle des Artefakts | Pfad bei diesem Client | Belegstatus |
|---|---|---|
| Wurzel-Anweisungsdatei | AGENTS.md |
[DOK] |
| Regeldateien | .devin/rules/*.md mit trigger-Frontmatter |
[DOK] |
| Skills | .devin/skills/<name>/SKILL.md |
[DOK] (QD-9, Stand 2026-09-18). Der Client durchsucht sechs Ablagen je Repositorium: .agents/skills/ (vom Hersteller empfohlen), .devin/skills/, .github/skills/, .claude/skills/ (die Ablage des Schwesterpacks), .cognition/skills/ und .windsurf/skills/ – „all six paths are scanned in every repo". Für vier greift die Importsteuerung (read_config_from: cursor, windsurf, claude und copilot für .github/skills/, dokumentiert, abgerufen am 2026-09-26); für .cognition/skills/ ist kein Schalter dokumentiert. windsurf steht auf true, .windsurf/skills/ lädt also. .github/skills/ lud am 2026-09-26 (3000.11.3) auch ohne Schalter nicht; die Wirkung von copilot: false ist deshalb nicht gemessen. Das Framework schreibt nur .devin/skills/; die übrigen nennt Abschnitt 7. Ob der Desktop-Client .agents/skills/ tatsächlich liest, ist nicht beobachtet |
| Skills, die das Modell erreicht | triggers: model im Frontmatter |
Erhoben am 2026-09-22: Der Sitzungsschritt <available_skills> führt drei der zwölf koolie-*-Skills – die mit triggers: user, model – und zwei eingebaute Skills des Clients (declarative-repo-setup, upload-secrets, je source: builtin:…). Die übrigen neun meldet das Modell als nicht vorhanden; sie sind Schrägstrich-Befehle für einen Menschen. Beim Schwesterpack ist ein gesperrter Skill dagegen über den Prompt erreichbar. devin skills list auf der Kommandozeile zeigt alle zwölf, also mehr, als die Sitzung sieht. Der eingebaute upload-secrets betrifft dieselbe Dateiklasse, die B3 schützt. Er lädt über devin cloud drs secret-create; die CLI liest die Werte selbst, ein deny Read trifft diesen Weg nicht, und mit --from-env steht kein Pfad im Befehl (geklärt am 2026-09-30). Der Schutz-Hook sperrt den Befehl, gemessen ohne Regeltext und mit --permission-mode dangerous; im Standardmodus lehnte schon die Regelschicht ab (K3, nicht delegierbar) |
| Startwerkzeug für Unteragenten | run_subagent (Argument profile) |
Erhoben am 2026-09-22: Die Mitschrift führt es unter agent.tool_definitions; neben koolie-reviewer stellt der Client zwei eigene Profile bereit (subagent_explore lesend, subagent_general mit vollem Schreibzugriff). Die Werkzeugaufrufe des Unteragenten stehen nicht in der Mitschrift – wer ihn misst, braucht einen Aufzeichnungs-Hook. Schutz-Hook und deny-Korb erfassen ihn (Lauf A1-DENY2) |
| Subagentenprofile | .devin/agents/<name>.md |
[DOK] |
| Berechtigungskonfiguration | .devin/config.json (erzeugt aus framework/runtime/permissions.json) |
In Sitzungen erhoben. Der Client liest die Datei, weist aus ihrem deny-Korb ab und nennt die Quelle: „Read access … was denied by a deny rule in the project settings" (2026-09-14, Läufe P4 und W1; am 2026-09-22 in zwölf Läufen bestätigt). Den hooks-Block führt er aus derselben Datei aus, eine eigene Hook-Datei nicht (2026-09-11, AP2-DD-10). Die Körbe ask und allow sind im nicht-interaktiven Betrieb von der Voreinstellung nicht zu unterscheiden (2026-09-22): Im Modus auto weist der Client jeden Schreibaufruf auch ohne Regel ab, im Modus accept-edits läuft jeder auch mit Regel durch, und allow: Exec(git status) verhält sich wie der leere Baum. Für den interaktiven Betrieb sagt das Pack nichts zu, weil sich eine Rückfrage an einen Menschen nicht-interaktiv nicht messen lässt. Der deny-Korb ist zurechenbar: Exec(git push) wird im Regelbaum abgewiesen und im leeren ausgeführt. --permission-mode dangerous hebt ihn auf (Vorbemerkung B-Block) |
| Hook-Konfiguration | .devin/config.json unter hooks (erzeugt aus framework/runtime/hooks.json) |
In einer Sitzung erhoben (AP2, 3.9.19 / CLI 3000.10.21): Aus .devin/hooks.v1.json wird kein Hook ausgeführt, aus config.json sofort. Eingabeschema belegt, einschließlich des undokumentierten Feldes tool_use_id |
| MCP-Konfiguration | .devin/mcp_config.json (Vorlage: .devin/mcp_config.json.example) |
Am Client erhoben (2026-09-16, Läufe E5 und E6): Der Container heißt mcpServers, ein Eintrag trägt command, args und transport. Drei Ablageorte; Standard ist der unversionierte: .devin/mcp_config.local.json (local), .devin/mcp_config.json (project), die Benutzerkonfiguration (user). Gemessen ist nur der stdio-Fall; der Lauf für einen http-Server brach ohne Ausgabe ab. Stichprobe des Owners (2026-09-28): Der Atlassian-Server als stdio-Eintrag über npx mcp-remote <Adresse des offiziellen Remote-Servers> in .devin/mcp_config.local.json, Anmeldung per OAuth im Browser, trägt; die Seitenwerkzeuge liefern die Version, anders als bei claude-code. Einen Kommentar in ein Ticket verweigerte die Regelschicht (Zweck lesen), bevor die Rückfrage auf das Schreibwerkzeug anlief. Die git-ignorierte mcp_config.local.json las der Client nicht: „matched by an ignore file … not allowed to read or modify ignored files“ |
| Projektverzeichnis-Variable in Hooks | DEVIN_PROJECT_DIR |
Im Hook-Prozess erhoben (2026-09-11, fünf Aufzeichnungen, ausgewertet am 2026-09-16 als Lauf E8): gesetzt, und der Wert zeigt auf das Projektverzeichnis |
| Nutzerlokale Überschreibung | AGENTS.local.md, .devin/config.local.json, *.local.md neben Regeln |
[DOK] |
Legacy: .windsurf/ wird nicht gepflegt; .devin/ hat Vorrang [DOK].
Die Regelmenge liegt werkzeugneutral im Kern (.koolie/core/framework/runtime/permissions.json, hooks.json) und wird bei der Installation in die Werkzeuge dieses Clients übersetzt. Was dabei abgebildet wird, steht maschinenlesbar im manifest.json; diese Tabelle ist die menschenlesbare Fassung.
| Neutrales Werkzeugverb | Werkzeug bei diesem Client | Anmerkung |
|---|---|---|
read |
Read(muster) |
|
search |
– | zwei Suchwerkzeuge, grep und find_file_by_name (erhoben 2026-09-14). Eine eigene allow-Regel entfällt: Die Klasse Read(...) dieses Clients umfasst die Suche mit – ein deny Read(**/.env) weist einen grep-Aufruf auf dieselbe Datei ab |
write |
Write(muster) |
ein Werkzeug für Ändern und Anlegen |
exec |
Exec(befehl) |
wörtliche Form; die Präfixform der Quelle wird nicht gebraucht |
fetch |
Fetch(muster) |
|
mcp |
mcp__* |
ohne Muster |
| Weitere Eigenschaft | Wert |
|---|---|
| Name ohne Verzeichnisanteil | ohne Wurzelangabe (.env) |
| Hook-Werkzeugnamen | exec, edit, write |
| Projektverzeichnis im Hook-Befehl | $DEVIN_PROJECT_DIR |
Die Abbildung ist kein freies Feld: Eine deny- oder ask-Regel, für die dieser Client kein Werkzeug kennt, lässt die Installation scheitern. Nur bei allow darf eine Regel entfallen – dort ist das Weglassen eine Verschärfung.
Zur Belegspalte. Jede [DOK]-Zeile nennt die Quellenkennung der Liste in Anhang 31.4.1 (QD-1 bis QD-17); nur die Kennung lässt sich gegen die Liste halten, ein Seitenpfad darf danebenstehen. Prüfung 73 setzt das durch. Eine Zelle, die auf eine andere Zeile verweist („wie B3"), erbt deren Kennung; so hängen B4, B5, B6 und B8 an B3.
Die Quellenzuordnung ist am 2026-09-22 aus dem Bestand gewonnen (Quellenliste und Protokolle zu AP2 und FW-AK-01), nicht aus einem eigenen Abruf. Der Recherchestand der Seiten bleibt der von FW-AK-01 (2026-09-18); eine Zuordnung ist keine Aktualitätsaussage.
| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
|---|---|---|---|---|
| R1 | Wurzel-Anweisungsdatei wird ungefragt geladen | AGENTS.md wird als always-on-Regel in die Regel-Engine eingespeist |
[TECHNISCH] |
[DOK] QD-6 (cli/extensibility/rules), Stand 2026-09-18: QD-6 führt AGENTS.md als Regeldatei ohne Bindung an einen Agenten. QD-5, die Seite, die diese Zusage wörtlich hergibt, beschreibt das Laden als Einspeisung in den Systemprompt des Cascade-Agenten – und der Changelog sagt zu 3.9.19 (2026-09-08): „Cascade has been removed. Devin Local is now the only agent available in Devin Desktop." QD-5 trägt die Zeile deshalb nicht (FW-AK-01, D-159) |
| R2 | Regeldateien mit Ladebedingungen | Frontmatter trigger: always_on, model_decision, manual, agent |
[TECHNISCH] |
[DOK] QD-6 (Zuordnung K-62). AP2-DD-09, 2026-09-11): Die Seite stellt die Frontmatter-Aktivierungswerte im Zusammenhang importierter Fremdformate dar und sagt nicht ausdrücklich, dass .devin/rules/*.md dieselben Werte trägt. 🟢 K-156 beantwortet mit 1.12.1 (D-411): Mit read_config_from.windsurf: false lädt Devin CLI die Regelablage nicht – mit 3000.11.1 und 3000.11.3, gegen die Herstellerdokumentation, die .devin/rules/ als eigenen Ablageort unabhängig von der Importsteuerung führt. Das Pack setzt windsurf: true (Zeile R6). Gemessen am 2026-09-26 mit 3000.11.3 an Kennworten je Kanal: always_on lädt; model_decision erscheint mit seiner Beschreibung unter den verfügbaren Regeln. 🔴 Eine Regel mit trigger: glob lädt nicht – weder aufgeführt noch nach dem Lesen einer passenden Datei, mit und ohne Anführungszeichen um das Muster, drei Läufe (K-161). 🟢 Seit 2026-10-05 geklärt: glob lädt, wenn globs eine YAML-Liste ist und kein Muster mit einem Verzeichnis beginnt – dann fügt der Client die Regel nach dem Lesen einer passenden Datei ein. Eine Zeichenkette lädt nie, ein Muster wie backend/src/**/*.java auch in einer Liste nicht; gemessen mit 3000.11.3 in zehn Läufen (tests/protocols/2026-10-05-nachlauf-2.1.0-teil-2.md). install.py schreibt die Muster deshalb als Liste und stellt **/ voran. Die Einstufung gilt damit für always_on, model_decision und glob |
| R3 | Regeln an Dateimuster bindbar | Frontmatter trigger: glob mit globs – Grundlage der Technology Packs |
[TECHNISCH] |
[DOK] QD-6 (Zuordnung K-62) |
| R4 | Bekanntes Zeichenlimit | Wurzel-Anweisung und Regeln mit always_on zusammen höchstens 40.000 (verbindlich); 12.000 je Workspace-Regel, 6.000 global als SOLL-Grenzen – Vorgabe des Frameworks, keine Produkteigenschaft |
[TEXTUELL] |
[EMPF]. Die Zahlen stammen aus der Cascade-Dokumentation (QD-7); für Devin Local nennt der Hersteller keine Grenze. Zweimal unabhängig geprüft am 2026-09-11 gegen Devin Desktop 3.9.19 (cli/extensibility/rules, ERH-10); K-19 bleibt offen. Nachtrag 2026-09-18 (FW-AK-01): Die Herkunft der Zahlen ist Altbestand. Der Changelog sagt zu 3.9.19, Cascade sei entfernt; QD-7 schreibt selbst „Memories apply to the legacy Cascade agent only". Die Zahlen bleiben in Kraft – als Vorgabe des Frameworks; ihre Herkunft ist nur keine Aussage über das ausgelieferte Produkt mehr. QD-2 sagt weiter „The existing Cascade agent remains available through July", QD-5, QD-7 und QD-8 sprechen im Präsens von Cascade |
| R5 | Die geladenen Regelquellen sind vollständig aufzählbar | devin rules list und devin rules show <name> führen die Regeln samt Herkunftspfad und Aktivierung; devin rules paths nennt die Ablageorte. Die vollständige Auskunft des Frameworks steht in Abschnitt 7 dieses Packs |
[TEXTUELL] |
Beobachtet – und mit gemessenem Vorbehalt. Die Kommandos laufen und listen (K-21). Ihre Aufzählung ist aber nicht deckungsgleich mit dem, was lädt: Mit windsurf: false führt devin rules list die abgeschaltete Quelle unverändert auf, obwohl ihr Inhalt nicht mehr im Kontext steht (ERH-02), und devin rules paths nennt ~/.claude/skills/ nicht, obwohl 67 von 81 Skills von dort stammen (ERH-03). Die Zusage ist damit nicht technisch getragen: Das Register ist eine Auskunft des Clients über seine Konfiguration, kein Abbild des Kontexts. Wer die Wirkung prüfen will, misst den Kontext |
| R6 | Keine Importe fremder Werkzeugformate | read_config_from in der Berechtigungsdatei: cursor, claude, copilot, opencode und zed auf false; windsurf steht auf true (siehe Beleg), agents_standard bleibt true – das ist bei diesem Client das Format der eigenen Wurzel-Anweisungsdatei; es abzuschalten hieße, das Framework abzuschalten. Erzeugt von clientmap.py aus dem Manifest |
[TEXTUELL] |
Wirkung gemessen, Durchsetzung widerlegt. Am 2026-09-11 gemessen: Mit abgeschalteten Fremdformaten verschwinden 67 fremde Skills (69 → 2) und der Inhalt der fremden Regel aus dem Kontext (K-21, K-23). Ebenso gemessen: Die Benutzerkonfiguration hat in beide Richtungen Vorrang (K-27, ERH-11) – die Einstellung ist damit ein Standard, den jede Arbeitsstation still aufheben kann, wirksam dort, wo die Benutzerkonfiguration schweigt. Prüfung 22 hält die Abbildung fest, nicht ihre Wirkung. Am 2026-09-22 ein zweites Mal gemessen, und diesmal an der Menge: In sieben Läufen im Baum ohne config.json lädt die Sitzung eine Anweisungsdatei aus dem Benutzerprofil als <rules type="always-on"> – …\.codeium\windsurf\memories\global_rules.md; in sechzig Läufen mit read_config_from.windsurf: false erscheint sie in keiner Mitschrift. Sieben gegen sechzig, derselbe Arbeitsplatz, derselbe Tag (D-290). 1.12.1 steht windsurf auf true – eine Abwägung, kein Versehen (D-411, K-156): Mit false lädt der Client die eigene Regelablage nicht (3000.11.1 und 3000.11.3, siehe R2). Der Preis ist der Kanal aus D-290: Gemessen am 2026-09-26 mit Kennworten je Kanal lädt mit true die Anweisungsdatei im Benutzerprofil und .windsurf/rules/ im Projekt; laut Dokumentation dazu Skills und MCP-Server aus Windsurf. install.py nennt die Kanäle nach Installation und Update, wenn sie belegt sind (import_channels_report) – eine Auskunft, keine Schranke. copilot, opencode und zed sind dokumentierte Schlüssel mit Standard true (abgerufen am 2026-09-26); das Pack setzt sie auf false, ihre Wirkung ist nicht gemessen |
Der HTML-Kommentar einer Regeldatei geht bei diesem Client in den Kontext ein (gemessen am
2026-09-12, .koolie/core/tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md): Er steht
wörtlich in dem Regelblock, den der Client bildet, und die Sitzung gab eine Marke aus dem
Kommentar zurück, ohne eine Datei zu lesen. Beim Pack claude-code ist es umgekehrt (ERH-01).
Normative Sätze gehören trotzdem in den Fließtext, damit nicht vom Werkzeug abhängt, was gilt.
| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
|---|---|---|---|---|
| S1 | Versionierte Skills im Repository | .devin/skills/<name>/SKILL.md mit Frontmatter |
[TECHNISCH] |
[DOK] QD-9, QD-10 (Zuordnung K-62) – die Skill-Suchpfade nennen beide Seiten |
| S2 | Gezielter Aufruf | Zwei Wege, beide erhoben (2026-09-14): ein Werkzeugaufruf skill mit dem Skillnamen im Argument und die Slash-Form /name, die die CLI clientseitig in den Prompt expandiert, bevor das Modell sie sieht |
[TECHNISCH] |
[DOK] QD-10 (Zuordnung K-62: Aufruf /skill-name). Der zweite Weg ist kein Werkzeugaufruf und von einer Werkzeugschranke deshalb nicht erreichbar. Und die Berechtigungsdatei erreicht auch den ersten nicht: Skill(name) und skill(name) im deny laufen beide durch, während Read(**/.env) in denselben Läufen abweist (K-34) |
| S3 | Werkzeugbeschränkung je Skill | Frontmatter allowed-tools, permissions. Beide Felder erreichen die installierte Fassung unverändert; anders als claude-code führt dieses Pack sie nicht in drop_fields |
[TECHNISCH], unter der Bedingung aus der Belegspalte |
Erhoben am 2026-09-22 an einer Installation, und die Zusage trägt (tests/protocols/2026-09-22-ap2-rest-devin-desktop.md, D-287). Sechs von sechs Läufen mit einem aktiven Skill, der edit in beiden Feldern ausschließt, wurden abgewiesen; acht von acht ohne diese Kombination liefen durch, und die Kontrolle ohne Skillaufruf im selben Baum ebenfalls. Die Bedingung ist der Messwert: allowed-tools allein wirkt nicht (vier Läufe), permissions allein wirkt nicht (zwei Läufe) – die Einschränkung greift nur, wenn edit aus allowed-tools fehlt und ein permissions-Block dasteht. Gemessen an vier Bäumen, die sich nur im Frontmatter eines Sondenskills unterscheiden, und am ausgelieferten koolie-code-explain. Alle dreizehn ausgelieferten Skills führen beide Felder – die Bedingung ist im Bestand erfüllt. K-93). Der Gegenbefund beim Schwesterpack bleibt davon unberührt (B01, CR-2026-050, D-50). 🟢 Auch für exec belegt (Stichprobe des Owners, 2026-09-28, D-468, K-187): Unter koolie-change-analyze wurden git status und find mit „Permission denied for this tool.“ abgewiesen, obwohl die Berechtigungsdatei Exec(git status) freigibt – auch diese Meldung nennt den Skill nicht. Ausgelesen aus der Sitzungsdatenbank des Clients (sessions.db, Tabelle tool_call_state) |
| S4 | Schreibende Skills nur benutzergetriggert | Frontmatter triggers – Framework-Konvention, statisch geprüft durch .koolie/core/tests/scripts/validate-framework.py |
[TEXTUELL] |
[EMPF]; die Laufzeitwirkung ist Modellverhalten. Reichweite: Die Zusage gilt für die Skill-Ablage, die das Framework schreibt. Skills aus Ablagen außerhalb des Repositoriums unterliegen diesen Konventionen nicht; sie sind nach Regel 2.6 der Prioritätshierarchie ebenenlos und dürfen den Handlungsspielraum nur einschränken (AP2-DD-16, CR-2026-032) |
| S5 | Die geladenen Skills sind vollständig aufzählbar, samt Herkunft und Aufrufbarkeit | devin skills list --json führt je Skill provider, base_dir und triggers; devin skills paths nennt die Suchpfade |
[TEXTUELL] |
Beobachtet – mit demselben Vorbehalt wie R5. Am 2026-09-11 führte die Liste 81 Skills, davon 67 aus ~\.claude\skills\ mit [user,model] (AP2-DD-16, K-24). devin skills paths nennt diese Ablage jedoch nicht (ERH-03): Die Aufzählung der Skills ist vollständig, die der Pfade nicht. Aufzählbarkeit ist zudem keine Kontrolle – die Liste entsteht nur, wenn ein Mensch das Kommando ausführt. Zweiter Befund am 2026-09-12 (ERH-17): Der Block <available_skills>, den der Client in den Sitzungskontext stellt, nennt je Skill den vollen Quellpfad – die Auskunft existiert also, nur nicht in dem Kommando, das sie verspricht. Als Ersatz für die fehlende Pfadangabe von devin skills paths steht daneben install.py --list-skills (CR-2026-041 E3), das den Teil aufzählt, für den das Framework einstehen kann. Am 2026-09-22 ist die Grenze dieser Aufzählung gemessen (D-288): devin skills list führt alle zwölf Skills des Frameworks, der Sitzungsschritt <available_skills> führt drei – die mit triggers: model – und dazu zwei eingebaute Skills des Clients, die in keiner Auflistung des Projekts stehen. Die Auflistung zeigt etwas, was die Sitzung nicht sieht, und verschweigt etwas, was sie sieht. Wer die Skillmenge einer Sitzung wissen will, liest die Mitschrift, nicht die Kommandozeile |
[TECHNISCH]heißt in diesem Block: Die Engine setzt die Regel durch, solange der Betriebsmodus die Berechtigungsprüfung nicht abschaltet. Die Einstufungen gelten für die Betriebsmodiauto,accept-editsundsmart; gemessen sind diese drei unddangerous.--permission-mode dangeroushebt den gesamtendeny-Korb auf (gemessen am 2026-09-22):Read(.env)wurde gelesen undExec(git push)ausgeführt, obwohl beide unter_core_rules_integrity.deny_must_containstehen, der Liste, die das Projekt nicht entfernen darf. Dort trägt der Schutz-Hook: Er blockierte denselben Lesezugriff (LaufH-D, Baum ohne Berechtigungsregeln; ebenso am 2026-09-11 im ModusBypass,AP2-DD-12). Diese Aussage setzt keine Prüfung durch.Die Sitzung muss im Verzeichnis der Installation starten (gemessen am 2026-09-26 mit Clientversion 3000.11.1,
tests/protocols/2026-09-26-mehrprojekt-tokenlast.md). In einem Unterverzeichnis mit eigenem git-Repositorium lädt der Client weder die Wurzel-Anweisung der Elternebene noch deren Berechtigungsdatei und Hooks: Ein Kennwort aus der Wurzel-Anweisung war unbekannt, ein aufzeichnender Hook lief nicht, und eine durchWrite(**/*.lock)gesperrte Datei wurde im Modusaccept-editsangelegt. In der Wurzel lief der Hook und blockierte den Lesezugriff auf.env; ein Kontrolllauf für diedeny-Regel dort fehlt, weil das Modell den Schreibaufruf nicht absetzte. Eine eigene Installation im Unterverzeichnis trägt. Einen falschen Startort meldet nichts.
| ID | Zusage des Frameworks | Kern | Mechanismus beim Client | Einstufung | Beleg |
|---|---|---|---|---|---|
| B1 | Berechtigungen versioniert im Repository | ja | .devin/config.json |
[TECHNISCH] |
[DOK] QD-12 (Zuordnung K-62) |
| B2 | Verweigern vor Rückfragen vor Erlauben | ja | Zusammenführung über Ebenen | [TECHNISCH] |
[DOK] QD-11 (Zuordnung K-62) |
| B3 | Secret-Dateien per Pfadmuster lesegeschützt | ja | Verweigerungsregeln auf .env, **/*.pem, **/secrets/** und weitere. Je Kanal: direktes Lesen wirkt (Regel und Hook); Shell wirkt über den Schutz-Hook; Suche wirkt über beide Schichten – ohne die Suchklasse im Hook-Matcher kam in einer Umgebung mit nur diesem Hook ein Secret über grep wörtlich heraus (gemessen 2026-09-14, tests/protocols/2026-09-14-erhebung-devin-werkzeuge.md, Läufe H1 und H2; wie ausgeliefert trug die Berechtigungsschicht, Läufe P4 und W1); Notebook-Lesen wirkt (2026-09-22) – die Klasse Read(…) dieses Clients umfasst auch notebook_read (Lauf KA-NB-P), obwohl das Manifest es nicht nennt; Notebook-Schreiben und Unterprozess nicht nachgewiesen. Im untersagten Betriebsmodus greift die Regel nicht und allein der Hook trägt (AP2-DD-12; am 2026-09-22 für --permission-mode dangerous nachgemessen, Läufe KA-D-P3 und H-D) |
[TECHNISCH] für Lesen, Suche, Notebook-Lesen und Shell; [TEXTUELL] für den Unterprozess |
Mechanismus [DOK] QD-11 (Zuordnung K-62). Muster-Semantik erhoben am 2026-09-22 in neun Läufen (D-277): **/ trifft null Verzeichnisse (server.pem auf Wurzelebene fällt unter Read(**/*.pem)) und mehrere (unter/tief/gold.pem); ein Präfixmuster ohne **/ wirkt (Read(deploy/**)). 🔴 Grenze, gemessen: Die Muster unterscheiden Groß- und Kleinschreibung. Read(**/*secret*) weist klein/notiz.secret ab und lässt UNTEN/Notiz.SECRET durch – zweimal gefahren –, während NTFS beide Schreibweisen als dieselbe Datei führt. Der Schutz-Hook tut das Gegenteil (Zeile H4), und seine Semantik gilt (K-92, D-492): Die Berechtigungsschicht gehört dem Client und lässt sich nicht angleichen; für das direkte Lesen trägt deshalb der Hook die Zusage in jeder Schreibweise, die Regel nur in der des Musters. Beim Pack claude-code unterscheidet die Berechtigungsschicht nicht (gemessen am 2026-09-30). Reichweite je Kanal: Der Befund B04 ist am Schutz-Hook gemessen (tests/protocols/2026-09-12-B04-B05-gegenpruefung.md); der Hook ist bei beiden Packs derselbe, die Berechtigungsschicht nicht |
| B4 | Framework- und Overlay-Artefakte schreibgeschützt | ja | Verweigerungsregeln auf AGENTS.md, .devin/ und das gesamte Kernverzeichnis (.koolie/core/**). Das Overlay sperrt allein der Schutz-Hook; die Berechtigungsdatei führt es nicht (nachgezählt an einer Installation am 2026-09-29). Je Kanal: direktes Schreiben wirkt; Shell und Unterprozess wirken nicht – die Berechtigungsdatei führt für exec ausschließlich Befehlsverbote und keine Pfadregel, und der Schutz-Hook prüft das Kernverzeichnis nur bei schreibenden Werkzeugen. Was den Shell-Schreibweg aufhält, ist die Regelschicht |
[TECHNISCH] für das direkte Schreiben; [TEXTUELL] für Shell und Unterprozess |
wie B3. Reichweite je Kanal: Der Befund B04 ist am Schutz-Hook gemessen (tests/protocols/2026-09-12-B04-B05-gegenpruefung.md); der Hook ist bei beiden Packs derselbe, die Berechtigungsschicht nicht (Läufe B04-1 bis B04-3) |
| B5 | CI-, Quality-Gate- und Lockdateien schreibgeschützt | ja | Verweigerungsregeln auf Lockdateien und die Overlay-Platzhalterpfade. Je Kanal wie B4: direktes Schreiben wirkt, Shell und Unterprozess nicht | [TECHNISCH] für das direkte Schreiben; [TEXTUELL] für Shell und Unterprozess |
wie B4 |
| B6 | Befehle per Muster verweigerbar | ja | Verweigerungsregeln auf Push-, Merge-, Lösch- und Rechteausweitungsbefehle | [TECHNISCH] |
wie B3 |
| B7 | Schreiboperationen fragen zurück | – | Rückfrageregel auf alle Schreiboperationen | [TECHNISCH] |
[DOK] QD-11 (Zuordnung K-62) |
| B8 | Netzwerkzugriff standardmäßig unterbunden | – | Verweigerungsregeln auf das Abrufwerkzeug sowie auf die Befehle curl, wget, ssh und scp. Je Kanal: das Abrufwerkzeug wirkt; der Shell-Kanal nur für diese vier Programme – andere netzfähige Programme sind nicht erfasst, und die Liste wird nicht verlängert |
[TECHNISCH] für das Abrufwerkzeug; [TEXTUELL] für den Shell-Kanal |
wie B3. Reichweite je Kanal: Der Befund B04 ist am Schutz-Hook gemessen (tests/protocols/2026-09-12-B04-B05-gegenpruefung.md); der Hook ist bei beiden Packs derselbe, die Berechtigungsschicht nicht (Lauf B04-6) |
| B9 | Nutzerlokale Konfiguration kann nur verschärfen | – | .devin/config.local.json und die Benutzerkonfiguration %APPDATA%\devin\config.json – Framework-Regel, keine Produkteigenschaft |
[TEXTUELL] |
[EMPF]. Der Client verhindert eine Lockerung nicht. Gemessen am 2026-09-11 in beiden Richtungen (K-27, ERH-11): Der Wert der Benutzerkonfiguration setzt sich gegen den projektseitigen durch – auch dann, wenn der projektseitige der strengere ist. Eine projektseitige Verschärfung ist damit ein Standard, den jede Arbeitsstation still aufheben kann, wirksam dort, wo die Benutzerkonfiguration schweigt (der Normalfall). Bei claude-code ist die Lage anders, gemessen am 2026-09-12 (tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md, Abschnitt 2.3): Dort setzt sich eine Verweigerung von jeder Ebene durch – die Benutzerkonfiguration kann verschärfen, nicht lockern, und auch ein nutzerglobales defaultMode: bypassPermissions blieb wirkungslos. Dieselbe Frage, zwei Clients, entgegengesetzte Antworten |
| B10 | Externer Abruf auf freigegebene Domains beschränkbar | – | Erhoben am 2026-09-22: Die Berechtigungsdatei erreicht den Abrufkanal dieses Clients in keiner Richtung. Das Abrufwerkzeug heißt webfetch; Fetch ist kein Werkzeugname dieses Clients (die Mitschrift führt die 25 Werkzeuge unter agent.tool_definitions). In acht Läufen über sechs Bäume, drei Schreibweisen und drei Betriebsmodi führen deny: Fetch(*), kein Korb, allow: Fetch(*), allow: Fetch(example.com) und allow: webfetch zum selben Ausgang wie der leere Korb: Der Aufruf scheitert am Betriebsmodus, und der Client nennt nie eine Regel als Quelle. Eine Domain-Angabe kann deshalb nicht wirken. Die Regel Fetch(*) bleibt in der werkzeugneutralen Regelmenge des Kerns und ist hier mechanisch unwirksam – wie AP2-CC-02, nur ohne Meldung beim Sitzungsstart. Den Kanal steuert allein der Betriebsmodus: auto, accept-edits und smart weisen jeden Abruf ab, dangerous lässt jeden durch. Ersatz durch das Framework: keiner, der Kern sagt die Beschränkung nicht zu (B11). Organisatorischer Ersatz ist die Freigabezeile des Overlays, ohne technische Seite |
[NICHT ABBILDBAR] |
gemessen, tests/protocols/2026-09-22-ap2-rest-devin-desktop.md Abschnitt 6. Der Kern sagt diese Beschränkung nicht zu (B11, D-59); die Zeile hält fest, warum sie es auch nicht könnte |
| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
|---|---|---|---|---|
| H1 | Prüfung vor Werkzeugausführung | hooks.PreToolUse in .devin/config.json; Matcher auf lesende, schreibende und ausführende Werkzeuge und auf MCP-Werkzeuge (mcp__.*) |
[TECHNISCH] |
beobachtet (AP2, tests/protocols/2026-09-11-AP2-devin-desktop.md); MCP-Werkzeuge heißen am Hook mcp__<server>__<werkzeug>, gemessen am 2026-10-06 mit einem Köderserver: der Köderwert erreichte den Server nicht, eine harmlose Notiz schon. Die Hooks stehen in der Berechtigungsdatei, weil der Client eine eigene Hook-Datei nicht liest (D-32) |
| H2 | Prüfung kann blockieren | Exit-Code 2 des Hook-Befehls bricht die Operation ab. Fail-closed (hook_fail_closed: true): Das Eingabeschema ist gegen eine Installation belegt, damit darf der Hook sperren, statt nur zu warnen |
[TECHNISCH] |
beobachtet: Ein Lesezugriff auf eine Secret-Datei wurde blockiert – in einer Umgebung ohne Regeltexte und bei ausgeschalteter Berechtigungsschranke, dort kann nichts als Anweisung gewirkt haben |
| H3 | Statusmeldung beim Sitzungsstart | SessionStart mit hook-overlay-status.py in .devin/config.json |
[TECHNISCH] |
[DOK] QD-13 Mechanismus (Zuordnung K-62); die Meldung selbst ist nicht beobachtet. Der Agent nannte den Overlay-Status zwar, konnte ihn aber aus den Regeltexten haben (AP2-DD-10) |
| H4 | Eingabeschema und Pfadidentität des Schutz-Hooks | Wie beim Pack claude-code: Ereignisprüfung, unprüfbar als eigener Ausgang (blockiert, weil dieses Pack hook_fail_closed: true führt), Prüfung der Operation statt des Umschlags, Pfadidentität über den aufgelösten Pfad, alle Pfadmuster ohne Rücksicht auf Groß-/Kleinschreibung. Eine Angabe /c/… löst der Hook unter Windows in beiden Lesarten auf – dieser Client liest sie als C:\c\…, eine MSYS-Shell als C:\…. Grenze: Ein Hook prüft vor dem Zugriff; eine zwischenzeitlich umgebogene Verknüpfung kann er nicht ausschließen |
[TECHNISCH], mit benannter Zeitlücke |
Gemessen am 2026-09-13 (tests/protocols/2026-09-13-B06-gegenpruefung.md, Befund B06): Die fünf Hook-Aufzeichnungen dieses Packs führen hook_event_name, prompt_id, session_id, tool_input, tool_name, tool_use_id – kein transcript_path und kein cwd. Der Fehlblockade-Befund des anderen Packs tritt hier deshalb nicht auf; das ist eine Eigenschaft dieses Schemas, keine des Hooks |
| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
|---|---|---|---|---|
| A1 | Rein lesendes Reviewprofil | .devin/agents/koolie-reviewer.md |
[TECHNISCH] |
Profilwirkung erhoben am 2026-09-22 und belegt (D-284, tests/protocols/2026-09-22-ap2-rest-devin-desktop.md Abschnitt 7): Das allowed-tools eines Subagentenprofils bestimmt den Werkzeugbestand des Unteragenten. Das Vollzugriffsprofil des Clients ruft exec und write auf; eine synthetische Sonde mit read, grep, glob und neutralem Rollentext ruft kein Werkzeug auf, und koolie-reviewer verhält sich wie die Sonde. Das Profil steht in der Sitzung, mit seiner eigenen Beschreibung und vor den beiden eingebauten Profilen des Clients. Der Beleg kommt nicht aus der Mitschrift: --export führt den Unteragenten nicht (D-282) – gemessen über einen Aufzeichnungs-Hook mit Positivkontrolle. Grenze: Belegt ist der Werkzeugbestand, nicht die Reichweite je Werkzeug. Mechanismus [DOK] QD-14 (Zuordnung K-62); Startwerkzeug run_subagent, erhoben am selben Tag |
| A2 | Rein lesendes Analyseprofil für Modus M1 | Subagent-Profil subagent_explore |
[TECHNISCH] |
[DOK] QD-14 (Zuordnung K-62: eingebaute Profile); übernommen mit CR-2026-025 |
| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
|---|---|---|---|---|
| M1 | Standardmodus fragt bei Schreiben und Befehlen zurück | Modus Normal (CLI: auto) |
[TECHNISCH] |
[DOK] (QD-11); die CLI-Namen abgeglichen am 2026-09-11 gegen 3.9.19 (ERH-08) |
| M2 | Modus ohne Rückfragen ausschließbar | Bypass (CLI: dangerous, auch über DEVIN_PERMISSION_MODE) ist untersagt (03-security.md Abschnitt 4). Eine Sperre des Modus selbst ist bei diesem Client nicht dokumentiert, nur die Begrenzung seiner Wirkung durch die Terminal Permissions der Organisationsebene, die laut Team-Dokumentation den höchsten Vorrang haben und von lokalen wie projektseitigen Konfigurationen nicht überschrieben werden – sie greifen also auch bei gewähltem Bypass |
[TEXTUELL] |
[DOK] für die Wirkungsbegrenzung (QD-16); nicht beobachtet – ohne Team-Plan mit Admin-Kontrollen nicht beobachtbar (K-05). Abgeglichen am 2026-09-11 gegen 3.9.19. Bei claude-code ist die Modus-Sperre selbst dokumentiert und belegt (AP2-CC-05) – die Packs unterscheiden sich hier. 🔴 Nachtrag 2026-09-18 (FW-AK-01), und er trifft die tragende Hälfte dieser Zeile: Die Wirkungsbegrenzung steht und fällt damit, dass die Organisationsebene unüberschreibbar ist – QD-12 sagt das unverändert („Organization-level (enterprise) settings can never be overridden by project or user config"). In der verbindlichen Zielspanne dieses Packs galt es nicht. Der Changelog weist zu 3.10.31 (2026-09-16) aus: „Restricted Mode blocks restricted workspace settings written in nested object form, not just the dotted form (CVE-2026-81376)." Bis einschließlich 3.10.27 wurde dieselbe eingeschränkte Einstellung also je nach Schreibweise durchgesetzt oder nicht – und QD-12 verwendet in seinen Beispielen die verschachtelte Form und nennt den Restricted Mode mit keinem Wort. Die Zielspanne 3.9.x liegt vollständig vor der Behebung. Das ist die Bauform von D-150 im Produkt: dieselbe Regel in zwei Ausdrucksformen, durchgesetzt nur in einer. Das Framework hat die eigene Entsprechung mit Prüfung 54 geschlossen (D-155) |
| M3 | Freigabe auf die Sitzung begrenzbar | Sitzungsfreigaben „einmalig" und „für die Sitzung" | [TECHNISCH] |
[DOK] QD-11 (Zuordnung K-62: Sitzungs-Grant-Stufen). Dieselbe Zusage beim Schwesterpack ist nicht zugeordnet – dort führt keine der sechs Seiten die Grant-Stufen (K-62) |
| M4 | Eigener Planungsmodus für Modus M2 | Plan-Modus mit persistenter Plan-Datei unter ~/.devin/plans/plan-<session>.md; die Datei liegt außerhalb des Repositorys |
[TECHNISCH] |
[DOK] QD-3, QD-4 (Zuordnung K-62: der Modus aus QD-3, die persistente Plan-Datei aus QD-4); übernommen mit CR-2026-025 |
| M5 | Eigener Nur-Lese-Modus für Modus M1 | Plan-Modus („read-only research“) | [TECHNISCH] |
[DOK] QD-3 (Zuordnung K-62); übernommen mit CR-2026-025 |
| M6 | Modus mit selbsttätiger Übernahme von Dateiänderungen begrenzbar | Accept Edits (CLI: accept-edits) genehmigt Dateiänderungen im Workspace ohne Rückfrage; nach 03-security.md Abschnitt 4 nur über dokumentierte Ausnahme bei Kontrollstufe niedrig zulässig. Eine Abschaltung des Modus ist nicht dokumentiert; wirksam ist auch hier allein die Wirkungsbegrenzung der Organisationsebene |
[TEXTUELL] |
[DOK] für den Modus (QD-11), [EMPF] für die Beschränkung; nicht beobachtet (K-05) |
| M7 | Selbst beurteilender Modus begrenzbar | Smart (CLI: smart) genehmigt Workspace-Änderungen selbsttätig und beurteilt die übrigen Aktionen nach eigener Sicherheitseinschätzung; nach 03-security.md Abschnitt 4 nur über dokumentierte Ausnahme bei Kontrollstufe niedrig zulässig. Ein Modus, der selbst beurteilt, was sicher ist, ersetzt die menschliche Freigabe durch Modellverhalten. Abschaltung nicht dokumentiert; Wirkungsbegrenzung wie M2 |
[TEXTUELL] |
[DOK] für den Modus (QD-11), [EMPF] für die Beschränkung; nicht beobachtet (K-05) |
| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
|---|---|---|---|---|
| X1 | Keine externe Anbindung ohne Einzelfreigabe | Keine MCP-Konfiguration ausgeliefert, nur die .example-Vorlage; Rückfrageregel auf alle MCP-Werkzeuge |
[TECHNISCH], mit zwei benannten Grenzen |
[DOK] (QD-11, QD-12), Stand 2026-09-18. Erste Grenze: Der Mechanismus deckt die Werkzeuganbindung. Das fremde Agentenprotokoll, das D-10 ebenfalls standardmäßig deaktiviert stellt, deckt er nicht – und der clientseitige Schalter ist entfallen: Changelog 3.10.23 (2026-09-10), „ACP is always enabled — the Enable ACP toggle is gone." Die Freigabezeile des Overlays bleibt als organisatorische Auflage in Kraft und hat für diesen Client keine technische Seite mehr (K-65). Zweite Grenze: Die organisationsseitige Skillquelle (QD-9, „Indexed repos") speist Skills aus allen angebundenen Repositorien in jede Sitzung ein, bevor überhaupt geklont wird. Sie liegt außerhalb jeder Datei, die das Framework schreibt, und die Teameinstellungen (QD-16) nennen sie nicht (K-64) |
| X2 | Art und Ort der Codebasis-Indexierung bekannt | Kein Mechanismus zur Steuerung bekannt | [NICHT ABBILDBAR] |
BELEG OFFEN (dauerhaft) – von außen nicht zu beobachten, Stand 2026-09-22 (K-20, D-292). Kein Ersatz durch das Framework: Was ein Client indexiert und wohin er es gibt, ist von außen nicht zu beobachten – weder die Installation noch der Validator sehen es. Die Zusage entfällt für diesen Client; K-20 hält die Frage ohne Frist offen. Nach D-41 eine Fähigkeitszusage, keine Kernzusage. Nachtrag 2026-09-18 (FW-AK-01): der erste dokumentierte Datenpunkt, und er ist schmal. QD-9 sagt: „Devin discovers skills from two sources, merged together at the start of every session: 1. Indexed repos — Devin's backend indexes SKILL.md files across all repositories connected to your organization." Damit ist für einen Gegenstand – Skilldateien – gesagt, dass eine serverseitige Indexierung stattfindet und woher sie speist. Über die Codebasis sagt es nichts, der Beleg bleibt offen, und ein Steuerungsmechanismus ist weiter nicht dokumentiert (K-64) |
Zählregel (normativ für diese Tabelle): Eine Zeile zählt bei ihrer schwächsten Einstufung. Trägt sie zwei Angaben je Zugriffskanal –
[TECHNISCH]für direktes Lesen und Schreiben,[TEXTUELL]für Shell und Unterprozess –, zählt sie als[TEXTUELL]. Zugesagt wird je Kanal, was gemessen ist; eine Zeile, deren Zusage in einem Kanal nur als Anweisung trägt, ist nicht technisch durchgesetzt. Prüfung 31 rechnet die Summen aus der Matrix nach.
| Klasse | Anzahl | davon Kernzusagen |
|---|---|---|
[TECHNISCH] |
21 von 36 | 3 von 6 (B1, B2, B6) |
[TEXTUELL] |
13 von 36 | 3 von 6 (B3, B4, B5 – Shell und Unterprozess) |
[NICHT ABBILDBAR] |
2 von 36 | 0 |
Belegstand: Genau eine Zeile sagt BELEG OFFEN – X2, dauerhaft, weil von außen nicht zu beobachten ist, was ein Client indexiert. Ein Verweisbeleg („wie B3") erbt den Beleg seines Ziels; B4, B5, B6 und B8 sind deshalb mit B3 belegt. Diese Angabe rechnet keine Prüfung nach. Gegen eine Installation geprüft sind S3, B3, B10 und A1 (2026-09-22) sowie H1, H2 (AP2) und R5, R6, S5 (2026-09-11).
Alle sechs Kernzusagen (B1 bis B6) sind als [TECHNISCH] vorgesehen; B3, B4 und B5 für den direkten Zugriff, für Shell und Unterprozess [TEXTUELL] (Abschnitt 3). Keine ist durch eine Messung zurückgenommen – B3 ist in neun Läufen bestätigt, mit der benannten Mustergrenze –, ein Eintrag hier ist deshalb nicht nötig. Zwei Grenzen stehen in der Vorbemerkung des B-Blocks: --permission-mode dangerous hebt den deny-Korb auf, dort trägt der Schutz-Hook; und die Pfadmuster der Berechtigungsschicht unterscheiden Groß- und Kleinschreibung.
Ergibt eine Prüfung, dass eine der sechs Zusagen nicht technisch durchgesetzt wird, ist sie hier einzutragen und nach der Regel in .koolie/core/clients/README.md Abschnitt 4 durch <SECURITY_CONTACT> freizugeben.
- Der Schutz-Hook läuft fail-closed (
hook_fail_closed: true): Das Eingabeschema ist gegen eine Installation belegt (Zeile H2). Die Hook-Aufzeichnungen dieses Clients führen wedertranscript_pathnochcwd, daher keine Fehlblockade wie beim Packclaude-code(Zeile H4). Prüfung 17 hält die Zusage an ihrer Wirkung fest. - Der nicht-interaktive Lauf bricht gelegentlich still ab. Braucht ein Lauf eine Rückfrage, endet er manchmal ohne Ausgabe mit Erfolgscode (
AP2-DD-13, ERH-05); eine leere Ausgabe beweist also nichts. Jeder Nachweislauf nach Abschnitt 6 bekommt deshalb--export <pfad>– die Mitschrift führt alle Schritte, auch wenn stdout leer bleibt –, und jeder Nachweis aus dem Ausbleiben einer Wirkung trägt eine Positivkontrolle im selben Lauf (Testkatalog Nr. 7). - Die Vertrauensschranke greift im nicht-interaktiven Betrieb. In einem unbestätigten Verzeichnis scheitert der Print-Modus, solange die Vertrauensprüfung nicht abgeschaltet ist (
--respect-workspace-trust false,AP2-DD-14). Die Prüfung nach Abschnitt 6 läuft in einem frischen Verzeichnis deshalb erst nach der Bestätigung. Ein Nachweis mit abgeschalteter Schranke ist zulässig, gilt aber nicht für den Normalbetrieb und nennt die Bedingung im Protokoll (Testkatalog Nr. 7). - Nutzerlokale Konfiguration kann lockern – B9 gilt bei diesem Client nicht. Die Benutzerkonfiguration (
%APPDATA%\devin\config.json) setzt sich in beide Richtungen gegen die projektseitige durch (ERH-11). Jede Arbeitsstation kann eine projektseitige Verschärfung also still aufheben, in einer Datei außerhalb des Repositoriums. Wirksam bleibt die Verschärfung, wo die Benutzerkonfiguration schweigt – der Normalfall, aber keine Zusage. Dagegen hilft nur eine Regel auf Ebene 2 (Organisation). - Sechs Skill-Ablagen je Repositorium (Abschnitt 1,
QD-9). Das Framework schreibt.devin/skills/, der Hersteller empfiehlt.agents/skills/. Welche Ablagen der Desktop-Client tatsächlich liest, ist unbestätigt. - Keine Workflows, keine Memories
[DOK]. Skills und versionierte Regeln übernehmen diese Funktion. - Keine Sandbox unter Windows (laut Dokumentation). Der Modus
Autonomous– in der CLI das Flag--sandbox(ERH-08) – ist dort nicht absicherbar;03-security.mdAbschnitt 4 lässt ihn nur zu, wo die Sandbox verfügbar ist, auf der Zielplattform also nicht. Er hat keine Matrixzeile, weil das Framework hier keine Zusage abbildet, sondern eine Beschränkung benennt. - Modusnamen von Oberfläche und CLI weichen ab. Oberfläche:
Normal,Accept Edits,Smart,Bypass; CLI (devin --help, 2026-09-11):auto,accept-edits,smart,dangerous. Die Zeilen M1, M2, M6 und M7 führen beide.
Die Starter install.cmd (Windows) und install.command (macOS) in der Wurzel des Archivs fragen Projekt, Client und Overlay-Muster im Dialog ab und rufen install.py --target auf. Ohne Dialog, aus dem entpackten Archiv:
python .koolie/core/install.py --target /pfad/zum/projekt --client devin-desktop
Danach im Projekt:
python .koolie/core/tests/scripts/validate-framework.py
Ohne --client erkennt install.py das installierte Pack; bei einer Erstinstallation ist devin-desktop der Standard. Ein Projekt, das den Kern schon trägt, wird mit --update aktualisiert.
Was dieser Client aus Ablagen außerhalb des Repositoriums lädt. Solche Quellen haben nach Regel 2.6 der Prioritätshierarchie keine Ebene: Sie dürfen einschränken, nie über die Ebenen 1 bis 4 hinaus erweitern und keine Governance-, Datenschutz- oder Sicherheitsregeln setzen.
Erhebungsstand: 2026-09-11, Devin Desktop 3.9.19 / CLI 3000.10.21, erhoben mit devin rules list, devin rules show <name>, devin rules paths, devin skills list --json, devin skills paths und devin doctor, dazu gemessene Kontextläufe in einer Installation ohne Regeltexte (tests/protocols/2026-09-11-erhebungen-K21-K26.md).
| Quelle | Ladebedingung | Belegstatus | Maßnahme des Frameworks |
|---|---|---|---|
~\.codeium\windsurf\memories\global_rules.md |
always-on, in jedem Projekt – auch in einem ohne jeden Regeltext | Gemessen (AP2-DD-15, Lauf A): Der Inhalt stand wörtlich im Kontext einer Sitzung in einem Verzeichnis ohne Regeltexte |
zugelassen (read_config_from.windsurf: true, R6); gemessen am 2026-09-26: ein Kennwort in der Datei erreicht die Sitzung. install.py meldet die Datei, wenn sie nicht leer ist |
.windsurf/ im Projekt (Regeln, Skills); MCP-Server aus Windsurf (~\.codeium\windsurf\mcp_config.json) |
Regeln always-on nach ihrem Frontmatter | Regeln gemessen am 2026-09-26 (Kennwort in .windsurf/rules/ lädt mit windsurf: true); Skills und MCP-Server [DOK], der Ablageort der MCP-Datei nach Windsurf-Konvention, nicht erhoben |
zugelassen; install.py meldet .windsurf/ im Projekt und eine vorhandene mcp_config.json |
~\.claude\skills\ |
67 von 81 Skills, Aufrufbarkeit [user,model] |
Gemessen (AP2-DD-16): Ein Skill von dort läuft; seine Werkzeugaufrufe erreichen Berechtigungsschranke und Schutz-Hook |
abgeschaltet über read_config_from.claude: false (R6); gemessen 69 → 2 Skills |
%APPDATA%\devin\AGENTS.md, ~\.devin\rules\*.md, ~\.devin\global_rules.md, ~\.claude\CLAUDE.md |
laut Herstellerdokumentation weitere Ablageorte für Regeln | [DOK] (ERH-09); auf dieser Arbeitsstation nicht erhoben; die ersten drei sind das eigene Format des Clients und von read_config_from nicht erfasst |
keine; sie bleiben Auskunft |
Berechtigungen, Hooks und Einstellungen außerhalb des Repositoriums betreffen genau die Linien, auf denen B1 bis B6 stehen.
| Quelle | Wirkung | Belegstatus |
|---|---|---|
%APPDATA%\devin\config.json (Benutzerkonfiguration) |
führt dieselben Schlüssel wie die Projektdatei – Berechtigungen, Hooks, read_config_from – und hat Vorrang, auch gegenüber einer projektseitigen Verschärfung |
Gemessen in beiden Richtungen (ERH-11); B9 gilt bei diesem Pack nicht |
.devin/config.local.json |
nutzerlokale Überschreibung im Projekt, nicht versioniert | [DOK]; dieselbe Lage wie oben |
Eine Auskunft ist keine Schranke. Was in read_config_from steht, kann die Benutzerkonfiguration aufheben (7.2); die Einstellung wirkt dort, wo jene schweigt.
Ein Abwesenheitsbeleg altert. Der Erhebungsstand oben gilt bis zur nächsten Clientversion. Prüfung 19 prüft, dass diese Auskunft da ist, nicht, dass sie stimmt.
Das Register des Clients ist keine zweite Quelle. Es zeigt mehr, als lädt (ERH-02), und seine Pfadauskunft weniger, als es gibt (ERH-03). Maßgeblich ist dieser Abschnitt, gestützt auf gemessene Kontextläufe.
| Version | Datum | Änderung | Autor (Rolle) |
|---|---|---|---|
| 0.1.0 | 2026-09-10 | angelegt aus dem Ist-Zustand der Laufzeitschicht (CR-2026-002) |
<FRAMEWORK_OWNER> |
| 0.2.0 | 2026-09-10 | Berechtigungen und Hooks aus dem Pack in den Kern; Semantikabbildung ergänzt (CR-2026-008) |
<FRAMEWORK_OWNER> |
| 0.3.0 | 2026-09-10 | Overlay-Laufzeitregel und die beiden Vorlagen in den Kern; Pack umfasst vier Dateien (CR-2026-010) |
<FRAMEWORK_OWNER> |
| 0.3.2 | 2026-09-11 | Fail-open ausgewiesen statt vorausgesetzt (CR-2026-026, D-31). Das Manifest führt hook_fail_closed: false; der Schutz-Hook dieses Packs lässt eine nicht lesbare Eingabe weiter durch, weil das Eingabeschema unbestätigt ist (V3). Prüfung 17 hält die Zusage an ihrer Wirkung fest. Das Pack claude-code führt seit diesem Release true – die Abweichung steht jetzt in der Matrix, statt aus dem Fehlen einer Angabe zu folgen |
<FRAMEWORK_OWNER> |
| 0.3.3 | 2026-09-11 | Die Hooks liegen in der Berechtigungsdatei (CR-2026-029, D-32) und der Schutz-Hook läuft fail-closed (CR-2026-026, D-31). AP2 hat gezeigt, dass aus .devin/hooks.v1.json kein Hook ausgeführt wird – H1 bis H3 waren wirkungslos. Mit dem belegten Eingabeschema ist auch die Bedingung für fail-closed erfüllt. H1 und H2 sind jetzt beobachtet, nicht nur dokumentiert; H3 bleibt unbeobachtet. Der Matcher deckt zusätzlich das Lesewerkzeug ab (CR-2026-030, D-33) |
<FRAMEWORK_OWNER> |
| 0.4.0 | 2026-09-11 | Fünf Zusagen mehr, drei VERIFY-Marker aufgelöst – zwei davon zum Schlechteren. Neu: R5 und S5 (Aufzählbarkeit der Regelquellen und Skills, beobachtet, mit dem Vorbehalt aus ERH-02/ERH-03), R6 (Importsteuerung, CR-2026-038/D-37), M6 und M7 (die beiden Modi, die D-05 regelt und die Matrix nicht führte, CR-2026-028). Aufgelöst: R4 – für diesen Client ist kein Zeichenlimit dokumentiert, die Zahlen bleiben als Vorgabe des Frameworks (CR-2026-027); B9 – die Benutzerkonfiguration hebt eine projektseitige Verschärfung auf, gemessen in beide Richtungen (ERH-11); M2 – eine Modus-Sperre ist nicht dokumentiert, wirksam ist die Wirkungsbegrenzung der Organisationsebene. Neuer Abschnitt 7 mit den Anweisungs- und Konfigurationsquellen außerhalb des Projekts. Die Zeilenzahl der Zusammenfassung ist nachgezählt worden: Sie führte „von 26", während die Matrix 29 Zeilen trug |
<FRAMEWORK_OWNER> |
| 0.8.0 | 2026-09-13 | Neue Zeile H4 und eine Berichtigung, die neun Releases überfällig war (CR-2026-056, D-61 bis D-63, Befund B06). H4 trägt Eingabeschema, Pfadidentität und die Zeitlücke des Schutz-Hooks. Der Fehlblockade-Befund des Packs claude-code tritt hier nicht auf – die fünf Hook-Aufzeichnungen dieses Packs führen kein transcript_path und kein cwd; das ist eine Eigenschaft des Schemas, keine des Hooks. Abschnitt 5 behauptete seit 0.25.0 fail-open und einen Manifestwert false, während Zeile H2 derselben Tabelle das Gegenteil sagte |
<FRAMEWORK_OWNER> |
| 0.9.0 | 2026-09-13 | Das Startwerkzeug für Unteragenten ist als unerhoben deklariert, und der Belegstand war um eine Zeile zu klein (CR-2026-058, D-70). Das Manifest führt agent_start_tools_absent: ["unerhoben"] samt Begründung – die leere Liste ist eine Aussage über den Belegstand, nicht über den Client; dieses Pack führt Subagenten als Vorschaufunktion (QD-14), gemessen ist dort nichts. Prüfung 34 verlangt künftig Nennung oder Erklärung. Berichtigt: Der Belegstand nannte 8 offene VERIFY-Marker und zählte B10 nicht mit, obwohl es seinen Marker seit 0.33.0 trägt – es sind 9 |
<FRAMEWORK_OWNER> |
| 0.10.0 | 2026-09-13 | Die nicht abgebildeten Werkzeugverben des Frontmatters sind deklariert – und ein Widerspruch dieses Manifests ist festgehalten (CR-2026-062, D-78). Beide tool_names-Blöcke führen tool_names_unmapped mit allen fünf Verben des Vokabulars samt Begründung: Dieses Pack bildet die Frontmatter-Werkzeugnamen nicht ab, und wie der Client sie wirklich nennt, ist unerhoben – Zeile S3 sagt es seit 0.7.0 selbst. Bis 0.39.0 war die Abwesenheit nur eine leere Abbildung, und ein unbekanntes Verb wurde wörtlich als Werkzeugname durchgereicht. Festgehalten, nicht behoben: Dasselbe Manifest erklärt unter hook_tools_absent, dieser Client führe kein eigenes Suchwerkzeug – und jede installierte Skilldatei trägt grep und glob als Werkzeugnamen. Beides kann nicht stimmen; welche Seite falsch ist, entscheidet eine Erhebung |
<FRAMEWORK_OWNER> |
| 0.11.0 | 2026-09-14 | Der Werkzeugbestand dieses Clients ist erhoben, und der Widerspruch aus 0.10.0 ist entschieden (CR-2026-065, D-87 bis D-89). Falsch war hook_tools_absent: Der Client führt zwei Suchwerkzeuge, grep und find_file_by_name; der erzeugte Hook-Matcher kannte die Klasse deshalb nicht, und ein Secret kam über grep heraus, wo ein read blockiert wurde (Läufe H1/H2). Seit diesem Release führt hook_tools die Suchklasse, und derselbe Aufruf wird abgewiesen. Richtig war glob im Frontmatter: Dieser Client führt dort ein eigenes, normalisiertes Vokabular (read, grep, glob, edit, exec, web_search), das mit seinen Laufzeitnamen nicht übereinstimmt – ein erster Entwurf trug find_file_by_name ein, und der Client verwarf es lautlos. Die Abbildung ist deshalb die Identität, der Namensraum ist deklariert, und Prüfung 38 ist namensraumbewusst. Der Skillaufruf ist ein Werkzeugaufruf (skill), über die Berechtigungsdatei aber nicht adressierbar – K-33 geschlossen, K-34 neu |
<FRAMEWORK_OWNER> |
| 0.11.0 | 2026-09-16 | (Unter derselben Nummer wie die Zeile davor eingetragen – ein Versehen; die Nummer bleibt stehen, weil der Verlauf nicht umgeschrieben wird, D-397.) Die verbindliche Zielversion ist festgelegt, drei Marker der Pfadabbildung sind aufgelöst, und das Pack ist abgenommen (CR-2026-075, D-112 bis D-114). Der Steckbrief führt seit diesem Release zwei Versionsangaben statt einer: die verbindliche Zielspanne 3.9.x (Geltungsbereich) und den gemessenen Punktwert 3.9.19 (Messwert). Beides in einer Zelle zu führen, hat beim Schwesterpack die Festlegung neben dem Messwert verloren gehen lassen. Aufgelöst: Schemadetails der Berechtigungskonfiguration (der Client liest permissions.deny und führt den hooks-Block aus derselben Datei aus; ask und allow bleiben ungemessen), Struktur der MCP-Konfiguration (am Client erzeugt und verglichen) und DEVIN_PROJECT_DIR (im Hook-Prozess aufgezeichnet). Zwei der drei Belege lagen seit dem 2026-09-11 beziehungsweise 2026-09-14 in diesem Repositorium – ein offener Marker ist eine Aussage über den eigenen Belegstand, und auch die veraltet. Der Status geht von entwurf auf pilot; damit steht kein Modulträger des Frameworks mehr auf entwurf |
<FRAMEWORK_OWNER> |
| 0.12.0 | 2026-09-18 | Produktbeobachtung FW-AK-01 gegen den Stand 3.10.31 (CR-2026-087). Alle siebzehn Quellen und der Changelog seit 3.8.20 abgeglichen – der erste vollständige Abgleich dieses Teils; er stand seit 0.1.0 aus. Vier Befunde: Die verbindliche Zielspanne 3.9.x deckt das ausgelieferte Produkt nicht mehr und wird nicht stillschweigend mitgezogen (D-157). Drei der siebzehn Quellen belegen einen Agenten, den der Hersteller zum 2026-09-08 entfernt hat – R1 bekommt deshalb den tragfähigen Beleg QD-6 statt des Cascade-gebundenen QD-5 (D-159). M2 stützt sich auf die Unüberschreibbarkeit der Organisationsebene, und die galt in der Zielspanne dieses Packs nicht (CVE-2026-81376, behoben erst in 3.10.31) – dieselbe Bauform wie D-150, im Produkt. Sechs Skill-Suchpfade statt zwei, zwei davon ohne dokumentierten Schalter, dazu eine organisationsseitige Skillquelle außerhalb jeder Datei des Frameworks (K-64, K-65) |
<FRAMEWORK_OWNER> |
| 0.13.0 | 2026-09-22 | AP2 ist zu Ende gefahren – vier Marker aufgelöst, einer bleibt dauerhaft (CR-2026-120, D-277 bis D-289; 70 Sitzungsläufe, siebzehn Messbäume, 0,4718 USD). S3 zum Schlechteren: Die Frontmatter-Felder erreichen die installierte Datei und begrenzen den Werkzeuggebrauch nicht (neun Läufe, in sieben lief edit durch). B10 zum Schlechteren und auf [NICHT ABBILDBAR]: Das Abrufwerkzeug heißt webfetch, und die Berechtigungsdatei erreicht den Kanal in keiner Richtung (acht Läufe, sechs Bäume, drei Schreibweisen). A1 zum Besseren: Das allowed-tools eines Subagentenprofils bestimmt den Werkzeugbestand des Unteragenten. B3 mit benannter Grenze: **/ trifft null bis mehrere Ebenen, und die Muster unterscheiden Groß- und Kleinschreibung, während NTFS es nicht tut. Neu in der Vorbemerkung des B-Blocks: --permission-mode dangerous hebt den deny-Korb auf; der Schutz-Hook trägt dort weiter. Neu in der Pfadabbildung: die Enthaltung zu ask/allow, das Startwerkzeug run_subagent und die drei von zwölf Skills, die das Modell erreichen |
<FRAMEWORK_OWNER> |
| 0.14.0 | 2026-09-22 | Die Markerform ist abgeschafft; die Belegspalte trägt den Nachweisstand (CR-2026-121, D-291, D-292). Zeile X2 sagt BELEG OFFEN (dauerhaft) statt eines fristgebundenen Markers – die Frage bleibt offen (K-20), die Marke nicht; eine Frist auf eine Frage, die dauerhaft nicht beobachtbar ist, war nie einlösbar, und die Zeile hat sie achtundneunzig Releases lang getragen. Und der Belegstand dieses Packs war seit 0.86.0 falsch (D-297): Er sagte „5 der 36" und zählte B4, B5, B6 und B8 über den Verweis „wie B3" mit – B3 ist mit 0.86.0 aufgelöst, und ein Verweisbeleg erbt den Beleg seines Ziels (D-266). Richtig ist 1 von 36, und die Übersicht in clients/README.md sagte das seit 0.86.0: zwei Träger desselben Hauses, zwei Zahlen |
<FRAMEWORK_OWNER> |
| 0.14.4 | 2026-09-26 | Vorbemerkung des B-Blocks: die Startort-Bedingung, gemessen mit Clientversion 3000.11.1 – im Unterverzeichnis mit eigenem Repositorium laden weder Wurzel-Anweisung noch Berechtigungen und Hooks; eine eigene Installation dort trägt (D-408). 🔴 R2 und R6: Befund K-156 – mit read_config_from.windsurf: false lädt der Client die Regelablage .devin/rules/ nicht (CR-2026-148) |
<FRAMEWORK_OWNER> |
| 0.14.5 | 2026-09-26 | 🟢 K-156 beantwortet: windsurf steht auf true (D-411, CR-2026-149) – mit false lädt die Regelablage auch unter 3000.11.3 nicht. Der Preis, gemessen an Kennworten je Kanal: die Anweisungsdatei im Benutzerprofil und .windsurf/rules/ laden; install.py meldet belegte Kanäle. copilot, opencode, zed auf false. R2: always_on und model_decision gemessen, glob lädt nicht (K-161). Feste Last mit Regelablage 8.344 Token |
<FRAMEWORK_OWNER> |
| 0.14.6 | 2026-09-29 | Zeile B4 folgt dem Erzeugnis: Das Overlay sperrt seit 1.17.0 allein der Schutz-Hook (D-448). Zeile MCP-Konfiguration: die Stichprobe des Owners zu 1.18.0 – stdio über mcp-remote trägt, die Seitenversion kommt an. Zeile S3: die Werkzeugsperre eines Skills wirkt auch für exec (K-187). CR-2026-158, D-468 |
<FRAMEWORK_OWNER> |
| 0.14.8 | 2026-09-30 | Der eingebaute Skill upload-secrets ist eingestuft (CR-2026-164, D-503, K-94): Er lädt über die CLI, die die Werte selbst liest; der Schutz-Hook sperrt cloud drs secret-create, gemessen in zwei Läufen |
<FRAMEWORK_OWNER> |
| 0.14.7 | 2026-09-30 | Die Schreibweise der Muster ist entschieden (CR-2026-163, D-491, D-492, K-92, K-96). Zeile B3: Die Semantik des Schutz-Hooks gilt, die Grenze der Berechtigungsschicht bleibt benannt. Zeile H4: /c/… in beiden Lesarten |
<FRAMEWORK_OWNER> |
| 0.15.0 | 2026-10-02 | Sprachlich überarbeitet; Zusagen, Einstufungen und Belege unverändert | <FRAMEWORK_OWNER> |
| 0.15.1 | 2026-10-05 | Zeile R2: glob lädt aus einer Liste ohne Pfadpräfix; install.py schreibt die Muster so (D-545, K-161) |
<FRAMEWORK_OWNER> |
| 0.15.2 | 2026-10-06 | „Update“ statt „Hebung“ (CR-2026-175 E2); Zusagen, Einstufungen und Belege unverändert |
<FRAMEWORK_OWNER> |
| 0.16.0 | 2026-10-06 | MCP-Aufrufe erreichen den Schutz-Hook, und die Wirksamkeitsprobe startet den Client ohne Modell (CR-2026-175 E5, K-198, K-199). Gemessen mit der Agent-CLI 3000.11.3: MCP-Werkzeuge als mcp__<server>__<werkzeug> am PreToolUse, Matcher und Präfix im Manifest; Köderwert abgewiesen, harmlose Notiz durchgelassen. Mit einem Proxy auf einem geschlossenen Port läuft der Client bis zum SessionStart-Hook; install.py --probe belegt damit K1 ohne Modellaufruf |
<FRAMEWORK_OWNER> |