fofos's capabilities failure was ownership, and one stat proved it

Three deploys reported the same two errors and neither report could explain them:

  dubious ownership in repository at '~/officerdev/capabilities'
  EACCES: permission denied, mkdir '~/officerdev/capabilities/affordances/officerdev'

They read as two problems — git refusing to operate, and Node refusing to create a directory, at different
steps of the deploy — and they were one sentence in two dialects: this path is not yours. Fifty paths under
that checkout were owned by root, .git and affordances among them, all stamped 19 Aug 21:43. Something ran
with sudo and left them.

Mode 755 is what made the shape confusing. Everything was READABLE, so git could see the repo and refused
it on ownership, while the plugin could see affordances and could not write into it. Two tools, two
messages, one inode owner.

The general point, which is why this is in servers.md rather than only in a commit: stat prints the owner
instead of inferring it, so it either proves ownership is the cause or eliminates it — one command, binary,
no theory. Three reports had guessed; none had looked.

The deploy commander's refusal to add a safe.directory entry was right and is recorded as such. It would
have silenced the git message and left the EACCES exactly as it was, spending the obvious explanation on
half the problem.

Fixed by the owner with chown -R; verified after by a mkdir into the directory that used to refuse one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/servers.md

@@ -77,10 +77,22 @@ All verified, none cosmetic.
 - **`bun run plugins:update` restarts sidecars itself**, printing `sidecar: started` per plugin — on
   `alpha` that is twelve processes bouncing during the plugins step, before any restart the plan asked for.
   Not a fault, but a deploy report that lists only `officer` under "restarted" is understating what moved.
-- **`fofos` cannot sync its capabilities**, and could not publish gitea affordances on 2026-08-21:
-  `dubious ownership` from git and `EACCES … mkdir '…/capabilities/affordances/officerdev'`. Both point at
-  that capabilities checkout being owned by somebody other than `pastilhas`. Deliberately not papered over
-  with a `safe.directory` entry until somebody has run one `stat` on it. **Unexplained.**
+- **`fofos` failed its capabilities sync for three deploys, and it was ownership.** Fixed 2026-08-21.
+  Two errors that read as unrelated problems — `dubious ownership` from git, and
+  `EACCES … mkdir '…/capabilities/affordances/officerdev'` from the gitea plugin — were one cause in two
+  dialects: fifty paths under that checkout were owned by `root`, including `.git` and `affordances`, all
+  stamped `19 Aug 21:43`. Something was run with `sudo` and left them behind. Mode `755` is why the split
+  looked odd: everything could be READ, so git saw the repo and refused it on ownership while the plugin
+  saw `affordances` and could not write into it.
+
+  One `stat` settled it, and that is the general lesson — `stat` prints the owner rather than inferring
+  anything, so it either proves ownership is the cause or eliminates it, in one command. Fixed with
+  `sudo chown -R pastilhas:pastilhas ~/officerdev/capabilities`; verified after by a `mkdir` into the
+  directory that used to refuse one.
+
+  **A `safe.directory` entry was deliberately NOT used**, and that call is worth keeping. It would have
+  silenced the git message and left the `EACCES` untouched — one symptom of a two-symptom cause hidden,
+  with the obvious explanation spent.
 
 ## Not platforms — ignore for now