You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Task: expand context abstractions for scope and factory contracts #9
Expand ModularityKit.Context.Abstractions with the missing core contracts needed for a more complete and predictable context package.
Goal
Make the abstraction layer match the actual runtime capabilities of the library and provide stable contracts for context creation, scoping, and future integration points.
Problem
ModularityKit.Context.Abstractions is currently too small for a package that already supports ambient context access, scoped execution, read-only projection, and execution tracing.
The current abstractions cover the basics, but they do not yet give consumers a clean contract for:
manual scope control
centralized context creation
future diagnostic integration
explicit lifecycle modeling
That makes the package usable, but under-specified.
Scope
Add a first-class IContextScope<TContext> abstraction
Add a IContextFactory<TContext> abstraction for centralized context creation
Add lifecycle-oriented contracts only where they are useful in the core package
Keep the abstraction layer aligned with the current runtime and model layers
Avoid duplicating model types as interfaces when a record or enum is a better fit
Update public examples and docs so the new abstractions are discoverable
Design Expectations
Abstractions should describe stable concepts, not implementation details.
The surface should stay small enough to remain approachable.
New contracts should improve composition without forcing extra layers on simple users.
Models should remain models when they do not need interface-based polymorphism.
Acceptance Criteria
The abstraction layer includes a clear scope contract.
The abstraction layer includes a factory contract for context creation.
The new abstractions map cleanly to the existing runtime APIs.
The package remains small and predictable instead of becoming over-abstracted.
Non-Goals
No governance layer.
No policy engine.
No event bus.
No persistence backend.
No ASP.NET-specific integration.
Notes
This issue is about making the abstraction layer match the library’s actual shape, not about turning the package into a large framework.
Activity