Build workflow
Branch-per-task, git worktrees, test gating, mutation audits, and no push without approval.
How work actually lands in the Conclave codebase. It's deliberately conservative — the trust story means a broken merge is expensive.
One branch (and worktree) per task
- Work on a single
feat/<slug>branch per task, per repo — usually in a dedicated git worktree so several tasks proceed in parallel without stepping on each other. - The plan for a task lives in
task-plan/TASK-<id>-<slug>.md. Build the flagged master list first, deepen one task at a time, then implement.
The merge gate
A change reaches main only when all of these hold:
- Full test suite is green. Every commit is test-gated; no merge on red.
- An independent mutation audit passed — a separate agent breaks each load-bearing behavior and confirms a test goes red, so the tests actually defend the behavior.
- Explicit human approval. Plan approval is not implementation approval; a green build is not a merge. Wait for the go-ahead.
Pushes are human-run
Many features are merged to a local main but not pushed — that's why Status
distinguishes built · merged local from shipped. Don't assume main is on origin; git fetch
before reasoning about ahead/behind.
Deploys
Never re-provision a CVM (it wipes the sealed volume). Deploy in place with phala deploy --cvm-id.
Bump the literal image tag every time. Full recipe: Deployment and
DEPLOYMENT-GUIDE.md.
When writing docs here
Match Writing docs: document only what's implemented, badge status
honestly, cite the source, keep npm run build green.