Plans
How PawOS proposes multi-step work before executing it.
For non-trivial coding requests, PawOS can propose a concrete, file-by-file edit plan before applying anything — review before mutation, not mutation with a narration after the fact.
A plan is a real, structured list of steps (one per affected file), not free text. Structured plans render in the Task Card as a visual Plan Review surface with approve/reject controls and expandable per-file details.
Visual Plan Review is implemented at plan level. Approval/rejection is submitted back into the normal conversation, and actual code edits still require the existing applyCodeEdit/writeFile confirmation. Hunk-level approval is not implemented.
| Concept | Meaning |
|---|---|
| Plan proposed | proposeCodeEditPlan or proposeExecutionPlan returned an ExecutionPlan. No mutation happened. |
| Plan approved | The user approved the plan-level scope through the Plan Review UI or conversation. |
| Code edit authorized | A specific applyCodeEdit/writeFile action passed the existing confirmation gate and may mutate files. |
| Plan rejected | The proposed mutations must not execute; the conversation remains available for revision. |
Product disclosure
This page documents the current PawOS behavior for Plans. It is intended to disclose what users can see and use, what permissions are required, what evidence is recorded, and what limitations remain.
This disclosure is part of the PawOS documentation for Plans. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.
What users see
- Concepts appear in the product as workspaces, tasks, task cards, plan review cards, confirmation prompts, Work Records, usage meters, and connector status.
- Users interact with concepts through normal requests rather than through an abstract configuration console.
- The same vocabulary appears in documentation, billing, security, and troubleshooting so a user can trace what happened after a task finishes.
What PawOS does
- A workspace scopes file and command work; a task groups one user request; a plan proposes future work; an action performs one concrete operation; evidence records what actually happened.
- The renderer displays task state, while the main process owns execution and security-sensitive checks.
- Execution records are assembled from real action request/result data rather than a free-form after-the-fact summary alone.
Permissions and boundaries
- Concept names are not permissions. Calling something a workspace, plan, or task does not remove confirmation gates.
- PawOS can reason about a requested outcome, but the model does not directly mutate the user machine; deterministic action handlers do.
- Entitlement gates and confirmation gates are separate protections and may both apply to the same request.
Evidence and records
- Evidence should identify the command, file, connector, validation step, screenshot, or result that supports a claim.
- A Work Record can honestly show partial success, skipped validation, a rejected plan, a failed command, or a blocked permission request.
Limitations and user responsibility
- Not every runtime emits the same richness of structured evidence yet; generic timelines remain the fallback where specialized evidence is not implemented.
- Plan state after approval depends on the existing conversation and execution handoff and should not be interpreted as a full lifecycle engine unless step transitions are recorded.
Warning
PawOS can assist with planning, coding, automation, connectors, billing flows, and system operations, but the user remains responsible for reviewing plans, confirmations, diffs, command effects, connector side effects, billing actions, and final outputs before relying on them.