Skip to content
GRPNR.

Options — candidate portfolios

Four genuinely different shapes. Per-app dispositions listed; diagrams show deployables and ownership. B is the simplest/most-native shape; D is the “do less / defer” candidate.

Option A — Full Factory

Essence: Robert builds all 9 apps as standalone services in a Robert-owned factory plane (separate repo or factory/ path). Own stack; integrates with Zaruba’s repos only via APIs/generated clients. The original batch-1/batch-2 blueprint executed as designed.

flowchart LR
  subgraph RF[Robert's Factory - own repo]
    L[Migration Ledger<br/>Temporal+PG]; T[Question Triage]; M[Fleet Monitor]; H[Parity Harness]
    KG[Knowledge Graph MCP]; RW[Rewrite Engine]; SC[Scaffolder]; DL[Decommission Ledger]; MB[MBUS Bridge]
  end
  subgraph Z[Zaruba monorepo-development]
    ZC[core plane]; ZI[internal plane]
  end
  RF -- API/clients only --> Z
  M --> G[(Grafana)]
  L --> P[(Postgres)]
  • DDD boundaries: factory = its own bounded context; zero shared code with greenfield; duplicate task/workflow concepts on both sides.
  • Test seams: full control — every app trophy-tested in isolation; but parity harness must integrate with Zaruba’s services via contract tests only.
  • Evolution path: factory grows unbounded; exit = abandon repo. Duplicates Zaruba’s tasks + workflow-management from day one [E3].
  • Rough cost: 9 apps ≈ months of build before first value; two Temporal platforms, two task systems, two UIs to operate.

Option B — Zaruba-Native Extension

Essence: no standalone factory. Everything is thin extensions inside Zaruba’s repos: triage = new TaskType + screens on his tasks service; ledger = rows/views on his workflow-management + coverage-status conventions; monitor = Grafana dashboards in monorepo-infra; harness = per-domain extensions of his reconciliation-oracle pattern; KG/rewrite/scaffolder/MBUS/decommission = drop/defer. Robert’s fleet works inside Zaruba’s conventions.

flowchart LR
  subgraph Z[Zaruba monorepo-development - system of record]
    ZT[tasks svc<br/>+agent TaskType]; ZW[workflow-management<br/>+migration rows]; ZR[reconciliation oracles<br/>per domain]
  end
  subgraph I[monorepo-infra]
    G[(Grafana<br/>+fleet dashboards)]
  end
  RFleet[Robert's agent fleet] --> Z
  RFleet -.telemetry.-> G
  • DDD boundaries: perfect greenfield fit — one task system, one workflow platform; but Robert owns no bounded context; every change lands in Tomas-reviewed paths.
  • Test seams: inherits Zaruba’s vitest discipline; fast loops; zero factory-specific suites to own.
  • Evolution path: cheapest start, hard ceiling — anything agent-scale (dedup, cost ledger, stall detection) must argue its way into core-plane services owned by a decision-bound solo founder [E8].
  • Rough cost: near-zero build; high coordination cost per change; Robert’s committed deliverable (fleet monitor) reduced to dashboards blocked on the billing gate [E5].

Option C — Two-Lane Thin Factory

Essence: Robert owns a thin factory lane built ON Zaruba’s substrate. Per app: (1) work ledger = one Encore service in the internal plane (Postgres SSOT: unit × state × attempts × cost × blocking-question; durable execution via Zaruba’s workflow-management; absorbs claim-before-work queue AND decommission data as row types); (2) triage = agent-question layer on Zaruba’s tasks (new TaskType + embedding dedup + rate limits + knowledge write-back — the unsolved part [E7]); (3) fleet monitor = adopt base + thin layer (doc-12 verdict, Robert’s committed deliverable); (4) dual-run parity harness = Robert’s flagship build (shadow-traffic diff service + characterization generation + impact-selected tests; generalizes Zaruba’s 3-oracle pattern); (5) KG scoped down to legacy-audit evidence extractor; (6) rewrite DROP; (7) scaffolder DROP; (8) decommission MERGED into ledger; (9) MBUS DROP as app (shadow-tap inside harness only). CODEOWNERS partition + OWNERSHIP.md + shared MADR ADR log per research/12.

flowchart LR
  subgraph Z[Zaruba monorepo-development]
    subgraph CP[core plane - Tomas DRI]
      ZT[tasks]; ZW[workflow-management]; ZO[reconciliation oracles]
    end
    subgraph IP[internal plane - CODEOWNERS partition]
      WL[work-ledger svc<br/>Robert DRI - PG SSOT]
      QT[triage layer<br/>dedup+ratelimit+writeback]
      VH[dual-run harness<br/>shadow diff + parity]
    end
  end
  subgraph I[monorepo-infra]
    G[(Grafana + thin fleet layer)]
  end
  QT -- TaskType via proposal API --> ZT
  WL -- durable exec --> ZW
  VH -- generalizes --> ZO
  VH -- shadow taps --> LEG[legacy runtime lab<br/>pinned EOL images]
  Fleet[Robert's fleet] --> WL
  Fleet -.OTel.-> G
  KG[legacy-audit evidence extractor<br/>tree-sitter, scoped] --> WL
  • DDD boundaries: factory = real bounded context (work-unit lifecycle) with Robert as DRI; human-task and workflow-execution invariants stay in Zaruba’s aggregates — no duplication [E3].
  • Test seams: ledger/triage/harness each Encore services with vitest integration tests against Docker PG (house pattern); harness additionally contract-tests against legacy lab; monitor layer = pure functions over OTel streams.
  • Evolution path: ledger → adds lanes for old-estate 1→N split later; harness → per-flagship adapters (Deal Factory M4+); KG extractor → productizes to MCP only if audit demand proves it; exit per-app (each independently droppable).
  • Rough cost: 3 thin services + 1 real build (harness) + dashboards; weeks not months; one runtime substrate (Zaruba’s), one UI (his admin + Grafana).

Option D — Defer-Most

Essence: ship only (3) fleet monitor (adopt+thin) and the doc-11 assessment now. Everything else waits for: Tomas’s answers to the 3 open questions, the M4 Orders gate, and the billing unblock. Rationale: Tomas is decision-bound; building factory apps before his rulebook stabilizes risks building on sand.

flowchart LR
  M[Fleet Monitor<br/>adopt+thin, local-first] --> G[(Grafana)]
  A[Assessment deliverable<br/>doc-11 runbook] --> T2[Tomas]
  W[everything else] -. wait for M4 gate +<br/>open-question answers .-> Later[re-decide]
  • DDD boundaries: none new; zero collision risk.
  • Test seams: monitor layer only.
  • Evolution path: maximal optionality; but the fleet Robert is supposed to run has no ledger, no triage, no harness — his own execution lane stays manual until re-decision.
  • Rough cost: minimal build; opportunity cost = Robert’s fleet idles below capability for ~months; first-mover value of triage/harness (unsolved in literature, [E7]) forfeited.