Product owner brief

Owner of what the PM sends the product owner and how it accepts the report. The product owner workflow owns isolation, procedure and the report format.

Owner of what the PM sends the product owner and how it accepts the report. The product owner workflow owns isolation, procedure and the report format.

Supply

All paths are project-root-relative cache paths that prepare-change-check.mjs reported:

  • the baseline version path (baselinePath);
  • the proposed version path (proposedPath);
  • the mechanical inventory path (inventoryPath);
  • the owner’s concerns, verbatim, only if the user gave any. Introduce them as concerns to investigate, not as facts;
  • exactly one assigned, unused report path from reportPaths, to which the product owner writes the whole report;
  • a link to the product owner workflow.

Describe the two versions neutrally: one is the current version and one is a proposed replacement, and the task is to compare them. Never include how either was produced or scored, the rubric, research, ledgers, backlog, review reports, drafts, writer handoffs, a previous change-check report, the base ref’s name or the commit hashes. The base ref and commit belong to the PM’s final report, not to the investigator.

Accept

Require the returned path to match the assigned path exactly, and read only that path. Recompute the hash of the source page afterwards and compare it with proposedHash: a changed page means the check is stale, so say so and do not present the report as current.

Check, by eye, that the report has, in this order:

  • a verdict of SHIP, SHIP AFTER CHANGES or HOLD with a short plain-English summary;
  • Your concerns, only when concerns were supplied, with a verdict on each;
  • a labelled My personal opinion, then What is genuinely better and What I would do next;
  • the Things to check before go-live table, with a link to an existing appendix entry in every row that needs one;
  • What I could not check;
  • the appendix, one anchored ### Detail N entry per worth checking or serious table row, and “none needed” in the Details cell of a minor row;
  • a verdict that follows the workflow’s rule: no HOLD or SHIP AFTER CHANGES resting only on minor items;
  • line numbers on the issues, in the baseline line N or proposed lines N-M form;
  • no finding about a problem the baseline already had, unless the change made it worse;
  • no finding or “could not check” item about how the component behaves or renders;
  • no finding about frontmatter, no finding that rests on length alone, and no Reads row that is really a guidance gap.

On failure, return one specific omission for one correction attempt, assigning the second path in reportPaths. Do not suggest a finding or a verdict. If the report is still incomplete, say so and relay what it contains, marked incomplete.

The PM never adjudicates the product owner’s findings, never corrects a quote or a line number itself, and never turns the report into a rating.

See also