Repository navigation
feat(mcp): let agents ask BOSS how it is doing - #1369
Conversation
95dd3fa to
30c9191
Compare
|
Review disposition: draft pending a clean rebase onto current dev. Oldest-first history check: the branch contains 68 commits that are already patch-equivalent to dev; only 30c9191 (the five-file boss-introspection feature, authored by @Vidhaankhare16) is unique. The unique feature behavior is coherent:
The merge blocker is branch ancestry, not that feature logic. A three-way merge against current dev would remove 28 current-dev paths, including:
Please rebase/update this branch from current dev and retain your feature commit/credit, or create a clean branch from dev and replay only 30c9191. Before requesting review again, verify:
Related-work check: #1364 is the matching open issue; #997 (workspace contents) and #1120 (panel layout) are adjacent MCP surfaces, not duplicates. No separate Claude review is present on this PR; the issue feedback from @surfthewave-commits is reflected in the unique tip's nested health payload, explicit not-sampling behavior, read-only declarations, and registration-wiring test. No migrations were applied. |
bdcf620 to
bc9aa3b
Compare
BOSS computes both halves of its own condition and exposed neither to a tool caller. WorkspaceHealthReport is reachable only through SingleInstanceManager - over the single-instance socket, from a CLI process outside the host - because `boss doctor` was built for a human at a terminal (risa-labs-inc#418, risa-labs-inc#579). The performance monitor publishes its snapshot to a settings panel and nowhere else. So the agent inside the host, the party that has to decide whether to open another browser tab or spawn another terminal, had no way to ask whether the host was already degraded or near a ceiling; it found out by causing the failure. Adds a host provider, boss-introspection, with get_workspace_health and get_performance_metrics, both read-only by declaration rather than by the mutating gate's fail-closed default. The health tool returns WorkspaceHealthReport.toJson() - the same object `boss status --json` emits - so the CLI and the MCP surface cannot drift into two shapes for one concept, and scripts and agents match the same codes. Counts and aggregates only. ResourceMetrics carries per-tab, per-terminal and per-editor lists and CpuMetrics carries thread names; none of it travels. A caller deciding whether it has headroom needs to know there are eleven browser tabs, not which pages they are on. A snapshot that does not exist yet reports sampling=false with no memory object at all, never zeros, for the reason the health report separates unchecked from "no findings": a caller reading 0 bytes used and concluding it has headroom is worse off than one told the monitor has not reported. Both sources are desktopMain and the provider is commonMain, so they arrive through suppliers wired in main.kt the way WorkspaceMcpToolProvider.windowCreator already is - which is also what lets the tests drive it with fakes. The health payload is nested under "health" rather than flattened beside an "available" flag, so the value is byte-identical to what `boss status --json` emits under its own "health" key and the two surfaces can be diffed on one machine. A test pins it by equality against toJson() rather than by spotting fields, and a future field on the report can no longer collide with "available". A drift test pins the registration and both supplier wirings. The failure it guards is silent: the provider can compile, expose its tools and pass every one of its own unit tests while never being registered, or while registered with no suppliers behind it - in which case every call answers available=false on a healthy host and the tools read as broken rather than absent. Source-text rather than booting the registry, which would construct the policy engine, approval bus and ledger and reach ~/.boss on the machine running the suite. Both raised by @surfthewave-commits in review on risa-labs-inc#1364.
30c9191 to
132541f
Compare
|
Rebuilt as you described: a clean branch from current Your four checks, run against that head: 1. The provider, its two wiring changes, its two focused test files. The live-sessions paths you listed — 2. 3. 4. No workflow or CI configuration touched; existing coverage is unchanged. Hosted CI on The same ancestry was on three more of mine. #1340, #1343 and #1347 were cut from the same pre-rewrite
#869 you had already rebuilt yourself - thank you. I have addressed the Claude review of One thing I could not do, and want to be straightforward about: I tried to reproduce the 28-path deletion you found with |
|
Merged to dev (squash). Gate: diff verification + CI green on head. feat(mcp): let agents ask BOSS how it is doing. |
…shots (#1595) #1524 dropped ResourceMetrics.browserTabs (and BrowserTabInfo with it) while #1369's introspection test still constructed one, so dev's compileTestKotlinDesktop fails on the merged tree - both PRs were green against their own bases. The privacy property the test pinned is now structural (nothing per-tab is retained), so the test now pins the wire shape instead: the count is reported and no per-tab key ever appears. Co-authored-by: Instinct Agent <agent@instinct.com>
3 participants
What this adds
A host MCP tool provider,
boss-introspection, answering "what condition is BOSS inright now?" with two read-only tools. Fixes #1364.
get_workspace_health/workspace_healthWorkspaceHealthReport:degraded,findings[]with stable codes and remedies,unchecked[],partial[]get_performance_metrics/performance_metricsThe gap
BOSS already computes both halves of its own condition and exposes neither to a tool
caller.
WorkspaceHealthReportis reachable only throughSingleInstanceManager— over thesingle-instance socket, from a CLI process outside the host.
boss doctor(#418,#579) was built for a human at a terminal.
PerformanceMonitorpublishes its snapshotto a settings panel and nowhere else.
So the agent sitting inside the host, which is the party that actually has to decide
whether to open another browser tab or spawn another terminal, could not ask whether
the host was already degraded or near a ceiling. It found out by causing the failure.
Three decisions worth reviewing
One contract, two surfaces.
get_workspace_healthreturnsWorkspaceHealthReport.toJson()— the same objectboss status --jsonalready emits —rather than a second shape for one concept. A script written against
boss doctor --jsonand an agent calling this tool read the same codes, and theycannot drift apart later.
Magnitudes, not contents.
ResourceMetricscarriesbrowserTabs,terminalsandeditorTabs;CpuMetricscarries a thread list. Those hold URLs, file paths andthread names. None of it is emitted. A caller deciding whether there is headroom needs
to know there are eleven browser tabs, not which pages they are on, and a tool that
answered the second question would be a far larger disclosure than the one it was
asked. There is a test asserting a tab's URL and title never reach the output while the
count still does.
Honest about not knowing.
PerformanceMonitor.currentSnapshotis null untilstart()has run and the first tick has landed. The tool reportssampling: falsewith no memory object at all rather than zeros — for the same reason
WorkspaceHealthReportseparatesuncheckedfrom "no findings". An agent that readheapUsedBytes: 0and concluded it had headroom would be worse off than one told themonitor has not reported. Likewise a missing supplier answers
available: false, neveran empty-but-successful report.
Platform seams
PerformanceMonitorandWorkspaceHealthCollectoraredesktopMain; this provider andthe registry are
commonMain. Both sources are injected at startup frommain.kt,exactly as
WorkspaceMcpToolProvider.windowCreatoralready is, so the provider carriesno platform assumption and the tests drive it entirely through fakes — no running
monitor, no window, no desktop.
Tests
IntrospectionMcpToolProviderTest, 10 cases, covering both tools' happy paths plus thecases that make the output trustworthy: an
uncheckedarea not reading as healthy, anull snapshot not reading as zero, a throwing source being reported rather than
propagated, an unwired supplier saying so, the per-tab detail not escaping, and both
tools declaring
readOnly.Relationship to the other host providers
WorkspaceContextMcpProvider— the workspace's contents(project path, open tabs, active editor file). Verified against its diff: no health
or performance code.
list_panelstoWorkspaceMcpToolProvider— layout.Also neither.
Those answer what the workspace contains; this answers what condition the host is
in. Complementary surfaces, and a separate provider keeps the concerns apart. The only
line shared with #997 is the
registerProvider(...)call inMcpToolRegistryImpl.init,which is a one-line merge in either order.