Validator Registry

Alle IIO-Validatoren auf einen Blick — Prozessflüsse, Gating-Points, bekannte Anti-Pattern und wie Coding Agents sie korrekt nutzen.

28 Validatoren 3 Publishing-Gates 2 Infra-Gates Fail-Closed by Design

Schnell-Einstieg: Was ist neu?

Lade Neuerungen...

    Publishing-Pipeline — iio/manual → intelego/manual/seed

    Autor
    Seite schreiben
    iio/manual/*.html
    ›
    ⚑ Gate 1
    CSS Drift Validator
    validate-manual-css.sh
    ›
    ⚑ Gate 2
    DNS Config Validator
    validate-dns-config.sh
    ›
    Transform
    Seed → Node Projektion
    project-seed-to-node.sh
    ›
    ✓ Output
    Rendering-ready
    intelego/manual/seed/
    Wie es funktioniert Gate 1 + Gate 2 laufen als Stage 0 in project-seed-to-node.sh — schlagen sie fehl, stoppt die Projektion. Kein Silent-Fail.

    Theme-Ingestion-Pipeline — Brand Source → CSS

    Deklaration
    stream-contract schreiben
    stream-contract.theme.yml
    ›
    ⚑ Gate 1
    Contract Validator
    validate-stream-contract.sh
    ›
    Extract
    Source-Assets holen
    execute-stream-contract.sh --stage=extract
    ›
    Transform
    Assets verarbeiten
    execute-asset-transform.sh
    ›
    Render
    CSS generieren
    execute-stream-contract.sh --stage=render
    ›
    ⚑ Gate 2
    Contrast Validator
    validate-theme-contrast.sh
    ›
    ✓ Output
    assets/style.css
    + assets-manifest.yml + contrast-report.yml

    Theme-Contrast-Hinweise — Live aus Runtime-Daten

    Lade Contrast-Hinweise...

      Source Provenance — Live aus Runtime-Daten

      Lade Source-Provenance...

        AI-Cell Rollout-Pipeline — Server → Governed Cell

        Server
        Laufender Debian 12
        inhzgx*.intelego.net
        ›
        ⚑ Stufe 1
        OS Hardening
        inhzgx-harden.sh
        ›
        ⚑ Stufe 2
        Stack + Key Config
        LiteLLM + vLLM + Ollama
        ›
        ⚑ Stufe 3
        DNS + SSL
        dns-set-record.sh
        ›
        ✓ Output
        IIO-governed Cell
        /etc/iio-asset.json

        Alle Validatoren — vollständiges Register

        Script Bereich Was wird geprüft Wann ausführen Typ
        validate-manual-css.sh iio/manual Hex-Farben, var(--iio-*) Pflicht, Naming-Konvention, Shell-Einbindung Vor jeder Projektion (Gate 1) Publishing-Gate
        validate-dns-config.sh iio/base/infra-dns dns.hetzner.com (verboten), falscher Auth-Header, veraltete Token-Namen Vor DNS-Operationen, in CI Infra-Gate
        validate-stream-contract.sh iio/base/theme-ingestion Placeholders, Pflichtfelder, IP-Gate, Source-URL, CSS-Status Vor Theme-Ingestion (Gate 1) Theme-Gate
        validate-theme-contrast.sh iio/specs WCAG-Kontrast fuer zentrale --iio-* Tokenpaare (light + dark), fail-closed Nach Render, vor Runtime/Publish (Gate 2) Theme-Gate
        validate-top-level-skill-mapping.sh iio/specs Jedes Top-Level-Verzeichnis hat deklarierten Skill-Typ Nach Struktur-Änderungen Governance
        validate-classification-completeness.sh iio/specs Alle Artefakte haben Klassifikation (own/reference/generated/imported) In Validation-Chain Governance
        validate-seed-projection.sh iio/specs Seed → Node Projektion konsistent, Pfade stimmen Nach Projektion Governance
        validate-environment-registry.sh iio/specs environment-registry.yaml Schema, Naming-Schema-Konformität In Validation-Chain Governance
        validate-review-gates.sh iio/specs Gate-Definitionen vollständig, Approver definiert Vor Release HITL-Gate
        validate-seed-operational-wiring.sh iio/specs Alle Skills korrekt verdrahtet, SKILL.md vorhanden Nach Skill-Änderungen Governance
        validate-premises-codex-wiring.sh iio/specs Premises-Referenzen in Skills und Gates konsistent In Validation-Chain Governance
        validate-mcp-policy.sh iio/specs MCP-Policy-Konformität, erlaubte Transports Vor MCP-Integration Governance
        validate-adapter-registry.sh iio/specs Alle Adapter registriert, Schema-Konformität Nach Adapter-Änderungen Governance
        validate-workspace-root-cleanliness.sh iio/specs Keine steuernden Dateien im Root (Rail 10/11) In Validation-Chain Governance
        validate-base-taxonomy.sh iio/base BASE-TAXONOMY vollständig und korrekt In Validation-Chain Governance
        validate-skill-reflection.sh iio/base/reflection Kein Skill referenziert sich selbst (Mirror-Trap) Nach Skill-Änderungen Governance
        validate-artifact-registry.sh iio/base/artifact-registry Artifact-Cache konsistent, Klassifikationen vollständig Nach Artifact-Änderungen Governance
        validate-revision.sh iio/base/revisions Revisions-Struktur korrekt, Evidence vorhanden Vor Revision-Publish Governance
        validate-projection-manifest.sh iio/specs Projektion-Manifest Schema und Vollständigkeit Nach Projektion Governance
        validate-capability-profiles.sh iio/specs Capability-Profile vollständig, Skill-Referenzen gültig In Validation-Chain Governance
        validate-story-consistency.sh iio/specs Story-Lifecycle konsistent, Übergänge gültig Nach Story-Änderungen Governance
        check-gate-readiness.sh iio/specs HITL-Gate-Kriterien erfüllt vor Approval Vor HITL-Gate HITL-Gate
        check-agent-steering.sh iio/specs Agent-Steering-Dokumente vorhanden und korrekt In Validation-Chain Governance
        check-cross-root-links.sh iio/specs Keine ungültigen Cross-Root-Referenzen In Validation-Chain Governance
        validate-forensic-records.sh iio/base/forensic Forensic-Records vollständig und integer Bei Forensic-Audit Governance
        validate-public-pack.sh iio/base/public Public-Artefakte vollständig, keine internen Daten Vor Public-Release Publishing-Gate
        validate-node-operational-rails.sh intelego/specs Node-spezifische Rails eingehalten Nach Node-Änderungen Node-Governance
        validate-node-premises-codex-wiring.sh intelego/specs Node-Premises-Referenzen konsistent mit Seed Nach Premises-Änderungen Node-Governance

        Anti-Pattern: Context Poisoning — Wie Fehler sich selbst replizieren

        ⚠ Context Poisoning — das hartnäckigste AI-Agent-Anti-Pattern

        1
        Falsches Wissen landet in einer Datei — z.B. ein Kommentar sagt dns.hetzner.com ist abgelöst (falsch) oder eine Variable heißt HETZNER_DNS_TOKEN statt HCLOUD_TOKEN.
        2
        Agent liest diese Datei als Kontext — er übernimmt die falsche Aussage als Fakt, weil sie in einer "Authority-Datei" steht (Script, SKILL.md, AGENTS.md).
        3
        Fehler wird in neue Dateien kopiert — Agent schreibt neue Scripts/Docs mit dem falschen Wissen. Fehler multipliziert sich.
        4
        Selbstverstärkung — nächste Session: Agent liest mehrere Dateien mit dem Fehler → bestätigt sich selbst → Fehler wird "stabiler".
        5
        Partielle Korrekturen scheitern — Agent korrigiert A, übersieht B und C. Fehler überlebt weil er nicht workspace-weit gesucht wurde.

        ✓ Gegenmittel — in dieser Reihenfolge

        1. Workspace-weite Suche zuerst — bevor man annimmt etwas stimmt oder korrigiert: grep -rn "verdächtiger-string" /workspace/ --include="*.sh" --include="*.md" | grep -v .git
        2. Validator bauen — wenn ein Fehler zweimal vorkommt: Validator der den falschen String aktiv blockiert (wie validate-dns-config.sh).
        3. Assertion im Script — Schutz direkt im Code: if [[ "$var" == *"falscher-wert"* ]]; then die "Falscher Wert"; fi
        4. In AGENTS.md verankern — bekannte falsche Strings explizit als VERBOTEN listen damit jeder Agent sie beim Start sieht.

        Weitere bekannte Anti-Pattern für Coding Agents

        Anti-PatternWas passiertGegenmittelIIO-Enforcement
        Context Poisoning Falscher String in Datei → repliziert sich in neue Dateien → workspace-weit verteilt Workspace-weite Suche + Validator bauen validate-dns-config.sh, validate-manual-css.sh
        Script-Bypassing Agent ruft curl, ssh, docker direkt auf statt IIO-Script zu nutzen → kein Audit-Trail, keine Fehlerbehandlung AGENTS.md: Script-First Policy. Vor jeder Aktion prüfen ob Script existiert. AGENTS.md Guardrail, SKILL.md Script-Tabelle
        Scope Creep Agent ändert Dateien ausserhalb des deklarierten Scopes → unbeabsichtigte Kollateralschäden Explizite Constraints: "Ändere NUR Dateien in X. Nichts in Y." Constraint Declaration Pattern im coding-agents-guide
        Optimistic Completion Agent meldet "fertig" ohne zu verifizieren → Fehler bleiben unbemerkt Verify-Before-Proceed: Agent muss Validator laufen lassen bevor er weitergeht Validatoren als Pflicht-Gates in allen Pipelines
        Legacy Contamination Agent liest migrate/ oder legacy/ als Autorität → übernimmt veraltete Muster Anti-Contamination-Policy: migrate/ ist UNTRUSTED. Niemals direkt übernehmen. ANTI-CONTAMINATION-POLICY.md, Validator-Chain Step 2.6
        Implicit Context "Du weißt ja wie das Theme aussieht" → Agent rät → falsches Ergebnis File-Anchored Reasoning: immer explizite Datei-Referenz, nie impliziten Kontext annehmen Semantic Grounding Prinzip im coding-agents-guide
        Partial Fix Agent korrigiert eine Stelle, übersieht 5 andere → Fehler überlebt Workspace-weite Suche vor und nach jeder Korrektur Validator-Pattern: blockiert verbotene Strings überall
        API Confusion Zwei APIs mit ähnlichen Namen → falsche genutzt → 401/404 Fehler die schwer zu debuggen sind APIs explizit in SKILL.md dokumentieren + Assertion im Script validate-dns-config.sh blockiert falsche Hetzner API
        Token Namespace Drift Verschiedene Namen für denselben Token (HCLOUD_TOKEN, HETZNER_TOKEN, HETZNER_DNS_TOKEN) → unklar welcher stimmt Kanonische Token-Namen in SKILL.md + Validator prüft veraltete Namen validate-dns-config.sh, infra-dns SKILL.md