pastilhasandClaude Opus 5 68d6dd942e update means something now: it depends on tags
"update" was `git pull` and re-install, unconditionally, for every plugin.
nothing could say whether there was anything to pull, so the button was always
there and usually did nothing — and "update all" was twenty-one no-ops with a
spinner on it. the button's own comment admitted it: gating on `outdated` would
hide it for ever, because nothing bumped a version.

versions are dated and tagged now, so the rule the owner asked for is possible:

  · a checkout NOT at a tag is always updateable — it is between releases, no
    claim is being made about it, pulling is always reasonable
  · a checkout AT a tag is updateable only when a NEWER tag exists

the part worth defending is how "newer" is decided. the obvious version-string
comparison is wrong the first time a plugin is tagged `v2` or `1.0.0-rc1`, and
wrong SILENTLY — a plugin that never offers an update looks like one nobody has
released. so newness is asked of git: the newest tag reachable from the REMOTE
branch, compared against the tag at HEAD. that holds for any names anyone
chooses, and there is a test with a tag called `beta` that sorts before `v1` to
keep it honest.

it never fetches. every answer comes from refs already on disk, because this
runs once per plugin on a request that renders a list and twenty-one network
round trips would make the screen feel broken. tags arrive at clone and at the
fetch `pullPlugin` already does.

the VERB refuses too, not just the UI. a plugins list is fetched once and a tag
can be pushed a second later, so the copy someone clicks is routinely older than
the truth — and `updateAll` iterates a list rather than asking per plugin.

"up to date · <tag>" is said out loud rather than shown as an absent button. no
button and up-to-date look identical, and only one of them is information.

verified on the real installs: example pulled to its tag and flipped to
up-to-date, caldav on an older commit stayed updateable, and updatePlugin on
example answered "already at 2026.08.27.01, the newest release" without pulling.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
2026-08-27 07:44:00 +00:00
2026-08-26 04:39:40 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00
2026-02-22 03:35:26 +00:00
2026-02-16 19:34:35 +00:00

The documentation, triaged

2026-08-13. A map of what is in here, what it is for, and what should happen to it. Made because there are 42 documents and 13,000 lines, and no way to tell from the filenames which describe the system as it is and which are a record of an afternoon in July.

How much I verified: the classifications below are from filenames, status lines, and greps for things that changed on 2026-08-13. Where I actually read the document or checked the code, it says so. The rest is a starting point for a conversation, not a verdict.


Living — these describe the system and must stay true

doc state
working-on-officer.md updated 2026-08-13. Operational guide.
secret-store.md updated 2026-08-13. Built; rotation still open.
install-variants.md new. The branch tree, for discussion.
http-secure-context-audit.md new. What breaks over plain http.
install-container-testing.md new. First container pass and its findings.
per-user-linux-accounts.md partly updated. OFFICER_OS_USERS is gone; check the rest.
navigation-audit.md authoritative on routing. Unverified against tonight's route removals.
workspace-panels.md + workspace-panel-todo.md the panel framework. 1,300 lines combined — likely the biggest cleanup here.
agent-coordination.md the north star for panel work.
deprovision-os-account.md implemented; the 'disabled' stage it may mention was deleted tonight.

Stale — describe things that changed on 2026-08-13

Each of these references something that no longer exists. Not yet corrected.

  • sidecar-topology.md — "ecosystem.config.cjs is the source of truth". It is generated now, and holds six processes.
  • sidecar-app-store.md — derives the catalogue from full − light. Those files are gone, and catalogue.test.ts was rewritten.
  • sidecar-bootstrapping.md — "20 PM2 entries, 18 sidecar dirs". Six entries now.
  • mobile-api-keys.md — partly corrected; recheck the origin-checking claims.
  • wallet-key-custody.md — VAULT_STORE_KEY is now the per-purpose wallet key.
  • push-notifications.md — "agreed design, 2026-07-31". Notify is a plugin and unmounted.
  • chat-session-lifetime.md, chat-ui-walkthrough.md — reference officer-agent, renamed.

Historical — a record of a moment, and should stay one

Do not rewrite these to match today's code. They document how a decision was reached, and editing them destroys the reasoning. If they mislead, add a dated header pointing forward.

  • sidecar-audit-2026-07.md (1,377 lines)
  • claude-sidecar-isolation.md — records the officer-claude → officer-agent rename that preceded tonight's officer-agent → officer-claude-code
  • open-threads-after-per-user-claude.md
  • two-agent-field-report-2026-08-12.md
  • api-method-changes-2026-08-06.md

The opencode cluster — nine documents for one migration

opencode-fork-decision · -parity · -api-2-assessment · -phase0-review · -phase1-report · -phase1-review · -serve-migration-plan · -serve-path · -testing-checklist

The migration landed — opencode serve is in the sidecar, verified. So opencode-serve-migration-plan.md saying "Nothing here is implemented" is false.

This is the clearest consolidation candidate in the whole directory: one document recording what was decided and what shipped, replacing nine that describe stages of getting there. I did not do it because it needs reading all nine, and deleting documents unread is not a thing to do at 4am.

The mobile-dav thread — three documents, one conversation

mobile-dav-provisioning · -feedback · -reply. A correspondence. Almost certainly one document.

Unclassified — I have not looked

design-language-interface · file-sync · jobs-unification · mobile-photo-sync-api · nextcloud-replacement · agent-git-identity


The plugin split, which affects most of the above

A core install is six processes. Everything else is a plugin, switched off tonight but present on disk. Most documents here were written when the estate was twenty processes and every one of them was simply "there", so they describe availability that no longer holds.

The useful rewrite is usually one line, not a rewrite: say whether the thing described is core or a plugin, and if a plugin, that it is not mounted on a fresh install.

S
Description
No description provided
Readme
51 MiB
Languages
TypeScript 84.6%
CSS 6.7%
Shell 5%
JavaScript 3.7%