chore: reconcile main into dev — rooms OSS core + the Alembic merge revision (ent#443)

[dolho]

Brings #2355 (multi-agent rooms → OSS core, ent#443) back from main, plus two docs/dependabot commits, and adds the Alembic merge revision the hotfix's landing now requires.

A merge, not a rebase

dev is shared: every open PR is based on it, so rewriting its history would invalidate every clone and orphan those bases. This repo has already settled the question — 7dc2aaef chore: reconcile main into dev (merge, not rebase).

The Alembic fork — the part that actually needs care

0044_shared_sessions_oss chained off 0038_portal_chat_state, which is main's head and was the only correct parent: naming dev's head would have referenced a revision main does not carry, i.e. a boot failure on the line it shipped to. dev had meanwhile grown 0039…0043 off that same parent — two children of 0038.

Neither branch could see it alone. check_alembic_heads was green on the hotfix PR (single-head tree) and green on dev (never saw 0044). It becomes two heads here, which is where it was predicted to.

Why that is worse than it looks: alembic upgrade head is singular and resolves its target before applying anything, so a two-head graph applies zero revisions — silently, and not just the forked one. Every revision since the fork stops arriving.

Why a merge revision and not a renumber

Repointing 0044.down_revision at 0043 also yields one head and looks fixed. It is not: an install already stamped at 0044 would then be at head, so upgrade head applies nothing and 0039…0043 never reach it — permanently, silently. 0045_merge_rooms_hotfix carries a tuple down_revision, which converges from any starting state.

All three verified against real PostgreSQL:

Starting state	Revisions applied	Ends at
fresh	46	0045_merge_rooms_hotfix
stamped 0044 (took the hotfix)	6 (0039…0043 + merge)	0045_merge_rooms_hotfix
stamped 0043 (dev line)	2 (0044 + merge)	0045_merge_rooms_hotfix

and all three end with both lines' schema: rooms=3 addressed_to=1 headroom=1.

SQLite track re-checked too — init_database() records shared_sessions_tables_to_oss and the dev-side migrations, with the room tables, the addressed_to_email column and subscription_headroom_history all present.

Conflicts, both append-only

• db/migrations.py — both lines added a migration function and a MIGRATIONS entry at the same spot. Both kept: dropping either silently stops that line's schema arriving. main's rooms adoption is appended last (independent tables; appending is this list's convention).
• docs/memory/learnings.md — both appended. Both kept and re-sorted chronologically. My first pass kept each side intact but interleaved the dates wrongly — which reads as fine and is not, so it is worth saying it was caught rather than avoided.

main itself is functional

Booted a pure-OSS image built from 366cf505 and exercised the merged feature:

edition= oss | features= []
GET /api/rooms                              200  {"rooms":[]}
GET /api/enterprise/room-budget-defaults    200
POST /api/rooms  → room_1fd1ec7a13b04e0d
POST /api/rooms/{id}/messages               200
participants: ['sage','scout','admin'] | messages: 2 | status: open

Clean boot, no errors in the log beyond the expected "no Docker socket" warnings for a socket-less test container.

Related to ent#443.

🤖 Generated with Claude Code

[dolho]

/review — back-merge audit

A back-merge's risk is not new code; it is a resolution that silently drops one side. So this was checked mechanically rather than by reading diffs.

Critical findings: 0.

Both sides survive — counted, not eyeballed

MIGRATIONS list:  dev 112 | main 108 | merged 113
  lost from dev: none    lost from main: none
  duplicated: none       invented: none
registered-but-undefined: none    defined-but-unregistered: none

113 is exactly 112 + the one main-only entry. And no MIGRATIONS entry points at a function that does not exist — which is the failure a hand-resolved append conflict actually produces.

Ledger: dev 119 + main 115 → merged 121, nothing lost or duplicated, and git diff origin/dev HEAD -- docs/memory/learnings.md has 0 deleted lines — a pure addition, so the re-sort moved nothing. The file is out of date order at 9 boundaries, but every one of them is pre-existing on dev (back in July), not introduced here.

Per-file markers from both sides present in main.py, db/schema.py, db/tables.py, db/migrations.py, mcp-server/src/client.ts, architecture.md.

Submodule pins — the thing back-merges get wrong

The merge silently took dev's pin for both submodules. That is correct, and the reason was verified rather than assumed:

	dev	main	merged
.claude	e1229b39	92a56ec8	e1229b39	main's is an ancestor → fast-forward
src/backend/enterprise	a4198127	65182c14	a4198127	main's is an ancestor → fast-forward

Neither is a regression.

Migration graph

• OSS line: 46 revisions, 1 head (0045_merge_rooms_hotfix)
• Enterprise line: 17 revisions, 1 head — untouched
• check_alembic_parity: PASS · revision-id lint: 48 passed

Convergence was proven against a real PostgreSQL for all three install populations before this PR was opened — fresh (46 applied), stamped 0044 (6 applied), stamped 0043 (2 applied), each ending at 0045 with both lines' schema (rooms=3 addressed_to=1 headroom=1).

Informational — 1

dev will run the rooms double-mount until the enterprise submodule is bumped.

dev's enterprise pin still contains _register_module(app, "shared_sessions") (backend/__init__.py:265), so after this lands both routers mount. Verified on this merged tree that the OSS one wins the match order, which is the transition state #2355 was designed for:

POST /api/rooms: 2 handler(s)
   [0] shared_sessions.router                     deps=['get_room_principal']
   [1] enterprise.backend.shared_sessions.router  deps=['requires_entitlement…', …]

Not a defect in this PR, and not fixable here. But it means one action is still outstanding: bump src/backend/enterprise on dev once trinity-enterprise's rooms-removal PR merges — otherwise enterprise_features keeps advertising shared_sessions as an entitled module for a surface every build now serves.

Clean

• SQL / data safety — no new DDL; 0045 is an empty merge revision (upgrade() is a docstring only).
• Auth — no route definitions changed by the resolution; the only route-table effect is ordering, verified above.
• Enum completeness — no new enum values; the MIGRATIONS list is the analogous closed set and is counted exhaustively above.
• Credentials — the one credential-adjacent file (_migrate_secret_settings_encryption, dev-side) arrives byte-identical to dev.
• Frontend / tests — arrive unmodified from their respective sides.

Nothing to fix in this PR.

[vybe]

Drive-by review — I merged the three PRs this reconciles (#2355 → trinity-enterprise#444 → #2360) while this branch was being cut, so flagging one thing it is missing.

The enterprise submodule pin is not in this diff

origin/dev      src/backend/enterprise -> a4198127
origin/main     src/backend/enterprise -> 2a5def35
PR #2364 head   src/backend/enterprise -> a4198127     <-- unchanged

But the branch does bring the OSS half across:

$ git show pr2364:src/backend/main.py | grep -n shared_sessions
129:from shared_sessions.router import budget_router as room_budget_router
130:from shared_sessions.router import router as rooms_router
1072:app.include_router(rooms_router)
1073:app.include_router(room_budget_router)

And the tree still pinned at a4198127 still registers the paid module:

$ git show a4198127:backend/__init__.py | grep -n '_register_module(app, "shared_sessions")'
265:    _register_module(app, "shared_sessions")

Both routers carry identical prefixes — /api/rooms and /api/enterprise/room-budget-defaults — so as it stands, an entitled build off dev mounts rooms twice.

What that actually costs

Not a crash. register_enterprise(app) is called at line 1143, after the OSS mount at 1072–1073, so the OSS routes win the match and the enterprise ones become shadowed dead weight. The real damage is the thing #444's own body gives as its reason for existing: _register_module still succeeds, so shared_sessions appears in enterprise_features and GET /api/settings/feature-flags advertises an entitlement for a surface every build now ships. The paid module's schema applier also still runs (harmless — the DDL is byte-identical and IF NOT EXISTS — but it is a second owner of three tables).

That is precisely what #2360 was cut to prevent on main. The same step is owed here.

Why git will not tell you

The gitlink and the new directory are independent paths with no textual conflict, so a merge that takes one without the other is a perfectly clean merge. No public CI catches it either — no workflow checks out the submodule (build-without-submodule passes because it omits the paid tree, and prod-image-smoke boots without it). The only check that would is a boot with the submodule mounted, i.e. /verify-local.

Fix

Move the pin in this same commit — to 2a5def35 at minimum, matching main:

git update-index --cacheinfo 160000,2a5def3567ce4dfbe25ae686a1dbef61c1dbb78a,src/backend/enterprise

Worth considering ff0a4f15 instead (2a5def35 + trinity-enterprise#436, the ent#435 enterprise half) — unlike main, dev does carry the OSS counterpart services/secret_settings.py from #2330, so on this branch that pin is safe and closes the pair. 6d82a3fa on top is docs-only.

The rest looks right on the two items I checked: 0045_merge_rooms_hotfix.py is present as the merge revision, and db/migrations.py is in the diff. Full context in #2361.

[vybe]

Validated via /validate-pr: correct reconcile shape (merge, not rebase — 7dc2aae precedent), both append-only conflicts kept both sides, and the 0045 Alembic merge revision converges all three stamp states on real PG (pg-migrations green here). I updated the branch for the 4 dev commits that landed after the cut (merge cc735b0): one both-sides-append conflict in main.py router mounts — rooms routers (ent#443) + portal_asks_router (ent#428) both kept, both before register_enterprise. Zero markers tree-wide, imports verified, compiles. Head seeds + regression diff green; base seed 99999 red is the known baseline-job noise. Merging as a merge commit per reconcile convention.