# Validation record and Windows pilot checklist

Build date: September 7, 2026. Development environment: Linux, Node.js and headless Chromium through Playwright.

## Version 1.0.5 startup repair

On a hosted/offline page, the revised UI downloads a self-contained `Run_Studio.cmd`; on the local helper page the control becomes `Check connection`. The launcher embeds the helper and local HTML, extracts them under the user profile, and starts Windows PowerShell with process-only `-ExecutionPolicy Bypass`. It does not change persistent execution policy and does not override Group Policy. Consent is displayed before native-wrapper compilation. Windows PowerShell 5.1 or PowerShell 7 compilation explicitly references System.dll, System.Core.dll and System.Xml.dll; the preflight does the same. PowerShell 6+ keeps its default reference set. An automatic-browser launch failure is caught and does not terminate the listener.

Checks rerun after the repair: all 18 parser tests; the original browser UI suite (including 23 navigation pages); extended browser regression tests; and a new synthetic startup suite. The startup suite covers static-page instructions with no API call, missing tokens, mocked successful metadata/token headers, simulated refresh, rejected sessions, unreachable helpers, malformed helper responses, unavailable session storage, mobile layout and embedded-helper/launcher byte equality. No uncaught page errors were observed.

A direct loopback-navigation test was attempted but blocked by the managed development browser with ERR_BLOCKED_BY_ADMINISTRATOR. Startup tests therefore substitute browser location/storage/history and fetch ONLY in a temporary in-memory test copy. This does not modify the delivered HTML. It is not an actual HTTP, Windows PowerShell, native compilation, Windows browser-launch, or real registry test. None of those Windows-specific runtime checks have been executed here.

Run the supplied Windows preflight and pilot on the intended image. For startup failures, preserve the displayed console error; do not share session-token URLs or evidence exports as diagnostics.

## Completed checks

- JavaScript syntax checks passed for `parsers.js` and `app.js`.
- **18 synthetic parser regression tests passed.** They cover fixture counts, modern/legacy UserAssist, BAM/DAM SID attribution, profile/logon SID preservation, FILETIME, FAT date/time word order, ShellBag volume/directory reconstruction, unsupported shell items, modern ShimCache semantics and malformed lengths, REG string/integer/binary import, deletion directives, malformed hex, CSV formula-like values, HTML escaping, base64/hex preservation and NetworkList local/unspecified dates.
- All **23 navigation pages** rendered in the browser harness without uncaught JavaScript errors.
- Browser checks covered search, artifact filtering, source-key navigation, row inspection, finding notes, case information, CSV/JSON/HTML downloads and full JSON re-import with findings preserved.
- Extended checks covered registry-column sorting, BAM user labels, invalid-base64 import rejection before replacing evidence, escaped hostile evidence strings in the UI/report, full CSV fields and UTF-16LE REG import with a maximum unsigned QWORD preserved as a decimal string.
- Collection, source-key fetching and branch traversal were tested against **explicitly simulated API responses**. These checks exercise the browser workflow, not Windows API correctness.
- All navigation pages were checked at a 390-pixel viewport without document-level horizontal overflow. Large tables intentionally scroll inside their own containers.
- Desktop overview and ShellBags screens were visually inspected. This does not substitute for accessibility testing with assistive technology.

The browser harness loaded the self-contained HTML using Playwright `set_content`: the managed development browser blocked direct file/localhost navigation. It did **not** exercise a real local HTTP session, Windows PowerShell, native API calls, endpoint security policies or a Windows browser. Web Crypto availability is environment dependent and is labeled by the application. Independent artifact-source validation and native field validation remain necessary.

## Not executed here

`Registry_Collector.ps1` and `Validate_On_Windows.ps1` have **not** run on Windows in this environment. Their PowerShell/native compilation, registry permissions, WLAN/session APIs, real event log retrieval, local HTTP authentication flow and live deployment behavior must be checked on the target image. Do not describe the package as production-validated or as covering every Windows version.

## Pilot on an approved Windows classroom machine

1. Use a disposable/approved lab machine, document its Windows build and the account used, and review the scripts. Check that the organization permits full-language PowerShell and the helper's native wrapper.
2. From Windows PowerShell in the extracted folder, run `./Validate_On_Windows.ps1`. Record syntax/compilation results, the known-key read, expected missing-key behavior and any WLAN/WTS warnings.
3. Run `Run_Studio.cmd`, type `YES`, and confirm that only the local page opens. Verify that the displayed user/SID and computer name match the intended subject.
4. Collect only system configuration and UserAssist first. Compare a small sample of displayed names, raw values and key paths with a read-only source inspection. Record inaccessible and missing items instead of treating them as negative findings.
5. Repeat with the other artifact groups and supporting inventory. Compare current sessions to the lab's session state, Wi-Fi profile identifiers to the lab's known profiles, and application registrations to their actual source keys. Do not use password-export options during comparison.
6. On the authorized lab image, request Security events and compare a small sample of event IDs, record IDs, UTC times and logon types with Event Viewer. Verify that absent auditing, insufficient privileges or no matching records is visibly reported.
7. Navigate a known branch in both requested registry views. Capture a small branch and confirm child-key coverage. Exercise a deliberately low whole-root key cap, stop/continue, and examine the resulting coverage record.
8. Export JSON, CSV and HTML. Verify that the HTML is static, that case notes and raw evidence are present, and that JSON re-import reconstructs the acquired dataset. Compare a computed SHA-256 against the sidecar when a hash was produced.
9. Stop the helper and confirm that new live reads are unavailable while already acquired data remains exportable. Restart it and check that a new session token is used.
10. Validate any evidentiary interpretation independently with trusted tools and the original artifacts. Preserve discrepancies and the exact Windows build in the class notes before broad rollout.

## Developer test commands

Ordinary students do not need these development tools.

```text
node --check parsers.js
node --check app.js
node test_parsers.cjs
python build.py
python test_browser_ui.py
python test_browser_extended.py
python test_startup_ui.py
```

The browser tests require the Python Playwright package and an installed Chromium-family browser. Set `STUDIO_BROWSER` to the executable path when automatic detection is insufficient. They use synthetic data and temporary output files, not a real Windows collector. A supported Python version with asyncio and pathlib is required for these optional developer scripts.
