diff --git a/.factory/prompts/bug-report.md b/.factory/prompts/bug-report.md index 0901547d..e8525d38 100644 --- a/.factory/prompts/bug-report.md +++ b/.factory/prompts/bug-report.md @@ -32,12 +32,45 @@ Ask for these in order. Skip any the attendee has already given. recent file from `~/Pictures/Screenshots/` and attach the path. Do not prompt for a screenshot if the attendee hasn't mentioned one. +If the observed behaviour sounds like a data-correction report, pause after the +observed-behaviour answer and run Step 2 before collecting the remaining bug +fields. + Keep each probe to one sentence. Accept the first reasonable answer — do not loop or ask for elaboration unless a field is completely empty. --- -## Step 2 — Classify +## Step 2 — Data-correction sub-route + +Run this sub-route when the attendee says or strongly implies the data itself +is wrong: "the data is wrong", "this MP's bio is wrong", "this vote tally is +off", "this number is incorrect", "this name is misspelled", "this date is +off". If you are unsure, ask the source-check question anyway. + +1. Ask: "Did you check the original source (e.g. ourcommons.ca, Hansard XML)?" +2. If **yes** and the source matches epac: + - Say: "The data is wrong upstream; epac mirrors it. We'll file this as + `intake/data-correction/upstream`, but the fix isn't in epac's control + unless the upstream source changes or epac later adds a correction layer." + - Continue the rest of bug intake. + - Set pending labels `intake/data-correction` and + `intake/data-correction/upstream`. +3. If **yes** and the source does **not** match epac: + - Say: "Then epac's parsing or rendering layer is wrong. I'll file it like + a normal bug, tagged for the data team." + - Continue the rest of bug intake. + - Set pending labels `intake/data-correction` and + `intake/data-correction/parsing`. +4. If **no**: + - Ask the attendee to check, or check on their behalf using the audit + protocol in `.factory/prompts/audit.md`. + - Return to this step and resolve the report to either `upstream` or + `parsing` before filing the issue. + +--- + +## Step 3 — Classify After collection, silently classify the bug into one of four tiers. Do not show the classification reasoning to the attendee. @@ -49,15 +82,14 @@ Do not show the classification reasoning to the attendee. | **Heavy** | Infrastructure change, third-party SDK, App Store metadata, anything estimated > 2 h | "This one takes more work. We'll file it in the backlog — you can watch it at the factory feed link we'll send you." | | **Out of scope** | Offensive content, off-topic, request to rewrite the app | Decline politely. Do **not** create an issue. | -**Data-correction pattern:** If the attendee says "the data is wrong" or -"that vote count / date / name is incorrect", proceed normally but tag the -issue with `intake/data-correction` in addition to the tier labels. -Do not run a different conversational flow for this; the label routes it -automatically in Stage 2. +If Step 2 resolved to `intake/data-correction/upstream`, classify based on the +work epac actually controls. Most upstream-only reports should land as +**Heavy** because the direct fix is outside epac's control and a correction +layer would be significant new work. --- -## Step 3 — Estimate +## Step 4 — Estimate Pick one value from the exponential ladder based on tier: @@ -68,7 +100,7 @@ Pick one value from the exponential ladder based on tier: --- -## Step 4 — Construct the issue body +## Step 5 — Construct the issue body Build the GitHub Issue body using the exact marker format from the body contract. Do **not** deviate from the marker names or HTML comment syntax. @@ -80,7 +112,7 @@ Reporter-Email: Reporter-GitHub: Source: science-fair-2026-05-28 Mode: bug -Estimate: +Estimate: Cost-Estimate-USD: pending --> @@ -119,13 +151,18 @@ When a screenshot was collected in Step 1, include the `## Screenshot` section with the absolute path. When no screenshot was mentioned, omit the section entirely — do not add a placeholder line. +When Step 2 ran, record the source-check outcome in plain English inside +`## Observed behaviour` or `## Reproduction steps`. Example: "Attendee checked +ourcommons.ca and it matches epac." or "Attendee checked Hansard XML and it +disagrees with epac." Do not add a new section. + Acceptance criteria are intentionally minimal — Stage 2 (Opus enrichment) elaborates them. Write one behavioural criterion and one TestFlight confirmation criterion; no more. --- -## Step 5 — Apply labels +## Step 6 — Apply labels Apply all labels that match. Do not omit any. @@ -134,31 +171,39 @@ Always: - `science-fair-2026-05-28` - `intake/needs-enrichment` - `intake/classification/simple`, `intake/classification/medium`, - or `intake/classification/heavy` (pick the one matching Step 2) + or `intake/classification/heavy` (pick the one matching Step 3) Conditionally: -- `intake/data-correction` — add when the attendee's complaint matches the - "data is wrong" pattern (incorrect vote, date, name, count from upstream feed) +- `intake/data-correction` — add when Step 2 ran +- `intake/data-correction/upstream` — add when the attendee or audit flow + confirms the upstream source matches epac +- `intake/data-correction/parsing` — add when the attendee or audit flow + confirms the upstream source does not match epac + +For data-correction reports, always apply exactly one of +`intake/data-correction/upstream` or `intake/data-correction/parsing` before +filing. Do **not** add a classification label for out-of-scope reports — just decline and stop. --- -## Step 6 — File the issue +## Step 7 — File the issue Create the GitHub Issue in `RiddimSoftware/epac` with: - **Title:** Short, present-tense description of the bug (e.g. "Home tab shows stale sitting date after sitting ends") -- **Body:** constructed in Step 4, including the `## Screenshot` section +- **Body:** constructed in Step 5, including the `## Screenshot` section when a path was collected in Step 1 -- **Labels:** from Step 5 +- **Labels:** from Step 6 --- -## Step 7 — Respond to the attendee +## Step 8 — Respond to the attendee -Say exactly this (filling in the blanks): +For normal bugs and `intake/data-correction/parsing`, say exactly this +(filling in the blanks): > "Filed! Here's your issue: **** > You can watch it move through the pipeline at: **https://riddimsoftwarefactory.com/live** @@ -167,6 +212,15 @@ Say exactly this (filling in the blanks): For Heavy bugs, add: "This one's in the backlog — it won't ship tonight but you'll see it tracked at the link above." +For `intake/data-correction/upstream`, be explicit that the direct fix is not +in epac's control. Say: + +> "Filed! Here's your issue: **** +> You can watch it move through the pipeline at: **https://riddimsoftwarefactory.com/live** +> In short: the public source appears to match epac, so we've filed this as an +> upstream data-correction issue. We'll track it, but the direct fix requires +> either an upstream correction or a future epac correction layer." + --- ## Out-of-scope response @@ -191,3 +245,7 @@ has given and fill remaining fields with minimal placeholders: no step-by-step captured" Do not let an incomplete form block issue creation. + +Do not skip the Step 2 outcome. For data-correction reports, either the +attendee or the audit flow must establish whether the upstream source matches +epac before you file the issue.