Contract Authoring · Lesson 02 of 04
Agent-safe lanes
Declare which tasks agents may run, which paths they may write, and which steps must run after changes.
Learning objectives
- Add
safe_tasksandprotected_pathsto an agent block - Explain why
verify_after_changesmatters for agent safety - Describe what happens when an agent attempts a protected path
Prerequisites
Agent safety is an explicit contract decision. A task name, detector confidence, AGENTS.md instruction, or CI job does not grant execution authority. The selected task and its full closure must be agent-admitted.
Declare the executable and filesystem boundary
safe_tasks identifies routine task entrypoints. writable_paths and protected_paths describe repository editing boundaries, while verify_after_changes tells agents which declared verification to rerun after changes. Task effects must remain consistent with those paths.
agent: default_task: test safe_tasks: [test] verify_after_changes: [test] writable_paths: [src, tests] protected_paths: [ota.yaml, package-lock.json, .github/workflows]Guidance is not universal confinement
Ota enforces agent admission when execution enters through ota run --agent or ota up --agent. Contract path guidance alone cannot stop an unrestricted process from using raw shell. Strong runtime controls require an enforcing sandbox or another adopted chokepoint.
Canonical terminology
Evidence boundary for this lesson
Establishes
- The worked examples establish the lesson's canonical Ota distinctions for its stated scope.
Does not establish
- Reading the lesson does not validate a repository, execute its tasks, or establish organizational acceptance.
Knowledge check
Does listing test in agent.safe_tasks authorize an unsafe dependency of test?
No. Effective agent admission evaluates the complete selected closure; an unsafe dependency keeps the entrypoint unavailable to the agent.