feat(daemon): daemon status lists the registered provider plugins

[thymikee]

Summary

Part 2 of 4 of #3755 (umbrella #3747), stacked on #3767. Blocked by #3748: do not merge before it.

• agent-device daemon status [--state-dir <path>] [--json] reads daemon.json without contacting the daemon and lists every provider it registered (builtin/store/embedder, active/failed, typed error.reason). A record whose pid/start time no longer names a live process reports running: false.
• plugins list --json still works without a daemon (it lists store selections), and when a daemon runs for the same --state-dir it also returns that daemon's inventory under daemon.
• daemon and plugins schema, usage and help updated; daemon stays out of MCP (mcpExposed: false).

agent-device daemon status --json
agent-device plugins list --json

Not in this PR: the failed inventory entry inside the provider-not-registered error. #3748 owns that error, so I'll add the entry after rebasing onto it.

9 files.

Validation

pnpm check:affected --run --head f8555c9010 (the stack top, which contains this layer): passed (exactCommit). CI owns integration, coverage and device lanes.

🤖 Generated with Claude Code

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://callstack.github.io/agent-device/pr-preview/pr-3768/
Built to branch gh-pages at 2026-10-16 23:19 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[github-actions]

Size Report

Metric	Base	Current	Diff
Installed (including dependencies)	5.35 MB	5.35 MB	+2.2 kB
Package (unpacked)	5.35 MB	5.35 MB	+2.2 kB
Package (download)	1.61 MB	1.61 MB	+758 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	23.9 ms	23.7 ms	-0.2 ms
CLI --help	67.4 ms	66.7 ms	-0.7 ms

[cubic-dev-ai]

All reported issues were addressed across 9 files

_{You’re at about 93% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

_{You’re at about 93% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[thymikee]

The code has one problem to fix before merge, and CI is green: 18 checks, 0 failing at 5645905. There are no conflicts.

readRecord and isTransport in daemon-status.ts add a third parser of daemon.json. The other two are readRegistration in daemon-registration.ts and readDaemonInfo in daemon-client-metadata.ts. isTransport copies readDaemonInfoTransport word for word, so the field schema (transport, version, plugins) now lives in two places and can drift. readRecord also catches every error and returns {}, which drops the absent/unreadable split that readRegistration keeps. If daemon.json exists but cannot be read (EACCES, I/O fault), daemon status prints "No running daemon for

." and plugins list leaves out the daemon inventory, even while a daemon serves that state dir. The rule: one owner in daemon-contracts parses daemon.json, and every reader uses it. Please move readDaemonInfo and its field readers into daemon-contracts next to readRegistration, or extend readRegistration to return the parsed record. Then build readDaemonStatus from that record and its registered, absent or unreadable status, delete readRecord and isTransport, and report "unreadable" instead of running: false. A test with an unreadable daemon.json should show that case.

Could readDaemonStatus become a small projection of registration status, the ownership check and readPluginInventory(record.plugins)? That would remove readRecord, the isTransport copy and the swallowed read error, and the CLI rendering and schema changes could stay as they are. The one thing that has to change first is a single daemon.json record reader in daemon-contracts, which daemon-client-metadata.ts then imports.

Not blocking, take or leave: plugins.md does not yet mention the daemon inventory that plugins list --json now returns (and line 20 still says an incompatible plugin stops the daemon from starting), so add one sentence or confirm a later stack PR owns it; and the em dash to hyphen change in the doc comment at daemon.ts:87 is unrelated and can be dropped.

Of the open inline threads, none still apply. All five are fixed at 5645905, so please resolve them: --clean only on stop, plugins flags per action, null start time, start-time JSDoc and plugins usage text.

No test here proves that a real daemon writes plugins into daemon.json; that write belongs to #3767, and every test here hand-writes the record. I did not rerun pnpm check:affected on the stack top, and I did not check whether a later stack PR owns the website page update and the changeset.

Before merge, one daemon-contracts reader must own daemon.json parsing for status, registration and client metadata. Merge also waits on #3748, as the PR body says.