yelei1027/codex-engineering-harness-v3/harness-maintain

Harness Maintenance

Follow U10–U16 in the workflow contract; this is design data, not a Codex native API. Resolve the real Harness/runtime paths and read bin/harness --help before using actual maintenance commands. Start with read-only inventory, accepted/candidate locks, ownership and active project consumers; avoid guessed latest versions and unknown global changes.

Build a concrete plan with pinned source/version/hash, dependencies, skill behavior/policy changes, project impact, touched files, candidate isolation, checks and recovery boundaries. Apply within existing user authorization; request only missing material permission, login, key, hook trust, sudo or irreversible migration approval. Never treat a skill mention as permission for all bundled side effects.

Use independent candidate dependencies/config/ports/test data. Back up each existing resource before mutation, record hashes/mode/ownership and a transaction journal; do not overwrite unknown user content. Static validation cannot substitute for actual component calls, model routing, complete snapshot review or enabled/disabled project verification. Promote only after required candidate checks and safe activation in the right new session; update accepted lock only for truly accepted tested state, not read-only checks. Do not replace dependencies used by an active encoding session. If the runtime cannot guarantee safe promotion, report blocked scope accurately.

Use actual CLI rollback for the transaction's touched set, preserving unrelated later configuration and user data, then reverify the old environment. Package only managed reproducible artifacts and pinned sources; exclude credentials/session stores/DBs/unrelated data. Application deploy/database recovery remains separate. Preserve one registration source per component: skills plugin OR standalone skills, project MCP config OR plugin MCP, never duplicate hook sources. First start previews project setup; prepare --apply uses the explicitly approved setup scope and defaults to L2 PWF/context hooks pending native trust. Valid existing setup is reused; explicit L0/L1 profiles stay hook-free. Shared installation owns one global natural-language entry, while the Main Router stays project scoped. refresh reconciles same-root owned overlays and retains task data. Cross-root updates use migrate --from preview then approved --apply, defer active/paused tasks, and retain the old root. Keep context-mode MCP-only and OCR CLI+delegation. PowerContext uses project-scoped Basic task summaries/Handoff; its Full background model extraction needs a separately verified provider. Screenshot work defaults to the current Codex session, with third-party generation checked separately. Never export Codex OAuth tokens into sidecar API-key fields. No global lifecycle hooks. Report real installed/registered/verified/unsupported states and incomplete external prerequisites.

Use recover-data for current-root retained local files and recover-memory for other removed roots' memory services; preview both before applying within existing recovery authorization. Complete install --prepare resumes applicable recovery. Retained memory uses the current verified immutable image only when it exactly matches the original; it preserves the volume, endpoint and project Scope/Revision, without reinstalling old programs, merging databases or replacing bindings. Missing volumes, unknown consumers, occupied ports, generation or image changes are conflicts. Report service startup separately from exact Scope/Revision verification. Public services and full uninstall include recovered deployments; uninstall removes their owned program while retaining provider environments, volumes and provenance records. Never infer database compatibility from a matching tag alone.