Reference
Writes and Caching
Where ota may write, where it must stay read-only, and how caches stay safe.
referenceautomation buildersintermediatestable2026-05-30
Recommended next
When to use this page
Use this page when you need to know what ota may change on disk and what it must leave alone.
Mutations must stay explicit, and cache state should never outrank filesystem truth, so read-only review stays trustworthy.
- map each command to whether it reads or writes before you rely on its output
- use review-first commands and move to explicit write modes only after checking the preview
- merge commands only apply eligible additive changes, so review remains safe before write
- rewrite commands are destructive and require explicit confirmation
- policy-aware diagnosis stays read-only
- hidden mutation paths are not allowed
How writes work
ota should only write when the command explicitly says it can.
If the command is read-only, it should stay read-only even when it has enough information to suggest a change.
- repo detect and workspace detect are review-by-default; writes happen only with
--write,--merge, or--rewrite ota detect --writepersists the first conservative detect-write candidate when no contract existsota detect --write,--merge, and--rewritepreserve versioned pnpm/yarn-backed Node engine requirements as canonicaltoolchains.nodeownership plus deterministic Compose service wiring when those signals are high-confidenceota detect --mergeapplies only eligible additive fields after preview with--merge --dry-runota detect --rewrite --yesreplaces only after a--rewrite --dry-runreviewota workspace detectfollows the same pattern with--write,--merge, and--rewrite- init commands are explicit scaffold paths and may only write when you choose that mode
Writable commands
ota detect --writeota detect --mergeota detect --rewrite --yesota workspace detect --writeota workspace detect --mergeota workspace detect --rewrite --yesota initota workspace init
Read-only commands
- default
ota detect/ota workspace detectbehavior is read-only unless a write mode is selected ota detect --contractis text-only and does not writedoctorandpolicy reviewdo not mutate contractscheckdoes not mutate contractsworkspace doctorandworkspace checkstay read-only- policy-aware diagnosis stays read-only
How caching works
Caching is only an implementation detail for repeated reads.
It exists to avoid re-parsing and re-scanning when nothing meaningful changed.
- repo cache entries are keyed by normalized file path and content hash
- workspace cache entries use the same path+hash strategy for
ota.workspace.yaml - changed file contents invalidate cache keys on next read
- cache is for performance only and does not alter command semantics
- if the filesystem changes, ota must trust the filesystem over any cached copy
How to use it
- use review-only commands when you want to inspect first
- use merge when you want ota to apply only eligible additive changes
- use rewrite only when you want to replace the existing file explicitly
- use
doctorwhen you want to inspect readiness without writing - use
detect --dry-runwhen you want a safe preview of what would change - use the
Agent boundarysection in detect/init preview to understand whether ota inferred a usable agent lane, a partial boundary, or intentionally omittedagentbecause no safe task was inferred - treat external structured
AGENTS.md/CLAUDE.mdcommand sections and exactTask | Commandtables inside those sections as low-authority detect hints rather than canonical execution truth; ota-generated agent docs and broader prose stay out of detect evidence - use
detect --merge --dry-runandworkspace detect --merge --dry-runbefore additive writes - use
detect --rewrite --dry-runandworkspace detect --rewrite --dry-runbefore destructive replacement
Why it matters
- preview a contract change before writing it
- keep
detect --dry-runreview-only - know that
initwrites only when asked - avoid stale contract state
- trust that a cached parse never wins over the current file on disk
What this is not
- not a background sync engine
- not a persistent hidden state machine
- not a general-purpose cache policy surface
- not a replacement for the contract or filesystem truth
- not a place where stale state can outrank what is on disk