Coding Overview

The Coding Runtime lets PawOS understand a real project, propose and apply multi-file edits as real patches, run a project through its own real build/test/lint pipeline, and self-heal a bounded number of times when validation fails.

It is a horizontal extension of PawOS’s general execution engine, not a separate product — the same confirmation gate, the same Work Record evidence, and the same tier ladder apply here as everywhere else.

What it does well

• Multi-file edits are applied as real hunk-based patches, not blind whole-file rewrites.
• A real validation pipeline runs syntax → imports → typecheck → lint → build → tests, with a bounded (3-attempt) automatic self-heal retry on failure.
• Edit history, architectural decisions, and stated preferences persist across sessions in a queryable memory graph, not just chat scrollback.

Real boundaries

Coding lifecycle

1. 1

   Request

   You describe the outcome. PawOS decides which project facts, files, tools, and validation steps are relevant.

2. 2

   Understand

   The runtime inspects the workspace, project structure, dependency graph, feature map, domain concepts, and likely affected files where supported.

3. 3

   Plan

   For multi-file edits, PawOS prepares a plan with one step per affected file.

4. 4

   Review

   The Plan Review card shows files affected, estimated line scope, per-file rationale, affected area, and proposed hunk diff where available.

5. 5

   Authorize

   Plan approval records intent. Actual edits and commands remain governed by the existing confirmation mechanism.

6. 6

   Edit

   Edits are applied as context-anchored hunks against current on-disk content, not blind whole-file rewrites.

7. 7

   Validate

   PawOS can run syntax, imports, typecheck, lint, build, and tests, reporting skipped steps honestly when a project lacks the script or config.

8. 8

   Preview and verify

   UI work can produce browser screenshots, console output, network evidence, and visual verification when invoked.

9. 9

   Evidence

   The Work Record keeps the action timeline, outputs, file changes, validation results, screenshots, failures, retries, and final report.

How it works

What you see

• Your task progress, plan review with affected files and proposed changes, permission questions, command output, diffs, test results, previews and the final Work Record.
• For multi-file work you see the plan, why each step is needed, and Approve, Reject and Revise controls.
• While work runs you can follow terminal output, running processes, build and test results, and preview screenshots.

What PawOS does

• PawOS reads your project structure, dependencies and related files before proposing changes.
• Edits are applied precisely against the current file contents.
• Checks can include syntax, imports, type checking, linting, builds, tests, running-app health and visual checks, depending on your project.

Permissions

• Approving a plan records your intent; each edit, overwrite, command, git change, install, system change, connection or deploy still asks for approval.
• Commands run under clear rules — PawOS is not an unrestricted shell.
• Diffs you see come from the real changes, never an illustration.

Records

• Finished coding work shows the files changed, commands run, their results and output, test results, and screenshots when the change is visual.
• If a check was skipped (for example, the project has no test script), the Work Record says so.
• A rejected plan makes no changes.

Good to know

• Deep project analysis is strongest for TypeScript and JavaScript; every language can be edited.