Compile and Project Repository Context
How one neutral context plan becomes truthful harness-specific output
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. Known unsupported capabilities become explicit warnings and omissions.
- 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 supported action was applied and no warning, omission, or failure changed the result. |
partial | Safe supported actions were applied, while known capability gaps or preservation rules remained visible as typed warnings and omissions. |
failure | Invalid input, an adapter defect, an unsafe path, a missing source, or an application error affected at least one action; the command is nonzero. |
A failure may coexist with omissions and successful independent actions. The receipt retains all of them so operators can distinguish a known harness boundary from broken projection behavior.
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.