Anglefeint Architecture: Why the Four-Layer Composition Prioritizes Lightweight Runtime, Safer Upgrades, and Long-Term Reusability for Real Projects

In this theme, architecture was decided before visual polish. The reason is simple: when structure is unclear, every new feature becomes more expensive.

Anglefeint uses four layers:

• ThemeFrame: shared frame and global page shell
• Shell: route mood and atmosphere-specific wrappers
• Layout: page structure composition
• Page: content and route data only

This separation lets visual changes and content changes move independently. You can evolve style without rewriting content logic.

At repository level, core implementation is packaged in @anglefeint/astro-theme, while starter keeps content and configuration. This keeps the upgrade path focused on package updates instead of repeated manual copy operations.

The user-facing configuration entry is centered in site.config.ts. A single entry significantly lowers onboarding cost and keeps maintenance predictable.

The four-layer model is not only an aesthetic preference. It is a practical engineering tradeoff:

• Lightweight by default: route pages stay simple, with behavior attached only where needed.
• Upgrade-friendly: package logic and starter content are separated, so users can update with fewer merge conflicts.
• Low coupling: visual systems can evolve without rewriting routing, i18n, or content APIs.
• Reusable parts: shared frame and shell primitives can be reused when adding new routes or themes.

We also intentionally keep configuration centralized. Instead of forcing users to chase scattered files, we expose one main entry and let adapter files stay generated or synchronized. This reduces maintenance anxiety for people who just want to publish reliably.

In short, the architecture is designed for two goals at once:

• creative expression on the surface,
• operational stability underneath.

That balance is what makes a theme usable beyond a demo.