/qa-day — the digest of a day's test sessions

The typical case, one command:

python3 "<plugin root>/skills/qa-day/scripts/qa_day.py" <project root> [<another root> …]

No root given — the current repository. <plugin root> is the plugin's own directory (../qa/references/harness/README.md, «Plugin root»): the path is taken from this very file's own directory (scripts/qa_day.py sits next to this SKILL.md).

The script prints facts out of the session folders; the answer to the user is written by you, not by the script — see «How to deliver it». Nothing here needs configuring: the paths come from the project profile that /qa-setup already wrote, and the digest introduces no key of its own.

The flags

--task searches in two passes: folder names first (*_<id>-*, in the root of <sessions>/ and in the month archives), and only then a grep of the passports. The second pass is what finds a task that was tested inside a multi-task session named after a different task — without it the answer would be «there was no session», which is worse than a slower search.

What the script reads, and what it deliberately does not

• the sessions path per root — sessions: from <root>/.claude/qa-profile.md; no profile or no key → the contract's default docs/test-sessions/. It also picks up language: and prints it per project;
• session folders at two levels — the root of <sessions>/ (what is alive) and its subfolders (the month archives the engine sweeps closed sessions into). A digest that walks one level loses everything from the previous month;
• the day of a session is the date in its FOLDER NAME, never a file's mtime: by the engine's convention the folder is named after the last round and a retest renames it. Consequence, stated plainly because it will come up: a session worked on today whose folder was not renamed is not in the digest. Precedent: a digest built on mtimes counted a session as today's because a typo was fixed in its report, and the day's list stopped matching what the person had actually run;
• the passport and the report — 0-session.md and 99-report.md, falling back to the names earlier schemes used (session.md, report.md, *-report*.md): live projects hold both schemes, and a round that ran under the old one is still a round that happened;
• the passport is localized, so nothing is matched by a field's caption — the parse rests on the template's structure (the - **field:** value rows above the first ##, then the last row of the round log) and prints the values verbatim. The interpreting is yours: that is what makes the digest work in any project language;
• the task ids of a session come from the folder name and the passport's title only, never from the passport's body: the body lists parent tasks, neighbours and past rounds. Precedent: reading ids out of the whole passport reported six tasks for one session, of which one was the session's;
• the registry row — the line in <sessions>/README.md that mentions the folder;
• out of the report — the verdict lines, the count of findings by severity (the untranslated Blocker/Critical/Major/Minor scale is the one anchor a script may match in a localized report) and the tail sections with their own headings, which is where «what is left on the environment» and the open questions live. A project format that has no such section simply has none — that is not an error;
• nothing found is never an error: a missing sessions directory, a folder with no passport, a report with no status each get an honest note: line and the run carries on. One unconfigured project must not cost the digest of all the others.

How to deliver it

1. Group by project, one live line per session: <task ids> <name> — <what was done: the round, the verdict, how many findings>. That is the shape of the answer to «what did I test today»; anything longer is the person doing the reading themselves. Precedent: raw output for one day across two projects ran past a hundred lines, and the question went unanswered until it was retold in five.
2. Name what is left on the environment separately, collected across all the projects — not scattered through the per-session lines. Leftover test entities and changed settings are what the next round's sanity check starts from, and a leftover named in the middle of a session's paragraph is a leftover nobody carries over.
3. Write in the project's language (language, which the script prints for every root). Roots with different languages — keep the whole digest in the language of the first root, the repository the user is sitting in: the digest is addressed to the person, and switching language mid-list serves nobody.
4. Do not dump the raw stdout. It carries the passport's whole header and the report's tail so that you can pick from it; pasting it makes the user the parser.
5. Do not invent what the files do not say. A note: line means exactly what it says — «no passport, status unknown» is a fine thing to report, «probably finished» is not. A session that carries several task ids is reported with all of them.
6. Say what the window was, and add the one caveat when it matters: the day comes from folder names, so a session whose folder was not renamed to today is absent. Volunteering that once is cheaper than the user rebuilding trust in the digest.
7. Close with the action block — ⚠️ for «I cannot answer this without you», 💡 for «worth doing, safe to ignore», each line an action rather than a problem. A digest reads files and asks nothing, so ⚠️ here is almost always absent and that is the correct outcome; the useful lines are 💡: clean up the leftovers named above, rename a folder whose round ran on another day so tomorrow's digest finds it, open the session whose passport is missing. An empty block is not printed at all.

Boundaries

• The digest does not go to the tracker and does not count the queue of tasks: reconciling with a tracker, and writing the result anywhere outside stdout (personal notes, a diary, someone else's files), is project specifics and lives in a project skill. The engine hands over the facts from its own folders, and that is the whole contract.
• It writes nothing — not into the project, not into the sessions. Reading and printing only.
• It introduces no profile key and asks nothing at onboarding: it works from the moment the plugin is installed. A digest that first needs a setup pass is a digest that gets set up on the day someone finally needs it.