Merge branch 'main' into fix/date-validation-572

Author: SinghCharanjeet11

CHANGELOG.md

@@ -215,3 +215,52 @@ This part is performed manually by maintainers when it's time to publish a new v
 3.  **Chrome Web Store Deployment**: Publishing the release triggers the "Publish to Chrome Web Store" workflow, which automatically packages the extension and uploads it for review.
 
 ### If you encounter any bugs, please report them at the [Issues page](https://github.com/fossasia/scrum_helper/issues).
+
+## AI-Assisted Contributions Guidelines
+
+This project is receiving an increasing number of AI-assisted contributions. While we welcome the productivity AI tools bring, we require all contributions to maintain our standards for quality, intentionality, and maintainability. To ensure a high signal-to-noise ratio in our repository, please adhere to the following guidelines.
+
+### Expectations from Contributors
+
+* **You must understand your code:** We expect human judgment to be the final filter. You take full responsibility for every line you submit.
+* **You must be able to explain:** If asked by a maintainer, you should be able to explicitly explain what your change does, why it is necessary, and how it integrates with the rest of the codebase.
+* **Code must be:** 
+  * Thoroughly tested
+  * Manually validated in a real browser environment
+  * Aligned with our existing architecture and codebase patterns
+
+### What We Do NOT Accept
+
+* PRs submitted without a clear use case or a linked, pre-approved issue.
+* AI-generated code pasted blindly without deep comprehension.
+* Duplicate PRs or attempts at solving issues that are already being handled.
+* Surface-level "fixes" (e.g., unprompted refactoring, nitpicks) without solid reasoning.
+* Features or abstractions that increase overall complexity without delivering tangible user value.
+
+### PR Requirements
+
+* **Linked Issue:** Every PR (unless it is a trivial typo fix) must be linked to an existing issue.
+* **Clear Description:** Provide a well-reasoned description detailing the problem and your solution. Do not paste AI-generated summaries of file diffs.
+* **Existing Patterns:** Follow the established project conventions implicitly. 
+* **Avoid Complexity:** Keep changes as minimal and focused as possible.
+
+### AI Best Practices Table
+
+| Area | Good Contribution | Poor Contribution |
+| :--- | :--- | :--- |
+| **Problem selection** | Solving a verified, pre-existing issue that you understand and ideally have encountered. | Submitting unrequested "improvements" or claiming random issues without a real-world use case. |
+| **Understanding** | Using AI to learn the codebase or brainstorm approaches, then writing/refining the final logic yourself. | Over-delegating to AI; submitting logic that you cannot confidently explain or debug. |
+| **Code quality** | Focused, minimal changes that address the exact problem efficiently. | Bloated PRs that introduce unnecessary code churn or rewrite entire blocks out of context. |
+| **Architecture** | Conforming strictly to the established design patterns and utilities of the project. | Hallucinating new dependencies or forcing foreign paradigms into the codebase. |
+| **Validation** | Manually compiling and verifying the extension works, and writing reliable tests. | Submitting code that has never been tested locally or fails basic linting. |
+| **Maintainability** | The implemented solution is simpler for us to maintain than the problem it solves. | Adding excessive "clever" complexity that increases the maintainer's review burden. |
+| **PR description** | Writing a clear, human-authored explanation of the *why* behind your changes. Including screenshots of your changes.| Pasting a generic, AI-generated summary of the modified files without context. |
+| **AI usage** | Disclosing your use of generative tools and verifying that the output makes sense. | Failing to review AI output, resulting in regressions or confidently incorrect logic. |
+
+### Maintainer Policy
+
+* We reserve the right to close low-quality or fully automated PRs that fail to meet these guidelines without extensive review.
+* PRs containing features not aligned with our current priorities or roadmap may be closed.
+* Contributors are strongly encouraged to pick well-defined, triaged issues to ensure their time and effort result in a successful merge.
+
+

README.md

@@ -0,0 +1,58 @@
+# Rules for AI-assisted contributions
+
+Scrum Helper accepts AI-assisted contributions, but all submissions must meet project standards. The contributor submitting the PR is fully responsible for correctness, scope, and validation.
+
+For setup and contribution process details, see [CONTRIBUTING.md](CONTRIBUTING.md).
+
+## Required rules
+
+### 1) Understand and explain every change
+
+- You must be able to explain what changed, why it changed, and how it interacts with existing code paths (popup, service worker/background, content scripts, GitHub API, i18n, and browser-specific build outputs).
+- If you cannot explain a change, do not submit it.
+
+### 2) Keep changes minimal and in scope
+
+- Keep PRs tightly scoped to the stated bugfix or improvement.
+- Do not include unrelated cleanup, drive-by refactors, formatting-only churn, or file moves unrelated to the task.
+- Do not modify generated outputs or unrelated files unless the task explicitly requires it.
+
+### 3) No new feature without a linked issue
+
+- New features must reference a linked GitHub issue in the PR.
+- If no issue exists, open one first and align scope before implementation.
+- Bug fixes and maintenance changes should still include clear problem context in the PR description.
+
+### 4) No blind AI output
+
+- Do not paste AI-generated code without reviewing and testing it.
+- Follow existing architecture, naming, structure, and error-handling patterns in nearby code.
+- Reuse existing helpers before adding new abstractions or duplicate implementations.
+
+### 5) Mandatory validation before PR update
+
+Run these commands locally after your changes and before opening/updating a PR:
+
+```sh
+npm run lint
+npm run check
+npm run build
+```
+
+Additional expectations:
+
+- If lint/check fails, fix issues before requesting review.
+- Reload and verify the built extension from `dist/chrome` and/or `dist/firefox` for the user-facing behavior you changed.
+- Validate edge cases relevant to your change (empty states, missing token/auth, API failures, rate limits, and large result sets where applicable).
+
+## Pull request requirements
+
+- Use a clear PR title and description with problem, approach, and validation evidence.
+- List the exact validation steps you ran and outcomes.
+- If maintainer feedback conflicts with an AI suggestion, follow maintainer direction.
+
+## Why these rules exist
+
+- Reduce maintainer overhead from speculative or low-signal PRs.
+- Prevent regressions from unverified AI-generated changes.
+- Keep the codebase consistent, reviewable, and aligned with project direction.

agents.md

@@ -26,9 +26,9 @@
   },
   "homepage": "https://github.com/fossasia/scrum_helper",
   "devDependencies": {
-    "@biomejs/biome": "2.4.10",
+    "@biomejs/biome": "2.4.11",
     "autoprefixer": "^10.4.27",
-    "postcss": "^8.5.8",
+    "postcss": "^8.5.9",
     "tailwindcss": "^4.2.2"
   },
   "dependencies": {