Workspaces

A workspace is a real folder on disk that PawOS has been pointed at — the boundary its file, terminal, and coding actions are scoped to for a given task.

PawOS does not maintain a hidden global filesystem boundary; each request that touches files or runs commands carries an explicit working directory (cwd), and workspace-security checks (CodingRuntimeSecurity) verify a requested path actually falls inside the declared workspace root before any write or command executes.

Product disclosure

This disclosure is part of the PawOS documentation for Workspaces. 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.