Rebrand and Architectural Alignment

[mdwigley]

This request proposes a comprehensive rebrand and architectural alignment of the project, transitioning from PlugHub to NucleusAF (Nucleus Application Framework).

The existing implementation has always supported a modular and extensible architecture; however, the terminology and structure did not accurately reflect this design. In particular, the use of “plugin”-oriented naming introduced a misleading mental model, implying optional or peripheral extensions rather than core compositional units.

This change aligns the codebase with its intended architecture by:

• Renaming core concepts:

  • Plugin → Module
  • PlugHub → NucleusAF

• Reorganizing the solution into clearly defined layers:

  • Core (NucleusAF)
  • Modules (NucleusAF.Modules)
  • Surfaces/UI (NucleusAF.Surfaces)

• Introducing and formalizing extensibility patterns:

  • Provider-based architecture (IProvider*)
  • Capability system (ICapabilityService, handlers, accessors)
  • Composite registry system for structured composition

• Refactoring configuration into explicit abstractions:

  • Separation of accessors and handlers
  • Support for JSON, memory, and secure configuration sources

• Establishing modules as first-class units with dedicated build targets

• Updating all tests, documentation, and supporting infrastructure to reflect the new architecture

This is a large-scale change affecting the entire codebase; however, it is primarily a structural and semantic alignment rather than a shift in underlying intent.

Licensing Alignment

As part of this realignment, the project has transitioned from LGPL‑3.0 to MPL‑2.0. This provides a clearer, more permissive boundary for module authors while maintaining a predictable copyleft scope at the file level. The goal is to make it easier for third‑party modules to be developed, owned, and distributed without imposing broader licensing constraints on adopters.

Context

This work directly supports the Core Foundation and Stability Baseline milestone, which aims to establish a clear, predictable, and reliable foundation for future development.

While the system has always been modular in practice, the previous naming and abstractions created several issues:

• Conceptual ambiguity
  “Plugin” terminology implied optional extensions, while these components were in fact central to application composition.

• Inconsistent extension patterns
  Extensibility mechanisms existed but were not consistently formalized, leading to fragmentation in how features were integrated.

• Implicit patterns
  Existing design approaches (e.g., extensibility, configuration handling) were not clearly codified.

This provides a critical opportunity to correct architectural inconsistencies early and establish a stable, scalable foundation before broader usage.

The result is a system that is:

• Easier to understand and onboard into
• More consistent in its extension model
• Better structured for long-term growth and maintenance

Possible Implementation

The implementation is realized through a full codebase refactor, including:

• Systematic renaming of namespaces, types, and projects
• Replacement of plugin-oriented interfaces with module and provider abstractions
• Introduction of new core systems:
  • Capability services
  • Composite registries
  • Configuration accessors and handlers
• Migration of existing functionality into the new module structure
• Separation of UI concerns into dedicated surface layers (Avalonia)
• Addition of module-specific build and clean targets
• Full rewrite and alignment of unit tests with the new architecture