Context
ORB (the review-gate engine) is mature and differentiated as a self-hosted product, but a deep architecture audit found it has no reusable "core" package the way the Autonomous Miner System already has — its actual review/decision logic lives almost entirely inline inside the Worker app itself, with no separable boundary. A future hosted/cloud edition of ORB — gittensory (the company) centrally operating the review gate for customers who don't want to self-host it — needs that boundary to exist first, the same way a hosted miner service can already cleanly depend on the miner's existing core package today.
This milestone has two phases. Phase A grows @jsonbored/gittensory-engine's ORB-side content substantially (not a new package — a new "orb-core" package would collide with the existing, unrelated src/orb/ broker/relay code). Phase B builds the actual cloud-readiness work on top of that foundation: multi-tenancy and data isolation, fleet/ops management, scaling and capacity, billing/usage metering, secrets management at scale, self-serve onboarding, and incident/SLA readiness. gittensory also already had a centrally-hosted review-execution path once and deliberately retired it — today's central Worker is a broker/relay only. Going hosted again means reviving central execution or centrally operating a fleet of self-host containers; most of Phase B applies to either path.
Scope summary
- Phase A — engine growth (7): verify
git mv rename recognition, finish the settings/ slice, extract content-lane/*, converge the scoring/rules twins, sweep for pure logic stranded in I/O files, extract the rest of signals/, extract signals/engine.ts itself.
- Phase B — multi-tenancy & isolation (9): eliminate global-singleton state that would leak across customers.
- Phase B — fleet/ops management (9): tooling to run, version, and roll back more than one deployment at a time.
- Phase B — scaling & capacity (12): move past architecture that assumes one operator, moderate volume.
- Phase B — billing/usage metering (6): a real quota/plan/invoice concept where none exists today.
- Phase B — secrets management at scale (5): centralized credential custody beyond GitHub tokens.
- Phase B — self-serve onboarding (6): true signup/provisioning where today everything is manual.
- Phase B — incident/SLA readiness (5): status page, paging, and a real SLA commitment.
How to use this issue
Phase A's 7 items are genuinely sequenced — work them in order, since later phases depend on earlier ones (the shim mechanism, the coverage wiring, and the risk classification all build on each other). Phase B's 52 items are largely independent of each other and can be worked in any order once Phase A is far enough along that a clean core boundary actually exists to build against — though nothing strictly blocks starting Phase B research/spec work in parallel with Phase A's later stages.
AMS Cloud Readiness cross-reference (added 2026-07-12)
See also #5230 (Epic: AMS Cloud Readiness) — a research pass comparing how Sentry/GitLab/Supabase/Cal.com/others split self-host from cloud recommended ORB and AMS converge on the SAME pattern going forward ("identical core package + thin, additive control-plane wrapper" — the Supabase/Ghost/Sentry shape), rather than each inventing its own bespoke cloud architecture. The key asymmetry: this epic's own Phase A is retrofitting a core-package boundary that AMS already has from day one (packages/gittensory-engine + packages/gittensory-miner) — AMS Cloud Readiness skips straight to this epic's Phase-B-equivalent categories. Keep the two milestones' approaches aligned as both progress.
Context
ORB (the review-gate engine) is mature and differentiated as a self-hosted product, but a deep architecture audit found it has no reusable "core" package the way the Autonomous Miner System already has — its actual review/decision logic lives almost entirely inline inside the Worker app itself, with no separable boundary. A future hosted/cloud edition of ORB — gittensory (the company) centrally operating the review gate for customers who don't want to self-host it — needs that boundary to exist first, the same way a hosted miner service can already cleanly depend on the miner's existing core package today.
This milestone has two phases. Phase A grows
@jsonbored/gittensory-engine's ORB-side content substantially (not a new package — a new "orb-core" package would collide with the existing, unrelatedsrc/orb/broker/relay code). Phase B builds the actual cloud-readiness work on top of that foundation: multi-tenancy and data isolation, fleet/ops management, scaling and capacity, billing/usage metering, secrets management at scale, self-serve onboarding, and incident/SLA readiness. gittensory also already had a centrally-hosted review-execution path once and deliberately retired it — today's central Worker is a broker/relay only. Going hosted again means reviving central execution or centrally operating a fleet of self-host containers; most of Phase B applies to either path.Scope summary
git mvrename recognition, finish thesettings/slice, extractcontent-lane/*, converge thescoring/rulestwins, sweep for pure logic stranded in I/O files, extract the rest ofsignals/, extractsignals/engine.tsitself.How to use this issue
Phase A's 7 items are genuinely sequenced — work them in order, since later phases depend on earlier ones (the shim mechanism, the coverage wiring, and the risk classification all build on each other). Phase B's 52 items are largely independent of each other and can be worked in any order once Phase A is far enough along that a clean core boundary actually exists to build against — though nothing strictly blocks starting Phase B research/spec work in parallel with Phase A's later stages.
AMS Cloud Readiness cross-reference (added 2026-07-12)
See also #5230 (Epic: AMS Cloud Readiness) — a research pass comparing how Sentry/GitLab/Supabase/Cal.com/others split self-host from cloud recommended ORB and AMS converge on the SAME pattern going forward ("identical core package + thin, additive control-plane wrapper" — the Supabase/Ghost/Sentry shape), rather than each inventing its own bespoke cloud architecture. The key asymmetry: this epic's own Phase A is retrofitting a core-package boundary that AMS already has from day one (
packages/gittensory-engine+packages/gittensory-miner) — AMS Cloud Readiness skips straight to this epic's Phase-B-equivalent categories. Keep the two milestones' approaches aligned as both progress.