[ROADMAP] VFD Lantern 1.0 — aktualny plan realizacji

[KeyffMS]

VFD Lantern 1.0 — roadmap po audycie dry-code

Aktualizacja: 2026-09-10

Ta roadmapa jest bieżącym operacyjnym źródłem kolejności prac dla VFD Lantern 1.0. Starsze komentarze i wcześniejsze sekwencje należy traktować historycznie, jeśli są sprzeczne z poniższym planem.

Cel 1.0

Dostarczyć bezpieczny, audytowalny i reprodukowalny VFD Lantern 1.0 dla Debian 13 Trixie / amd64 (x86_64), z jednym aktywnym VFD po Modbus RTU/RS-485, Verified identification, monitoringiem, diagnostyką, kontrolowanym pojedynczym write oraz ograniczonym backup/diff/restore.

Arm64 i inne systemy pozostają poza bieżącym zakresem 1.0 i wracają dopiero po ukończeniu oraz kwalifikacji Debian 13 amd64.

Niezmienniki architektoniczne

• jeden proces, jeden produkcyjny binary i jeden composition root vfd-lantern;
• dependency inversion: lantern-app definiuje politykę i porty, adaptery wskazują do środka;
• SPoA: pojedynczy BusActor dla fizycznego RTU, pojedynczy WriteCoordinator dla fizycznych write, storage jako właściciel I/O plikowego;
• SPoT: ValidatedDeviceProfile, ApplicationState, SessionStateMachine, UiState, LatestValues, PollPlan;
• read-only jest stanem domyślnym;
• write wymaga Verified + trust + Armed + Healthy audit + prepare/confirm + durable prepare + dokładnie jednego write + bounded read-back;
• zero retry write, zero rollback, zero auto-restore, zero motion/fault-reset/raw-PDU;
• restore 1.0 wyłącznie dla allowlisty Normal przez ApprovedRestorePlan i RestoreOperationPermit;
• każda zmiana przed candidate musi zachować fail-closed boundaries oraz pełne committed conformance evidence [PLAN 01] Zablokować architekturę modularnego monolitu Rust #1–Create logical issue #6 commit #40.

Stan osiągnięty

