diff --git a/PLAN.md b/PLAN.md
index 85c58dd..3ec2e5d 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -199,7 +199,16 @@ GPU instance record содержит стабильные slot/generation; пл
 
 ### P3. Освещение, тени и temporal reconstruction
 
-Расширить local lights, добавить clustered/Forward+ при измеренной необходимости, cascaded sun shadows и ограниченный local shadow atlas. Shadow views имеют собственную видимость и бюджеты.
+**Освещение и тени реализованы до измеренного выбора пути; приёмка этапа ещё
+открыта.** Есть authored directional/point/spot lights, общий shader ABI для
+Direct и P2, четыре каскада солнца, отдельный 16-face atlas для point/spot,
+видимость каскадеров из shadow views и общий бюджет 4096 caster draws.
+Ранжирование 128 local lights, атомарный отказ от шести point faces и
+unshadowed fallback доступны с диагностикой. На Linux reference GPU Release
+1920×1080 измеренный рост стоимости main raster уже превысил порог для
+Forward+, поэтому depth-free tiled путь 16×16 и повторные измерения входят в
+оставшуюся работу. [Протокол проверки](docs/validation/p3-lighting-2026-09-24/README.md)
+отделяет текущий checkpoint от финальной Linux/Windows приёмки.
 
 Затем: previous transforms, motion vectors, jitter, history rejection и TAA; temporal upscaling — после устойчивого TAA. Проверять тонкую геометрию, движение, disocclusion, camera cut и смену разрешения, сравнивать с режимом без temporal. У cache/pass видны затраты и причины обновления.
 
