agent-trellis 0.5.2 → 0.6.0

package/docs/roadmap.md

@@ -951,6 +951,23 @@ tests passing.
 | P18 | ✅ `envAliases`: a migrated `${NAME}` env reference whose name differs from its own key (found via live dogfooding — a real Notion MCP server crashing pi after migrate, not a hypothetical) is now recognized as a reference, not silently shipped as literal unexpanded placeholder text. New `McpServerDef.envAliases` field, threaded through migrate-read (both JSON and Codex TOML sources), every adapter's write path, the pre-write unresolvable-env refusal guard, the pi bridge's runtime resolution, and canonical's own `env_aliases`/`envAliases` on-disk round-trip | P16 |
 | P19 | ✅ Migrate reclassify-repair: found immediately after P18 shipped — re-running migrate on data migrated *before* a classification fix didn't pick the fix up at all, since `planMcpServer`'s conflict check was plain `deepEqual` (any structural difference, real customization or not, was refused as "resolve by hand"). New narrow `isSafeReclassification` check + `"reclassify"` migrate action: applied automatically when a value only moved between `staticEnv`/`env`/`envAliases` while resolving to the exact same literal/reference text, everything else identical; any real difference still conflicts, unchanged. Verified for real on this machine: `migrate --from claude-code --only mcp` correctly reclassified notion's stale entry and left all 8 other already-migrated servers untouched | P18 |
 | P20 | ✅ Memory extraction: closes P15's own explicitly-named "per-agent extraction into canonical remains a separate, open gap." New `trellis memory extract` — the reverse of `memory sync` — reads the shared graph's real, non-`trellis-memory` entities (the same ownership marker `memory sync` already uses to leave agent-created content untouched, read the other direction) and writes each as a new canonical `memories/*.md` file: readable markdown, not a serialization format, not meant to round-trip byte-for-byte back through `memory sync`. Same create/no-op/conflict discipline as every other Trellis write; not wired into `onboard`'s automatic chain (a deliberate, occasional action, like `migrate`) | P15 |