• M0 Architecture locked — DONE ([PLAN 01] Zablokować architekturę modularnego monolitu Rust #1–[PLAN 06] Ustalić konfigurację aplikacji, CLI i katalogi XDG #6)
• M1 Read-only transport proven — DONE ([PLAN 07] Zbudować wykrywanie portów, hotplug i obsługę Linux RS-485 #7–[PLAN 09] Zbudować maszynę stanu sesji, identyfikację i reconnect #9, [PLAN 20] Zbudować bazowy symulator PTY/RTU i harness ramek #20)
• M2 Read-only MVP — DONE ([PLAN 10] Zbudować planner odczytów i kontrolę wykorzystania magistrali #10–[PLAN 15] Zbudować przeglądarkę parametrów i bezpieczny edytor wartości #15)
• M3 Diagnostics/data — DONE ([PLAN 18] Zbudować dekodowanie faultów i freeze-frame #18–[PLAN 19] Zbudować wydajne logowanie CSV i metadane sesji #19)
• M4 Single-write beta — DONE ([PLAN 16] Zbudować dwuetapowy core prepare/confirm zapisu #16, [PLAN 22] Zbudować obserwowalność, trwały AuditPort i pakiet diagnostyczny #22, [PLAN 23] Zamknąć profile trust, bezpieczeństwo funkcjonalne i supply chain #23)
• M5 Restore core — DONE ([PLAN 17] Zbudować bezpieczny backup, semantyczny diff i ograniczony restore #17)
• M6 Candidate infrastructure — DONE ([PLAN 21] Zbudować reusable CI, fuzzing, benchmarki i długie workflow self-hosted #21, [PLAN 24] Zbudować pakiety, dokumentację i infrastrukturę draft-release #24, [PLAN 27] Zbudować macierz scenariuszy zgodności pełnego produktu #27)
• PR sim: start full-product conformance scenario matrix (#27) #75 zamknął [PLAN 27] Zbudować macierz scenariuszy zgodności pełnego produktu #27; committed golden conformance evidence obejmuje 40/40 case IDs.

Wynik audytu KISS / DRY / SPoA / SPoT / clean-code

Rdzeń bezpieczeństwa, transport, profile, polling, telemetry, write kernel i restore kernel są gotowe do dalszego hardeningu. Audyt wykazał jednak, że przed przejściem wyłącznie na sprzęt należy domknąć integrację produktu oraz kilka uproszczeń utrzymaniowych.

M6.5 — Dry-code completion & cleanup — AKTYWNE TERAZ

Ten etap nie wymaga fizycznego VFD.

1. Backup / Diff / Restore — pełna integracja produktu

   • połączyć istniejący core [PLAN 17] Zbudować bezpieczny backup, semantyczny diff i ograniczony restore #17 z ApplicationState / effect boundary / production runtime;
   • zastąpić placeholder ekranu Backup / Diff / Restore realnym przepływem TUI;
   • zapewnić capture complete backup, semantic diff, prepare restore, jawne potwierdzenie, begin/step/finish/abort;
   • żadnej drugiej ścieżki write: wszystkie kroki restore nadal przez istniejący WriteCoordinator.

2. Process-level dry E2E backup/restore

   • symulator/PTy oraz produkcyjna ścieżka composition root;
   • success + refusal + disconnect + OutcomeUnknown + audit failure;
   • dokładnie jeden write na krok, zero retry, zero rollback/resume;
   • potwierdzenie, że TUI nie może ominąć permit/trust/audit.

3. Bus Diagnostics UI

   • zastąpić placeholder rzeczywistą projekcją istniejących statystyk RTU/poll/queues/timeouts/drops;
   • presentation-only, bez nowego stanu transportowego.

4. SPoT session/write cleanup

   • ograniczyć RuntimeSessionControl / WriteSessionSnapshot do projekcji/cache stanu aplikacji;
   • SessionStateMachine pozostaje jedynym właścicielem decyzji o stanie sesji, authorization, audit health i operation;
   • brak drugiego mutable authority.

5. KISS / DRY refactor bez zmiany semantyki

   • rozbić duże moduły implementacyjne (application.rs, poll.rs, ewentualnie wewnętrznie write_coordinator.rs) bez tworzenia nowych SPoT/SPoA;
   • scalić powtarzalne restore abort/finalize helpers;
   • uprościć powtarzalne reset/search flows w UiState;
   • nie deduplikować safety re-checków wykonywanych ponownie tuż przed write — ich powtórzenie jest wymaganiem bezpieczeństwa.

6. Clean-code / docs cleanup

   • usunąć nieaktualne placeholder/status texty;
   • zaktualizować README ze stanu architecture bootstrap / pre-alpha;
   • uporządkować nazewnictwo UI i ograniczyć niepotrzebnie szeroki publiczny surface tam, gdzie można to zrobić bez ryzyka.

Kryterium zakończenia M6.5

• Backup/Diff/Restore jest osiągalny z produkcyjnego TUI przez właściwe capability boundaries;
• Bus Diagnostics nie jest placeholderem;
• brak drugiego authority dla bus/write/session;
• architecture checks zielone;
• pełny CI zielony na Debian 13 amd64;
• wszystkie dry/process E2E zielone;
• 40/40 committed conformance pozostaje zielone i semantycznie nieosłabione.

---

BRAMKA SPRZĘTOWA — H1

Sprzęt wchodzi dopiero po zakończeniu M6.5. To jest pierwszy etap, którego nie da się wiarygodnie domknąć wyłącznie symulatorem/PTy.

H1 — zakup i przygotowanie stanowiska

Wymagane minimum:

• komputer/runner Debian 13 amd64 z dostępem do rzeczywistego RS-485;
• co najmniej 2 fizyczne VFD od 2 różnych producentów wraz z właściwymi manualami i znanym firmware/revision;
• adaptery do późniejszej matrix: FTDI, CP210x, CH34x;
• rzeczywisty native UART z kernelowym TIOCGRS485/TIOCSRS485 do obowiązkowej bramki native-RS485;
• bezpieczne stanowisko: brak niekontrolowanego ruchu, właściwe odłączenie/LOTO/interlocks zgodnie z charakterem testowanego układu.

Brak sprzętu nie blokuje M6.5. Blokuje natomiast kwalifikację profili i rzeczywisty candidate 1.0.

M7.1 — Profile qualification na fizycznym sprzęcie

Po H1:

1. ustalić finalny profil dla każdego wybranego VFD i exact semantic profile_hash;
2. wykonać fizyczną kwalifikację każdego write-capable hash;
3. utrwalić QualificationReportV1 związany z hardware model, firmware, manual revision i safe-write scope;
4. utworzyć produkcyjny frozen QualificationIndexV1;
5. nie używać release/fixtures/qualification-index-v1.json jako production evidence — fixture pozostaje tylko do testów infrastruktury.

Qualification report musi istnieć przed candidate buildem.

M7.2 — Candidate freeze i jeden prawdziwy draft

Po M7.1:

• zamrozić toolchain, Cargo.lock, schemas, profiles, qualification index i workflows;
• ustawić finalną wersję 1.0.0 oraz changelog;
• utworzyć exact candidate commit;
• uruchomić release-candidate-build dla Debian 13 amd64;
• wszystkie dalsze testy pobierają wyłącznie assety tego draftu i weryfikują SHA-256;
• lokalny rebuild nie jest dowodem candidate.

M7.3 — Exact-asset acceptance

Na dokładnych candidate assets:

• package/install/upgrade/uninstall;
• zgodność embedded/disk profile manifest;
• pełne conformance [PLAN 01] Zablokować architekturę modularnego monolitu Rust #1–Create logical issue #6 commit #40;
• performance budgets;
• system/data failure tests i security/red-team/docs review.

M7.4 — Hardware candidate HIL / soak / adapter matrix

Na tym samym zamrożonym draft asset:

• 24 h self-hosted soak Debian 13 amd64;
• candidate HIL obu VFD;
• 24 h read-only, identification, telemetry/faults, complete backup/diff;
• kontrolowane manual write do dozwolonych klas;
• restore wyłącznie Normal z permit;
• disconnect/reconnect i fingerprint mismatch;
• zero retry write, disarm oraz trwałe audit outcomes;
• FTDI / CP210x / CH34x / native UART TIOCGRS485/TIOCSRS485;
• raporty związane z exact candidate commit i asset SHA-256.

Candidate HIL jest drugim, odrębnym dowodem od wcześniejszej profile qualification.

M7.5 — Finalizer i approval

Po wszystkich raportach:

• upload gate reports;
• snapshot asset set S;
• finalizer tworzy CandidateManifest jako jedyny końcowy asset po snapshotcie;
• external manifest hash + protected approval;
• finalny zbiór musi być dokładnie S ∪ {CandidateManifest}.

M7.6 — Publish 1.0

• tag wskazuje exact candidate commit;
• publish promuje ten sam draft, bez rebuild/repackage/re-upload;
• post-publish download i porównanie hashy;
• rozbieżność = release-blocking incident;
• close [PLAN 25] Przeprowadzić hardening, self-hosted soak, HIL i bramkę wydania 1.0 #25;
• close [ROADMAP] VFD Lantern 1.0 — aktualny plan realizacji #26.

Skrócona kolejność wykonawcza

M0–M6 DONE → M6.5 dry-code completion/cleanup → H1 zakup/przygotowanie sprzętu → M7.1 profile qualification → M7.2 candidate 1.0.0 → M7.3 exact-asset acceptance → M7.4 HIL/soak/adapter matrix → M7.5 finalizer/approval → M7.6 publish → close #25/#26

Zakres poza 1.0

• arm64 i inne systemy;
• wiele aktywnych VFD/portów;
• Modbus TCP/ASCII, CANopen, EtherCAT i inne protokoły;
• raw register/PDU, broadcast, blind scan;
• motion control i fault reset;
• restore klas innych niż Normal;
• network/server/cloud/update/plugin runtime;
• GUI/mouse/Windows/macOS;
• safety-rated guarantee.

Kryterium zamknięcia roadmapy

Roadmapa może zostać zamknięta dopiero po zakończeniu M6.5, wykonaniu fizycznych qualification/HIL wymaganych przez #25 oraz opublikowaniu VFD Lantern 1.0 Debian 13 amd64 z identycznym, zweryfikowanym asset setem candidate.

[github-actions]

Autorytatywny stan wykonania #1–#9 i #20

Odczyt bezpośrednio z GitHub API:

• PR Implement roadmap issues #1–#9 #33: state=closed, draft=false, merged_at=2026-08-13T08:56:43Z;
• PR HEAD: 0d44845630c22efc9675b1fd1b32abceaf75bfe3;
• merge SHA: 4e554f3ad83d15d194d3165e4d98182d08bc9776;
• main SHA: 4e554f3ad83d15d194d3165e4d98182d08bc9776;
• fundament [PLAN 01] Zablokować architekturę modularnego monolitu Rust #1–[PLAN 09] Zbudować maszynę stanu sesji, identyfikację i reconnect #9: PASS;
• workflow domknięcia: missing;
• workflow naprawy [PLAN 20] Zbudować bazowy symulator PTY/RTU i harness ramek #20: missing;
• ścisły audyt [PLAN 20] Zbudować bazowy symulator PTY/RTU i harness ramek #20: missing.

#20 nie jest uznawane za ukończone na podstawie samej kompilacji. Wymagany jest PASS ścisłego audytu potwierdzającego rzeczywisty tokio-modbus RTU server oraz test przez produkcyjny BusActor i SessionStateMachine.

[KeyffMS]

Operacyjna aktualizacja roadmapy po odbiorze #12: #12 jest closed/completed po merge PR #63 (4e1906ac2e4147c96a6ee85feb787346150489f7). Finalny CI #590 na self-hosted runnerze #21 (vfd-lantern-podman-01, amd64) przeszedł build, fmt, Clippy, pełne testy, benchmark, rustdoc, architecture i supply-chain. Następnym blockerem M2 jest #13; aktywna ścieżka zaczyna się teraz #13 → #14 → #15 → #18 → #19 → #16 → #22 → #23 → #17 → #24 → #25. Arm64 pozostaje wstrzymane zgodnie z tymczasową polityką.

[KeyffMS]

Roadmap checkpoint — 2026-08-28

Sekwencja po #11 pozostaje obowiązująca. Stan wykonania:

• [PLAN 12] Zbudować szkielet TUI w Ratatui z jednokierunkowym przepływem stanu #12 — completed;
• [PLAN 13] Zbudować read-only kreator połączenia i identyfikacji #13 — completed, PR Implement #13: verified read-only connection wizard #65 squash-merged jako 31c1d450574626f6f1eae769c10ffdbfb4ef65b4, finalny self-hosted CI #675 full success;
• [PLAN 14] Zbudować dashboard i wielokanałowy scope #14 — następny aktywny etap;
• dalej: [PLAN 15] Zbudować przeglądarkę parametrów i bezpieczny edytor wartości #15 → [PLAN 18] Zbudować dekodowanie faultów i freeze-frame #18 → [PLAN 19] Zbudować wydajne logowanie CSV i metadane sesji #19 → [PLAN 16] Zbudować dwuetapowy core prepare/confirm zapisu #16 → [PLAN 22] Zbudować obserwowalność, trwały AuditPort i pakiet diagnostyczny #22 → [PLAN 23] Zamknąć profile trust, bezpieczeństwo funkcjonalne i supply chain #23 → [PLAN 17] Zbudować bezpieczny backup, semantyczny diff i ograniczony restore #17 → [PLAN 24] Zbudować pakiety, dokumentację i infrastrukturę draft-release #24 → [PLAN 25] Przeprowadzić hardening, self-hosted soak, HIL i bramkę wydania 1.0 #25.

#21 (CI) i #27 (conformance) pozostają ciągłe. #14 będzie osobnym PR-em i nie będzie mieszał zmian #15. Odbiór w feature phase nadal na self-hosted amd64 zgodnie z #21.

[KeyffMS]

Roadmap status — 2026-08-28

Etap 2 przesunął się względem tekstu głównego roadmapy:

• [PLAN 12] Zbudować szkielet TUI w Ratatui z jednokierunkowym przepływem stanu #12 — done, PR Implement #12: Ratatui TUI shell and one-way presentation flow #63 merged;
• [PLAN 13] Zbudować read-only kreator połączenia i identyfikacji #13 — done, PR Implement #13: verified read-only connection wizard #65 merged po pełnym zielonym CI na vfd-lantern-podman-01;
• [PLAN 14] Zbudować dashboard i wielokanałowy scope #14 — active, PR Implement #14: semantic dashboard and Scope monitoring #66 (agent/issue-14), obecnie model semantycznego Dashboard/Scope + subskrypcje PollPlanner; trwa domykanie bramek bieżącego checkpointu na self-hosted amd64;
• [PLAN 15] Zbudować przeglądarkę parametrów i bezpieczny edytor wartości #15 pozostaje następnym głównym issue po pełnym zakończeniu [PLAN 14] Zbudować dashboard i wielokanałowy scope #14.

Obowiązująca kolejność wykonawcza pozostaje bez zmian. #21/#27 pozostają pracą ciągłą; zakres #14 będzie dopisany do dowodów conformance/CI przed zamknięciem issue.

[KeyffMS]

Aktualizacja po domknięciu #15:

• PR Implement #15: virtualized parameter browser and typed intent editor #67 merged jako 4ae355d62afed36a2a85938242995baa5233a0ac
• final PR CI #778: full success
• post-merge main CI #779: full success
• [PLAN 15] Zbudować przeglądarkę parametrów i bezpieczny edytor wartości #15 closed/completed
• M2 ma 6/6 issues ([PLAN 10] Zbudować planner odczytów i kontrolę wykorzystania magistrali #10–[PLAN 15] Zbudować przeglądarkę parametrów i bezpieczny edytor wartości #15) closed/completed
• następny aktywny feature: [PLAN 18] Zbudować dekodowanie faultów i freeze-frame #18

Milestone M2 jest gotowy do zamknięcia.

[KeyffMS]

Status operacyjny — 2026-09-10

#27 jest zakończone i scalone do main przez PR #75, merge commit 5ccab737ebc61fc0ea190d55dea4dc9406b10713. Finalne CI #977 dla evidence commit ca735d2889dc399cea67077790ea97641c28abc1 zakończyło się sukcesem; macierz conformance ma committed golden evidence dla case IDs #1–#40.

M6 Candidate infrastructure: DONE — #21, #24 i #27 są zakończone.

Aktualny etap wykonawczy: #25 / M7 Stable 1.0 (Debian 13 amd64). Wcześniejsze fragmenty opisu roadmapy wskazujące #27 → #25 albo #27 jako otwarte należy czytać jako historyczne; aktualna kolejność to wyłącznie #25 → publikacja 1.0 → zamknięcie #26.

Preflight #25 wykazał, że infrastruktura build/finalize/publish jest dostępna, ale prawdziwy candidate build pozostaje zablokowany do czasu dostarczenia produkcyjnych profile qualification reports / frozen QualificationIndexV1 dla rzeczywistych profili VFD.