Context
Sub-leaf of #12461 (B3 defensive reads of the AiConfig SSOT). The broad parent identifies scripts/maintenance as one cleanup cluster, but the current open B3 PRs cover GitLab (#12528) and ConceptDiscoveryService (#12539), not this two-file maintenance-script surface.
Duplicate / collision sweep performed 2026-06-04:
- GitHub issue searches for
maintenance B3 AiConfig backup defrag and backup.mjs defragChromaDB AiConfig returned no equivalent open child ticket.
- Open PR search for #12461 shows #12528 and #12539 only.
- Local
resources/content/{issues,discussions} sweep found historical maintenance-script context, but no active equivalent B3 cleanup ticket for this cluster.
origin/dev grep shows the relevant live B3 reads at ai/scripts/maintenance/backup.mjs:140 and ai/scripts/maintenance/defragChromaDB.mjs:152.
The Problem
ADR 0019 classifies defensive ?. reads on the AiConfig SSOT as B3: the config provider guarantees the resolved tree, so consumers should read resolved leaves at the use site and fail loud if the subtree is missing.
The maintenance scripts still defend these reads:
resolveBackupRetention() uses aiConfig.maintenance?.backup?.retention.
resolveDefragSnapshotRetention() uses aiConfig.maintenance?.defrag?.snapshotRetention.
Those functions are operator-facing maintenance-script helpers. Keeping B3 guards here weakens the fail-loud contract precisely on the scripts operators run for backup and Chroma defrag safety.
The Architectural Reality
These scripts are legitimate AI entrypoints that already import Tier-1 AiConfig from ai/config.mjs. Per ADR 0019 §5, entrypoints read the resolved leaves directly. No new config surface or fallback policy is needed; the leaf defaults live in the AiConfig provider.
This is a narrow read-site cleanup, not a retention-policy redesign. The existing fallback behavior inside the returned retention objects remains owned by the leaf defaults and function-local destructuring/default handling.
The Fix
Change only the maintenance B3 read sites:
ai/scripts/maintenance/backup.mjs: aiConfig.maintenance?.backup?.retention -> aiConfig.maintenance.backup.retention.
ai/scripts/maintenance/defragChromaDB.mjs: aiConfig.maintenance?.defrag?.snapshotRetention -> aiConfig.maintenance.defrag.snapshotRetention.
Run targeted verification for the affected scripts and the B3 grep for these files.
Contract Ledger
| Target Surface |
Source of Authority |
Proposed Behavior |
Fallback / Edge Case |
Docs |
Evidence |
resolveBackupRetention() AiConfig read |
ADR 0019 B3 + #12461 |
Read aiConfig.maintenance.backup.retention directly |
If the subtree is absent, fail loud; do not hide it with optional chaining |
Existing JSDoc remains accurate |
Focused grep shows no B3 read in backup.mjs; existing backup unit coverage green if present |
resolveDefragSnapshotRetention() AiConfig read |
ADR 0019 B3 + #12461 |
Read aiConfig.maintenance.defrag.snapshotRetention directly |
If the subtree is absent, fail loud; function-local defaults still govern missing retention fields inside a present object |
Existing JSDoc remains accurate |
Focused grep shows no B3 read in defragChromaDB.mjs; existing defrag unit coverage green if present |
Decision Record impact
aligned-with ADR 0019.
Acceptance Criteria
Out of Scope
- Changing backup or defrag retention semantics.
- Changing AiConfig leaf defaults.
- Cleaning other #12461 B3 clusters.
- B3/B4 test-spec cleanup, which remains coupled to #12435.
Related
Parent: #12461. Epic: #12456. Authority: ADR 0019.
Origin Session ID: dcdaac0b-9ae0-45b5-b4da-da39541af497
Retrieval Hint: maintenance B3 AiConfig backup defragChromaDB ADR 0019
Context
Sub-leaf of #12461 (B3 defensive reads of the AiConfig SSOT). The broad parent identifies
scripts/maintenanceas one cleanup cluster, but the current open B3 PRs cover GitLab (#12528) and ConceptDiscoveryService (#12539), not this two-file maintenance-script surface.Duplicate / collision sweep performed 2026-06-04:
maintenance B3 AiConfig backup defragandbackup.mjs defragChromaDB AiConfigreturned no equivalent open child ticket.resources/content/{issues,discussions}sweep found historical maintenance-script context, but no active equivalent B3 cleanup ticket for this cluster.origin/devgrep shows the relevant live B3 reads atai/scripts/maintenance/backup.mjs:140andai/scripts/maintenance/defragChromaDB.mjs:152.The Problem
ADR 0019 classifies defensive
?.reads on the AiConfig SSOT as B3: the config provider guarantees the resolved tree, so consumers should read resolved leaves at the use site and fail loud if the subtree is missing.The maintenance scripts still defend these reads:
resolveBackupRetention()usesaiConfig.maintenance?.backup?.retention.resolveDefragSnapshotRetention()usesaiConfig.maintenance?.defrag?.snapshotRetention.Those functions are operator-facing maintenance-script helpers. Keeping B3 guards here weakens the fail-loud contract precisely on the scripts operators run for backup and Chroma defrag safety.
The Architectural Reality
These scripts are legitimate AI entrypoints that already import Tier-1
AiConfigfromai/config.mjs. Per ADR 0019 §5, entrypoints read the resolved leaves directly. No new config surface or fallback policy is needed; the leaf defaults live in the AiConfig provider.This is a narrow read-site cleanup, not a retention-policy redesign. The existing fallback behavior inside the returned retention objects remains owned by the leaf defaults and function-local destructuring/default handling.
The Fix
Change only the maintenance B3 read sites:
ai/scripts/maintenance/backup.mjs:aiConfig.maintenance?.backup?.retention->aiConfig.maintenance.backup.retention.ai/scripts/maintenance/defragChromaDB.mjs:aiConfig.maintenance?.defrag?.snapshotRetention->aiConfig.maintenance.defrag.snapshotRetention.Run targeted verification for the affected scripts and the B3 grep for these files.
Contract Ledger
resolveBackupRetention()AiConfig readaiConfig.maintenance.backup.retentiondirectlybackup.mjs; existing backup unit coverage green if presentresolveDefragSnapshotRetention()AiConfig readaiConfig.maintenance.defrag.snapshotRetentiondirectlydefragChromaDB.mjs; existing defrag unit coverage green if presentDecision Record impact
aligned-with ADR 0019.
Acceptance Criteria
ai/scripts/maintenance/backup.mjshas no B3 optional chaining on the AiConfig maintenance subtree.ai/scripts/maintenance/defragChromaDB.mjshas no B3 optional chaining on the AiConfig maintenance subtree.Out of Scope
Related
Parent: #12461. Epic: #12456. Authority: ADR 0019.
Origin Session ID: dcdaac0b-9ae0-45b5-b4da-da39541af497
Retrieval Hint:
maintenance B3 AiConfig backup defragChromaDB ADR 0019