Local first, main only
Edit in your IDE, push to main, Vercel deploys. Speed is the feature.
Local first, main only
Everything is developed on main. You edit locally, you see it locally, you
push, it is live. No branches, no review queue, no staging environment.
The loop
YOUR IDE PROD
┌────────────────────┐ ┌───────────────────────────┐
│ docs/be-*/*.md │ │ internal.beliefengines.io │
│ │ └───────────────────────────┘
│ npm run dev │ ▲
│ localhost:4321 │ git push main │
│ hot reload │ ────────────────────┘
└────────────────────┘ Vercel builds
▲ │
└───────┘
you see it before
anyone else does
Local rendering is the review step. Look at the page, then push it.
Why no branches
BRANCH + PR MAIN
edit ─▶ branch ─▶ PR edit ─▶ push ─▶ live
─▶ wait for review
─▶ address comments seconds
─▶ merge ─▶ live
hours to days
A branch is a queue. On a wiki the cost of a bad page is that someone reads
a bad page for ten minutes — then git log and it is gone. The cost of a
review gate is that every good page waits behind it.
We optimise for throughput of correct output, from employees and agents alike. The default is publish, then correct.
The safety net is git, not process
git log -- docs/<page>.md find the old version
git checkout <sha> -- docs/<page> bring it back
Nothing here is unrecoverable. That is what makes the speed safe — not carefulness, recoverability.
What this buys the agents
An agent that can commit and push without a prompt finishes the job in one turn. Every gate you add is a place it stops and waits for a human. The pre-approved allowlist in the harness exists for exactly this reason.
Where this does NOT apply
Engineering work still goes through a PR — see Handoff. Fast on docs, deliberate on code. The two rules are not in tension: one governs what we decide, the other governs what gets built.