PRD: Establish team-wide documentation and issue tracking workflow

[khahani]

Problem Statement

The EasyEyes team has no shared, explicit system for how work moves from idea to implementation. Work is tracked in two parallel, disconnected systems (Trello and GitHub Issues), PRs have no standard structure, and there is no convention for coordinating features that span the four active repos (threshold-scientist, remote-calibrator, website, Easyeyes-Analyzer). As a result, the chain of intent from a domain idea to a merged PR is only in people's heads — traceable by asking, not by looking.

Solution

Establish a lightweight, two-layer documentation and tracking system built on existing tools the team already uses. Trello remains the owner's surface for assigning high-level domain intent. GitHub Issues in threshold-scientist becomes the single engineering source of truth: PRD-level issues live here, cross-repo implementation issues link back to them, and a minimal PR template in every repo ensures every PR is traceable to a Trello card and a GitHub issue.

User Stories

1. As the EasyEyes owner, I want to assign a Trello card to a developer and find a link to the corresponding GitHub PRD issue in the card's comments, so that I can follow engineering progress without opening GitHub.
2. As the EasyEyes owner, I want every PR to include a Trello card link, so that I can trace any shipped change back to the original intent without asking the developer.
3. As a developer, I want a clear entry point for translating a Trello card into an engineering plan, so that I know where to write the PRD and how to structure it.
4. As a developer, I want the PRD issue to link back to the originating Trello card, so that I can refer to the owner's original intent throughout implementation.
5. As a developer, I want a parent PRD issue in threshold-scientist to list all cross-repo sub-issues as a task checklist, so that I can see overall feature progress without navigating to each repo individually.
6. As a developer working in remote-calibrator, I want implementation issues to live in remote-calibrator's own issue tracker (not threshold-scientist), so that my PR can auto-close its issue with closes #N.
7. As a developer, I want a consistent PR template in every repo, so that I never forget to link the Trello card, the closing issue, or relevant reviewer notes.
8. As a developer, I want to open a PR in any of the four repos and immediately know the standard format expected, so that code review is faster and traceability is automatic.
9. As a team member, I want to open threshold-scientist issues and find the PRD for any in-progress feature, so that I can understand the full scope of work without asking the developer who started it.
10. As a team member, I want sub-issues in each repo to reference their parent PRD issue in threshold-scientist, so that the chain of intent is navigable from any direction.
11. As a developer, I want a PRD issue to clearly state which repos are affected by the feature, so that I can anticipate cross-repo coordination before starting implementation.
12. As a new team member, I want to understand how work flows from Trello to merged PR by reading the threshold-scientist README, so that I can contribute without a lengthy onboarding call.

Implementation Decisions

• Two-layer tracking: Trello handles domain-level assignment by the owner (unchanged). GitHub Issues in threshold-scientist handles all engineering documentation — PRDs and cross-repo coordination.
• threshold-scientist as the coordination hub: All PRD-level (feature-level) issues are created in threshold-scientist, regardless of which repos the feature touches.
• Cross-repo issue structure (Option B): For a feature affecting multiple repos, the PRD issue in threshold-scientist contains a task list checklist that links to implementation issues in each affected repo. Implementation issues live in their own repo so that PRs can auto-close them.
• Two-way Trello ↔ GitHub linking: The developer adds the Trello card URL to the PRD issue body. The developer (or owner) adds the PRD issue URL as a comment on the Trello card. This convention is manual but required.
• PR template: A minimal .github/PULL_REQUEST_TEMPLATE.md is added to all four repos with four sections: What (one sentence), Issue (closes #), Trello (card URL), Notes (reviewer context).
• Google Docs unchanged: The Threshold Manual and Parameter Glossary remain in Google Docs. Links to these documents are added to the relevant repo READMEs.
• Slack integration unchanged: Only the website repo triggers Slack notifications. No expansion to other repos.
• README improvements: Out of scope for this PRD but flagged as a follow-up task.

Testing Decisions

This PRD is about process and configuration, not application logic. There is no automated testing applicable. Verification is manual:

• Confirm .github/PULL_REQUEST_TEMPLATE.md appears when opening a new PR in each of the four repos.
• Confirm a test PRD issue in threshold-scientist correctly links to a test sub-issue in remote-calibrator via task checklist, and that checking the task checklist item reflects the linked issue's state.

Out of Scope

• README improvements across the four repos (follow-up task).
• Slack integration expansion beyond the website repo.

Further Notes

• The PR template should be kept minimal. Adding more fields risks the template being ignored. The four sections (What, Issue, Trello, Notes) are the ceiling, not the floor.