Stabilize the public runtime API surface and separate internal composition modules

[David-patrick-chuks]

Summary

Refine exports and module boundaries so contributor work does not accidentally leak unstable internals into the package API.

Context

As the project grows, maintainability will depend on a deliberate distinction between public extension points and internal wiring.

Scope

• Audit current exports.
• Separate public API modules from internal composition modules.
• Add documentation or comments marking unstable internals where needed.
• Preserve contributor-facing extension interfaces.

Acceptance Criteria

• Public exports are intentionally defined.
• Internal-only modules are no longer implicitly part of the package surface.
• README or contributor docs clarify supported extension points.
• Tests or type-level checks protect the public API shape where reasonable.

Out of Scope

• Large-scale architectural rewrite.
• Monorepo split.
• Semantic versioning automation.

Dependencies

• Introduce tool execution middleware for validation, policy, and instrumentation #2
• Build a runtime context factory with scoped state and immutable execution metadata #4
• Extend ModelProvider with capability metadata and invocation settings #7

Suggested Labels

architecture, public-api, maintenance