[PLAN 21] Zbudować reusable CI, fuzzing, benchmarki i długie workflow self-hosted

[KeyffMS]

Cel

Zbudować reprodukowalną, wielokrotnego użytku infrastrukturę CI, fuzzingu, coverage, benchmarków, self-hosted soak i HIL. To issue dostarcza workflow i kontrakty raportów; rzeczywiste wykonanie wszystkich bramek na kandydacie 1.0 należy do #25.

Granica odpowiedzialności

#21 zamyka się po utworzeniu i przetestowaniu reusable workflows. Nie wymaga draft release z #24, rzeczywistych 24-godzinnych raportów kandydata ani publikacji 1.0.

• [PLAN 21] Zbudować reusable CI, fuzzing, benchmarki i długie workflow self-hosted #21: infrastruktura i demonstracyjny run na nieprodukcyjnym fixture/artifact.
• [PLAN 27] Zbudować macierz scenariuszy zgodności pełnego produktu #27: kompletna macierz testów funkcjonalnych.
• [PLAN 24] Zbudować pakiety, dokumentację i infrastrukturę draft-release #24: package/draft/finalizer/publish infrastructure.
• [PLAN 25] Przeprowadzić hardening, self-hosted soak, HIL i bramkę wydania 1.0 #25: rzeczywisty candidate run, soak, HIL, raporty, manifest, approval i publikacja.

Decyzje bezalternatywne

• Build/test w debian:trixie-slim po digest.
• Rust 1.97.1 przez APT rustup i rust-toolchain.toml.
• Każde Cargo używa --locked.
• PR amd64: ubuntu-24.04; PR arm64: natywny ubuntu-24.04-arm.
• Actions po pełnym SHA, minimalne permissions, bez sekretów dla fork PR.
• Narzędzia z dokładnymi wersjami w tools.lock.toml z [PLAN 02] Ustalić toolchain, wersje zależności i politykę aktualizacji #2.
• Brak Pythona/pip i Node jako języka skryptów projektu.

Bramka pull requestu

Statyczna jakość

• fmt check;
• Clippy workspace/all-targets/all-features z -D warnings;
• rustdoc -D warnings;
• doctests;
• cargo hack dla legalnych feature sets;
• cargo machete.

Testy

• nextest workspace/all-features/locked;
• grupy fast, PTY serial, filesystem fault injection;
• bieżące scenariusze [PLAN 20] Zbudować bazowy symulator PTY/RTU i harness ramek #20 i automatycznie dołączane testy [PLAN 27] Zbudować macierz scenariuszy zgodności pełnego produktu #27 po ich dodaniu;
• profile fixtures;
• Ratatui snapshots;
• round-trip/JCS/golden;
• architektura crate graph/capabilities/SPoA/SPoT.

Arm64 smoke

• canonical profile hash;
• PTY raw;
• Verified identification;
• polling/reconnect;
• golden trace zgodny z amd64;
• po pojawieniu się funkcji: compile/run smoke automatycznie objęty tym samym workspace test command.

Supply chain

• cargo deny check;
• cargo audit;
• cargo vet check;
• zakaz wildcard i niezatwierdzonych git dependencies;
• raport licencji/deps.

Coverage

• cargo llvm-cov + nextest;
• globalnie minimum 80% linii;
• krytyczne reguły write/trust/audit/restore/state mają testy dodatnie i ujemne niezależnie od procentu.

Nightly hosted

• pełny zestaw amd64/arm64 w limitach hosted;
• przypięty nightly dla fuzz;
• targety parserów, canonical model, adresów, kodeków i trwałych formatów;
• Miri dla pure crates/serializers;
• corpus/crash artifacts;
• benchmark smoke.

Nightly nie udaje 24-godzinnego soak.

Reusable self-hosted workflows

Dedykowane, jednoznaczne etykiety:

• vfd-lantern-soak-amd64;
• vfd-lantern-soak-arm64;
• vfd-lantern-hil;
• stałe performance runners.

Dwu-jobowy protokół dla każdego runu dłuższego niż 20 godzin

