chore: willboosterify this repo

.cursor/rules/general.mdc

@@ -14,27 +14,34 @@ alwaysApply: true
 - If on `main`, create a new branch; otherwise work on the current branch.
 - Run `git` commands one at a time to avoid `index.lock` conflicts.
 - Write a test only when explicitly requested, or when a behavior is likely to regress and no existing automatic check (type checking, linting, an existing test or CI check) would catch the breakage. Never add a test that merely restates a mapping from conditions to constant outputs (it fails only on intentional edits) or that only confirms an external fact (a library's behavior, whether a version fixes an issue); verify those once manually.
-- When writing tests, follow these rules:
-  - Test externally observable behavior (e.g., emitted files, CLI output, rendered results) at the system boundary, not implementation details: do not mirror production logic, assert that a branch is taken, or feed hand-assembled internal objects to internal functions.
-  - Prefer actual API calls over mocks, unless actual calls are impractical, have unintended side effects, or mocks are explicitly requested.
-  - Ensure tests are idempotent and independent (e.g., reset persistent data) so they can run repeatedly or in parallel.
-  - Avoid fixed waits in E2E tests; wait for conditions instead.
-  - Continue modifying tests and/or code until all tests pass.
+- Test externally observable behavior (e.g., emitted files, CLI output, rendered results) at the system boundary, not implementation details: do not mirror production logic, assert that a branch is taken, or feed hand-assembled internal objects to internal functions.
+- Prefer actual API calls over mocks, unless actual calls are impractical, have unintended side effects, or mocks are explicitly requested.
+- Ensure tests are idempotent and independent (e.g., reset persistent data) so they can run repeatedly or in parallel.
+- Avoid fixed waits in E2E tests; wait for conditions instead.
 - When fixing issues (including test failures), investigate the root cause first (e.g., via debug logs or screenshots) and fix it instead of applying workarounds.
 - After making changes, run `bun run verify` (type checking and linting; up to 10 minutes), or `bun run verify-full` (all tests; up to 1 hour) if you changed runtime behavior or tests. Fix errors and re-run until it passes.
-  - Run verification normally and wait for completion without restarting it. Prefer completion notifications; otherwise use the longest permitted wait. No output does not mean the command has stopped. If the displayed excerpt is insufficient, read the indicated log file before rerunning verification. If the environment kills long-running commands, use detached execution with a saved log and exit status.
+  - Wait for it to finish without restarting it: prefer completion notifications, otherwise the longest permitted wait; no output does not mean it has stopped. If the displayed excerpt is insufficient, read the indicated log file before rerunning. If the environment kills long-running commands, run them detached with a saved log and exit status.
 - Once verified, commit and push to the current (non-main) branch, and create a PR via `gh` if none exists for the branch.
   - Follow the Conventional Commits format (e.g., `feat:`, `fix:`).
-  - End your commit message with a blank line followed by `Co-authored-by: WillBooster (Cursor) <agent@willbooster.com>`.
+  - End your commit message with a blank line followed by `Co-authored-by: WillBooster (Cursor) <agent@willbooster.com>`, the only AI attribution to add.
   - Always create new commits; avoid `--amend`.
-  - Base the PR body on `.github/pull_request_template.md` when creating or updating a PR, even when a skill or workflow supplies its own skeleton: keep the template's headings in order, fill each section with what its placeholder comment asks for at a length fitting the change (a sentence for a small change, numbered subsections for a large one), delete the placeholder comments and an empty Notes section, and keep `Close #<n>` only when the PR resolves an existing issue.
-- When creating an issue, follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither needs no template. The YAML front matter between the `---` lines is metadata, not body text: prefix the title as its `title` says, pass its `labels` via `--label`, and submit only the content below the closing `---` as the body. Always keep the first three sections of `change.md` and add the rest as the change grows; keep Problem and Proposal of `bug.md` and drop Evidence or Impact when they add nothing. Delete the placeholder comments.
-- In any explanatory text (commit messages, PR descriptions, documentation, code comments, etc.), describe only the current implementation: never mention symbols or concepts that were added and later removed or renamed along the way, and drop any statement naming an identifier or feature you cannot confirm exists in the final diff or the current codebase. Whenever you notice documentation or comments that no longer match the current implementation (removed options, deprecated usage, outdated behavior), delete or rewrite them, even in files you are not otherwise changing. Mention a past state only where it is needed to understand why the current design is as it is, or when explicitly asked; files that record history by design (e.g., a changelog) are exempt.
+  - Base the PR body on `.github/pull_request_template.md` when creating or updating a PR, even when a skill or workflow supplies its own skeleton: keep the template's headings in order, fill each section with what its placeholder comment asks for at a length fitting the change (a sentence for a small change, numbered subsections for a large one), and delete the placeholder comments and an empty Notes section. Without a template, use no fixed headings: state the scope, the motivation, and the verification concisely.
+  - Start the body with `Close #<n>` only when the PR resolves an existing issue.
+  - Requirements section: one line per requirement, taken from the requester's instructions as they were given (the issue, the conversation that asked for the change), each marked `required` (asked for, or an existing contract callers depend on) or `chosen` (your own decision, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write `required: not recorded — ask the requester` as the only request-derived line (a `required` line for an existing contract callers depend on may still be listed) and say so in Notes.
+  - Record rule: an existing Requirements section is a record, not a description of the diff. Keep its `required` lines as they are, rewriting them only when the requester's instructions changed (then from the updated instructions, dropping a line only when the requester removed it; with no instructions available, keep them unchanged); add a `chosen` line for a new decision, and replace or remove one when the decision it records changed. A section that merely describes the implementation, or holds only the template's placeholder or a `required: not recorded` line, is not a record: write it afresh by the rule above.
+  - Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.
+  - Never drop or weaken a `required` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.
+- When creating an issue:
+  - Follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.
+  - Title: a Conventional Commits prefix for the type that fits the change (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, ...); when it differs from the template's `title` prefix, replace the template's type label (`t: ...`) with the one matching the type.
+  - The YAML front matter between the `---` lines is metadata, not body text: pass its `labels` via `--label` and submit only the content below the closing `---` as the body.
+- In any explanatory text (commit messages, PR descriptions, documentation, code comments, etc.), describe only the current implementation: drop any statement naming an identifier, feature, or concept you cannot confirm exists in the final diff or the current codebase (e.g., one added and later removed or renamed along the way). Whenever documentation or comments no longer match the current implementation (removed options, deprecated usage, outdated behavior), delete or rewrite them, even in files you are not otherwise changing. Mention a past state only where it is needed to understand why the current design is as it is, or when explicitly asked; files that record history by design (e.g., a changelog) are exempt, and so is the PR body's Requirements section, which records what was asked for rather than what the code contains.
 - Use heredoc for multi-line command input (e.g., `git commit -F -`, `gh pr create --body-file -`, `gh issue create --body-file -`).
 - Put temporary files in `.tmp`; use `/tmp` only for files that must live outside the repo.
 - `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.cursor/rules/general.mdc`, and `.gemini/styleguide.md` are generated from `AGENTS_EXTRA.md` and overwritten on every `wbfy` run; to change agent instructions, edit only `AGENTS_EXTRA.md`.
 - Tool versions (e.g., node) are pinned in `mise.toml`; run `mise install` after changing it and never install those tools globally instead.
 - `bunfig.toml` uses Bun's isolated linker, so only declared dependencies resolve. If an import fails to resolve, declare that package in the `package.json` that imports it; never switch `linker` to `hoisted` or add to `publicHoistPattern` to work around it.
+- Private repositories use self-hosted CI runners. Keep OS/size constraints in an explicit self-hosted label array; fix missing runner capabilities instead of switching to GitHub-hosted runners. The sole approved exception is the Windows desktop build in WillBooster/cheerlings.
 
 ## Coding Style
 

.github/pull_request_template.md

@@ -6,6 +6,10 @@ Close #<IssueNumber>
 
 <!-- The problem, with the numbers or observations behind it, and why this approach over the alternatives. -->
 
+## Requirements
+
+<!-- The requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed. -->
+
 ## Customer Summary
 
 <!-- Behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation. -->