5161304f12cef007a55f18532b4194c34f5ac7ee
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  pastilhasandClaude Opus 5
|
5161304f12 |
the commander rules are general; deploying is an instance of them
The rules had leaked toward the one commander that exists. Audited by grepping the commander skill for deploy vocabulary rather than by rereading it, which found five places where a general rule was written in terms of the specific job it came from: - the baseline rule's headline example was "watch for a new tag" — the one case, standing in for all of them. Now "watch for new X, whatever X is: a tag, a file in a folder, a row, an unread message, an alert". - the loop "cannot weigh a host" → cannot weigh a situation. - OFFICER_ROOT being empty "makes every release look permanently undeployed" → makes anything the loop writes to record its own progress land where nothing reads it, so a watcher has no baseline and acts on the same work for ever. Same defect, stated as what it costs any watcher. - "a procedure in a file makes the deploy repeatable next month" → makes the same job repeatable, and reviewable by somebody else. - the local-address rule was fleet-specific AND duplicated what the deploy skill already says. Generalised to "reach what you are watching by the shortest path available", with the Officer-specific instance left where it belongs. The cross-reference now names the Deploying Officer SKILL rather than a file path, because a skill has a description in the index and a file path has to be known about first. What the audit was checking: a user describing something that has nothing to do with releases must get the same rules — baseline, claim once, ask before arming if the condition is not clear, spawn for judgement, say what you did not do. Those were always general. The examples around them were not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
57eaf603a0 |
a watcher needs a baseline, and the deploy procedure needs to be findable
Two gaps found by testing the actual goal — "I say watch master for a new tag, and it works without me listing the caveats" — rather than by rereading what was written. THE BASELINE. The commander skill had "what must never happen twice", which is a CLAIM: do not act twice on the same item. The owner's constraint is different and was missing entirely: do not act on items that already existed when you were armed. "Watch for a new tag" is not a condition — a watcher armed today sees every historical tag and, unless something says otherwise, treats all of them as news and acts on each in turn. Nobody says "ignore the ones already there" because to a person it is obviously implied. It is not implied to a shell loop. So the skill now names the two honest kinds of baseline — a record of what has been handled, which survives a restart, or a snapshot taken at arming, which does not — and requires the loop to say which it is using. On this machine the lock files made the omission harmless. On a fresh one, a new commander would have deployed every tag in the history, one at a time. FINDABILITY. The deploy procedure was reachable only through a sentence at the end of the commander skill, so an agent asked to deploy would have to open one skill and read to its last line to learn the other existed. It has a description of its own now, which is the entire interface: the agent sees only that before deciding to open anything. The new skill does NOT copy the procedure. It names `scripts/deploy-claim.sh`, `docs/servers.md` and the plan format, which live with the code and change with it — a second copy would be right the day it was written and wrong the day somebody edits the first, and the copy an agent happened to read would be the stale one. One hop costs a Read; a wrong procedure costs a fleet. What it does carry is the fleet-specific part that would not belong in a procedure: poll a local remote and why (a tag pushed at 21:47 noticed at 23:07 through the public one, twenty seconds through the local), pm_cwd rather than a hard-coded path, the per-host login, plugins:update restarting sidecars on its own, and that a skipped host is either behind or current — different things, and only one of them asks the owner for anything. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
5592d31867 |
the commander skill was missing four mechanics, three of them expensive
Audited it against what the background-job dialog actually sends and against the deploy procedure, rather than trusting that it was complete. It carried the concepts and five of the nine mechanics. Four were absent, and three had cost real time to discover: - OFFICER_ROOT is EMPTY in the sidecar's environment, so a path built from it resolves to /data/... — a lock lands where nothing reads it and every release looks permanently undeployed. - stderr must be kept out of a --output-format=stream-json pipe. The CLI prints warnings there and one of them corrupts the first jq parse. - jq --unbuffered, or the job panel shows nothing for the duration and reads as hung. A background job with no output is indistinguishable from a dead one. - The claim goes before the SPAWN, not inside the action: an action that dies before claiming has claimed nothing and runs again. Also added the one instruction the dialog sends that the skill had dropped, and it is the most important of them: ASK before arming if the condition is not completely clear. A wrong condition fails silently — it either never fires or fires constantly — and is found out days later. Arming late costs a minute. The audit is the point. A skill that covers the concepts and misses the mechanics reads as complete and produces a loop that does not work, which is the failure mode a reference is supposed to prevent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7c453d57ae |
two skills: the platform, and commanders
An agent answering "what is a commander, how do I start one" had nothing to answer from. skills/load.ts already compiles an index of name + when-to-reach-for-it + path into every session, with the body read on demand — so this needed skills written, not a mechanism built. There was one skill before these; now three. skills/platform/SKILL.md is GENERATED by the platform repository's `bun run skills:platform`, and its `docs:check` fails if it drifts. Do not edit it here — an edit is lost on the next run, and the generator carries the prose for exactly that reason. skills/commander/SKILL.md is written by hand, because none of it is derivable. What is in it is what three days of running one taught, including the parts that surprised us: - A commander is an ordinary chat session in a particular directory. Not a special agent — a conversation plus a loop somebody started from inside it. - Three pieces, and people get the third wrong: the conversation, the shell loop that waits, and the HEADLESS AGENT the loop spawns when it fires. They expect the commander itself to wake up. It does not. - Its cost line understates, structurally: only turns crossing the platform's chat socket are recorded, and a spawned agent's never do. A commander that spent dollars through children can display cents. - A spawned agent cannot be linked to its parent after the fact. The entry types that look like they mark one are the harness's own and appear in both. If the link matters, the loop must record the id itself. - Poll a local address, never a public hostname behind a reverse proxy — rate limiting there reads as an access-rights error and is not one. - The platform may not know a watcher exists: its bookkeeping engages only for the hand-back-and-re-arm fire behaviour, so a working loop can sit beside a row that says unarmed. The largest section is about helping somebody SHAPE one, since that is the part that is a conversation rather than a form. Four questions, and the third is the one nobody volunteers: what must never happen twice. A trigger that stays true after a failed action fires again, and again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |