Crabox

Was macht Crabox?

• Gezielter Remote-Nachweis: Befolgen Sie die Proof Policy. Bevorzugen Sie begrenzte lokale Tests auf einem qualifizierten, verfügbaren Host. Teure oder plattformspezifische Arbeiten können Remote-Kapazitäten nutzen. Warteschlange: Stoppen Sie die eigene Zuordnung; verwenden Sie PR CI oder einen sicheren lokalen Bereich und melden Sie nicht abgedeckte Anforderungen. Erforderlicher Build vor Veröffentlichung nicht verfügbar: Verwenden Sie die Entwurfs-/CI-Proof-Policy der Testfähigkeit.
• Warten Sie niemals auf Warteschlangen oder verketten Sie Anbieter-Fallbacks.

Backends:

• blacksmith-testbox: vertrauenswürdige Maintainer-Quelle. Vorbereitetes CI. tbx_....
• aws: direkte vermittelte Crabbox. Frische PRs. Benutzerdefiniertes Sync/Env/Capture. cbx_....
• local-container: Docker-Fallback. Kein Remote-Nachweis.
• ssh: Vorhandener Operator-Host. macOS/Windows/WSL2.

Melden Sie immer Anbieter, ID, Run-URL, Befehl, Ergebnis. Nennen Sie Testbox niemals "AWS Crabbox."

Repository-Vertrag

• Lösen Sie Beispielbefehle, Bootstrap, Container-Image, PR gemäß den Anweisungen des vertrauenswürdigen Nutzers auf. Erfinden Sie niemals Befehle oder kopieren Sie die Einrichtung eines anderen Nutzers.
• Nutzerspezifische Einrichtung bleibt außerhalb der portablen Fähigkeit. Siehe Platzhalter-Definitionen.

Autorisierung und Isolation

• Aufgabenerforderliche Erstellung, Wiederverwendung, Bereinigung, temporärer Zustand, saubere Checkouts: vorab genehmigt. Vorhandene Branches, Checkouts, nicht zusammenhängende Änderungen beibehalten.
• Quellvertrauen, Anmeldeinformationen, Produktionszugriff, Budget, Veröffentlichung bleiben Autoritätsgrenzen. Isolierter Zustand; niemals das Operator-Gateway ohne aufgabenbezogene Genehmigung berühren.

Zuerst Routen

• Behalten Sie den aufgelösten Anbieter bei: Testbox für vertrauenswürdige Quelle; direktes AWS, wenn dessen Semantik erforderlich ist; geheimnisloses CI/AWS für nicht vertrauenswürdigen Code. Führen Sie niemals nicht vertrauenswürdige Wrapper/Konfiguration lokal aus oder hydrieren Sie einen nicht vertrauenswürdigen Lease.
• Beschaffen Sie, wenn der Befehl bereit ist; verwenden Sie die eigene ID wieder; stoppen Sie danach.
• Kleinstes nachgewiesenes Profil. Größer: aufgezeichneter Speichernachweis oder gemessener Gesamtkostenvorteil erforderlich, nicht generischer Fehler/Verzögerung/Timeout. Erhöhen Sie keine Worker-Anzahlen zum Ausgleich.
• Testbox-Größenanpassung: --blacksmith-workflow, niemals direkt --class/--type; Profiländerungen erfordern frische Leases.
• Blacksmith-Runner-Labels fordern eine Stufe an, garantieren jedoch keine CPU oder RAM. Blacksmith kann abhängig von der Serviceverfügbarkeit kleinere Maschinen zuweisen. Für ressourcenempfindliche Tests oder Benchmarks messen Sie verfügbare CPUs, Affinitäten/Kontingente und nutzbaren RAM auf der zugewiesenen Maschine. Dimensionieren Sie Worker und Workloads basierend auf diesen Messungen. Zeichnen Sie die angeforderte Stufe und die beobachteten Ressourcen separat auf. Qualifizieren Sie Hardware oder Leistung nicht allein anhand von Labels.
• Größe, Dauer, Hydrierungsfehler, Kapazität autorisieren niemals Anbieterüberschreibungen; explizite Benutzerauswahl oder erforderliche Backend-Semantik tun dies.

