Spike: enterprise edition architecture — private module strategy for compliance features (SSO, SCIM, SIEM)

[vybe]

Summary

Research and define the architecture for a Trinity Enterprise edition — compliance-gating features (SSO/SAML, SCIM provisioning, SIEM log export) that live in a private repository, not the public OSS repo, while remaining easy to develop, test, and ship alongside the core platform.

Context

Trinity is moving toward a dual-tier model:

• Community (OSS): MIT or AGPL — full agent runtime, scheduling, multi-channel, orchestration. Everything currently in this repo.
• Enterprise (paid): SSO/SAML, SCIM, SIEM export — the three features that cause a SOC2/ISO audit to fail without them. These must not ship in the public repo.

The problem this spike solves: how do we build enterprise features in a private repo while keeping one coherent development process, shared CI, and a clean integration path into the Trinity runtime?

Research Questions

1. Module integration mechanism — Python package (installable via private PyPI / GitHub Packages), git submodule, or plugin registration hook in main.py? What is the least coupling with the most isolation?
2. Development workflow — Can a developer work on enterprise features locally alongside the OSS repo without manual symlinks or path hacks? What does the local dev setup look like?
3. CI/CD — How does the private repo's CI run tests against the OSS core? Does the OSS repo publish a dev package the enterprise repo depends on?
4. License enforcement — What mechanism gates enterprise features at runtime? License key (signed JWT), environment flag, or trust-based (enterprise customers get the private package URL)?
5. Trinity Cloud integration — How does the Cloud deployment bundle the enterprise package? Is it a build step or a runtime dependency?
6. Repository structure — One private monorepo (trinity-enterprise) or separate repos per feature domain?

Acceptance Criteria

• Spike document written: compares at least 2 integration approaches (Python package vs. plugin hook) with tradeoffs on maintenance burden, local DX, and CI complexity
• Proof-of-concept: a minimal enterprise feature (stub SSO endpoint) wired into Trinity via the chosen mechanism, running locally without modifying the public repo
• Local dev setup documented: steps from clone to running Trinity + enterprise features in under 15 minutes
• CI strategy defined: how the private repo tests against the OSS core without tight coupling
• Decision recorded: chosen approach with rationale, documented in docs/planning/ENTERPRISE_ARCHITECTURE.md

Technical Notes

The three enterprise features that gate the first enterprise license:

1. SSO / SAML 2.0 / OIDC — replaces email-code login for enterprise users; integrates with Okta, Azure AD, Google Workspace
2. SCIM provisioning — automated user lifecycle (create/deactivate) driven by corporate directory
3. SIEM log export — real-time audit log push to external SIEM (Splunk, Datadog, Elastic) via webhook or scheduled export

All three are purely additive — they don't require modifying core runtime code, which makes them good candidates for a clean extension point.

Related license decision: whether OSS edition ships as MIT or AGPL determines how hard the enterprise boundary needs to be enforced technically. AGPL + commercial license means the package separation is for clean development, not security through obscurity.