# Catlx Runtime Lifecycle

> CATLX — Runtime Lifecycle Sequences

- Skill: `samraddhashrivastavatech/catlx-runtime-lifecycle` (Agent Skill)
- Install (CLI): `npx skillmds@latest add samraddhashrivastavatech/catlx-runtime-lifecycle`
- Raw SKILL.md: https://api.skillmd.com/api/skills/samraddhashrivastavatech/catlx-runtime-lifecycle/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: SAMRADDHASHRIVASTAVATECH (https://skillmd.com/u/samraddhashrivastavatech)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/samraddhashrivastavatech/catlx-runtime-lifecycle

---


# CATLX — Runtime Lifecycle Sequences

This skill owns the **ordered end-to-end sequences** that tie the subsystems together: how CATLX boots, how a
voice command flows, how a workflow runs, how a plugin is installed, and how recovery proceeds.

> Canonical detail: `../knowledge/references/runtime-lifecycle.md`. The voice sequence is also in
> `../examples/voice-command-lifecycle.md`. Load on demand.

---

## Purpose

Give the exact, ordered step sequences so that no stage is skipped or performed out of order. Use these as the
authoritative procedural truth for orchestrating CATLX behavior.

## When to activate

- User asks about startup/boot order, or "what happens when CATLX starts."
- Tracing a voice command, a workflow run, a plugin install, or a recovery end-to-end.
- Verifying a specific stage (e.g. when the Capability Router runs vs the Memory Broker).

## What this skill handles

1. **Boot sequence** (§18.1) — launcher detects `CATLX_ROOT` → stale-PID check → Hardware Profiler (< 50 ms) →
   Capability Router emits `CapabilityMap` → databases open (WAL replay) → Module Registry scanned in
   dependency order → Event Bus on `:7701` → Security Layer → Memory Broker → AI Provider Layer (health/local
   servers T1+) → Workflow Engine scheduler → Voice Pipeline (wake word + mic) → Plugin Runtime →
   Electron Shell/HUD → write PID lockfile → emit `system.ready` → restore workspace →
   operational.
2. **Voice command lifecycle** (§18.2) — wake word → capture → VAD (800 ms) → STT → context → NLU
   (`IntentObject`, confidence < 0.75 → disambiguate/loop) → Workflow Planner → Permission validation → DAG
   execute → per-step checkpoint + TTS/HUD → completion → Memory Broker writes EpisodicRecord → monitoring.
3. **Workflow lifecycle** (§18.3) — load YAML/dynamic → validate DAG (no cycles, deps present, modules
   available) → create execution context (run ID, input snapshot, rollback log) → schedule → dispatch root
   nodes → per-node module invoke → store output/unlock dependents → on failure retry policy → on FAILED offer
   rollback → on success COMPLETED → emit completion → archive run.
4. **Plugin lifecycle** (§18.4) — package (marketplace/local) → signature verify → manifest parse → capability
   grant review → store grants in `plugins.db` → resolve/vendor deps → build/validate → register → load into
   sandbox → `initialize()` → register capabilities with router → available → update (hot-swap or restart
   flag) → uninstall (`cleanup()`, deregister, destroy sandbox, remove files).
5. **Recovery lifecycle** (§18.5) — crash detected via stale PID → Recovery Mode flag / Safe Mode UI → replay
   WAL → load workspace snapshot → find `RUNNING` workflows → verify checkpoint hash → present Resume/Rollback/
   Ignore → execute chosen action → clear flag → continue boot.

## Requirements / constraints

- **R8 (replay safety):** all lifecycle steps that mutate state are checkpointed.
- **R7 (deterministic recovery):** recovery sequence is deterministic; `Recovery Mode` flag cleared only when
  complete.
- Windows-first paths and mechanisms apply throughout (see `../knowledge/rules/windows-rules.md`).

## Canonical knowledge it reads

`../knowledge/references/runtime-lifecycle.md` · `../knowledge/references/recovery.md` ·
`../knowledge/references/workflow-engine.md` · `../knowledge/references/voice-pipeline.md` ·
`../knowledge/references/plugin-ecosystem.md` · `../knowledge/references/data-registries.md`.

## Delegation

Because these sequences cross subsystems, delegate to the owning skill when a specific stage needs detail:
`catlx-voice-pipeline`, `catlx-workflow-engine`, `catlx-plugin-ecosystem`, `catlx-electron-shell`,
`catlx-security`, `catlx-recovery`, `catlx-hardware-adaptation`, `catlx-capability-routing`. Use
`skill({ name: "<target>" })` and pass the specific stage as the minimum context.

## Edge cases & warnings

- **Boot ordering:** the Capability Router must emit the CapabilityMap before any subsystem initializes.
- **Stale PID:** a genuine crash triggers recovery; a live PID must not be treated as stale.
- **Confidence loop:** NLU must loop on disambiguation only while confidence < threshold; avoid infinite loops
  (cap the number of clarification turns).
- **Plugin/unit ordering at boot:** modules and plugins load in dependency order.

## Component lifecycle policy (reuse → install → adapt → create)

**NEVER create a new component as the default.** Before building/creating anything (a sub-skill, dependency,
reference, workflow, helper, adapter, or template), check, in order:
1. **Reuse** an existing local component (resolve aliases/equivalent capabilities first) — reuse, don't rebuild.
2. **Use** an already-registered component from the registry.
3. **Install** a suitable existing, trusted, supported component → validate → register → connect to the graph → use.
4. **Adapt** an existing compatible component via a small persistent adapter/wrapper instead of re-creating it.
5. **Create only as last resort** — then make it permanent immediately: stable id, canonical location, register,
   add to the capability index + dependency graph, add provenance, use, and allow future reuse.
6. Never reorganise/recreate already-generated components (no `Skill X 2` / `new` / `temp` variants); extend the
   existing one. Never create a second competing knowledge source; connect back to the canonical `knowledge/` layer.
   Promote any reusable artifact out of `/tmp`/scratch into the permanent ecosystem.

> Full policy: `../knowledge/rules/component-lifecycle.md`.

## Source / provenance

- **Source:** PART XVIII §18.1–18.5 (boot, voice command lifecycle detailed, workflow lifecycle, plugin
  lifecycle, recovery lifecycle).
- **Inferred:** none; sequences preserved as ordered steps.