Use this when introducing a new pluginConfig or dashboard setting field.
Add a field without breaking defaults, migration behavior, settings persistence, or documentation parity.
lib/config.ts— runtime config resolution/defaultslib/schemas.ts— env/config schema validation and typed field contractslib/dashboard-settings.tsorlib/unified-settings.ts— persisted settings shapelib/codex-manager/settings-hub.tsand extracted settings helpers — interactive editing if user-facingdocs/configuration.md— user-facing config docsdocs/reference/settings.md— settings referencedocs/development/CONFIG_FIELDS.md— full field inventorytest/config.test.ts,test/dashboard-settings.test.ts,test/unified-settings.test.ts— behavior coveragetest/documentation.test.ts— docs parity
- Define the default in the owning config/settings module first.
- Thread it through persistence and loading paths before exposing UI controls.
- If user-facing, add the smallest possible settings UI path after the storage/config part is correct.
- Document the field in both user docs and maintainer inventory.
- Add tests for defaulting, persistence, and docs parity.
- New fields must have deterministic defaults.
- Do not change existing default values in the same PR unless that is the actual feature.
- Keep docs and code aligned in the same change.
- Recheck the Windows persistence notes when the field is written to disk;
EBUSYandEPERMretry behavior must stay documented and covered.
npm run typechecknpm run lint -- lib/config.ts lib/dashboard-settings.ts lib/unified-settings.ts test/config.test.ts test/dashboard-settings.test.ts test/unified-settings.test.ts test/documentation.test.ts- Run the targeted test files that cover the field
- If the field is user-visible, exercise the real settings path manually