10 KiB
phase, plan, type, wave, depends_on, files_modified, autonomous, requirements, must_haves
| phase | plan | type | wave | depends_on | files_modified | autonomous | requirements | must_haves | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 11-real-world-rollout-feedback | 03 | execute | 3 |
|
|
false |
|
|
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.
<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/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
<!-- Things the technician explicitly called out as good. One bullet per item. -->
-
## 2. What Blocked
<!-- Things that stopped the technician or forced a workaround. One bullet per item. Include severity (hard-block / workaround / annoyance). -->
-
## 3. What's Missing
<!-- Gaps the technician felt while using ImpTune end-to-end: features, docs, ergonomics. -->
-
## 4. Raw Quotes / Notes
<!-- Verbatim technician comments worth preserving. Optional. -->
---
## 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.
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.
Built so far: v1.1-rollout.md with sections 1–4 filled from Task 2.
Steps for the human operator:
-
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.1items MUST become either new requirements in REQUIREMENTS.md or spawn a gap-closure phase before v1.1 closes -defer-to-v1.2items MUST be captured as v1.2 backlog (noted in rationale) -won't-doitems 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.mdto tick RWR-01..04 if all success criteria are met, and add anyfix-in-v1.1items 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.
<success_criteria>
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.
</success_criteria>