---
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"
---

<objective>
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.
</objective>

<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>

<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
</context>

<tasks>

<task type="auto">
  <name>Task 1: Scaffold v1.1-rollout.md with structured sections and triage template</name>
  <files>.planning/feedback/v1.1-rollout.md</files>
  <action>
    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.
  </action>
  <verify>
    <automated>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</automated>
  </verify>
  <done>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.</done>
</task>

<task type="checkpoint:human-action" gate="blocking">
  <name>Task 2: Human — collect structured feedback from the deploying technician</name>
  <files>(human-driven — no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action)</files>
  <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.
  </action>
  <verify>
    <automated>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.</automated>
  </verify>
  <done>Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal.</done>
</task>

<task type="checkpoint:human-action" gate="blocking">
  <name>Task 3: Human — triage every feedback item with tag + rationale, then sign off</name>
  <files>(human-driven — no files written directly by agent; updates DEPLOYMENT.md / ROLLOUT-RUN.md / v1.1-rollout.md as specified in the action)</files>
  <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.
  </action>
  <verify>
    <automated>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.</automated>
  </verify>
  <done>Human operator has performed the steps above, updated the referenced artifact, and replied with the resume signal.</done>
</task>

</tasks>

<verification>
- 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)
</verification>

<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>

<output>
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.
</output>
