The Support Loop.

01 · Releases

One week, two lines, ten releases

What a user actually gets — not a changelog, the experience.

Alongside the releases, the same week carried performance work now in Modern's line: the TX→RX capture reopen after a transmission dropped from ~270 ms to ~200 ms, muted RX frames stopped being broadcast while the radio is keyed, and PTT release latency got its own SDD version row (V2.55). None of it is glamorous. All of it is measurable.

And the loop itself shipped that week too: on Sep 19, MRRC Modern deployed the FDE board — the lineage's fourth loop practice — a public kanban where every analysis lands classified (bug / feature / noise), plus an unattended implementer that turns scheduled entries into test-gated patches on isolated branches. It is not an installer, so it is not in the table. It is the subject of §05.

02 · The chain

What "self-service" and "self-diagnosis" actually mean

Five stages — release → upgrade → diagnose → analyze → answer — with the round-trips engineered out.

Most support chains are an email alias with hope. This one is a pipeline with an instrument on each end. On the user's side, the app is built so that the four things a user needs never require a ticket:

On the maintainer's side, the same chain runs on a ten-minute cron: fetch new bundles → summarize (reusing the exact summarizer the client ran, so both ends agree on what the summary means) → model analysis under a written discipline → a structured JSON verdict → a rendered card → publish. Publishing is default-deny, runs are idempotent per bundle ID, half-packages are skipped, and each pass caps at two bundles.

Both product families now run this identical chain. Modern inherited it whole with v1.18.0 — bundle format, summarizer, answers page, update check — and its first two auto-triaged replies went out on Sep 19, within a day of its first bundles arriving.

03 · Walls → features

Three incidents that became shipped product

How solved problems mine new requirements — the mechanism, not the slogan.

03.1 · The rigctld wall

The same wall, twice in one morning

On Sep 17, two FT-891 reports arrived within two hours — 20260917-073700-14ef at 07:36, 20260917-085736-ebd2 at 08:53. Same symptom ("can't connect to the radio; audio syncs fine"), same verdict from the bundles: the CAT daemon rigctld wasn't running, the config was correct, three logged timeouts, no crash. Per the verdict table, both cases were environment, and both answer cards taught the user the same PowerShell incantation.

Individually closed. Together, a product gap: a "universal remote" that requires every new user to hand-launch a daemon is making the same ask of everyone. The repetition converted it. The same day: hotfix 6.1.14 shipped auto-start (rigctld_supervisor.py); hotfix 6.1.15 fixed model-name→number resolution (rigctld --list) and vendored rigctld.exe into the installer (V6.1.15); V6.1.16 made the fallback yield instead of ever blocking a boot. A public answer card now tells FT-891 owners to just update.

03.2 · Water sound

An answer became a default; a default became an engine

Report 20260917-132643-020a: "water flowing, distortion after denoising" on NR2 level 2. The bundle's own numbers made the verdict provable rather than plausible — audio capture health 99.9%, no Traceback, no double-denoise stack — so the card diagnosed the classic spectral-subtraction musical noise artifact and taught the moves: level 2→1, AGC mode, bandwidth.

Then the product absorbed the lesson in three steps over three days. Default changed: the NR2 level table moved down a notch (hotfix 6.1.17), then to −6/−9/−12/−16. Knobs exposed: C-layer alpha/npMax setters in a rebuilt libwdsp, with new defaults closed-loop measured (npmax 0.98, AE 20/0.50). Engine added: NR3 — RNNoise, a neural denoiser from Xiph — selectable as plus|only|off, shipped in V6.1.18 together with the gating fix that makes "off" a true bypass (users had reported distortion persisting after turning denoise off — itself a report worth mining).

03.3 · macOS silence

Two silent failures, and the regression protocol

Modern's first macOS release hit two silent failures, and both fixes are lessons in observability. "Damaged": every macOS build so far had shipped unsigned — the signing step had been failing silently in the build — so Gatekeeper refused the app with a dialog no right-click bypasses. The fix is twofold: lay the bundle out the way codesign requires, and make a failed signature abort the build. The silent failure was the defect; the dialog was only the symptom. Silent RX: the bundle declared no audio-input permission, and macOS answered by opening the capture stream and filling it with zeros — the log said "check the radio" while CoreAudio reported no error. The fix requests the permission properly and points the warning at System Settings, not the radio.

The third case is the triage system biting its own tail, productively. Bundle 20260918-114118-9ad3 carried a "Recording dropped / queue full" signature matching a defect fixed in V2.44/V2.45 — but every matching log line was dated Sep 12, before the fix shipped. The published verdict refused both easy answers ("already fixed" / "regression!") and ran a protocol instead: the user records one new QSO and reports back; the follow-up bundle (20260919-085517-b3aa) closed it, with Sep-19 logs healthy and the old lines identified as pre-fix residue. The harness change that made this possible is one line of process, committed as ecb2652: the model reads the project's own incident history before writing verdicts — SDD version history, CHANGELOG, and exact code positions are inputs, not afterthoughts.

