Scheme chooses policy; Rune supplies native effects
Flint's workflow compiler, scheduler, leases, retries, recovery, and interfaces live in Scheme. Rune supplies bounded filesystem, process, sandbox, credential, content, and network operations. That split lets the CI policy evolve without creating a separate product-specific Rust runner.
A workflow describes requested work. The operator chooses which repositories, resources, executables, images, credentials, and remote authorities are available. Recognized workflow syntax does not create those prerequisites. A label such as runs-on is not an automatic machine allocator.
A resource pool tracks slots and leases. A pool named postgres does not install or start PostgreSQL. Hooks can connect allocation to real operator-managed resources, but only through approved selectors. This is why resource inspection and operator preparation come before a workflow submission.
Cleanup controls do not establish hostile-tenant isolation
Native jobs require supported Linux with cgroup v2, namespaces, and overlayfs. Those controls help contain process trees, mount selected roots, and clean up work. They are not a security boundary for hostile repositories on the same trusted host.
Credentials remain opaque handles in policy code. Rune materializes a selected job secret only when creating the sandbox process and masks selected credential values from process output. That mechanism does not make malicious job code trustworthy or grant permission to give it secrets.
Provider status I/O stays outside the sandbox. Operator-owned action metadata and content are selected by immutable keys and mounted read-only. Public listener exposure and authentication remain separate operator decisions. None of these boundaries permits arbitrary workloads under another person's service account.
History, execution, and publication have separate outcomes
Flint stores run and job history in application SQLite. The database records workflows, dependencies, leases, cancellation, and publication work. It is not Rune's runtime control database. Repo-mode data and named deployment data also have distinct roots.
A run can be stored while its native work has not started. A job can finish while its provider status is still waiting for publication. A replay is a new run linked to stored history, not an overwrite or proof that work ran again. Health and explanation exist to make those distinctions visible.
Cancellation and recovery require evidence that the native process tree has been cleaned. Lease release can also require a successful release hook. When the implementation cannot prove cleanup, it fails closed and can quarantine a slot. Treating that condition as a routine retry could assign the same resource to overlapping jobs.
Startup recovery and publication retries use persisted state, claim generations, and receipts to distinguish current work from stale effects. A green wrapper command alone cannot prove the state of that work. Read the run, job, cleanup disposition, and publication result.
Preview contracts are not release acceptance
These guides use unreleased source for exact command and interface behavior. That source can print the same Rune version as an existing public release while exposing different HTTP envelopes and operation registration. Version strings alone do not identify the contract.
The matched HTTP route uses operation and arguments. The older baseline uses method and params. Registry metadata and in-process transport fixtures can describe interfaces that the production CLI does not host. In particular, a production MCP process entrypoint is missing, and annotated operation paths returned 404 during direct HTTP evaluation.
macOS checks can exercise Scheme and control-plane behavior. They are not successful Linux jobs or Flint 1.0 acceptance. Native execution, cancellation, recovery, resource hooks, and provider publication require evidence from their actual environment before an operator claims them.
Forge's inert Linux capsule workflow is a maintainer preview requiring an existing offline toolchain and dependencies. It does not provide a standalone Flint binary or supported binary image, OCI, or unikernel output. Import does not execute Scheme, create a managed home, or overwrite a destination. Unsigned provenance does not authenticate a publisher.
Return to the sample tutorial for an inspectable starting point, or use Rune compatibility help to check a different installed build.