Preflight

Vertrauenswürdiges Repository-Root: Lesen Sie .crabbox.yaml, lösen Sie installierte Binärdatei auf, überprüfen Sie Anbieter/Befehle:

export CRABBOX="$(command -v crabbox)"
test -n "$CRABBOX"
"$CRABBOX" --version
"$CRABBOX" config show --json | jq '{provider, profile, target}'
"$CRABBOX" run --help

• Verwenden Sie die vertrauenswürdigen Wrapper/Installationsanweisungen des Nutzers.
• Der Nachweis des nativen Linux/WSL-Befehlslebenszyklus und der -unterbrechung erfordert eine vollständige passende Crabbox-Distribution oder ein verifiziertes Laufzeitmanifest, das mit CRABBOX_RUNTIME_ARTIFACTS ausgewählt wurde. Passen Sie die Begleiter an die eingefrorene Quelle an und verifizieren Sie, dass das Manifest den exakt ausgewählten Controller bindet. Eine Entwicklungs-CLI ohne Laufzeitpaket verwendet legacy SSH-Überwachung; --version allein begründet keine native Überwachung. Verifizieren Sie das ausgewählte Paket vor der Zuordnung; zählen Sie CLI-only-Nachweis nicht als nativen Lebenszyklus-Nachweis. Befolgen Sie die Upstream- Laufzeitartikel-Anweisungen.
• Reparaturen: Überprüfen Sie Upstream; verwenden Sie sauberen, aufgabeneigenen Checkout; bewahren Sie installierte Binärdatei + nicht zusammenhängende Quelle auf. Vertrauen Sie niemals einem Geschwister-Checkout nur aufgrund des Namens.

Lease-Lebensdauer

• TTL zählt ab Erstellung, einschließlich Hydrierung; Leerlauf-Timeout zählt Inaktivität. Früheres Ablaufdatum gewinnt. Standardwerte: 30m pro Stück, maximal 4h. Besitzer-/Organisationsüberschreibungen können bis zu 24h erlauben; verwenden Sie effektive Richtlinie und bereinigte Klemmhinweise, nicht angeforderte Dauern. Richtlinienverschärfung gilt auch für laufende Leases.
• --keep und stop: never verhindern kein Ablaufen. Fordern Sie explizite begrenzte TTL und Leerlauf für beibehaltene direkte Leases an. Einfacher Heartbeat, Setup, Sync, SSH und Desktop-Nutzung verlängern die Gesamt-TTL nicht; run fordert begrenzte automatische Verlängerung nur während der Ausführung eines Befehls, innerhalb der Richtlinie, des Budgets und der Anbieterfähigkeit.
• Überprüfen Sie vor langer quellabhängiger Arbeit die verbleibende Gesamtlebensdauer. Wenn erlaubt, fordern Sie eine begrenzte extend <id> --ttl <gewünschte-gesamt> --json an; Verlängerung setzt Leerlauf nicht zurück. Abgelehnte/Budget/nicht unterstützte/nicht fortschreitende/inaktive Ergebnisse erfordern eine sichtbare Überspringung oder einen Fehler, niemals Anbieterwechsel oder unendliche Leases-Ketten. Erstellungsfeste Anbieter wie Daytona benötigen ausreichend TTL bei der Zuordnung.
• Ein direkter Guest-Refresh-Fehler kann eine längere Anbieterfrist mit der alten lokalen Frist hinterlassen. Behalten Sie denselben lokalen Zustand bei und wiederholen Sie dieselbe feste Gesamt-TTL nur zur Abgleichung; behandeln Sie die fehlgeschlagene Verlängerung nicht als Schutz.
• Beachten Sie vertrauenswürdiges directLeases: deny und directLeaseAllow. Ein verweigerter Anbieter erfordert die konfigurierte Koordinator-Route; umgehen Sie es niemals mit direkten Anmeldeinformationen. Testbox behält seine nativen Job- und Leerlaufgrenzen bei; --ttl verlängert keinen delegierten Workflow.
• list zeigt laufende Koordinator-Leases; list --retained fügt beibehaltene terminale Ressourcen hinzu, deren Bereinigung unbestätigt ist. Verwenden Sie exakte ID-Überprüfung/Stopp für die Wiederherstellung. Behalten Sie Beanspruchungen und Wiederherstellungszustand bei, bis ein blockierender Stopp den Abschluss bestätigt.

