project trained
The learned layer of the project guru: one state owner and one code/document owner per outcome, with evidence attached where the state updates.
mental model
An outcome has one state owner and one code/document owner. Issue state, source state, and runtime state are connected evidence, not substitutes.
examples
gh issue list --state open --limit 50gh project list --owner OWNER
Read before writing; include only an actual owner value when the repository establishes one.
best practices
- Extend existing labels, fields, paths, and documents minimally.
- Store acceptance evidence with the state update, including link and timestamp.
- Map consumers before relocating source or artifacts.
strengths
Explicit owners make handoffs and changes reviewable. GitHub Projects supports built-in and API/Actions automation (source).
weaknesses / pain points
Tracker state can lag source or production. Repository layouts often contain historical exceptions that must be read before standardizing.
gotchas
GitHub REST and GraphQL have independent limits; pace API automation using response headers (source).
known bugs
No version-specific defect is known here.
troubleshooting
| symptom | root cause | fix |
|---|---|---|
| board says done but checks fail | tracker was treated as runtime proof | attach fresh verification evidence |
| duplicated plans disagree | parallel state owners | choose and update the established owner |
| move breaks consumers | imports/config were not mapped | trace consumers before moving and scan old path afterward |