Skip to content

Configuration Master — Settings, Runes, selectors and generation boundaries #64

Description

@zenithruneblade

Scope split with Extension Master #63: this issue is the map of operator-selectable and tunable values—principally global Settings, Rune schemas/instances, exact registered references, bounded policy and their immutable generations. It does not define how Backend, Altar, Graph, Animator/Connector, Composition or Packaging become extensible. Those contribution surfaces and their child issues belong to #63; this master specifies how an already admitted surface may be configured without turning data into code or authority.

Map everything LychD may configure, the source and scope of each value, and the boundary between declared intent, runtime observation, durable truth and authority. This is a tracking and decomposition issue, not a second configuration implementation.

Canonical law remains in ADR 12 — Configuration. Supporting owners include ADR 05 — Extensions, ADR 08 — Containers, ADR 09 — Security, ADR 22 — Dispatcher, ADR 23 — Orchestrator and ADR 28 — Workflow. Issues cite these decisions; ADRs do not embed the mutable backlog.

Configuration surface map

Surface Scope / representation Delivery / bounded work Boundary to preserve
Global Settings One immutable lychd.toml generation plus declared environment/file-secret precedence #1 Closed typed root; unknown/obsolete fields fail; every accepted field has a real consumer
Rune instances Typed TOML leaves in owned anchors with path identity and provenance #1, #21 Runes declare intent; they are not runtime objects, registries, raw units or authority
Extension selection Exact built-in/Crypt activation ids #21 Selection permits one boot registration generation; it does not start services or enable arbitrary neighbours
Host realization Validated generation compiled into owned deployment plans #3, #18 Revalidate ports, secrets, mounts, routes and ownership before effects; direct raw unit injection is forbidden
Capability instances and profiles Exact registered interface/profile/driver refs plus bounded overlays #42 Configuration cannot invent capabilities, proved limits, permissions or provider readiness
Dispatch ranking and fallback Versioned bounded policy over already eligible candidates #17 Eligibility and authority remain hard constraints; fallback cannot silently change semantic road
Resource and lifecycle policy Declared limits, service classes and transition policy #16, #50 Measurements and current readiness are observations, not TOML truth; Orchestrator owns physical convergence
Scroll/casting selection Exact registered Scroll, implementation, Agent/Posture and Context refs plus bounded policy #29 Canonical Scroll remains typed JSON; no Python imports, Graph nodes, arbitrary prompts, source bytes, credentials or live handles
Application/Gateway deployment profiles One exact registered profile revision and role set #3, #57, later Composition-specific work Loose booleans cannot assemble partial authority, migration, network or credential topology
Altar editing Typed staged request, whole-tree validation and explicit apply/reload #56 UI does not gain ambient filesystem, secret, activation or promotion authority
Presentation preferences Finite validated semantic fields when admitted #56 or a later bounded frontend slice No raw CSS/selector or extension side channel; accessibility invariants remain frontend-owned
Secrets References in Codex; values resolved once through the accepted secret boundary #1, #37 Secret values never enter TOML, snapshots, ordinary telemetry or generated samples

Generation and change requirements

  • State the owner, source, scope, units, defaults, bounds and precedence for every configurable value.
  • Distinguish global Settings, reusable profile defaults, Rune-local overlays, request-time overrides and observed runtime facts.
  • Validate the complete selected Settings/extension/Rune generation before reconciliation; downstream consumers never reopen the files.
  • Pin admission-relevant selection for existing Runs. A newer configuration generation affects only lawfully new admissions unless an owning migration says otherwise.
  • State whether a change is a no-op reconciliation, explicit reload, service restart, new Vessel generation or typed Evolution effect.
  • Missing, stale, contradictory and unsupported values fail visibly; they never trigger a hidden default provider, route or authority.
  • Configuration chooses only already registered and authorized identities. It cannot register code, create Graph edges, grant effects, prove readiness or rewrite durable history.
  • Samples and editor projections remain inactive or staged until explicitly applied and revalidated.
  • State of Work and maintained receipts distinguish typed validation from live host/model/network acceptance.

Existing first slices

Completion dimensions

Treat closure as two independent proofs:

  1. Map completeness: every admitted field, selector, precedence edge, and generation transition has one owner and a bounded route or explicit deferral.
  2. Operator journey evidence: one maintained edit → preview/diff → validate → apply → reload/restart path proves immutable generation handling, error visibility, secret boundaries, and effect ownership.

A complete field map does not prove the journey; one working editor does not make every value safely configurable.

Completion condition

Close this master when every admitted field and future selector in ADR 12 has a bounded issue or explicit deferral; cross-surface precedence and generation transitions are unambiguous; and one maintained operator route shows edit/preview/apply/restart behavior without leaking authority.

Closure means the configuration map and decomposition are coherent. It does not mean every Designed selector or UI editor has shipped.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:hostCLI, layout, host services, binding and installation lifecycle.trackingCollects deliverables or routes work; not one implementation assignment.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions