# 0034. Config editing UI: the layer-grouped effective-config view, and why the rest waits on proto

Status: Accepted · Date: 2026-10-26 · Design section: CLI and UI, Patch layers

Decided: built the one piece of phase 6's "config editing by layer ... effective-config view annotated by origin and secrets masked" that the current API surface actually supports — grouping `GetEffectiveConfig`'s values by `origin.layer` in the design's own bottom-up order — and did not build layer *editing*, impact preview, or schema-driven forms, because none of them have a backend to call yet.

## Context

Roadmap phase 6 is "config editing UI." Architecture.md's `## CLI and UI`
section names four things: "config editing by layer," "an effective-config
view annotated by origin and secrets masked," "impact preview before
applying," and "schema-driven forms." Before building any of it, checked
what `proto/ichor/v1alpha1/` actually exposes today — unchanged since ADR
0016, still only `ClusterService`, `MachineService` and `NodeService`,
none of them with a write method for `TalosConfigPatch`:

- `NodeService.GetEffectiveConfig` is read-only and already returns
  exactly `EffectiveConfigValue{path, value, secret, origin{layer,
  source}}` per leaf (ADR 0018) — the "effective-config view annotated by
  origin and secrets masked" clause is already fully backed.
- There is no `PatchService` (or any method on an existing service) to
  list, create, update or delete a `TalosConfigPatch`. "Config editing by
  layer" means writing one; there is nothing to call.
- `pkg/fieldmeta.Assess(paths []string, pinned *VersionContract) Impact`
  is the whole implementation of "impact preview" — but it takes *the set
  of changed paths* as input. Nothing changed exists without an edit to
  diff against, and no RPC passes a proposed change anywhere, so this
  function cannot be invoked from the browser's side of any existing
  call. It is also Go-only, not reachable from the UI directly even if an
  edit existed to feed it.
- No RPC returns a CRD's schema. `TalosConfigPatch`'s full shape (the
  typed-config mirror types ADR 0003 generates) is baked into
  `config/crd/bases/ichor.maesh.dev_talosconfigpatches.yaml`'s committed
  OpenAPI schema, but nothing serves that schema to a browser that only
  talks to the backend, not the Kubernetes API server (architecture.md,
  "Trust").

## Decision: build the effective-config view's layer grouping, nothing that needs a write path

`ui/src/pages/NodeDetail.tsx`'s `EffectiveConfigSection` already called
`GetEffectiveConfig` and rendered one flat table (built in the phase 5
unit, before this one). It did not satisfy "the effective-config view in
the UI shows which layer each value came from" (architecture.md, "Patch
layers" — the one concrete UI requirement that section states): origin
was a text column to read per row, not a grouping. `groupByLayer` buckets
`EffectiveConfigValue[]` by `origin.layer` and renders one table per
layer, in `ConfigLayer`'s own numeric order — which is already the
design's bottom-up order (system, cluster, role, selector, machine), so
no second ordering table was needed. A short, explicit line above the
tables says this view is read-only and that editing isn't available from
this screen yet, rather than leaving a reader to wonder why there's no
edit button.

**Not built, and not stubbed**: a patch-editing form, an impact-preview
panel, or a schema-driven field list. Ponytail's first question —
does this need to exist — has a clear answer here: a form with no RPC to
submit to is not a smaller version of the feature, it is a non-functional
one that looks finished. Building it would also have meant exactly the
mistake the task warned against twice over: hand-listing `TalosConfigPatch`'s
fields (when mirrorgen exists specifically so no parallel catalogue of
Talos's field names has to exist, ADR 0003) and hand-porting
`pkg/fieldmeta`'s reboot/install-time verdicts into JS (a second, harder
to keep in sync, copy of a table whose own package doc explains at length
why each entry needed real verification against Talos's source rather
than being guessed).

## Gap report: what proto needs for the rest of phase 6

Not added, per the task's own instruction — reported with enough shape
that implementing them is mechanical, not another research pass:

1. **A write path for `TalosConfigPatch`.** Smallest useful shape: a
   `PatchService` with `ListPatches(cluster ObjectRef) → []Patch`,
   `GetPatch`, `CreatePatch`, `UpdatePatch`, `DeletePatch`, mirroring
   `MachineService`'s own shape (ADR 0016) rather than inventing a new
   one. `Patch` needs at least `ref`, `clusterRef`, `layer`, `priority`,
   `target`, `documents[]` — the same fields `TalosConfigPatchSpec`
   already has; the wire message should mirror the CRD spec, not reduce
   it.
2. **Impact preview needs a method that takes a proposed edit and
   returns `pkg/fieldmeta.Assess`'s result.** Either a dry-run field on
   `CreatePatch`/`UpdatePatch` (compute the diff server-side against the
   currently-applied config, call `Assess`, return the `Impact` alongside
   or instead of writing), or a standalone `PreviewImpact(patch) →
   {rebootRequired bool, installTimeOnly []string, unsupported []string}`
   — `fieldmeta.Impact`'s three fields, unchanged. Either way, the UI
   needs to show `installTimeOnly` and `rebootRequired` as genuinely
   different outcomes, not two severities of the same warning: the design
   task that produced this ADR was explicit that a reboot does nothing
   for an install-time-only field, so presenting them identically would
   invite an operator to reboot for no reason.
3. **Schema-driven forms do not need a new RPC** — `config/crd/bases/
   ichor.maesh.dev_talosconfigpatches.yaml`'s OpenAPI schema is already
   committed and already generated from the same mirror types a form
   would need to render (ADR 0003), and the browser already never talks
   to the Kubernetes API server directly, so serving that one YAML file
   (or a JSON-converted copy) as a static asset — no live cluster state
   in it — doesn't cross the "browser talks only to the backend" line
   either way. This is recorded here rather than built now because a form
   with nothing to submit to (point 1) is not worth building yet, not
   because the schema itself is hard to reach.

## Consequences

- `ui/src/pages/NodeDetail.tsx`'s effective-config view groups by layer;
  `ui/src/lib/`, `proto/`, `internal/uiapi/` are otherwise untouched by
  this unit.
- No proto change. `buf lint`/`buf breaking` were not run against a diff
  because there is no proto diff.
- The three gaps above are not new discoveries — ADR 0016 and ADR 0018
  already named "config editing, a different, later unit" and "disk
  roles and network link configuration join this request message,
  additively, once they land on the CRD" as deferred. This ADR is the
  first unit that actually needed them and found no workaround, so it
  records the concrete shapes rather than leaving the gap as a one-line
  mention.
- `TalosOperation`'s progress view, the GitOps page, PR mode and OIDC
  remain out of this unit's scope, per the task's own boundary.