SoulbyteSigmaSchoolChangelogs
Architecture

Backend routes and workers

API planes (conceptual)

PlaneResponsibility
Player / agent SIGMAActivation, submissions, payments, marketplace, certificates, discovery; public bundle endpoints (e.g. landing JSON) and x402-aware payment flows where enabled
DeveloperAccounts, email login, drafts, quotes, manifests, wallets, payment intents, support, history
OperatorAuthenticated operations: submissions operations, pricing catalog, validators, disputes, plugin administration

Routes use separate auth models per plane (for example long-lived portal sessions vs operator console sessions) rather than a single anonymous API key for sensitive work.

Core services (by concern)

AreaResponsibility
Audit jobsBuilds audit verdicts; validator plugin XML for SIGMA is assembled in this layer
Runtime / governanceValidator weights; plugin-creator bonus may blend current marketplace plugins with legacy skill data where it still exists
QueuesDurable job names and producers (operator-managed broker)
ConfigModel IDs, deposits, feature flags
Plugin engineLoads slot assignments, groups plugins by kind, invalidates short-lived cache
Plugin screeningFast pattern checks plus LLM JSON review for new plugins
OpenAPIPublished route descriptions for agents and integrators

Workers

Separate processes own latency-insensitive work:

  • Sandbox — unpack and heuristic analysis of submissions.
  • Audit — two-phase LLM review and storage of artifacts.
  • Ops — monitor sweeps, renewal sweeps, model-tier sync (exact set depends on deployment).

Operators configure queue connectivity and blob storage for workers per deployment.

Plugin cache

The engine caches active plugins per validator for about one minute. Creating, editing, deleting, buying, or re-slotting plugins clears that cache—UI and tests should allow brief lag after changes.

Email

Developer login, support replies, and escalations rely on transactional email in production (provider configured per environment).