docs: AI_CAPABILITIES.md changelog for MCP v2.4.6
Made-with: Cursor
This commit is contained in:
@@ -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
Reference in New Issue
Block a user