Skip to content
PawOS Docs

Electron Architecture

Process model and packaging.

A single main process supervises one renderer window for the primary UI plus a lightweight overlay window for the companion. Both windows share the same preload-exposed IPC bridge.

Product disclosure

Implemented

This reference page describes the current PawOS implementation surface for Electron Architecture. Internal details are disclosed for clarity but are not a promise that every internal type is a public API.

This disclosure is part of the PawOS documentation for Electron Architecture. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.

What users see

  • Reference docs are intended for engineers and administrators who need to understand process boundaries, IPC, runtime action types, evidence records, entitlements, billing isolation, connector architecture, and current API/SDK status.
  • Users should expect architectural disclosure, not marketing copy.
  • Reference pages should identify which contracts are public, internal, implemented, partial, or reserved extension points.

What PawOS does

  • PawOS is an Electron application with main, preload, and renderer responsibilities separated by typed bridges and IPC.
  • Runtime actions use shared request/result types, with main-process plugins performing the actual side effects.
  • Evidence, billing, connector, and entitlement systems are intended to be separable so one subsystem cannot silently stand in for another.

Permissions and boundaries

  • Internal TypeScript types are not automatically public API guarantees.
  • A documented extension point is not the same as a shipped external SDK or supported third-party plugin API.
  • Architecture docs should not imply a provider, connector, payment path, or runtime exists unless it is actually wired.

Evidence and records

  • Reference claims should be traceable to implemented modules, tests, build outputs, or explicit limitation statements.
  • For compliance-style use, Work Records and connector/billing records matter more than natural-language claims.

Limitations and user responsibility

  • Public API and SDK surfaces remain limited unless a page explicitly documents a supported external contract.
  • Architecture may evolve; changelog and release notes should identify user-visible behavior changes, not only implementation details.

Warning

PawOS can assist with planning, coding, automation, connectors, billing flows, and system operations, but the user remains responsible for reviewing plans, confirmations, diffs, command effects, connector side effects, billing actions, and final outputs before relying on them.

Related