First Coding Task

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.

Product disclosure

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

• The desktop application, companion surface, task card, workspace picker, account and billing surfaces, confirmation prompts, and Working History.
• Documentation pages explain the product path, but the operational product is the local Electron app running on the user machine.
• A new user normally sees sign-in, workspace selection, model/provider configuration where needed, and permission prompts only when a requested action needs them.

What PawOS does

• PawOS turns a user request into a task, records the task timeline, and routes read-only analysis separately from execution-class actions.
• When the task is about files or code, PawOS uses the selected workspace folder as the normal project boundary.
• For coding tasks, PawOS can inspect project structure, plan work, request approval, apply patches, run commands, validate results, and report evidence.

Permissions and boundaries

• Starting PawOS, signing in, or reading documentation does not grant blanket permission to edit files, run commands, install tools, change PATH, use connectors, or deploy software.
• Plan approval and action authorization are separate events. A plan can be accepted while later destructive actions still require their own confirmation.
• Subscription entitlements determine whether a request can move from read-only analysis into execution.

Evidence and records

• A completed task should leave a Work Record containing the real actions that ran, outputs, files changed, validation results, failures, and skipped steps.
• If an action was not run or could not be verified, the docs and Work Record should describe that limitation instead of implying success.

Limitations and user responsibility

• Public installer and update availability may vary by platform and release channel; use the Download page as the source of current distribution status.
• Some advanced project-understanding features are strongest for TypeScript and JavaScript projects and may be thinner for other languages.
• Local machine permissions, missing dependencies, organization policy, connector scopes, or subscription tier can prevent an otherwise valid request from executing.