Context
Surfaced in @neo-fable's review of PR #12885 (operator-flagged: "setting DATA on a state provider… ouch"). Several lifecycle/maintenance scripts activate debug logging by mutating the shared AiConfig reactive Provider SSOT at runtime — <Config>.data.debug = true — which is the ADR 0019 B4 write-class (consumers must read resolved leaves, never mutate the Provider). PR #12885 removed this from the two summary/backfill children (routing progress to stderr directly instead); the other call-sites remain.
The Problem
Consumer-side mutation of the reactive Provider singleton is the #12335 / #12435 hazard class (shared-instance bleed), and in the cloud deployment it hard-codes child verbosity non-operator-controllably for production-resident children.
Affected sites (V-B-A'd against dev)
ai/scripts/runners/runSandman.mjs:94 — Memory_Config.data.debug = trueai/scripts/maintenance/syncKnowledgeBase.mjs:19 — KB_Config.data.debug = trueai/scripts/migrations/migrateMemoryCore.mjs:63 — MC_Config.data.debug = trueai/scripts/maintenance/ingestTenant.mjs:185 — KB_Config.data.debug = true
The Fix
Replace each config.data.debug = true mutation with a B4-safe activation — e.g. emit the intended operator-visible output directly to stderr (the captured channel; the pattern PR #12885 adopted via console.error('[INFO] …')), OR a non-Provider logger-sink / config-materialization path. Constraint: the Provider is read-only for consumers.
Decision Record impact
aligned-with ADR 0019 (reactive Provider SSOT — read resolved leaves, never mutate).
Out of Scope
- The PR #12885 summary/backfill children (already fixed there).
Related
- PR #12885 (#12812) — where this was surfaced + fixed for two of the sites.
- #12456 — Eliminate ai/ AiConfig-SSOT antipatterns (epic; this is the write-side sibling of its read-side scope).
- #12335 / #12435 — the B4 singleton-mutation hazard family.
Release classification: post-v13 (B4-safety cleanup; non-blocking — a known runtime-mutation hazard, not a v13 ship-blocker).
Origin Session ID: b159aa60-24b1-4abd-864b-100573458d38.
Authored by Claude Opus 4.8 (@neo-opus-vega).
Context
Surfaced in @neo-fable's review of PR #12885 (operator-flagged: "setting DATA on a state provider… ouch"). Several lifecycle/maintenance scripts activate debug logging by mutating the shared AiConfig reactive Provider SSOT at runtime —
<Config>.data.debug = true— which is the ADR 0019 B4 write-class (consumers must read resolved leaves, never mutate the Provider). PR #12885 removed this from the two summary/backfill children (routing progress to stderr directly instead); the other call-sites remain.The Problem
Consumer-side mutation of the reactive Provider singleton is the #12335 / #12435 hazard class (shared-instance bleed), and in the cloud deployment it hard-codes child verbosity non-operator-controllably for production-resident children.
Affected sites (V-B-A'd against
dev)ai/scripts/runners/runSandman.mjs:94—Memory_Config.data.debug = trueai/scripts/maintenance/syncKnowledgeBase.mjs:19—KB_Config.data.debug = trueai/scripts/migrations/migrateMemoryCore.mjs:63—MC_Config.data.debug = trueai/scripts/maintenance/ingestTenant.mjs:185—KB_Config.data.debug = trueThe Fix
Replace each
config.data.debug = truemutation with a B4-safe activation — e.g. emit the intended operator-visible output directly to stderr (the captured channel; the pattern PR #12885 adopted viaconsole.error('[INFO] …')), OR a non-Provider logger-sink / config-materialization path. Constraint: the Provider is read-only for consumers.Decision Record impact
aligned-withADR 0019 (reactive Provider SSOT — read resolved leaves, never mutate).Out of Scope
Related
Release classification:post-v13 (B4-safety cleanup; non-blocking — a known runtime-mutation hazard, not a v13 ship-blocker).Origin Session ID: b159aa60-24b1-4abd-864b-100573458d38. Authored by Claude Opus 4.8 (@neo-opus-vega).