Von der IDE zum Nachtjob – Agentic Engineering in Produktion

Datum: 2026-06-15

Wer nur tippt, hat einen Assistenten

Tagsüber in Cursor arbeiten ist effektiv – aber Qualität um 3 Uhr nachts entsteht nicht aus Motivation. Sie entsteht aus Jobs: feste Zeiten, feste Befehle, Logs, Exit-Codes. Alles, was du tagsüber per Hand in der IDE startest, gehört langfristig in die Shell.

Der Unterschied ist nicht philosophisch, sondern operativ:

Dieser Beitrag zeigt konkret, wie wir das bauen – mit echten Scripts, Orchestrator-Steps, Env-Flags und Kommentaren, die im Repo stehen und nicht im Kopf verloren gehen.

Das Problem

Wer Agentic Engineering ernst meint, braucht Produktion – nicht nur Werkstatt. Die Fabrik beginnt dort, wo ein Befehl ohne Mensch startet und ohne Diskussion endet.

Das Pattern – drei Schichten

Alles Reproduzierbare folgt derselben Schichtung:

Cron / CI / manuell
    ↓
start-vendor-*.php  (dünner Entry-Point)
    ↓
CLIOrchestrator     (Steps 001…00N, Briefing-First)
    ↓
Step-Services       (Logs, Validierung, Agent-Aufruf)
    ↓
cursor agent        (headless, Subagent aus cursor-rules/agents/)
    ↓
Ralph-Marker        (OPEN_FAILURES=0, CHANGED_FILES=0 → Konvergenz)

Andere CLIs (Claude Code, Aider, OpenCode) folgen demselben Prinzip: stdin/stdout, Exit-Code, Logfile. Der Agent-Stack ist austauschbar – die Shell-Vertragsschicht bleibt.

Entry-Point: `start-vendor-development-workflow.php`

Jedes Vendor-CLI-Script ist ein dünner Entry-Point. Keine Business-Logik im Script – nur Bootstrap, Parameter-Validierung, Orchestrator-Aufruf, Zusammenfassung, Exit-Code.

Auszug aus dem Vendor-Script (Struktur 1:1 in jedem `start-vendor-*.php`):

#!/usr/bin/env php
<?php

declare(strict_types=1);

use fabian\CLIOrchestrator\CLIDevelopmentWorkflow\CLIDevelopmentWorkflowOrchestrator;
use fabian\CLIServices\Cli\CliScriptTerminalBootstrapService;
use fabian\Services\Cli\VendorConsoleOutputHelper;
use fabian\Services\Cli\VendorTerminalEntireLineRedErrorOutputService;

/**
 * Development Workflow Start-Script
 *
 * Briefing-First: Änderungen zuerst in briefing/CLIOrchestrator/CLIDevelopmentWorkflow/,
 * danach Quellcode. VERBOTEN im Host: Root-Kopie dieses Scripts (@skill-vendor-cli-host-cleanup).
 *
 * Workflow-Steps (Master: CLIDevelopmentWorkflowOrchestrator.md):
 *   Step 001: Log-Verzeichnis leeren — CLIDevelopmentWorkflow001LogFileClearService
 *   Step 002: Fachlichen Development-Workflow — CLIDevelopmentWorkflow002ExecuteDevelopmentWorkflowService
 */

// 001. Projekt-Root portabel: Consumer-Host wenn Script unter vendor/.../base-ui-testcase liegt.
$scriptDir = dirname(__FILE__);
$vendorPackageDirSuffix = '/vendor/fabianrossbacher/base-ui-testcase';
if (str_ends_with($scriptDir, $vendorPackageDirSuffix)) {
    $projectRoot = dirname($scriptDir, 3);  // Host-Root, nicht Paket-Root
} else {
    $projectRoot = $scriptDir;
}
$_SERVER['DOCUMENT_ROOT'] = $projectRoot . '/htdocs';
chdir($projectRoot);
require_once $projectRoot . '/vendor/autoload.php';

// 002. Help ohne Orchestrator (kein Terminal-Clear, kein Agent-Lauf).
if ($argc >= 2 && in_array(strtolower((string) $argv[1]), ['help', '-h', '--help'], true)) {
    // … Nutzungshinweis …
    exit(0);
}

