diff --git a/README.md b/README.md
index 76713a5..96949df 100644
--- a/README.md
+++ b/README.md
@@ -37,7 +37,7 @@ infra/
   vm/             build.sh, run.sh (QEMU)
 docs/
   architecture.md Component map, IPC, capability table, env vars
-  security.md     Capability model, process isolation, GAP-6 statement
+  security.md     Capability model, process isolation, SpiderMonkey security boundary
   building.md     Build instructions for all targets
 ```
 
@@ -90,11 +90,11 @@ See `docs/security.md`. Key points:
 - WASI filesystem isolation via preopened directories
 - Ed25519 package signing; optional EROFS dm-verity
 - Optional seccomp BPF blocklist in `weft-runtime`
-- SpiderMonkey is not sandbox-isolated beyond process-level isolation (GAP-6; see `docs/security.md`)
+- SpiderMonkey is not sandbox-isolated beyond process-level isolation (see `docs/security.md`)
 
 ## Servo fork
 
 - Repository: `https://github.com/marcoallegretti/servo`, branch `servo-weft`
 - Base revision: `04ca254f`
-- Patches: keyboard input (GAP-1), backdrop-filter stylo (GAP-4)
-- See `crates/weft-servo-shell/SERVO_PIN.md` for full gap status
+- Patches: keyboard input, backdrop-filter in stylo
+- See `crates/weft-servo-shell/SERVO_PIN.md` for Servo integration status and known limitations
diff --git a/crates/weft-servo-shell/SERVO_PIN.md b/crates/weft-servo-shell/SERVO_PIN.md
index 5c0a3f1..d81108e 100644
--- a/crates/weft-servo-shell/SERVO_PIN.md
+++ b/crates/weft-servo-shell/SERVO_PIN.md
@@ -73,11 +73,11 @@ When the EGL path is active Servo presents directly to the EGL surface via
 surfman's `eglSwapBuffers`; the softbuffer blit is skipped. Mesa handles
 DMA-BUF buffer sharing with the compositor transparently.
 
-## Known gaps at this pin
+## Known limitations at this pin
 
-- **GAP-1**: ~~Wayland input events not forwarded to Servo~~ **Resolved** — keyboard and
+- **Wayland input events**: ~~not forwarded to Servo~~ **Resolved** — keyboard and
   mouse events forwarded via `webview.notify_input_event`; key mapping in `keyutils.rs`.
-- **GAP-2**: ~~`ZweftShellWindowV1` created with `surface = null`~~ **Resolved** —
+- **Wayland surface sharing**: ~~`ZweftShellWindowV1` created with `surface = null`~~ **Resolved** —
   `ShellClient::connect_with_display(display_ptr, surface_ptr)` uses
   `Backend::from_foreign_display` to share winit's `wl_display` connection; the winit
   `wl_surface` pointer is passed directly to `create_window`, associating the compositor
@@ -86,8 +86,8 @@ DMA-BUF buffer sharing with the compositor transparently.
   per-frame event dispatch are unchanged.
   Protocol note: `wayland-scanner 0.31` generates `_type` (not `r#type`) for the
   `navigation_gesture` event arg named `type`.
-- **GAP-3**: WebGPU adapter on Mesa may fail CTS — validation task, requires Mesa GPU hardware.
-- **GAP-4**: ~~CSS Grid~~ **Grid resolved** (Taffy-backed, fully wired).
+- **WebGPU on Mesa**: adapter may fail CTS — validation task, requires Mesa GPU hardware.
+- **CSS layout features**: ~~CSS Grid~~ **Grid resolved** (Taffy-backed, fully wired).
   ~~CSS `backdrop-filter` unimplemented~~ **`backdrop-filter` resolved** (servo/servo issue
   [#41567](https://github.com/servo/servo/issues/41567)). Implemented across two commits:
   - `marcoallegretti/stylo` `servo-weft` `f1ba496`: removed `servo_pref = "layout.unimplemented"`
@@ -98,13 +98,13 @@ DMA-BUF buffer sharing with the compositor transparently.
     WebRender stacking-context early-return on `backdrop_filter.0.is_empty()`; `display_list/mod.rs`
     adds `BuilderForBoxFragment::build_backdrop_filter` calling `push_backdrop_filter` before
     background paint.
-- **GAP-5**: ~~Per-app process isolation~~ **Resolved** — each app runs in a separate
+- **Per-app process isolation**: ~~not implemented~~ **Resolved** — each app runs in a separate
   `weft-app-shell` and `weft-runtime` OS process pair supervised by `weft-appd`. OS-level
   isolation does not require Servo's multi-process constellation architecture.
-- **GAP-6**: SpiderMonkey is not sandbox-isolated beyond process-level isolation. JIT-compiled JS
-  runs with the same memory permissions as the Servo process. WEFT relies on SpiderMonkey's own
-  security properties for the JavaScript execution boundary. See `docs/security.md` for the full
-  bounded statement. Not addressed.
+- **SpiderMonkey sandbox**: SpiderMonkey is not sandbox-isolated beyond process-level isolation.
+  JIT-compiled JS runs with the same memory permissions as the Servo process. WEFT relies on
+  SpiderMonkey's own security properties for the JavaScript execution boundary. See
+  `docs/security.md` for the full bounded statement. Not addressed.
 
 ## Update policy
 
diff --git a/docs/security.md b/docs/security.md
index 386ba9c..5fdda69 100644
--- a/docs/security.md
+++ b/docs/security.md
@@ -30,7 +30,7 @@ For verified read-only package storage, `weft-pack build-image` produces an EROF
 
 Each app registers its surface with the compositor via `zweft_shell_manager_v1`. The compositor enforces that each surface belongs to the session that created it. The app cannot render outside its assigned surface slot.
 
-## JavaScript Engine — GAP-6
+## JavaScript Engine (SpiderMonkey)
 
 The Servo embedding uses SpiderMonkey as its JavaScript engine. SpiderMonkey is a complex JIT compiler. The following are known limitations that are not mechanically addressed by WEFT OS at this time:
 
@@ -42,4 +42,4 @@ The Servo embedding uses SpiderMonkey as its JavaScript engine. SpiderMonkey is
 
 **Not addressed:** JIT spraying, speculative execution attacks on SpiderMonkey's JIT output, and parser-level memory corruption bugs. These require either a Wasm-sandboxed JS engine or hardware-enforced control-flow integrity, neither of which is implemented.
 
-This gap (GAP-6) is tracked. The bounded statement is: *WEFT OS relies on SpiderMonkey's own security properties for the JavaScript execution boundary. Any SpiderMonkey CVE that allows code execution within the renderer process is in-scope for the WEFT OS threat model.*
+The bounded statement is: *WEFT OS relies on SpiderMonkey's own security properties for the JavaScript execution boundary. Any SpiderMonkey CVE that allows code execution within the renderer process is in-scope for the WEFT OS threat model.*