C4: consolidate DI composition - single provider-factory owner, single observation-core owner

[IanFrelinger]

C4 — DI composition cleanup

Consolidation item C4. The riskiest of the set: registration order in NexoKernelRegistrar is load-bearing, so the hard constraint was do not change observable DI resolution. Every service must still resolve to the same implementation, and registration-order semantics must be preserved.

The 20-phase model is kept as-is. Duplicates were consolidated inside it; the phase composition is not restructured.

What was consolidated

1. The provider-factory chain now has a single owner (Phase 15).

The chain was assembled in two assemblies at once. Paths A and C were built in NexoKernelRegistrar.Phases.cs; Path B was built inside Nexo.BackgroundAgents.AddTrustServices. Nothing enforced that exactly one fired — correctness rested on three booleans (useSanitizingProviderFactory, skipProviderRegistration, useAdaptive) crossing the assembly boundary in a combination that happened to be mutually exclusive. Flip one and you get either two IProviderFactory registrations racing on last-wins, or none.

The kernel now always calls AddTrustServices with skipProviderRegistration: true, so trust contributes taxonomy, sanitization proxy and audit log and nothing else. The chain is composed bottom-up from two independent switches instead of three hand-maintained branches:

ProviderFactory -> [SanitizingProviderFactory] -> [AdaptiveProviderFactory]

producing the same four shipped combinations by construction rather than by three branches agreeing with each other.

2. Observation core has a single owner per configuration.

IPatternStore, IPatternProcessedStore and IContextAssembler were registered by both Phase 07 (adaptation) and Phase 12 (observation pipeline), both with AddSingleton, with Phase 12 silently winning on last-wins. The two are not equivalent — they disagree about where the store lives:

	path
Phase 07	new LiteDbPatternStore(patternStorePath) — verbatim
Phase 12	new LiteDbPatternStore(Combine(repoRoot, storePath)) — repo-rooted

Ownership is now explicit: the pipeline owns observation core when active, adaptation owns it otherwise.

3. Deleted the orphan AddNexoAgents.

Analysis correction — Phase 07 is not a dead orphan

The premise going in was that the Phase 07 observation closure is dead. That is only half true, and the half that is not matters:

configuration	outcome
Full / Server (pipeline on)	Phase 12 wins, Phase 07 dead
AirGapped (pipeline off)	Phase 07 is the ONLY registration — load-bearing
any profile + DisableObservationPipeline	same, load-bearing

AirGapped ships IncludeAdaptation: true with IncludeObservationPipeline: false. Deleting Phase 07's registration outright — the obvious reading of "remove the dead duplicate" — would have left adaptation resolving a missing IContextAssembler there. Ownership was therefore made conditional rather than removed.

Two further corrections from the same investigation:

• With an absolute PatternStorePath the two registrations produce byte-identical strings, because Path.Combine discards the root when the second argument is absolute. The duplicate is only observable with a relative path. That is why it went unnoticed, and why the pinning tests use a relative path deliberately.
• IAgentFactory resolves to <null> in all 14 configurations. AddNexoAgents was not an unused service — it was a registration helper never wired into composition at all.

Behaviour-preservation proof

A probe builds the real container from AddNexo under 14 flag configurations (Full / Server / Edge / AirGapped / System × trust × adaptive × ephemeral × pattern-store variants) and records both the full ServiceDescriptor list in registration order and the concrete type each of 21 key services resolves to. Baseline captured on master before any edit, then diffed.

	result
Resolved types, 21 services × 14 configs	identical to master
Provider decorator chains (reflectively unwrapped)	identical
Store paths (relative-path discriminated)	identical
ServiceDescriptor list	0 additions, 0 moves, 6 removals

The 6 removals are exactly the three observation-core descriptors in the two configurations where both phases ran. Every configuration where Phase 07 is load-bearing is untouched, and in the relative-path case the surviving path is still the repo-rooted one — the registration that was already winning is the one that remains.

Chains are compared unwrapped, not by resolved type. Adaptive -> Sanitizing -> Provider and Adaptive -> Provider both surface as AdaptiveProviderFactory; a chain that lost its sanitizing layer still resolves, still reports the same type, and would have passed every pre-existing test while sending unscrubbed prompts past the trust boundary.

Judgment calls, flagged

1. TryAdd was deliberately NOT applied to AddObservationCore / AddObservationPipeline. Both are public API on packed assemblies, and Add to TryAdd inverts precedence for any host that pre-registers its own store: today the kernel overrides them, with TryAdd they would win. That is an observable resolution change that cannot be proven safe, and it conflicts with the hard constraint. The last-wins accident is gone regardless — removed structurally by single ownership rather than by the mechanism.
2. AddTrustServices keeps its provider branch. Nexo.BackgroundAgents is packed (scripts/pack-nexo-hosting-graph.sh), so deleting it would be a behaviour break for SDK consumers who call it directly, not a kernel change. The kernel simply never takes it now; it is commented as such.
3. IAgentFactory / AgentFactory types remain. Public Core.Application surface, still hand-registerable. Only the unused helper was deleted. No PublicAPI.Shipped.txt or approved snapshot references it, so nothing needs blessing.
4. GenerativeArtifactBrick is genuinely two objects, not two registrations of one: TryAddSingleton creates the DI singleton while AddNexoBrick routes the type through AdaptationBrickOptions to ActivatorUtilities.CreateInstance, which constructs a fresh instance. Left alone — the brick is stateless, and making the registry resolve from the container would change instance identity for every additional brick type.
5. Two asymmetries preserved rather than tidied, both documented in code: the plain path still does not register the concrete ProviderFactory (only the interface), and the IEphemeralModelLifecycle probe is still non-uniform across paths — equivalent as the kernel ships, divergent only if a host pre-registers its own lifecycle.

AddAdaptationInfrastructure gains an overload rather than an optional parameter, so the change is additive for the packed Nexo.Infrastructure surface instead of binary-breaking.

Tests

KernelDiCompositionProdStyleTests (10 tests) pins what a presence check cannot see: the ordered provider chain for all four flag combinations, that wrapper and wrapped are the same instance, the deliberate concrete-ProviderFactory asymmetry, that observation core has exactly one registration (asserted on the descriptor list — resolution only ever shows the winner), and which owner wins in each direction.

suite	result
Nexo.sln build	0 errors, 0 warnings
Hosting / strict-mode E2E	56/56
DI pinning (new)	10/10
Nexo.Tests.Application	244/244
Nexo.Tests.Domain	73/73
kernel-coverage floor	68.31% vs 67% floor, exit 0

Application coverage moves 68.35% to 68.31%, a 0.04pp drop purely from deleting the covered orphan.

Pre-existing failure, not from this change

Three RuntimeStudioBlackBoxSmokeTests daemon tests time out locally. Verified by checking out master, rebuilding and rerunning: identical 3 failures on master. They spawn the real CLI daemon; one of the three does not involve the observation pipeline at all.

🤖 Generated with Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.