Documentation
Gates, guards, and stop rules
Choose verification gates and opt-in safety rules for an unattended coding-agent shift, including the clock-out hook that refuses an early stop.
Updated
What do Nightshift’s gates and guards check during a shift?
Gates prove an item meets its declared project standard. Guards deny five elevation categories out of the box and enforce the command, path, identity, and secret rules the owner adds. Both are explicit and project-local; neither is a security sandbox.
Gates verify outcomes
Setup proposes stack-aware checks and asks before adding them. A gate might run tests, lint, types, or a project-specific command immediately before the item commit.
- No tooling is a supported path.
- A failed gate keeps the item open.
- Suppressions require a written reason.
- Human review still decides whether the result is good.
Guards enforce the boundaries
One guard ships switched on: sudo, containers, global package installs, daemons, and interactive service logins are denied during a shift unless the owner allows the category, permanently or for one night. Every other guard, command patterns, protected paths, expected Git identity, and secret patterns, stays empty until the owner writes it. Hooks read the rules file on every tool call, and the shift session is denied editing it.
- Elevation gates creating system state; reads like docker ps and brew list are not gated.
- Keep added rules narrow enough to understand, and test them during an attended first run.
- Treat host permissions and isolation as separate controls the guards never replace.
Stop always wins
Use the host Stop command or create .nightshift/STOP. The shift clocks out orderly and leaves unfinished boxes open rather than pretending they were completed.
touch .nightshift/STOPStart with a bounded prompt
This prompt names the outcome and preserves Nightshift’s review boundary. Paste it into the supported coding host from the project you want to change.
Inspect this project and propose the smallest useful item gate and owner-defined guards. Do not enable any rule until I approve it.What this workflow does not claim
- Guards are pattern-based controls, not a security sandbox or adversarial containment system.
- Five elevation categories ship denied; every other guard stays empty until the owner sets it.
Evidence and sources
These links support the released behavior, public outcomes, or problem language described on this page.