Skip to main content

ovecc architecture suggest

Recognizes which built-in template the indexed repository most resembles, and binds it to the repository's real root.

Usage: ovecc architecture suggest

For each template it detects the root (src/, apps/web/src/ in a monorepo, or the repository root), rebinds the template there, and scores the fit as coverage × conformance:

  • coverage — the share of the repository's source files a component claims,
  • conformance — the share of internal import edges the template allows.

Above a 50% threshold it reports the best match with the command that applies it.

Example​

$ ovecc architecture suggest
Best match: fsd (fit 1.00)
  root: src/
  coverage: 100% (64/64 source files, 3 components)
  conformance: 100% (0 divergent edge(s) of 143)
  apply: ovecc architecture init --template fsd

A repository that follows none of them is told so, rather than pushed a template it does not fit:

$ ovecc architecture suggest
No template fits above 50% — this repository does not clearly follow a built-in architecture.

That is the honest answer for most repositories that grew organically. Use architecture init instead: it drafts the contract from your actual graph rather than trying to force an archetype onto it.

What this is, and is not​

This is recognition against a curated basket of archetypes, not architecture recovery from scratch. Recovering an arbitrary architecture automatically is a hard, low-accuracy problem; classifying a repository against a handful of known targets is well-posed.

For the graph-derived view of your subsystems — no templates involved — see components.

Needs an index.

Options​

Only the global options.