# FC01 `heap_4` — stan weryfikacji

## Stan na 2026-07-20

Karta ma jeden centralny eksperyment na niezmodyfikowanym
`heap_4.c` z FreeRTOS-Kernel V11.3.0. Przebieg jest podzielony na osiem
deterministycznych checkpointów E01–E08 i działa na RV32I/Hazard3.

## Potwierdzone na Hazard3

| Event | Stan | Dowód |
|---|---|---|
| E01 | arena po inicjalizacji | `free=largest=4080`, 1 blok |
| E02 | `alloc A(24)` | zużyto 48, zostało 4032 |
| E03 | `alloc B(40)` | zużyto 64, zostało 3968 |
| E04 | `alloc C(16)` | zużyto 32, zostało 3936 |
| E05 | `free(A)` | 3984, 2 wolne bloki |
| E06 | `free(C)` | 4016, 2 bloki, `free > largest` |
| E07 | `free(B)` | `free=largest=4080`, 1 blok |
| E08 | kontrolowany OOM | `NULL`, hook=1, asserts=0, PASS=1 |

Na RV32 `sizeof(BlockLink_t) == 8`, ale `portBYTE_ALIGNMENT == 16`, więc
prywatne `xHeapStructSize == 16`. To wyjaśnia zużycie 48/64/32 bajtów.

## Diagramy i iteracja

- A1 CONTEXT: pięć kroków CODE — granice odpowiedzialności.
- A2 STRUCTURE: jeden krok CODE i pięć kroków RUN — nagłówek, split,
  lista adresowa oraz scalenie lewego i prawego sąsiada.
- A5 FLOW: osiem kroków RUN mapowanych 1:1 na E01–E08.
- A6 STATE: pięć reprezentatywnych stanów E01, E04, E06, E07 i E08.
- A7 RUNTIME: tożsamość źródła/ELF, pamięć `ucHeap` i końcowy werdykt.
- A3, A4 i A8 są jawnie pominięte, ponieważ dublowałyby A2/A5.

Szczegółowa kolejność komend, obserwacji i kryteriów znajduje się w
[`hazard3-iteration-plan.md`](hazard3-iteration-plan.md).

## Wykonane testy

- testy hostowe Task 1–3;
- budowa RV32I i kontrola symboli ELF;
- Hazard3 RTL: zakończenie kodem 0 po 27308 cyklach;
- osiem checkpointów obecnych w ELF;
- walidacja JSON i odwołań `code_ref`/`snapshot_ref`;
- kontrola PlantUML, SVG, HTML, TeX i siedmiostronicowego PDF;
- TypeScript/React typecheck generatora.

## Pozostaje poza zakresem tej iteracji

- próba na fizycznym RP2350/Pico 2 W;
- commit i publikacja — wymagają osobnego polecenia.