docs: tighten agent and pull request guidance

.github/pull_request_template.md

@@ -8,7 +8,7 @@ Use `Closes #123` when complete, `Refs #123` when related, or `Not applicable` w
 
 ## Verification
 
-Describe tests added or updated, manual scenarios and platforms, useful reviewer reproduction steps, and anything not verified. Do not repeat CI status.
+Describe what focused tests prove first. Introduce manual scenarios with `Manually verified in ...:` and a numbered list that names the platform. End with `Not verified:` when relevant. For documentation-only changes, name the targeted validation performed instead. Do not reproduce CI output, aggregate test counts, coverage reports, or exit codes.
 
 ## Notes
 

AGENTS.md

@@ -2,18 +2,20 @@
 
 ## Workflow And Authorization
 
-- Follow [`CONTRIBUTING.md`](./CONTRIBUTING.md) for documentation authority, issues, project management, branches, commits, pull requests, and releases. Read the relevant sections before acting.
-- Creating an issue or pull request includes triaging it. Read `Maintainer Project Management` and `Pull Requests` before creating either.
+- Use [`CONTRIBUTING.md`](./CONTRIBUTING.md) as the workflow authority. Read [Documentation And Change Authority](./CONTRIBUTING.md#documentation-and-change-authority) before durable documentation or product-behavior changes, [Branches And Commits](./CONTRIBUTING.md#branches-and-commits) before committing, [Pull Requests](./CONTRIBUTING.md#pull-requests) before opening or updating a pull request, and [Maintainer Project Management](./CONTRIBUTING.md#maintainer-project-management) before creating or triaging issues or Project items.
+- Use [Documentation](./docs/README.md#documents) to identify the owning product or engineering document and its precedence before editing durable project guidance.
+- Creating an issue or pull request includes its required triage; do not treat triage as a later step.
 - Treat planning, review, investigation, and diagnosis requests as read-only unless the user explicitly requests implementation or changes.
 - When multiple commits have been agreed, complete and verify each stage before committing it.
 - Never push, create or modify issues or Project items, open or merge pull requests, create tags or releases, or otherwise mutate remote GitHub state without explicit authorization.
-- For release work, also read `.github/workflows/release.yml` and the Release issue reference; `CONTRIBUTING.md` covers release coordination, not automation.
+- For release work, also read the [release workflow](./.github/workflows/release.yml) and [Release issue template](./.github/maintainer-issue-templates/release.md); `CONTRIBUTING.md` covers release coordination, not automation.
 
 ## Core Implementation Rules
 
 - Treat package and crate manifests as the source of truth for dependency versions and available APIs.
 - Prefer features supported by the installed versions and established local patterns. Modernize code being changed when appropriate, but do not modernize unrelated code without an explicit request or agreed scope.
 - Consult current official documentation when API behavior is uncertain.
+- Keep code comments for non-obvious rationale, constraints, or consequences. Do not narrate what the following code does or how it does it when the code already makes that clear.
 
 ## Architecture Boundaries
 
@@ -28,7 +30,7 @@
 - Use `pnpm check:frontend` for frontend-only changes, `pnpm check:backend` for Rust/Tauri-only changes, and `pnpm check` for cross-cutting changes.
 - For documentation-only or repository-metadata changes, run targeted formatting or validation rather than the full application suite unless executable configuration is affected.
 - Do not start browser or application verification for trivial UI or copy-only changes unless requested or the behavior depends on rendered interaction.
-- Reread prose before committing it — code comments, documentation, commit bodies, and pull request text — as a reader who has only the diff, and cut what depends on having been in the session. Rationale a reader cannot recover stays; the account of how it was reached goes.
-- Do not weaken or delete tests, fixtures, snapshots, coverage floors, lint rules, specifications, or acceptance criteria merely to obtain passing checks. Treat a necessary change to the verification oracle as a separate decision and support it with evidence.
+- Reread documentation, commit bodies, and pull request text as durable project records. Keep rationale and constraints a reader cannot recover from the diff; remove session history and accounts of how the work unfolded.
+- When an accepted change supersedes existing behavior or architecture, update or replace the tests, fixtures, snapshots, and specifications that describe it while preserving coverage of behavior that remains required. Treat lower coverage floors, disabled lint rules, or reduced acceptance criteria as separate decisions supported by evidence rather than ways to make checks pass.
 - Terminate any development server or temporary verification process before finishing.
 - Report the checks actually run, their results, and any remaining manual verification in the final response.

src/AGENTS.md

@@ -15,6 +15,7 @@
 ## Styling And UI Primitives
 
 - Reuse theme tokens from `src/App.css` for standard application surfaces, text, borders, focus states, and semantic colors.
+- In CSS files, prefer Tailwind utilities through `@apply` when an equivalent utility expresses the rule clearly. Use raw declarations for custom properties, generated content, unsupported values, or behavior that Tailwind cannot express precisely.
 - Reuse existing primitives from `src/components/ui/` before introducing another component or abstraction.
 - Use `cn` from `src/lib/cn.ts` for conditional Tailwind class composition.
 - When behavior-rich accessible primitives are needed, prefer the installed Radix primitives over recreating interaction, focus, or accessibility behavior.