Naftiko Fleet v1.0.0 Alpha 2 — "Catamaran" Is Here

The second alpha of the Naftiko Fleet — code name “Catamaran” — is out. The release was announced today by Jerome Louvel in Naftiko Discussions #7, and it lands as the biggest single update yet for the open-source Framework, the VS Code extension, and the Backstage templates.

Two-hundred-sixty-four commits across the Fleet since First Alpha. 477 changed files in the Framework alone, with +54,952 / −11,011 lines moved. Four contributors. Two scripting language additions. One new transport layer. The shape of Spec-Driven Integration is firming up.

This post is the operator’s-eye view of what shipped — what to install, what changed under the hood, and which limitations to plan around before Alpha 3.

What is Naftiko Fleet, in one paragraph

The Naftiko Fleet is the leading product for Spec-Driven Integration — a set of tools, documentation, and services to design, create, deploy, and manage capabilities that reinvent API integration for the AI era. Capabilities are declared entirely in YAML; the engine parses them and exposes them via MCP, Agent Skill, or REST out of the box. The Community Edition shipping today bundles the open-source Naftiko Framework, the VS Code extension, and the Backstage templates — everything needed to get from idea to running capability without leaving the open-source stack.

What’s new in Alpha 2

The headline list — each item ties to a real shift in how capabilities get built and operated:

• OpenAPI interoperability. Import OpenAPI 3.x and Swagger 2.0 specs directly into Naftiko capabilities. Export back to OAS 3.0. Two-way means existing API estates start contributing capabilities on day one — no rewrite required.
• Inline scripting. Groovy, JavaScript, and Python steps inside a capability with sandboxed execution and Control Port governance. The data-shaping that used to require a sidecar service can now live in the spec.
• Observability. Distributed tracing on the W3C Trace Context standard, RED metrics, a Prometheus endpoint, and Grafana dashboards. SRE-grade telemetry is now built into the engine instead of bolted on.
• OAuth 2.1 server auth. JWT validation with OIDC discovery for exposed REST and MCP endpoints. The “how do I secure my MCP server?” question now has a one-line answer in the YAML.
• DDD aggregates. Define a domain function once, project it through REST and MCP adapters via ref. The same business operation gets exposed through every protocol consumers actually use without copy-pasting.
• Unified MCP transport. The MCP runtime moved from Jetty to Restlet, picked up HTTPS support, and now passes MCP tool hints through as ToolAnnotations. One transport, both stdio and streamable HTTP.
• VS Code modeline detection. Capability files no longer have to live as *.naftiko.yml. A modeline header is enough — fits how teams already organize repos.
• Spectral linting upgrades. Custom rule functions for aggregate semantics, Control Port presence, script defaults, and unique namespaces. The ruleset now enforces the patterns the spec was designed around.
• Backstage catalog linking. A custom scaffolder action links consumed APIs to generated components — the catalog gets the wiring, not just the file.
• Linux ARM64 CLI. Native binary now ships alongside macOS ARM64, Linux AMD64, and Windows AMD64.

Naftiko Framework — biggest update yet

The open-source foundation gets the lion’s share of the changes. Full notes are in the Framework v1.0.0-alpha2 release. The areas that matter most for adoption:

• OpenAPI import/export moves the framework from “you write Naftiko YAML by hand” to “you bring your existing OAS and the framework meets you where you are.”
• Inline scripting steps unlock the data-mediation work that previously fell out of capability scope. Groovy for JVM teams, JavaScript for the broad audience, Python for data-engineering shops — same execution model, same governance.
• OpenTelemetry-based observability with a Control Port is the quiet but load-bearing change. Capabilities now emit traces, metrics, and logs by default; the Control Port is the governance hook that decides what gets emitted, sampled, and forwarded.
• OAuth 2.1 resource server closes the loop for production deployments — REST and MCP endpoints can now be put behind a real identity provider with one declarative block.
• DDD-inspired aggregates move the spec from “one HTTP operation per capability” toward a richer domain model where the same business function can be projected through multiple protocols. This is the path to capabilities that are bigger than a single endpoint.
• Restlet-based MCP transport with HTTPS and ToolAnnotations support brings the MCP surface up to parity with what the latest MCP clients expect.
• Enriched JSON Schema and 15+ engine bug fixes round out the polish.

Naftiko Extension for VS Code

The free VS Code extension gets the changes that matter most when authoring capabilities at the keyboard:

• Modeline-based detection so the extension activates on any YAML file with the right header, not just files named *.naftiko.yml.
• Inline Spectral validation with the Alpha 2 custom rules — the same governance the CI runs.
• Automatic schema and rules sync from Framework CI — the editor stays in lockstep with the spec without a manual upgrade dance.
• Broader IDE compatibility — minimum required VS Code version was downgraded to widen the install base.

The extension is not on the Marketplace yet. Download the VSIX from the release assets and install via Extensions → ⋯ → Install from VSIX…

Naftiko Templates for Backstage

The Backstage templates pick up three changes:

• Custom scaffolder action that links the consumed APIs of a capability through Backstage’s Catalog API — components and APIs get wired together at scaffold time.
• Modeline header in scaffolded files so the VS Code extension lights up on freshly generated capabilities.
• Skeleton aligned with the latest spec — newly scaffolded capabilities reflect the Alpha 2 schema, not the Alpha 1 one.

TechDocs and Kubernetes plugin integration are tracked for a later release.

Coming in Alpha 3 — Naftiko Operator for Kubernetes

The Kubernetes Operator has been prototyped but is not part of this release. It is planned for Alpha 3, and it is what closes the loop on the Fleet’s Kubernetes-native story — capabilities as CRDs, the Operator reconciling them into running engines, and the same Control Port governance applied at cluster scale. If you want to influence the shape of the Operator API, the Fleet Roadmap is where that conversation is happening.

By the numbers

Known limitations

Honest list — what is not in your hands yet:

• VS Code extension is not on the Marketplace. VSIX install from release assets only. Marketplace listing is in flight.
• Backstage TechDocs and Kubernetes plugin integration are not yet in the templates.
• Kubernetes Operator is prototyped but unreleased — Alpha 3.
• Windows CLI installation is not yet straightforward; macOS, Linux AMD64, and Linux ARM64 are smoother today.

If any of these are in your critical path, raise it in Discussions — the prioritization for Alpha 3 is being shaped now.

Links

• Fleet v1.0.0-alpha2 release notes — the full Fleet changelog
• Framework v1.0.0-alpha2 release notes — the full Framework changelog
• Fleet Wiki — overview, install paths, fleet-level architecture
• Framework Wiki — specification, tutorials, use cases
• Fleet Roadmap — what is coming next
• Naftiko Discussions — where to ask, share, and contribute

This is still a pre-release. Breaking changes will continue between alphas as the spec converges toward 1.0 GA. That is the deal — early visibility for early feedback. If you are running Naftiko in any non-trivial environment, CONTRIBUTING.md is the door in.

Catamaran is in your hands. Tell us what runs, what breaks, and what you want next.