Wisienka #8. Zamiast wierzyć na słowo, że finding „został naprawiony", porównujemy dwa
evidence-package tego samego incydentu — sprzed retestu (T0) i po retescie (T1) — i pokazujemy różnicę: co się
zmieniło w severity, w statusie dowodu, w statusie działania i — kluczowe — w package_sha256. Zmiana
hasha jest dowodem, że pakiet faktycznie odzwierciedla nowy stan, nie tylko zmienioną etykietkę.
/retest-diff. To, co jest realne: GET /reports/evidence-package/:id
(§F2, patrz API Explorer) zwraca za każdym razem świeży package_sha256
liczony z aktualnego stanu incydentu w PostgreSQL. Wywołanie go dwa razy — przed i po retescie — i ręczne (lub
narzędziem /verify) porównanie dwóch pakietów jest już dziś możliwe i dowodliwe,
bo pole package_sha256 jest realnym hashem realnych danych. Nie ma jeszcze: gotowego widoku diff
side-by-side w panelu, ani zapisanej pary snapshotów T0/T1 jako jednego obiektu. To jest ROADMAP.
Jeśli ktoś twierdzi „naprawione", a package_sha256 pakietu incydentu jest identyczny jak przed retestem —
to sygnał, że nic w rekordzie faktycznie się nie zmieniło (albo zmiana nie została zapisana w systemie). Diff nie
ocenia jakości naprawy — ocenia, czy pakiet dowodowy naprawę odzwierciedla.
package_sha256 na żądanie LIVEGET /reports/evidence-package/:id liczy hash kanonicznego JSON przy każdym wywołaniu, z bieżącego
stanu incydentu/evidence w PostgreSQL — nie z cache. Dwa wywołania w różnym czasie dają porównywalne migawki.
Zanim porównasz T0 z T1, możesz osobno zweryfikować każdy pakiet narzędziem /verify (SHA-256 liczony lokalnie w przeglądarce) — potwierdzasz, że żaden z dwóch pakietów nie został zmieniony po pobraniu.
incident.severity, incident.response_status, incident.evidence_status,
manifest.confirmed_evidence/signal_only i audit_trail są realnymi polami
zwracanymi przez API — to surowiec do diffu, dostępny bez dodatkowego kodu.
Poniżej ilustracja formatu na przykładowym incydencie demo. Wartości demonstracyjne, nie stan realnej infrastruktury.
Severity: P1
Status działania: open
Status dowodu: MEDIA_SIGNAL
confirmed_evidence: 0 · signal_only: 1
Severity: P2 obniżona
Status działania: verified
Status dowodu: CONFIRMED
confirmed_evidence: 1 · signal_only: 0
Wartości hex to placeholdery demonstracyjne (format), nie realne skróty z produkcji.
| Pole | T0 (przed) | T1 (po) | Co dowodzi zmiana |
|---|---|---|---|
incident.severity | np. P1 | np. P2 lub bez zmian | Czy ryzyko zostało formalnie przeklasyfikowane — nie tylko „naprawione ustnie". |
incident.response_status | open / in_progress | verified / closed | Przejście stanu działania (patrz maszyna stanów na /response-retest). |
incident.evidence_status | MEDIA_SIGNAL / GAP | CONFIRMED | Zgodnie z regułą zamknięcia: brak treści dowodu = UNVERIFIED, nie automatyczny CONFIRMED. |
manifest.confirmed_evidence / signal_only | np. 0 / 1 | np. 1 / 0 | Liczbowy skrót manifestu — ile artefaktów ma twardy dowód vs. sam sygnał narzędzia. |
audit_trail (długość/ostatni wpis) | N wpisów | N+k wpisów | Czy retest/zamknięcie zostawiło ślad audytowy — bez wpisu w audit_trail zmiana jest niewidoczna dla audytora. |
package_sha256 | hash A | hash B ≠ A | Dowód integralności całości: jeśli którekolwiek z powyższych pól się zmieniło, hash musi się zmienić. Ten sam hash przy deklarowanej zmianie = sygnał ostrzegawczy. |
# T0 — przed retestem (operator/analyst/auditor/admin, JWT wymagany) curl -H "Authorization: Bearer $TOKEN" \ https://k0nsult.cloud/api/ip3/v1/reports/evidence-package/IP3-DEMO-0001 > pkg_t0.json # ... retest, dowod naprawy, aktualizacja statusu w systemie ... # T1 — po retescie, ten sam incydent curl -H "Authorization: Bearer $TOKEN" \ https://k0nsult.cloud/api/ip3/v1/reports/evidence-package/IP3-DEMO-0001 > pkg_t1.json # porownanie pol + hashy (dowolne narzedzie diff, lub /verify dla kazdego z osobna) diff <(jq -S . pkg_t0.json) <(jq -S . pkg_t1.json)
To jest dziś realna ścieżka — reuse istniejącego endpointu, bez nowego kodu. Ograniczenie: trzeba ręcznie zachować obie migawki i ręcznie je zestawić. Właśnie to domyka ROADMAP poniżej.
/incidents/:id/retest-diff ROADMAPSerwer sam przechowuje snapshot T0 (w momencie oznaczenia REMEDIATED) i T1 (w momencie VERIFIED) i zwraca gotowy obiekt diff — bez ręcznego zestawiania dwóch osobnych wywołań.
Panel z dwiema kolumnami (przed/po), podświetlonymi różnicami pól i wizualnym wskaźnikiem zmiany hasha — odpowiednik przykładu wyżej, ale generowany automatycznie z danych, nie ręcznie.
Automatyczna flaga, gdy status działania przechodzi w VERIFIED/CLOSED, a package_sha256 nie zmienił
się względem ostatniego snapshotu — sygnał, że deklarowana naprawa nie ma odzwierciedlenia w danych.
Powiązane: reguła zamknięcia i maszyna stanów działania → /response-retest · weryfikacja integralności pojedynczego pakietu → /verify · KPI pokrycia dowodowego → /coverage-score · pełna roadmapa z dowodami → /roadmap-dev · macierz statusów → /status-matrix.