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:

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:

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.