# Index — `EditModalSaveContextHolder` Missing DI Registration (BlazorBlocks / AuthBlocks)

**Status:** ✅ RESOLVED — shipped in `Cerebellum.BlazorBlocks.Web` 10.3.33 + `Cerebellum.AuthBlocks.Web` 10.3.36 (2026-06-20). ~~scoped, not yet started. Confirmed against `Cerebellum.BlazorBlocks.Web` 10.3.32 / `Cerebellum.AuthBlocks.Web` 10.3.33. Author: product-designer. Date: 2026-06-19.~~

> **Resolution (2026-06-20):** `AddBlazorBlocksWeb()` landed in `Cerebellum.BlazorBlocks.Web` 10.3.33 and `ConfigureAuthServices` calls it in `Cerebellum.AuthBlocks.Web` 10.3.36; DeepDrftManager picked up 10.3.36 and removed its local `EditModalSaveContextHolder` stopgap.
> This brief is retained as historical record — no further action required.

## The defect

BlazorBlocks' `ModelView` / `EditModelModal` components have a `required [Inject]` dependency on
`Web.Maintenance.Entities.EditModalSaveContextHolder` (a per-circuit save bridge), but the BlazorBlocks
`Web` package ships no registration extension for it and AuthBlocks' `ConfigureAuthServices` never registers
it either. Any consumer of a `ModelView`-based page (e.g. AuthBlocks' `Users.razor` /
`Registrations.razor`) crashes the Blazor circuit on navigation with an unregistered-service
`InvalidOperationException`. Two independent downstream products have each hand-registered the internal
service as a stopgap — the tell that this is a leaked library registration.

## The two-team layered fix (ordered — do not reorder)

1. **BlazorBlocks ships first.** Add a Web-side `AddBlazorBlocksWeb()` extension that registers the holder
   via `TryAddScoped` (scoped is required). Bump `Cerebellum.BlazorBlocks.Web` from 10.3.32; report the new
   version.
2. **AuthBlocks ships second.** Bump its `Cerebellum.BlazorBlocks.Web` reference to that new version, call
   `AddBlazorBlocksWeb()` from `ConfigureAuthServices`, bump `Cerebellum.AuthBlocks.Web` from 10.3.33.

AuthBlocks is blocked until BlazorBlocks' new version is published. Registration lives with its owner
(BlazorBlocks); AuthBlocks stays self-contained by composing it. MudBlazor (`AddMudServices`) stays a
caller-owned prerequisite throughout.

## The detail lives in the two team briefs

Each is fully self-contained for an orchestrator working in only that one repo:

- **BlazorBlocks team** → [`team-brief-blazorblocks-modelview-di.md`](./team-brief-blazorblocks-modelview-di.md)
  (root cause, `[Inject]` audit, lifetime rationale, the new extension, version bump, acceptance criteria).
- **AuthBlocks team** → [`team-brief-authblocks-modelview-di.md`](./team-brief-authblocks-modelview-di.md)
  (the blocking BlazorBlocks prerequisite, the `ConfigureAuthServices` call, version bump, acceptance
  criteria).