Plan tab selected
Original brief
The leeromos-core topology decision needs an operator ruling before the package count grows: adopt the modular-mono hybrid (packages/* + apps/* in one repo, shared harness) now, or hold for a polyrepo deploy-model spike. The plan was revised once after review; the reviewer wants the sign-off recorded.
Acceptance criteria: Topology ruling recorded; the deploy model (single repo, per-app deploy) is signed off or a spike is filed.
No attention signal — progressing normally.
Plan v2 (the modular-mono hybrid) addressed the review finding, but the reviewer will not sign off until the topology ruling is recorded. The call is an operator one: adopt the hybrid now and file the polyrepo split as a follow-up spike, or hold for the spike first.
Approve the modular-mono topology
Expected outcome: Moves the brief to Ready and files the polyrepo deploy-model spike as a linked follow-up brief.
Also runs: Auto-create a follow-up brief for the polyrepo deploy-model spike.
Hold for a deploy-model spike
Returns the brief to Specifying for the planner to run the deploy-model spike.
Approach A — polyrepo split: 1. Split each package + app into its own repo with an independent release train. 2. Publish @leeromos/* to a private registry; apps consume the pinned versions. 3. Per-repo CI; the harness is vendored into each repo. Rationale: independent deploy cadence per surface.
Approach B — modular-mono hybrid (revised after review): 1. Keep packages/* + apps/* in ONE repo with pnpm workspaces + TypeScript project refs. 2. ONE inherited harness + ONE lockfile (no per-repo vendoring drift). 3. Per-app deploy targets (the console deploys independently of the worker). 4. A polyrepo split stays possible later, but only once a surface needs a separate release train. Rationale: a polyrepo split now fractures the shared harness + the lockfile for no current benefit.