Source Availability

VulpineOS uses a mixed-source model. Product names and high-level capabilities are public; implementation source is open only where the product is intended to be open infrastructure.

Open Source

Product	Repository	What Is Public
VulpineOS	`PopcornDev1/VulpineOS`	Browser runtime, MCP server, web panel, TUI, Juggler bindings, no-op extension interfaces
Vulpine Mark	`PopcornDev1/vulpine-mark`	Set-of-Mark screenshots, visual element labels, JSON/SVG output, click/type/hover by label
MobileBridge for Android	`PopcornDev1/mobilebridge`	Android ADB/CDP bridge, device listing, gestures, attached server, reconnect handling
Foxbridge	`PopcornDev1/foxbridge`	CDP-to-Firefox proxy, protocol forwarding, OpenClaw/Puppeteer compatibility
Docs	`PopcornDev1/vulpineos-docs`	Product docs, setup guides, public API positioning, open-source project documentation

These repositories can describe commercial products by name, but should contain only public interfaces, no-op stubs, docs, and open-source implementation code.

Source-Closed

Product	What It Provides
Vulpine API	Hosted extraction API, recurring monitors, billing, API keys, dashboard backend, paid endpoints
Vulpine Vault	Credential references, secure autofill, TOTP, authenticated workflows, provider imports
AudioBridge	Browser audio capture sessions, audio chunk streaming, transcription-oriented workflows
MobileBridge for iOS	iOS device support and Web Inspector bridge integration
Vulpine Sentinel	Stealth health monitoring and fleet risk scoring
Vulpine Replay	Deterministic debugging and audit replay workflows
Vulpine Clockwork	Mid-session identity rotation for long-running browser sessions

Closed products may be listed in public docs and API materials. Their source code, private build wiring, browser patches, operational details, and private plan docs stay outside public repositories.

Browser Patch Boundary

A paid build may include source-closed browser-engine patches. The boundary is:

Allowed Publicly	Kept Private
Product name and user-facing capability	Patch source code for closed capabilities
Stable public protocol/tool names	Private patch files and build scripts
No-op public interfaces	Real closed-provider implementations
High-level API behavior	Internal capture, credential, iOS, or paid-service logic

Publishing a binary does not publish source code by itself. Source becomes accessible only if the patch files, implementation code, symbols with sensitive detail, debug artifacts, or source bundles are shipped or committed publicly.

Integration Pattern

Public VulpineOS builds expose stable extension interfaces. Without a provider attached, commercial extension tools return clear unavailable errors. Paid/private builds attach real providers behind the same public tool names, so client code does not need to change.

Capability	Public Surface	Source-Closed Provider
Credential workflows	`vulpine_get_credential`, `vulpine_autofill`	Vulpine Vault
Audio workflows	`vulpine_start_audio_capture`, `vulpine_stop_audio_capture`, `vulpine_read_audio_chunk`	AudioBridge
Mobile workflows	`vulpine_list_mobile_devices`, `vulpine_connect_mobile_device`, `vulpine_disconnect_mobile_device`	Android open source, iOS source-closed
Visual workflows	`vulpine_annotated_screenshot`, `vulpine_click_label`	VulpineOS and Vulpine Mark, with paid hosted endpoints in Vulpine API

Planned Commercial Products

The following names are public roadmap language. They remain source-closed unless explicitly reclassified later:

Vulpine Sentinel
Vulpine Replay
Vulpine Clockwork
Vulpine Prism
Vulpine Pulse
Vulpine Forge
Vulpine Scribe
Vulpine Harbor
Vulpine Mesh
Vulpine Oracle