diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md index 0a99fe4..7c5075f 100644 --- a/.planning/ROADMAP.md +++ b/.planning/ROADMAP.md @@ -1,97 +1,101 @@ -# Roadmap: ImpTune - -## Milestones - -- βœ… **v1.0 MVP** β€” Phases 1–7, 13 plans, 27/27 requirements (shipped 2026-04-13) β€” see [`milestones/v1.0-ROADMAP.md`](milestones/v1.0-ROADMAP.md) -- 🚧 **v1.1 Hardening & Validation** β€” Phases 8–11, 15 requirements (in progress, started 2026-04-13) - -## Phases - -
-βœ… v1.0 MVP (Phases 1–7) β€” SHIPPED 2026-04-13 - -- [x] Phase 1: Foundation (3/3 plans) β€” 2026-04-10 -- [x] Phase 2: Driver Management (2/2 plans) β€” 2026-04-10 -- [x] Phase 3: Printer Configuration (2/2 plans) β€” 2026-04-10 -- [x] Phase 4: Script Generation (2/2 plans) β€” 2026-04-10 -- [x] Phase 5: Package Export (2/2 plans) β€” 2026-04-10 -- [x] Phase 6: Wire Icon into .intunewin (1/1 plan, gap closure) β€” 2026-04-10 -- [x] Phase 7: Dashboard & Navigation Polish (1/1 plan, gap closure) β€” 2026-04-13 - -Full details: [`milestones/v1.0-ROADMAP.md`](milestones/v1.0-ROADMAP.md) - -
- -### 🚧 v1.1 Hardening & Validation (Phases 8–11) - -- [ ] **Phase 8: Nyquist Validation Track** β€” Retro-fit Nyquist-compliant VALIDATION.md across all 7 v1.0 phases with evidence-backed checks -- [x] **Phase 9: UX Tech Debt Closure** β€” Fix the three carried-over UX gaps so the deployed build is the polished one technicians actually use (completed 2026-04-13) -- [x] **Phase 10: Real-World Runtime Validation** β€” Validate generated artifacts end-to-end against a live Intune tenant and a real managed endpoint (completed 2026-04-13) -- [ ] **Phase 11: Real-World Rollout & Feedback** β€” Deploy the container to a real MSP environment, push a real package, and capture structured technician feedback - -## Phase Details - -### Phase 8: Nyquist Validation Track -**Goal**: Every v1.0 phase has a signed-off Nyquist-compliant validation record with cited evidence, and any blocking gaps are tracked. -**Depends on**: Nothing (parallelizable β€” pure audit of shipped code, no runtime dependency) -**Requirements**: NYQ-01, NYQ-02, NYQ-03 -**Success Criteria** (what must be TRUE): - 1. An operator can open any of the 7 v1.0 phase folders and read a `VALIDATION.md` where every success criterion maps to exactly one observable check with cited evidence (commit, test name, file path, or screenshot) - 2. An operator can open `.planning/milestones/v1.0-VALIDATION-INDEX.md` and see a single pass/fail roll-up across all 7 phases with links to each phase's validation file - 3. Any validation gap surfaced during the Nyquist pass appears in the index as either a v1.1 defect ticket (linked to the fixing phase) or an explicitly deferred item with written rationale -**Plans**: TBD - -### Phase 9: UX Tech Debt Closure -**Goal**: The three carried-over UX defects are fixed and live-verified in a real browser so the rolled-out build is the polished one. -**Depends on**: Nothing (independent of validation and rollout β€” but must complete before Phase 11) -**Requirements**: UX-01, UX-02, UX-03 -**Success Criteria** (what must be TRUE): - 1. A technician uploading a new driver on the printer form sees the new DriverDesc appear in the dropdown without manually reloading the page - 2. A technician typing an IP address into the printer form sees the port field auto-populate via the PRNT-03 Alpine.js handler, observed live in a real browser and recorded in VALIDATION.md - 3. A technician on the printer detail page can click direct download links for the install, uninstall, and detect scripts individually, in addition to the existing package export buttons -**Plans**: 3 plans - - [ ] 09-01-driver-upload-fix-and-inline-oob-PLAN.md β€” Fix POST /drivers/upload 500 + add inline upload to printer form with HTMX OOB refresh (UX-01) - - [ ] 09-02-playwright-port-autofill-PLAN.md β€” Add Playwright dev dep + headless test for PRNT-03 IP->port auto-fill (UX-02) - - [ ] 09-03-script-download-links-PLAN.md β€” Add .ps1 route aliases + printer_detail.html script download links (UX-03) - -### Phase 10: Real-World Runtime Validation -**Goal**: Generated .intunewin, install, detect, and uninstall artifacts are proven to work end-to-end on a real Intune tenant against a real Windows endpoint, with evidence recorded. -**Depends on**: Phase 9 (rollout uses the validated-AND-polished build; validation itself only strictly needs v1.0, but running it on the polished build avoids re-doing the pass) -**Requirements**: RTVAL-01, RTVAL-02, RTVAL-03, RTVAL-04, RTVAL-05 -**Success Criteria** (what must be TRUE): - 1. A generated `.intunewin` package is uploaded to a real Microsoft Intune tenant and accepted without format errors, with the tenant ingestion confirmation captured as evidence - 2. A technician assigning the package to a real Intune-managed Windows endpoint observes the install script succeed under SYSTEM context, with `pnputil` driver staging and `$PSScriptRoot` path resolution verified in the device log - 3. After install, the Intune detection rule driven by the generated detect script reports "installed" for the endpoint - 4. A technician triggering uninstall from Intune sees the printer cleanly removed from the endpoint under SYSTEM context - 5. A reviewer can open `RUNTIME-VALIDATION.md` and read a signed-off report listing tenant, device, OS build, driver vendor(s), screenshots/logs, and any issues found -**Plans**: 3 plans - - [ ] 10-01-preflight-package-and-scaffold-PLAN.md β€” Generate real .intunewin from current commit and scaffold RUNTIME-VALIDATION.md with tenant/device/vendor metadata (RTVAL-05 scaffold) - - [ ] 10-02-live-intune-runtime-validation-PLAN.md β€” Drive RTVAL-01..04 manual checkpoints against a live Intune tenant + real Windows endpoint, capturing screenshots and device logs as evidence - - [ ] 10-03-report-signoff-PLAN.md β€” Finalize RUNTIME-VALIDATION.md, human sign-off, tick RTVAL-01..05 and mark Phase 10 complete - -### Phase 11: Real-World Rollout & Feedback -**Goal**: ImpTune is running in a real MSP environment, has produced a package that actually reached endpoints, and technician feedback has been captured and triaged. -**Depends on**: Phase 9 (UX tech debt), Phase 10 (runtime validation passed) -**Requirements**: RWR-01, RWR-02, RWR-03, RWR-04 -**Success Criteria** (what must be TRUE): - 1. ImpTune is running in its single Docker container inside at least one real MSP environment serving real printers, with the host/URL recorded in the feedback document - 2. At least one printer deployment package generated by the deployed instance has been pushed to real endpoints via Intune or NinjaRMM end-to-end - 3. A reviewer can open `.planning/feedback/v1.1-rollout.md` and read structured feedback from the deploying technician covering what worked, what blocked, and what's missing - 4. Every feedback item in that document is tagged fix-in-v1.1, defer-to-v1.2, or won't-do with written rationale -**Plans**: TBD - -## Progress - -| Phase | Milestone | Plans Complete | Status | Completed | -|-------|-----------|----------------|----------|------------| -| 1. Foundation | v1.0 | 3/3 | Complete | 2026-04-10 | -| 2. Driver Management | v1.0 | 2/2 | Complete | 2026-04-10 | -| 3. Printer Configuration | v1.0 | 2/2 | Complete | 2026-04-10 | -| 4. Script Generation | v1.0 | 2/2 | Complete | 2026-04-10 | -| 5. Package Export | v1.0 | 2/2 | Complete | 2026-04-10 | -| 6. Wire Icon into .intunewin | v1.0 | 1/1 | Complete | 2026-04-10 | -| 7. Dashboard & Nav Polish | v1.0 | 1/1 | Complete | 2026-04-13 | -| 8. Nyquist Validation Track | v1.1 | 0/? | Not started | β€” | -| 9. UX Tech Debt Closure | 3/3 | Complete | 2026-04-13 | β€” | -| 10. Real-World Runtime Validation | v1.1 | 3/3 | Complete | 2026-04-13 | -| 11. Real-World Rollout & Feedback | v1.1 | 0/? | Not started | β€” | +# Roadmap: ImpTune + +## Milestones + +- βœ… **v1.0 MVP** β€” Phases 1–7, 13 plans, 27/27 requirements (shipped 2026-04-13) β€” see [`milestones/v1.0-ROADMAP.md`](milestones/v1.0-ROADMAP.md) +- 🚧 **v1.1 Hardening & Validation** β€” Phases 8–11, 15 requirements (in progress, started 2026-04-13) + +## Phases + +
+βœ… v1.0 MVP (Phases 1–7) β€” SHIPPED 2026-04-13 + +- [x] Phase 1: Foundation (3/3 plans) β€” 2026-04-10 +- [x] Phase 2: Driver Management (2/2 plans) β€” 2026-04-10 +- [x] Phase 3: Printer Configuration (2/2 plans) β€” 2026-04-10 +- [x] Phase 4: Script Generation (2/2 plans) β€” 2026-04-10 +- [x] Phase 5: Package Export (2/2 plans) β€” 2026-04-10 +- [x] Phase 6: Wire Icon into .intunewin (1/1 plan, gap closure) β€” 2026-04-10 +- [x] Phase 7: Dashboard & Navigation Polish (1/1 plan, gap closure) β€” 2026-04-13 + +Full details: [`milestones/v1.0-ROADMAP.md`](milestones/v1.0-ROADMAP.md) + +
+ +### 🚧 v1.1 Hardening & Validation (Phases 8–11) + +- [ ] **Phase 8: Nyquist Validation Track** β€” Retro-fit Nyquist-compliant VALIDATION.md across all 7 v1.0 phases with evidence-backed checks +- [x] **Phase 9: UX Tech Debt Closure** β€” Fix the three carried-over UX gaps so the deployed build is the polished one technicians actually use + (completed 2026-04-13) +- [x] **Phase 10: Real-World Runtime Validation** β€” Validate generated artifacts end-to-end against a live Intune tenant and a real managed endpoint (completed 2026-04-13) +- [ ] **Phase 11: Real-World Rollout & Feedback** β€” Deploy the container to a real MSP environment, push a real package, and capture structured technician feedback + +## Phase Details + +### Phase 8: Nyquist Validation Track +**Goal**: Every v1.0 phase has a signed-off Nyquist-compliant validation record with cited evidence, and any blocking gaps are tracked. +**Depends on**: Nothing (parallelizable β€” pure audit of shipped code, no runtime dependency) +**Requirements**: NYQ-01, NYQ-02, NYQ-03 +**Success Criteria** (what must be TRUE): + 1. An operator can open any of the 7 v1.0 phase folders and read a `VALIDATION.md` where every success criterion maps to exactly one observable check with cited evidence (commit, test name, file path, or screenshot) + 2. An operator can open `.planning/milestones/v1.0-VALIDATION-INDEX.md` and see a single pass/fail roll-up across all 7 phases with links to each phase's validation file + 3. Any validation gap surfaced during the Nyquist pass appears in the index as either a v1.1 defect ticket (linked to the fixing phase) or an explicitly deferred item with written rationale +**Plans**: TBD + +### Phase 9: UX Tech Debt Closure +**Goal**: The three carried-over UX defects are fixed and live-verified in a real browser so the rolled-out build is the polished one. +**Depends on**: Nothing (independent of validation and rollout β€” but must complete before Phase 11) +**Requirements**: UX-01, UX-02, UX-03 +**Success Criteria** (what must be TRUE): + 1. A technician uploading a new driver on the printer form sees the new DriverDesc appear in the dropdown without manually reloading the page + 2. A technician typing an IP address into the printer form sees the port field auto-populate via the PRNT-03 Alpine.js handler, observed live in a real browser and recorded in VALIDATION.md + 3. A technician on the printer detail page can click direct download links for the install, uninstall, and detect scripts individually, in addition to the existing package export buttons +**Plans**: 3 plans + - [ ] 09-01-driver-upload-fix-and-inline-oob-PLAN.md β€” Fix POST /drivers/upload 500 + add inline upload to printer form with HTMX OOB refresh (UX-01) + - [ ] 09-02-playwright-port-autofill-PLAN.md β€” Add Playwright dev dep + headless test for PRNT-03 IP->port auto-fill (UX-02) + - [ ] 09-03-script-download-links-PLAN.md β€” Add .ps1 route aliases + printer_detail.html script download links (UX-03) + +### Phase 10: Real-World Runtime Validation +**Goal**: Generated .intunewin, install, detect, and uninstall artifacts are proven to work end-to-end on a real Intune tenant against a real Windows endpoint, with evidence recorded. +**Depends on**: Phase 9 (rollout uses the validated-AND-polished build; validation itself only strictly needs v1.0, but running it on the polished build avoids re-doing the pass) +**Requirements**: RTVAL-01, RTVAL-02, RTVAL-03, RTVAL-04, RTVAL-05 +**Success Criteria** (what must be TRUE): + 1. A generated `.intunewin` package is uploaded to a real Microsoft Intune tenant and accepted without format errors, with the tenant ingestion confirmation captured as evidence + 2. A technician assigning the package to a real Intune-managed Windows endpoint observes the install script succeed under SYSTEM context, with `pnputil` driver staging and `$PSScriptRoot` path resolution verified in the device log + 3. After install, the Intune detection rule driven by the generated detect script reports "installed" for the endpoint + 4. A technician triggering uninstall from Intune sees the printer cleanly removed from the endpoint under SYSTEM context + 5. A reviewer can open `RUNTIME-VALIDATION.md` and read a signed-off report listing tenant, device, OS build, driver vendor(s), screenshots/logs, and any issues found +**Plans**: 3 plans + - [ ] 10-01-preflight-package-and-scaffold-PLAN.md β€” Generate real .intunewin from current commit and scaffold RUNTIME-VALIDATION.md with tenant/device/vendor metadata (RTVAL-05 scaffold) + - [ ] 10-02-live-intune-runtime-validation-PLAN.md β€” Drive RTVAL-01..04 manual checkpoints against a live Intune tenant + real Windows endpoint, capturing screenshots and device logs as evidence + - [ ] 10-03-report-signoff-PLAN.md β€” Finalize RUNTIME-VALIDATION.md, human sign-off, tick RTVAL-01..05 and mark Phase 10 complete + +### Phase 11: Real-World Rollout & Feedback +**Goal**: ImpTune is running in a real MSP environment, has produced a package that actually reached endpoints, and technician feedback has been captured and triaged. +**Depends on**: Phase 9 (UX tech debt), Phase 10 (runtime validation passed) +**Requirements**: RWR-01, RWR-02, RWR-03, RWR-04 +**Success Criteria** (what must be TRUE): + 1. ImpTune is running in its single Docker container inside at least one real MSP environment serving real printers, with the host/URL recorded in the feedback document + 2. At least one printer deployment package generated by the deployed instance has been pushed to real endpoints via Intune or NinjaRMM end-to-end + 3. A reviewer can open `.planning/feedback/v1.1-rollout.md` and read structured feedback from the deploying technician covering what worked, what blocked, and what's missing + 4. Every feedback item in that document is tagged fix-in-v1.1, defer-to-v1.2, or won't-do with written rationale +**Plans**: 3 plans + - [ ] 11-01-deploy-container-to-msp-PLAN.md β€” Build + deploy ImpTune container into real MSP environment and record host/URL/commit (RWR-01) + - [ ] 11-02-push-real-package-PLAN.md β€” Generate a real package via the deployed instance and push to a real endpoint via Intune/NinjaRMM (RWR-02) + - [ ] 11-03-capture-and-triage-feedback-PLAN.md β€” Capture structured technician feedback in .planning/feedback/v1.1-rollout.md and triage every item (RWR-03, RWR-04) + +## Progress + +| Phase | Milestone | Plans Complete | Status | Completed | +|-------|-----------|----------------|----------|------------| +| 1. Foundation | v1.0 | 3/3 | Complete | 2026-04-10 | +| 2. Driver Management | v1.0 | 2/2 | Complete | 2026-04-10 | +| 3. Printer Configuration | v1.0 | 2/2 | Complete | 2026-04-10 | +| 4. Script Generation | v1.0 | 2/2 | Complete | 2026-04-10 | +| 5. Package Export | v1.0 | 2/2 | Complete | 2026-04-10 | +| 6. Wire Icon into .intunewin | v1.0 | 1/1 | Complete | 2026-04-10 | +| 7. Dashboard & Nav Polish | v1.0 | 1/1 | Complete | 2026-04-13 | +| 8. Nyquist Validation Track | v1.1 | 0/? | Not started | β€” | +| 9. UX Tech Debt Closure | 3/3 | Complete | 2026-04-13 | β€” | +| 10. Real-World Runtime Validation | v1.1 | 3/3 | Complete | 2026-04-13 | +| 11. Real-World Rollout & Feedback | v1.1 | 0/3 | Not started | β€” | diff --git a/.planning/phases/11-real-world-rollout-feedback/11-01-deploy-container-to-msp-PLAN.md b/.planning/phases/11-real-world-rollout-feedback/11-01-deploy-container-to-msp-PLAN.md new file mode 100644 index 0000000..bd9baaa --- /dev/null +++ b/.planning/phases/11-real-world-rollout-feedback/11-01-deploy-container-to-msp-PLAN.md @@ -0,0 +1,157 @@ +--- +phase: 11-real-world-rollout-feedback +plan: 01 +type: execute +wave: 1 +depends_on: [] +files_modified: + - .planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md +autonomous: false +requirements: + - RWR-01 +must_haves: + truths: + - "ImpTune is running in a single Docker container inside a real MSP environment" + - "The deployed instance is reachable from the technician's workstation at a recorded URL" + - "The exact ImpTune commit SHA running in production is recorded" + artifacts: + - path: ".planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md" + provides: "Deployment record: host, URL, commit SHA, image tag, container ID, deploy date, operator" + contains: "host:" + key_links: + - from: "Technician workstation browser" + to: "Deployed ImpTune container" + via: "HTTP(S) URL recorded in DEPLOYMENT.md" + pattern: "url:.*http" +--- + + +Deploy the current ImpTune build as a single Docker container inside a real MSP environment and record the deployment facts (host, URL, commit, image tag) so downstream plans and reviewers can locate the running instance. + +Purpose: RWR-01 requires ImpTune to actually be running somewhere real β€” not on localhost β€” before any real package can be pushed. This plan is the "get it on a real host" step. + +Output: A deployed, reachable ImpTune container plus `.planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md` recording where it lives. + + + +@C:/Users/SebastienQUEROL/.claude/get-shit-done/workflows/execute-plan.md +@C:/Users/SebastienQUEROL/.claude/get-shit-done/templates/summary.md + + + +@.planning/PROJECT.md +@.planning/STATE.md +@.planning/ROADMAP.md +@.planning/REQUIREMENTS.md +@.planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md + + + + + + Task 1: Scaffold DEPLOYMENT.md and lock build metadata + .planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md + + Create `.planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md` with the following sections (leave values blank for fields that only the human deploy step can fill; pre-fill the ones the agent can determine now): + + - Title: `# ImpTune v1.1 Rollout Deployment Record` + - Build metadata (pre-fill now from the working tree): + - `commit_sha:` β€” run `git rev-parse HEAD` and paste the full SHA + - `commit_date:` β€” run `git show -s --format=%ci HEAD` + - `branch:` β€” run `git rev-parse --abbrev-ref HEAD` + - `dirty:` β€” yes/no from `git status --porcelain` (non-empty = yes) + - Docker image (leave blank for the human to fill during deploy): + - `image_tag:` (e.g. `imptune:v1.1-rollout`) + - `image_digest:` (from `docker images --digests` after build) + - Deployment target (leave blank for the human): + - `msp_name:` + - `host:` (hostname or IP of the Docker host inside the MSP env) + - `url:` (full URL the technician will open β€” http(s)://host:port) + - `deployed_by:` + - `deployed_at:` (ISO8601) + - `container_id:` + - Notes section (free text, optional) + + Also pre-fill a short "How this was deployed" checklist placeholder with the three steps the human will perform in Task 2: build image, transfer/pull on MSP host, `docker run` with persistent volume for `imptune.db` + `uploads/`. + + Do NOT attempt to `docker build` or `docker run` in this task β€” this task is metadata scaffolding only. + + + test -f .planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md && grep -q "commit_sha:" .planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md && grep -q "^commit_sha: [0-9a-f]" .planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md + + DEPLOYMENT.md exists with commit_sha/commit_date/branch/dirty filled from git, and empty placeholders for image_tag, host, url, deployed_by, deployed_at, container_id. + + + + Task 2: Human β€” build, ship, and run the container in the real MSP environment + (human-driven β€” no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action) + + CHECKPOINT β€” human action required. Agent must pause here and display the instructions below to the user, then wait for the resume-signal. + + Built so far: DEPLOYMENT.md scaffold from Task 1 with commit SHA locked. + + Steps for the human operator: +This step is unavoidably human because it requires access to the MSP's real infrastructure (VM, Docker host, network) which no CLI the agent can reach owns. + + Steps for the human operator: + + 1. On a workstation with Docker: + - `docker build -t imptune:v1.1-rollout .` (from repo root) + - `docker images --digests imptune:v1.1-rollout` β€” copy the digest + 2. Transfer image to MSP host (choose one): + - `docker save imptune:v1.1-rollout | ssh msp-host 'docker load'`, OR + - Push to an internal registry and `docker pull` on the MSP host + 3. On the MSP host, run the container with persistent storage: + - `docker run -d --name imptune --restart unless-stopped -p 8000:8000 -v imptune-data:/app/data imptune:v1.1-rollout` + - (Adjust port / volume path to match the repo's actual Dockerfile β€” confirm by reading `Dockerfile` + `imptune/config.py` before running.) + 4. From the technician's workstation, open the URL in a browser and confirm the ImpTune dashboard loads. + 5. Fill DEPLOYMENT.md: + - `image_tag:`, `image_digest:` + - `msp_name:`, `host:`, `url:`, `deployed_by:`, `deployed_at:` (ISO8601), `container_id:` (from `docker ps`) + 6. Commit DEPLOYMENT.md. + + Resume signal: Type "deployed {url}" with the real URL, or describe the blocker. + + + MISSING β€” checkpoint is human-gated; verification is operator attestation captured via the resume-signal. Agent should confirm the referenced artifact file was updated (e.g. grep for the newly-filled field in the target doc) before accepting the resume signal. + + Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal. + + + + Task 3: Verify deployment record is complete and instance is reachable + (human-driven β€” no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action) + + CHECKPOINT β€” human action required. Agent must pause here and display the instructions below to the user, then wait for the resume-signal. + + Built so far: Deployed ImpTune container + filled DEPLOYMENT.md. + + Steps for the human operator: +1. Open `.planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md` β€” confirm no placeholder fields are still blank among: image_tag, image_digest, msp_name, host, url, deployed_by, deployed_at, container_id. + 2. From any machine with access, open the recorded `url:` in a browser β€” ImpTune dashboard must load. + 3. On the MSP host, run `docker ps --filter name=imptune --format '{{.Status}}'` β€” status must be `Up`. + 4. Confirm the image the container is running corresponds to the commit_sha recorded in DEPLOYMENT.md (spot-check: container's `/app` should match, or rely on image_digest match). + + Resume signal: Type "verified" or list the gaps. + + + MISSING β€” checkpoint is human-gated; verification is operator attestation captured via the resume-signal. Agent should confirm the referenced artifact file was updated (e.g. grep for the newly-filled field in the target doc) before accepting the resume signal. + + Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal. + + + + + +- DEPLOYMENT.md exists and has all 8 required fields populated (commit_sha, image_tag, image_digest, msp_name, host, url, deployed_by, deployed_at, container_id) +- The deployed URL returns the ImpTune dashboard in a browser +- `docker ps` on the MSP host shows the container as `Up` + + + +ImpTune is running in a single Docker container on a real MSP host, reachable at a recorded URL, and DEPLOYMENT.md captures the exact commit SHA + image digest + deployment target so downstream plans can reference the same instance. + + + +After completion, create `.planning/phases/11-real-world-rollout-feedback/11-01-deploy-container-to-msp-SUMMARY.md` + diff --git a/.planning/phases/11-real-world-rollout-feedback/11-02-push-real-package-PLAN.md b/.planning/phases/11-real-world-rollout-feedback/11-02-push-real-package-PLAN.md new file mode 100644 index 0000000..4a035ea --- /dev/null +++ b/.planning/phases/11-real-world-rollout-feedback/11-02-push-real-package-PLAN.md @@ -0,0 +1,157 @@ +--- +phase: 11-real-world-rollout-feedback +plan: 02 +type: execute +wave: 2 +depends_on: + - 11-01 +files_modified: + - .planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md +autonomous: false +requirements: + - RWR-02 +must_haves: + truths: + - "A real printer deployment package was generated by the deployed ImpTune instance (not a local dev instance)" + - "That package was pushed end-to-end via Intune or NinjaRMM to at least one real endpoint" + - "The technician observed the printer installed on the real endpoint after push" + artifacts: + - path: ".planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md" + provides: "Rollout run record: package name, printer model, source ImpTune URL, delivery channel (Intune/Ninja), target endpoint, install result" + contains: "delivery_channel:" + key_links: + - from: "Deployed ImpTune instance (from 11-01)" + to: "Real endpoint" + via: "Intune or NinjaRMM package assignment" + pattern: "delivery_channel: (intune|ninjarmm)" +--- + + +Use the ImpTune instance deployed in Plan 11-01 to generate a real printer deployment package and push it end-to-end to at least one real endpoint via Intune or NinjaRMM. Record the full rollout chain so the feedback plan (11-03) has concrete facts to reference. + +Purpose: RWR-02 requires that the deployed instance actually produces value β€” not just that it runs. "Package reached real endpoints" is the core proof. + +Output: A real printer visible on a real endpoint, plus `.planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md` recording the rollout. + + + +@C:/Users/SebastienQUEROL/.claude/get-shit-done/workflows/execute-plan.md +@C:/Users/SebastienQUEROL/.claude/get-shit-done/templates/summary.md + + + +@.planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md +@.planning/phases/11-real-world-rollout-feedback/11-01-deploy-container-to-msp-SUMMARY.md +@.planning/phases/10-real-world-runtime-validation/RUNTIME-VALIDATION.md + + + + + + Task 1: Scaffold ROLLOUT-RUN.md + .planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md + + Create `.planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md` with the following fields (placeholders the human will fill in Task 2): + + - Title: `# ImpTune v1.1 Rollout β€” First Real Package Run` + - Source instance: + - `imptune_url:` (copy from DEPLOYMENT.md) + - `imptune_commit_sha:` (copy from DEPLOYMENT.md) + - Package generated: + - `printer_model:` + - `driver_vendor:` + - `package_name:` + - `package_file:` (e.g. `FloorPrinter_A.intunewin`) + - `generated_at:` (ISO8601) + - Delivery channel (exactly one): + - `delivery_channel:` β€” `intune` OR `ninjarmm` + - If intune: `tenant:`, `app_id:`, `assigned_group:` + - If ninjarmm: `org:`, `policy_or_script_id:`, `target_device_group:` + - Target endpoint: + - `device_name:` + - `os_build:` + - `push_started_at:` + - `install_observed_at:` + - Outcome: + - `printer_visible_on_endpoint:` (yes/no) + - `evidence:` (path to screenshot or log excerpt, or short attestation line if human-only) + - `issues_encountered:` (free text, bullet list) + + Pre-fill `imptune_url:` and `imptune_commit_sha:` by reading DEPLOYMENT.md. Do NOT attempt to call Intune/NinjaRMM APIs β€” delivery is human-driven in Task 2. + + + test -f .planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md && grep -q "delivery_channel:" .planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md && grep -q "imptune_url: http" .planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md + + ROLLOUT-RUN.md exists, imptune_url and imptune_commit_sha pre-filled from DEPLOYMENT.md, all other fields are explicit placeholders. + + + + Task 2: Human β€” generate real package via deployed instance and push to real endpoint + (human-driven β€” no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action) + + CHECKPOINT β€” human action required. Agent must pause here and display the instructions below to the user, then wait for the resume-signal. + + Built so far: ROLLOUT-RUN.md scaffold with source instance facts pre-filled. + + Steps for the human operator: +Human-only steps (requires Intune/NinjaRMM tenant + real target endpoint β€” no CLI the agent owns can perform these): + + 1. Open the deployed ImpTune URL (`imptune_url:` from DEPLOYMENT.md) in a browser. + 2. Upload the real printer driver (any real printer model in the MSP fleet β€” not the Phase 10 test printer unless that's still the target). + 3. Create a printer in the form (name, IP, driver, model). Confirm port auto-fill works (UX-02 already validated, but spot-check). + 4. Export the package from the printer detail page β€” download the `.intunewin`. + 5. Push via ONE of the two channels: + - **Intune**: Upload `.intunewin` to the tenant as a Win32 app, set detection rule from the generated detect script, assign to a real device group containing at least one real endpoint. + - **NinjaRMM**: Create a policy or scheduled script that pushes the package and runs `install.ps1`, target at least one real endpoint. + 6. Wait for the endpoint to pick up the assignment (Intune sync / Ninja policy interval). + 7. On the target endpoint (RDP / physical): confirm the printer appears in `Settings -> Printers & scanners` or `Control Panel -> Devices and Printers`. + 8. Capture evidence (screenshot preferred; log excerpt acceptable). Save under `.planning/phases/11-real-world-rollout-feedback/evidence/` and reference the filename in `evidence:`. + 9. Fill in every blank field in ROLLOUT-RUN.md, including `printer_visible_on_endpoint:` and `issues_encountered:`. + 10. Commit ROLLOUT-RUN.md (+ evidence files). + + Resume signal: Type "pushed {endpoint}" with the target endpoint name, or "blocked: {reason}". + + + MISSING β€” checkpoint is human-gated; verification is operator attestation captured via the resume-signal. Agent should confirm the referenced artifact file was updated (e.g. grep for the newly-filled field in the target doc) before accepting the resume signal. + + Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal. + + + + Task 3: Verify ROLLOUT-RUN.md is complete and the printer is live on the endpoint + (human-driven β€” no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action) + + CHECKPOINT β€” human action required. Agent must pause here and display the instructions below to the user, then wait for the resume-signal. + + Built so far: Real printer installed on a real endpoint through a real delivery channel, plus a filled ROLLOUT-RUN.md. + + Steps for the human operator: +1. Open ROLLOUT-RUN.md β€” no blank placeholder fields remain. + 2. `delivery_channel:` is exactly `intune` or `ninjarmm`, and the channel-specific fields (tenant/app_id OR org/policy_id) are populated. + 3. `printer_visible_on_endpoint:` is `yes`. + 4. `evidence:` references a file that exists OR is clearly labeled as technician attestation (and this will be flagged in the phase SUMMARY just like Phase 10 did). + 5. Re-confirm on the target endpoint that the printer still prints a test page (optional but strongly recommended β€” catches "installed but broken" gap). + + Resume signal: Type "verified" or list the gaps. + + + MISSING β€” checkpoint is human-gated; verification is operator attestation captured via the resume-signal. Agent should confirm the referenced artifact file was updated (e.g. grep for the newly-filled field in the target doc) before accepting the resume signal. + + Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal. + + + + + +- ROLLOUT-RUN.md is fully filled +- delivery_channel is one of {intune, ninjarmm} with the corresponding subfields populated +- Printer is confirmed visible on the real endpoint + + + +A package generated by the deployed ImpTune instance (not a local dev build) was pushed to a real endpoint via Intune or NinjaRMM and the printer is installed and visible on that endpoint, with the full chain recorded in ROLLOUT-RUN.md. + + + +After completion, create `.planning/phases/11-real-world-rollout-feedback/11-02-push-real-package-SUMMARY.md` + diff --git a/.planning/phases/11-real-world-rollout-feedback/11-03-capture-and-triage-feedback-PLAN.md b/.planning/phases/11-real-world-rollout-feedback/11-03-capture-and-triage-feedback-PLAN.md new file mode 100644 index 0000000..f01bc88 --- /dev/null +++ b/.planning/phases/11-real-world-rollout-feedback/11-03-capture-and-triage-feedback-PLAN.md @@ -0,0 +1,199 @@ +--- +phase: 11-real-world-rollout-feedback +plan: 03 +type: execute +wave: 3 +depends_on: + - 11-01 + - 11-02 +files_modified: + - .planning/feedback/v1.1-rollout.md +autonomous: false +requirements: + - RWR-03 + - RWR-04 +must_haves: + truths: + - "A reviewer can open .planning/feedback/v1.1-rollout.md and read structured technician feedback covering what worked, what blocked, and what's missing" + - "Every feedback item is tagged exactly one of: fix-in-v1.1, defer-to-v1.2, won't-do" + - "Every triage tag has a written rationale" + - "The feedback document links back to DEPLOYMENT.md and ROLLOUT-RUN.md so the rollout context is traceable" + artifacts: + - path: ".planning/feedback/v1.1-rollout.md" + provides: "Canonical v1.1 rollout feedback + triage document" + contains: "## Triage" + key_links: + - from: ".planning/feedback/v1.1-rollout.md" + to: ".planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md" + via: "relative markdown link" + pattern: "DEPLOYMENT.md" + - from: ".planning/feedback/v1.1-rollout.md" + to: ".planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md" + via: "relative markdown link" + pattern: "ROLLOUT-RUN.md" +--- + + +Capture structured feedback from the deploying technician after the real rollout in Plan 11-02, and triage every feedback item into `fix-in-v1.1`, `defer-to-v1.2`, or `won't-do` with written rationale. Produce the canonical `.planning/feedback/v1.1-rollout.md` document reviewers will read to judge v1.1 success. + +Purpose: RWR-03 and RWR-04 together define the "did it land?" exit criterion for v1.1. Without this document, the rollout is just a deploy β€” there's no loop closed between real usage and the next milestone. + +Output: `.planning/feedback/v1.1-rollout.md` β€” structured, triaged, linked to deployment + rollout records. + + + +@C:/Users/SebastienQUEROL/.claude/get-shit-done/workflows/execute-plan.md +@C:/Users/SebastienQUEROL/.claude/get-shit-done/templates/summary.md + + + +@.planning/phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md +@.planning/phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md +@.planning/phases/11-real-world-rollout-feedback/11-01-deploy-container-to-msp-SUMMARY.md +@.planning/phases/11-real-world-rollout-feedback/11-02-push-real-package-SUMMARY.md + + + + + + Task 1: Scaffold v1.1-rollout.md with structured sections and triage template + .planning/feedback/v1.1-rollout.md + + Create `.planning/feedback/v1.1-rollout.md` with this exact structure: + + ``` + # ImpTune v1.1 Rollout β€” Technician Feedback & Triage + + **Milestone:** v1.1 Hardening & Validation + **Rollout date:** {copy from ROLLOUT-RUN.md push_started_at} + **Deployed instance:** {copy imptune_url + commit_sha from DEPLOYMENT.md} + **Delivery channel:** {copy delivery_channel from ROLLOUT-RUN.md} + **Target endpoint(s):** {copy device_name from ROLLOUT-RUN.md} + **Technician:** {name β€” to be filled by human in Task 2} + + Links: [DEPLOYMENT.md](../phases/11-real-world-rollout-feedback/deploy/DEPLOYMENT.md) Β· [ROLLOUT-RUN.md](../phases/11-real-world-rollout-feedback/deploy/ROLLOUT-RUN.md) + + --- + + ## 1. What Worked + + - + + ## 2. What Blocked + + - + + ## 3. What's Missing + + - + + ## 4. Raw Quotes / Notes + + + --- + + ## Triage + + Every item from sections 1–3 above must appear in exactly one row below with tag ∈ {fix-in-v1.1, defer-to-v1.2, won't-do} and a rationale. + + | # | Item (short) | Source section | Tag | Rationale | + |---|--------------|----------------|-----|-----------| + | | | | | | + + --- + + ## Sign-off + + - Technician: _______________________ Date: __________ + - Product owner (SΓ©bastien QUEROL): _______________________ Date: __________ + ``` + + Pre-fill the metadata block (Rollout date, Deployed instance, Delivery channel, Target endpoint) by reading DEPLOYMENT.md and ROLLOUT-RUN.md. Leave the section bodies empty (just the `-` placeholder) and the triage table with one empty row. + + + test -f .planning/feedback/v1.1-rollout.md && grep -q "## Triage" .planning/feedback/v1.1-rollout.md && grep -q "DEPLOYMENT.md" .planning/feedback/v1.1-rollout.md && grep -q "ROLLOUT-RUN.md" .planning/feedback/v1.1-rollout.md + + v1.1-rollout.md exists with all required sections (What Worked / What Blocked / What's Missing / Triage / Sign-off), metadata pre-filled from the deploy + rollout records, and links to both source documents. + + + + Task 2: Human β€” collect structured feedback from the deploying technician + (human-driven β€” no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action) + + CHECKPOINT β€” human action required. Agent must pause here and display the instructions below to the user, then wait for the resume-signal. + + Built so far: v1.1-rollout.md scaffold with metadata pre-filled. + + Steps for the human operator: +This is a human interview / async fill step. Run it within 48h of the rollout in 11-02 while details are fresh. + + 1. Sit with (or async-message) the technician who performed the rollout. + 2. Walk through the whole flow: upload driver β†’ create printer β†’ export package β†’ push via Intune/Ninja β†’ verify on endpoint. + 3. For each of the three sections, capture at least one concrete item. Do NOT leave a section empty. If genuinely nothing comes up for a section, write "No items reported" explicitly β€” empty bullets are not acceptable. + 4. Fill section 4 with at least one verbatim quote if the technician said anything quotable. + 5. Set the `Technician:` field in the metadata block. + 6. Commit v1.1-rollout.md. + + Ground rules: + - Items must be specific ("HTMX driver-dropdown refresh fired before the new driver appeared in the DB" β€” not "UI was weird") + - Severity labels on What Blocked: `hard-block` (had to abandon), `workaround` (got past it), `annoyance` (tolerable) + - No item gets silently dropped between sections and Triage β€” everything surfaces in both. + + Resume signal: Type "feedback captured" or describe the blocker. + + + MISSING β€” checkpoint is human-gated; verification is operator attestation captured via the resume-signal. Agent should confirm the referenced artifact file was updated (e.g. grep for the newly-filled field in the target doc) before accepting the resume signal. + + Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal. + + + + Task 3: Human β€” triage every feedback item with tag + rationale, then sign off + (human-driven β€” no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action) + + CHECKPOINT β€” human action required. Agent must pause here and display the instructions below to the user, then wait for the resume-signal. + + Built so far: v1.1-rollout.md with sections 1–4 filled from Task 2. + + Steps for the human operator: +1. For every bullet in sections 1, 2, and 3, create exactly one row in the Triage table with: + - A short item description + - Source section (1, 2, or 3) + - Tag ∈ {`fix-in-v1.1`, `defer-to-v1.2`, `won't-do`} + - A written rationale (one sentence minimum β€” why this tag, not the others) + 2. Triage rules: + - `fix-in-v1.1` items MUST become either new requirements in REQUIREMENTS.md or spawn a gap-closure phase before v1.1 closes + - `defer-to-v1.2` items MUST be captured as v1.2 backlog (noted in rationale) + - `won't-do` items MUST include why it was rejected (out of scope, wrong direction, superseded, etc.) + 3. No item may remain un-tagged. No tag may be left without a rationale. + 4. Both sign-off lines at the bottom must be filled: technician + product owner (SΓ©bastien QUEROL), with dates. + 5. Commit the final document. + 6. Update `.planning/REQUIREMENTS.md` to tick RWR-01..04 if all success criteria are met, and add any `fix-in-v1.1` items as new tracked requirements. + + Resume signal: Type "triaged and signed" or list the unresolved items. + + + MISSING β€” checkpoint is human-gated; verification is operator attestation captured via the resume-signal. Agent should confirm the referenced artifact file was updated (e.g. grep for the newly-filled field in the target doc) before accepting the resume signal. + + Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal. + + + + + +- v1.1-rollout.md exists at `.planning/feedback/v1.1-rollout.md` +- Metadata block references DEPLOYMENT.md + ROLLOUT-RUN.md and pulls real values from them +- Sections 1, 2, 3 each have at least one item (or an explicit "No items reported") +- Every section-1/2/3 item has exactly one Triage row +- Every Triage row has a tag in {fix-in-v1.1, defer-to-v1.2, won't-do} and a written rationale +- Sign-off block has technician + product owner names and dates +- REQUIREMENTS.md updated (RWR-01..04 ticked; any fix-in-v1.1 items added) + + + +A reviewer opening `.planning/feedback/v1.1-rollout.md` can, in under 2 minutes, understand: what ImpTune build was deployed, where it was deployed, what package reached which endpoint, what the technician thought, and what the team decided to do about each piece of feedback. RWR-01..04 are all checkable against artifacts, not verbal assurance. + + + +After completion, create `.planning/phases/11-real-world-rollout-feedback/11-03-capture-and-triage-feedback-SUMMARY.md` and mark Phase 11 complete in ROADMAP.md + STATE.md. +