Add new hummingbird QA skill

README.md

@@ -55,17 +55,18 @@ skills currently available:
 
 ### Domain: `qa`
 
-| Category | Skill Folder       | Skill Name           | Description                                                                                                                                                                                        |
-| -------- | ------------------ | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `dev`    | `prestashop-pr-qa` | **prestashop-pr-qa** | QA a pull request against a running environment, in a browser, on the command line or over HTTP: reproduce the bug, verify the fix, and report whether it is approved, with the recording as proof. |
+| Category | Skill Folder             | Skill Name                   | Description                                                                                                                                                                                                                                                            |
+| -------- | ------------------------ | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `dev`    | `prestashop-pr-qa`       | **prestashop-pr-qa**         | QA a pull request against a running environment, in a browser, on the command line or over HTTP: reproduce the bug, verify the fix, and report whether it is approved, with the recording as proof.                                                                     |
+| `dev`    | `hummingbird-theme-qa`   | **hummingbird-theme-qa**     | Run a full end-to-end test campaign on the Hummingbird theme against a given PrestaShop version, driven by the theme's own testing checklist. Reports what was checked, what was found and what nobody looked at, and refuses to build a report whose greens have no evidence behind them. |
 
 ## 🗂️ Repository Structure
 
 The repository is organized by **application domains**. Currently, the supported
 domains include:
 
 - [`autoupgrade`](#domain-autoupgrade) (Module Update Assistant)
-- [`qa`](#domain-qa) (Quality assurance on pull requests)
+- [`qa`](#domain-qa) (Quality assurance on pull requests and on the Hummingbird theme)
 
 _(More domains like core, specific modules, and themes will be added over
 time)._
@@ -91,10 +92,14 @@ PrestaShop/skills/
 │   └── dev/              # Developer-facing skills
 ├── qa/                   # Domain
 │   └── dev/
-│       └── prestashop-pr-qa/
+│       ├── prestashop-pr-qa/
+│       │   ├── SKILL.md
+│       │   ├── references/   # Long knowledge, read on demand
+│       │   └── scripts/      # Code the skill runs, shipped rather than retyped
+│       └── hummingbird-theme-qa/
 │           ├── SKILL.md
-│           ├── references/   # Long knowledge, read on demand
-│           └── scripts/      # Code the skill runs, shipped rather than retyped
+│           ├── references/
+│           └── scripts/
 └── README.md             # This file
 ```
 

qa/dev/hummingbird-theme-qa/references/checklist.md

@@ -0,0 +1,71 @@
+# Reading the checklist
+
+The checklist decides what a campaign answers for. This skill reads it and adds nothing.
+
+## Where it comes from
+
+`docs/qa/testing-checklist.md`, in the Hummingbird repository and nowhere else. The skill never
+carries a copy: a copy would be wrong the first time the theme changed, which is the one thing
+the checklist is built not to be.
+
+**Take it from the release tag matching the theme version.** Two people testing the same release
+then read the same checklist, and a campaign resumed months later reads it again unchanged.
+`checklist.js` asks for `refs/tags/v<version>`, the tag itself rather than any ref with that name,
+so a branch called `v2.1.0` can never be labelled a release. One spelling only: every Hummingbird
+release is tagged `vX.Y.Z`. It falls back to the working copy when that tag does not carry the
+file, and says so. The report says which of the two it used, on its front page,
+because a checklist from a moving branch is a weaker basis than one from a tag.
+
+## What counts as a test
+
+Two kinds of line:
+
+* every `- [ ]` tick box
+* rows in the tables that list things to test
+
+A table is a list of tests when its **first column heading** says so: `Module`, `Setting`,
+`BO tab`. Everything else, product types, profiles, breakpoints, the severity table, the list of
+sources the checklist is derived from, is reference material. `checklist.js` prints its decision
+for every table it meets, with the heading that decided it, so a wrong call is visible instead of
+silently adding or dropping tests.
+
+## Points that change a shop setting
+
+The checklist marks them, and it does so in two ways. Some points carry `(config)` themselves.
+Some sections say it once in their own prose, either "everything in this section is (config)" or,
+as in the multishipment section, by turning a feature flag on for the whole section. Both are
+picked up, and a section that declares it passes it down to its subsections, which is where the
+points actually live.
+
+Over-marking a point costs one reading of a setting. Under-marking it leaves the shop altered for
+every section that follows, so the reading errs towards marking, and prints the line that decided
+it.
+
+## How a point is named
+
+`3.2/07` is the seventh testable line of section 3.2. That name is convenient and, on its own,
+a trap: add one line at the top of a section and every number below it shifts, quietly attaching
+yesterday's results to the wrong test.
+
+So a point is identified by **its text as well as its position**. `checklist.json` carries a hash
+of each point's text, and comparing two revisions matches on that first:
+
+```bash
+node "$SKILL_DIR/scripts/checklist.js" --diff old.json new.json
+```
+
+It reports additions, removals and moves, naming both the old and the new number for every move.
+Read the moves before reusing anything written against the older revision.
+
+## Staying in step with the theme
+
+The theme's own `CONTEXT.md` binds the checklist to the code: change the hook assignments in
+`config/theme.yml`, add or remove a module override, add a page or a partial, or change the
+breakpoints, and the checklist changes in the same pull request.
+
+So this skill never needs updating when the theme grows a page or a module. What it does need is
+for the campaign to read the checklist belonging to the version under test, which is why the tag
+matters. If a checklist point turns out to be wrong, that is a correction to propose against the
+theme repository, not a finding against the theme: answer that point `inconclusive` with the
+reason, list it under `checklistCorrections`, and open no ticket. The full rule is in
+[reporting.md](reporting.md).

qa/dev/hummingbird-theme-qa/references/design.md

@@ -0,0 +1,101 @@
+# How the report looks
+
+`report.js` writes the whole of this into the page as one `<style>` block. Nothing is fetched, so
+the report opens with no network and reads the same in a year. Change a value here and change it
+there, or this file becomes a description of something that no longer exists.
+
+## The one idea
+
+**The reader is deciding whether to trust the campaign**, not admiring it. So the page leads with
+how much was actually covered, not with a score, and every claim sits next to the thing that
+backs it. Nothing is styled to look reassuring.
+
+## Colour
+
+| Token | Light | Used for |
+| --- | --- | --- |
+| `--ink` | `#1d1d1f` | text |
+| `--muted` | `#6b6b70` | labels, captions, anything secondary |
+| `--line` | `#e3e3e6` | the only border in the system |
+| `--bg` | `#fff` | the page |
+| `--panel` | `#f6f6f8` | cards, table headings, findings |
+| `--ok` | `#1d7a46` | settled and holding |
+| `--bad` | `#c0233c` | settled and not holding, and blocker |
+| `--look` | `#8a5a00` | waiting for a person, and major |
+| `--flat` | `#6b6b70` | not covered, and minor |
+
+In the coverage bar, not-covered and partly-covered are the same grey at two
+strengths: 55% for partly covered, 20% for never looked at. They are the same
+kind of absence, in two amounts, and neither is allowed to read as a colour that
+means something happened.
+
+Every one is redefined for a dark screen, and again under an explicit dark choice, so the page
+follows the reader's setting in both directions. `body` paints its own background: a transparent
+page borrows whatever is behind it and stops being legible.
+
+**Waiting for a person is not a warning colour by accident.** It is the amber of something
+unfinished, because that is what it is, and a report where half the checklist sits in amber is
+telling the truth about itself.
+
+## The coverage bar
+
+Under the five headline numbers, one bar the width of the page, divided by how
+many checklist points ended in each state. It is the first thing a reader sees
+after the counts, and it is there to make a thin campaign look thin: a bar that
+is two thirds grey cannot be read as a pass.
+
+**It carries counts, never a percentage.** Each segment names its own number in
+its tooltip, the legend under it repeats all of them as text, and the whole bar
+has one label for a screen reader. Nothing about it depends on telling the
+colours apart.
+
+## The proof table
+
+Two hundred rows in one block is a wall. One block per checklist section, each
+opening with the section number, its title, and its own tally: *3 of 8 settled,
+2 waiting for a person, 3 not covered*. A section that went badly is visible
+without reading a single row of it.
+
+Above the table, two buttons: everything, or only what is not settled and
+holding. They are hidden until the script that drives them has run, so the table
+is whole and readable with no scripting at all. The script loads from nowhere,
+hides rows, and does nothing else.
+
+## Getting around
+
+A row of links under the title, one per section of the report. Plain text, no
+box, no colour until hovered. A report of this length is read by jumping to the
+part someone is arguing about.
+
+## Printing
+
+A QA report gets printed and passed around, so there is a print block: ink on
+white, the navigation and the filter gone, the table unfolded rather than
+scrolled, and a finding never split across two pages.
+
+## Type and space
+
+The reader's own interface face, reached through the system stack so nothing is downloaded.
+Every length in `rem`, so a reader who has set a larger default gets it.
+
+Sections are separated by a rule and generous space above the heading, never by a box. The only
+boxes are the five headline cards, the findings, and the warnings, which earn one because they
+interrupt.
+
+## Layout
+
+One column, at most `74rem`, with a gutter that never disappears. Everything reflows at phone
+width: the cards, the environment list and the finding panels all wrap to one column, and only
+the proof-of-test table scrolls sideways, inside its own frame. The page itself never scrolls
+sideways at any width, which is checked the same way the campaign checks the theme.
+
+## What it must never do
+
+* Show a single percentage. Points and cells are different units and mixing them into one figure
+  is how a partial campaign starts looking complete. The coverage bar shows proportions because
+  that is the shape of the campaign, but every number next to it is a count.
+* Colour a partly covered point green, or fold it into the settled count.
+* Show a finding without the evidence beside it.
+* Load anything from outside itself, script included.
+* Need scripting to be readable. Everything the script does is a convenience over a page that is
+  already complete.