04 · First reading

The machine's first reading, the human's verdict

Triage is a contract, not a vibe: a structured output, a verdict ontology, and guardrails that fail closed.

The analyzer's output is a fixed JSON contract — verdict, status (answered | needs_fix | need_more_info), category, diagnosis[], solution[], evidence[], keys[], needs_code_change, code_hint — rendered into the answer card verbatim, evidence lines included. The verdict ontology is written down as a table, not a feeling: Traceback or a repeating exception → defect; many launches without a Traceback → not a crash; -9996 with an empty device table → environment (a VM without a sound card); rigctld not running → environment; capture health below threshold → performance; certificate warnings → normal noise.

05 · The fourth loop

From answered to implemented

On Sep 19 the chain grew a public board and an unattended implementer — the loop now reaches the code.

05.1 · The board

Classification is the decision

Until Sep 19 the loop could read and answer, but the bug/feature split it produced had nowhere to go — a human still had to pick what to fix, fix it, and close the case by hand. The board (vlsc.net/mrrc_modern/board) supplies the missing halves, and its rule is one sentence: classification is the decision. The analysis contract gained three optional fields (kind: bug / feature / noise, plus severity and title), and the taxonomy became a dispatcher:

The board and the answers page share one privacy filter (redact_public) and link to each other. A user's report becomes a card with a status column — feedback stops being a mailbox and becomes a queue with a visible position, which is also a public promise: what got closed, what got scheduled, what is still waiting, and why.

05.2 · Unattended implement

A tested patch on a branch, while main sleeps

The same cron that triages now carries --implement. For each scheduled entry, single-flight — one entry per run, and only from a clean main worktree — the pipeline runs the model with read-only tools (read,grep,find,ls) and asks for a JSON contract: understanding, a unified-diff patch, a test plan, a risk level, a commit message — or no_action, which lands on the board as Rejected with the reason. The model has no write permission; the patch is text until the pipeline decides otherwise.

What the pipeline does with that text is where the safety lives:

• Guards first — the two cross-file tooling-guard scripts, certs/, win/, packaging/ and the installer manifests (.iss) are refused outright; a single patch may touch at most eight files.
• git apply --check before anything moves; a failed check ends the attempt with the reason recorded on the board.
• An isolated branch — the patch is applied only on a fresh fde/<id> branch, never on main.
• The full test suite is the gate — green commits to the branch (the board records branch@hash plus the test line); red deletes the branch, restores the worktree, and records failed with the tail.
• main never moves. An unattended process cannot reach it; merging the branch is a human act.

The design view is the same one behind the PTT gate: the machine may propose, evidence decides, the human accepts. Nothing about the radio is automated away, and nothing about the code lands unreviewed — what changes is that a scheduled bug no longer waits for a human to be at a keyboard to even begin.

05.3 · The loop's own incidents

Two failures of the loop itself — and what they prove

An unattended loop has failure modes of its own, and two of them surfaced within the first day — each worth more than the feature it delayed.

The model runner that couldn't run. The cron triage pi had been dying with SIGABRT two days running. Root cause: a Homebrew upgrade had broken the bottled Node's dylib linkage (llhttp) — the model runner, not the model. The fix was not a retry but a diagnosis: run_pi now names signal death and its likely cause in the log. A loop that fails wordlessly is indistinguishable from a loop with nothing to do; an unattended loop must be able to explain its own silence.

The test fixture that reached production. Test runs patched the local page paths but still shipped their fixture answers/board pages to the live server — discovered because the production board suddenly displayed a test bundle ID. The fix made page shipping one patchable seam (_ship_page()), and the verification is the point: a full 1,299-test run now leaves both the local board state and the live board page byte-identical. The loop's own release path is under test.

05.4 · Distillation

The human's job compresses to two verbs

Read against §04, the board changes what the automation is allowed to decide. Before: the machine read and classified, and a human chose, fixed, and released. After: classification dispatches — noise closes itself, bugs enqueue themselves — and the human's intervention collapses to decide (one scheduling note per feature) and merge (accept a tested branch). That is the same division of labor as the rest of the engineering system — judgment human, execution delegated, evidence gates — now applied to the product's own backlog rather than its source tree.

06 · Loops, honestly

What this chain says about agentic engineering

Agentic engineering separates judgment from execution. The support chain is that separation applied where the users are.

06.1 · Boundaries

Loops have boundaries — and the repo is the wrong one

