[LutzLange]

Stacked on this fork so the diff is this PR only (base: copilot/pr3c-settings-jsonc). Eighth change in the series; James gets one integration PR from copilot/integration when the series is ready. Product-wide: every managed programs.* key, not only Copilot.

Why. The controller kept one configuration status per device (applied or failed, one error string), and one conflicting file blocks every managed file on the device. An admin could not tell which program conflicted, which were blocked by it, or which were configured but not pointed at the gateway because the local LLM proxy was not running.

What it does.

• Agent. Each apply reports an outcome per managed program, by precedence failed > conflict > blocked > inactive > applied/removed > unchanged. Provider gains a required id(). Reconciler::plan_with_report plans every provider and keeps planning past a failing one; AttributedPlan::apply applies with the same all-or-nothing rules and returns the same first error as before (Reconciler::apply now wraps it). ReconcilePlan::apply says where it stopped (conflict, changed file, private directory, failed write), so the failing program is failed, programs already written applied, the rest blocked. A program counts as changed when bytes on disk differ or it recorded a create/update/remove, so a sidecar rewritten with the same bytes does not make an unchanged program look applied. The Copilot CLI and both VS Code files report inactive with the reason. Reported programs: configured ones (an exhaustive destructure of ProgramsConfig) and ones with something to clean up, conflict or fail. Details are at most 1024 bytes; a sidecar parse error no longer quotes the file's values. Every apply logs one program configuration outcome line per program that is not applied or unchanged (warnings for failed, conflict, blocked).
• Proto (additive). ConfigStatus.programs (ProgramStatus { program, state, detail }, ProgramState) and ConfigStatus.programs_reported. Older controllers ignore them; older agents send neither.
• Controller. Migration 0003: device_program_status (with the report position) and device_config_status.programs_reported. A report is validated (at most 32 programs, IDs [a-z0-9-] up to 64 bytes, no duplicates, details up to 2048 bytes) and written with the device row in one transaction, so a program missing from a report disappears. A report that fails validation does not break the stream: the device status is stored and the last accepted program rows stay. GET /api/v1/devices/{id} returns programs and programs_reported; the device list and overview are unchanged.
• UI. A "Managed programs" card on the device page (tool, state badge, detail, time; rows from an earlier revision show it); "Per-program status is not reported by this agent version" for older agents; storybook fixtures for every state.
• README. "Configuration status" under "Start locally, grow into a fleet": the states, precedence, all-or-nothing, the log line, what a restart reports, rollout in either order, and that the migration is one-way (roll back from a database backup).

Process. Spec reviewed (Opus, 14 findings) and revised to rev 3 (the test author found attribution needs Provider::id); baseline tests first (f1e6e15, rebased as 6684bf5: 13 reconciler, 2 remote, 5 controller), unchanged through every revision (the test fake gained id()). Three review lenses: conformance conforms; maintainer one major (Reconciler::apply kept its own loop), adversarial minors (a sidecar value could reach the detail, a rejected report looped the stream, two stop paths untested), all fixed with tests. Delta 1 and delta 2 passed with minors (fallback only for invalid reports and keeping the last accepted rows; private-directory stop path tested; earlier-revision rows marked). The PR 3b test capi_tunnel_closes_when_the_cached_credential_expires failed under parallel load (a 300 ms cache window); fixed without weakening what it checks (ledger). Gate: agent 269, core 18, controller 18, storybook 52, clippy, fmt, schema, frontend.

Lab (Linux VM, user mode, controller-pushed config, API and admin UI). First run by an independent agent on v1: the device page lists claude-code, copilot, vscode; a comment in chatLanguageModels.json gives vscode conflict with the path, claude-code blocked ("not applied: vscode conflicted"), copilot unchanged, device failed, file untouched; without the proxy listener copilot and vscode are inactive with the reason; removing copilot gives removed, then no row; an older agent shows "not reported by this agent version"; a newer agent against an older controller applies without errors (an older controller refuses a database migrated by this one, documented). One checklist expectation was wrong by design (after a restart the report says unchanged, since the startup apply wrote the files first; documented, local issue 014 for the startup report). Repeat on v3 with lab/checks/pr4-status.sh: 14 of 14. The lab also found that its build script could install a stale binary when worktrees share a cargo target directory; fixed in the lab tooling.

Not covered: Postgres (tests and lab ran SQLite; the migration uses the same statements as 0001/0002); a check that no pairing value appears in the stored API responses (the lab agent was not allowed to read the pairing file; to be run by hand); retry after a cleared conflict (the reconcile tick, PR 5).

Follow-ups (local issue tracker): 014 report the startup apply; 002 reconcile tick; 006 sidecar rewritten on every apply.

🤖 Generated with Claude Code

[LutzLange]

Superseded: landed upstream in agentdesktop-dev#146 (per-program status).