Description
Settings Management exposes supported platform preferences through a small, predictable CLI surface for operators who need repeatable configuration. dots settings get reads a setting and dots settings set validates and writes its value through the configured API boundary. Global context resolves the endpoint, credential, company selector, output format, and agent marker.
The workflow is designed for operators and coding agents. It uses the same authenticated, company-scoped service contracts as the rest of Dots, so terminal or protocol convenience never creates a second source of truth. Inputs are validated before or at the route boundary, and outputs preserve identifiers and structured details needed for a reliable next step.
Selling Points
- Makes configuration changes reproducible rather than dependent on remembered UI clicks.
- Allows deployment and onboarding scripts to establish supported defaults.
- Uses the same authenticated company selection as every other administrative command.
- Provides formatted read-back so changes can be verified immediately.
- Keeps the surface intentionally narrow, reducing ambiguous configuration behavior.
User Story
An administrator reads a company setting, records its current value, updates it as part of an onboarding script, and reads it back in JSON for verification. The change is scoped to the selected company and leaves a repeatable command trail. The result is a concrete, inspectable outcome that another person or automation can continue from without reconstructing hidden state.
Extension Surface
The feature is automatable: packages/cli/src/commands/settings.ts binds a fixed get/set route contract. Settings values may configure behavior, but no external code can add new CLI settings commands. The rating reflects the most-open supported seam that is true for this capability, not a transitive implementation detail. The cited path is the operational proof: consumers can use the documented seam, while unsupported changes still require a core release.
Capabilities & Limits
- Capability: Authenticated setting retrieval.
- Capability: Validated setting updates.
- Capability: Human-readable and machine-readable verification output.
- Limit: Only settings intentionally exposed by the platform contract are addressable; secret stores and unsupported internal configuration remain outside this surface.
The limit is intentional product truth rather than missing documentation. Calls also remain subject to authentication, tenant selection, schema validation, and the permissions enforced by the authoritative service.
Implementation Map
packages/cli/src/commands/settings.tspackages/cli/src/context.tsdocs/cli/settings-files-and-human-md-commands.md