Your codebase already has architecture rules. Archprint tries to catch them in the act.

What is it?

Archprint is a small TypeScript architecture-mining tool with an unusually sensible premise: instead of asking a team to write down every boundary it thinks the codebase follows, inspect the imports and find the boundaries the code actually follows. It builds an import graph, looks for statistically consistent relationships, and turns sufficiently strong patterns into rules that existing tools can enforce.

The project says it can emit rules for ESLint, dependency-cruiser and ts-arch. That matters because the output is not another architecture diagram destined to become archaeological evidence. The point is to convert an observed convention into something CI can reject when a later change breaks it.

Why did Radar notice it?

Architecture rules are often weakest at exactly the moment they matter most: when they exist as tribal knowledge. 'Services do not import UI', 'features only reach the database through this layer', or 'packages point inward, never sideways' can be obvious to the people who built a system and invisible to the next developer or coding agent.

Archprint flips that problem around. It treats the existing repository as evidence, and it attaches counts and confidence to an inferred rule rather than presenting a guess as doctrine. That is more interesting than another AI-written ARCHITECTURE.md because the inference is only useful if the code itself repeatedly supports it.

What's the catch?

Inference from the present can fossilise accidental structure. A repository may be consistently organised for historical reasons rather than good ones, and statistical confidence is not the same thing as architectural wisdom. The current scope is also deliberately narrow: TypeScript import relationships are much easier to mine than runtime coupling, data flow or architectural intent.

The repository is tiny by popularity standards, with only a handful of stars when Radar checked it, so there is little independent operational evidence yet. Treat the generated rules as proposals with receipts, not tablets from the mountain.

Who might want it?

TypeScript teams with an established codebase, especially ones introducing more automated coding, where preserving already-working boundaries is more valuable than asking an agent to invent a new architecture policy from scratch.