freemo
85ac059489
Remove from SKILL.md and all reference files: - 'Am I choosing between Legacy and v3 plan workflow?' decision tree - LangChain/LangGraph sections (write-code tree, testing tree, code-style README, testing README) - FakeListLLM / MemorySaver / TypedDict LangGraph references - Backwards-compat pre-v3.0.0 policy block (project-version-specific) - v3 ULID format and Backwards-compat-starts rows from Key Numbers table - v3 Plan Lifecycle vs Legacy table from code-style README - Master-tree branch pointing to the v3/legacy workflow tree Generalise across all reference files: - commits/README: pre-commit checklist uses 'task runner session (e.g. nox -s X)' - pull-requests/README: fix approval count 2->1 with self-approval permitted; remove 'neither approver may be original author' (project allows self-approval); generalise automated-checks table command column - testing/README: remove LangChain/LangGraph Testing section; generalise all bare nox commands with task-runner framing and language note at top - code-style/README: rewrite General Principles to language-agnostic tooling guidance; generalise Import Guidelines with Python/Java/TS examples; rename and generalise Type Safety section; remove entire LangChain/LangGraph Best Practices section; remove entire v3 Plan Lifecycle vs Legacy section - security/README: generalise bare nox -s security_scan reference - issue-tracking/README: generalise subtask examples (Behave/nox) ISSUES CLOSED: #0
Pull Request Guidelines
Terminology
PR and MR are interchangeable. This project is hosted on Forgejo, which uses the term Pull Request (PR).
PR Submission Checklist
All 13 requirements must be satisfied before requesting review:
- Detailed description — summary of what was done and motivation for the change
- Closing keyword —
Closes #NorFixes #Nfor each linked issue (one keyword per issue) - Dependency direction — PR blocks the issue; issue depends on the PR (see PR Dependency Direction below)
- One Epic scope per PR — PRs that span multiple Epics must be split
- Atomic, well-scoped commits — each commit follows the commit guidelines
- Commit messages reference tickets — every commit includes
ISSUES CLOSED: #N - Conventional Changelog format — all commits use the correct type/scope/description format
- Changelog updated — one entry per commit
- No build or install artifacts in any commit
- CONTRIBUTORS.md updated if this is your first contribution to the project
- Version bump if applicable (see Versioning below)
- All automated checks pass — task runner full suite passes (see Automated Checks below)
- Correct milestone assigned and exactly one
Type/label applied
Automated Checks Required
All of the following must pass before a PR can be merged. Commands shown are Python/nox examples — replace with your ecosystem's task runner equivalent:
| Check | Example command (Python/nox) | Requirement |
|---|---|---|
| Unit tests | nox -s unit_tests |
All pass |
| Integration tests | nox -s integration_tests |
All pass |
| Linting & formatting | nox -s lint |
Clean |
| Static type checking | nox -s typecheck |
Clean, no suppressions |
| Security scanning | nox -s security_scan |
Clean |
| Coverage | nox -s coverage_report |
≥ 97% — blocks merge |
Coverage below 97% blocks merge. This is a hard project requirement.
Peer Review Requirements
- Minimum 1 approving review required (project-specific rule; C.O.C. baseline is 2)
- Self-approval is permitted, including for automated bot PRs
- Approval can be a formal "APPROVED" review or a comment with explicit approval (e.g. LGTM, ✅)
- No open "Request Changes" or "Rejected" reviews at merge time — all must be resolved or dismissed
- The project owner may override and merge in exceptional circumstances (documented)
What Reviewers Evaluate
- Correctness — satisfies the acceptance criteria of all linked issues
- Readability — clear names, easy to follow logic
- Performance — no unnecessary inefficiencies introduced
- Security — no vulnerabilities or unsafe patterns
- Style — follows project coding standards
- Test coverage — adequate tests, including edge cases and failure modes
PR Dependency Direction (Critical)
PR → blocks → Issue
Issue → depends on → PR
To configure in Forgejo: open the PR, then add the linked issue under "blocks".
NEVER set it the other way around. If the issue blocks the PR, neither can be closed without the other — an unresolvable deadlock.
After Submission
- Move linked issue(s) to State/In review
- Watch CI — fix any failures immediately; do not leave a broken PR waiting
- Address all review comments, then re-request review from each reviewer
- After merge: move linked issue(s) to State/Completed
Merge Requirements Summary
- PR description is detailed and includes
Closes #N/Fixes #Nkeywords - Dependency direction is correct: PR blocks issue (not the reverse)
- All CI checks pass
- Coverage ≥ 97%
- At least 1 approval; no open "Request Changes" or "Rejected" reviews
- All commits follow Conventional Changelog format
- Every commit references the associated issue (
ISSUES CLOSED: #N) - Changelog updated
- CONTRIBUTORS.md updated (if first contribution)
- Version number updated (if applicable)
- Correct milestone assigned
- Exactly one
Type/label applied - Linked issues are in State/In review or State/Completed
Versioning (Clever Semantic Versioning)
| Change Type | Version Bump |
|---|---|
| Incompatible API changes (breaking changes) | MAJOR |
| Backwards-compatible new functionality | MINOR |
| Backwards-compatible bug fixes | PATCH |
| Refactoring, documentation, tests, unreleased changes | none |
Breaking changes must also be marked in the commit message with ! after the type/scope (e.g. feat!:) or a BREAKING CHANGE: footer.