From 260775e4976c35ca1f2a0638e2093b56999b2cfa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ademir=20Jos=C3=A9=20Ferreira=20J=C3=BAnior?= Date: Tue, 4 Aug 2026 00:28:14 -0300 Subject: [PATCH 1/4] Clarify agent prose and verification guidance --- AGENTS.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 5d8fdab..ac952a8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -14,6 +14,7 @@ - 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 +29,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. From df761cac4528ade3fb68c3e6bfca4f93fff3b4fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ademir=20Jos=C3=A9=20Ferreira=20J=C3=BAnior?= Date: Tue, 4 Aug 2026 00:28:43 -0300 Subject: [PATCH 2/4] Prefer Tailwind utilities in stylesheets --- src/AGENTS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/AGENTS.md b/src/AGENTS.md index dbbaa4b..423e867 100644 --- a/src/AGENTS.md +++ b/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. From 1a412e4674812277070997ed5d27720371a91598 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ademir=20Jos=C3=A9=20Ferreira=20J=C3=BAnior?= Date: Tue, 4 Aug 2026 00:29:01 -0300 Subject: [PATCH 3/4] Standardize pull request verification guidance --- .github/pull_request_template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index e10a027..34793af 100644 --- a/.github/pull_request_template.md +++ b/.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 From 4b282b7d80d7233cbd594372eec2744468729769 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ademir=20Jos=C3=A9=20Ferreira=20J=C3=BAnior?= Date: Tue, 4 Aug 2026 00:37:28 -0300 Subject: [PATCH 4/4] Route agent work to authoritative guidance --- AGENTS.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index ac952a8..fd6ec79 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,12 +2,13 @@ ## 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