## Summary
Move the cross-domain shared trees out of the repo root into a single
`platform/` umbrella. Domain-scoped trees (`submitqueue/`, `stovepipe/`,
`runway/`) keep their own `core/`, `entity/`, `extension/`.

| From | To |
|------|----|
| `core/{errs,metrics,consumer}` | `platform/{errs,metrics,consumer}` |
| `core/httpclient` | `platform/http` |
| `entity/*` (`change`, `mergestrategy`, `messagequeue`) |
`platform/base/*` |
| `extension/*` (`counter`, `messagequeue`) | `platform/extension/*` |

Details:
- `platform/http`: package renamed `httpclient` -> `http`; `net/http`
aliased as `nethttp` inside the package; callers that also import
`net/http` use a `phttp` alias.
- `platform/base`: root doc package renamed `entity` -> `base`; `change`
/ `mergestrategy` / `messagequeue` preserved as subpackages.
- Rewrites all Go import paths and Bazel labels; updates `Makefile`
schema/admin paths and `go:generate` roots.
- Docs refreshed to the `platform/` layout (`CLAUDE.md`, package
READMEs, RFCs), documenting current state only.

> Stacked on #256 (hermetic Go SDK). Review/merge that first.

## Test plan
- [x] `make gazelle` clean (BUILD files in sync)
- [x] `make build` — 201 targets build (hermetic)
- [x] `make test` — 54/54 unit tests pass

