# Production Readiness
This document defines what “production ready” means for `ready-active-safe`
and how we get there without drifting into a framework.
---
## Current Status (v0.1.x)
The crate is production-usable today as a **pure lifecycle kernel**:
- `Machine` is Sans-I/O and deterministic
- `Decision` is explicit, inspectable data
- `Policy` enables external transition rules
- `LifecycleError` provides a minimal failure type
The `runtime`, `time`, and `journal` modules are intentionally **minimal**:
they are reference-quality building blocks (not frameworks) and are still expected
to evolve before the 1.0 API freeze.
---
## Definition: “Production Ready”
For this crate, “production ready” means:
1. **Semantics are explicit** and tested (especially around policy denial and command dispatch).
2. **The core contract is stable**: changes are rare, intentional, and documented.
3. **Safety and reliability guarantees hold**:
- No `unsafe`
- No panic-based control flow in library code
- Deterministic decision logic
4. **Docs and examples are sufficient** for a first successful integration.
5. **Compatibility is maintained** (MSRV and `no_std` story are real, tested, and documented).
It does *not* mean “every optional feature exists”.
---
## Checklist
### API Semantics
- Written, unambiguous rules for:
- command ordering
- transition application
- policy denial behavior
- replay and determinism expectations
### Test Coverage
- Unit tests for core types and invariants
- Doctests for public surface as executable spec
- `cargo test --no-default-features` coverage for the `no_std` core (with `alloc`)
### Release Discipline
- MSRV policy enforced in CI
- Changelog entries for behavior changes
- Pre-1.0: breakage is allowed, but must be intentional and documented
### Integration Guidance
- Clear examples for:
- embedded/no_std usage (core only)
- a minimal sync event loop (std)
- policy usage and denial handling
- replay pattern for auditing/debugging
---
## Roadmap To “Batteries Included” (Optional)
For the full versioned release plan, see [`ROADMAP.md`](ROADMAP.md).
For the competitive audit, see [`AUDIT.md`](AUDIT.md).
If we implement these, they should remain small and composable:
- `runtime`: reference loop + command dispatch hooks (std-only)
- `time`: deadline types and clock traits (no scheduler in core)
- `journal`: in-memory transition recording + replay helpers (std-only)
Each must be independently optional and must not change the core semantics.