docs(archreview): log SecuredWrites IBrowseService bUnit-harness failures against PLAN-07 (pre-existing, surfaced during PLAN-03 full-suite run)

2026-07-09 05:46:29 -04:00
parent c7a0c92244
commit 765ff131d8
2 changed files with 21 additions and 0 deletions
@@ -100,3 +100,7 @@ Consolidated in **PLAN-08 Task 11** → `docs/plans/2026-07-08-deferred-work-reg
 ### Plan deviations during Wave 1 PLAN-03 execution (2026-07-09)

 - **Task 15 (S6) — deploy-success reporting redesigned: readiness handshake, not swallow-only.** The plan's Task 15 relied on the `Terminated` signal beating the persistence result, so a stale persistence `Success` could simply be swallowed once the init-failure path had already replied `Failed`. **In practice the store commits FIRST** (the optimistic `StoreDeployedConfigAsync` completes before the child's async `PreStart` throws), so the swallow-only guard still reported `Success` for an actor that then died — the exact S6 bug. Fix as shipped makes the join deterministic: `InstanceActor.PreStart` now sends a new `InstanceActorInitialized` readiness message to the DeploymentManager as its final init step, and deployment `Success` requires **both** the persistence commit **and** that signal (`InFlightDeploy.Persisted && Initialized`); an actor that dies during init never signals readiness, so the `Terminated` fallback fails the deployment and rolls back the optimistic state. A second, related bug was fixed at the same time: the optimistic `Store…` and the rollback `Remove…` were independent `Task.Run`s with no ordering guarantee, so the persisted-row rollback is now **deferred until the store commits** (`_initFailedPendingRowRemoval`) and can never race ahead of it. New public surface: `Messages/InstanceActorInitialized.cs` (additive). **Follow-up owner: PLAN-03 Task 26** — the design-doc updates must describe the two-signal deploy-success join + the readiness message (alongside Task 4's already-flagged synchronous-compile-gate deviation). No further code work outstanding; this is a doc-capture follow-up.
+
+### Pre-existing failure discovered during Wave 1 PLAN-03 execution — owner PLAN-07 (2026-07-09)
+
+- **3 `CentralUI.Tests / SecuredWritesTests` render tests fail — `IBrowseService` not registered in the page's bUnit harness (PLAN-07 / Secured Writes, NOT PLAN-03).** PLAN-03's final full-solution `dotnet test` surfaced 3 failures in `SecuredWritesTests` (`Operator_SeesSubmitForm`, `Operator_Submit_CallsServiceWithEnteredValues`, `Verifier_OwnSubmission_HasApproveAndRejectDisabled`), all `InvalidOperationException: Cannot provide a value for property 'BrowseService' on type 'NodeBrowserDialog' — no registered service of type 'IBrowseService'`. Root cause: the Secured Writes page (`Components/Pages/Operations/SecuredWrites.razor`) renders `Components/Dialogs/NodeBrowserDialog.razor`, which `@inject`s `IBrowseService`; the test fixture (`SecuredWritesTests`) registers `_service`/`_siteRepo`/`_dialog`/auth but **not** a fake `IBrowseService`, so rendering the child dialog throws. **Confirmed pre-existing and out of PLAN-03 scope** — the failing files were last touched by commits outside the PLAN-03 session (`1a7e7351` page/test, `9cff87fe` dialog), and PLAN-03 never touches Secured Writes / CentralUI. Merged to `main` (`c7a0c922`) with this red present because it is not a regression from this branch. **Owner: PLAN-07** — register a stub `IBrowseService` in the `SecuredWritesTests` `Services` collection before `RenderPage()` (or in the shared bUnit fixture). See PLAN-07 "Post-plan known issues".