1. *-run:
   • pobiera i weryfikuje wejściowy artifact przed startem;
   • działa wymagany czas bez polegania na tokenie po pobraniu;
   • zapisuje raport do chronionego lokalnego stagingu <runner>/<workflow_run_id>/<artifact_hash>;
   • zapisuje completion marker, commit, asset hash, seed i SHA-256 plików;
   • nie próbuje uploadować po 24 godzinach.
2. *-upload:
   • jest osobnym jobem zależnym od *-run, więc otrzymuje świeży GITHUB_TOKEN;
   • działa na tym samym unikalnym runner label;
   • weryfikuje marker, run ID, commit i asset hash;
   • uploaduje raport;
   • usuwa staging dopiero po potwierdzonym uploadzie.

concurrency i lokalny lock blokują dwa równoległe długie runy na jednym runnerze. Staging innego run ID nie może zostać użyty.

Reusable soak

• parametr czasu, domyślnie 24 h dla candidate;
• dashboard/scope/CSV/faults/reconnect po dodaniu [PLAN 27] Zbudować macierz scenariuszy zgodności pełnego produktu #27;
• metrics, CPU, RSS, latency, dropy;
• scenario hash/seed;
• demonstracyjny krótki run w [PLAN 21] Zbudować reusable CI, fuzzing, benchmarki i długie workflow self-hosted #21 potwierdza mechanizm staging/upload bez czekania 24 h.

Reusable HIL

• read-only default;
• write wymaga protected Environment;
• długie runy używają tego samego run/upload staging;
• raport zawiera fingerprint, profile hash, firmware, adapter, app/artifact hash i audit outcome;
• [PLAN 21] Zbudować reusable CI, fuzzing, benchmarki i długie workflow self-hosted #21 testuje workflow na fixture/mock hardware gate, ale rzeczywisty sprzętowy run należy do [PLAN 25] Przeprowadzić hardening, self-hosted soak, HIL i bramkę wydania 1.0 #25.

Benchmarki

Criterion dla codec, planner, downsampling, pipeline, profile validation, diff, render model, JCS/hash i AuditPort.

PR wykonuje smoke; pełne performance workflow jest reusable i testowane na nieprodukcyjnym artefakcie. Twarde budżety są oceniane w #25.

Interfejs workflow

Reusable workflows przyjmują jawnie:

• artifact path/source;
• expected SHA-256;
• commit SHA;
• profile/scenario hash;
• duration;
• output schema version.

Zwracają manifest raportu i status bramki. Nie zakładają istnienia draft release; #25 może podać asset pobrany przez #24.

Kryteria akceptacji

• PR gate obejmuje fmt/clippy/docs/tests/profiles/security/coverage amd64 i native arm64 smoke.
• PTY/Modbus działa w CI.
• cargo vet check jest poprawnym poleceniem.
• Fuzz/mutation mają corpus i raporty.
• Reusable soak/HIL/performance workflows istnieją i mają test demonstracyjny.
• Długie runy stosują osobny run job i świeży-token upload job.
• Staging jest związany z run ID i artifact hash oraz czyszczony po uploadzie.
• [PLAN 21] Zbudować reusable CI, fuzzing, benchmarki i długie workflow self-hosted #21 nie wymaga rzeczywistego draftu ani candidate report do zamknięcia.
• Podstawowy CI nie wymaga sprzętu ani Pythona.

Zależności

• [PLAN 02] Ustalić toolchain, wersje zależności i politykę aktualizacji #2
• [PLAN 04] Zaprojektować wersjonowany format profilu i pełną walidację #4
• [PLAN 20] Zbudować bazowy symulator PTY/RTU i harness ramek #20

Korekta organizacji testów i supply-chain

Reusable CI rozdziela testy #20 na: unit tests symulatora; serializowane PTY/raw/wire faults; integrację produkcyjnego BusActor i SessionStateMachine; process-level E2E produktu dołączane po #13.

Raport cargo-vet osobno wykazuje audited, imported, exempted i unaudited. Automatyczny baseline exemptions nie jest nazywany audytem. Standardowy PR gate wykonuje rzeczywiste machete, deny, audit i vet, nie tylko uproszczony baseline.