Runners

Planned Tutr hosts, declared capabilities and the evidence still needed for support claims.

A runner loads a course, teaches its lessons and keeps evidence of the learner’s work. Tutr is planned for three hosts: Claude Code, Codex and embedded Pydantic AI. Each destination below remains planned and unqualified. This showcase offers no installation command or claim of demonstrated runtime support.

Planned Tutr destinations

Tutr for Claude Code — planned

A planned host destination. Capability support has not been demonstrated by this candidate. Its learner-confirmation boundary remains unqualified.

Tutr for Codex — planned

A planned host destination. Capability support has not been demonstrated by this candidate. Its learner-confirmation boundary remains unqualified.

Tutr embedded with Pydantic AI — planned

A planned application integration. Capability support and a protected learner-confirmation path still require evidence from an actual embedded application.

Build a runner

Start from the candidate’s execution, record and identity contracts. Describe implemented behaviour and its limits before requesting a future listing.

The repository’s receipt experiment report inspected host interfaces. Its synthetic tests do not demonstrate a production receipt boundary. The approved capability contract requires separate qualification for every host. Stock prompt labels, callbacks and tutor-reachable signing tools do not establish learner provenance.

A declaration needs evidence

The candidate recognises only run-checks, observe and judge. A declaration says what a runner claims to do; evidence must show that behaviour on each named host. No capability badges appear on these planned tiles because the candidate establishes none of them for Tutr. See capabilities and the conformance guide for their distinct evidence requirements.

A check passing is not proof that the learner owned a decision. Without the receipt boundary, learner calls remain unverified and cannot support settlement of objectives that depend on them. A runner with no capabilities can still deliver lessons, but settles no objective. Candidate review qualifies neither a host nor a stable runner (candidate and stable).

Before claiming support

A future listing should identify the implementation release, target format version, tested host and declared capabilities. It should link reproducible runtime evidence and disclose missing capabilities and receipt limits. The support guide explains the work; the conformance guide separates current repository evidence from the future public suite. This page lists plans only, with no released package or independent runner implied.