How it works

The loop has five steps: describe, validate, render, sync and check. Here is each one, with the command that does it.

Step 1
Describe
`wl init` writes a workloom.workspace.json template (it refuses to overwrite one unless you pass --force). Fill in the binding, the targets, and each target’s providers and packages.
Step 2
Validate
`wl validate workloom.workspace.json` checks the manifest against the schema, then reports trust gate diagnostics: denied hooks and MCP servers, and assets whose trust class exceeds the workspace maximum.
Step 3
Render
`wl render -w workloom.workspace.json --dry-run` prints the render plan per target and provider: path, projection policy, ownership and write mode. Nothing touches disk.
Step 4
Sync
`wl sync -w workloom.workspace.json` writes the projections the trust gate allows and records the drift baseline. Committed projections need a local approval first: `wl sync --approve-local`.
Step 5
Check
`wl sync --check` compares disk with the drift baseline, writes nothing and exits non-zero on drift, so CI can run it on every pull request. `wl restore` puts drifted Workloom-owned files back.

Stop hand-editing four config files per repository

Keep one workspace manifest per repository, render it for every provider your team uses, and let CI tell you when a projection drifts.