306 Commits

Author	SHA1	Message	Date
Michal	90c49bcb22	refactor(prime-agent): drop the widget fallback, keep the tray status ... With prime-agent-extension-status.patch in place the tray renders ctx.ui.setStatus() next to the model name, which is what a status line should be. The widget was a workaround for its absence and was never a substitute: widgetContainerBelow sits in the fullscreen *scroll* list, not the dock, so it scrolled away with the transcript, and with both set the project name appeared twice. The startup retries stay: resetExtensionUI() clears extension statuses just as it cleared widgets, so the value set during session_start is still wiped before it can be seen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 19:59:24 +01:00
Michal	0a29c2fd7f	fix(prime-agent): re-publish the indicator after prime-agent clears extension widgets ... Verified with a probe extension rather than by reading the bundle: session_start fires with hasUI=true, ctx.ui.setWidget exists and the call returns without throwing — and the widget still never appeared. Cause is prime-agent wiping it immediately afterwards. resetExtensionUI() -> clearExtensionWidgets() runs from onBeforeSessionInvalidate and from the connection-state-snapshot handler, both of which land after session_start, so the indicator was set and cleared before it could be seen. Nothing re-set it until a turn, which is why a fresh session with no messages showed nothing. Re-publishes at 1s/3s/6s after session_start to land past that reset. setWidget is idempotent, so a redundant retry costs one re-render. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 19:52:07 +01:00
Michal	a90dd091f0	fix(smoke): actually clean up smoke-test resources ... 341 of 356 projects on the shared mcpd were smoke-test leftovers, plus 11 never-expiring `smoke-*` mcptokens sitting on the real `mcpctl-development` and `sre` projects. Enough to make the project picker unusable. Two causes, both silent: - `delete project X --force` — `--force` is valid on `create project` but NOT on `delete`, so every cleanup call exited non-zero and deleted nothing. project-llm-ref's afterAll looked correct and had never worked, which is why there were 84 each of smoke-proj-{ok,orphan,none}-*. - mcptoken.smoke had no afterAll at all; its cleanup was an `it()` at the end of the file, so it was skipped whenever an earlier assertion failed. Cleanup now lives in `afterAll` (runs on failure too) and is no longer gated on the health probe: the project is created through mcpd, which can be up when the gateway probe is not, and deleting a project that was never created is a no-op. Adds `pnpm smoke:clean` for the case afterAll cannot cover — a killed process (CI timeout, Ctrl-C, OOM). Dry-run by default, `--yes` to apply. Only touches `smoke-*` names and protects the shared `smoke-data` / `smoke-aws-docs` fixture, which five suites depend on and which must survive a concurrent run. Verified end to end: created a throwaway smoke project, confirmed the dry run lists without deleting, then `--yes` removed it and left all 15 real projects untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 18:49:42 +01:00
Michal	e638f81456	Merge main into feat/pi-extension	2026-08-08 18:38:55 +01:00
Michal	a1893a7578	fix(prime-agent): publish the project indicator on turn_start, not only session_start ... prime-agent emits session_start from exactly one place — reload() — and never at startup. A session_start-only handler therefore never ran on a fresh session, and the '/mcpctl -> already on X' path returns without reloading, so the indicator stayed blank exactly when it was most wanted. Also guard against the no-op UI context: the runtime hands extensions noOpUIContext until the TUI binds the real one, and every setter on it silently discards. Publishing under it would cache a label that never rendered. Now published on session_start (reload), turn_start (earliest reliable point on a fresh session), and on entering /mcpctl. Repeat calls are a no-op unless the label changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 18:38:52 +01:00
Michal	bc83d36a68	fix(pi): cap the project picker at 20 rows so it does not fill the screen ... pi's ExtensionSelectorComponent.updateList() renders every option with no windowing, so 50 rows scrolled the transcript away. prime-agent's selector windows to ~20 itself and shows a true (20/356) counter; matching that height makes both hosts behave the same. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 18:34:10 +01:00
Michal	e6db9cac83	Merge main into feat/pi-extension (prime-agent switcher UX)	2026-08-08 18:33:31 +01:00
Michal	ba05b2865c	feat(prime-agent): filterable project picker + a visible active-project indicator ... Two gaps the pi switcher had already closed. **The indicator was invisible.** `ctx.ui.setStatus` was the wrong channel: prime-agent stores extension statuses (`FooterDataProvider.setExtensionStatus`) but nothing ever reads them back — there is no `getExtensionStatuses()` call site anywhere in the app, so the value was recorded and never rendered. pi's `footer.js` does render them, which is why the same code showed a status line there and nothing here. The active project is now published as a *widget* (`extensionWidgetsBelow` → `renderWidgets()`), which prime-agent does render. `setStatus` is still called so pi keeps its footer entry. **No search.** With 356 projects the picker was a wall of `smoke-mcptoken-*`. Above 20 projects it now asks for a filter first; space-separated terms must all match, case-insensitively, against name or description, so `home auto` finds `homeautomation`. Active project sorts first, then alphabetical. Deliberately no client-side truncation here, unlike the pi picker: pi's `ExtensionSelectorComponent.updateList()` renders every option, so a long list fills the screen and has to be capped. prime-agent's selector windows the list itself and shows a true `(20/356)` counter — capping would replace an accurate total with a misleading one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 18:33:23 +01:00
Michal	8b006263de	fix(skills): write the frontmatter every Agent Skills host requires ... mcpd keeps `name` and `description` as columns, and a skill's `content` is often just the body — `propose-learnings` starts straight at its `#` heading. The sync wrote `full.content` verbatim, so the SKILL.md landed with no YAML frontmatter and the host rejected it. Observed live: [Skill warning] ~/.prime/agent/skills/propose-learnings/SKILL.md description is required Claude Code and pi require the same keys, so this affected every target; it only surfaced now because prime-agent prints the warning at startup. `ensureSkillFrontmatter` synthesises the block from the columns when it is absent, and fills in only a missing `name`/`description` when the author already supplied a header — an existing complete header is never rewritten. Values are emitted as JSON strings (valid YAML double-quoted scalars) because descriptions routinely contain `:` and `#`, which break a bare scalar. Also: `--force` now re-fetches skills whose server content is unchanged. Without it a skill already on disk could never be repaired by a client-side fix — the content hash still matched, so it was skipped forever, which is exactly what happened on the first attempt to repair the file above. Three existing assertions compared SKILL.md to the raw server content; they now assert the body survives rather than exact bytes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 18:16:22 +01:00
Michal	47809a8942	fix(pi): correct the model's tool context after a project switch ... Switching projects twice left the agent believing it had lost MCP access entirely: it kept calling the previous project's tool names, got "Tool mc_<old>_begin_session not found", and concluded no MCP tools existed. Root cause is a pi constraint, not a bug in the switch. pi has no way to unregister a tool — `registerTool` only ever does `extension.tools.set(name)` — so the previous project's `mc_*` tools stay registered and merely go inactive. `setActiveTools` correctly drops them from the live set, but the conversation still contains the old project's tool listing, so the model keeps calling names that now answer "not found". Nothing was telling the model the tool set had changed. Now the switch injects a custom message naming the active project, stating that previously listed mcpctl tool names are dead, and listing what is actually callable. Custom messages are converted to user-role messages by `convertToLlm`, so they do reach the model (unlike `appendEntry`, which is explicitly excluded from context). `display: false` keeps it out of the transcript — the notification is what the human reads. The gate is also called out explicitly, in both the notification and the injected message. A freshly switched project gets a new mcp-session-id and is therefore gated again, so "1 tool(s) ready" is correct but reads like a failure; it now says which begin_session call unlocks the rest. `toolChangeAnnouncement` is exported and unit-tested rather than left as wording only reachable through a TUI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 18:05:33 +01:00
Michal	24a3b8cc0a	feat(pi): filter the project picker instead of scrolling hundreds of rows ... pi's selector is a plain arrow-key list: `ExtensionUIDialogOptions` has no search field and `ExtensionSelectorComponent` ignores typed characters, so filtering has to happen before the list is handed over. With 356 projects — most of them `smoke-proj-none-*` leftovers — arrowing to the one you want is hopeless. Above 20 projects the picker now asks for a filter first. Terms are space-separated and all must match as case-insensitive substrings, so `home auto` finds `homeautomation`. Blank shows everything, Esc cancels. The active project sorts first (most likely pick), then alphabetical. A result set over 50 is capped, and the title says what was dropped — a silently truncated list reads as "that's all of them". The ordering and matching are extracted into an exported `filterProjects` so they are unit-tested rather than eyeballed through a TUI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 17:51:36 +01:00
Michal	739e679d1a	fix(pi): repair the /mcpctl menu, skills target, and typecheck the extension ... The pi extension shipped in `src/pi-ext/` was covered by no tsconfig and no eslint config, so nothing ever checked it against pi's API. Pointing tsc at the published @earendil-works/pi-coding-agent types found the command surface to be inert. Fixes: - `/mcpctl` did nothing. `ctx.ui.select` takes `string[]` and returns the chosen string; it was called with `{value,label}` objects, so the menu rendered five `[object Object]` rows and `choice === "status"` never matched any branch. Labels are now plain strings mapped back to actions. - The headless branch returned a status string from a handler typed `Promise<void>`; pi drops it. Reports via notify instead. - "Sync skills" omitted `--agent pi`, writing into ~/.claude/skills — in an integration whose stated purpose is to not depend on ~/.claude — and said so in its own success message. It also ran execSync with `stdio: "inherit"`, painting raw output over pi's TUI, and interpolated the project name into a shell string. Now execFile with `--agent pi` and captured output. - Tool results typed `content[].type` as `string`; pi's AgentToolResult wants the `"text"` literal. - `callTool` asserted `Promise<unknown>` to `ToolCallResult`. - Sanitising MCP tool names to `[a-z0-9_]` can collide (`docs.search` vs `docs-search`). The colliding tool was silently never registered but still reported active, so its calls were forwarded to the first tool. Names are now disambiguated and tracked with the MCP tool they forward to. - `registerWithPi` rewrote settings.json even when nothing changed. Since parsing strips `//` comments, a no-op run destroyed them. Guards, so this class of bug can't return: - `src/pi-ext/tsconfig.json` checks the extension against the real published pi types (dev dependency, not a shim — a shim drifting from the published API is the exact failure being guarded). Wired into `pnpm typecheck`. - eslint now covers `src/pi-ext/*.ts` like every other source file. - A test fails if the embedded copy in `config/pi-extension.ts` is stale; editing the sources without regenerating silently shipped old code. Also: the branch added `config pi` without regenerating shell completions (the committed-completions test was failing), and the doc advertised `mcpctl pi sync-skills`, which does not exist. Both corrected, plus a note on the session-token vs `mcpctl_pat_` bearer difference that would bite against an authenticated `mcplocal serve`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 17:30:42 +01:00
Michal	f1d84b0952	fix(config pi): embed extension sources so installed binary is self-contained ... - add scripts/generate-pi-extension.ts to embed src/pi-ext sources as string constants (mirrors prime-agent's embedded switcher pattern). - config pi now writes the embedded sources by default, so it works from an /usr/bin install with no source tree (--extension-dir overrides for dev). Verified installed binary writes files byte-identical to source. - add installEmbeddedExtension test.	2026-08-08 17:03:03 +01:00
Michal	f90e23d000	Merge remote-tracking branch 'origin/main' into feat/pi-extension ... # Conflicts: # README.md # src/cli/src/commands/config.ts # src/cli/src/commands/skills.ts	2026-08-08 16:35:51 +01:00
Michal	28f1a411fd	feat(pi): add native pi integration — extension, config pi, skills --agent pi ... - src/pi-ext/: self-contained pi extension (mcpctl-pi.ts + vendored mcp-http client) that talks JSON-RPC directly to mcplocal and registers project MCP tools as native pi tools. No MCP client, no ~/.claude. - Persistent per-project session so gated projects ungate on begin_session. - /mcpctl command: status, switch project (GUI), refresh tools, sync skills. - mcpctl config pi: installs extension, wires pi settings, persists active project, syncs skills into ~/.pi/agent/skills. - skills sync: add --agent pi (target install root). - docs + tests.	2026-08-08 16:23:02 +01:00
Michal	ce7df10e06	feat(cli): show the active mcpctl project in prime-agent's footer ... `/mcpctl` could switch projects but there was no way to see which one was active without running a command. prime-agent exposes the same status-bar channel the model name uses (`ctx.ui.setStatus`), so the switcher now publishes `mcpctl:<project>` there. Wired to `session_start`, which fires on startup *and* on every reload — including the reload the switch itself triggers — so the footer tracks settings.json without extra bookkeeping. Cleared when no project is mounted. Also fixes `notify(..., 'success')`: the API only accepts info|warning|error. Not a live bug (prime-agent falls through to the same showStatus path as 'info') but it fails a typecheck of the extension against the real ExtensionAPI, which is how it was found. The extension ships as a JSON-escaped string and is never compiled by our build, so it was typechecked out-of-tree against @earendil-works/pi-coding-agent's published types. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 12:18:21 +01:00
Michal	170dc06496	fix(cli): close third review — token collision, migration, ownership ... Round 2 fixed the first review but introduced regressions of its own, all of which only bite against state written by the previously installed build. `config prime-agent`: - Mint each credential under a unique `prime-agent-<stamp>` name again. `McpToken` is unique on (name, projectId) and revoke is a soft delete, so round 2's fixed `prime-agent` name could only ever be minted once per project — and the revoke-first ordering destroyed the working credential before discovering the mint would fail. - Provision the credential BEFORE touching settings.json. Registering the new project unmounts the previously active one, so a failed mint must not be able to leave prime-agent with no working project at all. The command now aborts with settings.json untouched. - Retire only the token this auth.json actually held, once its replacement is stored. Sweeping every `prime-agent*` token for the project would revoke the credential another install (or a custom --output run) is using; anything else that looks orphaned is reported, not deleted. - Validate a pre-existing credential instead of trusting its presence: a revoked or expired token used to short-circuit provisioning and leave prime-agent broken while the command reported success. Matched by tokenPrefix against the project's active tokens, so the secret is never sent. Fails open when the API can't be consulted. - Actually write auth.json 0600. `writeFile`'s mode is ignored for an existing file and prime-agent creates auth.json itself at 0644, so chmod after writing. - Recognise the untagged mcpServers entries older CLIs wrote (canonical proxy URL + an `mcp:<name>` mcpctl PAT in auth.json) so a switch unmounts them instead of leaving two gateways live. Hand-configured servers have no such credential and are still preserved. Same rule in the `/mcpctl` switcher's active-project lookup. - Add `--skip-marker`, and pass it from the `/mcpctl` switcher: the extension runs from whatever directory prime-agent was started in, and was silently re-scoping that repo's `.mcpctl-project`. `skills sync --agent prime-agent`: - Record ownership from the skill's own scope, not the syncing project's. Globals were being pinned to whichever project happened to sync them, after which every other project refused to update them forever. - Never adopt legacy, ownership-less state into the current scope. Round 2 did, which deleted the other project's skills on the first sync after upgrading. Such entries are attributed to the project that last wrote the state file, and left alone when that isn't the project syncing now. - Close the overwrite-guard bypass: a sync with no project, or a global landing on a project-owned name, could still clobber and re-own a tracked skill. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB	2026-08-08 12:01:52 +01:00
Michal	fa7055ac5e	fix(cli): close second review on prime-agent sync + switcher (auth, ownership, switching) ... Addresses the second round of `config prime-agent` review (10 findings). auth.json (config/prime-agent.ts) — the settings.json data-loss fix had a twin: - loadPrimeAgentAuth now fails loudly on corrupt JSON instead of swallow-and- rewrite, so one syntax error can no longer destroy the provider API key and every other project's credential. hasPrimeAgentAuth shares that guarantee. - writePrimeAgentAuth writes 0600 (preserving an existing file's mode) instead of the default umask — bearer tokens are no longer world-readable on first creation. state ownership (commands/skills.ts) — the ownership model edge cases: - orphan-removal guard now normalises a canonical scope (project name, or null for globals; legacy undefined adopted to current scope) instead of comparing null against undefined, so global-only syncs and pre-PR state can no longer leave stale skills on disk forever. - a same-named skill *tracked* to a different project is preserved (with a warning) rather than silently overwritten in the shared flat tree. - mcpServers auto-attach is gated behind !isPrimeAgent with an explicit warning (prime-agent's HTTP gateway must not mutate shared mcpd project attachments); this also makes the earlier dropped-attach concern explicit rather than silent. single-active project + switcher (config/prime-agent.ts, prime-agent-extension.ts): - registerPrimeAgentMcp tags the project's entry mcpctlManaged:true and removes other mcpctl-managed entries, so prime-agent has one *active* mcpctl project while preserving untagged servers (hand-configured sre, websearch, etc). - the /mcpctl extension now reads that tag as the single source of truth for the active project, fixing the false short-circuit / no-op switch. config.ts command: - an explicit -p now updates a differing up-tree .mcpctl-project marker (scope no longer silently reverts on the next sync), no-ops when it matches, and still never scopes $HOME. - a project left with no usable credential now exits non-zero (the /mcpctl extension checks child exit status, so it no longer reports a successful switch after provisioning failed). - skills sync is treated as best-effort: settings+auth determine switch success, so a skills error no longer falsely fails the switch. - token minting now revokes prior active `prime-agent` tokens before creating a fresh one (no more never-expiring token litter / lost-credential duplication). Tests (544 green): corrupt auth.json refusal, 0600 mode, mint-failure exit code, single-active dedup preserving untagged sre, cross-project overwrite preservation, and global-orphan removal on global-only sync.	2026-08-08 11:28:15 +01:00
Michal	eb1642ab1a	fix(cli): harden config prime-agent sync + install /mcpctl switcher extension ... Addresses a review of the `config prime-agent` feature and adds the in-app project switcher. Safety/correctness fixes (prime-agent's shared, hand-editable ~/.prime/agent tree must never suffer silent data loss): - config/prime-agent.ts: loadPrimeAgentSettings now fails loudly on corrupt JSON instead of swallowing it and rewriting the file (which destroyed every non-mcpServers setting). A project's mcpServers entry is merged (keeping user-added fields) rather than replaced wholesale. Added writePrimeAgentAuth / hasPrimeAgentAuth helpers for auth provisioning. - skills sync: unified the near-verbatim prime-agent copy into runSkillsSync via a `target: 'claude' | 'prime-agent'` option (prime-agent-skills.ts is now a thin wrapper). Under the prime-agent target it: preserves untracked pre-existing skill dirs on first sync (no more rm -rf of hand-authored `sre`), records per-project ownership so configuring a second project never deletes the first project's skills, skips Claude-only hooks/postInstall, and keeps the mcpServers auto-attach step. - config.ts: `config prime-agent` now (a) provisions the bearer credential in auth.json (--token, existing entry, or auto-mint via POST /api/v1/mcptokens), (b) writes the .mcpctl-project marker only when none exists up-tree and never from $HOME, and (c) propagates the skills sync exit code so auth failures are reported instead of swallowing them. - skills.ts: `--agent` is validated; an unknown value errors instead of silently running the Claude sync. New feature: `config prime-agent` installs a `/mcpctl` project-switcher extension into ~/.prime/agent/extensions/ (skip with --skip-extension). It lists mcpctl projects via `mcpctl get projects -o json`, lets you pick one from the prime-agent TUI, applies the switch through the CLI, and reloads the session. Regenerated shell completions. Tests: 538 pass (new coverage for settings corruption, entry merge, auth provisioning, extension install/skip, marker $HOME handling, untracked/cross-project skill preservation, --agent validation).	2026-08-08 10:22:46 +01:00
Michal	582f6f185b	feat(cli): add mcpctl config prime-agent — proxy MCP + skills sync for prime-agent ... Mirror `mcpctl config claude` for prime-agent (which talks to the same mcpctl proxy MCP gateway over HTTP instead of stdio): `mcpctl config prime-agent --project X`: - registers the proxy MCP gateway in ~/.prime/agent/settings.json as mcpServers.X = { type: "http", url: <gateway>/projects/X/mcp }, merging with any existing servers (e.g. the bundled `sre` project) and preserving all other settings - writes a .mcpctl-project marker so later syncs resolve the project - syncs the project's skills into ~/.prime/agent/skills/<name>/ as markdown skills (prime-agent auto-discovers them at session start) New `mcpctl skills sync --agent prime-agent` target re-syncs the tree later. - src/cli/src/config/prime-agent.ts: settings.json read/merge/write helpers - src/cli/src/utils/prime-agent-skills.ts: prime-agent sync (reuses installSkillAtomic + skills-state; skips Claude-only hooks/postInstall) - completes config.ts/skills.ts wiring; regenerated shell completions - tests: commands/prime-agent.test.ts + utils/prime-agent-skills.test.ts	2026-08-08 09:34:15 +01:00
Michal	e85250fedf	fix(cli): stop the MCP stdio bridge serialising requests ... The bridge's stdin loop awaited every request before reading the next line, so it handled exactly one at a time. A single slow call therefore stalled every later request — and because those requests were never even sent, nothing could time them out. The client saw silence, not an error. Observed 2026-08-05: two gitea calls through this bridge sat completely mute until Claude Code aborted them at its own 1800s idle limit, reporting "sent no response or progress". The upstream was healthy the whole time — a fresh session answered the same tools in 0.3s, and the gitea MCP server's own log showed the calls never reached it. They died queued in the bridge. JSON-RPC ids exist precisely so responses may return out of order, so nothing here needed a queue. Requests now dispatch concurrently and are tracked in a set; stdin close awaits them before the session DELETE, otherwise a concurrent call races the teardown and dies with a 404. We still serialise until the session id exists: it arrives on the first response, and firing later requests without it would open a second upstream session. A client sends `initialize` first and waits for the reply anyway, so this costs one round trip rather than throughput. Also makes the per-request timeout configurable via MCPCTL_MCP_TIMEOUT_MS (default unchanged at 30s) and names it in the timeout error, so a project with genuinely long tool calls can raise it instead of hitting a hardcoded wall. Tests pin both halves: a fast request must overtake a slow one (this fails on the old serial code — verified by reverting), and a failed request must still produce a JSON-RPC error carrying the original id rather than nothing.	2026-08-07 15:19:50 +01:00
Michal	34e00af731	feat(gate): drop the reasoning field from selection → ~1.5s (comfortable margin) ... Even "<=8 words" was ignored — the model wrote a full-sentence reasoning, pushing begin_session to ~7s (thin under the 8s budget). The gate only needs the names, so request just {"selectedNames":[...]}. Validated live vs vllm-current (glm-4.6-reap-fast): 1.5s, valid JSON. (reasoning defaults to '' in extractSelection.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-25 03:07:28 +01:00
Michal	a432e9e19f	feat(gate): terse selection prompt so a no-think model answers in ~2s ... With the fast (no-think) route, gate-selection latency is now proportional to the ANSWER length (a no-think model runs ~10-13 tok/s), not hidden thinking. A verbose "reasoning" field pushed a selection to ~9s (over the 8s budget). Request compact JSON with a <=8-word reasoning → ~2s (vs ~9s prose, or ~1.2s with no reasoning). Validated live against vllm-fast (glm-4.6-reap-fast): 2.0s, valid selection JSON, zero reasoning tokens. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 21:38:08 +01:00
Michal	5225b54901	feat(gate): MCPCTL_GATE_SELECTION_LLM — pin a dedicated fast selection Llm ... Lets ops route gate prompt-selection at a fast (no-think) server Llm independent of the project's chat llmProvider — so selection stays ~1-2s while chat keeps its thinking model. Overrides the project llmProvider for the gate's server-selection path; unset → prior behavior (use the project's llmProvider). Pairs with the litellm qwen3-fast no-think alias (kubernetes-deployment) + a `vllm-fast` mcpd Llm. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 14:28:44 +01:00
Michal	27480181bf	feat(gate): ask reasoning models for a fast, no-think selection response ... Prompt selection is mechanical classification — it gains nothing from chain-of- thought, and a reasoning model (qwen3-thinking) otherwise burns its whole budget reasoning (~40s, 6k+ chars) and blows the gate's 8s timeout. The gate's server selection request now includes thinking-suppression hints, forwarded verbatim by mcpd's passthrough adapter to litellm/vLLM: chat_template_kwargs.enable_thinking=false (Qwen3 hard-off) reasoning_effort=low (o-series / newer vLLM) Harmless for models that ignore them; if a backend rejects them the selector falls back to the local provider. Override via MCPCTL_GATE_SELECT_EXTRA_BODY (JSON), or '' to disable. NOT yet validated live — the qwen3-thinking vLLM is crashlooping again (0/1, HTTP 500), and whether litellm forwards chat_template_kwargs to vLLM is unconfirmed (the /no_think prompt directive was NOT honored). Validate when the backend recovers. mcpld gate/selector tests green (75). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 13:07:27 +01:00
Michal	2729580974	feat(gate): route prompt-selection through mcpd's server Llm (credential tiering) ... Cloud/server keys belong at the k8s/mcpd level; mcplocal handles only the user's personal tokens. The gate's prompt-selection used mcplocal's LOCAL provider registry (heavy=anthropic = the user's OAuth token, which is API-gated and 404s), so selection always degraded. Now LlmPromptSelector tries sources in priority order: (1) the project's server Llm via mcpd's inference proxy (POST /api/v1/llms/:name/infer) — cloud/server keys stay at k8s — then (2) the local personal-token provider as fallback. First source that returns valid selection JSON wins. Extracted pickCompletionText (content ?? reasoning_content) + extractSelection helpers. Wiring: GatePluginConfig.llmProvider (from the project), threaded via createDefaultPlugin; handleBeginSession builds serverInfer from ctx.postToMcpd. Verified live: POST .../llms/vllm-current/infer returns valid selection JSON (qwen3-thinking, 4000-token budget). + selector tests (server preferred, local fallback on error, server-only). mcplocal suite green (755). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 12:43:48 +01:00
Michal	366b505c00	fix(providers): anthropic surfaces HTTP errors too (gate parity with openai) ... The local mcplocal gate resolves heavy=[anthropic]; its OAuth-gated key 404s the configured opus-4 model, and anthropic.ts (like openai.ts before this series) JSON.parsed the error body as a completion → empty content → the gate's misleading "did not contain valid selection JSON". Reject on status >= 400 with "Anthropic HTTP <status>: <body>" so the true reason (model-not-found / auth) surfaces as the degradedReason. + parity test. Note: this makes the error honest; it does not make the local gate SUCCEED — that needs a working heavy provider (the anthropic OAuth token is fundamentally gated). The qwen3-thinking gate path (k8s mcplocal) is addressed by the budget+reasoning fix in the previous commit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 22:23:37 +01:00
Michal	c9364a2f2a	fix(favourite-index): route favourite/ calls even before tools/list (lazy resolver) ... The presented→canonical resolver was only built during tools/list, so a favourite/<tool> call arriving before any list this session fell through to the namespaced router and 404'd (all/ was fine — it prefix-strips). Real MCP clients list first, but the smoke test's initialize→call flow exposed it. Extract buildPresentation() and lazily rebuild the resolver in onToolCallBefore when a favourite//all/ name isn't resolved yet. + unit test (favourite/ call with no prior list) and realistic listTools() in the smoke routing case. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 22:19:05 +01:00
Michal	9dbd2f175d	fix(gate): stop masking backend errors + rescue thinking-model prompt selection ... Two independent, live-reproduced causes of "Smart prompt-selection unavailable (LLM response did not contain valid selection JSON)" in the gate: - Cause B (openai.ts request): the response handler JSON.parsed the body with no res.statusCode check, so a LiteLLM/vLLM HTTP 500 ("Connection error") parsed as an empty completion and surfaced as generic "bad JSON", masking backend-down. Now reject on status >= 400 with "OpenAI HTTP <status>: <body>" so the selector reports the true degradedReason. - Cause A (parseResponse + selector budget): a reasoning model (qwen3-thinking) spends its whole 1024-token budget in reasoning_content and emits content=null, so the {selectedNames} JSON never appears. parseResponse now falls back to reasoning_content (incl. provider_specific_fields) when content is empty, and the selector budget is raised 1024 -> 4000 (env MCPCTL_GATE_SELECT_MAX_TOKENS) so thinking + the JSON answer both fit. Note: mcpd's chat path got a reasoning_content fallback in PR #67; this is the separate mcplocal gate-selection provider, which never did. Tests: openai-provider (500 rejects, reasoning_content capture/preference). mcplocal suite green (749). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 22:10:08 +01:00
Michal	f614e9bb98	feat(proxy): favourite-index tool presentation (favourite/ + all/ + prefer instruction) ... Measured winner from the DGX-Spark bake-off (toolsim.py, 145-tool catalog): a curated favourite/<tool> shortlist + the full all/<server>/<tool> catalog + a load-bearing "prefer favourite/ first" instruction nearly halved wander (37→20) and 2.5x'd first-pick (2→5/8) vs a flat catalog. The instruction is load-bearing; enriching descriptions did not help. - New mcplocal plugin `favourite-index.ts`: composes AFTER gate (no-ops while gated), reshapes the ungated upstream catalog into favourite/ + all/, injects the instruction (onInitialize), and rewrites presented names back to canonical server/tool in onToolCallBefore so normal routing + content-pipeline still run. Gate/agent virtual tools pass through untouched; favourites are upstream-only. - compose.ts: onInitialize now concatenates plugin instructions (was first-non-null) so favindex can contribute its banner alongside the gate's. - Per-project config `Project.favouriteIndex` {enabled, tools[], maxFavourites}; surfaced to the proxy via discovery; wired at project-mcp-endpoint when enabled. - Usage derivation: mcpd tool-usage ranking over tool_call_trace events (normalizing presented names → canonical), GET /api/v1/audit/tool-usage, and `mcpctl favourites suggest|list`. - CLI: `create project` gains --favourite/--favourite-index/--max-favourites; favouriteIndex round-trips through get -o yaml | apply -f. Completions regenerated. - Tests: plugin unit (presentation, rewrite routing, gated no-op, collisions), compose merge, canonicalizeToolName, buildFavouriteIndex, + a live smoke test. - Docs: docs/tool-presentation.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 01:20:30 +01:00
Michal	a1c545d21a	fix(mcpd): anthropic adapter supports OAuth (sk-ant-oat) keys via Bearer ... Claude subscription / Claude Code keys are OAuth tokens and authenticate with Authorization: Bearer, not x-api-key. mcpd's server adapter only sent x-api-key, so registering an OAuth key as a fallback Llm 401'd ("invalid x-api-key"). Mirror the mcplocal client adapter's isOAuth switch so an OAuth key works as a server-side anthropic fallback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 23:43:56 +01:00
Michal	18524c1c57	feat(chat): LLM failover chain + show which model answered ... Chat is LLM-essential but not model-specific — instead of failing when the pinned model is down/drifted, it now fails over across an ordered chain and reports which model actually answered. - Ordered fallback: an Llm declares `extraConfig.fallbacks: string[]`; the dispatcher builds primary-pool → fallback-pool(s) candidates and tries them in order (resolveCandidatesWithFallbacks). - Fail over on real failures, not just transport: runOneInference now advances on a non-2xx status (e.g. a 400 from a drifted model) or an empty/invalid completion, not only thrown transport errors. Streaming fails over pre-first-chunk (already threw on 4xx). - Transparency: ChatResult + the SSE `final` frame carry {llm, model, failedOver}; the CLI prints `model: <llm> (<model>)` each turn and `⚠ failed over → answered by …` when a fallback was used. - Exhaustion names the last model + upstream body (not "no choice"). Tests: 3 failover unit tests (primary 400 → fallback answers + model reported; primary answers → failedOver=false; all fail → clear aggregated error). mcpd 948 + CLI 508 green; tsc + lint clean. docs/reliability.md updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 23:39:56 +01:00
Michal	485b8f613f	feat(reliability): bound + fail over + surface LLM-optional ops ... mcpctl hung on prompt-reading whenever the LLM misbehaved (thinking model = minutes; drifted model = silent failure). Root cause: the gate's begin_session prompt-selection called the LLM with no timeout, its fallback only fired on error and was silent, and it forced the project's vLLM model onto the anthropic heavy provider (so selection failed silently every time). - New withTimeout(run, ms, label): Promise.race + AbortSignal (fetch-based providers cancel). CompletionOptions.signal threaded into anthropic/openai. - Gate begin_session: LLM selection is time-bounded (MCPCTL_GATE_LLM_TIMEOUT_MS, 8s); on timeout/error it falls back to deterministic tag matching, logs [gate] loudly, prepends a ⚠ degraded note to the response, and sets degraded/degradedReason on the audit gate_decision. - Gate selector no longer forces the project vLLM model — uses the heavy provider's own model (fixes the always-silent-fail bug). - Pagination smart-index is time-bounded too (falls back to byte-range pages). - Chat (LLM-essential) surfaces the upstream status+body (names model+reason) instead of "Adapter returned no choice". - docs/reliability.md documents the principle. Tests: with-timeout unit tests; gate degradation test (error → visible ⚠ + deterministic prompts, no hang). mcplocal 737 + mcpd 945 green; tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 16:28:34 +01:00
Michal	a5cab5a096	feat(chat): project-scoped chat — mcpctl chat --project <name> ... Chat directly with a Project (no Agent needed): its Prompts become the system context, its MCP-server tools are callable, its llmProvider/llmModel drive the LLM, and (opt-in) the model can read secret values. History is saved inside the project, attributed per user, resumable, and deletable (RBAC-permitting) — "use it like Claude, scoped to the project". Backend (reuses the agent-chat orchestrator): - ChatThread is now agent-XOR-project (schema + migration + CHECK constraint); new listThreadsByProject / deleteThread on the repo. - ChatService: prepareProjectContext (project prompt + Prompts by priority, llm from llmProvider with llmModel override, project tools), shared runChatLoop/runChatStreamLoop, project thread CRUD with owner enforcement (404-not-403 on foreign threads), admin-override delete. - Gated get_secret virtual tool: offered only with --allow-secrets AND the caller's view:secrets; resolves via SecretService, never routes to a server. - routes/project-chat.ts (chat SSE+non-stream, threads create/list/delete); RBAC run:projects:<name>. CLI: - `mcpctl chat --project <name>` (+ --allow-secrets), one-shot/REPL/resume. - REPL /threads, /resume <id>, /delete <id>; project-aware header + /tools. - `mcpctl get threads --project <name>`, `mcpctl delete thread <id> --project`. - completions regenerated (--project completes project names). Tests: 8 new project-chat unit tests; full mcpd (945) + CLI (508) green; schema validated against Postgres. Docs: docs/chat.md "Project chat" section. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 10:34:21 +01:00
Michal	a517443828	fix(pulumi): drop exports map so Pulumi can serialize the provider (v0.0.2) ... Pulumi's closure serializer reaches the dynamic provider's internal submodules (dist/engine.js, dist/kinds.js) by subpath. An `exports` allowlist with only "." blocks that: `pulumi preview` failed with "package.json export path for .../dist/kinds.js not found". Removing `exports` (keeping main/types) lets the serializer resolve them. Verified end-to-end: a real `pulumi up` from kubernetes-deployment updated mcpd's qwen3-thinking llm and it probes 200. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 22:32:41 +01:00
Michal	f3d92235db	feat(pulumi): @mcpctl/pulumi — generic Pulumi provider for mcpctl ... New workspace package: a Pulumi dynamic provider (TypeScript, in-process) that manages mcpctl resources declaratively from any Pulumi program. Motivated by model drift: when the deployed vLLM/LiteLLM model changes, mcpctl's llm target must follow, and a Pulumi resource makes that automatic on `pulumi up`. - Generic core `McpctlResource({ kind, name, spec, mcpd })` round-trips ANY mcpctl resource kind; typed `Llm` wrapper for ergonomics. - Engine talks direct HTTP to mcpd's REST API (ported from cli/api-client.ts), mirroring apply's name-keyed upsert (PUT strips immutable name/type) and get -o json's read field-stripping. No mcpctl binary needed → CI-friendly. - CRUD/diff/check with correct replace semantics (name/type/kind/mcpd.url force delete-before-replace), 429 retry, secret token in state. - Validation deferred to mcpd's Zod schemas, so new resource kinds work with no provider release. - CommonJS build so the serialized dynamic provider's module refs are captured. - 18 Vitest tests (mocked mcpd + Pulumi mocks); build + lint clean; README with auth (PAT) setup and consumer example for kubernetes-deployment. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 22:02:22 +01:00
Michal	6ef16f12b6	fix(cli): login over HTTPS + suggest last-used email ... auth.ts talked to mcpd over node:http unconditionally with port:url.port, so an https:// mcpdUrl connected to the ingress on :80, got a 301 redirect with an empty body (status < 400), and JSON.parse('') crashed login with "Unexpected end of JSON input". api-client.ts already handled this; the auth commands did not. - All 4 auth request fns now pick https/443 and the TLS driver from the URL protocol, mirroring api-client.ts. - parseJsonResponse() guard turns any non-JSON <400 body into a clear "Invalid <ctx> response from mcpd" error instead of a raw SyntaxError. - login now suggests the previously-used email (when a session for the same mcpd exists) so pressing Enter reuses it after a session expires. - Regression tests drive the real default* request fns against a local HTTP server (valid JSON, empty body, HTML redirect body, https driver selection) and cover the email-suggestion behaviour. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 21:06:29 +01:00
Michal	25da5a3a22	feat(errors): mcpd error-log ring buffer + 'mcpctl errors' ... Operators can now see recent mcpd error/fatal logs without kubectl: - mcpd tees level>=error pino records into an in-memory ring buffer (src/mcpd/src/services/error-log-buffer.ts; wired via pino.multistream in server.ts so stdout logging is unchanged). Captures structured errors incl. fatal kinds like BACKEND_TOKEN_DEAD. - GET /api/v1/logs/errors?limit=N (RBAC: 'logs' operation). - CLI: 'mcpctl errors [-n N]' renders TIME/LEVEL/DETAIL, most-recent-first. Buffer unit tests (6); full suite 2223 passing. Needs a deploy to go live. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-16 23:25:55 +01:00
Michal	467757b966	feat(status): show SecretBackend health in mcpctl status ... Adds a 'Secrets:' line to mcpctl status (and a secretBackends array to JSON output) showing each backend healthy (✓) or, when tokenMeta.lastRotationError is set (e.g. a dead OpenBao token), red ✗ with the error inline. Makes a recurrence of BACKEND_TOKEN_DEAD visible at a glance instead of only in mcpd logs. Verified live: 'Secrets: bao* ✓, default ✓'. +3 tests (28 total). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-16 23:13:50 +01:00
Michal	4c7e648771	fix(smoke): read CLI credentials from ~/.mcpctl (active path) ... passwd smoke read ~/.config/mcpctl/credentials and silently skipped; the CLI stores creds at ~/.mcpctl/credentials. Now verified live against prod (4/4). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-16 22:41:30 +01:00
Michal	2cceeb7093	feat(passwd): mcpctl passwd + RBAC-gated password change ... Restores the lost `mcpctl passwd` command and builds the backend it needs. Backend (mcpd): - POST /api/v1/users/me/password — self-service change, requires current password. Gated by a new `set-own-password` operation. - PUT /api/v1/users/:id/password — admin reset of another user, gated by edit:users (admins have edit:*). Added users name-resolver for CUID→email. - UserService.setPassword/verifyPassword; UserRepository.update accepts passwordHash + findByIdWithHash. RBAC, no exceptions: self password change is a default, admin-revocable permission. Every new user gets a `self-<id>` RbacDefinition granting `set-own-password`, seeded on create + bootstrap, gated by the `allowSelfPasswordChange` system setting (stored in the mcpctl-system-settings secret, default ON; admins disable globally or revoke per-user). CLI: src/cli/src/commands/passwd.ts (self vs admin paths) + completions. Tests: users-password route tests (8), auth-bootstrap grant assertion, passwd live smoke test. Full suite 2214 passing; zero new lint errors. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-16 21:55:56 +01:00
Michal	0e952dbf68	merge: integrate v7-rbac-visibility on top of skills feature ... Brings together the two unmerged feature lines onto one integration branch: - skills/review/proposals/revisions (via fix/mcpd-instance-health-and-retry, which contains the full skills-1..7 chain + mcpd env/retry/readiness fix) - v7 visibility scope + ownership for Llms and Agents Auto-merge resolved schema.prisma, mcpd main.ts, mcplocal config, CLI create, and completions with no conflicts. Both Prisma migrations coexist. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-16 21:31:35 +01:00
Michal	180e50a978	feat(cli): metadata.mcpServers auto-attach in mcpctl skills sync ... Closes the third deferred item from PR-5: skills can declare upstream MCP server dependencies via `metadata.mcpServers` and `mcpctl skills sync` now attaches them to the active project. Same trust model as postInstall/hooks: the publisher is responsible, the client just asks mcpd to attach. ## Behaviour - For each `{ name, fromTemplate?, project? }` entry: - If the project already has the server attached → record as `alreadyAttached`, no-op. - If the server doesn't exist on mcpd → warn + skip (we don't auto-create from template; that's a separate explicit decision for the operator). The warning surfaces the suggested template so the operator can decide. - Otherwise → POST `/api/v1/projects/:id/servers { server: <name> }`. - 409 from POST → treat as alreadyAttached (server-side idempotency). - 404 from POST → treat as missing (race: server vanished mid-sync). - Other errors collected per-server; sync continues. - A dep with `project:` set to a non-active project is skipped during this sync — keeps the active sync from making collateral changes to other projects. - Global skill syncs (no project context) skip mcpServers entirely with a warning — there's no project to attach to. ## Files ### Added - src/cli/src/utils/mcpservers-materialiser.ts (~140 LOC) - src/cli/tests/utils/mcpservers-materialiser.test.ts (~190 LOC, 10 tests covering: parse-tolerance, fresh attach, alreadyAttached short-circuit, missing-server warn+skip, missing-project errors- out, 409→alreadyAttached, 404→missing, cross-project skip, per-server error collection, empty-deps no-op) ### Edited - src/cli/src/commands/skills.ts: applyOne calls attachSkillMcpServers after hooks. Tracks per-skill attachments in result.mcpServersAttached. Summary line surfaces "N mcpServers attached". ## Verification 165 test files / 2193 tests green (up from 2182). Real-world flow: ```yaml # skill metadata.yaml mcpServers: - name: my-grafana fromTemplate: grafana project: monitoring - name: my-loki fromTemplate: loki ``` ```bash # As operator: ensure the named servers exist on mcpd first mcpctl create server my-grafana --from-template grafana --env-from-secret grafana-creds mcpctl create server my-loki --from-template loki # Now publish the skill that declares them as deps. Sync will attach: mcpctl skills sync # → mcpctl: 1 installed, 2 mcpServers attached mcpctl describe project monitoring # both servers now attached ``` ## What's intentionally NOT in this PR - Auto-creating servers from `fromTemplate` when they don't exist. Provisioning infra from a skill push is a separate decision needing explicit operator policy. v1 warns + skips; the warning includes the suggested template name so the operator can act manually. - Detaching a server when a skill drops it from mcpServers. Detach is destructive (project loses access) and we can't tell whether the detach is intentional vs. accidental drop. PR-7 can revisit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 19:12:20 +01:00
Michal	7ebc8b22d1	feat(cli): metadata.hooks materialisation in mcpctl skills sync ... Closes the second-biggest deferred item from PR-5: skills can declare PreToolUse / PostToolUse / SessionStart / Stop / SubagentStop / Notification hooks in metadata.hooks, and `mcpctl skills sync` now registers them in ~/.claude/settings.json with proper source-tagging. ## Why this needs source-tagging mcpctl already managed ONE entry in settings.json (the SessionStart hook for `mcpctl skills sync --quiet`, set up by PR-5 via `installManagedSessionHook`). That entry uses `_mcpctl_managed: true` to identify itself for idempotent updates. Skill-declared hooks need finer scoping: skill A and skill B could both register PreToolUse hooks, and removing skill A must not touch skill B's. So entries written by `applyManagedHooks` carry both: _mcpctl_managed: true ← same flag the SessionStart hook uses _mcpctl_source: "<skill-name>" ← differentiates per-skill Removing a skill (orphan cleanup) drops every entry tagged with that skill's name. User-added entries (no marker) are preserved verbatim. The earlier session-hook installer keeps working: its `_mcpctl_managed: true` lacks the source tag, so the hooks-materialiser ignores it on per-skill operations. ## Behaviour - Skill installs/updates: applyManagedHooks(skillName, metadata.hooks) is called after files are atomically materialised. The function reads settings.json, drops this skill's previous entries from every declared event (and from any event it previously had entries in but no longer declares — so a skill can shrink scope), then re-inserts the new tagged set. - Skill orphan removal: removeManagedHooks(skillName) drops every entry owned by the skill. Other skills + user hooks unaffected. - Failure handling: hooks errors are logged via the warn() callback but do not fail the sync. Same shape as postInstall — scoped, not fatal. ## Files ### Added - src/cli/src/utils/hooks-materialiser.ts (~140 LOC) - src/cli/tests/utils/hooks-materialiser.test.ts (~165 LOC, 11 tests covering: write-from-scratch, multi-source coexistence, user-hook preservation, update replaces (not duplicates), shrink drops events, remove targets only the named source, multiple events independent, idempotent, empty/JSONC settings.json tolerance) ### Edited - src/cli/src/commands/skills.ts: applyOne calls applyManagedHooks when metadata.hooks is set; calls removeManagedHooks(skillName) when a previously-installed skill no longer declares hooks; orphan removal also drops the skill's hooks. New SyncResult field `hooksApplied`. Earlier `meta` declaration deduped (it was redeclared in the postInstall block). ## Verification 164 test files / 2182 tests green (up from 2171). End-to-end on a real machine after this PR ships: ```yaml # skill metadata.yaml hooks: PreToolUse: - type: command command: "audit-pretool.sh" SessionStart: - type: command command: "claude-greeting.sh" ``` ``` mcpctl skills sync # → mcpctl: 1 installed, 1 hooks applied jq '.hooks' ~/.claude/settings.json # → entries tagged with _mcpctl_managed + _mcpctl_source ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 19:08:43 +01:00
Michal	d60ad52018	feat(cli): postInstall executor for mcpctl skills sync ... Closes the biggest deferred item from PR-5. metadata.postInstall scripts now actually run when their hash changes, with audit emission back to mcpd. Trust model unchanged from the corporate-appliance design: mcpd is the source of truth, content is reviewed at publish time, the client just runs. No sandbox, no signing, no consent prompts. The controls that matter are already on the publishing side (RBAC, audit, reviewer queue). What we DO provide is ops hygiene: - Hard timeout (default 60 s; per-skill override via metadata.postInstallTimeoutSec). SIGTERM at the deadline, SIGKILL after a 2 s grace. - Hash pinning. The script's sha256 is recorded in ~/.mcpctl/skills-state.json. Re-syncs of an unchanged script are a cheap no-op. A re-published "same version, fixed script" still triggers re-execution because its hash changed. - Curated env. PATH/HOME/USER/SHELL inherited; everything else dropped. MCPCTL_SKILL_NAME / _VERSION / _DIR / _PROJECT injected so scripts have stable context. - Per-skill install log under ~/.mcpctl/skills/<name>/install.log. Bounded at 5 × 256 KB; old entries truncated from the front. - Audit event back to mcpd (POST /api/v1/audit-events, eventKind=skill_postinstall) on every run, including hostname so admins can see fleet rollout state. Best-effort — failures are warned but never block the sync. - Path-escape rejection. metadata.postInstall must resolve inside the skill bundle; relative paths that try to climb out are refused. - Auto-chmod 0755 on the script before spawn. Some upstreams ship 0644 + a shebang and expect a shell to handle it; we always spawn the path directly so we need +x. Failure semantics: on timeout or non-zero exit, the recorded postInstallHash is NOT updated. Next sync retries. Other skills in the same sync run continue regardless — postInstall errors are scoped, not fatal. ## Files ### Added - src/cli/src/utils/postinstall.ts (~200 LOC) - src/cli/tests/utils/postinstall.test.ts (~190 LOC, 10 tests covering success, env vars, chmod, non-zero exit, timeout via exec sleep, path-escape, missing script, log file shape + append-across-runs) ### Edited - src/cli/src/commands/skills.ts: applyOne now invokes runPostInstall + emitPostInstallAudit when metadata.postInstall is set and the script hash differs from prior state. New SyncResult fields: postInstallsRan, postInstallsSkipped. Summary line surfaces "N postInstall ran". --skip-postinstall flag now actually does what it says. ## Verification 163 test files / 2171 tests green (up from 2161). End-to-end on a real machine (after this PR ships and a skill with metadata.postInstall is published): ``` mcpctl skills sync # → mcpctl: 1 installed, 1 postInstall ran cat ~/.mcpctl/skills/<name>/install.log # see stdout/stderr mcpctl skills sync # idempotent — skipped ``` If the same skill is republished with a fixed script: ``` mcpctl skills sync # → mcpctl: 1 updated, 1 postInstall ran (hash changed → rerun) ``` If the script fails (exit 7): ``` mcpctl skills sync # → mcpctl: 1 updated, 1 errors mcpctl skills sync # state.postInstallHash NOT updated → retries ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 19:05:42 +01:00
Michal	e6cd73543a	fix(mcpd): fail-loud on env resolution + retry/backoff + readiness via proxy ... Three connected issues with how instances came up + got reported as healthy when their secret backend was unreachable. The motivating case: gitea-mcp-server starts when mcpd can't read the gitea-creds secret from OpenBao, runs with an empty GITEA_ACCESS_TOKEN, replies fine to tools/list (so liveness passes), but every authed call fails with "token is required" — and `mcpctl get instances` cheerfully reports the instance as healthy. ## What changed ### 1. Env resolution failures are now fatal for the start attempt `src/mcpd/src/services/instance.service.ts` The previous behaviour swallowed `resolveServerEnv` failures and let the container start anyway with whatever env survived ("non-fatal — container may still work if env vars are optional"). That's the bug: the gitea container started with no token, ran for weeks, and was reported healthy. The catch now calls `markInstanceError(instance, "secret resolution failed: <reason>")` and returns. Optional/missing env vars should be modelled as `value: ""` entries on the server, not as silent secret-resolution failures. ### 2. ERROR instances retry with backoff, not blind churn Adds Kubernetes-style escalation: 30 s × 5 attempts, then 5 min pauses thereafter. Retry state lives on `McpInstance.metadata` (no schema migration) — `attemptCount`, `lastAttemptAt`, `nextRetryAt`, `error`. The reconciler no longer tears down ERROR instances and creates fresh replacements (which would reset attemptCount and effectively loop at 30 s forever). Instead: - ERROR rows whose `nextRetryAt` is in the future are LEFT ALONE and counted against the replica budget — preventing tight create- fail-create churn while a previous attempt is in its backoff window. - ERROR rows whose `nextRetryAt` has elapsed are retried IN-PLACE via a new `retryInstance` method, which preserves attemptCount on the same row so the schedule actually escalates. The work has been factored into `startOne` (creates + initial attempt) + `attemptStart` (env + container) + `retryInstance` (re-attempt the same row) + `markInstanceError` (write retry metadata). ### 3. STDIO readiness probe goes through mcpProxyService `src/mcpd/src/services/health-probe.service.ts` The legacy `probeStdio` (a `docker exec node -e '... spawn(packageName) ...'` invocation) only worked for packageName-based servers. Image- based STDIO servers like gitea-mcp-server fell through with "No packageName or command for STDIO server" and were reported unhealthy for the WRONG reason — they have no packageName because they are an image, not because anything's wrong. New `probeReadinessViaProxy`: sends `tools/call` through the live running container via `mcpProxyService.execute`. Same code path as production traffic, so probe failures match real failures. Picks up: - JSON-RPC errors (e.g. "token is required" when env is empty). - Tool-level errors expressed as `result.isError: true`. - Connection failures wrapped as exceptions. - Hard timeouts via the deadline race. After this PR, configuring `gitea` with `healthCheck: { tool: get_me, intervalSeconds: 60 }` makes `mcpctl get instances` report it as `unhealthy` whenever the auth token is missing or wrong — which is honest. The dead `probeStdio` (~120 LOC) is removed; HTTP/SSE bespoke probe paths are kept for now (they work and the diff stays minimal). ## Tests `src/mcpd/tests/instance-service.test.ts`: - Replaces "cleans up ERROR instances and creates replacements" with "retries ERROR instances in-place when their backoff has elapsed". - Adds "leaves ERROR instances alone while their nextRetryAt is in the future" and "escalates the backoff: attemptCount + nextRetryAt persist on retry failures". `src/mcpd/tests/services/health-probe.test.ts`: - Swaps STDIO probe mocks from `orchestrator.execInContainer` → `mcpProxyService.execute`. - Adds "marks unhealthy when proxy returns a JSON-RPC error (e.g. broken-secret auth failure)" — explicitly the gitea case. - Adds "marks unhealthy when proxy returns a tool-level error in result.isError" — covers servers that report tool failures as isError instead of as JSON-RPC errors. - Renames "handles exec timeout" → "handles probe timeout" and exercises the deadline race rather than an exec rejection. Full suite: 162 test files / 2161 tests green (+4 new). ## Manual verification step (post-deploy) ```bash mcpctl edit server gitea # → add healthCheck: # tool: get_me # intervalSeconds: 60 # timeoutSeconds: 10 # failureThreshold: 3 ``` If OpenBao is still down: gitea instance enters ERROR with attemptCount + nextRetryAt visible in `mcpctl describe instance`. Otherwise: gitea env resolves at next start, probe passes, instance is honestly healthy. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 18:55:23 +01:00
Michal	e8c3803fac	feat(web): bold redesign — Tailwind v4 + shadcn-style primitives + Skills/Proposals/Revisions UI ... Phase 6 of the Skills + Revisions + Proposals work. The web UI gets a new design language and first-class affordances for everything the backend now supports. ## Visual direction - Tailwind v4 with custom @theme block (oklch tokens). Dark-mode-only (internal tool — light mode doubles QA surface). - Inter for UI, JetBrains Mono for code/IDs (loaded via Google Fonts; trivial to swap for self-hosted geist later — the fallback stack reads identically). - Sidebar layout (always-visible at desktop widths) replacing the previous top-bar nav. Pending-proposals badge polls every 30 s so reviewers see a queue building without refreshing. - Lucide icons throughout. - Spacing and radii on Tailwind defaults. Existing inline-styled pages (Projects, Agents, AgentDetail, ProjectPrompts, PersonalityDetail, Login) continue to work unchanged inside the new Layout — Tailwind doesn't conflict with their inline styles. A follow-up can migrate them incrementally. ## What's added ### Build infra (src/web/) - package.json: tailwindcss@^4 + @tailwindcss/vite, lucide-react, class-variance-authority, clsx, tailwind-merge, diff, geist (held for future self-hosting). - vite.config.ts: registers the @tailwindcss/vite plugin. - src/index.css: Tailwind import + @theme tokens + @layer base. - src/main.tsx: imports index.css. - src/lib/utils.ts: shadcn-style cn() helper. ### shadcn-style primitives (src/components/ui/) Hand-written rather than generated via `npx shadcn` so the repo doesn't depend on a CLI tool that needs interactive runtime: - button.tsx — variants: primary / secondary / ghost / danger / link; sizes: sm / md / lg / icon. - card.tsx — Card + Header/Title/Description/Content/Footer subparts. - badge.tsx — variants: default / info / success / warning / danger / outline. - input.tsx — Input + Textarea + Label. - tabs.tsx — no-dep accessible Tabs (no Radix needed for our use). - separator.tsx — h/v separator with role=separator. ### Diff component (src/components/Diff.tsx) Wraps the `diff` package (already added in PR-2) for inline unified- diff display with color-coded add/remove rows. Used by both the proposal review page and the skill revision-history tab. ### New pages (src/pages/) - Dashboard.tsx — at-a-glance home. Counts for skills, prompts, projects, agents, proposals; pending-proposals call-out card if any. - Skills.tsx — list view, separated into Global vs Project/Agent- scoped sections. - SkillDetail.tsx — name + semver + description; tabs for SKILL.md / Files / Metadata / History. History tab shows revisions with click-to-diff against the live body. - Proposals.tsx — queue with Pending/Approved/Rejected tabs. Pending count is highlighted in amber. - ProposalDetail.tsx — full body, diff against current resource (or "would create new" if it doesn't exist), approve button + reject- with-required-note flow. ### usePolling hook (src/hooks/) Tiny polling-with-cancellation hook used by Layout and Proposals. ### Layout rewrite (src/components/Layout.tsx) Sidebar with nav items: Dashboard, Projects, Agents, Skills, Proposals. Lucide icons. Active-route highlighting via NavLink. Pending-proposals warning badge on the Proposals item. ### Routes (src/App.tsx) New routes: /dashboard, /skills, /skills/:name, /proposals, /proposals/:id. Default redirects to /dashboard. ### API types (src/api.ts) Type defs for Skill, VisibleSkill, Proposal, Revision (with the shapes the new pages consume). ## Tests Existing 7 web tests still pass (Login + api). New page-level tests deferred — the new pages are mostly compositions of primitives and fetch hooks that round-trip to the backend; the backend tests already cover what they call. PR-7 polish can add render-and-click tests if coverage drift surfaces. ## Verification - `pnpm --filter @mcpctl/web build` clean, no warnings. - `pnpm test:run` whole monorepo: 162 test files / 2157 tests green. - Visual smoke deferred — needs a running mcpd to populate the fixtures. Manual smoke tested locally is the next step. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 17:54:55 +01:00
Michal	58e8e956ce	feat(cli+mcpd): mcpctl skills sync + config claude extension ... Phase 5 of the Skills + Revisions + Proposals work. Skills are now materialised onto disk under ~/.claude/skills/<name>/, with hash-pinned diff against mcpd, atomic per-skill install, and preservation of locally-modified files. `mcpctl config claude --project X` now wires the full pickup chain: writes .mcpctl-project marker, runs the initial sync, installs the SessionStart hook so subsequent Claude invocations stay in sync transparently. ## Sync algorithm 1. Resolve project: `--project` flag overrides; else walk up from cwd looking for `.mcpctl-project`; else fall back to globals-only. 2. GET /api/v1/projects/:name/skills/visible (or /api/v1/skills?scope=global without a project). Server returns id + name + semver + scope + contentHash + metadata — no body, no files. The contentHash is sha256 of the canonicalised body, computed server-side; any reordering of keys produces the same hash, so it's a stable diff key. 3. Load ~/.mcpctl/skills-state.json (lives outside ~/.claude/skills/ on purpose — Claude Code reads that tree and we don't want to pollute it with our bookkeeping). 4. Diff: - server skill not in state → INSTALL - server skill, state contentHash matches → SKIP (cheap path) - server skill, state contentHash differs → UPDATE (fetch full body) - state skill not in server → orphan, REMOVE (preserve if locally modified, unless --force) 5. Atomic per-skill install: write to <targetDir>.mcpctl-staging-<pid>/, rename existing tree to .mcpctl-trash-<pid>, swap staging in, rmtree the trash. A concurrent reader (Claude Code starting up) never sees a partial tree. 6. State file updated with new versions, per-file SHA-256, install path. saveState is atomic (temp + rename). ## Failure semantics - `--quiet` mode (used by SessionStart hook): exit 0 on network / timeout / mcpd error. Fail-open is non-negotiable here — we never want a hung mcpd to block Claude Code starting up. - Auth failure: exit 1, clear "run mcpctl login" message. - Disk error during state save: exit 2. - Per-skill errors are collected in the result and reported as a count; one bad skill doesn't stop the others. Network fetches run with concurrency 5. The server-side `/visible` endpoint is metadata-only so the cheap path (everything unchanged) needs exactly one HTTP roundtrip total. ## Files added ### CLI utilities (src/cli/src/utils/) - skills-state.ts — load/save state, per-file sha256, edit detection. - project-marker.ts — walk-up to find `.mcpctl-project`, bounded by user home so we never search above $HOME. - sessionhook.ts — install/remove a SessionStart hook entry tagged with `_mcpctl_managed: true`. Idempotent. Defensive against missing/empty/JSONC settings.json. - skills-disk.ts — atomic install via staging-dir rename swap, symmetric atomic delete via trash-dir rename. Path-escape attempts in files{} are rejected. ### CLI command (src/cli/src/commands/) - skills.ts — `mcpctl skills sync` Commander wrapper + the `runSkillsSync(opts, deps)` library function (also called from `mcpctl config claude --project`). Supports `--dry-run`, `--force`, `--quiet`, `--keep-orphans`. `--skip-postinstall` is reserved (postInstall execution lands in a follow-up PR, not this one). ### Wiring - index.ts: registers `mcpctl skills` after `mcpctl review`. - config.ts: `mcpctl config claude --project X` now writes the `.mcpctl-project` marker, runs `runSkillsSync` in-process, and calls `installManagedSessionHook('mcpctl skills sync --quiet')`. New flag `--skip-skills` opts out (used by tests; useful for CI). ## Server-side change - src/mcpd/src/services/skill.service.ts: getVisibleSkills now computes contentHash on the fly from the canonical body shape the client will reconstruct. Cheap (sha256 of ~few KB per skill); no schema migration needed since hash is derived not stored. ## Tests Four new utility test files (31 tests) under src/cli/tests/utils/: - sessionhook.test.ts — creation, idempotency, command updates, preservation of user hooks, removal, empty/JSONC tolerance. - skills-disk.test.ts — atomic write, replacement without leftovers, path-escape rejection, atomic delete, listing ignores staging/trash artifacts. - skills-state.test.ts — sha256 determinism, state round-trip, schema-version drift handling, edit detection. - project-marker.test.ts — cwd hit, walk-up, $HOME boundary, empty marker, write+read round-trip. The existing `mcpctl config claude` test (claude.test.ts) was updated to pass `--skip-skills` so it stays focused on .mcp.json generation; the new sync flow is covered by the utility tests. Full suite: 162 test files / 2157 tests green (up from 158 / 2127). ## Deferred to a follow-up - `metadata.hooks` materialisation into `~/.claude/settings.json` — the data path exists, sync receives it; PR-7 or a focused follow-up will write the `_mcpctl_managed: true` entries for declarative hooks. - `metadata.mcpServers` auto-attach via mcpd API — likewise. - `metadata.postInstall` script execution — the most substantive deferred piece. Current sync logs a TODO and skips. The corporate trust model (publisher-side rigor, not client-side defence) means this is straightforward to add once we wire the curated env + timeout + audit emission. Orthogonal to file sync, easier to ship separately. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 16:26:35 +01:00
Michal	db57bb5856	feat(mcpd+mcplocal+cli): propose-learnings system skill, propose_skill MCP tool, mcpctl review ... Phase 4 of the Skills + Revisions + Proposals work. Closes the reflexive loop: Claude sessions can now propose back content (prompts or skills) that maintainers triage via a CLI queue. The system documents itself to Claude through the same mechanism it documents to humans. ## What's added ### propose-learnings global skill (mcpd bootstrap) - src/mcpd/src/bootstrap/system-skills.ts — idempotent upsert, mirrors system-project.ts. Single skill seeded today: `propose-learnings`, ~430 words, explains when to engage with propose_prompt vs propose_skill, what makes a good proposal, what NOT to propose, and the review→approve flow. Priority 9, global scope. - main.ts: `bootstrapSystemSkills(prisma)` called right after `bootstrapSystemProject`. ### gate-encouragement-propose system prompt - system-project.ts gains a new gate prompt (priority 10, alongside the other gate-* prompts) that nudges Claude to call propose_prompt when it discovers a project-specific lesson. Pairs with the propose-learnings skill — the prompt is the trigger, the skill is the manual. ### propose_skill MCP tool (mcplocal) - proxymodel/plugins/gate.ts: new virtual tool registered alongside propose_prompt. Posts to /api/v1/proposals (the new endpoint from PR-2) with resourceType='skill'. Tool description steers Claude toward propose_prompt for project-specific knowledge and reserves propose_skill for cross-cutting cases. propose_prompt's tool description is also expanded to point at the propose-learnings skill for guidance — the bare "creates a pending request" copy was bland enough that nothing in Claude's prior would actually make it engage. ### mcpctl review CLI - New top-level command in src/cli/src/commands/review.ts. Subcommands: mcpctl review pending List pending proposals mcpctl review next Show oldest pending mcpctl review show <id> Full detail mcpctl review approve <id> POST /proposals/:id/approve mcpctl review reject <id> --reason "..." mcpctl review diff <id> Side-by-side current vs proposed - Wired into src/cli/src/index.ts. Registered after createApproveCommand to keep the existing project-ops `mcpctl approve promptrequest` command working (legacy) while the new review surface is the preferred path. ## Tests touched - bootstrap-system-project.test.ts already counts via getSystemPromptNames() length, so it picked up the new prompt automatically; only the priority assertion needed nothing — the new prompt starts with `gate-` so the existing `gate-* → priority 10` invariant validates it. - system-prompt-validation.test.ts: bumped expected length from 11→12 and added a `toContain('gate-encouragement-propose')` assertion. Full suite: 158 test files / 2127 tests green. ## What's NOT in this PR - A SkillService mock-based test for the proposal approval handler — the PromptService approval handler is structurally identical and already covered; the database-backed integration is exercised in PR-2's tests. - Changes to mcplocal's existing handleProposePrompt URL — it still POSTs to the legacy /api/v1/projects/.../promptrequests endpoint, which works because PR-2 left that route in place. PR-7 will cut mcplocal over to /api/v1/proposals along with the PromptRequest table rename + drop. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 13:13:33 +01:00
Michal	20a541a5d6	feat(mcpd): Skill resource end-to-end (CRUD + backup + revision integration) ... Phase 3 of the Skills + Revisions + Proposals work. Skills get the same inline-content + revision-history shape as prompts, with the addition of `files` (multi-file bundles, materialised by `mcpctl skills sync` in PR-5) and a typed `metadata` Json (hooks, mcpServers, postInstall, …). ## What's added ### Validation (src/mcpd/src/validation/skill.schema.ts) Typed metadata schema with a closed list of recognised hook events (PreToolUse, PostToolUse, SessionStart, Stop, SubagentStop, Notification), typed `mcpServers` dependency declarations (name + fromTemplate + optional project), and `postInstall` / `preUninstall` paths into the bundle's `files{}`. `.passthrough()` so unknown fields survive — forward-compat for follow-on additions. ### Repository (src/mcpd/src/repositories/skill.repository.ts) Mirrors PromptRepository exactly. Same `?? ''` workaround for nullable-FK compound-key lookups. ### Service (src/mcpd/src/services/skill.service.ts) Mirrors PromptService for create / update / delete / restore / upsert, including: - Auto-bump patch on content/files/metadata change. - Revision recording (best-effort — failures don't block the save). - 'skill' approval handler registered with ResourceProposalService so proposalService.approve dispatches to skills the same way it dispatches to prompts. - `getVisibleSkills(projectId)` returns id + name + semver + scope + metadata for `mcpctl skills sync` (PR-5) to diff against on-disk state. ### Routes (src/mcpd/src/routes/skills.ts) - GET /api/v1/skills (filters: ?project= ?projectId= ?agent= ?scope=global) - GET /api/v1/skills/:id - POST /api/v1/skills - PUT /api/v1/skills/:id - DELETE /api/v1/skills/:id - GET /api/v1/projects/:name/skills - GET /api/v1/projects/:name/skills/visible — sync diffing - GET /api/v1/agents/:name/skills - POST /api/v1/skills/:id/restore-revision { revisionId, note? } ### main.ts SkillRepository + SkillService instantiated; revision/proposal services wired in. `skills` segment added to the RBAC permission map (uses the existing `prompts` permission for now — same trust shape) and to `kindFromSegment` so the git-backup hook captures skill mutations. ### Backup integration - yaml-serializer.ts: `BackupKind` adds 'skill'; APPLY_ORDER bumps to 9 with skill last (it depends on projects/agents). `parseResourcePath` recognises the `skills/` directory. - git-backup.service.ts: `serializeResource` adds the `case 'skill'` branch alongside prompts. The git-sync loop now round-trips skills on every change. - (Bundle backup-service.ts is NOT updated in this PR — deferred to PR-7 alongside the cutover. The git-based backup IS wired, which is the primary persistence path.) ### CLI - `mcpctl create skill <name>` with --content / --content-file, --description, --priority, --semver, --metadata-file (YAML/JSON), --files-dir (walks a directory tree into `files{}`, UTF-8 only; null bytes rejected). - shared.ts adds `skill` / `skills` / `sk` aliases. ### apply.ts Not updated — `mcpctl apply -f skill.yaml` is deferred to PR-7. The existing CRUD endpoints + `mcpctl create skill` cover the bootstrap need; bulk-apply will arrive with the `propose-learnings` seed and docs. ## Tests 158 test files / 2127 tests green across the workspace. The DB-level schema tests for Skill landed in PR-1; the new service-level integration is exercised through main.ts wiring + the existing prompt revision tests (skill follows the same code path through proposal service approval). A `describe('Skill service mocks')` test file deliberately not added — the PromptService mock-based tests already cover the revision/approval handler shape, and the skill handler is structurally identical (same upsert + record-revision + link-currentRevisionId pattern). PR-7 will add an integration test that walks the full propose → review → approve flow for both resource types. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 00:48:40 +01:00