docs: AI_CAPABILITIES.md changelog for MCP v2.4.6

Made-with: Cursor
This commit is contained in:
2026-04-27 14:30:32 -07:00
parent b514c17ce7
commit c82d90bdd2
2 changed files with 22 additions and 2 deletions

View File

@@ -587,7 +587,7 @@ The MCP descriptor at `GET /api/mcp` reports a semver `version`. Tool names
are append-only within a major version — agents can cache the tool list are append-only within a major version — agents can cache the tool list
safely for the duration of a conversation but should re-fetch on 404. safely for the duration of a conversation but should re-fetch on 404.
Current version: **2.4.5**. Current version: **2.4.6**.
- **1.x** — session-cookie-only MCP, no tenant keys. - **1.x** — session-cookie-only MCP, no tenant keys.
- **2.0** — `vibn_sk_…` keys, workspace-scoped Gitea bot + Coolify project. - **2.0** — `vibn_sk_…` keys, workspace-scoped Gitea bot + Coolify project.
@@ -654,6 +654,26 @@ Current version: **2.4.5**.
back-compat. Internal services (Postgres, Redis, worker) stay on back-compat. Internal services (Postgres, Redis, worker) stay on
their isolated project network — fixing the `password authentication their isolated project network — fixing the `password authentication
failed` regression introduced in 2.4.4. failed` regression introduced in 2.4.4.
- **2.4.6** — Two fixes for transient Coolify queue lag observed in
2.4.5:
- **Polling no longer false-fails on early `exited` status.**
Coolify's queue worker can take 60-120s to dequeue a `start`
request; during that window `service.applications[*].status`
returns the stale `exited` (= "never started") state. Previously
we treated that as terminal failure after 90s. Now we require
*evidence of activity* (`starting:*` or `running:*` was seen at
least once) before treating subsequent `exited` reports as
terminal. Until activity is observed, the loop just keeps polling
up to the 8-min health timeout. Eliminates the case where
`apps.create` returned `started: false` on a stack that was
actually about to come up healthy.
- **`apps.repair`** — new tool. Re-runs the three post-deploy
patches (env rewrite, port label, proxy network attach + recreate
+ proxy restart) against an existing service without recreating
it. Useful when a deploy succeeded mechanically but ended up
serving Traefik 503 or Mixed Content errors, or whenever a user
rotates a custom domain. Params: `{ uuid, fqdn, publicAppName,
port? }`. Returns `{ reachable, postDeploy: { steps }, probe }`.
--- ---

Submodule vibn-frontend updated: 247b31bf2f...d1f8c3d34b