Integrations ​

Platform capabilities, evidence levels, and the follow-up each host requires — rendered from the verified facts layer, never from page prose.

Audience ​

Users running Tenetora on a specific coding-agent platform.

Task path ​

1. Find your platform in the matrix below; it states the maximum configurable capability for the verified product version, not the state of your machine.
2. Complete the required follow-up column — trust review, restart, or reload — before relying on full runtime behavior.
3. Learn the evidence levels below, so tenetora status output is read honestly.
4. Re-check after any plugin or hook change; activation states can move back to trust review.

Evidence levels ​

tenetora status and tenetora doctor grade how a runtime state is known, from strongest to weakest:

1. runtime-observed — a matching source actually executed recently.
2. host-api-verified — the host API or registry confirms enablement or trust.
3. config-verified — the official configuration is complete and enabled.
4. inferred — the effective source is inferred from discovery order.
5. file-present — a file exists; nothing more is claimed.
6. unknown — the platform cannot verify reliably right now.

A file on disk is never promoted to "runtime active". Runtime observation stays on the local machine and records the project hash, source fingerprint, version, and event time — never prompts, tool payloads, absolute project paths, or secrets.

One runtime per platform and project ​

Lifecycle skills may exist in both global and project scope, but one platform and one project run exactly one runtime adapter:

• With both scopes installed, a single runtime owner is kept; the other scope still refreshes skills.
• A detected duplicate runtime is reported as blocked, never treated as double protection.
• On hosts that offer both, native plugin hooks and project fallback hooks are mutually exclusive.
• Cleanup removes only unmodified Tenetora-owned adapters that match a known release template; anything foreign, modified, or ambiguous stays untouched.

Capability states and acknowledgement ​

Capability states describe the verified ceiling and the required action, not marketing: active (the configuration satisfies the platform contract on this host — it does not mean the current session has already executed events), active-partial (the host lacks an equivalent mandatory stop boundary, so part of the runtime ceiling is unavailable), skills-only (no portable runtime hook standard exists on this host — this is a supported degraded capability, not a broken install: lifecycle skills keep rules, guards, and workflows available; only runtime hooks and observation are absent), needs-trust-review (the host requires an explicit trust decision before runtime parts activate), unknown (the platform cannot currently verify this state, and it is displayed as unknown rather than guessed), and covered (this scope's skills are complete while another scope owns the runtime).

Two observation states sit below active and each names its remedy: runtime-not-observed (the configuration exists, but no execution of the current runtime has been observed yet) and runtime-observation-stale (the configuration exists, but no recent evidence matches the current version). Both resolve the same way: restart or reload the host, trigger one real event — start a session, send a prompt — then re-run tenetora doctor. An install receipt alone never proves activation.

Platform notes ​

• The native plugins for Claude Code, Codex, and ZCode are user-level capabilities; a project-scope install on those hosts provides lifecycle skills, not a second runtime.
• Pi ships skills plus an auto-loaded TypeScript extension: the user-level extension loads automatically, while the project-scope extension stays gated by Pi's project trust and is reported as needs-trust-review until the host's decision is observable.
• OpenCode and Pi both cap at active-partial: neither host offers the full mandatory stop/subagent contract a stronger integration requires.
• Generic Agents remain skills-only: lifecycle skills and the CLI, with no portable runtime hook standard.

This matrix lists the platforms verified against a product version — it is not a promise of native support for arbitrary platforms. A host not listed here has no verified capability statement; absence means "not yet verified", never "supported".

Acknowledging a finding records that you understood it and deliberately deferred action — it never changes the runtime. An acknowledgement carries a single-line reason, expires after at most 90 days, is written to the governance trail, and cannot suppress a blocking finding. When the underlying evidence fingerprint changes, the old acknowledgement lapses on its own.

Limitations ​

• The matrix shows the verified snapshot only; unknown states are displayed as unknown, never downgraded to "supported".
• Follow-up actions are required where listed; skipping them leaves the platform in a reduced state.
• Hosts do not expose identical APIs; Tenetora reports the real ceiling instead of guessing.
• Unlisted hosts have no verified capability statement; the matrix never implies native support for arbitrary platforms.

Next steps ​

• See Quickstart for install availability.
• See Security for hook trust decisions.