2026-03-24 09:50:06 +01:00
|
|
|
# <Project> Findings
|
|
|
|
|
|
|
|
|
|
Date: YYYY-MM-DD
|
|
|
|
|
Path inspected: `<path>`
|
|
|
|
|
|
|
|
|
|
## Summary
|
|
|
|
|
|
|
|
|
|
`<path>` is a <one-line description>.
|
|
|
|
|
|
|
|
|
|
The repo is trying to prove or build <main idea>.
|
|
|
|
|
|
|
|
|
|
Verdict in one sentence: <works as X, does not yet read as Y>.
|
|
|
|
|
|
|
|
|
|
## What It Contains
|
|
|
|
|
|
|
|
|
|
- `<path/to/file-or-dir>` - <why it matters>
|
|
|
|
|
- `<path/to/file-or-dir>` - <why it matters>
|
|
|
|
|
- `<path/to/file-or-dir>` - <why it matters>
|
|
|
|
|
- `<path/to/file-or-dir>` - <why it matters>
|
|
|
|
|
|
|
|
|
|
## Review
|
|
|
|
|
|
|
|
|
|
State the main architectural idea plainly.
|
|
|
|
|
|
|
|
|
|
Say what the repo gets right.
|
|
|
|
|
|
|
|
|
|
Say what still looks early, brittle, overcomplicated, missing, or high-risk.
|
|
|
|
|
|
|
|
|
|
Call out the main constraint directly: <build glue / unstable deps / missing tests / wrapper burden / runtime complexity / unclear ownership / etc.>
|
|
|
|
|
|
2026-03-24 14:24:30 +01:00
|
|
|
Keep this section short. Write like a reviewer, not a tour guide.
|
2026-03-24 09:50:06 +01:00
|
|
|
|
|
|
|
|
## Pros
|
|
|
|
|
|
|
|
|
|
- <clear strength>
|
|
|
|
|
- <clear strength>
|
|
|
|
|
- <clear strength>
|
|
|
|
|
- <clear strength>
|
|
|
|
|
|
|
|
|
|
## Cons
|
|
|
|
|
|
|
|
|
|
- <clear weakness>
|
|
|
|
|
- <clear weakness>
|
|
|
|
|
- <clear weakness>
|
|
|
|
|
- <clear weakness>
|
|
|
|
|
|
|
|
|
|
## Status
|
|
|
|
|
|
|
|
|
|
Current status: <working prototype / partial implementation / mature subsystem / etc.>
|
|
|
|
|
|
|
|
|
|
State what is already proven.
|
|
|
|
|
|
|
|
|
|
State what would still need work before repeated reuse or production use.
|
|
|
|
|
|
|
|
|
|
End with a short reviewer verdict: <promising experiment / solid foundation / not ready to trust / etc.>
|
|
|
|
|
|
|
|
|
|
## Optional Sections
|
|
|
|
|
|
|
|
|
|
Add only if they help:
|
|
|
|
|
|
|
|
|
|
- `## Ecosystem Maturity`
|
|
|
|
|
- `## Calling Direction`
|
|
|
|
|
- `## Toolchain Recommendation`
|
|
|
|
|
- `## Practical Read On <Project>`
|
|
|
|
|
- `## Risks`
|
|
|
|
|
- `## Next Problems`
|
|
|
|
|
|
|
|
|
|
## Writing Rules
|
|
|
|
|
|
|
|
|
|
- Use Title Case for headings.
|
|
|
|
|
- Keep the tone direct and critical.
|
|
|
|
|
- Prefer short paragraphs over long walkthroughs.
|
|
|
|
|
- Do not write like an assistant explaining itself.
|
|
|
|
|
- Avoid filler such as "it appears" unless the point is genuinely uncertain.
|
|
|
|
|
- Prefer verdicts over summaries when the evidence is already clear.
|
|
|
|
|
- If something is fragile, say it is fragile.
|
|
|
|
|
- If something is promising but early, say that plainly.
|
2026-03-24 14:24:30 +01:00
|
|
|
- Do not use poetic wording.
|
|
|
|
|
- Avoid colorful adjectives and adverbs.
|
|
|
|
|
- Prefer factual wording over rhetorical wording.
|
