PUDO treats context as an engineering artifact. The goal is not to give the AI more text; the goal is to give it the right evidence before implementation.
Use this format before non-trivial coding work:
# Context Pack
## Task
What needs to change.
## Current Phase
Plan / Understand / Develop / Optimize
## Relevant Files
- `path/to/file`: why it matters
## Verified Facts
- Fact backed by source inspection
## Assumptions
- Assumption that still needs confirmation
## Constraints
- Technical, product, security, release, or time constraints
## Edge Cases
- Edge cases that must be handled or explicitly deferred
## Verification
- Commands or manual checks that prove the change
Include only files that help decide what to change or how to verify it:
Avoid including:
Before asking for implementation, require evidence:
Before coding, inspect the relevant files and report:
1. Files read
2. Existing patterns found
3. APIs or contracts verified
4. Assumptions still open
5. Smallest safe implementation path
Do not accept implementation that depends on unverified paths, APIs, env vars, database columns, or package behavior.
For larger tasks, create a compact repo map:
## Repo Map
| Area | Files | Why It Matters |
|---|---|---|
| Routing | `...` | Request entrypoint |
| Data | `...` | Persistence and migration risk |
| UI | `...` | User-facing state |
| Tests | `...` | Verification path |
| Config | `...` | Runtime behavior |
Stop expanding context once the implementation path is clear.
For work that crosses sessions or tools, update .pudo/session.md with inspected files, decisions, tests run, remaining risks, and next action.