CONTINUUM: Verifiable semantic recovery for long-running AI agents. Semantic checkpoints (not conversation dumps), an idempotent action ledger that refuses duplicate side effects, and a hash-chained tamper-evident event log, all exposed as a deny-by-default MCP server. Framework-agnostic, Python 3.11+.
If CONTINUUM helps your agents recover, please star the repo. It helps others discover it and keeps good first issues coming.
English | 简体中文 | Español | 日本語 | Português | 한국어
--- ## Contents [Why](#why) · [Quick Start](#quick-start) · [How it works](#how-it-works) · [Where CONTINUUM sits](#where-continuum-sits) · [Features](#features) · [Security Extension](#security-extension) · [Empirical Verification](#empirical-verification) · [MCP Integration](#mcp-integration) · [Framework Integration](#framework-integration) · [Core Concepts](#core-concepts) · [Architecture](#architecture) · [API and CLI](#api-and-cli) · [Roadmap](#roadmap) · [What CONTINUUM Is Not](#what-continuum-is-not) · [Related work](#related-work) · [Status and limitations](#status-and-limitations) · [Contributing](#contributing) · [License](#license) --- ## Why Modern AI agents run long tasks (hundreds of LLM calls, tool invocations, file and database writes). When they crash, the usual response is to replay everything from scratch, which duplicates work, duplicates side effects, wastes tokens, and loses decisions. CONTINUUM asks a narrower, harder question: can an agent resume from a compact semantic representation of its task state while independently verifying that state is still valid in the current environment? Its differentiator is three-part: - **Semantic checkpoints**: a compact, versioned representation of what the agent needs to continue, not a conversation dump. - **Independent environment revalidation**: every checkpoint component is verified against the current environment before resume, with staleness propagating through the dependency graph. - **Provenance-aware state**: every fact traces to its origin, so agent-reported progress is never self-certifying. ## Quick Start Published to PyPI as `continuum-agent` 0.1.2: `pip install continuum-agent` (`pip install continuum-agent==0.1.2` to pin). Release tags additionally ship built wheels attached to [GitHub Releases](https://github.com/Cyrax321/CONTINUUM/releases). Paths that need no clone and no local install: | Path | How | |:--|:--| | Install from PyPI | `pip install continuum-agent==0.1.2`, then `continuum --help` | | Install with Homebrew | `brew install wized2/continuum/continuum`, then `continuum --help` | | Watch crash recovery happen end to end | `docker run --rm ghcr.io/cyrax321/continuum` | | Use the CLI through Docker | `docker run --rm ghcr.io/cyrax321/continuum continuum --help` | | Run the CLI without cloning | `uvx --from git+https://github.com/Cyrax321/CONTINUUM.git continuum --help` | | Windows PowerShell (from a clone) | `powershell -ExecutionPolicy Bypass -File .\try-it.ps1` or `powershell -ExecutionPolicy Bypass -File .\try-it.ps1 cli --help` | | Watch the same recovery in a notebook | [](https://colab.research.google.com/github/Cyrax321/CONTINUUM/blob/main/examples/demo.ipynb) | | The same notebook, on Binder | [](https://mybinder.org/v2/gh/Cyrax321/CONTINUUM/HEAD?labpath=examples%2Fdemo.ipynb) | | Full dev environment in the browser | [](https://codespaces.new/Cyrax321/CONTINUUM?quickstart=1) | The Docker image is published to GHCR by CI on every push to `main` and every release tag (`.github/workflows/docker-publish.yml`). The Codespace is defined in `.devcontainer/`. The notebook is [examples/demo.ipynb](examples/demo.ipynb): its first cell installs CONTINUUM only when the import fails, so the one file runs on Colab, on Binder, and from a clone. ```bash git clone https://github.com/Cyrax321/CONTINUUM.git cd CONTINUUM uv venv && source .venv/bin/activate # macOS / Linux; Windows: .venv\Scripts\activate # Contributors (recommended): library + CLI + test tooling + framework integrations uv pip install -e ".[dev]" # Or pick only what you need: . (minimal), [mcp], [browser], [kubernetes], # [otel], [langgraph], [openai], [langchain], [attest], [postgres] # Or skip the clone entirely: uv pip install git+https://github.com/Cyrax321/CONTINUUM.git uv pip install "continuum-agent[mcp] @ git+https://github.com/Cyrax321/CONTINUUM.git" ``` > **pip fallback:** replace `uv pip install` with `pip install` in every command above. Optional environment adapters: - `uv pip install -e ".[browser]"` enables `BrowserAdapter`; run `playwright install chromium` separately to install the browser binary. - `uv pip install -e ".[kubernetes]"` enables `KubernetesAdapter`; `kubectl` and a configured cluster remain external prerequisites. If you use pip instead of uv, run `pip install -e ".[browser]"` or `pip install -e ".[kubernetes]"` with the same external prerequisites. Verify: ```bash continuum --help # CLI entrypoint continuum-mcp --help # MCP server entrypoint (needs [mcp] or [dev]) pytest -q # ~3950 collected, ~3,950 passed, ~0 skipped on a minimal env (exact counts vary) ruff check src/ tests/ examples/ && ruff format --check src/ tests/ examples/ mypy src/continuum # the three gates CI enforces ``` The core library has one runtime dependency (`pydantic>=2.7`); everything else is opt-in. The full package map, extras matrix, Postgres test setup, and per-command verification are in [references/install.md](references/install.md). ### Wire a coding agent in two minutes For Claude Code, Gemini CLI, or Codex, you do not write Python and do not need a prompt file: ```bash continuum start my-task --goal "What the agent should do" continuum hooks install claude-code --with-gate # also: gemini, codex ``` From then on every file the agent writes is captured as hash-chained evidence, its session starts with an automatic status briefing, unclaimed side effects registered in `.continuum/gate.json` are refused before they fire, and a fresh session after any crash resumes with executable next steps. No CLAUDE.md required. Minimal library example, record and recover: ```python from continuum import EventType, Run, SQLiteStorage, project store = SQLiteStorage("agent.db") store.create_run(Run(run_id="run_4821", goal="Analyze 10,000 documents")) store.append_event( "run_4821", EventType.RUN_STARTED, {"goal": "Analyze 10,000 documents", "total": 10_000} ) for i, doc in enumerate(documents): analyze(doc) store.append_event("run_4821", EventType.WORK_COMPLETED, {"doc": i}) # After a crash, a new process picks up exactly where it stopped: state = project("run_4821", store.read_events("run_4821")) print(state.progress.completed) # already done, not repeated print(store.verify_events("run_4821").ok) # True, chain intact after the crash ``` **Run the proof yourself:** ```bash python examples/crash_recovery_agent.py # real process kill, real side effect python examples/context_compaction.py # transcript lost, checkpoint survives python examples/model_switch.py # Model A dies, Model B resumes safely python scripts/mcp_smoke.py # real subprocess, real JSON-RPC traffic ``` The `e2e-autonomy-test/` kit scripts a real invoice-batch task, a hard-kill mid-run, and a fresh resume session, then scores the outbox, ledger, and event chain out of band. Run 1 scored **7/7 mechanics** against a real Claude Code session. Full walkthrough in [references/e2e.md](references/e2e.md). ## How it works CONTINUUM separates **LLM context** (temporary) from **durable task state** (permanent). Instead of saving conversation history, it constructs a semantic checkpoint, the minimum verified information required to continue.  The detailed explanation, the projection model, and the recovery context are in [references/architecture.md](references/architecture.md). ## Where CONTINUUM sits Four concerns overlap in every long-running agent. CONTINUUM owns only the last one and touches the other three through explicit seams. No competitor is named and no claim is made without a shipped module or a published suite that already prints it. | Layer | Answers | How it connects (shipped modules or published output) | |:--|:--|:--| | Harness | How does the agent call tools and make progress toward a goal? | Outside CONTINUUM. Wiring points ship in `src/continuum/adapters/generic.py` (`GenericAgentAdapter`), `src/continuum/adapters/thin.py` (CrewAI, AutoGen, Pydantic AI hooks), `src/continuum/mcp/server.py` (MCP stdio), `src/continuum/hooks.py` and `src/continuum/clienthooks.py` (coding-CLI lifecycle hooks), `src/continuum/gateway.py` (enforcing HTTP proxy for any language), and `src/continuum/otel.py` (OpenTelemetry bridge). Recipes are in `docs/recipes/` and `references/adapters.md`. | | Durable execution | What happened before a crash and what can be replayed without losing work? | Hash-chained event log `src/continuum/events.py` with `verify()` and `trusted_through`, durable storage `src/continuum/storage/sqlite.py` (WAL, `synchronous=FULL`, schema v6) and `src/continuum/storage/postgres.py` plus `src/continuum/storage/migrations.py`, policy-driven checkpoints `src/continuum/checkpoint/manager.py` and `src/continuum/checkpoint/policy.py` that replay the gap on `restore()`. Walkthrough is in `docs/recovery_walkthrough.md` (output of `examples/recovery_walkthrough.py`). | | Control plane | Which run is active, who may act on it, and where does output go? | Run registry and parent/child hierarchy `src/continuum/storage/` and `src/continuum/recovery/family.py` (`continuum tree`), allowlist authz `src/continuum/mcp/authz.py` (`CONTINUUM_MCP_MUTATING_CLIENTS` / `CONTINUUM_MCP_TOKEN`), presentation surfaces `src/continuum/dashboard/app.py` and `src/continuum/serve/server.py`, CLI `src/continuum/cli/main.py` (`continuum runs`, `continuum tree`, `continuum health`). | | Verification substrate | Given the checkpoint at time T and the world as it is now, is it still safe and correct to continue? | `src/continuum/state/validator.py` (staleness `dependency -> evidence -> finding -> decision` plus `PlanStep.depends_on`), `src/continuum/provenance_map.py` (`Origin` to `REQUIRES_REVIEW` until `REVIEW_CONFIRMED`), `src/continuum/actions/ledger.py` with `src/continuum/actions/idempotency.py` and `src/continuum/gate.py` / `src/continuum/gateway.py` (claim-before-fire, refuses duplicates, raises `UnknownSideEffect` for reconciliation), `src/continuum/replayguard.py` (portable guard), `src/continuum/pinning.py` and `src/continuum/replay_similarity.py` (replay correctness), `src/continuum/budgets.py` (retry caps), `src/continuum/recovery/engine.py` + `src/continuum/recovery/contract.py` + `src/continuum/recovery/planner.py` + `src/continuum/recovery/observations.py` (max-severity `RESUME < ... < ABORT`, sealed contract with `evidence` / `reason` / `next_allowed_action` / `human_steps`), `src/continuum/checkpoint/rewind.py` (atomic dual-state rewind), `src/continuum/analysis/prefix_trust.py` (advisory trust). Published checks: `docs/recovery_walkthrough.md`, `benchmarks/fault_injection/` (suite that prints `detection_rate` / `unsafe_resume_rate`), `src/continuum/benchmark/phase6/` (recovery-correctness suite), `docs/RESULTS.md`, and the regenerable visual below. | Every row above is traceable to a path that exists on `main` at the tagged commit. Nothing in this table restates a benchmark number, benchmarks live only in the suite output they already print. See `docs/research.md` for the full list of published suites and design docs. ### Crash recovery, for real The image below is not a mock. It is the output of `python demo-run/generate_crash_visual.py`, which runs `demo-run/worker.py` until `os._exit(9)` at document 399, calls `continuum resume --env dataset=v4` and shows the refusal path (`REQUEST_HUMAN`, `safe:false`, exit 21), reconciles the uncertain side effect with a probe, then resumes from the same database and finishes with no duplicate work. The transcript is also saved as `docs/assets/crash-recovery.txt` for audit. Regenerate it: ```bash python demo-run/generate_crash_visual.py # or: python scripts/generate_crash_visual.py ```  Full walkthrough with code is in `docs/recovery_walkthrough.md` (`examples/recovery_walkthrough.py`). The minimal bench harness is in `references/bench.md` (`continuum benchmark`). ## Features | Capability | What it gives you | |:--|:--| | Semantic checkpoints | Compact, versioned, inspectable state, not a transcript dump | | Idempotent action ledger | Refuses duplicate external side effects; surfaces uncertain ones for reconciliation | | Environment revalidation | Every checkpoint component verified against the current world before resume | | Provenance-aware state | Agent-reported progress is marked `REQUIRES_REVIEW`, never self-certifying | | Recovery engine | Seven recovery modes with a deterministic, sealed next-action contract | | Deny-by-default MCP server | Thirteen tools, read-only/mutating split, caller allowlist | | Framework adapters | Generic Python, OpenAI Agents SDK, LangGraph, and LangChain integrations | | Secure planning loop | Two-signal observation verification escalates high-risk branches to REQUIRES_REVIEW | | Periodic revalidation | Environment re-checked on a schedule, catching mid-run drift within one cycle | | Tamper-evident log | Hash-chained event log (55 event types) with integrity verification | | Enforcing gate | Unclaimed side-effect calls are refused before they fire; deny messages teach the claim protocol | | Observation hooks | Every file a coding CLI writes becomes digest-verified evidence, outside model control | | Session briefing | Fresh sessions learn run state deterministically at start, including the last session's reasoning summary | | Reconciler probes | Registered commands settle uncertain side effects automatically; humans see only the rest | | Executable guidance | Resume/validate render next steps as runnable commands, not statuses | | Enforcing HTTP gateway | Outbound calls in any language require claims; responses settle them from reality | | OpenTelemetry bridge | Tool-call spans from production tracing become evidence with zero code changes | | Action index | Cross-run idempotency lookups are indexed reads, not full-log scans | | Version pinning | Caller-asserted prompt/tool/model hashes stored per claim; drift surfaced on resume | | Retry budgets | Per-action-type attempt caps enforced at claim time; agents see remaining attempts | | Multi-agent parent/child | Parent resume composes family worst state; uncertain child blocks parent | | Informed retry | Engine-authored failure summaries injected into post-recovery resumes | | Fork semantics | Divergent continuations branch into child runs with fresh authority | | Log compaction | Pre-anchor prefix archived verbatim; live log bounded for month-long runs | | Consumed-grant tracking | Single-use authority references are marked spent at terminal status; reuse after restore is refused (`GRANT_DENIED`), defending the checkpoint-restore path against Authority Resurrection | | Chain attestation | `continuum attest` signs a run's chain head with Ed25519 so an external verifier can prove history was unaltered as of a known key | | HITL dashboard surface | Confirm/reconcile/complete buttons with audit parity to the CLI | ## Security Extension Two additive security extensions sit on top of the recovery and checkpoint substrate. They do not change resume, replay, or the existing crash-time revalidation path. > **Status: specified and tested, not shipped** (issue [#1030](https://github.com/Cyrax321/CONTINUUM/issues/1030)). The modules below are complete and pass their tests, but nothing in the engine or any seam invokes them yet (CONTINUUM revalidates at crash/resume only). Wiring them is a roadmap decision; read the present tense below as the design, not the shipped behaviour. - **Secure Planning Loop**: observations carry provenance and are verified by two independent signals (`verified` / `unverified` / `contested`). A plan branch gated on an unverified or contested observation is escalated to `REQUIRES_REVIEW`. Decisions are appended to the ledger as `PERCEPTION_OBSERVED` and `BRANCH_RESOLVED` events. - **Periodic Revalidation**: reuses the recovery engine on a step interval (default 25) and on app switch, so mid-run environment drift is caught within one cycle instead of only at the next crash. See [docs/PROBLEM.md](docs/PROBLEM.md), [docs/RESULTS.md](docs/RESULTS.md), and [STATUS.md](STATUS.md). ## Empirical Verification CONTINUUM is verified against real LLM agents, live protocol boundaries, and hard process crashes, not just mock unit tests. - **Real agents**: multi-session Claude Code invoice batches with mid-run `SIGKILL`, scored 7/7 on mechanics; resumed sessions queried `continuum_resume`, routed side effects through the two-phase ledger, refused to duplicate verified writes, and respected `request_human`. Live testing surfaced prompt-drift dedup gaps, closed by canonical path normalization and token-based fallback in `ActionLedger.claim()`. - **Third-party clients**: Gemini CLI and Kilo Code connected over stdio JSON-RPC against the live SQLite store, validating multi-agent co-existence and authorization isolation. - **Protocol compliance**: driven end to end with `@modelcontextprotocol/inspector --cli` across process deaths; mutating tools deny by default behind `CONTINUUM_MCP_MUTATING_CLIENTS`; external claims degrade to `REQUIRES_REVIEW` (`safe: false`). - **Self-healing**: hard-killed servers recover from orphaned SQLite `-wal`/`-shm` sidecars via single-retry cleanup at startup. - **Scale**: roughly 3950 tests collected (~3,950 passing; ~0 skipped; other outcomes vary by environment) on Python 3.11, 3.12, and 3.13 (unit, `hypothesis` property-based, concurrency, adversarial). CONTINUUM-Bench runs five crash scenarios plus a dedicated argument-drift scenario, measuring 0 duplicate work and 0 duplicate side effects for CONTINUUM against full duplication for naive replay; the horizon-scale suite publishes those duplicate counts next to the number of post-reconstruction re-attempts the ledger refused, so its zeros carry a positive control rather than reading as constants; a separate 14-scenario recovery-correctness suite (`continuum.benchmark.phase6`) encodes the crash points from the durable-execution survey as executable assertions, and a 7-fault risk-injection suite (`benchmarks/fault_injection/`) grades failure handling. - **Adversarial audit**: the full MCP surface was audited over the live protocol; three defects were found and fixed. Method and reproduction steps in [test.md](test.md). ### Horizon-scale benchmark (real runs, no invented numbers) Generated: 2026-10-08T18:27:24.485759 Horizon scenarios: 5 Passed: 4 Failed: 1 Accuracy: 0.8 Unnecessary escalation: 0.2 Repair precision: 0.8 Duplicate side effects: 0 Duplicate work: 0.0 Compression: 0.26 Side effects performed: 630 Duplicate re-attempts refused by the ledger: 79 | Scenario | Cycles | Years | Correct | Actual | Accuracy | | --- | --- | --- | --- | --- | --- | | horizon_steady_progress_year | 141 | 2.3 | resume | resume | 1.0 | | horizon_quarterly_drift_year | 141 | 2.3 | repair | request_human | 0.0 | | horizon_budget_exhaustion_year | 141 | 2.3 | request_human | request_human | 1.0 | | horizon_compaction_stress_year | 177 | 2.87 | resume | resume | 1.0 | | horizon_abort_condition_year | 141 | 2.3 | abort | abort | 1.0 | Fault-injection: 7 scenarios, detection 1.0, unsafe 0.0 ## MCP Integration CONTINUUM ships an MCP server so an agent can record progress, checkpoint, and route external side effects through the ledger without embedding the library: ```bash uv pip install -e ".[mcp]" CONTINUUM_MCP_MUTATING_CLIENTS=your-client-name continuum-mcp ``` On Windows, the env-prefix form has no PowerShell equivalent, so set the variable first: ```powershell uv pip install -e ".[mcp]" $env:CONTINUUM_MCP_MUTATING_CLIENTS = "your-client-name" continuum-mcp ``` Thirteen tools over stdio. Three are read-only (`continuum_validate`, `continuum_resume`, `continuum_list_actions`); ten mutate. Side effects are two-phase (claim, perform, complete), and mutating tools deny by default behind an allowlist. Agent-reported state is recorded with `Origin.EXTERNAL_AGENT` provenance and marked `REQUIRES_REVIEW`. Verification details, including crash recovery at startup and the end to end Claude Code test, are in [references/mcp.md](references/mcp.md). If a registered server reports `CONNECTION_CLOSED`, the cause is almost always `PATH` resolution rather than the server itself: [docs/api/mcp.md](docs/api/mcp.md#troubleshooting) has the diagnosis and two remedies. ## Framework Integration Nine adapters ship in `src/continuum/adapters/` (one in-process facade plus eight integrations), all optional installs so the core stays standard-library-only: | Adapter | Class | Notes | |:--|:--|:--| | Generic Python agent | `GenericAgentAdapter` | In-process facade; writes trusted (`Origin.DETERMINISTIC`) state. | | Filesystem sandbox | `FilesystemSandboxAdapter` | Local directory sandbox, no external service, default for docs and CI. | | Python in-process | `PythonInProcAdapter` | Runs Python in a temp workdir, records via ledger. | | Container | `ContainerAdapter` | Docker backed, guarded skip when `docker` is absent. | | Browser | `BrowserAdapter` | Playwright backed, guarded skip when not installed. | | Kubernetes | `KubernetesAdapter` | `kubectl` backed, guarded skip when not configured. | | OpenAI Agents SDK | `OpenAIAgentAdapter` | Experimental. Hooks `ToolContext` / `RunHooks`; optional `openai-agents`. | | LangGraph | `LangGraphAgentAdapter` | Experimental. Wraps a `StateGraph`; optional `langgraph`. | | LangChain | `LangChainAgentAdapter` | Experimental. Drops `checkpoint_node` into an LCEL `Runnable` pipeline and the `create_agent` tool-calling loop; optional `langchain`. | Each adapter records progress through the ledger and routes external effects through the two-phase intercept/complete protocol. All three framework adapters have end-to-end integration tests and have been driven against a **live OpenRouter model**, where the runs surfaced and then closed an LLM argument-drift dedup gap and two OpenAI-adapter bugs, including a live hard-crash (`os._exit(137)` mid-side-effect) proof per adapter. Full usage, live-model results, and runnable examples for every adapter are in [references/adapters.md](references/adapters.md). Production LangGraph apps can also keep their native persistence API: `make_continuum_checkpointer(storage)` implements LangGraph's `BaseCheckpointSaver` over CONTINUUM's storage, so every put lands in the same hash-chained, provenance-tagged event log (see [references/adapters.md](references/adapters.md)). Three further production frameworks are covered by thin, SDK-free hook surfaces in [`adapters/thin.py`](src/continuum/adapters/thin.py): | Framework | Interception surface | Entry point | |:--|:--|:--| | CrewAI | global before/after tool-call hooks | `install_crewai_hooks(storage, run_id)` | | AutoGen core | `FunctionTool.run_json` wrapped in place | `wrap_autogen_tool(tool, storage, run_id)` | | Pydantic AI | async Hooks capability | `Agent(capabilities=[wrap_pydantic_ai_hooks(storage, run_id)])` | For stacks none of these reach: `continuum gateway` enforces claims on outbound HTTP from any language, `continuum.otel.make_span_processor(storage)` turns existing OpenTelemetry tool spans into evidence, and `continuum serve` exposes the same operations as the MCP tools over a language-agnostic JSON wire protocol (stdio, or HTTP via `--transport http` with `CONTINUUM_SERVE_TOKEN` auth). ### Resuming agent- or MCP-reported runs State reported over MCP, or through the OpenAI adapter, carries `Origin.EXTERNAL_AGENT` provenance and resolves to `request_human` until confirmed. LangGraph and LangChain runs use `Origin.DETERMINISTIC` and resume directly. To clear review and resume: ```bash continuum confirmBecome a sponsor: GitHub Sponsors, or add FUNDING.yml custom link if you prefer another platform.
## License Apache 2.0 - see [LICENSE](LICENSE). --- Deep reference material: - [references/install.md](references/install.md) - prerequisites, install levels, package map, verification - [references/concepts.md](references/concepts.md) - semantic checkpoints, validation, ledger, recovery modes, contract - [references/architecture.md](references/architecture.md) - data model, event log, projection, storage, checkpointing, recovery engine, security - [references/adapters.md](references/adapters.md) - framework adapter usage and live-model validation results - [references/api.md](references/api.md) - Python and adapter API - [references/cli.md](references/cli.md) - full CLI command list, exit codes, state diff - [references/mcp.md](references/mcp.md) - MCP server status, verification, open questions - [references/bench.md](references/bench.md) - CONTINUUM-Bench design - [references/quickstart.md](references/quickstart.md) - install, examples, the proof scripts - [references/e2e.md](references/e2e.md) - end to end autonomy test walkthrough - [references/testing.md](references/testing.md) - test suite layout and conventions - [references/related-work.md](references/related-work.md) - annotated related work and citation audit Architecture, in five related pages. Read them in this order if you want the whole picture, or start at the data if you already know the shape: - [references/architecture-spec.md](references/architecture-spec.md) - the authoritative text-only specification, written so it can be handed to an image model - [references/architecture-data.md](references/architecture-data.md) - every figure read from the code at the current `main` commit, with `file:line` citations (guarded by `tests/test_architecture_data.py`) - [references/architecture-diagram.md](references/architecture-diagram.md) - the complete system view: clients, adapters, the deny-by-default MCP server, SDK internals - [references/architecture-flow.md](references/architecture-flow.md) - verified Mermaid flow graph, every node label matching `architecture-data.md` - [references/architecture-drawing-prompt.md](references/architecture-drawing-prompt.md) - the prompt that turns the diagram into an image Integration and attestation: - [references/integration-architecture.md](references/integration-architecture.md) - attaching to any system, and what the field does about it - [references/auto-resume-integration.md](references/auto-resume-integration.md) - auto-resume architecture, current state, and open problems - [references/attestation.md](references/attestation.md) - event-chain attestation design (implemented) - [references/implementation-plan.md](references/implementation-plan.md) - remaining roadmap items, status verified against the tree - [references/citation-audit-2026-08-24.md](references/citation-audit-2026-08-24.md) - audit of external claims about the related-work list ## Quick links - [Issues](https://github.com/Cyrax321/CONTINUUM/issues) for bugs/features - [Discussions](https://github.com/Cyrax321/CONTINUUM/discussions) for design proposals - [Release Notes](docs/release-notes.md) - [Release Checklist](docs/release-checklist.md)