# Run Artifacts
`projects/runs/` is the canonical repo-local run-artifact area for this workflow.
Use it for per-run workspaces only. It is not a reusable project pack, it is not neutral workflow canon, and it must never be selected as `projects/<selected-project>/`.
## One run, one subdirectory
Each execution should use its own dedicated run root under:
```text
projects/runs/<run-id>/
```
Choose a unique `<run-id>` for every run so artifacts from different executions stay segregated. Do not reuse one run directory for multiple independent runs, and do not write per-run output back into `projects/<selected-project>/`.
## Expected per-run layout
Within each `projects/runs/<run-id>/` directory, keep the existing workflow split explicit:
```text
projects/runs/<run-id>/
├── public/
├── evidence/
├── gates/
└── logs/ # optional
```
- `public/` holds public deliverables only, including generated drafts, rendered public output, and any public manifest.
- `evidence/` holds internal proof-chain artifacts only, such as run briefs, source maps, claim ledgers, validation packets, review packets, and evidence manifests.
- `gates/` holds gate and status artifacts for the run: PASS/FAIL records, rerun boundaries, checkpoint summaries, and similar stage-status files.
- `logs/` is optional and holds harness-local execution notes or raw logs that are not public deliverables.
## Placement rules
- Reusable pack inputs live under `projects/<name>/`.
- Per-run outputs and intermediate artifacts live under `projects/runs/<run-id>/`.
- Keep the public/evidence split inside every run directory; do not collapse them into one mixed artifact area.
- Treat run directories as run-owned workspaces: stages may create, overwrite, and retain files there without changing reusable pack content.
## Rule of thumb
If a file helps define what a project is, it belongs in a reusable project pack.
If a file was generated or collected for one specific execution, it belongs under that run's `projects/runs/<run-id>/` directory.