The ledger article (Seven Billion Tokens, Dissected) measured the inner loop: contract tests go red first, agents deliver to green, median 19 minutes. That loop closes inside the repository. But a green suite is a loop closed around the wrong boundary if the unit of iteration for a product is not the commit — it is the unanswered user symptom. A product can ship for months with every test green and every third user stuck on the same wall, because nothing inside the repository boundary can see the wall. The support chain extends the loop: field → bundle → verdict → product change → release → user self-service. The loop only counts as closed when the user's next click succeeds without a human in the path.

06.2 · Bandwidth

Self-service is bandwidth, not courtesy

Every step moved to the user's side removes a round-trip from the loop: upgrade without a download page, rollback without a reinstall, a diagnosis without reading logs, an answer without an email. The design test for each is the same sentence: can the user complete the move without understanding the log? This is why "self-diagnosis" is not a marketing word — the bundle is an instrument placed on the user's side, designed for the receiver rather than the sender: redaction by whitelist, a summary written to be read at a glance, restarts discriminated from crashes, device tables attached. And it is why the answers page publishes raw evidence lines: a user who can check the reasoning can trust the next answer before reading it.

06.3 · Conversion

Signatures, not verdicts, promote into the roadmap

One report is a case. A repeated signature is a requirement. The verdict ontology is what keeps this honest — it is the sieve that protects the roadmap from phantom requirements (environment misread as defect) and protects users from abandonment (defect misread as environment). But the quantity that actually drives iteration is the signature across reports, plus the time from signature to shipped fix. Sep 17: two environment verdicts, two hours apart → same-day hotfix. Sep 17–18: one tuning answer → level table → knobs → third engine. The support queue and the roadmap are the same ledger, read at different periods.

06.4 · Cadence

A cadence stack, not a single loop

A system's learning rate is set by the fastest loop able to capture each class of incident. The support chain adds the outermost period to the stack — the only one that can capture classes that never appear inside a repository: virtual machines without sound cards, USB re-enumeration, macOS permission dialogs, Gatekeeper. The ledger's incident chains (13 days, then 7 days, from incident to machine-enforced constraint) and this week's same-day support arcs are the same principle measured at different radii.

06.5 · Two ledgers

The ledgers apply to answers, too

"Answered" is process evidence: it says the case was read, classified, and given an actionable move. "Fixed · 6.1.13" is a product claim bound to a shipped artifact. The answers page keeps the two apart, and need_more_info exists as the honest rung — one of the first seven replies stands there. Nothing in a support card promotes a product claim; the version row in the release ledger does. This is the same discipline as the main evidence ledger (/agentic.html#evidence): a process badge never promotes a product claim, and the boundaries stay written down.

06.6 · The non-delegable core

What stays human, on purpose

Three things in this chain are deliberately human-only. RF safety: the upgrade path refuses to touch a transmitting radio (the 423 gate) — no automation overrides the PTT gate, and no automated verdict touches transmit behavior. Privacy anchors: keys, passwords, recordings, and memory channels never leave the user's machine; redaction is a whitelist, not a promise. The verdict on code: needs_code_change, the change itself, and the release are maintainer-owned — the machine's reach ends where the diff begins. Deep hardware bring-up (marginal USB power, CI-V quirks) also remains manual, and the lifecycle documentation writes its limits down explicitly — summary-based triage reads summaries, not whole environments — instead of implying automation it doesn't have. The umbrella page names this retained half — intent, boundaries and judgment — and its rule is why this section exists: agents carry execution, not accountability (roles).

06.7 · Claims

What I claim — and what I don't

Claimed: the chain converts field symptoms into shipped product changes with cited evidence at every step; users resolve the majority of issue classes without a human round-trip; every published verdict is checkable against raw log lines; the failure modes of the triage automation itself are bounded and written down. Not claimed: autonomy over the roadmap — a human reads the answers page and decides what a signature is worth; safety automation — nothing in the pipeline touches transmit; completeness — summary-based triage cannot see everything a full environment shows, which is exactly why need_more_info is a first-class outcome. The products were built by the maintainer's hands and pipeline; the agent's role is triage, first reading, and the mechanics of publishing — and the products are better this week because of what the loop carried back, not because of who did the typing.

07 · Closing

Close the loop that touches the user

One week, two releases, and a sentence to keep.

Self-service is not a cost optimization; it is the sensor network of the product. A support chain that only answers mail is a cost center. A support chain that turns repeated signatures into shipped features — same-day hotfixes, changed defaults, new engines — is a requirements engine. The loop that touches the user decides whether the product evolves, so close it deliberately: instrument the failure before fixing it, make the answer self-service before scaling the queue, and let the repeated signature promote itself into the roadmap while the verdict stays human. And when the loop grows an implementer, the same discipline scales: classification decides, the machine proposes, the tests gate, and the merge stays human.

Try the endpoints: MRRC answers · MRRC Modern answers · MRRC download · MRRC Modern download. Comparable cross-project numbers (tests, constraints, versions) live in one place: the evidence ledger.