cgalo5758
6dbce6140f
Register bool and duration ConfigSpec keys from the Default's type, move fedwiki's four sync knobs and discourse's two into their integrations' ConfigSpecs, and replace core's read of fedwiki-custom-domain-target with a core domains-connect-target key resolved once and threaded through server and worker config. Generate init's optional-integration scaffold sections from each registered ConfigSpec instead of the hand-maintained list, and reword the Temporal boot warning generically. Archives the integration-config-parity change; status bookkeeping and the verify-skill doc follow with the test-stack commit.
48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
# console-init Specification
|
|
|
|
## Purpose
|
|
TBD - created by archiving change member-console-init-scaffold. Update Purpose after archive.
|
|
## Requirements
|
|
### Requirement: `init` scaffolds a usable starter config
|
|
|
|
`member-console init <path>` SHALL write a starter `mc-config.yaml` to the target
|
|
directory composed of the embedded core configuration template (`embeds.Config`)
|
|
plus one generated section per registered integration that declares configuration
|
|
(`config.ConfigProvider`), not a placeholder stub. The scaffolded file SHALL be
|
|
valid YAML containing every configuration key that `member-console start` requires,
|
|
with commented placeholder values the operator fills in. Each generated integration
|
|
section SHALL list that integration's `ConfigSpec` keys as commented lines carrying
|
|
the key's usage text, its default when one is declared, and a file-based
|
|
alternative note for secret keys. The embedded core template SHALL NOT hand-list
|
|
keys that an integration's `ConfigSpec` declares. The template's OIDC issuer
|
|
example SHALL reference a dedicated application realm placeholder, never an
|
|
administration realm such as Keycloak's `master`.
|
|
|
|
#### Scenario: init writes the embedded starter template
|
|
|
|
- **WHEN** an operator runs `member-console init ./my-instance`
|
|
- **THEN** `./my-instance/mc-config.yaml` SHALL be created from the embedded template
|
|
- **AND** it SHALL parse as YAML and contain the required keys (`base-url`, `db-dsn`,
|
|
`valkey-addr`, `oidc-idp-issuer-url`, `oidc-sp-client-id`, `csrf-secret`)
|
|
|
|
#### Scenario: Every declaring integration appears in the scaffold
|
|
|
|
- **WHEN** the scaffolded config is inspected
|
|
- **THEN** it SHALL contain one commented section per registered integration that
|
|
declares configuration, including every key from that integration's `ConfigSpec`
|
|
- **AND** no registered declaring integration SHALL be absent
|
|
|
|
#### Scenario: Integration sections are generated, not hand-maintained
|
|
|
|
- **WHEN** a new integration registering a `ConfigSpec` is added to the integration
|
|
registry
|
|
- **THEN** `init`'s scaffold SHALL include its section with no change to the
|
|
embedded template or `init` code
|
|
|
|
#### Scenario: scaffold does not model the admin-realm anti-pattern
|
|
|
|
- **WHEN** the scaffolded config's `oidc-idp-issuer-url` is inspected
|
|
- **THEN** it SHALL point at a dedicated-realm placeholder and SHALL NOT reference
|
|
`realms/master`
|
|
|