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, proposeCodeEditPlan returns a structured ExecutionPlan with one planned applyCodeEdit 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.

Product disclosure

This disclosure is part of the PawOS documentation for Coding Overview. 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 Coding Workspace, Task Card, Plan Review card, affected files, status pills, proposed changes, permission summary, command output, diff surfaces, validation results, preview state, and final Work Record.
• For multi-file work, users should see the plan title, scope summary, per-step rationale, affected area, proposed diff when hunk data exists, and Approve, Reject, and Revise controls.
• During execution, users may also see terminal output, running processes, build/test evidence, browser preview state, screenshots, and real file-change summaries.

What PawOS does

• PawOS may inspect project structure, dependencies, import graphs, feature groupings, domain concepts, affected files, and coding memory before proposing work.
• Code edits use structured action requests such as applyCodeEdit and writeFile; applyCodeEdit uses context-anchored hunks against current on-disk content.
• Validation can include syntax checks, import checks, typecheck, lint, build, tests, process health, browser console/network checks, and visual evidence when those tools are available.

Permissions and boundaries

• Plan approval records intent only. It does not bypass applyCodeEdit confirmation, writeFile overwrite checks, command confirmation, git write confirmation, install confirmation, PATH/system confirmation, connector authorization, or deploy authorization.
• Commands are governed by allowlists and execution rules; PawOS is not a raw arbitrary shell.
• A generated diff is only authoritative when it comes from actual hunk data or a real git/file diff. The UI must not invent a diff for a step that has no patch.

Evidence and records

• A real coding completion should show file paths, changed content or diff stats, commands executed, exit codes, relevant output, validation results, and any screenshots or browser evidence used to confirm UI behavior.
• If validation was skipped because a script or config was absent, that skipped state should be disclosed.
• If a plan was rejected, there should be no planned mutation from that rejected plan.

Limitations and user responsibility

• Live Plan Review visual QA, real Pro/Pro Max account execution, and plan-to-execution lifecycle visualization may require an eligible running app/account environment.
• Some non-TypeScript projects remain editable but may not receive the same deep structural analysis as TypeScript/JavaScript projects.
• Whole-file writes can describe intended content, while fine-grained View Changes requires concrete patch hunk data or an actual diff source.