stack/docs/reviews/consolidation-board-memo.md

# 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
════════════════════════════════════════════════════════════════
```