// 003. Terminal-Clear + Start-Header — Pflicht vor jedem Orchestrator-Lauf.
(new CliScriptTerminalBootstrapService())->executeClearTerminalAndEmitStartHeader(
    'start-vendor-development-workflow.php',
    $argc,
    $argv
);

set_time_limit(0);  // Agent-Läufe dürfen Stunden dauern — Cron bricht sonst ab.

// 004. Orchestrator — die eigentliche Arbeit liegt in Step-Services, nicht hier.
$orchestratorService = new CLIDevelopmentWorkflowOrchestrator();
$result = $orchestratorService->execute(null);

// 005. Zusammenfassung + Exit-Code aus Statistiken — maschinenlesbar für CI.
$workflowSuccessful = $result->getErrorCount() === 0
    && ($result->getSuccessCount() + $result->getSkippedCount() + $result->getErrorCount()) === $result->getTotalCount()
    && $result->getTotalCount() > 0;

VendorConsoleOutputHelper::closeLogging();
exit($workflowSuccessful ? 0 : 1);

Warum das für Cron/CI wichtig ist: Der Entry-Point garantiert `exit 0` nur bei objektiv grünem Workflow. Cron wertet genau das aus – nicht die Farbe im Terminal.

Ralph-Loop: `start-vendor-subagent-ralph-loop.php`

Subagents laufen nicht einmal – sie laufen bis Konvergenz. Der Ralph-Loop parst Env-Flags für verschachtelte Aufrufe (z. B. Screen-Check ruft Ralph-Loop pro Screen auf):

// Env-Flags: verschachtelter Ralph-Loop → kein Terminal-Clear (sonst flackert Cron-Log).
$cliEnvironment = new SubagentRalphLoopCliEnvironmentModel();
$cliEnvironment->setIsNestedRalphLoopInvocation(
    getenv('CHECK_SCREEN_SUPPRESS_RALPH_LOOP_CLEAR') === '1'
    || getenv('CHECK_CLI_SUPPRESS_RALPH_LOOP_CLEAR') === '1'
    || getenv('DEEP_CHECK_SUPPRESS_RALPH_LOOP_CLEAR') === '1'
    || getenv('FEATURE_SUPPRESS_RALPH_LOOP_CLEAR') === '1'
);

// Fortschrittsanzeige für verschachtelte Loops (z. B. Screen 3 von 12).
$checkScreenTotal = getenv('CHECK_SCREEN_TOTAL');
$cliEnvironment->setCheckScreenTotal($checkScreenTotal !== false ? $checkScreenTotal : null);
$checkScreenIndex = getenv('CHECK_SCREEN_INDEX');
$cliEnvironment->setCheckScreenIndex($checkScreenIndex !== false ? $checkScreenIndex : null);

$runTerminalClear = !$cliEnvironment->getIsNestedRalphLoopInvocation();
(new CliScriptTerminalBootstrapService())->executeClearTerminalAndEmitStartHeader(
    'start-vendor-subagent-ralph-loop.php',
    $argc,
    $argv,
    $runTerminalClear  // false bei Nested → Cron-Log bleibt lesbar
);

// Orchestrator übernimmt Parse, Log-Ordner, Agent-Runden, Marker-Auswertung.
$argvArguments = SubagentRalphLoopArgvArgumentsModel::buildFromRawArgvSource();
exit((new CLISubagentRalphLoopOrchestrator())->execute($projectRoot, $argc, $argvArguments, $cliEnvironment));

Maschinenlesbare Konvergenz (Rule `018-subagent-ralph-loop-output.mdc`)

Jede Ralph-Runde endet mit drei Pflicht-Markern – kein „sieht gut aus“:

RALPH_LOOP_OPEN_FAILURES=0
RALPH_LOOP_CHANGED_FILES=0
RALPH_LOOP_CHANGED_FILE_LIST=none

Cron und CI parsen nicht den Fließtext – sie parsen Exit-Codes. Die Marker sind die Brücke zwischen Agent-Sprache und Shell-Semantik.

Mehrphasen-Kette: `workflow-start.sh`

