Work Records
What a coding task’s Work Record actually contains.
A coding task’s Work Record includes real command evidence (exit code, real output), real file evidence (what changed), and real validation evidence (per-step pass/fail) — see Core Concepts → Work Records for the full model.
Partially implemented
Software-installation and PATH-repair steps within a coding task currently only appear in the record’s generic timeline, not as their own structured evidence type the way commands and file edits are — a known, disclosed gap, not an oversight left undocumented.
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.