Hardening and Public Launch

Hardening and Public Launch turns Pomavo into a product you can operate, evaluate, and extend in the open. The release focuses on deterministic automation, stronger identity boundaries, safer outbound networking, faster asset delivery, shared packages, and this public documentation site.

A typed automation engine extracted into its own library

The automation engine is now a dedicated, typed library rather than a loose collection of worker executors. The Automation Engine defines one canonical contract for node ids, ports, data types, object properties, and generic list shapes.

That contract is used by the editor, server-side resolver, runtime orchestrator, and validation layer. When you wire a graph, design-time resolution and runtime execution agree on what each node accepts and emits.

Deterministic graph execution

The extracted engine evaluates automation graphs through a clear orchestration spine. It starts from matching triggers, resolves inputs through exact graph edges, executes nodes, gates false branches, and skips expensive output materialization when nothing downstream consumes the value.

Loops and schedulers are first-class. ForEach runs a downstream sub-graph once per item and Collect forms an ordered list when iterations complete. Scheduler nodes fork a run, snapshot the upstream values needed later, and resume the deferred branch through the Job Pipeline.

Runtime validation that fails loud

Automation bugs are expensive when they silently turn into null three nodes later. Pomavo now validates runtime output shapes against the declared contract as values move between nodes.

This makes automation behavior deterministic and testable. The conformance suite covers contracts, runtime shapes, resolver parity, graph execution, dynamic handles, node families, and real graph scenarios.

RS256 and JWKS authentication

Authentication has been hardened for public operation. The Auth service issues RS256-signed JWTs, publishes public signing keys through JWKS, and the .NET services validate tokens using cached JWKS keys instead of shared symmetric secrets.

The token path is also cookie-first for the browser. When you select an organization, the Auth service issues a one-hour JWT with user and organization claims, sets it as the pomavo_jwt HTTP-only cookie, and lets frontend API clients send it automatically with credentials: include.

This design keeps signing authority in the Auth service while letting API services validate tokens independently. It also supports cross-subdomain organization flows without exposing bearer tokens to frontend JavaScript.

SSRF protection for outbound server requests

Public launch required a stricter outbound request boundary. Pomavo now validates server-side URLs before plugin lifecycle calls, agent runtime requests, MCP discovery, MCP server calls, and model provider calls.

The shared validator requires absolute HTTP or HTTPS URLs, requires HTTPS outside approved development localhost cases, disables automatic redirects, resolves DNS itself, and blocks private or sensitive address ranges. It also blocks metadata.google.internal explicitly.

Cookie-only browser sessions

The web client no longer needs to store or manage API bearer tokens in JavaScript. The shared API client sends the HTTP-only pomavo_jwt cookie automatically, and the server authentication layer reads the cookie only when there is no Authorization header.

That header precedence is useful because non-browser callers can still use API keys or bearer tokens where appropriate. Browser sessions get safer default behavior, while integrations and automation clients keep explicit machine authentication.

See the Security Model for how identity, permissions, API keys, plugin sandboxing, and tenant isolation fit together.

CDN-served attachment delivery

Attachments now resolve through a public storage CDN host rather than raw object-storage endpoints. Presigned URLs are signed directly against the CDN host, and nginx forwards the original host so SigV4 signatures remain valid.

This improves the public deployment shape in three ways: browsers do not need to reach the raw MinIO endpoint, CORS is easier to reason about, and attachment delivery can be separated from app and API traffic.

Open-source @pomavo/ui and @pomavo/sdk

The shared UI and SDK packages are now published under the @pomavo npm scope. Plugin authors can build against the same primitives Pomavo uses, and the first-party GitHub plugin consumes the packages through public imports.

The packages are versioned, built, typechecked, and published through CI. Package publishing uses npm trusted publishing with OIDC and verifies that the tag version matches the package version before publishing.

1
2

import { createPomavoClient } from "@pomavo/sdk/client";
import { Button } from "@pomavo/ui";

Public docs and Query DSL highlighting

This documentation and marketing site is now part of the product surface. You can point users to architecture docs, plugin docs, security docs, release notes, and the full Query Language reference.

The Query DSL page includes syntax-highlighted examples for filtering, sorting, grouping, aggregation, references, date literals, and bulk mutations.

1
2
3
4

status != "Done"
group by assignee
return assignee, count() as open_tickets, avg(
quot;Story Points") as avg_points
order by open_tickets desc

Elastic License 2.0 adoption

Pomavo now ships with the Elastic License 2.0. The source is available for use, copying, distribution, and derivative works under the license terms, while preserving important limits around offering the software as a competing hosted or managed service.

CI hardening for public work

CI now gives public contributors and maintainers clearer guardrails. The web workflow installs dependencies, checks formatting, runs ESLint, runs TypeScript build mode, and builds the web app. The .NET workflow restores and tests the unified test project. The docs workflow builds this site and deploys it through GitHub Pages.