Für den vollen Nachtlauf kettet unser Host-Script die Vendor-CLIs in fester Reihenfolge – mit `set -euo pipefail` und expliziter Exit-Code-Weitergabe:

#!/usr/bin/env bash
#
# Mehrphasen-Workflow: Development → CLI-Check → Screen-Check → Deep-Check → PHPUnit.
# Skript-Auflösung: Host-Root, dann vendor/fabianrossbacher/base-ui-testcase/.
# Doku: @skill-workflow-prompts

set -euo pipefail

# Zweck: Script-Pfad im Host oder Vendor finden — Consumer-Host darf keine Host-Kopie pflegen.
workflow_start_resolve_script_path() {
  local root="$1"
  local script_name="$2"
  local host_path="${root}/${script_name}"
  local vendor_path="${root}/vendor/fabianrossbacher/base-ui-testcase/${script_name}"

  if [[ -f "${host_path}" ]]; then
    echo "${host_path}"
    return 0
  fi
  if [[ -f "${vendor_path}" ]]; then
    echo "${vendor_path}"
    return 0
  fi
  return 1
}

# Zweck: Development-Workflow; bei Exit ≠ 0 sofort abbrechen (kein halber Nachtlauf).
workflow_start_step_002_run_development() {
  local dev_ec=0
  local root resolved_path

  root="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
  resolved_path="$(workflow_start_resolve_script_path "${root}" "start-vendor-development-workflow.php")" || {
    echo -e "\033[0;31mFEHLER:\033[0m start-vendor-development-workflow.php nicht gefunden." >&2
    exit 1
  }

  php "${resolved_path}" || dev_ec=$?
  if [[ "${dev_ec}" -ne 0 ]]; then
    echo -e "\033[0;31mFEHLER:\033[0m Development-Workflow Exit-Code ${dev_ec}." >&2
    exit "${dev_ec}"  # Cron sieht 1 — kein stilles Weiterlaufen
  fi
}

# Reihenfolge: Dev → CLI-Check (Ralph) → Screen-Check (Ralph) → Deep-Check (Ralph) → PHPUnit.
main() {
  workflow_start_step_002_run_development
  workflow_start_step_003_run_check_cli
  workflow_start_step_004_run_check_screen
  workflow_start_step_005_run_deep_check
  workflow_start_step_006_run_phpunit "$@"
}

Nerdy Detail: `exec php …` im letzten Step ersetzt den Shell-Prozess – PHPUnit-Exit-Code landet direkt beim Cron-Parent, ohne Wrapper-Verlust.

Git-Push als automatisierter Job: `start-vendor-git-push.php`

Auch Push ist ein Job – mit Agent-generierter Commit-Message und hartem Abort bei Verify-Fehler:

// 003. Terminal-Bootstrap: nach update-rules-Kette kein Clear (Marker-Datei).
$runTerminalClear = true;
$chainSuppressMarkerPath = $projectRoot . '/.git/cli-chain-suppress-terminal-clear-after-update-rules';
if (is_file($chainSuppressMarkerPath)) {
    $runTerminalClear = false;
    unlink($chainSuppressMarkerPath);  // Einmalig — nächster Lauf cleared wieder
}

(new CliScriptTerminalBootstrapService())->executeClearTerminalAndEmitStartHeader(
    'start-vendor-git-push.php',
    $argc,
    $argv,
    $runTerminalClear
);

set_time_limit(0);  // Cursor Agent für Commit-Message kann Minuten brauchen

// Modus full: fetch, merge, submodule add, Agent-Message, commit, push, verify.
$result = $orchestrator->execute($projectRoot, 'full', '');

if ($result->getIsAborted()) {
    VendorTerminalEntireLineRedErrorOutputService::emitEntireLineRed($result->getAbortMessage());
    VendorConsoleOutputHelper::closeLogging();
    exit(1);  // Cron/CI: rot — kein halber Push
}

VendorConsoleOutputHelper::success('start-vendor-git-push: fertig', null, null, null, '000Summary');
VendorConsoleOutputHelper::closeLogging();
exit(0);

Die Wrapper-Kette `git-push.sh` kopiert Vendor-Scripts bei Bedarf, setzt `chmod 755` und führt linear aus:

