Compile and Project Repository Context
How one neutral context plan becomes truthful harness-specific output
Historical (retired in CLI 6.0.0). This page describes the manifest-driven lifecycle. The Registry Baseline replaced it: see Scaffold Baseline and the CLI scaffolding runbook.
Harness Intelligence compiles repository meaning once, persists it as a neutral context plan, and projects that same plan into each supported AI harness.
The flow begins after setup has discovered the repository and resolved its final pack selection. The compiler owns semantic context. Adapters own harness capabilities and native targets. The filesystem application layer owns writes. Keeping those boundaries separate prevents a target path or harness-specific compromise from becoming repository truth.
Trigger
hi scaffold enters this flow after repository discovery and final pack resolution. Discovery includes the prospective wiki scope when scaffolding will create one, so the plan describes the repository that the command is about to materialize rather than only the files that existed before it ran.
Flow
- Repository discovery identifies scopes and the selected packs for each scope.
- The compiler resolves five contribution families: skills, scoped prompts, subagent templates, lifecycle hooks, and tool configuration. It preserves canonical identity, provenance, compatibility, reference closure, and deterministic order. A skill's workflow remains owned by its
SKILL.md. - Strict schema decoding rejects target paths, native writes, and other materialization fields. The resulting
ContextPlanis semantic evidence, not filesystem instructions. - Setup uses the plan to drive scaffold output and persists the same evidence at
.devpunks/context-plan.json. - Harness projection loads that file. Absence alone permits the legacy materialization path. Present but malformed or invalid context never falls back to legacy behavior.
- Claude, Codex, Cursor, and OpenCode adapters consult their versioned capability matrices. Supported contributions become native actions. Expected provider limitations and preserved project-owned prompts become neutral durable provenance.
- The application layer validates every source and target against the repository root, preserves consumer-owned regular prompt files, and applies safe independent actions even when another action is omitted or fails.
- The CLI writes
.devpunks/harness-projection-receipt.jsonand surfaces the aggregate status through setup/default-stage output.
Outcomes
| Status | Meaning |
|---|---|
success | Every required supported action applied. Expected provider limitations and preserved project-owned prompts may remain as neutral receipt provenance. |
partial | A genuine actionable nonfatal anomaly occurred while independent supported actions still applied. |
failure | Invalid input, an adapter defect, an unsafe path, a missing managed canonical source, or an application error affected at least one action; the command is nonzero. |
A failure may coexist with neutral limitations, omissions, and successful independent actions. The receipt retains all of them so operators can distinguish an expected harness boundary from broken projection behavior. A normal receipt and manifest remain success; scaffoldDegradations is empty. Legacy nonempty degradation bookkeeping is silently cleared by the next normal update receipt refresh.
Durable Evidence
.devpunks/context-plan.jsonrecords neutral semantic intent..devpunks/harness-projection-receipt.jsonrecords what each adapter attempted, omitted, applied, or failed. It is evidence, not desired state.- Setup output exposes the receipt path and aggregate status.
See Harness Capability Projection for the support model, Shared Scaffold Model for ownership, and the CLI scaffolding runbook for operator response.
The historical IP-317 planning and implementation artifacts retain their original evidence. This flow is the current authority and supersedes their former omission-to-partial health rule.