docs(rfc): propose service-scoped extensions, splitting SubmitQueue storage per service

[roychying]

Why?

Both SubmitQueue services depend on one thirteen-store Storage aggregate, so a gateway controller can resolve BatchStore and nothing objects. The split is already the documented design — status-list-api.md says the gateway owns the request log and three read models, and the orchestrator's stores are pipeline working state — but nothing expresses it.

Separating the services onto their own databases already works today; what does not is provisioning. The schema is one filegroup, so each database gets all thirteen tables, including the nine or four that service never reads.

What?

An RFC for the layout rule: when only one service of a multi-service domain resolves an extension, its Factory, aggregate, implementations, mocks and schema move to {domain}/{service}/extension/{ext}/, while the behavioural
contracts stay shared.

The split is on reachability, not declaration — what a service may resolve is decided by its aggregate's accessors, so that is the part worth scoping. Moving the contracts too would add no enforcement and cost every domain-level caller a dependency on a service package.

Scope is storage only. changeprovider, validator, conflict, buildrunner and speculation are orchestrator-only and would qualify, but none has a schema and none is the reason for this change; they wait for a later RFC. queueconfig stays shared — gateway-only today, expected in both.

Test Plan

Issue

[behinddwalls]

Agent-written.

4/9 split is right. Split Factory/Storage by service; keep store interfaces at submitqueue/extension/storage/, or the core/ inversion is in this RFC.

[behinddwalls]

Agent-written.

Layout

platform/extension/counter/              # shared; mysql impl; each service has its own table
submitqueue/
├── extension/
│   ├── storage/                         # errors, Config, store interfaces
│   └── queueconfig/                     # shared — stays here
├── gateway/extension/storage/
│   ├── storage.go                       # Factory/Storage (4)
│   └── mysql/schema/                    # 4 tables
└── orchestrator/extension/storage/
    ├── storage.go                       # Factory/Storage (9)
    └── mysql/schema/                    # 9 tables

No store is shared today. RequestLogStore is gateway-owned (orchestrator publishes logs; gateway persists).

A later shared store: interface in submitqueue/extension/storage/, accessor on both aggregates, explicit table ownership. Do not reassemble the 13-way Storage.

queueconfig stays at submitqueue/extension/queueconfig/. It will be used by both services; do not move it under gateway.

[behinddwalls]

Agent-written.

Requesting changes: split Factory/Storage by service, but keep store interfaces in submitqueue/extension/storage/. Moving *_store.go inverts core/ and is in scope for this RFC. queueconfig stays domain-level (shared). Preserve a colocated schema union.

[roychying]

@behinddwalls Stack now uses your layout. contracts and their mocks stay at submitqueue/extension/storage/, only the aggregate, implementation, mocks and schema are service-scoped. Also added the union schema target and dropped the gateway schema from the orchestrator suite.

But still one more concern. Splitting contract from implementation costs some cohesion. a table's interface now sits in a different tree from its MySQL code and its .sql, and ownership reads from the two aggregates rather than the directory. If the store sets stay disjoint forever, keeping them together is probably the nicer end state?

Went with yours anyway because it avoids the inversion now. moving the contracts to service level only becomes clean after the other extensions refactor lands and core/changeset can follow them. plus it's compatible with a store both services need later if we will have such one.

so imo if the store sets stay disjoint indefinitely and the extensions move is definitely happening, cohesion wins and it's worth revisiting before this is entrenched. otherwise I'm happy here.