# <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.>

Keep this section short and judgmental in the useful sense. Write like a reviewer, not a tour guide.

## 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.