GET /api/work/agent-fleet/tooling
The guardrails, extracted
Live · · sole engineer
The safety system I describe in the fleet write-up, pulled out on its own and stripped of everything company-specific — the actual traffic-cop code, cleaned up and published.The session-lock layer, fleet scripts, context tooling and review-agent configs behind the fleet write-up, lifted out of the private repo and sanitized.
- Node.js
- Git hooks
- Claude Code
- Shell
- launchd
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ agent-fleet/ tooling"
Response200 OK · 2.8 KB
{ "id": "agent-fleet/tooling", "title": "The guardrails, extracted", "status": "live", "year": 2026, "category": "work", "role": "sole engineer", "summary": "The session-lock layer, fleet scripts, context tooling and review-agent configs behind the fleet write-up, lifted out of the private repo and sanitized.", "summary_plain": "The safety system I describe in the fleet write-up, pulled out on its own and stripped of everything company-specific — the actual traffic-cop code, cleaned up and published.", "stack": [ "Node.js", "Git hooks", "Claude Code", "Shell", "launchd" ], "links": { "source": "https://github.com/Dylansg318/Portfolio/tree/main/code" }, "parent": { "id": "agent-fleet", "title": "Running a dozen AI coding sessions on one repo", "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet" }, "problem": "The fleet write-up makes claims: hooks that block dangerous git operations, a lock on the shared index, review triggered by consequence. Claims about guardrails are cheap. And the problem isn't niche any more; anyone running several coding agents against one repository hits the same failure modes, usually without noticing until a commit sweeps in someone else's staged files. The proof is the code.", "unique": "The lock is keyed on the real index path (git rev-parse --git-path index), the file that's actually shared, so worktrees, which have their own index, never block each other, and the lock serializes exactly the sessions that can hurt each other. Stale locks get stolen by PID liveness and TTL, so the coordinator can't deadlock the thing it coordinates. And every guard fails open: a crashed hook exits clean, because a safety layer that can take the fleet down is a worse hazard than the ones it guards against.", "ai": "Agents write most of the code these hooks police, and agents did the extraction too, each with a hard deny-list contract, audited by me and a second-model review before commit. Backing the parent write-up's claims with the actual mechanism is the point of this page.", "learned": [ "Lock the resource, not the concept. \"One session per repo\" would've serialized work that can't conflict; locking the physical index file encodes the sharing boundary exactly and leaves the parallelism free.", "A guard that fails closed becomes the outage. The first draft blocked on its own errors; the rewrite treats guard failure as a no-op and logs it, and that decision is written at every exit path.", "Getting ready to publish forces clean architecture. The mechanism sanitized in an afternoon; the embedded rule text took the longest, and the tangle of policy and mechanism it showed was worth knowing about anyway." ], "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet/tooling" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.
The problem
The fleet write-up makes claims: hooks that block dangerous git operations, a lock on the shared index, review triggered by consequence. Claims about guardrails are cheap. And the problem isn't niche any more; anyone running several coding agents against one repository hits the same failure modes, usually without noticing until a commit sweeps in someone else's staged files. The proof is the code.
What was unique
The lock is keyed on the real index path (git rev-parse --git-path index), the file that's actually shared, so worktrees, which have their own index, never block each other, and the lock serializes exactly the sessions that can hurt each other. Stale locks get stolen by PID liveness and TTL, so the coordinator can't deadlock the thing it coordinates. And every guard fails open: a crashed hook exits clean, because a safety layer that can take the fleet down is a worse hazard than the ones it guards against.
Where AI fit in
Agents write most of the code these hooks police, and agents did the extraction too, each with a hard deny-list contract, audited by me and a second-model review before commit. Backing the parent write-up's claims with the actual mechanism is the point of this page.
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ agent-fleet/ tooling? fields=problem%2Cunique%2Cai"
Response200 OK · 1.3 KB
{ "problem": "The fleet write-up makes claims: hooks that block dangerous git operations, a lock on the shared index, review triggered by consequence. Claims about guardrails are cheap. And the problem isn't niche any more; anyone running several coding agents against one repository hits the same failure modes, usually without noticing until a commit sweeps in someone else's staged files. The proof is the code.", "unique": "The lock is keyed on the real index path (git rev-parse --git-path index), the file that's actually shared, so worktrees, which have their own index, never block each other, and the lock serializes exactly the sessions that can hurt each other. Stale locks get stolen by PID liveness and TTL, so the coordinator can't deadlock the thing it coordinates. And every guard fails open: a crashed hook exits clean, because a safety layer that can take the fleet down is a worse hazard than the ones it guards against.", "ai": "Agents write most of the code these hooks police, and agents did the extraction too, each with a hard deny-list contract, audited by me and a second-model review before commit. Backing the parent write-up's claims with the actual mechanism is the point of this page.", "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet/tooling" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.
What’s here
Four pieces of the safety system, lifted out on their own and cleaned up. The traffic cop that stops two AI helpers tripping over each other when they share one workspace. The scripts that open a separate workspace per helper and later check that no finished work got left behind unmerged. The tooling that keeps each helper’s long-term memory index honest. And the written playbooks that decide when work gets a second opinion before it runs, based on what a mistake would cost, never on how big the change looks.
Nothing company-specific survived the trip: the rules the guards enforce were rewritten
as generic examples, and every path, name and address is a stand-in. The code sits in
the code/ folder of this site’s own repository, open to anyone.
The pieces
All four live under code/
in this site’s repository, with their tests and the reasoning kept in the comments:
- session-lock — the coordination layer: O_EXCL atomic locks on the shared git index, PID-liveness + TTL steal, reentrancy by session id, a cross-session broadcast inbox, and the guard hooks that block
git add -A,commit -a,--no-verifyand full-tree test runs. Every path fails open, on purpose, and the comments argue each failure mode. - fleet-scripts — spawn one terminal tab per work slice (each agent briefed, in its own worktree), reap sessions by liveness and merge state, and audit worktrees for finished-but-unmerged work, including the
git diff A...Bthree-dot trap that once let finished features rot for five weeks. - ai-context-tools — the memory index as a generated artifact (frontmatter in, index out, a check mode that fails CI on drift), and a read-only SQLite-graph visualizer that renders module architecture as one interactive map.
- agent-configs — the transferable core of consequence-triggered, cross-model review, plus the change-record planning format that replaced 900-line implementation plans with a 60–90-line decision ledger.
The reviewer has to be a different model than the writer. Two passes by the same model share the same blind spots, so the configs pair every session model with a reviewer from a different family and treat a rubber-stamp result as a failed review.
What I learned
- Lock the resource, not the concept. "One session per repo" would've serialized work that can't conflict; locking the physical index file encodes the sharing boundary exactly and leaves the parallelism free.
- A guard that fails closed becomes the outage. The first draft blocked on its own errors; the rewrite treats guard failure as a no-op and logs it, and that decision is written at every exit path.
- Getting ready to publish forces clean architecture. The mechanism sanitized in an afternoon; the embedded rule text took the longest, and the tangle of policy and mechanism it showed was worth knowing about anyway.
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ agent-fleet/ tooling? fields=learned"
Response200 OK · 745 B
{ "learned": [ "Lock the resource, not the concept. \"One session per repo\" would've serialized work that can't conflict; locking the physical index file encodes the sharing boundary exactly and leaves the parallelism free.", "A guard that fails closed becomes the outage. The first draft blocked on its own errors; the rewrite treats guard failure as a no-op and logs it, and that decision is written at every exit path.", "Getting ready to publish forces clean architecture. The mechanism sanitized in an afternoon; the embedded rule text took the longest, and the tangle of policy and mechanism it showed was worth knowing about anyway." ], "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet/tooling" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.