End performs the final architecture-aware review of a project. It maps how the code is organized and how data moves before judging it, then produces a health diagnosis and an ordered refactoring plan grounded in the repository’s real constraints.
The audit is broad, but execution remains controlled. Analysis is read-only, and implementation starts only after an explicit authorization.
What it reviews
End traces entry points, layer ownership, state and data flow, build and release configuration, public interfaces, error boundaries, and the conventions already carrying the project. It looks for confirmed bugs, architectural debt, maintenance risks, security problems, performance costs, duplication, and opportunities to simplify.
The workflow supports JavaScript and TypeScript projects, major web and mobile stacks, VS Code extensions, libraries and CLIs, as well as Rust, Go, Python, C#, and Flutter repositories. Stack support informs the review; it never replaces direct evidence from the code.
A useful health diagnosis
The report separates three kinds of information:
- Confirmed bugs that have evidence and a clear impact.
- Technical debt, structural friction, and risks that make future work harder or less safe.
- Optional suggestions whose value depends on product direction or maintainer preference.
It also makes one explicit architecture decision: the current structure is ready, needs small adjustments, or would benefit from restructuring. The accompanying score summarizes the repository’s condition without pretending that a number can replace the findings behind it.
From report to implementation
Recommended work is split into ordered phases with scope, intent, affected areas, and a verification strategy. A plain go approves one phase only. An explicit request to run every phase enables continuous execution, with a result reported after each boundary.
This keeps a large refactor observable. It also gives the maintainer a safe opportunity to stop if new evidence changes the plan.
Safety boundaries
End checks the worktree before editing and preserves changes that were already present. It uses the existing package manager and project checks, does not introduce dependencies without permission, never creates a new test structure when none exists, and avoids changing public behavior except when correcting a justified defect.
For repositories with more than 50 source files, the audit may sample around architectural boundaries. The report names areas it did not read instead of claiming complete coverage. Plans remain in the conversation unless the user explicitly asks to save them to disk.
