commanders: the connection is the platform's, not the commander's

Framed this as a credential-safety rule; it is a boundary. A commander does not
hold a Whisper URL, does not name one and has no parameter for it — it knows the
platform can transcribe and asks the platform. So there is usually nothing
sensitive in a commander to leak, and sharing is simple for a reason rather than
by luck. The credential rule survives for the case where a commander genuinely
needs a secret of its own.

Also records a scope decision. Whether the platform is configured at all is a
system administration problem, not something to solve with a capability
registry — and the commander skill already covers it: do the first run by hand,
then arm. An unconfigured endpoint fails in front of the person doing it, and the
same rule catches somebody forking the commander onto a machine that lacks it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

docs/commander-directory.md

@@ -117,16 +117,22 @@ what is ignored and how credentials are handled is reference material — read o
 for it. An affordance's body is charged to every turn of every commander forever, and this would earn that
 cost approximately never. `capabilities/skills/commander/SKILL.md` gains a section.
 
-**Credentials are named, never valued.** This is the rule that matters, because the natural place to put a
-Whisper URL is the config file that is about to become public. A commander declares what must be
-configured — "an STT endpoint" — and the platform holds the value. Gitignoring `state/` does not cover
-this: a credential is definition-shaped, it looks like configuration, and it would be committed and pushed
-and stay published.
+**A commander never holds a service's connection details, and that is a boundary rather than a
+precaution.** The Whisper URL is not the commander's business: it knows the platform can transcribe and
+asks the platform, which holds the connection. So there is usually nothing sensitive in a commander to
+leak, and the sharing story is simple for a reason rather than by luck.
 
-**And a shared commander declares what it requires.** Yours assumes a transcription plugin, a Whisper
-server actually configured, and a folder that exists. Landing on an install without them, it arms cleanly
-and fails silently at 3am — the worst failure this system has. Same problem `osDependencies` solves for a
-plugin, wanting the same answer: the receiving platform refuses rather than pretends.
+Where a commander genuinely does need a secret of its own, the same rule applies for the obvious reason: a
+credential is definition-shaped — it looks like configuration — so excluding `state/` does not protect it,
+and a shared repository is exactly the artefact where one gets published and stays published. Name what
+must be configured; let the platform hold the value.
+
+**Whether the platform is actually configured is not this system's problem.** A commander depending on
+transcription can be armed on a server where nobody set up a Whisper endpoint, and it would produce
+nothing. That is a system administration mistake, and the answer is already in the commander skill rather
+than in new machinery: **do the first run by hand, then arm.** A first run against something unconfigured
+fails in front of the person doing it. The same rule catches the shared case — somebody forking this onto
+their own machine finds out on their first run instead of at 3am.
 
 The forking story then reads: clone, open a conversation, answer where your memos land and what you want
 done with them, and the commander rewrites its own parameters and arms.