diff --git a/docs/IMPLEMENTATION.md b/docs/IMPLEMENTATION.md
index 2e3ae24..425116f 100644
--- a/docs/IMPLEMENTATION.md
+++ b/docs/IMPLEMENTATION.md
@@ -466,3 +466,48 @@ rendered 120 frames in Direct mode. The corresponding
 [native/manual CI run](https://github.com/emil28092005/Faset_Engine/actions/runs/35922643004)
 passed on Linux and Windows. Unsupported-HZB integration and physical Windows
 GPU coverage remain untested.
+
+## P3 lighting checkpoint — authored lights and bounded shadow views
+
+At source revision `b191ae0`, the versioned `faset.light` schema and SceneView
+extract directional, point, and spot lights. Any authored Light, even disabled,
+suppresses the compatibility sun; scenes without a Light keep their previous
+appearance. The renderer validates all local records, then selects at most 128
+by priority, projected influence, and stable ID. A single typed lighting
+descriptor ABI serves Direct and P2 GPU graphics: materials remain set 0,
+lighting is set 1, GPU scene graphics data moves to set 2, and existing push
+constant sizes remain unchanged. Both paths shade the same sun/local PBR lights
+before tone mapping.
+
+A pure CPU shadow planner builds up to four texel-snapped sun cascades from an
+explicit camera frustum, ending at at most 80 world units; a low-level Snapshot
+without the frustum keeps one shadow view. Shadow caster bounds come from the
+source LOD-0 draw and are tested against the light view, independently of
+camera/P2 culling. The Vulkan backend renders the sun to its own D32 atlas and
+point/spot shadows to a separate 4×4 D32 atlas. A point light claims six faces
+atomically, a spot one. Both atlases try 2048² and then 1024² if required by
+capabilities or allocation. The combined frame budget is 4096 caster draws;
+scheduled tiles are cleared and redrawn each frame. Overflow, disabled shadow,
+or unavailable atlas leaves a submitted light illuminating without shadow.
+There is no hidden sun raster when the sun is absent, its shadow is disabled, or
+the scene only has sprites. Atlas ownership, dropout, submitted light counts,
+actual raster work and GPU timings are exposed in `FrameStats`, Player profiles
+and the optional Editor diagnostics overlay.
+
+The implementation's Linux Debug checkpoint at `a5fb216` built all targets and
+ran 60 CTests with no failures; the existing native window lifecycle test
+skipped under the compositor. The optional ImGui overlay passed its dedicated
+test in an enabled build. After benchmark integration at `b191ae0`, six focused
+tests passed, including the real Vulkan benchmark smoke. These are bounded
+checks, not a final P3 acceptance run. The [lighting validation record](validation/p3-lighting-2026-09-24/README.md)
+lists cases, exact revision, and remaining Windows/Release evidence.
+
+The fixed-scene Release reference-GPU sweep uses 1920×1080, 0/4/16/32/64/128
+lights, Direct/GPU frustum/GPU occlusion, shadows on/off, three independent
+repeats, ten warm-up and thirty measured frames per configuration. It reached
+the agreed Forward+ gate: main-raster overhead at 32 lights was about 0.50 ms
+relative to the matching zero-light case, roughly 30% of that GPU frame;
+64 and 128 lights added about 1.02 and 2.03 ms. Its raw CSV/report are being
+published separately with the exact benchmark revision and driver. A 16×16
+tiled Forward+ path, image parity and before/after build+raster measurement are
+therefore pending. Temporal reconstruction is developed and accepted separately.
diff --git a/docs/manual/editor/diagnostics.md b/docs/manual/editor/diagnostics.md
index 71aba0b..c9706b5 100644
--- a/docs/manual/editor/diagnostics.md
+++ b/docs/manual/editor/diagnostics.md
@@ -16,7 +16,27 @@ The panel reports the previous completed frame: renderer wall time, GPU timestam
 
 In **GPU occlusion** mode, enable **Show HZB** to inspect the current grayscale depth pyramid. The **Mip** slider selects a pyramid level; the preview starts at mip 3 to keep its readback small. A larger mip number shows coarser depth. The preview reads the HZB only while the panel and toggle are open, and only once per completed frame or mip change. Switching it off or closing the panel releases the preview; its GPU texture retires when the next frame begins. Opening diagnostics also enables readback of GPU visibility counters, which is disabled again when the panel closes. Disable the HZB preview for performance comparisons: its diagnostic copy and texture upload add GPU and CPU work. **Freeze counters** does not freeze the HZB image.
 
-The Vulkan backend emits `VK_EXT_debug_utils` labels for `ShadowMap`, `ForwardAndUI`, `Readback`, and, when presenting, `Presentation`. A graphics capture tool that supports this extension can identify those command-buffer regions. Labels remain available without the Khronos validation layer when the extension is exposed; unsupported systems continue rendering and report labels unavailable. A submitted-label count confirms calls were emitted, not that an external capture tool was tested.
+The **Lighting and shadows** section reports the actual local lights submitted
+and omitted, requested/effective sun cascades, requested/rasterized local faces,
+allocated local tiles, and shadow caster draws against the 4096-draw limit.
+Dropped-face counters distinguish a full atlas, caster budget, and unavailable
+atlas; `point` counts faces dropped as a complete six-face group. A light whose
+shadow faces are dropped still illuminates without a shadow. Atlas memory is the
+live explicit Vulkan allocation size for the separate sun and local atlases.
+When GPU timestamps are available, the panel shows sun and local shadow pass
+durations. A zero duration after a disabled sun or sprite-only frame confirms
+that no sun shadow raster ran. The lighting path names the algorithm actually
+used, so compare it with a benchmark's requested mode before interpreting costs.
+See [Lighting](lighting.md) for the 128-light and 16-tile limits.
+
+The Vulkan backend emits `VK_EXT_debug_utils` labels for `SunShadowAtlas`,
+`LocalShadowAtlas`, `ForwardAndUI`, `Readback`, and, when presenting,
+`Presentation`. A fallback frame can have no shadow-raster label. A graphics
+capture tool that supports this extension can identify the command-buffer
+regions. Labels remain available without the Khronos validation layer when
+the extension is exposed; unsupported systems continue rendering and report
+labels unavailable. A submitted-label count confirms calls were emitted, not
+that an external capture tool was tested.
 
 This module is disabled by default and is linked only to the graphical Editor and its dedicated test when enabled. Player and exported games do not link ImGui. No overlay control changes authoring documents, gameplay state or export settings.
 
diff --git a/docs/manual/editor/lighting.md b/docs/manual/editor/lighting.md
index dee215a..f667ac4 100644
--- a/docs/manual/editor/lighting.md
+++ b/docs/manual/editor/lighting.md
@@ -1,37 +1,82 @@
-# Add lights to a 3D scene
+# Light a 3D scene
 
-Add a **Light** component to a scene entity. The entity's transform places a point
-or spot light; its rotation aims a spot light along local negative Z. A directional
-light uses the entity's orientation. Light colors and intensity contribute to the
-mesh's linear PBR illumination before tone mapping. Sprites and UI retain their
-unlit tint.
+Select an entity in the **Scene** tree, choose **+ Add Component** in the
+**Inspector**, and add **Light**. Its Transform places a point or spot light. A
+spot light points along the entity's local negative Z axis; a directional light
+uses the entity's orientation. Lights affect 3D meshes in linear PBR shading
+before tone mapping. Sprites and Editor UI remain unlit.
 
-The version-1 `faset.light` component has three `kind` values:
-
-| Kind | Position and direction | Useful fields |
+| Light kind | Coverage | Shadow cost |
 | --- | --- | --- |
-| `directional` | Direction from the entity transform | `color`, `intensity`, `casts_shadow` |
-| `point` | Position from the entity transform; illuminates every direction | `color`, `intensity`, `range` |
-| `spot` | Position and local negative-Z direction | `color`, `intensity`, `range`, `inner_angle`, `outer_angle` |
+| `directional` | A sun-like direction, independent of position | Up to four cascade tiles |
+| `point` | All directions within `range` | Six local-atlas tiles, assigned together |
+| `spot` | A cone within `range` | One local-atlas tile |
 
-Angles are radians. A spot's inner angle must not exceed its outer angle. Intensity
-must be nonnegative and range positive. `enabled: false` keeps the component in the
-scene without contributing light. The `shadow_priority` integer is reserved for the
-bounded local-shadow scheduler; it does not change brightness.
+The Light component's fields are:
 
-In the current rendering checkpoint, one enabled directional light can cast the
-existing single-map shadow. Point and spot lights illuminate meshes but do not yet
-cast shadows. The [P3 lighting plan](https://github.com/emil28092005/Faset_Engine/blob/main/docs/superpowers/plans/2026-09-24-p3-lighting.md)
-tracks cascades and the bounded local-shadow atlas. A scene with no Light component
-keeps the legacy white sun so older projects retain their appearance. Adding any
-Light component, even a disabled one, turns off that compatibility fallback. If
-several directionals are enabled, Faset chooses the one with the smallest stable
-entity ID and reports a diagnostic for the others.
+| Field | Default | Meaning |
+| --- | --- | --- |
+| `kind` | `directional` | `directional`, `point`, or `spot` |
+| `enabled` | `true` | A disabled light contributes no illumination |
+| `color` | `[1, 1, 1, 1]` | RGB illumination color; alpha is part of the schema color value |
+| `intensity` | `1` | Nonnegative brightness |
+| `range` | `10` | Positive reach of point and spot lights |
+| `inner_angle` | `0.35` | Full-strength spot cone half-angle, in radians |
+| `outer_angle` | `0.7` | Outer spot cone half-angle, in radians; must be at least `inner_angle` |
+| `casts_shadow` | `true` | Allow this light to use its shadow atlas |
+| `shadow_priority` | `0` | Higher local-light selection and shadow priority; does not change brightness |
 
-## Author a point light through MCP
+The Inspector validates the spot angles together. Their allowed outer limit is
+below π/2 radians. A point light does not depend on the entity's rotation.
+After editing the light or Transform, save the scene as usual. [Editor
+workspace](workspace.md) explains Inspector editing, Undo, and save conflicts.
 
-Use `faset_schema` to inspect the current field IDs, then send a `faset_scene_edit`
-batch with the document ID, current revision, and target entity ID. For example:
+## Sun shadows and compatibility
+
+With a 3D scene camera, a shadow-casting directional light uses four cascades
+covering the camera near plane through at most **80 world units**, or the camera
+far plane if it is closer. Faset blends samples near cascade splits and snaps
+each shadow projection to texels to reduce shimmer during small camera moves.
+Objects outside the camera view can still cast into a visible receiver: shadow
+visibility uses each light's view and the source mesh's LOD 0, separately from
+the main camera's Direct or GPU visibility result. A low-level renderer Snapshot
+without an explicit camera frustum uses one compatibility sun view.
+
+Only one enabled directional light is used. If there are several, Faset chooses
+the one with the smallest stable entity ID and reports the ignored lights. A
+scene with **no Light component** retains the older white sun. Adding any Light
+component, including a disabled one, suppresses that compatibility sun. Thus a
+local-only scene does not receive an unexpected directional light.
+
+## Local shadow capacity and fallbacks
+
+The renderer accepts at most **128** local lights per frame. It sorts candidates
+by `shadow_priority` (highest first), then projected influence, then stable ID.
+The `omitted_local_lights` counter reports lights beyond this limit; an omitted
+light contributes no illumination. All authored light records are validated,
+including candidates past the limit.
+
+The separate local shadow atlas has **16 tiles**. A spot consumes one; a point
+consumes six or none. Sun cascades and local shadows share a maximum of **4096
+caster draws** per frame. A light whose shadow group does not fit the remaining
+tiles or draw budget still illuminates, **without a shadow**. Disabling
+`casts_shadow` also keeps illumination while skipping that light's shadow work.
+The renderer reports requested faces, rendered faces, tiles, and drops by cause
+in [Diagnostics](diagnostics.md) and the [Player profile](profiling.md).
+
+Faset uses separate sampled D32 sun and local atlases, normally 2048×2048 pixels
+each. If a device cannot use that size, the renderer tries 1024×1024; if a
+sampled depth atlas cannot be created, the affected lights fall back to unshadowed
+illumination and report unavailable shadow views. Scheduled atlas tiles are
+cleared and redrawn each frame; there is no persistent shadow cache yet.
+Sprite-only scenes, a missing sun, and a sun with `casts_shadow: false` skip sun
+shadow raster work.
+
+## Add a point light through MCP
+
+MCP edits the **Editor document**, not entities in a running game. Use
+`faset_schema` to inspect the current field IDs, then send a `faset_scene_edit`
+batch with the document ID, its current revision, and a target entity ID:
 
 ```json
 {
@@ -46,22 +91,24 @@ batch with the document ID, current revision, and target entity ID. For example:
       "kind": "point",
       "color": [1, 0.15, 0.1, 1],
       "intensity": 8,
-      "range": 6
+      "range": 6,
+      "shadow_priority": 2
     }
   }]
 }
 ```
 
-Move the entity with its Transform component. `component.add` fills any omitted
-light fields from the version-1 schema; use `component.set` for later edits. See
-[MCP and command line](mcp.md) for revision and retry handling.
+Move the entity with its Transform component. `component.add` fills omitted
+fields from the schema; `component.set` changes an existing field. Save the
+document with `faset_document_save`. [MCP and command line](mcp.md) covers
+revisions, retries, and transactions.
 
 ## Supply lights directly from C++
 
-When building a `faset::render::Snapshot` yourself, set
-`authored_lights_present` to suppress the compatibility sun in a local-only scene.
-Provide a stable ID for each light so future shadow scheduling remains independent
-of submission order.
+Code that constructs a renderer `faset::render::Snapshot` can supply lights
+directly. Set `authored_lights_present` even when the only authored Light is
+disabled, so the renderer does not synthesize the compatibility sun. Use stable,
+unique IDs for deterministic capacity decisions:
 
 ```cpp
 faset::render::Snapshot snapshot;
@@ -74,6 +121,7 @@ point.position = {-2, 1.5f, 0};
 point.color = {1, 0.3f, 0.1f, 1};
 point.intensity = 8;
 point.range = 6;
+point.shadow_priority = 2;
 snapshot.local_lights.push_back(point);
 
 faset::render::LocalLight spot;
@@ -88,5 +136,7 @@ spot.range = 9;
 snapshot.local_lights.push_back(spot);
 ```
 
-The renderer submits at most 128 local lights per frame in stable-ID order. Later
-P3 work adds explicit overflow diagnostics and measured light-list optimization.
+This is the **renderer Snapshot API**, not a gameplay `Update()` method. The
+current gameplay scripting API does not expose live Light-component creation or
+modification; author lights in the Inspector or through Editor MCP. See
+[Gameplay scripting](../scripting/index.md) for the APIs available to game code.
diff --git a/docs/manual/editor/profiling.md b/docs/manual/editor/profiling.md
index 8180efc..fc19f69 100644
--- a/docs/manual/editor/profiling.md
+++ b/docs/manual/editor/profiling.md
@@ -118,13 +118,59 @@ and reads back the full image, so `cpu_ms` is wall time including waits, not CPU
 utilization. An open scene can run slower with HZB; visibility correctness and
 full-frame speed are separate findings.
 
+## Measure P3 lighting and shadows
+
+A Player `--profile` sample includes `effective_lighting_path`, local lights
+submitted/omitted, requested/effective sun cascades, requested/rasterized local
+shadow faces, tile use, shadow drop reasons, caster draws, and explicit atlas
+allocation bytes. `gpu_main_raster_ms`, `gpu_sun_shadow_ms`, and
+`gpu_local_shadow_ms` are GPU timestamps or `null` when timestamps are
+unavailable. A light can illuminate while its shadow faces are dropped. A
+submitted-light count of zero is a different workload from 128 lights whose
+shadows are disabled. See [Lighting](lighting.md) for the capacity policy and
+[Diagnostics](diagnostics.md) for the Editor counters.
+
+The fixed-scene benchmark compares 0, 4, 16, 32, 64, and 128 local lights under
+Direct, GPU frustum, and GPU occlusion visibility, with shadows on and off. Its
+wrapper runs three independent 1920×1080 repetitions per configuration, each
+with ten warm-up and thirty recorded frames. First inspect the planned matrix:
+
+```sh
+python3 tools/benchmark_p3_lighting.py --list-runs
+```
+
+From the repository, after a Linux Release renderer build, run one shadow setting
+into a new output directory. Supply the actual device driver identity:
+
+```sh
+python3 tools/benchmark_p3_lighting.py --sweep \
+  --executable build/linux-release/faset_p3_lighting_benchmark \
+  --output .cache/p3-lighting-off \
+  --shadows off --driver 'REPLACE_WITH_ACTUAL_DRIVER' --validation off
+```
+
+The wrapper writes one raw CSV per run, `merged.csv`, and `summary.json`. Keep
+all three with the exact source revision and device. It checks that every run
+used its requested visibility mode and submitted every requested light. GPU
+timestamps for the main raster isolate fragment-heavy lighting better than
+renderer wall time, which includes GPU waits and synchronous readback. Shadow
+time is split into sun and local GPU durations. The Forward+ decision compares
+the median of three run medians against the matching zero-light configuration;
+the threshold is **1.0 ms extra main raster time or 15% of the zero-light GPU
+frame** at 32, 64, or 128 lights on the Linux physical reference GPU. The
+[P3 lighting validation record](https://github.com/emil28092005/Faset_Engine/blob/main/docs/validation/p3-lighting-2026-09-24/README.md)
+states the measured decision and scope. A software Vulkan run checks
+functionality, not physical GPU performance.
+
 ## Current performance scope
 
 The accepted MVP path uses direct draws and CPU culling; P2 adds optional GPU
 visibility for opaque static meshes, with prepared LODs supplied by the project.
-Both paths currently use one graphics queue and synchronous full-image
-capture/readback. Use measurements to find the next bottleneck before introducing
-parallel jobs or expanding GPU-driven rendering. Neither an offscreen capture
-benchmark nor a tiny demo is a promise of a production frame budget. Observed
-measurements and follow-up targets belong in the implementation acceptance report
-with their source revision and method.
+P3 adds local lights and bounded sun/local shadow atlases. The benchmark's
+`lighting_path` and a Player profile's `effective_lighting_path` identify the
+algorithm actually used. Both paths currently use one graphics queue and
+synchronous full-image capture/readback. Use measurements to find the next
+bottleneck before introducing parallel jobs or expanding GPU-driven rendering.
+Neither an offscreen capture benchmark nor a tiny demo is a promise of a
+production frame budget. Observed measurements and follow-up targets belong in
+the implementation acceptance report with their source revision and method.
diff --git a/docs/validation/README.md b/docs/validation/README.md
index 76be397..fd42aec 100644
--- a/docs/validation/README.md
+++ b/docs/validation/README.md
@@ -5,6 +5,7 @@ These files preserve bounded checks and their inputs. Each record states its sou
 - [MVP acceptance dossier](mvp-acceptance.md): criterion-by-criterion closure, tested revisions and remaining compatibility coverage.
 - [P2 GPU visibility Linux evidence](p2-gpu-visibility-2026-09-23/README.md): Debug/Release GPU acceptance, lavapipe functional checks, relocated Player exports, and explicit platform/performance limits.
 - [P2 pinned SwiftShader compatibility](p2-swiftshader-2026-09-23/README.md): the Windows CI regression, shader capability fix, independent review closure, final native CI and relocated Player evidence.
+- [P3 lighting and shadows](p3-lighting-2026-09-24/README.md): implementation, acceptance matrix, bounded evidence, and remaining Forward+/platform checks; temporal reconstruction is tracked separately.
 - [Windows software Vulkan](windows-software-vulkan-2026-09-18/README.md): fresh native build, 35 tests, launcher/window/MCP workflows and both relocated Release games on SwiftShader.
 - [Checkpoint 5 Linux acceptance](checkpoint5-linux-2026-09-18/README.md): clean offline source build, first Editor launch, exact-candidate standalone games and live Blender checks.
 - [Final Linux source checks](final-linux-2026-09-18/README.md): `4cb8255` integrated test results and both Release games after the asset-relocation correction, including package manifests and standalone captures.
diff --git a/docs/validation/p3-lighting-2026-09-24/README.md b/docs/validation/p3-lighting-2026-09-24/README.md
new file mode 100644
index 0000000..4d31a26
--- /dev/null
+++ b/docs/validation/p3-lighting-2026-09-24/README.md
@@ -0,0 +1,98 @@
+# P3 lighting and shadows — acceptance record
+
+This record tracks P3 lighting separately from temporal reconstruction. The
+implementation checkpoint is source revision
+`b191ae0bed77a1544a49504b9a3f07e9a3c691f2` on `feat/p3-lighting`. The
+Manual/record edit itself is documentation-only. A later Forward+ change and
+its measurements require a new revision and validation entry before the lighting
+slice can be called complete. Temporal reconstruction has its own acceptance.
+
+## Implemented at the checkpoint
+
+- Authored directional, point, and spot lights are extracted from the same
+  versioned Light schema used by the Inspector and MCP. No authored Light
+  component retains the legacy sun; any authored Light, including disabled or
+  local-only, suppresses that fallback.
+- Direct, GPU frustum, and GPU occlusion graphics paths use the same typed
+  lighting data. Material descriptors remain set 0, lighting set 1, and GPU
+  graphics scene data set 2. Sun and local light contributions accumulate before
+  tone mapping. Sprites and UI remain unlit.
+- Four texel-snapped sun cascades cover up to 80 world units for an explicit
+  camera frustum. A low-level Snapshot without one keeps a single sun view.
+  Shadow caster selection uses each light view and source LOD 0, independent of
+  camera visibility and prepared camera LOD. Missing/disabled sun and sprite-only
+  scenes skip sun shadow raster.
+- The separate D32 local atlas admits 16 faces, one per spot or six atomically
+  per point. Both shadow systems share a 4096-caster-draw frame budget. Up to 128
+  local lights are submitted by priority, projected influence, then stable ID.
+  Overflow or unsupported-atlas lights remain unshadowed when submitted; omitted
+  lights beyond 128 do not illuminate. Both atlases try 2048², then 1024².
+- The editor overlay and Player profile expose actual submitted/omitted lights,
+  requested/effective views, drop reasons, atlas bytes, caster draws, GPU shadow
+  durations, and the effective lighting path. Shadow tiles are redrawn every
+  frame; no persistent depth cache is claimed.
+
+## Acceptance matrix
+
+| Case | Automated evidence | Current status |
+| --- | --- | --- |
+| Empty, disabled, local-only, multiple sun; schema bounds | `scene_view`, `render_lighting_policy`, `render_offscreen` | Covered by Debug tests at the implementation checkpoint; re-run on final revision |
+| Four cascades, split bounds, subtexel stabilization, offscreen/source-LOD0 caster | `render_lighting_policy`, `render_lighting_sun` | Covered by CPU policy and Linux Vulkan image tests; final-revision runs pending |
+| Spot cone, six point faces and seam, dropped whole point shadow | `render_lighting_local`, `render_lighting_policy` | Covered by Linux Vulkan image and CPU tests; final-revision runs pending |
+| 128-light/16-face/4096-draw limits, unsupported-atlas fallback | `render_lighting_policy`, `render_offscreen`, `render_lighting_local` | CPU and supported-atlas GPU paths covered; actual unsupported Vulkan device not tested |
+| Direct/GPU frustum/GPU occlusion image parity, P2 reload and 2D/UI independence | `render_lighting_sun`, `render_lighting_local`, `render_shader_reload`, `render_offscreen` | Linux supported-driver paths covered; final-revision runs pending |
+| Driver, profile, real 64×64 benchmark smoke | `render_lighting_benchmark_schema`, `render_lighting_benchmark_smoke`, `player_shutdown_diagnostics` | Focused integration tests passed on `b191ae0`; full raw log pending |
+| 1920×1080 0/4/16/32/64/128 Release sweep, three repeats, both shadow states | `tools/benchmark_p3_lighting.py --sweep` | Baseline measured on Linux physical GPU; raw CSV and post-Forward+ comparison pending publication |
+| Windows native build, pinned SwiftShader GPU tests, relocated Release 2D/3D Players | `windows-graphics.yml`, `ci.yml` | New P3 revision has not yet completed Windows CI |
+
+The supported-atlas GPU tests create a renderer with validation requested and
+assert zero reported Vulkan errors; a test result is a validation-layer pass only
+when the layer was actually active. `render_window_lifecycle` can skip if the
+Linux compositor declines programmatic restore. The Windows workflow uses pinned
+SwiftShader, not a physical Windows GPU, and may lack the Khronos layer. Linux
+reference-GPU results cannot establish physical Windows performance.
+
+## Reproduction and retained evidence
+
+The P3 CTest registrations are `render_lighting_policy` and
+`render_lighting_benchmark_schema` (CPU), plus `render_lighting_sun`,
+`render_lighting_local`, and `render_lighting_benchmark_smoke` (labelled
+`gpu;p3`). Use `ctest --test-dir build/linux-debug -N -L p3` to confirm those
+five cases exist before running them; an empty test selection is not a pass.
+The Windows full graphics job runs all registered tests, while the native
+Windows CPU job uses `-LE gpu` and therefore excludes the three Vulkan cases.
+
+On the Linux host at `b191ae0`, the [CTest inventory](linux-debug-p3-inventory.txt)
+listed all five cases. The [CPU-only P3 run](linux-debug-cpu-ctest.txt) passed
+`render_lighting_policy` and `render_lighting_benchmark_schema` 2/2 with zero
+failures. The [strict MkDocs build](strict-mkdocs.txt) passed for these Manual
+changes. This run deliberately excluded Vulkan tests while the 1920×1080
+physical-GPU baseline was being measured, so it is not a final GPU acceptance
+result. The local host was Linux x86_64, kernel 7.0.0-31-generic; the source
+checkout had documentation changes only during these checks.
+
+```sh
+cmake --build --preset linux-debug --parallel 2
+ctest --test-dir build/linux-debug -L p3 --no-tests=error --output-on-failure
+ctest --test-dir build/linux-debug --output-on-failure
+cmake --build --preset linux-release --parallel 2
+ctest --test-dir build/linux-release --output-on-failure
+```
+
+The benchmark wrapper retains one raw CSV per run, a merged CSV, and a summary.
+It rejects visibility fallback, missing GPU timestamps, missing lights, duplicate
+frames, and validation errors. An offscreen capture's `cpu_ms` includes GPU wait
+and readback; it is not thread CPU time. The exact Release benchmark revision,
+driver, CSV paths, before/after Forward+ gate, Linux SwiftShader results, final
+Debug/Release CTest logs, and Windows Actions links will be added after those
+checks run. Do not use this provisional record as a P3 completion claim.
+
+## Limits carried forward
+
+The current checkpoint scans all submitted lights in each mesh fragment; the
+measured Forward+ threshold was reached on the Linux reference GPU, so a bounded
+tiled path is in progress. Transparent/game UI and sprites keep their existing
+ordering and unlit behavior. The atlas caps are fixed budgets, not adaptive
+quality settings, and shadow depth is redrawn each frame. The renderer still
+performs synchronous framebuffer readback. No broad scene/driver matrix or
+physical Windows GPU performance claim follows from these fixtures.
diff --git a/docs/validation/p3-lighting-2026-09-24/linux-debug-cpu-ctest.txt b/docs/validation/p3-lighting-2026-09-24/linux-debug-cpu-ctest.txt
new file mode 100644
index 0000000..e1c61cf
--- /dev/null
+++ b/docs/validation/p3-lighting-2026-09-24/linux-debug-cpu-ctest.txt
@@ -0,0 +1,12 @@
+Test project /home/emil/Desktop/.worktrees/Faset_Engine-p3-lighting/build/linux-debug
+    Start  9: render_lighting_policy
+1/2 Test  #9: render_lighting_policy .............   Passed    0.04 sec
+    Start 17: render_lighting_benchmark_schema
+2/2 Test #17: render_lighting_benchmark_schema ...   Passed    4.95 sec
+
+100% tests passed, 0 tests failed out of 2
+
+Label Time Summary:
+p3    =   4.99 sec*proc (2 tests)
+
+Total Test time (real) =   5.00 sec
diff --git a/docs/validation/p3-lighting-2026-09-24/linux-debug-p3-inventory.txt b/docs/validation/p3-lighting-2026-09-24/linux-debug-p3-inventory.txt
new file mode 100644
index 0000000..a6b05e0
--- /dev/null
+++ b/docs/validation/p3-lighting-2026-09-24/linux-debug-p3-inventory.txt
@@ -0,0 +1,8 @@
+Test project /home/emil/Desktop/.worktrees/Faset_Engine-p3-lighting/build/linux-debug
+  Test  #7: render_lighting_sun
+  Test  #8: render_lighting_local
+  Test  #9: render_lighting_policy
+  Test #17: render_lighting_benchmark_schema
+  Test #18: render_lighting_benchmark_smoke
+
+Total Tests: 5
diff --git a/docs/validation/p3-lighting-2026-09-24/strict-mkdocs.txt b/docs/validation/p3-lighting-2026-09-24/strict-mkdocs.txt
new file mode 100644
index 0000000..af3ccf2
--- /dev/null
+++ b/docs/validation/p3-lighting-2026-09-24/strict-mkdocs.txt
@@ -0,0 +1,20 @@
+warning: An executable named `mkdocs` is not provided by package `mkdocs-material` but is available via the dependency `mkdocs`. Consider using `uvx --from mkdocs mkdocs` instead.
+
+ │  ⚠  Warning from the Material for MkDocs team
+ │
+ │  MkDocs 2.0, the underlying framework of Material for MkDocs,
+ │  will introduce backward-incompatible changes, including:
+ │
+ │  × All plugins will stop working – the plugin system has been removed
+ │  × All theme overrides will break – the theming system has been rewritten
+ │  × No migration path exists – existing projects cannot be upgraded
+ │  × Closed contribution model – community members can't report bugs
+ │  × Currently unlicensed – unsuitable for production use
+ │
+ │  Our full analysis:
+ │
+ │  https://squidfunk.github.io/mkdocs-material/blog/2026/02/18/mkdocs-2.0/
+
+INFO    -  Cleaning site directory
+INFO    -  Building documentation to directory: /home/emil/Desktop/.worktrees/Faset_Engine-p3-lighting/build/manual
+INFO    -  Documentation built in 0.84 seconds