diff --git a/README.md b/README.md
index 7b5eb3b..f89e48e 100644
--- a/README.md
+++ b/README.md
@@ -10,9 +10,11 @@ migration strategy can be watched instead of slide-decked.
 docker compose up -d --build
 ```
 
-Then open **http://localhost:8080**. That's the only host port published —
-`legacy-backend` and `case-framework` are deliberately unreachable from the
-host (see §4 below).
+Then open **http://localhost:8080** (Session 1's placeholder UI) or
+**http://localhost:8080/portal** (Session 2's Angular portal) — both are
+reachable side by side through the same proxy, for comparison. That's the
+only host port published — `legacy-backend` and `case-framework` are
+deliberately unreachable from the host (see §4 below).
 
 **Memory:** SQL Server (`legacy-db`) needs roughly 2GB of RAM; budget ~6GB
 total for Docker/Podman. First start takes a minute or two while SQL Server
@@ -28,13 +30,22 @@ Verify everything end to end:
 Run this against a **freshly started** stack — it depends on the untouched
 seed data (legacy ids 1001–1012, owned ids `REG-2026-0001..0005`).
 
-## What's built so far (Session 1 — backend)
+## What's built so far
 
-Nine containers: two frontends (one placeholder, see below), three backends,
-three databases, one proxy. `new-frontend` in this session is a deliberately
-plain, unstyled HTML page (`new-frontend/index.html`) that exercises the same
-API a real UI would — it exists to prove the backend before a real Angular
-portal replaces it in Session 2, not to be a good UI.
+**Session 1 — backend.** Ten containers: three frontends, three backends,
+three databases, one proxy. `new-frontend` (reachable at `/`) is a
+deliberately plain, unstyled HTML page (`new-frontend/index.html`) that
+exercises the same API a real UI would — it exists to prove the backend, not
+to be a good UI.
+
+**Session 2 — Angular portal.** `portal-frontend` (reachable at `/portal`) is
+a real Angular application over the same API, kept alongside `new-frontend`
+rather than replacing it, so the two can be compared side by side. It covers
+full functional parity with the placeholder: the worklist, case detail, and
+all four actions (edit applicant details, record assessment, take/release
+ownership) — driven entirely off the API's own `actions`/`seams` blocks in
+each response, never a hardcoded URL. See
+[`portal-frontend/`](portal-frontend) for the app itself.
 
 ## The seams and write paths
 
@@ -100,7 +111,11 @@ work for `LegacyAanvraagMapper` instead of a copy-paste.
 
 ## 10-minute click-through
 
-1. **Werkvoorraad** — `GET /api/worklist` (or the placeholder page at `/`):
+Every step below works identically through the raw API, the Session 1
+placeholder at `/`, or the Session 2 Angular portal at `/portal` — they're
+three windows onto the same backend.
+
+1. **Werkvoorraad** — `GET /api/worklist` (or either frontend's root page):
    17 cases from two databases in one list. Filter `?origin=Legacy` /
    `?origin=Owned` to see which is which.
 2. **`A-1001`** (`GET /api/worklist/legacy/1001`) — all three write paths