Lifecycle In progress
Starting a process is easy. Stopping one without losing work is the hard part. Clamp's lifecycle model is designed around both.
Status. A synchronous lifecycle prototype (example 05) is in development against fake resources and is not on the main branch yet. The full phase model below is the design; each row says what the prototype covers.
Alive does not mean Ready. Ready does not mean Healthy.
Phases
| Phase | What happens | Status |
|---|---|---|
| Created | The application exists structurally. No side effects yet. | Planned |
| Configured | Configuration is resolved from defaults, files, environment and arguments. Missing required configuration fails before any work is accepted. | Planned |
| Composed | Modules, capabilities and contributions are assembled. Describe what exists and what is required — no I/O. | Prototype |
| Validated | The known composition is checked before external resources open: missing or ambiguous providers, cycles, orphan contributions. | Prototype |
| Initialized | External resources are prepared — pools, keys, telemetry — in dependency order: providers before the modules that need them. | In progress |
| Started | Components begin active work. initialize() prepares; start() begins. | In progress |
| Ready | The process is prepared to accept its intended workload. Never ready if startup or a required health check failed. | In progress |
| Running | Normal execution under supervision. | Planned |
| Stopped | Reached through the shutdown pipeline below, or through Failed → cleanup from any phase. | In progress |
Shutdown, in order
Shutdown starts by refusing new work, not by destroying dependencies.
- Shutdown requested.
- Readiness becomes false; admission closes.
- In-flight work drains, bounded by a deadline — consumers first (Worker, then the modules it uses).
- Remaining cancellable work is cancelled. Cancellation stops work; it does not undo side effects that already happened.
- Participants stop in reverse dependency order — providers last.
- Final diagnostics are flushed, within a bound.
- Infrastructure closes; the process exits.
What the prototype proves
The lifecycle prototype freezes and validates a Worker projection (Worker → Users → a fake Database capability) before running any lifecycle operation, then derives order from Kernel's resolved requirements. Its eight tests cover:
- Initialization and startup order derived from dependencies; cleanup in reverse.
- No readiness after a startup failure or a failed required health check.
- Cleanup of only the resources that were actually acquired.
- Cleanup that continues after injected errors.
- Drain deadlines, optional degradation, programmatic shutdown, and a bounded final flush.
Status keeps started, ready, alive, accepting_work and health as separate values rather than one boolean.
Health vocabulary
| Signal | Question it answers |
|---|---|
| Liveness | Is the process alive? |
| Readiness | Should new work be sent to this process? |
| Health | How is each component doing? Per component, not a single yes or no. |