Separate built-in compiler features from executable addon extensions

[cssbruno]

Summary

The current gowdk.Addon abstraction serves two different purposes:

1. A marker that enables hard-coded compiler/generator behavior through Features().
2. An executable extension point for CSS processors, SEO providers, and targeted Go-block consumers.

Built-in capabilities such as SSR, actions, APIs, auth, contracts, realtime, and rate limiting are implemented inside GOWDK. Their addon values mostly select existing core logic rather than supplying that logic.

This makes the public model look more plugin-oriented than the architecture actually is and forces the config loader to resolve constructors and inspect interfaces even for ordinary built-in feature flags.

Why this matters

• Feature selection and third-party code execution have different trust, lifecycle, compatibility, and performance characteristics.
• Built-in constructors require AST-loader special cases and executable-bridge capability discovery.
• Config.HasFeature loses typed configuration and provenance by flattening capabilities into string-like feature IDs.
• External addons can advertise a built-in feature ID without actually implementing the compiler behavior associated with it.
• Documentation must repeatedly explain that an addon marker does not make the compiler call third-party runtime code.
• The executable extension protocol becomes harder to version because marker addons and behaviorful extensions share the same base abstraction.

Proposed direction

Represent built-in capabilities explicitly and reserve an extension abstraction for code that actually participates in compiler phases.

For example:

type Config struct {
    Features   FeatureConfig
    Extensions []Extension
}

or typed optional feature sections such as SSR, actions, contracts, and observability configuration.

Executable extensions should declare supported phases and protocol compatibility explicitly, such as:

• validation;
• target planning/lowering;
• generated files;
• CSS processing;
• build-time metadata providers.

Runtime services should remain app-owned lifecycle or registration hooks rather than implicit extension execution.

Compatibility approach

During 0.x, existing built-in addons/<name>.Addon() constructors can map to the new feature configuration with deprecation diagnostics or a compatibility adapter. External behaviorful addons can migrate to the explicit extension contract.

Acceptance criteria

• Built-in compiler capabilities no longer require opaque Addon instances solely to enable feature gates.
• Third-party executable extensions have a distinct, versioned contract and explicit phase/capability declaration.
• A third-party marker cannot claim a core feature ID and thereby imply that core behavior is safely configured.
• The config loader does not need constructor-specific semantic parsing for every built-in feature.
• Feature-specific options are typed and validated by the owning feature configuration.
• Runtime background services remain explicit through lifecycle/app wiring.
• Existing 0.x configs have a documented migration or compatibility path.
• Addon/extension documentation clearly distinguishes built-in feature selection, build-time extension execution, and runtime application hooks.