diff --git a/NEXT_STEPS.md b/NEXT_STEPS.md
index 0996a17..c882b29 100644
--- a/NEXT_STEPS.md
+++ b/NEXT_STEPS.md
@@ -13,22 +13,25 @@ product-ready.
    and hands fetched file details to `StreamInstallGame` instead of the normal
    download command.
 
-2. **Replace per-file `unrar p` with a final archive provider**
+2. **Done — Replace per-file `unrar p` with a final archive provider**
 
-   The prototype provider is intentionally simple: `unrar lt`, then `unrar p`
-   per file. Good for non-solid archives, bad for solid archives. Final shape
-   should be a one-pass provider with real entry boundaries, likely via libunrar
-   or a purpose-built wrapper.
+   The shared external `unrar` stream provider now runs `unrar lt` once for the
+   archive metadata and one sequential `unrar p` pass per archive for payload
+   bytes. It frames directories, file starts, file chunks, and file ends from
+   the technical listing, so CLI and GUI callers use one purpose-built provider
+   instead of a per-file extraction loop.
 
 3. **Handle solid archives deliberately**
 
-   Add archive inspection that decides:
+   The provider exposes the RAR `solid` flag in `ArchiveBegin`; the remaining
+   work is to make that flag a tested policy decision instead of an incidental
+   stream attribute. Add archive inspection that decides:
 
-   - non-solid: per-file streaming is fine
-   - solid: one sequential archive pass only
+   - non-solid: current one-pass streaming is fine
+   - solid: prove and enforce one sequential archive pass only
 
-   This is the big architectural fork we discussed, and the prototype’s
-   provider is the thing to swap.
+   This is the big architectural fork we discussed: keep non-solid and solid
+   archive handling explicit in the provider contract and scenario coverage.
 
 4. **Decide the integrity model**