feat: add Claude Code rules for UI evidence, task completion, GitHub access, and PR management

Add four rule files to .claude/rules/ to codify development workflow expectations:
- UI changes require automated screenshot evidence in PRs and docs
- Tasks must have passing CI and tests matching the user's request
- GitHub token permissions for the nsheaps organization
- PR lifecycle management including draft-only creation and body updates after every push

https://claude.ai/code/session_01SaZuyTFLGaCcnox7B4ghsN

Author: claude

.claude/rules/github-token-access.md

@@ -0,0 +1,9 @@
+# GitHub Token Access
+
+Your environment includes a GitHub token with the following permissions:
+
+- **Read access** across the entire `nsheaps` GitHub organization (all repositories).
+- **Write access** to create and edit issues and pull requests in any repository within the organization.
+- You may act as the user (`nsheaps`) when interacting with GitHub via `gh` CLI or the GitHub API.
+
+Use these permissions to look up context in related repositories, cross-reference issues, and manage PRs and issues as needed.

.claude/rules/pr-management.md

@@ -0,0 +1,19 @@
+# Pull Request Management
+
+## PR Body and Title Updates (CRITICAL)
+
+After EVERY push, you MUST review the PR title and body and update them to accurately reflect the full set of changes in the PR:
+
+- The PR title and body describe the **cumulative changes** in the PR and how they relate to the user's original request. They are NOT a description of the most recent commit or push.
+- Before updating, evaluate the full commit history, commit messages, and diffs on the branch so you properly understand the complete scope of changes.
+- Keep the PR title concise (under 70 characters) and the body well-structured with a summary and test plan.
+
+## PR Lifecycle (CRITICAL)
+
+You are expected to open and maintain PRs. Follow these rules:
+
+1. **Open PRs in draft**: Always create PRs in draft state (`gh pr create --draft`). Never move a PR from draft to ready-for-review — that is the user's responsibility.
+2. **Assign nsheaps**: Always assign `nsheaps` as a reviewer/assignee on PRs you create.
+3. **Keep PRs up to date**: Update the PR title, body, and labels as the branch evolves.
+4. **Close duplicates**: If one PR duplicates functionality from another or resolves an issue, use GitHub magic phrases (e.g., `Closes #123`, `Fixes #456`) in the PR body to link and close appropriately.
+5. **Never mark ready for review**: Do NOT remove the draft status from a PR. Only the user may do that.

.claude/rules/task-completion-criteria.md

@@ -0,0 +1,8 @@
+# Task Completion Criteria
+
+Your task is NOT complete until ALL of the following are satisfied:
+
+1. **CI passes**: All continuous integration checks must be green. If CI fails, investigate and fix the issue before considering the task done.
+2. **Automated test coverage**: New functionality must have automated tests that cover it. Tests must validate the behavior described in the user's initial request.
+3. **Match the initial request**: Tests and implementation must match what the user originally asked for. Do NOT deviate from the initial request or implement beyond it without first discussing the pivot with the user to understand the appropriate direction.
+4. **No scope creep**: If you discover adjacent improvements or refactors that seem valuable but were not requested, raise them with the user rather than implementing them unilaterally.

.claude/rules/ui-screenshot-evidence.md

@@ -0,0 +1,11 @@
+# UI Screenshot Evidence Rule
+
+All UI changes MUST be accompanied by photographic evidence (screenshots).
+
+## Requirements
+
+1. **Screenshot capture**: After making any UI change, capture screenshots demonstrating the change using the E2E screenshot tooling (`bun run test:e2e:screenshots`).
+2. **PR inclusion**: Screenshots MUST be included in the pull request body so reviewers can visually verify the change.
+3. **Documentation automation**: Screenshots MUST be inserted into documentation pages via automation (not manually). This ensures pictures do not become stale or out of date as the UI evolves.
+4. **QA validation**: These automated screenshots also serve as QA validation artifacts. They may be used to verify visual correctness in CI and review workflows.
+5. **No manual screenshot management**: Never manually place or update screenshots in documentation. Always rely on the automated pipeline so that docs stay in sync with the actual UI.