Dla dev/ops integrujących ipIII (Evidence & Resilience Orchestrator): jak wersjonujemy strony, API i schemat bazy, co dziś gwarantujemy w kompatybilności wstecznej, jaka jest ścieżka aktualizacji oraz jaka jest polityka breaking changes. Doktryna claim ≤ proof: pre-1.0 = jawnie brak formalnej gwarancji SemVer, nie udajemy inaczej.
ipIII nie ma jednego numeru wersji obejmującego wszystko. Strony /ai-truth/ipIII/* są statycznym
HTML wersjonowanym przez commit w repozytorium (bez build-stepu). API ma własny prefiks kontraktu
/api/ip3/v1. Schemat bazy jest aktualizowany przyrostowo (idempotentne CREATE TABLE IF NOT EXISTS /
ALTER TABLE ... ADD COLUMN IF NOT EXISTS uruchamiane przy starcie serwera), nie osobnym numerem wersji.
Kanon numeru wersji produktu = release notes (dziś: v0.8 controlled pilot).
| Oś | Jak wersjonowana dziś | Gdzie sprawdzić | Status |
|---|---|---|---|
| Produkt (ipIII jako całość) | Numer opisowy w release notes (v0.8 controlled pilot), nie ścisły SemVer. Kolejne wydania
opisane jako przyrosty do v1.0. |
/release-notes | LIVE |
| API (kontrakt) | Jeden aktywny prefiks /api/ip3/v1. Kontrakt referencyjny oznaczony jako
0.1.0-reference — to opis endpointów (OpenAPI-lite), nie SLA. Dziś nie istnieje /v2. |
/api-docs | LIVE v1 |
| Schemat bazy danych | Brak osobnego numeru wersji. Tabele domeny ipIII tworzone/rozszerzane idempotentnie w kodzie tras
(CREATE TABLE IF NOT EXISTS, ADD COLUMN IF NOT EXISTS) przy starcie procesu —
additive-only, bez formalnych down-migracji dla tej domeny. |
/model-danych | LIVE (proces) |
| Strony (dokumentacja/UI) | Statyczny HTML w repozytorium (public/envois/ait-ip3-*.html), bez build-stepu i bez
osobnego numeru wersji strony — wersją jest commit git. URL-e (canonical) traktujemy jako stabilne. |
/status-matrix | LIVE |
MAJOR.MINOR.PATCH z jawną definicją breaking change
dla API) jest planowana po v1.0 — dziś jej nie ma i nie udajemy inaczej. Do tego czasu obowiązuje sekcja 3 poniżej.
Poniżej jawnie: co jest dziś stabilne (można na tym polegać) i co może się zmienić bez formalnego okresu wypowiedzenia w fazie pre-1.0.
Ścieżki URL /ai-truth/ipIII/* (canonical) — nie usuwamy stron bez przekierowania.
Prefiks API /api/ip3/v1 — endpointy oznaczone LIVE w kontrakcie nie znikają w ramach v1.
Kształt evidence-package (manifest + package_sha256 + chain-of-custody) — pola nie są usuwane, mogą być dodawane.
Dokładny kształt pól JSON w odpowiedziach nowych endpointów (dodawanych w trakcie pilota) — traktuj jako kontrakt referencyjny, nie SLA.
Nazwy wewnętrznych statusów/enumów w warstwie dev (np. workflow remediacji) — dopóki nie oznaczone jako LIVE w status-matrix.
Struktura tabel w schemacie — zmiany są dziś additive-only (dodawanie kolumn/tabel), ale formalna gwarancja „nigdy nie usuniemy kolumny" nie jest jeszcze ogłoszona.
/ai-truth/ipIII/<slug> jest stabilny;
jeśli integrujesz linki głębokie, linkuj do canonical, nie do kopii treści./api/ip3/v1. To jedyny aktywny kontrakt.
Endpointy oznaczone x-status: LIVE w referencji OpenAPI-lite (/api-docs)
działają na żywej bazie z JWT/RBAC. Endpointy poza tym prefiksem (np. legacy placeholder) traktuj jako GAP, nie jako kontrakt./v2. Dziś nie istnieje kolejna wersja API. Gdy powstanie,
zostanie ogłoszona tu i w aktualizacjach z okresem równoległego działania
v1 — to zobowiązanie na przyszłość (ROADMAP), nie opis dzisiejszego stanu.CREATE TABLE IF NOT EXISTS, ADD COLUMN IF NOT EXISTS) przy starcie serwera —
restart procesu = bezpieczne dogranie brakujących obiektów, bez ręcznego kroku migracji dla integratora.
Zobacz strukturę: /model-danych.migrations/ z datowanymi plikami SQL — ipIII na razie nie tego wzorca).
Brak formalnych down-migracji (cofnięcie zmiany schematu wymaga ręcznej interwencji operatora bazy). To oznaczamy jako
ROADMAP, nie ukrywamy.package_sha256 evidence-package przed/po zmianie jako regresja
integralności. To praktyka operacyjna, nie zastępuje formalnego runbooka DR — zobacz
backup & DR.| Faza | Co to oznacza dla integratora | Status |
|---|---|---|
| Dziś (pre-1.0, controlled pilot) | Brak formalnie ogłoszonej polityki SemVer i deprecation window. Zmiany komunikowane opisowo w
aktualizacjach i release notes.
Endpointy oznaczone LIVE w kontrakcie v1 nie są dziś usuwane bez zapowiedzi, ale nie
jest to jeszcze zobowiązanie kontraktowe — do ustalenia indywidualnie z partnerem pilota. |
stan dziś |
| Po v1.0 (planowana polityka) | Formalny SemVer dla API (MAJOR = breaking, ogłoszony minimalny okres równoległego działania
starej i nowej wersji), jawny changelog kanoniczny per wersja, oznaczenie Deprecated na endpointach
przed usunięciem. Ta polityka jest dziś projektem, nie działającym mechanizmem. |
ROADMAP |
LIVE
ani pola evidence-package „po cichu" w ramach jednego wydania — zmiana o takim charakterze jest odnotowywana w
aktualizacjach. To dyscyplina zespołu, nie jeszcze wyegzekwowany
mechanizm kontraktowy (SLA) — rozróżnienie ważne dla działu prawnego/procurement partnera.
LIVE w status-matrix.package_sha256) na środowisku nieprodukcyjnym.Powiązane: release-notes · roadmap-dev · status-matrix · known-limitations · api-docs · model-danych · deployment-modes.