Omar Baseline + Jules Deep Audit Workflow
Reference operating flow for the first production rollout: baseline gate first, Jules deep audit second, then staged expansion.
- cli
- omar
- jules
- workflow
- rollout
Recommended rollout sequence:
- Run baseline guardrails first
- `sl omargate deep --path .`
- address any P0/P1 blockers
- Run Jules deep frontend audit
- `sl audit frontend --path . --stream`
- capture artifact bundle from `.sentinelayer/audits/<run-id>`
- Reconcile with deterministic review
- `sl review --diff`
- Promote only after clean gate posture
Why this order
- baseline catches merge blockers quickly
- Jules deep audit adds domain depth without replacing baseline controls
- deterministic review artifacts keep handoff and reproducibility intact
What expands next
- backend/runtime audit lanes
- daemon-driven auto-routing and assignment controls
- full swarm runtime orchestration after staged validation
Structured Answers
Why not run all autonomous lanes immediately?
The staged approach reduces operational risk while proving Omar baseline + Jules depth quality first.
What evidence should teams keep for each run?
Keep the run report, findings JSON, event timeline, and any reviewer decisions under `.sentinelayer` artifacts.