Vertrauenswürdige Testbox

Aufgelöster Anbieter = Testbox (oder explizit angefordert): Befehle bewahren es. Fügen Sie --provider blacksmith-testbox nur für explizite Überschreibung hinzu:

"$CRABBOX" run --timing-json -- CI=1 <check-command>

Mehrere Befehle: einmal aufwärmen, ID speichern, wiederverwenden, stoppen.

"$CRABBOX" warmup --keep --timing-json
"$CRABBOX" run --id <tbx_id> --timing-json -- <check-command>
"$CRABBOX" stop <tbx_id>

Regeln:

• Ein Lease, ein aktiver Befehl. Kein Sync/Reclaim während des Laufs.
• Bevorzugen Sie bash -c; Login-Profile können Verzeichnisse ändern. In der ausführenden Shell stellen Sie physischen Checkout + erwartete Quelle/Patch sicher; HEAD allein ≠ Dirty-Sync-Nachweis. Befolgen Sie den dokumentierten Hydrierungs-Shell-Vertrag des Nutzers.
• Native Testbox führt eigenen Sync durch, einschließlich wiederverwendeter --id-Läufe. Verlassen Sie sich niemals auf --no-sync für Remote-Baseline: Blacksmith hat keinen nativen Bypass; freigegebene Crabbox-Versionen können das Flag stillschweigend ignorieren. Unveränderter absichtlicher Neulauf ≠ Ausnahme.
• --reclaim nur für bewusste Checkout-Pfad-Besitzübertragung.
• Befolgen Sie den Zuordnungsbeleg des Nutzers für die Wiederverwendung. Kompatible Source-Commits können einen Lease wiederverwenden, wenn Aufgabe, physischer Checkout, Basis, Abhängigkeiten, Vorbereitung und Workflow/Job/Ref unverändert bleiben. Behalten Sie die ursprüngliche Zuordnungsherkunft. Inkompatibler Beleg: Stopp; erneut aufwärmen. Keine stale-Lease-Überschreibung.
• Roher SHA unzuverlässig für warmup --ref; verwenden Sie Branch/Tag.
• blacksmith testbox list verbirgt Zustände. Verwenden Sie list --all oder status --id <tbx_id>.
• Testbox-Status/Stopp: --id. Kein Status --json.
• Delegierter Anbieter lehnt --fresh-pr, --full-resync, --script*, --env-helper, Capture/Download-Flags ab.

Blacksmith-Verzeichnis-Downloads

Rekursive Downloads + erforderlicher Remote-Trailing-Slash: Verzeichnis-Downloads.

Nicht vertrauenswürdiges AWS

• Sauberer, vertrauenswürdiger default-Branch-Checkout. Installierte vertrauenswürdige Crabbox-Binärdatei.
• Frischer Lease pro überprüfter vollständiger Head-SHA. Keine Instanzrolle, Tailscale, Hydrierung.
• Weiterleiten nur CI. Vertrauenswürdigen Bootstrap neben --fresh-pr hochladen.

cd <sauberer-vertrauenswürdiger-default-branch-checkout>
env -u CRABBOX_AWS_INSTANCE_PROFILE \
  "$CRABBOX" config show --json | \
  jq -e '.aws.instanceProfile == ""' >/dev/null

