docs: arch-review remediation — component docs sweep, execution log, residuals register

Final consistency sweep per plan §6: verified component docs against shipped
WP1-WP3 + adversarial-review-fix state, corrected drift found in SiteRuntime
(recursion-exempt run cap, stale ScriptExecutionActor/AlarmExecutionActor
references), TemplateEngine (BundleImporter watermark path), DeploymentManager
(phase-2 PendingDeployment staging), CentralUI (shared KPI cache, dedup'd alarm
poll, render coalescing), StoreAndForward (rate-limited drop logging), and
ConfigurationDatabase (documented DbContext-pooling non-adoption). Updated the
docs/components/ developer-reference set (SiteRuntime, SiteEventLogging,
InboundAPI) to drop the deleted per-run actor classes. Amended one known-issue
for the superseding MaxBatchSize:64 read-page pin. Added CLAUDE.md bullets for
stream graceful-completion reconnect, the required site audit DB path, honest
CLI HTTP timeouts, bulk DeploySiteAsync, and LocalDb 0.2.1. New execution log
records the phase→commit map, gate results, adversarial-review tally, the
three test-flake root causes, and the nine-item residuals register.
This commit is contained in:
Joseph Doherty
2026-08-15 01:30:59 -04:00
parent a9ca51e008
commit 7804fe7958
12 changed files with 244 additions and 49 deletions
@@ -30,9 +30,20 @@ case). See the Phase 2 plan (D6) and `docs/plans/2026-07-19-localdb-phase2-live-
**Closed by LocalDb 0.2.0** (arch-review WP3.3): batching is now bounded by
`LocalDb:Replication:MaxBatchBytes` — summed serialized bytes, default **2 MB**, sized under the
4 MB limit — with the row count demoted to a secondary cap, and a single row above the budget sent
alone rather than stalling the stream. The rig's `MaxBatchSize = 16` pin is retired and both keys
are left at their defaults; a deployment replicating wide rows no longer has to size a row count
against its widest column by hand.
alone rather than stalling the stream. The rig's old `MaxBatchSize = 16` pin (sized against the
4 MB *wire* limit) is retired.
**Amended (2026-08-14) — `MaxBatchSize` is back, pinned to a different value for a different
reason.** `MaxBatchBytes` bounds the wire message, but it doesn't bound the DB **read page**:
`OplogStore.ReadBatchAboveAsync`/`SnapshotStreamer` materializes a whole `MaxBatchSize`-row page
into memory *before* the byte-budget split runs, so an unset (500-default) `MaxBatchSize` still
lets a reconnect drain transiently allocate ~35 MB per read even though every wire message stays
under `MaxBatchBytes` (arch-review adversarial finding F2). Both site-a nodes on `docker/` now pin
an explicit `"MaxBatchSize": 64` to bound that transient read-side allocation, while
`MaxBatchBytes` is left at its 2 MB default to bound the wire message; site-b/site-c stay
unreplicated so the key doesn't apply there. Not to be confused with LocalDb 0.2.1's unrelated
sync-inbox bound (also 64, but message count on the *receive* side, hardcoded in the library, not
a config key) — see CLAUDE.md's LocalDb bullet.
Note the failure mode differs from the one documented below: an oversized gRPC message is
**rejected**, not silently dropped.