Four ranks, one shared floor.
Vinculum’s worker hierarchy has four ranks, and each one is functional, not decorative. A Colonel orchestrates a session, running the most capable model available and persisting for as long as the session runs. A Lieutenant takes a batch of work from the Colonel, breaks it into individual directives, and fans out the workers under it. A Sergeant and a Private are the two ranks that actually touch files. They hold identical permissions; the only difference between them is which model tier does the reasoning.
Rank decides who assigns work and who breaks it down. It does not decide what a worker is allowed to do to a filesystem or a shell. That line is drawn separately, and it applies to every rank the same way: the deny floor.
The floor every rank inherits, no exceptions.
A deny floor is the set of actions a worker is refused, full stop, regardless of trust profile, rank, or which operating mode the session is running under. Writing a git commit, reading a credential file, running sudo, deleting the filesystem outright: none of that is a judgment call left to a Private or a Sergeant. It’s refused before the worker gets a chance to try, whether the task is mechanical cleanup or work that needed a Sergeant’s reasoning, and whether the session is running supervised, where a human approves before an action lands, or fast, where it doesn’t wait.
That promise held only in supervised mode. #13168 recorded the gap: switching a session to fast mode silently dropped 41 of the 46 deny patterns the bootstrap text swears are enforced. The credential guards, the sudo guard, the rm -rf / guard, and the git guards were all present in supervised mode and mostly gone the moment a session ran without a human approving each step. What actually held under fast mode was 5 patterns out of 46.
The gap, and the fix that closed it.
#13168 is the finding, filed after a session checked what its own fast-mode guardrails actually enforced instead of trusting what the bootstrap text claimed. It found human_loop_mode=‘fast’ carrying 5 of the 46 deny patterns supervised mode carries. The credential guards, the sudo guard, the rm -rf / guard, and the git guards the bootstrap text swears are always on were the ones silently dropped.
#13341 is the fix, and it went further than patching the mode bug. It rebuilt the deny floor itself, the baseline set of actions a Sergeant or Private is denied regardless of trust profile, taking it from 20 patterns to 49. Credential guards and the two destructive-command guards (sudo:* and rm -rf /*) were already solid. What got added: the rest of the git-write surface (git rebase closed the last gap, bringing git guards to 13 patterns), the full package-manager surface (24 patterns covering apt, brew, bun, cargo, gem, go, npm, pip, pnpm, poetry, uv, yarn), and piped execution into a shell (4 patterns, curl and wget piped into bash or sh). Net new: 29 patterns.
None of it shipped on the strength of a description. 83 of 83 tests passed: 47 new parametrized cases covering the added pattern classes, and all 36 pre-existing floor tests still green with zero regressions.
| What was measured | The number |
|---|---|
| deny patterns fast mode actually enforced | 5 of 46 |
| deny floor before the fix | 20 patterns |
| deny floor after the fix | 49 patterns |
| net new patterns added | 29 — git-write (1), package managers (24), piped execution (4) |
| tests proving it | 83 of 83 passing (47 new, 36 pre-existing, zero regressions) |
| source | Vinculum substrate entries #13168, #13341 |
Common questions.
What can a worker never do, no matter which mode it runs under?
Everything on the deny floor: writing a git commit, reading a credential file, running sudo, deleting the filesystem outright, plus the full git-write and package-manager surface. 49 patterns, all refused before a Sergeant or Private gets a chance to try. See the receipt below for exactly what’s in that set and how it got there (#13341).
What's the difference between supervised and fast mode?
Supervised mode holds a worker’s action for a human to approve before it lands. Fast mode lets the worker move without waiting on that approval. Both modes are supposed to run under the identical deny floor. The difference between them is who signs off on the actions the floor still allows, not which actions the floor blocks.
How was the #13168 gap found in the first place?
A session checked its own fast-mode enforcement against what the bootstrap text promised, and found the gap that way, not from an external audit or a user report. #13341 closed it under the same habit: reading what the code actually does instead of what the documentation says it does.