officerdev/platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: a running list of servers, and the fleet updater it feeds

Browse Source 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
pastilhas
2026-08-21 05:17:14 +00:00
co-authored by Claude Fable 5
parent 030db140c4
commit 31e858bcb7
2 changed files with 105 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO.md
+43
View File
@@ -36,6 +36,49 @@ the owner's OS user and can never be granted. Indirection there really is accide
generating" was once treated as permission and started a second agent in a repository another was
building in. Whatever shape this takes, it inherits those three refusals.
## Fleet — one command across every server
**The list exists: `docs/servers.md`**, written 2026-08-21 and verified from this host. Five machines
hold a platform checkout, three run it, and it records how to reach each one.
- [ ] **An orchestrator that acts on every server at once** — pull and update every platform, restart a
process everywhere, report which host is behind. The list is the input; this is the thing that
reads it.
Three facts from writing the list decide the design, and all three are verified: the checkout
**path differs per host** (take it from PM2's `pm_cwd` for the `officer` process, never a
hard-coded path); `alpha` carries a **second, stale checkout** so pulling the wrong one succeeds
while changing nothing; and the **git remotes differ** — one host pulls over HTTPS and one points
at a different Gitea altogether. An orchestrator built on "ssh, cd to the same path, git pull"
is wrong on three counts before it starts.
Open: whether this is a script over SSH, an Officer screen, or a chat capability; and whether
`headscale` and `omega` — checkout present, nothing running — are targets at all. Note the
platform already has an **Update button** for a single server (`03abdeb2`); this is that, fanned
out, and it should probably share the code rather than reimplement the pull.
- [ ] **A way to mark a commit "this one ships", so a release is not just `master`'s tip.** Wanted
2026-08-21. **No version numbers** — not now — and **not a tag**: the owner does not want a second
ref to mint and push for something the commit itself could carry. So a **codeword in the commit
message**, and the fleet updater pulls to the newest commit carrying it rather than to whatever
`master` points at.
That distinction is the whole value: today a server updates to the tip, so an in-progress commit
ships the moment it is pushed. A marker makes shipping a deliberate act while leaving the push
unchanged.
Shape to settle when it is built:
- **A trailer, not a word in prose** — `Release: yes` on its own line, in the same family as
`Co-Authored-By`. `git log --grep='^Release:' --format=%H -1` then gives the target SHA in one
command, and no commit message that merely *talks* about a release matches by accident.
- **The trade against a tag, stated honestly:** a tag can be moved or deleted when a release turns
out to be bad; a commit message cannot be edited once pushed. Un-marking means marking a newer
commit — which is a forward-only, revert-shaped workflow. That is a fine answer, but it should
be a chosen one.
- The updater then does a checkout at that SHA, not a `pull` — same discipline the plugin-pinning
item asks for: **verify `rev-parse HEAD` matches, or refuse.**
## File watchers
- [ ] **Watch a directory, and attach actions to what lands in it.** Wanted 2026-08-21. The owner sets a