bubbles-isolated-ml-sidecar

Enforces compute-only isolation of Python ML sidecars from data stores via typed service tiers.

1|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-isolated-ml-sidecar-pkirsanov
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: bubbles-isolated-ml-sidecar
Source: https://github.com/pkirsanov/bubbles/tree/main/skills/bubbles-isolated-ml-sidecar
Command: npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-isolated-ml-sidecar-pkirsanov

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Python/ML sidecars often gain direct access to databases, caches, and queues through drivers and connection URLs, creating a large security blast radius when fast-churning ML dependencies are compromised. This Skill enforces an architectural invariant where the Python tier is compute-only and reaches persistent data exclusively through a strongly-typed service tier over a typed contract wire. ## Core Features & Use Cases - Invariant Definition: Defines the non-negotiable rule that Python/ML sidecars must not hold credentials, import data-store drivers (psycopg, asyncpg, sqlalchemy, redis, kafka, pymongo), or read infra connection URLs (DATABASE_URL, REDIS_URL, RABBITMQ_URL). - Two Sanctioned Transports: Supports both service-gated (HTTP with protobuf-only bodies) and bus-gated (message-bus typed payloads) realizations without mandating one. - Guard Enforcement: Specifies a python-compute-only-guard with three static scans (forbidden drivers, infra URL reads, REMOVED-marker persistence) wired into pre-push and CI with no bypass flags. - Audit Checklist: Provides a 7-step agent-runnable audit covering driver scans, env-delivery checks, transport posture, and conformant-by-architecture N/A decisions. - Use Case: When reviewing a new embedding service, run the audit checklist to confirm it imports no database drivers, receives no infra URLs in its environment, and communicates with the Rust/Go service tier only via protobuf messages. ## Quick Start Audit my Python ML service to verify it holds no database credentials or drivers and reaches data only through the typed service tier.

Frequently Asked Questions about bubbles-isolated-ml-sidecar

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I isolate a Python ML service from database access?▼

Make the Python sidecar compute-only: remove all data-store drivers (psycopg, asyncpg, sqlalchemy, redis, kafka) and infra connection URLs from its environment. Route all data access through a strongly-typed Rust or Go service tier over protobuf HTTP or typed bus messages.

What is a python-compute-only-guard and how do I wire it into CI?▼

A python-compute-only-guard is a static scan of the Python surface checking for forbidden driver imports, infra URL reads, and REMOVED-marker persistence. Wire it into your existing pre-push hook and CI pipeline through the repo runner, with no skip or force bypass flags.

Can a Python sidecar keep FastAPI under the compute-only invariant?▼

Yes, FastAPI may be retained purely as a protobuf ASGI transport with a proto route registry. What must be removed is the storage layer and any JSON business API; the protobuf transport itself is a sanctioned part of the service-gated realization.

Should I use HTTP protobuf or a message bus for sidecar communication?▼

Both are sanctioned realizations of the same invariant. Choose service-gated HTTP with protobuf bodies for synchronous request/response products, and bus-gated messaging for event-driven architectures; do not force one shape onto the other.

When does the isolated ML sidecar rule not apply?▼

Products with no Python data plane, such as Go-only or Rust-only services, are conformant by architecture and need no guard. Python used only as a build-time tool for codegen or linting is also out of scope; record the N/A decision explicitly in the spec.

Why must the compute-only guard have no bypass flag?▼

A bypass flag would let a future change silently reintroduce a data path, defeating the invariant. Instead of bypassing, a legitimately data-owning surface is added to the guard's reviewed allowlist, keeping every exception explicit and auditable.