Scaffold Update

Historical (retired in CLI 6.0.0). This page describes the manifest-driven lifecycle (hi scaffold, hi ensure, hi update --check). The Registry Baseline replaced it with hi init, hi update, hi diff, and hi check: see Scaffold Baseline and the CLI scaffolding runbook.

Root hi check is the read-only pre-work drift command. Normal hi update applies scaffold reconciliation from one compiled desired state, the observed repository, and the prior successful receipt. Use hi update --check for a read-only preview.

Trigger

An operator or session-start hook runs hi check after setup. An operator runs hi update to apply verified baseline changes, or hi update --check to preview without writing.

Actors

• Operator
• hi CLI
• Scaffold baseline

Steps

1. Read settings, .devpunks/scaffold-manifest.json, and prior successful ownership evidence.
2. Re-scan repository facts, resolve the active baseline and packs, and compile the desired files, package dependencies, structured keys, projections, and provenance.
3. Observe repository state without treating invalid data as missing.
4. Plan deterministic per-entry create, update, archive-and-replace, remove, skip, degradation, conflict, and failure outcomes. Effective ownership keeps project-owned, intentionally customizable, and current project-generated content outside fixed baseline recovery.
5. hi check compares through a read-only stage without a writable temporary tree. It reports settings upgrades, executable drift, scaffold/baseline drift, and changelog summaries without changing settings, pins, manifests, or receipts.
6. hi update --check reports the reconciliation preview without applying it.
7. Normal hi update executes independent safe actions even when another entry conflicts or fails. --write and --yes remain compatibility aliases for the same apply behavior. Combining either alias with --check fails before baseline resolution or filesystem effects.
8. Dependency actions refresh the detected Bun, pnpm, npm, Yarn Classic, or modern Yarn lockfile. A failed refresh restores the package manifest and recognized lockfiles and keeps the prior receipt so retry remains deterministic.
9. Update stages the wiki and other managed surfaces. Baseline-identical content with stale ownership evidence heals silently. A genuine edit to fixed ScaffoldManaged content is archived once under .devpunks/replaced-scaffold/<fingerprint>/<path>, then replaced from the verified baseline.
10. Persist receipt evidence from the committed result. A successful update finishes with a clean subsequent hi check --json.
11. Report changed and stale files, manifests, baseline/pack/wiki drift, reconciliation status, planned actions, outcomes, and whether receipt persistence succeeded.

Outcome

Read-only checks do not update pins, files, or receipts. An update with only successful or skipped work returns succeeded. An update with both blocked and successful actions returns partial; an update with blocked work and no success returns failed. Partial and failed updates exit nonzero, keep failures visible, and never claim those entries as applied.

Project-owned and intentionally customizable files remain silent and unchanged. Current ProjectGenerated and RepositoryMirror outputs retain their producer-bound ownership; missing or stale producer evidence remains visible because update does not invent producer output.

If verified baseline authority is unavailable, update fails safely without treating bundled or observed bytes as authority. Update otherwise uses the same best-effort required-tool bootstrap behavior as setup. Tool install failures print recovery context but do not block independent managed actions.

Update reports exact .cursor, .codex, .claude, .agents, and .opencode ignore patterns in root .gitignore as harness drift, then removes them when applying.