Documentation
Gates, guards, and stop rules
Choose verification gates and opt-in mechanical rules for an unattended engineering shift.
Answers: coding-agent gates and safety rules · Updated
Gates prove an item meets its declared project standard. Guards enforce owner-selected command, path, identity, and secret rules. 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 chosen boundaries
Optional hooks can deny command patterns, protected paths, unexpected Git identity, or configured secret patterns. They are off by default until the owner chooses them.
- Keep rules narrow enough to understand.
- Test the rules during an attended first run.
- Treat permissions and isolation as separate host controls.
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.
- No rule is imposed by default; the owner chooses the boundaries.
Evidence and sources
These links support the released behavior, public outcomes, or problem language described on this page.