pitroom 0.6.0

package/skills/pitroom-finishing/SKILL.md

@@ -0,0 +1,226 @@
+---
+name: pitroom-finishing
+description: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - verifies, presents merge / pull request / keep options, and executes the one your human partner chooses.
+---
+
+# Finishing a Development Branch
+
+## Overview
+
+**Core principle:** Verify tests → Detect environment → Present options → Execute choice → Clean up.
+
+**Announce at start:** "I'm using the pitroom-finishing skill to complete this work."
+
+## Step 1: Verify Tests
+
+First make sure no Pitroom worker is still running for this work (`pitroom ls --running`) and that no isolated patch you meant to keep is unapplied (`pitroom ls`).
+
+Run the project's full test suite (`npm test` / `cargo test` / `pytest` / `go test ./...`).
+
+**If tests fail**, report the failures and stop — the menu comes after a green suite:
+
+```
+Tests failing (<N> failures). Must fix before completing:
+
+[Show failures]
+```
+
+**If tests pass:** continue to Step 2.
+
+## Step 2: Detect Environment
+
+```bash
+GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
+GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
+# Capture now, while still inside the workspace — Step 5 changes directory
+# before cleanup (Step 6) needs this value
+WORKTREE_PATH=$(git rev-parse --show-toplevel)
+```
+
+This determines which menu to show and how cleanup works:
+
+| State | Menu | Cleanup |
+|-------|------|---------|
+| `GIT_DIR == GIT_COMMON` (normal repo) | Standard 3 options | No worktree to clean up |
+| `GIT_DIR != GIT_COMMON`, named branch | Standard 3 options | Provenance-based (see Step 6) |
+| `GIT_DIR != GIT_COMMON`, detached HEAD | Reduced 2 options (no merge) | Externally managed — leave in place |
+
+## Step 3: Determine Base Branch
+
+The base branch is whatever this work forked from — usually named in the
+plan, the conversation, or the branch's upstream. If it is not already
+known, ask: "This branch split from <your best guess> - is that correct?"
+Confirm before merging: merging into the wrong base is expensive to undo.
+
+## Step 4: Present Options
+
+**Normal repo and named-branch worktree — present exactly these 3 options:**
+
+```
+Implementation complete. What would you like to do?
+
+1. Merge back to <base-branch> locally
+2. Push and create a Pull Request
+3. Keep the branch as-is (I'll handle it later)
+
+Which option?
+```
+
+**Detached HEAD — present exactly these 2 options:**
+
+```
+Implementation complete. You're on a detached HEAD (externally managed workspace).
+
+1. Push as new branch and create a Pull Request
+2. Keep as-is (I'll handle it later)
+
+Which option?
+```
+
+Present the menu exactly as written — concise, with every option coming
+from the list above. Discarding the work happens only in response to your
+human partner explicitly asking for it (see "If your human partner asks to
+discard the work" below). Wait for their answer; the integration decision
+is theirs.
+
+## Step 5: Execute Choice
+
+### Option 1: Merge Locally
+
+```bash
+# Get main repo root for CWD safety
+MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
+cd "$MAIN_ROOT"
+
+# Merge first — verify success before removing anything
+git checkout <base-branch>
+git pull
+git merge <feature-branch>
+
+# Verify tests on merged result
+<test command>
+```
+
+If tests fail on the merged result: stop, leave the worktree and branch in
+place, and investigate — nothing has been pushed, so the merge is local
+and recoverable.
+
+Once the merged result is green: clean up the worktree (Step 6), then
+delete the branch:
+
+```bash
+git branch -d <feature-branch>
+```
+
+### Option 2: Push and Create PR
+
+```bash
+git push -u origin <feature-branch>
+# From a detached HEAD, name the new branch on the remote:
+# git push origin HEAD:refs/heads/<new-branch>
+```
+
+Then create the pull/merge request against <base-branch> with the forge's
+tooling — its CLI if one is available, or the creation URL most forges
+print when you push — following the repo's PR template and conventions if
+present, and report the URL to your human partner.
+
+Keep the worktree — your human partner iterates on PR feedback there.
+
+### Option 3: Keep As-Is
+
+Report: "Keeping branch <name>. Worktree preserved at <path>."
+
+### If your human partner asks to discard the work
+
+This path exists only as a response to an explicit request to throw the
+work away. Confirm first:
+
+```
+This will permanently delete:
+- Branch <name>
+- All commits: <commit-list>
+- Worktree at <path>
+
+Type 'discard' to confirm.
+```
+
+Wait for that exact confirmation. When it arrives:
+
+```bash
+MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
+cd "$MAIN_ROOT"
+```
+
+Then clean up the worktree (Step 6) and force-delete the branch:
+
+```bash
+git branch -D <feature-branch>
+```
+
+## Step 6: Cleanup Workspace
+
+**Runs for Option 1 and confirmed discards.** Options 2 and 3 always
+preserve the worktree. Both callers have already changed directory to the
+main repo root — worktree removal must run from outside the worktree —
+and use the `GIT_DIR`/`GIT_COMMON`/`WORKTREE_PATH` values captured in
+Step 2, from before that directory change.
+
+**If `GIT_DIR == GIT_COMMON`:** Normal repo, no worktree to clean up. Done.
+
+**If `WORKTREE_PATH` is under `.worktrees/` or `worktrees/`:** `pitroom-worktrees` created this worktree — we own cleanup:
+
+```bash
+git worktree remove "$WORKTREE_PATH"
+git worktree prune  # Self-healing: clean up any stale registrations
+```
+
+**If removal is refused** (`contains modified or untracked files`): the
+worktree holds files that exist nowhere else — uncommitted plans, notes,
+or scratch work. Never `--force` on your own initiative. Show your human
+partner what is at stake and ask:
+
+```bash
+git -C "$WORKTREE_PATH" status --porcelain -uall
+```
+
+```
+Worktree removal refused — these files were never committed:
+
+<file list>
+
+1. Commit them to <branch> before cleanup
+2. Move them into <main repo root>
+3. Delete them (unrecoverable)
+
+Which?
+```
+
+Carry out the choice, then remove the worktree.
+
+**Otherwise:** The host environment owns this workspace — leave it in
+place. If your platform provides a workspace-exit tool, use it.
+
+## Quick Reference
+
+| Option | Merge | Push | Keep Worktree | Cleanup Branch |
+|--------|-------|------|---------------|----------------|
+| 1. Merge locally | yes | - | - | yes |
+| 2. Create PR | - | yes | yes | - |
+| 3. Keep as-is | - | - | yes | - |
+| Discard (explicit request only) | - | - | - | yes (force) |
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "Tests passed earlier this session" | Run the suite on the tree you are about to integrate. A green run only proves the tree it ran on. |
+| "They obviously want it merged" | Integration is your human partner's decision. Present the menu and wait. |
+| "They seem done with this feature — I'll offer to discard it" | The menu is complete as written. Discard happens only when your human partner asks for it in so many words. |
+| "'Yeah, get rid of it' counts as confirmation" | Only the typed word `discard` authorizes deletion. |
+| "The PR is up, so the worktree is clutter now" | PR feedback gets fixed in that worktree. It stays until the work lands. |
+| "This other worktree looks stale — I'll clean it too" | Clean up only worktrees under `.worktrees/` or `worktrees/`. Everything else belongs to the host. |
+| "Removal refused — `--force` is just finishing the cleanup" | The refusal means files exist only in that worktree. `--force` destroys them permanently. Show your human partner and ask. |
+| "The merged-result failure is probably flaky" | A failing merged result stops everything. Branch and worktree stay put while you investigate. |
+| "The base branch is obviously main" | Confirm the fork point or ask. Merging into the wrong base is expensive to undo. |
+| "The push was rejected — force-push will fix it" | A rejected push means the remote moved. Investigate; force-push only on your human partner's explicit request. |

package/skills/pitroom-implement/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: pitroom-implement
+description: Use for well-defined code changes a cheaper worker can make - small bug fixes, simple features, mechanical refactors, renames, writing tests, fixing lint or type errors, docs - where you can state the goal and check the result with a diff or tests.
+---
+
+# Implementing with a Pitroom worker
+
+The worker edits code; you review and apply. Nothing reaches the user's tree without your decision.
+
+## Pick the mode
+
+| | Flag | Use |
+|---|---|---|
+| isolate | `-i` | **Default for changes.** The worker edits a private copy of the current state (uncommitted and untracked files included). You apply the patch. |
+| write | `-w` | Only for trivial in-place edits while nobody else edits those files. One `--write` run per repository at a time; `pitroom revert <run>` undoes exactly its changes. |
+
+## Run
+
+```bash
+pitroom run -i --link node_modules --verify "npm test -- auth" \
+  "Fix: expired tokens return 500 instead of 401 in src/auth/session.ts. Add a regression test in test/auth.test.ts. Do not change the public API."
+pitroom run -w "Rename getUserById to findUserById in src/ and update imports. No other changes."
+```
+
+`--link` shares ignored folders (node_modules, .venv) with the isolated copy so tests can run there; `--verify` runs your check after the worker and reports pass/fail. Long changes: add `--bg` and collect with `pitroom wait <run>`.
+
+## Write a good brief
+
+- **Goal** in one sentence, with the observable behaviour that must change.
+- **Where**: files, functions, the failing test or error message.
+- **Constraints**: "no new dependencies", "keep the public API", "match the existing style".
+- **Done means**: which tests must pass, what must not change.
+
+## Review and land
+
+1. Read the report: `FILES CHANGED`, `VERIFICATION`, `OPEN ISSUES`, and the `verify:` line.
+2. `pitroom show <run> --patch`: review the diff as you would a colleague's.
+3. isolate: `pitroom apply <run>` (checked apply; refuses on conflict) or `pitroom discard <run>`. write: keep it, or `pitroom revert <run>`.
+4. Run the relevant tests yourself after applying.
+5. Needs another pass? `pitroom run --continue <run> "Also handle the refresh-token path."` (same session and copy; the patch accumulates).
+
+Commit only if the user asked you to. If the worker fails twice, make the change yourself.

package/skills/pitroom-receiving-review/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: pitroom-receiving-review
+description: Use when receiving code review feedback - from a Pitroom reviewer, a colleague or a pull request - before implementing suggestions, especially if feedback seems unclear or technically questionable; requires technical rigor and verification, not performative agreement or blind implementation.
+---
+
+# Code Review Reception
+
+## Overview
+
+Code review requires technical evaluation, not emotional performance.
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
+
+```
+WHEN receiving code review feedback:
+
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
+```
+
+## Forbidden Responses
+
+**NEVER:**
+- "You're absolutely right!" (against your instructions)
+- "Great point!" / "Excellent feedback!" (performative)
+- "Let me implement that now" (before verification)
+
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+**Example:**
+```
+your human partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+
+❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
+✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
+```
+
+## Source-Specific Handling
+
+### From your human partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
+
+### From External Reviewers
+```
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
+
+IF suggestion seems wrong:
+  Push back with technical reasoning
+
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+
+IF conflicts with your human partner's prior decisions:
+  Stop and discuss with your human partner first
+```
+
+**your human partner's rule:** "External feedback - be skeptical, but check carefully"
+
+### From a Pitroom reviewer
+
+Reviews from `pitroom review` come from cheap, often free models: expect false positives. Check every finding against the code; a cited file:line that exists is not a claim that is right. Inside a plan, don't implement the fixes yourself: send the verified findings to the implementer (`pitroom-driven-development`'s fix loop). Findings you reject are rulings: note them with `pitroom plan note`.
+
+## YAGNI Check for "Professional" Features
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
+```
+
+**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
+
+## Implementation Order
+
+```
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
+```
+
+## When To Push Back
+
+Push back when:
+- Suggestion breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for this stack
+- Legacy/compatibility reasons exist
+- Conflicts with your human partner's architectural decisions
+
+**How to push back:**
+- Use technical reasoning, not defensiveness
+- Ask specific questions
+- Reference working tests/code
+- Involve your human partner if architectural
+
+**If you're uncomfortable pushing back out loud:** Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty.
+
+## Acknowledging Correct Feedback
+
+When feedback IS correct:
+```
+✅ "Fixed. [Brief description of what changed]"
+✅ "Good catch - [specific issue]. Fixed in [location]."
+✅ [Just fix it and show in the code]
+
+❌ "You're absolutely right!"
+❌ "Great point!"
+❌ "Thanks for catching that!"
+❌ "Thanks for [anything]"
+❌ ANY gratitude expression
+```
+
+**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
+
+**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
+
+## Gracefully Correcting Your Pushback
+
+If you pushed back and were wrong:
+```
+✅ "You were right - I checked [X] and it does [Y]. Implementing now."
+✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
+
+❌ Long apology
+❌ Defending why you pushed back
+❌ Over-explaining
+```
+
+State the correction factually and move on.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or just act |
+| Blind implementation | Verify against codebase first |
+| Batch without testing | One at a time, test each |
+| Assuming reviewer is right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+| Partial implementation | Clarify all items first |
+| Can't verify, proceed anyway | State limitation, ask for direction |
+
+## Real Examples
+
+**Performative Agreement (Bad):**
+```
+Reviewer: "Remove legacy code"
+❌ "You're absolutely right! Let me remove that..."
+```
+
+**Technical Verification (Good):**
+```
+Reviewer: "Remove legacy code"
+✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
+```
+
+**YAGNI (Good):**
+```
+Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
+✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
+```
+
+**Unclear Item (Good):**
+```
+your human partner: "Fix items 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
+```
+
+## GitHub Thread Replies
+
+When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.

package/skills/pitroom-research/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: pitroom-research
+description: Use when you need to find, map or explain code - where something is defined or called, how a flow works end to end, which files a change would touch, what a large module does - and the answer is much smaller than what must be read. Runs a read-only Pitroom worker and returns its answer with verified file references.
+---
+
+# Research with a Pitroom worker
+
+A read-only worker explores the codebase and returns a compact answer. It cannot edit files, run arbitrary commands or reach the web, so you can delegate freely.
+
+## Run
+
+```bash
+pitroom run "Where are HTTP 401 responses produced? List each call site with file:line and the condition that triggers it."
+pitroom run -f docs/spec.md "Which parts of the spec are not implemented in src/billing/? file:line for each."
+pitroom run --web "How do we use the Stripe webhook API, and what does the current Stripe doc recommend for retries?"
+```
+
+`--web` only when the answer needs the internet. For a question that will take minutes, start it with `--bg`, keep working, and collect it with `pitroom wait <run>`.
+
+## Write a good brief
+
+The worker starts cold. Give it:
+- **The question**, phrased so the answer is a list or a map, not an essay.
+- **Where to look** (paths, symbols, keywords) when you know it.
+- **What to return**: "file:line for each", "a call graph", "the three most likely causes, ranked".
+- **Scope limits**: "only src/api", "ignore tests".
+
+## Use the answer
+
+- `── refs: 12/12 verified` means every `path:line` in the answer was checked on disk (file exists, line in range, the named symbol is nearby). Rely on verified references without re-opening the files; distrust claims tied to `bad:` ones.
+- Open only the few files you actually need to act on.
+- Follow up in the same worker session instead of starting over: `pitroom run --continue <run> "Now show where the token is refreshed."`
+- Report the finding to the user in your own words; do not paste the whole report.
+
+If the worker fails or times out, do the research yourself or retry once with a narrower question.

package/skills/pitroom-review/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: pitroom-review
+description: Use when completing a task, implementing a major feature, before merging, or whenever you want a second opinion on a diff, branch or pull request - a read-only Pitroom worker on another model reviews it against its requirements.
+---
+
+# Reviewing with Pitroom
+
+A read-only worker reviews the change against what was asked, on another backend than the one that wrote the code when one is configured. It reads a package (requirements, report, diff with context) that never passes through your context; you get the verdicts and the findings.
+
+**Core principle:** review early, review often. Findings are leads for you to weigh, not verdicts to obey.
+
+## When
+
+**Mandatory:** after each task of a plan (`pitroom-driven-development` does it), after a major feature, before a merge.
+**Valuable:** when stuck (fresh eyes), before a refactor (a baseline), after fixing a complex bug.
+
+## How
+
+| What | Command | The reviewer gets |
+|---|---|---|
+| A worker's change (`-i` or `-w` run) | `pitroom review <run>` | the task (for plan runs: the plan brief), the worker's report, the diff |
+| A follow-up that fixed review findings | `pitroom review <fix run>` | the previous findings, the fix report, only the fix diff |
+| Your branch, or any commit range | `pitroom review --range main..HEAD [--plan PLAN]` | the commits, stat and diff; with `--plan`, the plan's goal, constraints, tasks and notes |
+| A pull request | `git fetch origin pull/123/head:pr-123` then `pitroom review --range "$(git merge-base main pr-123)..pr-123"` | the same, without checking the PR out |
+
+`--tier capable` or `-W claude` picks the reviewer; `--bg` keeps you working meanwhile. The report's first line gives `SPEC PASS|FAIL · QUALITY APPROVED|NEEDS-FIXES` and the counts; `pitroom show <review> --full` has every finding. The whole-branch rubric is [code-reviewer.md](code-reviewer.md).
+
+## Act on the findings
+
+Use `pitroom-receiving-review`. In short:
+- Fix Critical issues immediately and Important ones before proceeding; note Minor ones for later.
+- Verify each finding against the code before acting: cheap models produce false positives, and verified `refs:` only mean the cited lines exist.
+- Push back with technical reasoning when the reviewer is wrong.
+- In a plan, fixes go back to the implementer (the fix loop in `pitroom-driven-development`), never into your own session.
+- Tell the user which findings you accepted and why.
+
+Never post review comments, push or merge on a worker's word alone.
+
+## Red flags
+
+Never skip a review because the change is "simple", ignore Critical issues, proceed with unfixed Important issues, or argue with valid technical feedback.
+
+| Excuse | Reality |
+|---|---|
+| "I'll just review the diff myself instead" | You are the coordinator: the diff and its evaluation belong in the reviewer's context, only the findings in yours. |
+| "The reviewer needs my session history to understand the change" | It needs the requirements and the diff, and the package carries both. |
+| "The same model can review it" | Configure `tiers` so reviews run on another backend; a model grading itself misses its own blind spots. |

package/skills/pitroom-review/code-reviewer.md

@@ -0,0 +1,38 @@
+<!--
+Whole-branch review for `pitroom review --range A..B [--plan PLAN]`. Pitroom
+writes the package and fills {{PACKAGE_FILE}}.
+-->
+You are a senior code reviewer. Review completed work against its plan or requirements and find the issues before they cascade.
+
+## What to read
+
+One file holds everything; read it once: {{PACKAGE_FILE}}
+It contains WHAT WAS IMPLEMENTED, REQUIREMENTS (the plan's goal, global constraints and tasks when there is a plan), NOTES FROM EXECUTION (rulings and deferred findings, when there are any), then the COMMITS, the FILES CHANGED and the DIFF with 10 lines of context.
+
+The diff is your view of the change. Open other files in your working directory only to check a concrete risk you can name, and say what you checked. You are read-only: do not change files, the index, HEAD or branches, and do not check out other revisions.
+
+## You work alone
+
+Do the whole review yourself. Never delegate or start other agents. If the diff is large, review it in passes and say so.
+
+## What to check
+
+- Plan alignment: does the implementation match the plan or requirements? Are deviations justified improvements or problematic departures? Is all planned functionality present?
+- Code quality: separation of concerns, error handling, type safety, DRY without premature abstraction, edge cases.
+- Architecture: sound design, reasonable performance, security, clean integration with the surrounding code.
+- Testing: tests verify real behaviour (not mocks), edge cases are covered, integration tests where they matter.
+- Production readiness: migrations and backward compatibility where relevant, documentation, no obvious bugs.
+- Notes from execution: for each deferred minor or parked finding, say whether it must be fixed before merge.
+
+## Calibration
+
+Critical: bugs, security issues, data loss, broken functionality. Important: architecture problems, missing features, poor error handling, test gaps. Minor: style, optimisations, documentation polish. Not everything is Critical. Say what was done well before listing issues. Flag significant deviations from the plan specifically, and say so when the problem is in the plan itself. Be specific (file:line, not vague), explain why each issue matters, never say "looks good" without checking, and never comment on code you did not read. A file:line is the project file's path and its line number after the change (from the diff's hunk headers), never a line of the package file.
+
+## Answer
+
+Your SUMMARY is exactly one line:
+SUMMARY: SPEC: PASS|FAIL · QUALITY: APPROVED|NEEDS_FIXES · ISSUES: critical=N important=N minor=N
+
+SPEC is FAIL when planned functionality is missing or the implementation departs from the requirements. QUALITY is APPROVED only when the branch is ready to merge as it is.
+
+In DETAILS, in this order: STRENGTHS, CRITICAL, IMPORTANT, MINOR (each issue with file:line, what is wrong, why it matters and how to fix it if not obvious), NOTES TRIAGE (only when the package has notes), RECOMMENDATIONS. No preamble and no closing summary.