Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions changelog.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,26 @@ export const STAGE_SELF_MANAGED_M66 = "$0.0001";
agentsfleet is in **stealth-mode testing** and pre-production. APIs and agent behavior may change between releases without long deprecation windows. Email [agentsfleet@agentmail.to](mailto:agentsfleet@agentmail.to) if you want a hand calibrating an agent or to join as a design partner.
</Tip>

<Update label="Jul 14, 2026" tags={["What's new", "API", "UI"]}>
## The fleet catalog stops overstating itself, and operators can fix a mistyped repository in place

A catalog entry's status badge now always matches what a workspace will actually get, and an operator can correct an entry's name, repository, or ref without deleting it — keeping every piece of curated install-gate copy. Copy buttons across the dashboard now report a failed copy instead of pretending it worked, the dashboard counts every fleet state, and the live activity thread shows the tools a fleet calls and what each event cost.

## What's new

- **Edit a catalog entry's identity** — name, repository, and ref are editable from the catalog's Edit dialog. Changing the repository or ref discards the stored bundle and returns the entry to draft, because the stored bundle was built from the old repository; fetch and publish again to go live. Workspaces already running the fleet keep the exact bundle they installed. A rename survives the next bundle fetch, and so does a pinned ref — **Fetch update** now fetches at the ref the entry names instead of resetting it to the default branch.
- **An honest status column** — an entry that is published but holds no bundle now shows as **Broken** (it was shown as Published while being invisible to every workspace). Its help text says how to resolve it: fetch a bundle, or unpublish.
- **The admin button says what it does** — **Create fleet library** replaces "Add fleet", matching the workspace-side dialog; the page and navigation use the singular **Fleet library**.
- **Copy buttons everywhere a value wants copying** — bundle hashes (the full hash, not the visible preview), fleet and host identifiers, secret names, model identifiers, cron schedules, webhook URLs, approval action identifiers, and one-time credentials. A failed clipboard write is reported on the button and announced to screen readers — previously several surfaces showed "Copied" or nothing at all when the write failed, which could cost you a one-time runner token or API key.
- **The dashboard counts every fleet** — installing and killed fleets now appear in the summary tiles; previously they were counted nowhere.
- **The live thread shows tool calls and cost** — each fleet response lists the tools it called with their durations while it works, and event history rows show tokens and wall time.

## API reference

`PATCH /v1/admin/fleet-libraries/{id}` additionally accepts `name`, `source_repo`, and `source_ref`. A request whose `source_repo` or `source_ref` differs from the stored value sets `content_hash` to null and `visibility` to `draft` atomically; re-sending the stored value is a no-op. A request that changes the source and sets `published: true` in the same call is refused with `UZ-CATALOG-002` (there is no bundle to publish by the time the publish would apply). Malformed sources are refused with `UZ-BUNDLE-001` using the same validation as onboarding. The entry identifier is never patchable.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 PATCH Operation Is Not Discoverable

This introduces PATCH /v1/admin/fleet-libraries/{id}, but the Fleet library API navigation does not include that operation. Operators browsing the API reference cannot discover the documented edit path and are left with only the collection GET and POST operations.

Prompt To Fix With AI
This is a comment left during a code review.
Path: changelog.mdx
Line: 41

Comment:
**PATCH Operation Is Not Discoverable**

This introduces `PATCH /v1/admin/fleet-libraries/{id}`, but the Fleet library API navigation does not include that operation. Operators browsing the API reference cannot discover the documented edit path and are left with only the collection GET and POST operations.

How can I resolve this? If you propose a fix, please make it concise.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 New Error Code Lacks Reference

The new combined source-and-publish failure returns UZ-CATALOG-002, but that code is absent from the error-code reference. Clients following the reference cannot map this reachable PATCH failure to its documented cause or present the intended recovery guidance.

Prompt To Fix With AI
This is a comment left during a code review.
Path: changelog.mdx
Line: 41

Comment:
**New Error Code Lacks Reference**

The new combined source-and-publish failure returns `UZ-CATALOG-002`, but that code is absent from the error-code reference. Clients following the reference cannot map this reachable PATCH failure to its documented cause or present the intended recovery guidance.

How can I resolve this? If you propose a fix, please make it concise.


</Update>

<Update label="Jul 12, 2026" tags={["What's new", "API"]}>
## Platform operators onboard fleets from the dashboard, and four prebuilt fleets are ready to install

Expand Down
18 changes: 15 additions & 3 deletions fleets/library.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -40,13 +40,25 @@ New fleets install only by library identifier. Local files can update an existin

## Onboard a platform entry

Platform entries are added from the dashboard at **Fleet libraries**, under Configuration. The page is visible only to an operator whose session carries the `platform-library:write` scope. Everyone else is redirected, and the API refuses the request independently.
Platform entries are added from the dashboard at **Fleet library**, under Configuration, with **Create fleet library**. The page is visible only to an operator whose session carries the `platform-library:write` scope. Everyone else is redirected, and the API refuses the request independently.

Enter the repository as `owner/repo`. `agentsfleet` fetches the repository, validates the bundle, stores it, and adds the catalog row. The entry then appears in every workspace's library, and any workspace can install it.
Enter the repository as `owner/repo`. `agentsfleet` fetches the repository, validates the bundle, stores it, and adds the catalog row **as a draft**. No workspace can see or install a draft; publishing is the only door to a workspace's library.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Onboarding Guidance Still Conflicts

This correctly says a platform entry starts as a draft, but the Jul 12 changelog still tells operators that onboarding adds it where every workspace can install it. An operator following that release note will expect immediate visibility and may treat the required publish step as a failed onboarding.

Prompt To Fix With AI
This is a comment left during a code review.
Path: fleets/library.mdx
Line: 45

Comment:
**Onboarding Guidance Still Conflicts**

This correctly says a platform entry starts as a draft, but the Jul 12 changelog still tells operators that onboarding adds it where every workspace can install it. An operator following that release note will expect immediate visibility and may treat the required publish step as a failed onboarding.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!


A platform entry's identifier comes from the `name` in the bundle's `SKILL.md`, not from the repository path you type. Keep the repository name, the `SKILL.md` name, and the `TRIGGER.md` name identical. When they differ, `agentsfleet` rejects the bundle or files it under an identifier you did not expect.

Onboarding the same repository twice updates the existing entry. It does not create a second one.
Onboarding the same repository twice updates the existing entry. It does not create a second one. A refetch always returns the entry to draft, so a newer bundle never reaches workspaces unreviewed.

## Edit a platform entry

An entry's name, repository, and ref are editable in place from the catalog's **Edit** dialog, alongside its description and the install-gate copy for each credential. The identifier is not editable — installed fleets reference it.

Changing the repository or ref discards the stored bundle and returns the entry to draft. The stored bundle was built from the old repository, and an entry never advertises a source it is not serving. Fetch the bundle again, then publish.

Workspaces already running the fleet are unaffected. Each install keeps the exact bundle it installed.

A rename survives the next bundle fetch, as the description and credential copy always have. A pinned ref survives it too: **Fetch update** fetches at the ref the entry names, rather than resetting the entry to the repository's default branch. Credential copy is pruned to the credentials the bundle actually declares, so a credential the fleet no longer requests does not linger in the dialog.

An entry that is published but holds no bundle shows as **Broken** in the catalog. It is invisible to every workspace; fetch a bundle or unpublish it.

## Prebuilt fleets

Expand Down
Loading