env -u CRABBOX_AWS_INSTANCE_PROFILE \
  -u CRABBOX_TAILSCALE \
  -u CRABBOX_TAILSCALE_AUTH_KEY \
  -u CRABBOX_TAILSCALE_AUTH_KEY_ENV \
  -u CRABBOX_TAILSCALE_EXIT_NODE \
  -u CRABBOX_TAILSCALE_EXIT_NODE_ALLOW_LAN_ACCESS \
  -u CRABBOX_TAILSCALE_HOSTNAME_TEMPLATE \
  -u CRABBOX_TAILSCALE_TAGS \
  "$CRABBOX" warmup \
  --provider aws --network public --tailscale=false \
  --tailscale-exit-node= \
  --tailscale-exit-node-allow-lan-access=false \
  --ttl 4h --idle-timeout 90m --keep --timing-json

"$CRABBOX" inspect --provider aws --id <cbx_id> --json | \
  jq -e '.network == "public" and .tailscale == null' >/dev/null

env -u CRABBOX_AWS_INSTANCE_PROFILE \
  CRABBOX_ENV_ALLOW=CI \
  "$CRABBOX" run \
  --provider aws --id <cbx_id> \
  --fresh-pr <besitzer/repo#nummer> \
  --no-hydrate --timing-json \
  --script <vertrauenswürdiges-bootstrap-script> -- \
  <erwartete_vollständige_head_sha> <check-command>

env -u CRABBOX_AWS_INSTANCE_PROFILE \
  "$CRABBOX" stop --provider aws <cbx_id>

• Vertrauenswürdiger Bootstrap muss nachweisen, dass IMDSv2-IAM-Anmeldeinformationen 404 zurückgeben; SHA überprüfen; Laufzeitinjektionsvariablen entfernen; Toolchain festlegen; HOME vor Installation/Test isolieren.
• Geänderter Head: frischer Lease. Fehlende Remote-PR oder kein-Rolle-Nachweis: geheimnisloses Fork-CI.

Direktes AWS

• Vertrauenswürdige AWS-Befehle, Auth-Diagnose, Resync, saubere PR/Container-Läufe: Lesen Sie direkte Anbieter.
• --no-hydrate bei Container-Läufen beibehalten; lokalen Container-Nachweis als lokal melden.

Beobachtbarkeit

• Artefakte sammeln/Anmeldeinformationen injizieren: Lesen Sie Capture- und Umgebungsflags.
• Exakter Schlüssel, ein Befehl. Niemals Geheimnisse drucken, im Repository schreiben oder in die Shell-Historie setzen.
• Kein sicherer Injektionspfad: Live-Auth blockiert; Fake-Key-Nachweis unzureichend.

Echtes E2E

• Angeforderten Benutzereinstiegspunkt mit isoliertem Nutzerzustand ausführen, nicht nur Remote-Komponententests.
• Für Install-/Provider-/Interaktionsnachweis + sicheren Revisionsvergleich: Lesen Sie E2E-Verfahren.

Desktop / Plattformübergreifend

SSH-Ziele, bezahltes macOS-Preflight, WebVNC, App-Übergabeverifikation: Lesen Sie Desktop- und plattformübergreifende Befehle.

Fehlertriage

Identifizieren Sie Wrapper-, Anbieter-, Hydrierungs-, Sync-, SSH- oder Befehlsfehler:

"$CRABBOX" doctor
"$CRABBOX" status --id <id>
"$CRABOX" inspect --id <id> --json
"$CRABOX" logs <run_id>
"$CRABOX" results <run_id>
blacksmith testbox list --all
blacksmith testbox status --id <tbx_id>

• Warteschlangenkapazität: Stoppen Sie eigene Zuordnungen; befolgen Sie die Proof Policy. Kein Wiederholungssturm oder Anbieterwechsel.
• Stale-Sync: --debug --timing-json, dann --full-resync einmalig bei direkten Anbietern.
• Fehlerhafte Phase/JUnit vor gezieltem Neulauf lesen. Defekter Wrapper: Diagnose mit installierter CLI auf demselben Anbieter; Update über den vertrauenswürdigen Pfad des Nutzers.
• Nur eigene IDs stoppen; stop nimmt kein --timing-json.