mirror of
https://github.com/tinyhumansai/openhuman.git
synced 2026-07-28 13:32:23 +00:00
Steven EnamakelandGitHub
6aeea8ba49
* chore: uppercase PR template (summary, problem, solution) Made-with: Cursor * chore: uppercase PR template (testing, impact) Made-with: Cursor * chore: uppercase PR template (breaking changes, related) Made-with: Cursor * chore: intermediate rename for pull request template path Made-with: Cursor * chore: use uppercase PULL_REQUEST_TEMPLATE.md Made-with: Cursor * docs: point agent docs at PULL_REQUEST_TEMPLATE.md Made-with: Cursor * chore: update pull request and feature issue templates for clarity and consistency - Standardized section headings to title case for uniformity. - Enhanced descriptions for each section to improve guidance for contributors. - Introduced a new feature issue template to streamline feature proposals and documentation requirements. * docs: enhance issue and pull request templates for better guidance - Added a new bug issue template to standardize bug reporting. - Updated the feature issue template to clarify the problem and solution sections. - Revised the pull request template to include a submission checklist for testing and documentation requirements. * chore: comment out E2E macOS workflow steps in test.yml - Temporarily disabled the E2E (macOS / Appium) job in the GitHub Actions workflow by commenting out all related steps for future reference.
1.3 KiB
1.3 KiB
Summary
- What changed and why.
- Keep this to 3-6 bullets focused on user-visible or architecture-impacting changes.
Problem
- What issue or risk this PR addresses.
- Include context needed for reviewers to evaluate correctness quickly.
Solution
- How the implementation solves the problem.
- Note important design decisions and tradeoffs.
Submission Checklist
- Unit tests — Vitest (
app/) and/orcargo test(core) for logic you add or change - E2E / integration — Where behavior is user-visible or crosses UI → Tauri → sidecar → JSON-RPC; use existing harnesses (
app/test/e2e, mock backend,tests/json_rpc_e2e.rsas appropriate) - N/A — If truly not applicable, say why (e.g. change is documentation-only)
- Doc comments —
//////!(Rust), JSDoc or brief file/module headers (TS) on public APIs and non-obvious modules - Inline comments — Where logic, invariants, or edge cases aren’t clear from names alone (keep them grep-friendly; avoid restating the code)
(Any feature related checklist can go in here)
Impact
- Runtime/platform impact (desktop/mobile/web/CLI), if any.
- Performance, security, migration, or compatibility implications.
Related
- Issue(s):
- Follow-up PR(s)/TODOs: