Decide repo structure / release process for the economy plugins (monorepo?) — revisit before open-sourcing

Multi-repo releases for the economy suite are getting complicated. Capture the options and revisit before going open source (the decision interacts with how external contributors will build/release).

What's actually causing the pain (observed)

1. Shared-library version dance. A hibernia-framework change (e.g. 1.0.1→1.0.2) means: change → publish → bump the pin in treasury + business-rian + treasury-api-plugin → rebuild each → juggle repo.paradaux.io vs mavenLocal. Recurs on every framework change.
2. Non-atomic cross-cutting changes. The Bedrock fix touched 7 repos (economy-schema, business-rian, treasury-ingest, hibernia-framework, ChestShop-3, realty, economy-explorer) as 7 PRs / 7 reviews / 7 merges — half-merged states are possible.
3. Schema ↔ code coupling across repo lines. economy-schema (Flyway) and the code that reads it (treasury-rest-api mappers, business mappers, explorer SQL) version independently; a migration and its consumers can't land/test together.
4. Per-repo release PRs + branch sprawl. ~7 develop→main PRs, mixed branches (some main, some develop, realty pushes upstream), manual Flyway workflow_dispatch.

What a monorepo fixes vs not

Fixes: 1–4 — atomic cross-cutting changes, one release train, kills the version dance, co-locates schema with its consumers. Doesn't fix / new costs:

• Mixed build systems stay mixed — Gradle (most), Maven (ChestShop), pnpm/Next (explorer, tesks-ui), Flyway (schema). Needs a top-level orchestrator + affected-only build/test.
• Deploy fan-out stays — jars→Paper PVCs, images→Harbor/Argo, schema→Flyway. Monorepo unifies building, not the 4 deploy targets.
• Loses clean fork/upstream relationships.

Suggested scope (partial monorepo, not all-in)

In (share the framework + DB, release together): hibernia-framework*, treasury (+treasury-api), business-rian (+business-api), treasury-api-plugin, treasury-ingest, economy-schema, treasury-rest-api, economy-explorer, integration-tests. Out: ChestShop-3 (vendored fork — keep mergeable with upstream), realty (pushed to MCN upstream mainline), tesks/tesks-ui (separate product/org). * hibernia only if it has no consumers outside these plugins; otherwise keep it independently published.

Cheaper first step (do before any migration — ~a day, reversible)

• Gradle composite builds (includeBuild) — consumers build hibernia from source and substitute the dep: no publish, no version bump, atomic. Removes the #1 pain without merging repos.
• Shared version catalog (libs.versions.toml).
• Coordinated-release tool (release-please / changesets-style) instead of hand-driven develop→main + tag + changelog per repo.

Recommendation

1. Now (or before OSS): composite builds + version catalog + release tooling — kills the framework-version dance cheaply and reversibly.
2. If cross-repo atomicity is still biting: consolidate the economy core (the "In" list) into one orchestrated-build repo with affected-only CI.
3. Do not make a single mega-monorepo of everything (fork + upstream + separate product make that strictly worse).

Open questions to settle the decision

• Does hibernia-framework have consumers outside these plugins?
• Can one CI pipeline build+deploy the right artifacts per changed path, or is deploy per-repo today?
• Team size / review model (monorepo trades per-repo CODEOWNERS granularity for atomicity).

Claude offered to prototype the composite-build wiring (hibernia → treasury/business) to feel the difference before committing — pick that up when revisiting.