Composing What Runs¶

The nine features¶

Everything is on by default. An install with no configuration is byte-for-byte the historical stack, so there is nothing to do unless you want less.

Change it from the terminal¶

coding-features                    # what is on, and why
coding-features set knowledge off  # one feature
coding-features profile proxy-only # a preset
coding-features explain knowledge  # why is this off?

Or from the dashboard¶

Health → Features, or localhost:3032/features directly.

Each row carries its id, when the change takes effect, and whether it needs Docker. Nothing happens until Save & apply.

Four presets¶

Only knowledge, codegraph and constraints need Docker. Switch all three off and the launcher never starts the container or asks for a daemon — which is what makes the bottom three profiles work on a machine without Docker Desktop.

Dependencies resolve downwards, never upwards¶

Three features are built on others:

lsl ──▶ observations ──▶ knowledge
llm-proxy ──▶ performance

A dependent whose dependency is off is switched off too. The dependency is never switched on for you. Turning something off is an explicit instruction and is honoured exactly; turning something on by implication would start services you did not ask for.

The editor previews the whole cascade before you commit to it. One click on Live Session Logging takes Observations and Knowledge Base with it — each greyed out, each saying which dependency it is waiting on, and the footer counting what would survive the save:

A blocked feature's toggle is not merely greyed — it will not move. Turning Knowledge Base back on from that state would be undone by the resolver a moment later, and a switch that silently flips itself back is worse than one that refuses.

When a change takes effect¶

Not everything can apply instantly, and the UI says which is which rather than implying they are all the same.

Where the setting lives¶

Four layers, last one wins:

1. built-in defaults — everything on
2. <repo>/config/features.yaml — committed, shared by the team
3. ~/.coding/features.yaml — this machine; what the CLI and the dashboard write
4. CODING_FEATURE_<ID>=on|off — this shell only

coding-features explain <id> names the layer that decided, so "why is this off" has one answer everywhere — the CLI, the status line tooltip and the dashboard chip all quote the same reason string.

Turning off the thing you are looking at¶

The dashboard is served by the health feature. Saving proxy-only or minimal from the editor therefore stops the editor. It asks first, and whatever terminal or log the apply lands in prints the way back:

⚠️  Health Monitoring is now off: the coordinator and the dashboard have stopped.
    The dashboard cannot turn it back on, because the dashboard is part of it.
    To restore everything:  coding-features profile full

What a pared-down install looks like¶

The status line is the fastest way to see the effect — a disabled feature contributes no badge at all, rather than a greyed-out one:

full — everything on:

[🏥●] [AX●C●] [🔒72%●7] [📚●] [N:OPEN P:AUTO] [🧠●] ███░░░░░ 46% [📋8-9] 08:19

logging-only — health, sessions and the log tranche survive; the knowledge, constraint and proxy badges go with their features:

[🏥●] [AX●C●] [N:OPEN P:AUTO] ███░░░░░ 47% [📋8-9] 08:19

proxy-only — one badge, the gauge, the clock:

[🧠●] ███░░░░░ 47% 08:19

minimal:

███░░░░░ 47% 08:19

The context gauge and the clock are core, not a feature, so they survive every profile. The examples above are generated from the real renders by scripts/render-statusline-png.mjs --spans, not typed — hand-written bars on this site had already drifted to ten-cell gauges and a split [N:] [P:] pair months after both changed.

Nine features, one resolver, four surfaces that must agree about them. This tier is the mechanism: how a decision is reached, who is allowed to act on it, and which failures are deliberately asymmetric.

The resolver¶

lib/features/resolve.cjs is the only thing that decides whether a feature is on. It is CommonJS on purpose — the status line renders it on every tmux tick and cannot afford ESM resolution — and it is mtime-cached, so a read costs a stat().

Four layers, evaluated in order, last one wins:

Layer 2 exists so a project can pin what it needs without every developer configuring it by hand; it ships entirely commented out, so it doubles as schema documentation in the place you would look for it.

Every resolution carries a reason string, and every surface quotes it verbatim rather than re-deriving one — coding-features explain, the status line tooltip, the dashboard chip. That is what makes "why is this off" have exactly one answer.

Dependencies¶

lsl ──▶ observations ──▶ knowledge
llm-proxy ──▶ performance

The rule is one-directional: a dependent whose dependency is off is auto-disabled; a dependency is never auto-enabled. Off is an explicit instruction and is honoured exactly. On-by-implication would start services nobody asked for, which is how a "minimal" install quietly becomes a full one.

The resolver applies this transitively to a fixed point, and so does the dashboard's preview — switching lsl off greys out observations and knowledge. An editor that previewed only one level was worse than one that previewed none, because the second surprise arrived after the click.

Fail-open and fail-closed are deliberately asymmetric¶

Apply tiers¶

apply deliberately does not restart the world: coding --claude already does a full start, and a config edit should cost the smallest disruption that makes the config true.

The three kinds of artifact¶

Adding a service, daemon, container program, tab or badge means declaring its feature, and four mappings have to agree — lib/features/daemons.mjs, scripts/apply-features.mjs, docker/entrypoint.sh and the architecture reference. tests/features/*.test.mjs fails the build when they drift.

There is one artifact that fits neither table: the ETM. enhanced-transcript-monitor.js is the writer behind lsl, and the health coordinator spawns it per project detached and unref()ed — no launchd label, no supervisord program, and it outlives whoever started it. It is therefore gated in three places rather than one:

The last two overlap on purpose: the coordinator can only reap while it is running, and minimal and proxy-only stop it in the same pass that switches lsl off.

Why the API lives on the coordinator, not the dashboard¶

/features is served by the health coordinator on :3034. The dashboard runs inside the coding-services container; the file it edits (~/.coding/features.yaml) is on the host, and applying a change runs launchctl / systemctl / schtasks. server.js reverse-proxies /api/features so the browser sees one origin. There is exactly one writer implementation, lib/features/write.mjs.

Docker¶

Only knowledge, codegraph and constraints need the container. With all three off, _start_services() skips it entirely and the launcher never demands a daemon.

health deliberately does not need Docker: the coordinator and both dashboard servers have host implementations, which is what lets logging-only run a dashboard on a machine with no Docker Desktop at all.

Reference¶

The engineering reference — the full feature→artifact matrix, port table, badge ownership, and the coordinator health-check mapping — is docs/architecture/features.md in the repo.