marfrit
dd13f0fe3f
Das Architekturmanifest nennt den Erbauer als offenes Tor 1 und
roster.yaml als "die Quelle, aus der sowohl die Container als auch das
Dispatcher-Roster entstehen. Eine Liste, zwei Verbraucher." Bisher gab
es sie nicht; die neun Container sind von Hand angelegt.
Diese Fassung ist AUFGENOMMEN, nicht entworfen: jede Zahl kommt aus dem
laufenden Aufbau. Drei Abweichungen sind dabei sichtbar geworden und
stehen jetzt als `abweichung:` in der Datei statt in niemandes Kopf:
* foreman, architect, reviewer haben boot.autostart=false — sie kaemen
nach einem Wirtsneustart nicht wieder.
* reviewer hat ausserdem KEINE einzige aktivierte Unit: ein Container
mit angemeldetem Claude Code und nichts verdrahtet.
Ebenfalls festgehalten, weil man es sonst wieder herausmessen muss: neun
Kinder sind heute die Decke (ein zehnter scheitert am Start mit
"newuidmap failed to write mapping", trotz idmap.size=1e9); die Summe
der Kinder-Deckel uebersteigt den Eltern um Faktor 2,62; die
Erlaubnisliste des Raums; dass grinds Ausgang GEFILTERT und nicht dicht
ist (eine Nullsperre baut einen toten Container, die Grinder-Schleife
braucht Proxy und Raum); und dass deus bewusst keine Zugangsdaten haelt.
secrets.example enthaelt keine Werte, sondern beschreibt, was existieren
muss und woher es kommt. Der Erbauer soll ABBRECHEN, wenn etwas fehlt,
statt sich Geheimnisse auszudenken — ein Aufbau, der das tut, ist beim
naechsten Lauf ein anderer Aufbau.
Der Erbauer selbst (deploy/bullpen-up, das die neun daraus erzeugt und
die Container AUS DEM PAKET aufsetzt) fehlt weiterhin. Das ist der
naechste Schritt; ohne die Quelle waere er nicht schreibbar gewesen.
61 lines
3.3 KiB
Plaintext
61 lines
3.3 KiB
Plaintext
# secrets.example — WELCHE Geheimnisse der Erbauer braucht und WOHER sie kommen.
|
|
#
|
|
# Diese Datei enthaelt NIE Werte. Sie beschreibt nur, was existieren muss und
|
|
# an welcher Stelle. Der Erbauer ERZEUGT nichts aus dem Nichts und BRICHT AB,
|
|
# wenn etwas fehlt — ein Aufbau, der sich seine Geheimnisse selbst ausdenkt,
|
|
# ist beim naechsten Lauf ein anderer Aufbau.
|
|
#
|
|
# ---------------------------------------------------------------------------
|
|
# 1. Post-Geheimnisse je Nick
|
|
# ---------------------------------------------------------------------------
|
|
# Ort: <container>:/etc/bullpen/post-secret.d/<nick> (0600, root)
|
|
# Inhalt: eine Zeile, zufaellig, ohne Zeilenumbruch am Ende
|
|
# Erzeugen (EINMAL, im room):
|
|
# head -c 48 /dev/urandom | base64 | tr -d '\n' > /etc/bullpen/post-secret.d/<nick>
|
|
#
|
|
# Wer welche haelt, steht in roster.yaml unter `nicks:`. Der `room` haelt ALLE,
|
|
# weil er prueft; jeder andere Container nur die Nicks, die er beherbergt.
|
|
#
|
|
# Ein Nick ist privilegiert GENAU DANN, wenn seine Datei existiert — es gibt
|
|
# keine zweite Liste. Wer ein Mitglied hinzufuegt, legt seine Datei an, sonst
|
|
# bleibt es stumm: der Raum nimmt seine Beitraege an, stempelt sie aber nie,
|
|
# und jeder Lurker verwirft sie (R4). Das sieht wie Schweigen aus, nicht wie
|
|
# ein Fehler.
|
|
#
|
|
# ---------------------------------------------------------------------------
|
|
# 2. Raum-Token (lmcp)
|
|
# ---------------------------------------------------------------------------
|
|
# Ort: <container>:/etc/bullpen-room.env (0600, root)
|
|
# Inhalt: LMCP_HOST=<ip des room-containers>
|
|
# LMCP_PORT=8080
|
|
# LMCP_TOKEN=<der Token des room-lmcp>
|
|
#
|
|
# Quelle des Tokens: der `room`-Container selbst (LMCP_TOKEN in seiner
|
|
# lmcp.service-Umgebung bzw. der Datei hinter LMCP_CONF).
|
|
#
|
|
# ⚠ Dieser Token gibt Zugriff auf die Werkzeuge des Raums. Welche das sind,
|
|
# entscheidet `LMCP_TOOL_ALLOW` (siehe roster.yaml). OHNE diese Liste bringt
|
|
# lmcp seinen vollen Grundstock mit — shell, write_file, edit_file —, und
|
|
# dann hat jeder Token-Halter eine Wurzelschale im room-Container. Gemessen
|
|
# am 2026-08-08, bevor die Liste existierte.
|
|
#
|
|
# ---------------------------------------------------------------------------
|
|
# 3. Motor-Anmeldungen
|
|
# ---------------------------------------------------------------------------
|
|
# claude (architect, reviewer): Claude-Code-Abo-Anmeldung im Container.
|
|
# KEIN API-Token (Direktive c). Wird interaktiv eingespielt und ist
|
|
# NICHT automatisierbar — der Erbauer prueft nur, ob sie vorhanden ist,
|
|
# und meldet den Container sonst als "wartet auf Anmeldung".
|
|
# opencode (foreman, testdesigner): Anbieter-Konfiguration ueber den
|
|
# hossenfelder-Proxy; kein Anthropic-Token.
|
|
# pi (deus): ~/.pi/agent/models.json, erzeugt aus dem Gateway-Katalog
|
|
# via `bin/models-json <host> --apply`. Erzeugt NICHTS von Hand.
|
|
#
|
|
# ---------------------------------------------------------------------------
|
|
# 4. Was der Erbauer NICHT anfasst
|
|
# ---------------------------------------------------------------------------
|
|
# * Gitea-Schluessel. Kein Agentcontainer bekommt einen. Ergebnisse verlassen
|
|
# den Aufbau per `git bundle`; wohin sie gehen, entscheidet ein Mensch.
|
|
# * Das Home-CA-Zertifikat fuer bullseye/deus: liegt auf hertz, wird
|
|
# hineingereicht, nicht neu erzeugt.
|