//! Windows [`cellos_core::ports::CellBackend`] — isolates a cell in a Windows
//! **Job Object** for hosts where the Linux-only backends (Firecracker, gVisor)
//! cannot run.
//!
//! ## What a Job Object gives us
//!
//! A [Job Object](https://learn.microsoft.com/windows/win32/procthread/job-objects)
//! is the closest Windows analogue to a cgroup-v2 leaf: a kernel object that
//! owns a set of processes and enforces aggregate limits over them. This
//! backend creates one job per cell and uses it for three things:
//!
//! 1. **Process-tree containment** — the workload and every descendant it
//!    spawns are members of the job, so teardown is a single kernel call that
//!    cannot leak orphans.
//! 2. **Resource caps** — `spec.run.limits.memoryMaxBytes` maps to a job-wide
//!    `JOB_OBJECT_LIMIT_JOB_MEMORY` cap, and `spec.run.limits.cpuMax` maps to a
//!    hard CPU-rate cap (`JOBOBJECT_CPU_RATE_CONTROL_INFORMATION`).
//! 3. **Residue-free teardown** — the job is created with
//!    `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`, so closing the last handle (or an
//!    explicit `TerminateJobObject` in `destroy`) kills everything still inside.
//!
//! ## Honest scope (v1)
//!
//! A Job Object is **process-level containment, not a virtualization boundary.**
//! It does not provide a separate kernel, syscall emulation, a filesystem mount
//! namespace, or network-egress enforcement. Its isolation strength is in the
//! same tier as the Linux proprietary (`cellos-host-cellos`) cgroup-only
//! backend — weaker than gVisor (`runsc`) and far weaker than a Firecracker
//! microVM. Operators who need a hardware/syscall boundary must run the cell on
//! a Linux host with `CELLOS_CELL_BACKEND=firecracker` (or `gvisor`).
//!
//! Two limitations are enforced **fail-closed** rather than silently ignored:
//!
//! - **Network egress is not enforced.** Windows has no `nft` equivalent wired
//!   here, so a spec that declares `authority.egressRules` gets a prominent
//!   per-cell warning. `CellHandle.nft_rules_applied` is always `None`.
//! - **`secretDelivery: env` is refused** when the spec also declares
//!   `secretRefs`. This backend *owns execution* (it spawns the workload
//!   itself), so the supervisor's host-subprocess env-injection path is
//!   bypassed; rather than run the workload without its secrets, `create`
//!   returns `InvalidSpec`. Use a broker-socket delivery mode (the default,
//!   `runtimeLeasedBroker`) where the child fetches secrets over a socket.
//!
//! ## Platform gating
//!
//! The real implementation (`backend`, `job`) is compiled only on Windows. On
//! every other target the crate exposes a small stub `WindowsCellBackend` whose
//! `CellBackend` methods return a clear `Host` error, so `cargo check
//! --workspace` and `cargo doc` stay green on Linux/macOS.

#[cfg(windows)]
mod backend;
#[cfg(windows)]
mod job;

#[cfg(windows)]
pub use backend::WindowsCellBackend;

#[cfg(not(windows))]
mod stub;
#[cfg(not(windows))]
pub use stub::WindowsCellBackend;
