An Issue Intake Note separates signal from evidence
The intake note preserves the original request while making uncertainty visible. It should be short enough to review before discovery and specific enough to guide the first check.
Do not turn an issue description into a claim that a bug, file, or root cause has already been confirmed.
| Field | Purpose |
|---|---|
| Signal | What was reported |
| Observed | What was reproduced or read |
| Unknown | What remains open |
| Impact | Why the issue matters |
| Next check | Smallest useful investigation |
Intake checklist
- Copy the request without adding assumptions.
- State current and desired behavior separately.
- List missing reproduction details.
- Identify risk and affected users or flows.
- Choose one read-only next check.
- Stop before proposing a broad fix.
Boundary example
Reported: <user-facing symptom>
Confirmed: <observable fact>
Hypothesis: <possible cause>
Not checked: <list>
Next: inspect <path> and run <focused check>Canonical lesson source · JavaRush
Open JavaRush material