ImpTune/.planning/phases/10-real-world-runtime-validation/10-01-preflight-package-and-scaffold-PLAN.md

phase, plan, type, wave, depends_on, files_modified, autonomous, requirements, must_haves

phase	plan	type	wave	depends_on	files_modified	autonomous	requirements	must_haves
10-real-world-runtime-validation	01	execute	1		.planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md .planning/phases/10-real-world-runtime-validation/evidence/.gitkeep	false	RTVAL-05	truths artifacts key_links A real .intunewin package generated by the current ImpTune build exists on disk and its SHA256 is recorded A RUNTIME-VALIDATION.md scaffold exists with tenant, device, OS build, and driver vendor fields ready to fill An evidence/ folder exists under the phase directory for screenshots and logs path provides contains .planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md Scaffolded evidence report with metadata table and empty result sections ## Tenant & Environment path provides .planning/phases/10-real-world-runtime-validation/evidence/.gitkeep Evidence folder placeholder so git tracks the directory from to via pattern imptune package export UI RUNTIME-VALIDATION.md metadata technician records printer name, driver vendor, SHA256, build commit Package SHA256:.*[a-f0-9]{64}

Produce the artifact under test and the evidence scaffold before any real-world testing begins.

Purpose: You cannot validate what you did not generate. Lock the exact commit, package, and metadata that will be sent to the tenant so the final report is reproducible. Output: A real .intunewin package generated by the running ImpTune instance and a RUNTIME-VALIDATION.md scaffold with all environment fields waiting to be filled in.

<execution_context> @C:/Users/SebastienQUEROL/.claude/get-shit-done/workflows/execute-plan.md @C:/Users/SebastienQUEROL/.claude/get-shit-done/templates/summary.md </execution_context>

@.planning/PROJECT.md @.planning/ROADMAP.md @.planning/STATE.md @.planning/REQUIREMENTS.md Task 1: Scaffold RUNTIME-VALIDATION.md and evidence folder .planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md, .planning/phases/10-real-world-runtime-validation/evidence/.gitkeep Create `RUNTIME-VALIDATION.md` under the phase directory with the following sections (empty values to be filled by technician in later tasks):

# Runtime Validation Report — ImpTune v1.1

**Status:** DRAFT (in progress)
**Started:** <YYYY-MM-DD>
**Signed off by:** <name>
**Signed off date:** <YYYY-MM-DD>

## Tenant & Environment
| Field | Value |
|-------|-------|
| Intune tenant (domain) | |
| Test device hostname | |
| Windows OS build | |
| Device is Intune-managed | yes / no |
| Driver vendor(s) tested | |
| ImpTune commit SHA | |
| Package file name | |
| Package SHA256 | |
| Generated at | |

## RTVAL-01 — Tenant ingestion
Status: PENDING
Evidence: (screenshot path)
Notes:

## RTVAL-02 — Install under SYSTEM (pnputil + $PSScriptRoot)
Status: PENDING
Evidence: (IntuneManagementExtension.log excerpt path)
Notes:

## RTVAL-03 — Detection rule reports Installed
Status: PENDING
Evidence: (screenshot path)
Notes:

## RTVAL-04 — Uninstall under SYSTEM
Status: PENDING
Evidence: (log path + screenshot)
Notes:

## Issues Found
(list any defects; link to v1.1 tickets or defer rationale)

## Sign-off
- [ ] All five RTVAL criteria PASS or have documented rationale
- [ ] Evidence files committed under `evidence/`
- [ ] Signed by: ___________________

Also create .planning/phases/10-real-world-runtime-validation/evidence/.gitkeep as an empty file so git tracks the evidence directory. test -f .planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md && test -f .planning/phases/10-real-world-runtime-validation/evidence/.gitkeep && grep -q "RTVAL-01" .planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md && grep -q "Sign-off" .planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md RUNTIME-VALIDATION.md scaffold exists with all five RTVAL sections and a sign-off block; evidence/ folder exists in git.

Task 2: Technician generates a real .intunewin package from running ImpTune .planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md PAUSE for human technician. Claude cannot run Docker + click through the export UI + read a local file's hash on the user's box. The executor agent must present the following instructions and wait.

Technician MUST perform the following:

1. Start ImpTune from the current commit (docker compose up or the local dev command).
2. Record the current commit SHA: git rev-parse HEAD and paste into RUNTIME-VALIDATION.md "ImpTune commit SHA".
3. In the UI, pick or create a test printer using a driver vendor representative of the target MSP environment (e.g., HP Universal, Konica Minolta, Brother). Record the vendor in the report.
4. Export the package via the package export button. Save the resulting .intunewin file locally.
5. Compute its SHA256: certutil -hashfile <file>.intunewin SHA256 (Windows) or sha256sum <file>.intunewin (Linux/WSL). Paste into report.
6. Fill in tenant domain, test device hostname, Windows OS build (winver on device), and generation timestamp in the report metadata table.
7. Copy the generated .intunewin file into .planning/phases/10-real-world-runtime-validation/evidence/ (or note its archived location if too large for git).

Expected outcome: RUNTIME-VALIDATION.md metadata table is FULLY populated before proceeding to plan 10-02.

Resume signal: reply "metadata filled" (with the package SHA256) or describe blockers. ! grep -E "^| (Intune tenant|Test device hostname|Windows OS build|Driver vendor(s) tested|ImpTune commit SHA|Package file name|Package SHA256|Generated at) | *|" .planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md Every row in the Tenant & Environment metadata table has a non-empty value; technician has replied "metadata filled".

- RUNTIME-VALIDATION.md exists with scaffold - Metadata table populated (commit SHA, tenant, device, OS build, vendor, package SHA256) - A real .intunewin file is generated and located (path or archive recorded)

<success_criteria> Technician signals "metadata filled"; report metadata table has no empty fields; package file exists and its SHA256 is recorded. </success_criteria>

After completion, create `.planning/phases/10-real-world-runtime-validation/10-01-preflight-package-and-scaffold-SUMMARY.md`