#!/usr/bin/env bash
set -euo pipefail

# Consumer-Host: Vendor-Scripts synchronisieren, dann linear — kein Retry-Chaos.
cp "$VENDOR_ROOT/start-vendor-git-push.php" .
cp "$VENDOR_ROOT/start-vendor-update-rules.php" .
chmod 755 start-vendor-git-push.php start-vendor-update-rules.php

./start-vendor-update-rules.php   # Rules/Skills/Subagents → cursor-rules Commit
./start-vendor-git-push.php       # Root Commit + Push via Cursor Agent

Logs und Watchdog

Logs unter `logs-*` – ein Ordner pro Script-Lauf:

Env-Flags für verschachtelte Ralph-Loops (Auszug):

Die Fabrik läuft, auch wenn die IDE zu ist. Morgens liest das Team Logs – rot oder grün, nicht „hoffentlich“.

Typische Nacht-Jobs

Rotation statt Monster-Job: Lieber täglich ein Batch als wöchentlich „alles auf einmal“ mit Timeout.

Cron – produktionsreif

Konzeptioneller Crontab-Eintrag mit Exit-Code-Auswertung und Log-Rotation:

# /etc/cron.d/seoprogrammierer-quality
# User: deploy | TZ: Europe/Berlin
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

# 002:00 — Development-Workflow (Vendor-Pfad, kein Host-Duplikat)
0 2 * * * deploy cd /var/www/seoprogrammierer && \
  php vendor/fabianrossbacher/base-ui-testcase/start-vendor-development-workflow.php \
  >> logs/cron/development-workflow-$(date +\%Y-\%m-\%d).log 2>&1 \
  || echo "[$(date -Iseconds)] FAILED development-workflow exit=$?" >> logs/cron/alerts.log

# 003:30 — Ralph-Loop Vendor-Duplikate (nach composer update am Vortag)
30 3 * * * deploy cd /var/www/seoprogrammierer && \
  php vendor/fabianrossbacher/base-ui-testcase/start-vendor-subagent-ralph-loop.php \
  subagent-check-vendor-duplicates \
  >> logs/cron/vendor-duplicates-$(date +\%Y-\%m-\%d).log 2>&1

# 005:00 — Vollkette nur Sonntag (langer Lauf)
0 5 * * 0 deploy cd /var/www/seoprogrammierer && \
  ./workflow-start.sh >> logs/cron/workflow-full-$(date +\%Y-\%m-\%d).log 2>&1

Pflicht: `|| echo … >> alerts.log` – Cron meldet sonsten stillen Erfolg, auch wenn PHP mit `exit 1` endet.

CI/CD-Anbindung (GitHub Actions)

Dieselbe CLI wie lokal – nur in YAML verpackt:

# .github/workflows/agent-quality.yml (konzeptionell)
name: Agent Quality

on:
  schedule:
    - cron: '0 3 * * *'   # Nightly — gleicher Job wie Cron auf dem Server
  workflow_dispatch:       # Manuell — „Fabrik per Knopfdruck“

jobs:
  quality:
    runs-on: ubuntu-latest
    timeout-minutes: 120   # Ralph-Loops brauchen Zeit — kein 10-Min-Cutoff

    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive   # cursor-rules ist Submodul

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: mbstring, curl

      - name: Composer install
        run: composer install --no-interaction --prefer-dist

      - name: Development Workflow
        run: |
          php vendor/fabianrossbacher/base-ui-testcase/start-vendor-development-workflow.php
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}   # Nie im Prompt — nur env

      - name: Upload agent logs
        if: always()   # Auch bei rot — Post-Mortem braucht Artefakte
        uses: actions/upload-artifact@v4
        with:
          name: logs-start-vendor-${{ github.run_id }}
          path: logs-start-vendor-*/
          retention-days: 14

Pipeline-Schritt „Agent Quality“ ist kein Sci-Fi – es ist dieselbe CLI wie lokal.

IDE vs. Nachtjob – Rollen

Nicht entweder/oder – beides mit klarer Trennung. Die IDE ist zum Denken; die Shell sorgt dafür, dass Qualität läuft, wenn niemand hinschaut.

Anti-Patterns