+| P21 | ✅ MCP gateway hosting: collapses each agent's MCP config to ONE native stdio entry (`trellis mcp-gateway --agent <id>`) that Trellis itself spawns — no Docker, no daemon, no lifecycle command. Four third-party gateways were evaluated and excluded on hard constraints (MetaMCP is Docker-only; mcp-local-hub is Windows-only today; `@samanhappy/mcphub` is a 43-dependency authenticated web product with no importable SDK surface; `@pcandido/mcphub` has correct OAuth but zero `${VAR}` expansion in its stdio `env`, verified by inspecting what a spawned child actually received — adopting it would mean plaintext secrets or a second resolution path outside `secrets audit`). Built instead on `pi-bridge`'s already-proven connect logic, extracted to `src/lib/mcpConnect.ts`, behind a `GatewayBackend` seam so the confirmed next step — one shared service for all agents, with the per-session process becoming a thin MCP-over-Unix-socket client — is a substitution at one construction site, with every agent's written config identical either way. Includes Trellis's own OAuth client (RFC 8414/9728 discovery, RFC 7591 DCR, RFC 7636 PKCE S256, refresh), tested against a hand-built Authorization Server that *enforces* those RFCs rather than rubber-stamping them; tokens live 0600 one-file-per-server outside canonical, never the OS keychain (macOS `security add-generic-password` measurably fails exit 152/154 with no GUI session — the gateway's exact context). Two bugs the design caught before shipping: the MCP SDK's stdio transport reports no EOF, so without explicit teardown every agent session would leak a gateway plus its whole upstream process set; and concurrent OAuth refresh silently kills a rotated refresh token, so it is serialized by a per-server lock. Remaining: the shared service itself (v2) | P2 |
+| P22 | ✅ Onboard closed loop: onboard used to stop the moment files were written, never checking whether any of it took effect, and never telling the user how the run went — a real run with a genuine sync conflict still ended its printed output on a later stage's unrelated green line. Two distinct fixes, not one: a **self-verification re-plan** (the mechanism that actually closes the loop) runs `sync`/`mcp sync` a second time, dry-run, immediately after their real apply, and treats anything still outstanding as its own blocking finding — `trellis doctor` was tried first and rejected for this job, since its six detectors compare agents against each other and never read canonical, so they cannot prove a write took effect even in principle. Doctor still runs, last, as a secondary whole-machine health scan (never `--probe-mcp` — the worst moment to spawn every configured MCP server is a user's first run of this command), with findings on an unmanaged agent demoted to a warning rather than hidden. Every stage's conflicts and findings normalize into one `VerdictItem[]`, printed as a terminal verdict block that is always the last thing on screen and always agrees with the exit code, each blocking item carrying a concrete remediation instead of a restatement of the problem. Also adds stage progress to stderr (never stdout, so `onboard > report.txt` stays exactly the report) and, on a real terminal, a `--dry-run` that ends by offering to apply (declining is the default; accepting re-plans against current state rather than replaying a now-stale preview) | P0 |
+
+**Cross-machine / cloud sharing — confirmed future direction, not yet
+scoped as a phase.** Surveyed 2026-09-15 (`docs/research.md`'s "Cross-
+machine / cloud sharing" section): keeping `~/.trellis` consistent across
+a person's own multiple machines, and separately, providing a smoother/
+shared runtime substrate for agents to actually execute in, are both
+confirmed as real, wanted future capabilities — not yet broken into a
+numbered phase because the substrate choice needs its own validation pass
+first (git-based sync for the config side; `dagger/container-use` as a
+zero-new-code MCP server entry for safer per-task sandboxing; `awslabs/
+cli-agent-orchestrator` as a candidate for actual cross-machine
+coordination, evaluated only after the simpler pieces are proven). See
+`docs/research.md` for the full survey, including why `cloudflare/computer`
+and `daytonaio/daytona` were both evaluated and not adopted (preview-only
+API instability, and unmaintained-as-of-June-2026, respectively).
 
 No dates. This is scoped by verification milestones, not calendar time.
 Execution order for P11–P16: P11 → P12 → P13 → P14 → P15 → P16 — CRUD

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-trellis",
-  "version": "0.5.2",
+  "version": "0.6.0",
   "description": "A single source of capability for every coding agent — skills, MCP, subagents, memory, and secret policy, adapted natively into Claude Code, Codex, Kiro, and pi.",
   "license": "MIT",
   "author": "Paul Leo",
@@ -26,8 +26,9 @@
     "build": "tsc -p tsconfig.json && node scripts/build-pi-bridge.mjs",
     "dev": "tsx src/cli.ts",
     "typecheck": "tsc --noEmit",
-    "test": "tsx --test test/unit/**/*.test.ts",
-    "prepublishOnly": "npm run typecheck && npm test && npm run build"
+    "pretest": "node scripts/build-pi-bridge.mjs",
+    "test": "tsx --test \"test/unit/**/*.test.ts\"",
+    "prepublishOnly": "npm run typecheck && npm run build && npm test"
   },
   "engines": {
     "node": ">=20"

package/schema/servers.example.yaml

@@ -128,15 +128,32 @@ known_host_injected:
   - memory
   - mirasim
 
-# How the servers above reach the four agents. Omit this whole block for
+# How the servers above reach the four agents. Omit BOTH blocks below for
 # direct mode (today's default: every agent gets all N server definitions
 # written straight into its native config).
 #
-# Set it to route every agent through a single HTTP endpoint instead —
-# every adapter then writes exactly ONE entry (this URL), not N. What runs
-# behind the URL is not Trellis's concern: could be a self-hosted
-# github.com/ravitemer/mcp-hub instance, a hosted mcp-router account,
-# anything else speaking MCP over HTTP. No engine/product switch to
-# maintain — see docs/architecture.md "MCP hub mode".
+# `hub` routes an agent through a single HTTP endpoint you operate
+# somewhere else — the adapter then writes exactly ONE entry (this URL),
+# not N. What runs behind the URL is not Trellis's concern: could be a
+# self-hosted github.com/ravitemer/mcp-hub instance, a hosted mcp-router
+# account, anything else speaking MCP over HTTP. No engine/product switch
+# to maintain — see docs/architecture.md "MCP hub mode".
 hub:
   url: "http://127.0.0.1:37373/mcp"
+
+# `gateway` also collapses an agent to one entry, but what sits behind it
+# is a local subprocess Trellis itself spawns (`trellis mcp-gateway`), not
+# a URL you operate. It connects out to the servers above once, resolves
+# their secrets through secrets.policy.yaml exactly as direct mode does,
+# and exposes their tools as `<server>__<tool>`. There is nothing to start
+# or stop: the agent spawns it like any other stdio MCP server, and it
+# exits when the session ends.
+#
+# `gateway` and `hub` are independent and may both be present; gateway
+# wins for any agent it covers. Omit `agents:` — the normal case — and it
+# applies to every managed agent; list them to leave the rest in direct or
+# hub mode.
+#
+# gateway:
+#   enabled: true
+#   agents: [claude-code, codex]