Skip to content
PawOS Docs

First Coding Task

Running your first real, execution-gated coding request.

Reading and planning are available on every tier. Actually editing files, running commands, or installing tools requires the advancedRuntimes entitlement — Paw Pro or higher.

  1. 1

    Open a workspace

    Select the project folder that contains the application.

  2. 2

    Ask for the change

    Example: "Add dark mode to my application."

  3. 3

    Project understanding

    PawOS inspects project structure, dependencies, routes/components, affected files, and existing style/theme conventions when supported.

  4. 4

    Plan

    For a multi-file change, PawOS prepares a structured plan before mutation.

  5. 5

    Visual plan review

    Review files affected, each file rationale, proposed hunk diffs, and estimated scope. Approve or reject the plan.

  6. 6

    Authorization

    After plan approval, actual edits, commands, git writes, or installs still use the existing confirmation gate.

  7. 7

    Code editing

    PawOS applies hunk-based patches against current on-disk files.

  8. 8

    Diff and validation

    Inspect changed files, run tests/build/typecheck/lint where available, and review failures or skipped steps.

  9. 9

    Live preview

    If the app can run locally, PawOS can start or use a dev server, check readiness, and capture a browser preview screenshot.

  10. 10

    Browser verification

    For UI work, screenshots, console output, network errors, and visual verification results can become evidence.

  11. 11

    Final Work Record

    The task closes with exactly what changed, what passed, what failed, what was not verified, and what remains.

Note

On Paw Go, the same request is answered as analysis/a suggested diff, not applied — PawOS tells you explicitly that execution requires an upgrade rather than silently doing less than asked.

How it works

What you see

  • The PawOS desktop app: your companion, the conversation panel, task progress, workspace selection, account and billing screens, and permission questions when an action needs them.
  • After signing in you choose a workspace folder, and PawOS asks before it does anything that changes your machine.

What PawOS does

  • PawOS turns each request into a task and keeps a record of what happens.
  • For files and code, the workspace folder you picked is the project boundary.
  • For coding work, PawOS can inspect your project, plan changes, apply them, run commands and tests, and report the results.

Permissions

  • Signing in does not give PawOS blanket permission: editing files, running commands, installing tools, connecting accounts or deploying each ask for approval.
  • Approving a plan and approving an action are separate — a plan can be approved while later actions still ask first.
  • Your plan determines which kinds of work PawOS can carry out.

Records

  • Every completed task leaves a Work Record: the actions that ran, their output, files changed, and test results.

Good to know

  • Project analysis is deepest for TypeScript and JavaScript projects; other languages are fully editable.
  • Local permissions, missing dependencies, organization policy or your plan can stop a request from running — PawOS tells you which.

Related