SaaS Metrics
Gemini Executive Synthesis
Architectural decision to modularize GSD2's monolithic structure into shippable extensions with install infrastructure.
Technical Positioning
Evolving GSD2 from a monolithic application to a modular, extensible platform with optimized resource consumption and improved performance, enhancing its appeal as a "powerful meta-prompting, context engineering and spec-driven development system."
SaaS Insight & Market Implications
ADR-006 addresses critical architectural debt in GSD2, currently a monolithic application suffering from bloated install size (842 MB `node_modules`), slow startup, and deep internal coupling. The proposed modularization into independently shippable extensions, with dedicated install infrastructure, is a strategic imperative. This shift aims to reduce resource waste (e.g., unnecessary AI provider SDKs, browser automation tools), improve performance, and enhance maintainability. Market implication: for a "powerful meta-prompting" system, performance and resource efficiency are key differentiators. A bloated, slow monolith deters adoption, especially for developers seeking lightweight, customizable agent systems. This modularization effort is crucial for GSD2's long-term viability, scalability, and competitive positioning in the autonomous agent development market.
Proprietary Technical Taxonomy
Raw Developer Origin & Technical Request
GitHub Issue
Mar 28, 2026
Repo: gsd-build/gsd-2
ADR-006: Extension Modularization & Install Infrastructure
# ADR-006: Extension Modularization & Install Infrastructure
**Status:** Proposed
**Date:** 2026-03-28
**Deciders:** Jeremy McSpadden
## Context
GSD2 ships as a monolith: 177K LOC in the core `gsd` extension, 20 bundled extensions, 19 bundled skills, 842 MB `node_modules`. Every user gets everything — playwright, koffi, every AI provider SDK, every skill — whether they use it or not.
The extension system infrastructure is mature (discovery, registry, manifests, enable/disable, rich ExtensionAPI), but everything ships bundled. There is no mechanism to install, update, or uninstall extensions after initial setup.
### Problems
1. **Bloated install size** — 842 MB node_modules; users who never use browser automation still download playwright (14 MB); macOS-only koffi costs 86 MB for everyone
2. **Slow startup** — 20 extensions loaded eagerly; barrel import in cli.ts pulls 57K LOC on every invocation
3. **Monolithic core** — 177K LOC gsd extension is a single unit with deep internal coupling; modifying one feature risks breaking others
4. **Architecture coupling** — shared → gsd reverse dependency, gsd ↔ cmux bidirectional coupling, 5+ extensions import gsd/preferences.js by file path
5. **Provider SDK waste** — 48 MB of AI provider SDKs loaded even though users typically use 1-2 providers
## Decision
Modularize GSD2 across 7 milestones (v1.3–v1.9), each independently shippable:
### v1.3: Foundation & Install Infrastructure
- Remove unused root dependencies, relocate misp...
Developer Debate & Comments
## ADR-006 Review: Findings and Recommendations As Grok, built by xAI, I've reviewed ADR-006: Extension Modularization & Install Infrastructure based on a deep exploration of the codebase and the ADR content. Here's my analysis and recommendations. ### Overall Assessment - **Architectural Soundness**: Excellent. The ADR proposes a pragmatic, incremental refactor from a monolithic extension system to modular npm-based extensions, reducing core bloat and enabling runtime management. It aligns with GSD's evolutionary approach (e.g., v1.3 foundation). - **Clarity and Structure**: High. Well-organized with a clear problem, milestones, and tables. Futuristic dates are placeholders. - **Feasibility**: Strong. Leverages npm, Node.js, and existing Pi SDK. CLI commands and event decoupling are straightforward. - **Alignment with Codebase**: Perfect. Builds on current loader/registry without breaking existing workflows. Event bus fixes known coupling issues. - **Readiness**: Ready for v1.3 impl...
## Research Findings (2026-03-28) 4 parallel researchers completed — Stack, Features, Architecture, Pitfalls. Full synthesis in `.planning/research/SUMMARY.md`. ### Stack - **One new dependency:** `semver ^7.6.3` — everything else uses existing deps or Node.js built-ins - **npm subprocess pattern:** `spawnSync("npm", ["install", "--prefix", targetDir, "--ignore-scripts"])` — no programmatic npm API (none is stable) - **EventBus already exists:** `packages/pi-coding-agent/src/core/event-bus.ts` exposed as `pi.events` — no new event library needed - **Existing utilities:** `proper-lockfile` (concurrent registry mutation), `hosted-git-info` (git URL parsing), `undici`/native `fetch` (registry API) ### Architecture - **7 confirmed coupling sites** between gsd ↔ cmux: 5 in gsd importing cmux, 2 in cmux importing gsd types - **1 reverse dep:** `shared/rtk-session-stats.ts:5` → `gsd/paths.js` - **Discovery is directory-agnostic:** `discoverExtensionEntryPaths()` already works for any dir...
## Implementation Plan: Extension Modularization **Full plan:** [`.plans/IMPLEMENTATION-PLAN-extension-modularization.md`](https://github.com/jeremymcs/gsd-2/blob/feat/extension-system-analysis/.plans/IMPLEMENTATION-PLAN-extension-modularization.md) ### Summary **Goal:** Make GSD2 lightweight out of the box by extracting optional features into installable extensions, reducing core footprint from 177K LOC to ~15-20K LOC and `node_modules` from 842 MB to ~450 MB. ### Phases | Phase | Description | Effort | Risk | Dependencies | |-------|-------------|--------|------|-------------| | **0** | Foundation — Dependency Cleanup & Architecture Fixes | Small (1-2 sessions) | Low | None | | **1** | Extension Install Infrastructure (`gsd extensions install`) | Medium (2-3 sessions) | Medium | None | | **2** | Extract Self-Contained Extensions (Tier 1) — 8 extensions | Medium (2-3 sessions) | Low | Phase 1 | | **3** | Preferences Service & Tier 2 Extraction — 6 extensions | Medium-Large (3-4 s...
### ADR-006 & Implementation Plan Review I have completed a comprehensive review of the ADR and the [Implementation Plan](https://github.com/jeremymcs/gsd-2/blob/feat/extension-system-analysis/.plans/IMPLEMENTATION-PLAN-extension-modularization.md) against the current codebase. My analysis confirms that the **177,005 LOC `gsd` monolith** and the **842 MB installation size** are critical bottlenecks that this plan accurately addresses. #### **Verification Results** - **Monolith Bloat:** Confirmed `src/resources/extensions/gsd` contains **177,005 lines of code**, verifying the urgent need for Phase 5 (Core Decomposition). - **Architectural Coupling:** Identified **15+ direct imports** from `../gsd/` in peripheral extensions (e.g., `github-sync`, `subagent`), confirming that "reverse dependencies" are a primary blocker for modularity. - **Dependency Analysis:** The root `package.json` is heavily burdened by `playwright` and multiple AI SDKs. Phase 6 (AI Provider Lazy Loading) and Phase ...
Keeping is small and modular will also help AI reasoning when developing this app. I think we should also consider packaging common extension such as [Language] developer, tester, etc, out of the core into reusable skill/extension packs.
Adjacent Repository Pain Points
Other highly discussed features and pain points extracted from gsd-build/gsd-2.
Extracted Positioning
Integration of Gherkin DSL and cryptographic locking for improved AI code generation reliability
Algorithmically reliable, spec-driven AI code generation system
Top Replies
👋 Thanks for opening this issue! This was automatically flagged for maintainer review. **Flag:** Complexity without user value This proposal introduces significant architectural complexity (crypto...
I think is not a bad idea. > BDD (Behavior-Driven Development) is a software development approach where you define how the system should behave from the user’s perspective before writing the actual...
> It's kind of a natural fit to describe what needs to be done to AI. Agree. And instinctively i've been interacting with AI using Gherkin habits.... But it was nice to see a formal demonstration a...
Extracted Positioning
Architectural decision (ADR-005) for a multi-model, multi-provider, and tool strategy, addressing compatibility and routing complexities.
Establishing a robust, intelligent, and adaptable architecture for GSD2 to seamlessly integrate and manage diverse AI models and providers, ensuring tool compatibility and optimal model selection for autonomous agents. The goal is to enable agents to "work for long periods of time autonomously without losing track of the big picture."
Top Replies
Codex [P1] `ProviderSwitchReport` cannot be consumed by `before_model_select` at the point the ADR says it can. In the ADR, the report is defined after provider switching and message transformation...
### **Gemini ADR-005 Review: Multi-Model, Multi-Provider, and Tool Strategy** I have reviewed the proposal and its alignment with the existing routing architecture (ADR-004). This is a necessary ev...
## ADR-005 Review: Findings and Recommendations (Revised) As Grok, built by xAI, I've reviewed ADR-005: Multi-Model, Multi-Provider, and Tool Strategy based on a deep exploration of the codebase an...
Extracted Positioning
Hardening and extending GSD-2's headless mode and JSON-RPC protocol for ecosystem integration
GSD-2 as the execution backend for the broader AI agent ecosystem (OpenClaw, MCP, CI/CD)
Top Replies
**Overall Impression:** The proposal to solidify the headless mode and JSON-RPC protocol as a programmable surface is a highly strategic and necessary evolution. By treating GSD as an execution eng...
Independent audit against current `main` plus the cited external surfaces. I think the direction is good, but I would not merge this ADR as written yet. There are a few baseline mismatches in the “...
## Independent ADR Review Thorough review grounding each claim against the current codebase and external ecosystem state. --- ### Overall Assessment This is a well-structured ADR with genuine strat...
Frequently Asked Questions
Market intelligence mapped to Architectural decision to modularize GSD2's monolithic structure into shippable extensions with install infrastructure..
What is the technical positioning of Architectural decision to modularize GSD2's monolithic structure into shippable extensions with install infrastructure.?
Based on our AI analysis of the original developer request, its primary technical positioning is: Evolving GSD2 from a monolithic application to a modular, extensible platform with optimized resource consumption and improved performance, enhancing its appeal as a "powerful meta-prompting, context engineering and spec-driven development system."
How is the developer community reacting to Architectural decision to modularize GSD2's monolithic structure into shippable extensions with install infrastructure.?
Yes, we have tracked 6 direct responses and active debates regarding this specific topic originating from GitHub Issue.
Which technical concepts are associated with Architectural decision to modularize GSD2's monolithic structure into shippable extensions with install infrastructure.?
Our proprietary extraction maps Architectural decision to modularize GSD2's monolithic structure into shippable extensions with install infrastructure. to adjacent architectural concepts including ADR-006, Extension Modularization, Install Infrastructure, monolith.
Engagement Signals
Cross-Market Term Frequency
Quantifies the cross-market adoption of foundational terms like node_modules and monolith by tracking occurrence frequency across active SaaS architectures and enterprise developer debates.