Made with [Cursor](https://cursor.com)

## Test Plan


## Issues


## Stack
1. @ #257
1. #258
1. #259
1. #260

---------

Co-authored-by: Cursor <cursoragent@cursor.com>

## Summary

### Why?

The "Rebase Stacked PRs" job silently no-ops when the repo's "Automatically delete head branches" setting is on. On merge, GitHub deletes the merged head branch, which auto-retargets every child PR's base from the merged head branch to the merged base (e.g. main) *before* the job runs. The job discovers children via `gh pr list --base <merged-head>`, which then returns nothing — so it rebases nothing, force-pushes nothing, and still reports success. Run #257 (and #256 before it) did exactly this, leaving the downstream stack (#258/#259/#260) with doubled diffs that had to be rebased by hand.

The fix is to keep "Automatically delete head branches" off (now done at the repo level) and let this workflow own head-branch cleanup. With the setting off, GitHub leaves child bases untouched, the lookup finds them, and the job rebases the stack and then deletes the merged branch itself — for both stacked and non-stacked PRs.

### What?

- Document the hard requirement that "Automatically delete head branches" stays off, with the retarget-race rationale, in the workflow header.
- Log a clear line when a merge has no child PRs instead of returning silently.
- Clarify the branch-deletion step: it runs on every merged PR (stacked or not) and is skipped only when a child rebase failed; fix the misleading "All stacked PRs rebased successfully" message that printed even on no-op runs.

No behavior change on the happy path — the job already deleted the merged branch on success; this makes the intent explicit and the logs legible.

## Test Plan

- ✅ `python3 -c "import yaml; yaml.safe_load(open('.github/workflows/rebase-stack.yml'))"` — YAML parses.
- Confirmed `delete_branch_on_merge` is `false` via `gh api repos/uber/submitqueue`.
- Post-merge: the next Rebase Stack run should log child rebases or "No open child PRs … nothing to rebase", then "Deleting merged branch …" and actually remove it.

Co-authored-by: Cursor <cursoragent@cursor.com>

## Summary

### Why?

The "Rebase Stacked PRs" job was silently no-opping: with the repo's
"Automatically delete head branches" setting on, GitHub deleted the
merged head branch on merge, which auto-retargeted every child PR's base
from the merged head branch to the merged base (e.g. `main`) *before*
the job ran. Its child lookup (`gh pr list --base <merged-head>`) then
found nothing, so it rebased nothing and still went green. Run #257 (and
#256 before it) did exactly this, leaving #258/#259/#260 with doubled
diffs that had to be rebased by hand.

The repo setting is now off, making this workflow the sole owner of
head-branch cleanup. But that exposed a second gap: the job only deleted
the merged branch at the end of its own run. When a child rebase
conflicts, the run intentionally keeps the merged branch (the child
still bases on it) and never fires again — so after the author manually
rebases and retargets the child, nothing ever deletes the orphaned
merged branch.

### What?

- Document the hard requirement that "Automatically delete head
branches" stays **off**, with the retarget-race rationale, in the
workflow header.
- Replace the outcome-gated single-branch delete with an invariant-based
sweep, `cleanup_orphaned_merged_branches`, that runs on every
invocation: for each recently merged PR whose head branch still exists,
delete it **iff** no open PR references it as a base or head. This:
- deletes the just-merged branch on a clean run (children retargeted
away),
- **keeps** it when an immediate child rebase failed (that child still
bases on it — deleting it would retarget the child to `main` and
recreate the broken diff),
- reaps branches stranded by an earlier conflicted run on the next
merge, once their children were manually fixed.
- Branch existence is snapshotted in one `git ls-remote`; the merged
base (e.g. `main`) is never touched. Conflicted runs also emit a
`::warning::` for visibility while still exiting non-fatally, and
no-stack merges log a clear line.

## Test Plan

- ✅ `yaml.safe_load` parses the workflow.
- ✅ `bash -n` on the extracted `run:` script.
- ✅ Simulated the sweep loop with mock data (dedup, skip-gone,
skip-base, consider-delete all behave correctly).
- Post-merge: the next Rebase Stack run should log child rebases (or "No
open child PRs … nothing to rebase"), then a sweep that deletes the
merged branch when nothing depends on it.

---------

Co-authored-by: Cursor <cursoragent@cursor.com>

…y) (#261)

## Summary
### Why?

Each service's gateway proto redefines its own `Change` message (and
SubmitQueue its own `Strategy` enum), duplicating wire contracts that
are meant to stay identical across domains. This is the proto-level gap
mirroring what `platform/base/{change,mergestrategy}` already solved for
the Go entities, and Stovepipe's upcoming gateway API would otherwise
add a third copy of `Change`.

### What?

Introduces an `api/base/` proto tree as the shared-wire-contract analog
of `platform/base/`:

- Adds `api/base/change` (`uber.base.change.Change`) and
`api/base/mergestrategy` (`uber.base.mergestrategy.Strategy`), each a
message-only contract that domains import instead of redefining.
- Teaches the hermetic codegen rule (`tool/proto/proto_codegen.bzl`) to
resolve cross-package proto `import`s (exec-root proto_path + imported
sources as action inputs) and to skip the gRPC/YARPC generators for
service-less contracts via a new `gen_services` attribute.
- Migrates the SubmitQueue gateway proto to import the shared
`Change`/`Strategy` and drops its local definitions; updates Go
consumers (land controller + unit/integration/e2e tests) to the shared
`protopb` packages.
- Makefile now creates the `protopb/` output dir and marks copied stubs
writable, so net-new proto packages generate cleanly.

Known cosmetic gazelle warning: resolving the new cross-proto import
prints "multiple rules may be imported" for the `# keep` rules_go
go_proto_library alias. It does not change generated BUILD files, the
build, or the committed-files path that consumers resolve via the root
`# gazelle:resolve go` directives.

## Test Plan
- ✅ `make proto` (regenerates stubs, including the message-only base
protos)
- ✅ `./tool/bazel build //...` (213 targets)
- ✅ `make test` (54 unit tests pass)
- ✅ `make fmt`

## Issues


## Stack
1. @ #261
1. #259
1. #260

Co-authored-by: Cursor <cursoragent@cursor.com>

## Summary
### Why?

The message queue topic-binding proto option was named `topics`, which
reads as a concrete wire topic name. It is not — it carries a stable
**logical topic key**. Each implementer maps the key to whatever topic
name its broker/queue requires (subject to that backend's naming
constraints); on our Go side the keys are `consumer.TopicKey` values,
mapped to concrete names through `TopicRegistry`. The name `topics`
invited the wrong mental model.

### What?

Rename the `google.protobuf.MessageOptions` extension `topics` →
`topic_keys` (field number `50001` unchanged, so the wire/extension
layout is identical) and reframe its doc comment to say it carries a
logical key, not a wire name. Regenerated `messagequeue.pb.go`
(`E_Topics` → `E_TopicKeys`).

This is the base of a stack; the runway contract and the contract RFC
that consume the option are updated in the branches stacked on top.

## Test Plan
✅ `make proto` — descriptor field renamed (`name=topics` →
`name=topic_keys`), field number `50001` unchanged
✅ `./tool/bazel build //...`

## Issues


## Stack
1. @ #264
1. #259
1. #260
1. #245
1. #247

## Summary
### Why?

Queue payloads are Go structs serialized with `encoding/json`, so the
wire shape is defined only by Go source. There is no language-neutral
contract a non-Go client can compile against, no explicit
topic-to-payload binding, and no distinction between a domain's private
wiring and a published cross-domain contract.

### What?

Doc-only — the design of record for message queue contracts
(`doc/rfc/messagequeue-contract.md`):

- **Contract language: Protobuf**, serialized as **protobuf JSON**
(`protojson`) so payloads stay self-describing JSON on the wire. The
`.proto` is the authority and the Go binding is generated from it, so it
cannot drift (no hand-authored struct, no drift test to keep them in
sync).
- **Topic binding:** a custom `topics` proto option (defined in
`api/base/messagequeue`) carries the wire topic names on the message
itself, read back by reflection — not on the publish/consume hot path,
which still resolves topics from a `consumer.TopicKey` via the registry.
- **Location by audience:** external contracts (something outside the
owning domain depends on them) live in `api/{domain}/messagequeue/`;
internal ones in `{domain}/core/messagequeue/`, with the split enforced
by Bazel `visibility`.
- Documents the accepted protojson conventions (snake_case field names,
UPPER_SNAKE enums, int64-as-string) and why JSON Schema, binary proto,
and Avro were rejected.

## Test Plan
- ✅ `make lint` (doc-only)

## Issues


## Stack
1. #264
1. @ #259
1. #260
1. #245
1. #247