001. Nur nachts hoffen – Ohne Script kein Job. Hoffnung ist keine Pipeline.

002. Cron ohne Exit-Code-Auswertung – Grün obwohl `exit 1`. Immer `|| alert` oder Monitoring.

003. Logs nicht rotieren – Platte voll, Ursache unklar. Tages-Logs (`-$(date +%Y-%m-%d)`) oder `logrotate`.

004. Agent mit Produktions-DB-Credentials im Prompt – Security-Desaster. `config.env` + env vars.

005. Ein Job „macht alles“ – Wieder Monster-Pipeline ohne Steps. Rotation schlägt Marathon.

006. Host-Kopie von Vendor-CLIs – Drift zwischen Projekten. Aufruf über `vendor/fabianrossbacher/base-ui-testcase/`.

007. Ralph-Loop ohne Marker – Agent sagt „fertig“, Shell weiß es nicht. Rule `018-subagent-ralph-loop-output.mdc`.

Parallele Ralph-Loops vermeiden

Zwei Loops auf dasselbe Repo = Race Conditions in `src/` und widersprüchliche Commits.

Wir nutzen Zeitfenster + Lockfile – simpel, debugbar, kein Redis nötig.

Häufige Fragen

Brauche ich einen dedizierten Server?

Nein – CI-Runner, Hetzner-VM oder lokaler Mac mit `cron` reicht für den Start. Wichtig: genug RAM für parallele Agent-Runden und SSD für Logs.

Wie vermeide ich parallele Ralph-Loops?

Lockfile (`flock`) oder Queue im Orchestrator; nicht zwei Loops auf dasselbe Repo. Cron-Slots versetzt planen.

Was wenn Cursor CLI down ist?

Logs + Alert; Pipeline rot; manueller Fallback am nächsten Morgen. Kein stilles Ignorieren.

Host-Kopie oder Vendor-Pfad?

Vendor-Pfad: `php vendor/fabianrossbacher/base-ui-testcase/start-vendor-*.php`. Ausnahme: `start-vendor-git-push.php` wird per `git-push.sh` synchronisiert.

Wie lange dürfen Nachtjobs laufen?

`set_time_limit(0)` in jedem Entry-Point. Cron-Timeout und CI `timeout-minutes` entsprechend hoch setzen (60–180 Min).

Muss ich alles in CI?

Nein – sinnvolle Aufteilung: CI für PR-Gates (schnell), Cron für tiefe Ralph-Loops (langsam). Dieselben Scripts, andere Schedule.

Verwandte Beiträge

Takeaway

CLI-Pipelines sind die Fabrik – der Chat ist die Werkstatt. Wer Checks, Subagents und Tests in Cron oder CI legt, macht Agentic Engineering produktionsfähig. Die IDE bleibt zum Denken; die Shell sorgt dafür, dass Qualität auch läuft, wenn niemand hinschaut.

Konkret heißt das: dünne `start-vendor-*.php`-Entry-Points, Orchestrator-Steps mit Briefing, Ralph-Marker für maschinenlesbares Grün, `workflow-start.sh` für die Kette, Logs auf Disk und Exit-Codes, die Cron und CI verstehen. Nerdig? Ja. Professionell? Erst dann.

Vertiefung: Von der IDE zum Nachtjob – Agentic Engineering in Produktion im Projektalltag

In unserem Repository ist agentic cron ci kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic cron ci ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 2)

Teams, die agentic cron ci produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 3)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-cron-ci` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-06-15-agentic-cron-ci/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-06-15-agentic-cron-ci/` vorhanden.

003. Route `/blog/agentic-cron-ci` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-cron-ci` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 4)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic cron ci skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-cron-ci` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.

Vertiefung (Teil 5): Von der IDE zum Nachtjob – Agentic Engineering in Produktion im Projektalltag

In unserem Repository ist agentic cron ci kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic cron ci ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 6)

Teams, die agentic cron ci produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 7)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-cron-ci` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-06-15-agentic-cron-ci/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-06-15-agentic-cron-ci/` vorhanden.

003. Route `/blog/agentic-cron-ci` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-cron-ci` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 8)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic cron ci skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-cron-ci` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.