# Board of Directors — Monorepo Consolidation Brief ## mosaic/stack → mosaic/mosaic-stack --- # PHASE 1: INDEPENDENT POSITION STATEMENTS --- ## CEO — Independent Position ``` POSITION: APPROVE with scope discipline enforced REASONING: This consolidation is strategically overdue. Two repos doing related work creates coordination overhead, duplicated context switching, and fragmented mental models. The decision to make the NEW repo the base is correct — it's the more mature platform. The four work packages are well-decomposed. WP4 first is the right call: fast win, no risk, unblocks everything. The dependency chain (WP4 → WP2 → WP1, WP3 parallel) is sound. The question I'm asking: "What happens if we don't do this?" Answer: continued dual-repo friction. Every future feature that touches both repos requires context-switching and manual sync. That cost compounds. We do this now. SCOPE BOUNDARY: IN: All four work packages as specified. OUT: NestJS orchestrator rewrite, FastAPI coordinator port, Prisma schema, old Docker/infra configs. These exclusions are correct and I will enforce them if scope pressure emerges mid-execution. RISKS: - WP1 is the "big one" and the brief acknowledges it. If WP1 stalls, the whole consolidation feels incomplete. Milestone enforcement matters. - OpenBrain integration is listed as optional ("when enabled") which is the right risk-management posture. Keep it optional. - The brief says "each work package is independently shippable" — I want the team to actually treat them that way. No holding WP4 hostage to WP1 being done. VOTE: APPROVE ``` --- ## CFO — Independent Position ``` POSITION: NEEDS REVISION — phase the financial commitment REASONING: This is a HIGH complexity project with four distinct work packages. Let me break down what I see: WP4 (profiles/guides/skills): Near-zero cost. Pure copy operation. No rewrites. Ship this in days. WP2 (packages/macp): Medium cost. Python → TS rewrites of gate-runner, credential-resolver, event system, learning capture. Five to six distinct modules. Call it 1-2 agent-weeks. WP1 (packages/forge): HIGH cost. This is the expensive one. Eleven stage definitions, all persona markdowns, three Python rewrites (pipeline-runner, stage-adapter, board-tasks), brief classifier, persona override system, OpenBrain integration. This is 2-4 agent-weeks minimum. Possibly more. WP3 (plugins/mosaic-framework): Low cost. Small surface area. A few days. TOTAL ESTIMATE: 4-7 agent-weeks. At current pipeline costs, this is not trivial. ROI ASSESSMENT: Direct: Reduced dual-repo coordination overhead. Unified platform means new features ship in one place. Clear win. Indirect: Foundation for Forge-as-platform play. High upside. Timeline to ROI: 6-8 weeks post-completion before friction savings materialize. The 85% test coverage requirement is where I push back hardest. Markdown-heavy packages (stages, personas) are not unit-testable in any meaningful way. The 85% target will balloon testing costs for WP1 without proportional value. I want this scoped to the TS implementation files only — not the markdown assets. COST ESTIMATE: 4-7 agent-weeks all-in, weighted toward WP1. ROI ASSESSMENT: Positive over 3-month horizon, but only if WP1 scope is controlled. OpenBrain integration is a cost wildcard. RISKS: - WP1 scope creep (persona override system is new work, not a port) - 85% coverage target on mixed markdown/TS packages = cost inflation - OpenBrain "when enabled" could silently become always-enabled - Opportunity cost: 4-7 agent-weeks not spent on platform features VOTE: NEEDS REVISION — Revision required: Clarify 85% coverage applies to TS implementation files only, not markdown assets. — Revision required: OpenBrain integration must be gated behind an explicit feature flag, not "when enabled" ambiguity. — Revision required: Stage-gate financial approval at WP2 completion before committing to WP1 full scope. ``` --- ## COO — Independent Position ``` POSITION: APPROVE — execution order is sound, add checkpoints REASONING: The brief's suggested execution order (WP4 → WP2 → WP1, WP3 parallel) maps well to operational reality. WP4 has no dependencies and creates immediate value. WP2 unblocks WP1. WP3 can parallel WP1 because it has no dependency on WP2. Resource reality: Jason is one person managing agent pipelines. The "independently shippable" framing is critical — if WP1 hits turbulence, WP4 and WP2 still ship. That's the right posture. TIMELINE ESTIMATE: WP4: 2-3 days (copy + validate) WP2: 7-10 days (5 TS rewrites + tests) WP1: 18-25 days (11 stages + personas + 3 rewrites + tests) WP3: 3-5 days (small surface, can parallel WP1) Total wall clock: 28-38 days (sequential WP4→WP2→WP1, WP3 parallel) RESOURCE IMPACT: - No conflicts with active work flagged (v0.2.0 is done per brief) - Agent capacity for parallel tasks within WP1 is available - Human bottleneck: brief review at each milestone checkpoint SCHEDULING: Ship WP4 immediately — no reason to wait. Start WP2 as soon as WP4 is confirmed. Gate WP1 start behind WP2 completion. WP3 can start when WP1 is 50% complete. RISKS: - WP1's persona override system is NEW scope (not a port) — this is where timeline estimates will slip - No explicit milestone for "packages/macp is usable by packages/coord" before WP1 starts — risk of integration surprise late in WP1 - The "all existing tests pass" success criterion requires a baseline. Has a test run been captured pre-consolidation? VOTE: APPROVE — Condition: Add explicit milestone gate between WP2 and WP1 (integration test: packages/coord uses packages/macp event emission before WP1 begins) — Condition: Baseline test run captured before any changes land ``` --- ## CTO — Independent Position ``` POSITION: NEEDS REVISION — unknowns require investigation before WP1 REASONING: The brief correctly rates this HIGH complexity. I want to flag where I think that estimate is conservative. Python → TypeScript rewrites are not mechanical transliterations. The credential resolver, gate runner, and pipeline runner all contain business logic that must behave identically in TS. There is a real risk of semantic drift — the TS version passes tests but behaves differently from the Python version in edge cases. The JSON5 stripping issue (already solved in the current repo) is a concrete example of this risk class. The persona override system is not a port — it's NEW design. "Project-level overrides extend (not replace) base personas" is an architectural decision that hasn't been made yet, just described. The merge semantics (how do YAML frontmatter, CLI flags, and file overrides interact?) are unspecified. This is an unknown, not a design. OpenBrain integration is listed as a feature of WP1 but its interface is not specified anywhere in the brief. "When enabled" implies a runtime toggle — but the package API for enable/disable is not defined. This is a blocker for WP1 design, not an afterthought. The `depends_on_policy` semantics must be preserved exactly. The brief notes this as a constraint. I am flagging it as a technical risk: the current Python implementation's behavior under edge cases (circular deps, timeout+dep combination) must be captured as tests BEFORE the TS rewrite begins, not after. COMPLEXITY: Complex → Risky (the brief says complex, I say risky) TECHNICAL RISKS: - Semantic drift in Python→TS rewrites (credential resolver, gate runner, pipeline runner) - Persona override merge semantics are unspecified - OpenBrain interface is undefined for WP1 design - depends_on_policy edge cases uncaptured before rewrite - Integration between packages/forge and packages/coord is described at a high level but the task API contract is not defined — this is a Phase 1 (Architecture) decision, not something the brief should be pre-deciding UNKNOWNS: - OpenBrain interface/API (needs investigation) - Persona override merge algorithm (needs design, not just intent) - depends_on_policy edge case behavior in Python (needs tests captured before rewrite) - packages/coord task API stability (is it actually stable enough to depend on for WP1?) VOTE: NEEDS REVISION — Revision required: Before WP1 begins, investigation spike on (1) OpenBrain interface, (2) persona override merge semantics, (3) depends_on_policy edge cases. — Revision required: packages/coord task API must be explicitly versioned/frozen before packages/forge depends on it. ``` --- ## Contrarian — Independent Position ``` OPPOSING POSITION: The entire framing of this brief deserves challenge. We are treating the NEW repo as the base because it is "more mature." But mature at what? The OLD repo contains the entire Forge pipeline, the MACP protocol, and the credential resolver — the intellectual core of the system. The NEW repo has better infrastructure scaffolding. We chose scaffolding over core. That is a value judgment that has not been argued, just assumed. KEY ASSUMPTIONS CHALLENGED: 1. "Two repos is the problem." Two repos have a forcing function: they can evolve independently without coupling pressure. One repo means every change to packages/macp risks breaking packages/forge risks breaking plugins/macp. The monorepo coupling cost has not been counted. 2. "Each work package is independently shippable." WP1 depends on WP2 (gate types, credential resolution). WP3 depends on having the rails it injects (WP1 output). The DAG is real. Independent shippability is aspirational, not structural. 3. "The TS rewrites are straightforward ports." The Python credential resolver, gate runner, and pipeline runner encode operational knowledge accumulated over real runs. Rewrites risk losing that knowledge silently. No one has inventoried what the Python code does that the brief doesn't describe. 4. "85% coverage is achievable and meaningful." For a package where 60-70% of the files are markdown assets and the TS code orchestrates AI agents (non-deterministic outputs), 85% branch coverage is either impossible to achieve honestly or achievable only through mocking everything meaningful away. ALTERNATIVE APPROACH: Don't rewrite. Port the Python code as a subprocess sidecar for WP2 (packages/macp) while the NEW repo's TS ecosystem matures. Run Python credential-resolver via child_process for one release cycle. This eliminates the semantic drift risk entirely and ships faster. WP1 still gets ported (the Forge pipeline is the right candidate for a TS rewrite), but WP2's Python → TS rewrites are the highest-risk, lowest-value rewrites. FAILURE MODE: The scenario nobody is discussing: WP2 ships with subtle semantic drift in the credential resolver. The plugins/macp Pi bridge starts silently using wrong credentials for certain provider configurations. This is not caught by tests (because the tests mock the credential sources). This surfaces in production when an agent call fails due to wrong credentials in an edge-case configuration. The failure is silent until it matters. VERDICT: DISSENT — The "no Python in the new repo" constraint should be questioned, not accepted as a given. It is architectural dogma, not a proven engineering requirement. ``` --- ## Moonshot — Independent Position ``` MOONSHOT VISION: This consolidation is the foundation for something much larger: a fully open-source, self-contained AI development pipeline framework. The Forge pipeline, MACP protocol, and credential resolver together form a complete agentic development system. Packaged correctly, this could be published as @mosaic/forge + @mosaic/macp — reusable by any team building AI-native development workflows. The mosaic-stack repo becomes a reference implementation. Other organizations adopt the protocol. MACP becomes a standard. PRAGMATIC STEPPING STONE: Design packages/forge and packages/macp with publishable APIs from day one. This costs ~10% extra design effort: - Clean public index.ts exports (no internal leakage) - Semantic versioning baked in at package.json - README with usage examples in the package directory - No hardcoded mosaic-stack-specific paths in the package core This doesn't delay the consolidation. It just builds the right foundation. SEED TO PLANT NOW: In packages/forge/src/index.ts, export a PipelineRunner interface that takes an abstract TaskExecutor, not a concrete packages/coord import. This decouples the Forge pipeline from the specific coord implementation. Cost: one interface definition. Payoff: packages/forge can be used without packages/coord in a standalone context. Other teams can plug in their own task executors. CONNECTION TO NORTH STAR: The Mosaic North Star is an autonomous development loop. packages/forge IS that loop's orchestration layer. Getting it into a clean, publishable TS package is not housekeeping — it's the core product. The mosaic-stack platform becomes the runtime; packages/forge becomes the brain. These should be designed as separable concerns from the start. DEFERRED OPPORTUNITIES: - Publish @mosaic/forge to npm (after consolidation stabilizes) - MACP as an open protocol spec with multiple implementations - Forge pipeline as a configurable product (enterprise personas, custom stage sequences, SLA-based gate configuration) - OpenBrain as a standalone learning service (cross-project memory for any agentic system) ``` --- # PHASE 2: RESPONSE & CHALLENGE --- ## Round 1 --- ### CEO → All: Responding to Phase 1 positions ``` To the CFO: Your cost estimate (4-7 agent-weeks) is right to flag, but the opportunity cost argument runs BOTH directions. Yes, 4-7 weeks not spent on features. But every week of dual-repo friction is also a tax. I want a clearer ROI framing that accounts for the ongoing cost of NOT consolidating, not just the cost of doing it. To the CTO: The semantic drift risk is real and I take it seriously. But your revision request (investigation spike before WP1) is the right move. I'll endorse that spike. What I won't endorse is using "we don't know enough yet" as a reason to delay WP4 and WP2. Those can proceed while the spike runs. To the Contrarian: The "new repo as base" framing deserves a direct answer. The NEW repo has the infrastructure the OLD repo lacks: NestJS gateway, Drizzle, BullMQ, OTEL, CLI with TUI. The OLD repo has better intelligence. We're not choosing scaffolding over core — we're putting core intelligence into better scaffolding. The decision is correct. On the subprocess sidecar alternative: I understand the appeal but it violates "no Python in the new repo" for good reason — you don't want subprocess reliability issues in a production platform. That's an operational debt I'm not willing to carry. To the Moonshot: The publishable API design is a 10% overhead you're right about. One condition: it cannot delay WP1 delivery. If designing for publishability causes scope pressure, the publishability goes to a future sprint. Noted and logged. My revised position: APPROVE, with the CTO's investigation spike endorsed as a pre-WP1 gate. ``` --- ### CFO → All: Round 1 challenge ``` To the CEO: You asked for a dual-direction ROI framing. Fair. Current dual-repo friction cost estimate: conservatively 2-4 hours/week of coordination overhead across agent pipeline runs and context switches. At current pipeline costs, that's roughly 0.5-1 agent-week per month compounding. Over 6 months post-consolidation, that's 3-6 agent-weeks saved. So the consolidation pays for itself in 6-8 months at the optimistic end. Reasonable. I maintain that the 85% coverage scope clarification is non-negotiable — that's pure waste otherwise. To the Contrarian: The subprocess sidecar alternative is financially attractive for WP2 (eliminates rewrite cost for credential-resolver, gate-runner). I want this put to a proper technical vote, not dismissed on architectural dogma grounds. CTO — is the "no Python" constraint a hard technical requirement or a convention? To the CTO: The OpenBrain interface unknown is also a financial unknown. If OpenBrain integration balloons WP1 scope, I need a flag that says "WP1 ships without OpenBrain, OpenBrain is WP1.5." That must be explicit in the brief revision. To the Moonshot: The publishable API design is worth the 10% overhead IF it's truly just interface extraction. But "no hardcoded mosaic-stack-specific paths" could require significant refactoring of the package internals. The cost ceiling for publishability-prep is one sprint, not more. REVISED POSITION: NEEDS REVISION — still. Core asks unchanged. ``` --- ### COO → All: Round 1 challenge ``` To the CTO: The investigation spike you're calling for is operationally sound, but I need it time-boxed. A spike with no deadline is a project in itself. I'm proposing a 3-day cap: one day each on (1) OpenBrain interface, (2) persona override merge semantics, (3) depends_on_policy edge cases. Findings go into a decision doc. WP1 starts or doesn't on day 4. That's how we keep the timeline from slipping. To the CFO: The 85% coverage scope clarification is also an operational ask. I need test coverage reporting to exclude markdown assets — otherwise the pipeline will report false failures and the team will chase ghost coverage gaps. This is a tooling change (vitest coverage config) that should be part of WP2/WP1 setup, not an afterthought. To the Contrarian: The "independently shippable" challenge is correct operationally. The dependency DAG is: WP4 → none WP2 → WP4 (uses profiles/guides)? Actually no — WP2 uses credential files, not profiles. WP2 is actually independent of WP4 at a code level. WP1 → WP2 (uses gate types, credential resolution) WP3 → WP1 (injects rails from WP1) So WP4 and WP2 are truly parallel. WP1 and WP3 are blocked. The "independently shippable" language should be revised to "WP4 and WP2 can ship in parallel; WP1 and WP3 are gated on WP2 completion." To the Moonshot: The "abstract TaskExecutor interface" proposal is architecturally interesting but I need a schedule commitment. Does this add days to WP1? If so, how many? "10% overhead" isn't a number I can schedule against. REVISED POSITION: APPROVE — with time-boxed spike before WP1 and coverage config clarification added to WP2 scope. ``` --- ### CTO → All: Round 1 challenge ``` To the Contrarian: Your subprocess sidecar alternative is more technically honest than the board is treating it. The "no Python" constraint is explicitly stated in the brief's Technical Constraints section. But the REASON isn't given. I suspect it's a maintainability convention, not a hard system requirement. The credential resolver is the highest semantic-drift risk in the entire brief. If we're going to rewrite it in TS, we need to capture the Python version's behavior as a test fixture BEFORE starting the rewrite. That's my position regardless of whether the subprocess alternative is chosen. To the CFO: OpenBrain as a financial wildcard — agreed. My position: OpenBrain integration must be excised from WP1 scope entirely and treated as WP1.5 or a future brief. The interface is undefined, the learning capture/recall modules are listed in WP2 but their integration into WP1 is unclear. This is two unknowns colliding in one feature. Cut it. To the COO: The 3-day spike cap is operationally reasonable. I accept it with one condition: if the spike reveals that persona override merge semantics require a non-trivial design decision, the COO agrees to escalate rather than forcing a day-3 decision. Some unknowns require a brief, not a time-box. To the Moonshot: The abstract TaskExecutor interface is architecturally correct. Packages should not have hard imports between them at the type level — they should share interfaces. This is not 10% overhead; it's a design decision that should happen in Planning 1 (Architecture), not in this brief. I support capturing it as a Planning 1 requirement, not a Board-level decision. REVISED POSITION: NEEDS REVISION — unchanged on core asks. OpenBrain must be cut from WP1. Investigation spike required. ``` --- ### Contrarian → All: Round 1 challenge ``` To the CEO: You answered "new repo as base is correct" by listing infrastructure advantages. But you didn't answer my actual challenge: we are accepting "no Python in the new repo" as a constraint without examining it. The CEO just said "subprocess reliability issues in production" — but the credential resolver doesn't run in production hot paths. It runs at dispatch time. The reliability argument doesn't hold for a batch/dispatch operation. This assumption is still unchallenged. To the COO: Your dependency DAG correction is valuable. But you've now revealed that WP4 and WP2 are actually independent — which means the suggested execution order in the brief (WP4 → WP2 → WP1) implies WP4 must finish before WP2 starts. That's unnecessary serialization. If WP4 and WP2 are truly parallel, the timeline shrinks. Run them in parallel. To the CTO: Your position on OpenBrain being cut from WP1 is correct. I want to push further: learning.ts in WP2's package structure should also be deferred. OpenBrain capture/recall is listed in WP2's scope (`learning_capture.py` + `learning_recall.py`). If OpenBrain's interface is undefined, why is it in WP2 either? Cut it from both WP2 and WP1. Make it a separate brief. To the Moonshot: The "publish @mosaic/forge to npm" idea is premature. Publishing a package externally means committing to a public API and semver guarantees. Mosaic's pipeline is actively evolving. Publishing now creates external consumers who constrain future changes. This is a scope concern, not just a timing concern. Don't even plant this seed yet. VERDICT: DISSENT MAINTAINED on "no Python" constraint. CONCEDE: New repo as base is the right call (infrastructure argument stands even if the constraint rationale is thin). ``` --- ### Moonshot → All: Round 1 challenge ``` To the Contrarian: On npm publishing — you're right that premature external publishing creates API freeze pressure. I concede the "publish to npm" part. But the "design for publishability" seed is different: it means clean exports, no internal path leakage, abstract interfaces. This is just good package design. It doesn't require external publishing. The value is internal: other packages in the monorepo can depend on packages/forge without coupling to its internals. To the CTO: Supporting the abstract TaskExecutor interface as a Planning 1 requirement. Agreed that it shouldn't be decided at Board level. I want it explicitly listed as a Planning 1 input, not implied. To the CEO: The OpenBrain cut-from-WP1 position (CTO + me) deserves a CEO ruling. OpenBrain is the most interesting long-term play in the entire brief — cross-run specialist memory is a genuine differentiator. But it's also the most undefined. Deferring it to WP1.5 preserves the vision while removing the risk. This is the right call. To the CFO: On the 10% overhead question for publishable API design — the concrete cost is: one interface file (TaskExecutor), clean index.ts exports (already required by good TS practice), no hardcoded paths (path resolution via config, which is needed anyway for project-scoped .forge/runs/). This is genuinely low-cost. The CFO should be reassured. MOONSHOT REVISION: Amended proposal — drop external publishing, keep internal package design quality. The "plant the seed" deliverable is: - Abstract TaskExecutor interface in Planning 1 scope - Clean public API for packages/forge and packages/macp - No mosaic-stack-specific hardcoding in package cores This enables the larger play later without committing to it now. ``` --- ## Round 2 --- ### CEO → All: Convergence check ``` Convergence is emerging on several points. Let me name what's settling and what isn't. SETTLED: - New repo as base: no serious remaining challenge - Execution order (WP4 and WP2 parallel, WP1 gated on WP2): correct - OpenBrain cut from both WP2 and WP1: I'm ruling on this now. OpenBrain is deferred to a future brief. It is OUT OF SCOPE for this consolidation. This is final. - 3-day investigation spike before WP1: endorsed - 85% coverage applies to TS implementation files only: endorsed NOT SETTLED: - The "no Python" constraint rationale. Contrarian has a live argument that the credential resolver could be a Python subprocess at dispatch time without meaningful reliability risk. CTO hasn't ruled this a hard technical requirement. I need a CTO ruling before Phase 3. - The abstract TaskExecutor as a Planning 1 requirement: I want this captured in the Board Memo as a Planning 1 input. Moonshot proposed it, CTO endorsed it. Done. My ask for Round 2: CTO — is "no Python in the new repo" a hard technical constraint or a convention? Your answer shapes the Contrarian's standing dissent. COO — can you give me a revised timeline with WP4 and WP2 running in parallel? ``` --- ### CFO → All: Round 2 position ``` On OpenBrain deferral: AGREED. This was my biggest financial wildcard. With OpenBrain out of scope, my cost estimate revises to: WP4: 2-3 days (unchanged) WP2 (without learning.ts): 4-7 days (3 rewrites: gate-runner, credential-resolver, event system/watcher/webhook/discord) WP1 (without OpenBrain integration): 15-20 days WP3: 3-5 days REVISED TOTAL: 24-35 days. Better. Still significant. On the subprocess sidecar for credential-resolver: I'm in a different position from the Contrarian. I don't care about the Python/TS theology — I care about cost. If a Python subprocess saves 3 days of rewrite + test cost on the credential resolver, that's a real saving. But if it introduces an ongoing maintenance burden (two languages, subprocess reliability, eventual TS rewrite anyway), the NPV is negative. CTO's ruling on this will determine my vote. On 85% coverage: With markdown assets excluded, and without OpenBrain, this is achievable for WP2. WP1 is still a question mark because pipeline-runner.ts orchestrates AI agent calls — how do you unit test non-deterministic behavior at 85%? I want a test strategy, not just a coverage number. REVISED POSITION: APPROVE — if CTO confirms "no Python" as a hard constraint (or the subprocess alternative is formally rejected with reasoning), and if WP1 test strategy is defined before WP1 begins. ``` --- ### COO → All: Revised timeline ``` REVISED TIMELINE (WP4 and WP2 in parallel): Day 1-3: WP4 (profiles/guides/skills — copy + validate) WP2 begins in parallel Day 1-10: WP2 (packages/macp — 3 TS rewrites + event system) Day 8-10: Integration test — packages/coord uses packages/macp (milestone gate before WP1 can start) Day 8-10: WP1 investigation spike (3 days, runs parallel to WP2 tail end) Day 11-30: WP1 (packages/forge — the big one, 20 days estimated) Day 18-30: WP3 (plugins/mosaic-framework — parallel with WP1 second half, ~5 days) TOTAL WALL CLOCK: ~30 days (vs 28-38 days sequential) The parallel execution of WP4 and WP2 saves about 3 days. The investigation spike overlapping with WP2's tail end saves 3 more days. Net: roughly a week better than the brief's implied sequence. On the test strategy concern (CFO): Operationally, I need a test strategy for WP1 before it starts — not because I care about testing philosophy but because I can't schedule test review gates without knowing what's being tested. This belongs in the WP1 investigation spike output. To the CEO: Ready for Phase 3 if CTO rules on the Python question. ``` --- ### CTO → All: Round 2 — Python constraint ruling ``` To the CEO: You asked for a ruling. Here it is. "No Python in the new repo" is a CONVENTION, not a hard technical requirement. There is no system-level reason why a Python subprocess cannot invoke the credential resolver at dispatch time. The operational reliability argument (CEO's objection) is thin for a batch/dispatch operation, as the Contrarian correctly noted. HOWEVER — I am not recommending the subprocess sidecar. Here is my technical reasoning: 1. The credential resolver is invoked at task dispatch time, which means it's in the critical path of every pipeline run. A subprocess adds latency (cold start, IPC overhead) that compounds across pipeline stages. For a system that runs 11+ stage pipelines, this is measurable. 2. Debugging a Python subprocess from a TS async pipeline is significantly harder. Error propagation across the subprocess boundary is non-trivial. Stack traces break. Observability (OTEL) cannot trace across process boundaries without explicit instrumentation. 3. The long-term plan is clearly a unified TS codebase. The subprocess is a debt instrument: we pay interest on it every time someone has to context-switch to debug it, and eventually we pay it off by doing the TS rewrite anyway. RULING: "No Python" should be maintained — not as dogma, but because the TS rewrite of the credential resolver is lower-risk than the Contrarian believes, given proper test fixture capture before the rewrite. The semantic drift risk is manageable IF the Python behavior is documented and tested as a fixture first. On WP1 test strategy (CFO): Unit tests for pipeline-runner.ts can be written at the task-generation level (given this stage config and brief, assert these coord tasks are generated) without invoking AI agents. The AI-invocation layer can be tested with integration tests using recorded fixtures. 85% coverage is achievable on the deterministic parts. This belongs in the Planning 1 output. REVISED POSITION: NEEDS REVISION — reduced to two asks: 1. Investigation spike output must include Python credential resolver behavior documentation (test fixtures) 2. WP1 test strategy must be in Planning 1 output before coding begins ``` --- ### Contrarian → All: Round 2 ``` To the CTO: Your technical reasoning on the subprocess is the answer I needed. I concede on the subprocess sidecar. Latency in the critical path + OTEL boundary issues + long-term debt are real costs that outweigh the rewrite risk. Conceded. But I want my condition on record: the Python credential resolver behavior MUST be documented and tested as fixtures before the TS rewrite. The CTO just said this too. This is now a consensus position, not a Contrarian dissent. It should be in the Board Memo as a hard requirement, not a soft recommendation. New challenge for Round 2: nobody has addressed the "11 stage definitions + all persona markdowns" copy operation in WP1. The brief says "copied" as if this is trivial. But these files live in a specific directory structure in the OLD repo, and the NEW repo's package structure puts them at `packages/forge/pipeline/`. This is a one-time copy that will immediately create a divergence point: OLD repo still has the originals, agents working in OLD repo will update those, not the NEW repo's copies. Until the OLD repo is archived, these will drift. Has anyone thought about this? VERDICT: DISSENT on subprocess — CONCEDED. NEW DISSENT: Markdown asset drift between OLD and NEW repos during the migration window is an unaddressed operational risk. ``` --- ### Moonshot → All: Round 2 ``` To the Contrarian: The markdown asset drift issue is real and I want to expand it. This is actually the seed of something bigger: what if the pipeline markdown assets were pulled from a single authoritative location rather than copied? A git submodule, a symlink strategy, or — more ambitiously — a package registry that serves the markdown assets as versioned releases. Then the OLD repo's files and the NEW repo's files are the same source. No drift possible. Pragmatic stepping stone: designate the NEW repo (packages/forge/pipeline/) as the authoritative source on day 1 of WP1. Archive the OLD repo (read-only) immediately after WP4 completes. No migration window. No dual-source. This eliminates the drift risk entirely and is operationally executable within the current timeline. To the CTO: On Planning 1 capturing the TaskExecutor interface — confirmed. I want this in the Board Memo as a named Planning 1 deliverable. To the COO: The "archive OLD repo immediately after WP4" proposal should be operationally feasible. What's the risk of early archive? If agents still have working branches in the OLD repo, they'd lose their workspace. Is there any in-flight work in OLD? SEED: Archive OLD repo as read-only immediately after WP4 completes. No migration window. This is the correct operational response to the drift risk. ``` --- ## Round 3 --- ### CEO → All: Final positions before synthesis ``` We are converging. This is my pre-synthesis read. CONVERGED: 1. APPROVE with revisions — all five revisions are now articulated and have consensus. 2. OpenBrain deferred to future brief — FINAL. 3. No Python in new repo — maintained for technical reasons, not dogma. 4. WP4 and WP2 in parallel — adopted. 5. Investigation spike (3 days, time-boxed) before WP1. 6. Python credential resolver behavior captured as test fixtures before TS rewrite. 7. 85% coverage applies to TS files only. 8. Abstract TaskExecutor interface is a named Planning 1 deliverable. ON MARKDOWN ASSET DRIFT (Contrarian/Moonshot): The Moonshot's proposal is correct: archive the OLD repo as read-only immediately after WP4 completes. This is operationally cleaner than a migration window. I'm ruling this as a hard operational requirement in the Board Memo. On "in-flight work in OLD repo" (Moonshot's question): This is a pre-execution check. Before WP4 begins, confirm no active branches or in-progress work in the OLD repo. If there is in-flight work, it either merges to OLD's main before archive or migrates to NEW first. This is a COO checkpoint, not a scope item for this brief. I am ready to move to Phase 3. Polling for convergence: does any member require another Phase 2 round? ``` --- ### CFO — Round 3 convergence vote ``` CONVERGE: YES. With OpenBrain deferred, test strategy in Planning 1, 85% coverage clarified, and revised timeline of ~30 days, my financial concerns are addressed. Final cost estimate: 24-30 agent-days. ROI: Positive at 6-month horizon. Dual-repo friction elimination is measurable. Proceed. VOTE: APPROVE (revised from NEEDS REVISION). ``` --- ### COO — Round 3 convergence vote ``` CONVERGE: YES. OLD repo pre-execution check added to my checklist. Will confirm no in-flight branches before WP4 begins. Archive OLD repo as read-only = operationally correct. Timeline at ~30 days wall clock is achievable. VOTE: APPROVE. ``` --- ### CTO — Round 3 convergence vote ``` CONVERGE: YES — with conditions met. My two remaining asks (Python fixture capture + WP1 test strategy in Planning 1) are now Board Memo requirements. I can proceed to synthesis. VOTE: NEEDS REVISION → APPROVE (conditions recorded in Memo). ``` --- ### Contrarian — Round 3 convergence vote ``` CONVERGE: YES — my standing dissents have been addressed. Subprocess sidecar: conceded (CTO's technical reasoning was sound). Markdown asset drift: addressed (archive OLD repo immediately post-WP4, with pre-execution branch check). "No Python" rationale: answered by CTO with reasoning, not dogma. One recorded dissent that was NOT addressed: The WP1 test strategy for non-deterministic AI agent calls. The CTO proposed "fixture-based integration tests" but this was a Phase 2 oral position, not a planning deliverable. I want the test strategy explicitly required as a Planning 1 output, not implied. The Board Memo should name it explicitly. VERDICT: CONCEDE (main concerns addressed). STANDING DISSENT: WP1 test strategy must be an explicit named deliverable in Planning 1, not implied. ``` --- ### Moonshot — Round 3 convergence vote ``` CONVERGE: YES. My proposals are captured: - Abstract TaskExecutor interface: Planning 1 deliverable (named) - Archive OLD repo as read-only: operational requirement (adopted) - Clean public API design for packages/forge and packages/macp: Planning 1 design principle (captured) - OpenBrain deferred, not abandoned: noted as future opportunity The foundation is being laid correctly. The ambitious play (publishable @mosaic framework, MACP as open protocol) is possible from this base. We're building the right thing. VOTE: APPROVE. ``` --- # PHASE 3: SYNTHESIS ## CEO — Final Board Memo --- ``` ════════════════════════════════════════════════════════════════ BOARD MEMO — MOSAIC MONOREPO CONSOLIDATION mosaic/stack → mosaic/mosaic-stack Date: 2026-03-30 Session: Full Board (CEO, CFO, CTO, COO, Contrarian, Moonshot) Phases Completed: 3 | Rounds: Phase 1 × 6, Phase 2 × 3 rounds ════════════════════════════════════════════════════════════════ DECISION: APPROVED (with binding conditions) Final vote: CEO APPROVE CFO APPROVE (revised from NEEDS REVISION) COO APPROVE CTO APPROVE (conditional — conditions adopted into Memo) Contrarian CONCEDE (main concerns addressed; one standing dissent recorded — see below) Moonshot APPROVE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 1 — SCOPE DECISIONS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ IN SCOPE (as specified in brief): - WP1: packages/forge (pipeline-runner, stage-adapter, board-tasks, brief-classifier, persona override system, all markdown assets) - WP2: packages/macp (gate-runner, credential-resolver, event system, webhook adapter, discord formatter) - WP3: plugins/mosaic-framework (rails injection hooks) - WP4: profiles/, guides/, skills/ (copy operations) EXPLICITLY OUT OF SCOPE (FINAL — no escalation): - OpenBrain integration: DEFERRED to future brief. Removed from both WP1 and WP2. The learning.ts module in WP2's proposed structure is removed. OpenBrain will be designed as a standalone brief when its interface is defined. - NestJS orchestrator rewrite (apps/orchestrator/) - FastAPI coordinator port (apps/coordinator/) - Prisma schema and apps/api migration - Old Docker/infra configs - External npm publishing of packages/forge or packages/macp ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 2 — BINDING CONDITIONS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ These are not recommendations. Execution does not begin until all pre-conditions are met. PRE-EXECUTION (before any work package begins): [ ] Confirm no in-flight branches or active work in OLD repo (mosaic/stack). If active work exists, merge to OLD main or migrate to NEW first. (Owner: COO checkpoint) PRE-WP1 (before packages/forge coding begins): [ ] 3-day time-boxed investigation spike must complete and produce a decision document covering: (a) depends_on_policy edge cases — documented as test fixtures for the TS rewrite (b) persona override merge semantics — design decision recorded (not deferred again) (c) Python credential resolver behavior — documented as test fixtures for the TS rewrite If spike reveals that any item requires a full design brief rather than a 3-day decision, escalate to human immediately. Do not force a day-3 decision. [ ] WP2 completion + integration milestone: packages/coord must successfully use packages/macp for event emission and gate running before WP1 coding begins. ONGOING (applies throughout execution): [ ] 85% test coverage applies to TypeScript implementation files only. Markdown assets (stages, personas, rails, gates, templates) are excluded from coverage measurement. Configure vitest coverage exclusions during WP2/WP1 setup. [ ] WP1 test strategy must be the first named deliverable of the Planning 1 phase for packages/forge. It must specify how pipeline-runner.ts (which orchestrates non-deterministic AI agent calls) achieves coverage targets using fixture-based integration tests. This is NOT implied — it must be an explicit document. POST-WP4 OPERATIONAL GATE: [ ] Archive OLD repo (mosaic/stack) as read-only immediately after WP4 (profiles/guides/skills) completes and is validated in the NEW repo. No migration window. packages/forge/pipeline/ is the authoritative source for all pipeline markdown assets from this point forward. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 3 — EXECUTION ORDER (REVISED) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wall clock estimate: ~30 days Day 1–3: WP4 (profiles/guides/skills) — copy + validate WP2 begins in parallel (Day 1) Day 1–10: WP2 (packages/macp) — 3 TS rewrites + event system Day 8–10: Integration milestone gate (packages/coord uses packages/macp) Day 8–10: WP1 investigation spike (3 days, parallel to WP2 tail end) Day 11–30: WP1 (packages/forge) — Planning 1 output first Day 18–30: WP3 (plugins/mosaic-framework) — parallel with WP1 second half Note: WP4 and WP2 are structurally independent and run in parallel. The brief's implied serialization (WP4 → WP2) was revised by the Board. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 4 — BUSINESS CONSTRAINTS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. COST CEILING: 30 agent-days. If WP1 scope expands beyond the brief's defined deliverables, a scope change request must be brought to the Board before proceeding. The persona override system and brief-classifier are in scope; no new features are in scope. 2. INDEPENDENT SHIPPABILITY: Each work package ships as a standalone merge. WP4 does not wait for WP1. WP2 does not wait for WP1. Partial consolidation is better than delayed consolidation. 3. NO PYTHON: Maintained. The "no Python in the new repo" constraint is a technical discipline decision, not dogma. CTO's ruling: subprocess sidecar for credential-resolver introduces latency in the pipeline critical path, OTEL boundary gaps, and long-term maintenance debt that outweighs short-term rewrite cost savings. 4. ROI GATE: CFO will assess dual-repo friction elimination at 6 months post-consolidation. If the consolidated platform does not demonstrably reduce coordination overhead, this informs future architecture decisions. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 5 — RISK REGISTER ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ RISK 1 — Semantic drift in Python → TS rewrites (HIGH) Affected: credential-resolver, gate-runner, pipeline-runner Mitigation: Python behavior captured as test fixtures before rewrite begins (binding condition, see Section 2) Owner: CTO / Planning 1 output RISK 2 — WP1 scope creep via persona override system (MEDIUM) Affected: packages/forge timeline and cost Mitigation: Persona override merge semantics decided in investigation spike (not deferred). Scope boundary enforced by CEO: no new features during WP1. RISK 3 — depends_on_policy edge case regression (HIGH) Affected: packages/coord integration, pipeline correctness Mitigation: Edge cases documented as test fixtures before TS rewrite. Binding condition. RISK 4 — Non-deterministic test coverage for pipeline-runner (MEDIUM) Affected: WP1 test coverage target Mitigation: WP1 test strategy (fixture-based integration tests) is the first Planning 1 deliverable. 85% target applies to deterministic TS code only. RISK 5 — packages/coord API stability for WP1 dependency (LOW-MEDIUM) Affected: packages/forge integration Mitigation: WP2 → WP1 gate requires packages/coord integration test passing before WP1 begins. RISK 6 — Markdown asset drift during migration window (RESOLVED) Mitigation: OLD repo archived as read-only immediately post-WP4. No migration window. packages/forge/pipeline/ is authoritative from day 1. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 6 — STANDING DISSENTS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DISSENT — Contrarian (partially standing): "The WP1 test strategy for non-deterministic AI agent orchestration was discussed in Phase 2 but not formally committed as a Planning 1 deliverable. The oral position (fixture-based integration tests) is correct but must be an explicit document, not implied convention." RESOLUTION: The Board has adopted this as a binding condition (Section 2). The Contrarian's dissent is formally resolved by Board action, not merely noted. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 7 — SPECIALIST RECOMMENDATIONS FOR PLANNING 1 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The following items are Board-level inputs to Planning 1. They are requirements for the architects — not design decisions the Board is making. 1. ABSTRACT TASKEXECUTOR INTERFACE (Moonshot, endorsed by CTO): packages/forge must not have a hard import of packages/coord at the type level. Define an abstract TaskExecutor interface in packages/forge/src/types.ts. The concrete packages/coord implementation satisfies this interface. This decouples the pipeline from the runtime. Planning 1 must design and validate this interface. 2. CLEAN PUBLIC API DESIGN (Moonshot): packages/forge and packages/macp must have clean index.ts exports with no internal path leakage. No mosaic-stack- specific hardcoded paths in package cores. Path resolution via configuration. This is a Planning 1 design principle. 3. WP1 TEST STRATEGY (Contrarian, CTO, CFO): Planning 1 must produce an explicit test strategy document for packages/forge specifying how pipeline-runner.ts and board-tasks.ts achieve coverage targets given their non-deterministic AI agent calls. Fixture-based integration testing is the expected approach; Planning 1 must validate and specify it. 4. CREDENTIAL RESOLVER TEST FIXTURES (CTO): Before the TS rewrite of credential-resolver begins, Planning 1 (or the investigation spike) must produce documented test fixtures capturing the Python version's behavior across all three resolution paths (mosaic credential files, OC config JSON5, ambient environment) and edge cases. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SECTION 8 — DEFERRED OPPORTUNITIES (for future briefs) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ These were raised in debate and are captured for future consideration. They are NOT in scope for this consolidation. - OpenBrain integration: Cross-run specialist learning and memory capture/recall. Requires a standalone brief once the interface is defined. High long-term value. - @mosaic/forge external publication: After the consolidated package stabilizes, evaluate publishing as an open-source framework. Requires API freeze and semver commitment. - MACP as an open protocol spec: MACP's JSON schemas and event system could be standardized as an external specification with multiple language implementations. Future brief. - Forge pipeline as a configurable product: Enterprise personas, custom stage sequences, SLA-based gate configuration. Enabled by the abstract TaskExecutor interface being adopted now. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONFIDENCE LEVEL: HIGH Rationale: All six Board members converged to APPROVE. Standing dissent was resolved by binding condition adoption. Core technical risks (semantic drift, coverage strategy, OpenBrain unknowns) are mitigated by binding pre-conditions rather than left to execution discretion. The investigation spike + WP2 milestone gate before WP1 is the Board's primary risk-management mechanism. If the spike reveals new unknowns that cannot be resolved in 3 days, the Board expects escalation — not a forced decision. — CEO Mosaic Board of Directors Session closed: 2026-03-30 ════════════════════════════════════════════════════════════════ ```