ship the capabilities repository, and update it from the same button as plugins
capabilities/ is the file-based item store, and most of it belongs to the owner: the six item directories are created by the platform at boot and extensions/tool-loader is written from platform source, so neither is tracked anywhere. What IS tracked is the small set the platform ships — today one affordance, telling an agent that markdown images render and that the USER'S DEVICE fetches the URL, which it cannot discover from the filesystem. That now lives in officerdev/capabilities, public so a fresh install can clone it without credentials. Two ways in. The setup script syncs it during the layout step — non-fatal, and it says what an install without it costs rather than failing: agents go back to guessing, which is what they did before this existed. And "Update all" on the marketplace screen carries it alongside the plugins, because it is the same question — get me what has been published since I installed — and a second different gesture for it is one nobody remembers. Three states in both places, and the third is the normal one on an existing machine: a checkout is pulled, an empty directory is cloned into, and a directory that already holds the platform's generated items gets a repository initialised around them. UNTRACKED files never block a pull, because the owner's own skills and tools living here is the ordinary state — only tracked changes do. `cloned` and `adopted` are reported in the UI where `pulled` is not: they mean this machine had no affordances at all until the button was pressed. Verified against the real checkout: sync reports pulled, and the loader finds officer/core/image-rendering afterwards. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -50,6 +50,12 @@ export const PluginsList = () => {
|
||||
<span className="text-duck-dark/60">
|
||||
{updateAllResult.updated} updated
|
||||
{updateAllResult.failed.length ? `, ${updateAllResult.failed.length} failed` : ''}
|
||||
{/* `cloned` and `adopted` are worth saying out loud: they mean this machine had no
|
||||
capabilities checkout until now, so its agents had no affordances at all. `pulled` is
|
||||
the ordinary case and does not need announcing. */}
|
||||
{updateAllResult.capabilities?.ok && updateAllResult.capabilities.action !== 'pulled'
|
||||
? ` · capabilities ${updateAllResult.capabilities.action}`
|
||||
: ''}
|
||||
</span>
|
||||
{/* Named, with the reason. The expected failure is a dirty checkout, and "2 failed" without
|
||||
saying which is a message that sends someone to the terminal to find out. */}
|
||||
|
||||
@@ -78,6 +78,8 @@ export type PluginActionResult = { ok: boolean; appName: string; steps: string[]
|
||||
/** What `POST /plugins/update-all` answers with. Per-plugin, because one failing must not hide the rest. */
|
||||
export type UpdateAllResult = {
|
||||
results: PluginActionResult[];
|
||||
/** The capabilities repository rides along — see the route. `adopted` means it had no checkout before. */
|
||||
capabilities?: { ok: boolean; action: 'pulled' | 'cloned' | 'adopted' | 'failed'; error?: string };
|
||||
updated: number;
|
||||
failed: { appName: string; error?: string }[];
|
||||
};
|
||||
|
||||
Reference in New Issue
Block a user