PROP-006: Operating modes — codeword-triggered work postures
01Status: accepted 2026-05-06; the framework and its codewords were extracted to the operating-modes flow 2026-07-14 (reached via the redbook dependency). This entry is now a thin pointer.
Related: CLAUDE.md (the four rules + session-end codeword), PROP-000 (foundation).
02vibevm's codeword-triggered operating postures — the safety-first default, why a codeword is an explicit opt-in into an alternate posture for a work cycle, the activation lifecycle and reporting cadence, and the shape for writing a new codeword — are the operating-modes flow:
- 03Framework:
spec://org.vibevm.world/operating-modes/flows/operating-modes/OPERATING-MODES-PROTOCOL#root - Writing a new codeword:
spec://org.vibevm.world/operating-modes/flows/operating-modes/writing-a-codeword#root
04The codeword catalogue is surfaced at session boot by vibevm/vibespecs/boot/90-user.xml.
«move fast and break things»
05The pre-authorised heads-down execution codeword — aim at the maximum version of the deliverable, phase the work into testable iterations, begin without asking, drive to completion without confirmation handshakes, and spend whatever time / tokens / reasoning depth it takes (the owner's verbatim description is recorded in the flow) — is the operating-modes flow's spec://org.vibevm.world/operating-modes/flows/operating-modes/mfbt-mode#root.
- 06It suspends only Rule 4's "ask before routine large changes".
- The four non-negotiable rules survive unchanged.
- Rule 4's non-routine red lines — rewriting published history,
git push --force/--force-with-lease, large binary blobs, CI / signing / secrets changes, anything whose reversal would cost work — STILL require explicit owner confirmation even when the codeword is active.