[FEATURE]: Subscription-adapter plugin for model-locked harnesses (Claude Code, Cursor, Windsurf)

Start by reviewing the linked opende reference implementation, especially the opende-mcp tools and the opende init entry point, and compare its integration surface with altimate-core. The issue does not name target files or tests in altimate-code; work is only defined after maintainers choose between adoption, co-maintenance, or a stable altimate-core API, with the selected path and acceptance criteria documented.

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

The problem

altimate-code is excellent when you can run it directly. But a growing number of dbt teams are standardized on subscription harnesses — Claude Code, Cursor, Windsurf — where company policy or cost constraints mean only one LLM is allowed to run.

The users most likely to want altimate-code's SQL intelligence — dbt teams at companies with strict tooling governance — are exactly the ones who can't use it today. This is a real adoption blocker.

The proposal

Ship an official subscription-adapter plugin alongside altimate-code: a thin harness layer that exposes altimate-core's deterministic engine to model-locked environments via the Model Context Protocol (MCP), with the altimate LLM agent never invoked.

Users in those environments would:

• Install the plugin — one npm install, one init command
• Get the same Rust/NAPI engine altimate-code uses: transpile, lint, lineage, PII check, equivalence, schema diff, dbt PR review with a signed verdict, impact analysis, finops, and more
• Get skills and agent personas scaffolded directly into their harness
• Never need an altimate API key or a second model

The altimate-code agent would be explicitly forbidden at the code level, not just undocumented. Users get the deterministic half of altimate-code only.

Prior art — proof of concept

I built a proof-of-concept called opende that implements exactly this. It exists because the gap is real and there was no official path.

A community fork tracking your core library is a worse outcome for everyone than an official plugin — version drift, inconsistent verdicts, confused users. The goal of this issue is to find a better path.

What I'm asking

I'd like to discuss whether Altimate would be interested in any of these:

1. Adopting this as an official plugin — maintained under the altimate-code org, with opende merged or superseded by an official implementation
2. Co-maintaining it — opende stays independent but is officially acknowledged and linked as the supported path for subscription-locked users
3. Committing to a stable public API surface in altimate-core — so community adapters can track releases without breakage

Happy to share more about the implementation, contribute code directly, or help design the integration. The demand is real — I built this because my own team needed it.

Reference implementation: https://github.com/lgwacker/opende