"""Isolation / change-manifest / selective-apply primitives for graphlemon's
Deploy Supervisor (the independent process that handles blue-green deploy +
automatic rollback for graphlemon's own self-modification -- not to be
confused with the "Supervisor（调度子 Agent）" role documented in
graphlemon_architecture.md, which is an in-process monitoring node inside
the Coder Work Graph. See docs/supervisor-auto-rollback-design.md for the
disambiguation.

Adapted 2026-07-30 from graphloop (`/Users/yibo/Documents/lemonAI/graphloop`,
an earlier attempt at the same graphlemon architecture, no longer
maintained). These four modules were copied essentially verbatim because
they are pure-stdlib, contain no Hermes/Claude CLI dependency, and were
already exercised against a real failure mode in graphloop's own Phase-10
self-evolution run (a worker wrote implementation files directly into the
source workspace instead of the isolated copy; `change_manifest`'s
symlink-rejecting isolated-tree snapshot plus the caller's manifest check
caught it before anything false was reported as evidence).

See docs/supervisor-design-comparison.md and
docs/supervisor-auto-rollback-design.md for why this code lives here and how
it plugs into the blue-green deploy/rollback state machine.

Module map (unchanged from graphloop):
- isolated_workspace.py   -- isolate_workspace(): disposable tempdir copy of
  a source directory; the source is never mutated directly.
- workspace_security.py   -- validate_artifacts() / validate_subprocess_command():
  path-escape and shell-metacharacter guards, used at every trust boundary.
- change_manifest.py      -- snapshot_workspace() / build_change_manifest():
  SHA-256 diff between a source snapshot and an isolated tree.
- selective_apply.py      -- apply_manifest(): the sole writer back into the
  real source tree; validates every approved path, stages bytes before any
  mutation, writes atomically via tempfile.mkstemp + os.replace.

Not yet wired into any graphlemon controller/process -- that happens when
the corresponding Enabler unit (see docs/development-plan.md) is scheduled.
This directory is staged ahead of that so the design doc can reference
concrete, already-adapted code rather than only prose.
"""