Files

T

cgalo5758 6dbce6140f Type the ConfigSpec seam and move the connect target to core

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.

2026-08-01 04:13:48 -05:00

2.3 KiB

Raw Blame History

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

2.3 KiB Raw Blame History