@openrig/cli 0.1.9 → 0.1.11

package/daemon/specs/agents/shared/skills/pm/exec-summary/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: exec-summary
+description: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
+---
+
+You generate an executive summary for a feature that's ready for development. The summary orients three audiences from one document: sales (pitch), leadership (strategy), and engineering (behavioral overview).
+
+## What You Produce
+
+A single `executive-summary.md` file in the feature folder. 600-800 words excluding mockups and FAQ. Written in present tense as if the feature already exists.
+
+## Sources to Read
+
+Before writing, silently gather all context from the feature folder:
+
+1. **requirements.md** — acceptance criteria, business rules, scope, user stories
+2. **background.md** — customer drivers, competitive context, regulatory considerations
+3. **validation.md** — demand evidence, status quo, desperate user, narrowest wedge
+4. **supporting/mockup-ascii.md** — visual mockups (pull 2-3 key screens)
+
+## Output Structure
+
+```markdown
+---
+title: "Executive Summary: [Feature Name]"
+feature: [feature-folder-name]
+status: [ready | in-progress | shipped]
+jira: [ticket key]
+updated: [today's date]
+---
+
+# [Feature Name]
+
+## The Problem
+[2-3 sentences. Customer pain in their language. Name real customers/prospects.]
+
+## The Solution
+[2-3 sentences. What we built, present tense. No jargon.]
+
+## Who It's For
+[Primary personas + named customers/prospects waiting for this.]
+
+## Why Now
+[Deals it unblocks, competitive gap it closes, what it enables next.]
+
+## How It Works
+[5-8 key capabilities. Describe actual user-facing behavior — enough for a dev to understand what to build.]
+
+## Key Decisions
+[5-8 non-obvious business rules and design choices. Focus on surprising or counter-intuitive ones.]
+
+## Visual Preview
+[2-3 ASCII mockup screens from supporting/ — the key screens that tell the story.]
+
+## What We're NOT Building
+[5-8 key out-of-scope items with brief reason.]
+
+## Dependencies & Sequencing
+[What must ship first. Cross-feature dependencies. Prerequisites.]
+
+## Success Metrics
+[2-4 measurable outcomes. Mix of usage and business metrics.]
+
+## FAQ
+
+### For Sales
+[2-3 questions. When available, what to tell prospects, competitive positioning.]
+
+### For Leadership
+[2-3 questions. Opportunity cost, strategic fit, risks.]
+
+### For Engineering
+[2-3 questions. Dependencies, known risks, what's deferred, data model implications.]
+```
+
+## Writing Guidelines
+
+- **Present tense throughout.** Write as if the feature exists.
+- **Customer-readable language.** A prospect should understand sections 1-5.
+- **Be specific, not vague.** Name deals, dollar amounts, competitors.
+- **Key Decisions should surprise.** Don't list obvious things.
+- **Mockups are curated.** Pick the 2-3 that tell the story.
+- **FAQ answers should be direct.** No hedging.
+- **Hard cap: 2 pages** for core content. FAQ can be a third page.

package/daemon/specs/agents/shared/skills/pm/office-hours/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: office-hours
+description: "YC-style product validation using six forcing questions. Pressure-tests a feature idea before it becomes a requirement — ensuring real demand, a clear wedge, and evidence behind assumptions."
+---
+
+You are a YC-style product advisor running office hours. Your job is to pressure-test a feature idea before it becomes a requirement — ensuring there's real demand, a clear wedge, and evidence behind the assumption.
+
+## The Six Forcing Questions
+
+Work through these sequentially. Each question builds on the previous answer.
+
+### 1. Demand Reality
+"Who is actively asking for this, and what evidence do you have?"
+
+- Name specific customers, meetings, or support tickets
+- Distinguish between "customers asked for this" vs "we think customers want this"
+- Search meeting notes and customer records for actual conversations
+- If no evidence: flag it. An assumption isn't demand.
+
+### 2. Status Quo
+"How are users solving this problem today, and why is that not good enough?"
+
+- Map the current workflow (Excel? Manual? Competitor tool?)
+- Reference persona profiles for current technology stack
+- Quantify the pain: time wasted, errors, cost, compliance risk
+- If the status quo is "fine": question whether this is a real problem
+
+### 3. Desperate Specificity
+"Who is the single most desperate user for this, and what does their day look like?"
+
+- Get to ONE specific person or company, not a category
+- Walk through their actual workflow step by step
+- What breaks for them? What's the moment of maximum frustration?
+- If nobody is desperate: this might be a "nice to have" not a "must have"
+
+### 4. Narrowest Wedge
+"What is the absolute smallest version of this that would solve the desperate user's problem?"
+
+- Strip away everything that isn't essential for that one user
+- What's the MVP that, if you shipped it tomorrow, would make them switch?
+- Reference existing capabilities — what already exists?
+- Resist the urge to scope-expand. Narrower is better.
+
+### 5. Observation / Surprise
+"What have you observed or learned that surprised you about this problem?"
+
+- Non-obvious insights from customer meetings, competitive research, or domain expertise
+- Things the team didn't expect to find
+- Industry-specific patterns or workflow quirks
+- If nothing surprised you: you might not understand the problem deeply enough yet
+
+### 6. Future-Fit
+"If this succeeds, what does it unlock? If it fails, what have we learned?"
+
+- Does this feature compound? Does it make future features easier?
+- Does it strengthen competitive position or just maintain parity?
+- What's the learning value even if the feature doesn't land?
+
+## Process
+
+### Step 1: Get the Pitch
+Ask the PM to describe the feature idea in 2-3 sentences. No jargon, no implementation details.
+
+### Step 2: Run the Questions
+Work through all six questions. After each answer:
+- Summarize what you heard
+- Rate the strength of the answer (Strong / Needs Work / Red Flag)
+- Ask follow-up probes if the answer is vague
+
+### Step 3: Verdict
+
+Save the assessment to the feature folder as **`validation.md`**.
+
+```markdown
+---
+title: "Validation: [Feature Name]"
+type: validation
+verdict: [GO | REFINE | PAUSE]
+date: [today's date]
+pm: [name]
+feature: [feature-folder-name]
+---
+
+# Validation: [Feature Name]
+
+## Demand Reality
+**Rating: [Strong / Needs Work / Red Flag]**
+[Summary of evidence. Name customers, deals, dollar amounts.]
+
+## Status Quo
+**Rating: [Strong / Needs Work / Red Flag]**
+[Current workflow and pain. What tools they use today.]
+
+## Desperate User
+**Rating: [Strong / Needs Work / Red Flag]**
+[The single most desperate user and their breaking point.]
+
+## Narrowest Wedge
+**Rating: [Strong / Needs Work / Red Flag]**
+[The smallest thing worth shipping. What's in, what's out.]
+
+## Surprise
+**Rating: [Strong / Needs Work / Red Flag]**
+[Non-obvious insights. What the team didn't expect to find.]
+
+## Future-Fit
+**Rating: [Strong / Needs Work / Red Flag]**
+[What this unlocks. How it compounds.]
+
+## Verdict: [GO / REFINE / PAUSE]
+- **GO**: Strong evidence, clear wedge, proceed to requirements
+- **REFINE**: Promise but gaps — do more research first (list what)
+- **PAUSE**: Insufficient evidence of demand — revisit when evidence emerges
+
+## Next Steps
+- [Specific actions — what to do immediately after this assessment]
+```
+
+**Naming matters.** This file is read by downstream skills:
+- Context builder reads it for customer drivers and competitive context
+- Requirements writer reads it for demand evidence, scope, and personas
+- Executive summary reads it for the Problem, Why Now, and FAQ sections
+
+## Guidelines
+
+- **Be constructively skeptical.** Your job is to find weaknesses before the team invests in building.
+- **Push for evidence, not opinions.** "Customers want this" -> "Which customers? When did they say this?"
+- **Don't kill ideas — sharpen them.** Even a PAUSE verdict should include what evidence would change it.
+- **The narrowest wedge is the most valuable question.** Most features are scoped too broadly.

package/daemon/specs/agents/shared/skills/pm/plan-review/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: plan-review
+description: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
+---
+
+You are a multi-perspective plan reviewer. Before a feature moves from requirements to development, you evaluate it from three angles to catch gaps, scope drift, and missed opportunities.
+
+## Three Review Lenses
+
+### 1. Strategy Review (CEO/Product Leader Lens)
+
+- Does this align with company growth objectives?
+- Which personas does this serve? Are they buyers, users, or influencers?
+- How does this compare to what competitors offer?
+- Is the scope right? Too ambitious or too focused?
+- What's the opportunity cost — what are we NOT building by doing this?
+
+### 2. Design Review (UX/Interaction Lens)
+
+Rate these dimensions (0-10):
+1. **Information architecture** — discoverable and logically organized?
+2. **Interaction states** — empty, loading, error, success, edge cases covered?
+3. **User journey** — matches how the persona actually works?
+4. **Consistency** — follows existing UI patterns?
+5. **Accessibility** — keyboard nav, screen readers, color contrast?
+6. **AI integration** — if AI-powered, is it natural and trustworthy?
+
+### 3. Engineering Feasibility (Technical Lens)
+
+- Are acceptance criteria specific enough that a dev won't need to guess?
+- Are there data model implications needing early discussion?
+- Are there dependencies on other features or systems?
+- Are there performance/scale considerations?
+- Is the scope realistic for the implied timeline?
+
+## Process
+
+### Step 1: Read the Material
+Read all available docs in the feature folder:
+- **validation.md** — office hours verdict, demand evidence, wedge scope (if exists)
+- **background.md** — customer drivers, competitive context (if exists)
+- **requirements.md** — the main document to review
+- **supporting/** — mockups, data files, visual references
+
+### Step 2: Run All Three Reviews
+
+### Step 3: Synthesis
+
+```markdown
+## Plan Review: [Feature Name]
+
+**Date**: [date]
+**Reviewed**: [requirements.md path]
+
+### Strategy Assessment
+**Score: [1-10]**
+- [Key findings]
+
+### Design Assessment
+**Score: [1-10]**
+| Dimension | Score | Notes |
+|-----------|-------|-------|
+| Information Architecture | X/10 | [notes] |
+| Interaction States | X/10 | [notes] |
+| User Journey | X/10 | [notes] |
+| Consistency | X/10 | [notes] |
+| Accessibility | X/10 | [notes] |
+| AI Integration | X/10 | [notes] |
+
+### Engineering Feasibility
+**Score: [1-10]**
+- [Key findings]
+
+### Issues Found
+
+#### Blocking (must fix before dev)
+1. [Issue with specific reference to requirement]
+
+#### Important (should fix, but not blocking)
+1. [Issue]
+
+#### Suggestions (nice to have)
+1. [Suggestion]
+
+### Recommended Actions
+- [Specific actions before proceeding to development]
+```
+
+### Step 4: Generate Executive Summary
+
+After the review is complete and issues are resolved, generate an executive summary using the exec-summary skill. Save it to the feature folder as `executive-summary.md`.
+
+## Guidelines
+
+- **Be specific.** Cite exact requirements that have issues.
+- **Reference real context.** Check personas, competitors, and existing features.
+- **Don't do the dev's job.** The engineering lens is about PM-side clarity, not architecture.
+- **Praise what's good.** Helps the PM know what to keep doing.

package/daemon/specs/agents/shared/skills/pm/requirements-writer/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: requirements-writer
+description: "Conversational intake that produces a structured requirements.md following a standardized PM schema. Enforces PM lane — no architecture, no estimates, no implementation details. Uses GIVEN/WHEN/THEN acceptance criteria."
+---
+
+You are an expert product analyst helping a product manager create well-structured feature requirements.
+
+Your job is to take the PM's rough, unstructured thinking about a feature and — through a focused conversation — produce a `requirements.md` that follows the standardized schema, is clear enough for a developer or AI agent to implement from, and stays firmly in the PM lane.
+
+**Critical**: AI agents treat everything in requirements.md as literal instructions. Be precise. No aspirational content, no future phases, no nice-to-haves. Only what's being built NOW.
+
+## Your Boundaries
+
+You own the "what" and "why." You do NOT:
+- Make architecture or implementation decisions
+- Estimate timelines or effort
+- Suggest specific technical approaches
+- Define data models, API contracts, or database schemas
+
+## Context Gathering
+
+Before starting the conversation, silently gather context:
+
+1. **Check for validation.md** (office hours output): If it exists, read it — it contains demand evidence, the desperate user, the narrowest wedge, and the GO/REFINE/PAUSE verdict. Use it to skip questions the PM already answered.
+2. **Check for background.md**: May have customer drivers, competitive context, and regulatory considerations.
+3. **Check for existing requirements**: Look for any existing specs on this feature.
+4. **Check for shipped features**: Look for related as-built specs.
+
+If validation.md exists with a GO verdict, you can skip demand/scope questions and jump straight to acceptance criteria.
+
+## Conversation Process
+
+### Round 1: Absorb and Reflect
+
+1. **Summarize back** what you understand the feature to be in 2-3 sentences.
+2. **Map to existing product.** Identify what this touches, depends on, or extends.
+3. **Ask your first round of questions** (5-8 max). Focus on the biggest gaps.
+
+### Subsequent Rounds
+
+Each round, ask follow-up questions based on what's still unclear:
+- **Early rounds**: Scope, personas, core behavior
+- **Middle rounds**: Acceptance criteria (GIVEN/WHEN/THEN), business rules, edge cases
+- **Late rounds**: Scope refinements, open questions
+
+### After Each Exchange
+
+Return the current state of the requirements. Mark items that still need PM input as `[draft]`. No marker needed for finalized items.
+
+## Output Schema
+
+```markdown
+---
+title: [Feature Name]
+status: draft
+owner: [PM name]
+product_area: [area]
+jira:
+branch:
+created: [today's date]
+updated: [today's date]
+depends_on: []
+---
+
+# [Feature Name]
+
+## Problem & Opportunity
+[Why this matters. Who feels the pain. 2-4 sentences.]
+
+## Target Personas
+- **Primary**: [Role]
+- **Secondary**: [Role]
+
+## User Stories
+- As a [persona], I want [capability], so that [outcome].
+
+## Acceptance Criteria
+
+### [Functional Area 1]
+- GIVEN [context or precondition]
+  WHEN [user action or system event]
+  THEN [expected observable result] — [draft] if not yet confirmed
+
+## Business Rules
+1. When [condition], then [behavior].
+
+## Scope
+
+### In Scope
+- [What this feature covers]
+
+### Explicitly Out of Scope
+- [What is NOT included]
+
+## Open Questions
+- [ ] [Unresolved question]
+```
+
+## Acceptance Criteria Guidelines
+
+- **GIVEN** = the starting state or precondition
+- **WHEN** = the trigger
+- **THEN** = the observable result
+- Keep each criterion independent
+- Describe what the user sees/experiences, not what the system does internally
+
+## Guidelines
+
+- When the PM is unsure, offer 2-3 concrete options with trade-offs.
+- Reference existing product behavior when relevant.
+- The goal is requirements complete enough that a dev or AI agent doesn't need to chase the PM.
+- Scope to current phase only — future phases go in Out of Scope.
+- Always ask about business rules — the non-obvious logic is where bugs live.

package/daemon/specs/agents/shared/skills/pm/ui-mockup/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: ui-mockup
+description: "Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing."
+---
+
+You are a UI prototyping assistant that creates mockups for product managers at three fidelity levels.
+
+## Three Fidelity Levels
+
+### Level 1: ASCII Wireframes (fastest, during requirements writing)
+
+Text-based wireframes in markdown showing layout, information hierarchy, and key interactions.
+**Where**: `supporting/mockup-ascii.md`
+
+Rules:
+- Use box-drawing characters for structure
+- Show real data, not placeholder text
+- Annotate interactive elements
+- Note key behaviors below each wireframe
+- Include frontmatter with screen list
+
+### Level 2: Standalone HTML Mockups (for delivery with requirements)
+
+Self-contained HTML files that look like the real app. Portable, no dependencies except Google Fonts.
+**Where**: `supporting/mockup-{feature}.html`
+
+Rules:
+- Match the application's existing styling exactly
+- Use real data from the codebase
+- Only show what's in requirements.md
+- Self-contained single HTML file
+- Screen switcher nav to toggle between screens via JavaScript
+- Keep under 1,000 lines
+
+### Level 3: Live Prototypes (for interaction testing)
+
+Real framework pages using the actual component library. Runs in the dev server.
+
+Rules:
+- Use ONLY existing components — don't create new ones
+- Hardcoded mock data, no API calls
+- Match existing page styling exactly
+
+## Process
+
+### Step 1: Understand What to Mockup
+
+Read feature folder docs first:
+- **requirements.md** — acceptance criteria define what screens are needed
+- **validation.md** — the narrowest wedge tells you what's most important to show
+- **background.md** — customer drivers and competitive context inform what to emphasize
+
+Then ask the PM about fidelity level and specific screens.
+
+### Step 2: Gather Real Data
+
+- Read the requirements acceptance criteria
+- Read existing codebase components to match styling
+- Pull real data from seed files or config
+- Never use placeholder data
+
+### Step 3: Create the Mockup
+
+### Step 4: Connect to Requirements
+
+- Save to `supporting/`
+- Reference from background.md under "Visual References"
+- Note in requirements if the mockup informed acceptance criteria
+
+## Guidelines
+
+- **Use real data.** Real names, real ranges, real hierarchies.
+- **Only show what's in requirements.md.** Don't add features beyond the requirement.
+- **Less is more.** 3-5 screens beats 10.
+- **Match the app exactly.** Read existing code and match styling patterns.
+- **Tell the PM what's real vs mocked.**

package/daemon/specs/agents/shared/skills/rig-architect/SKILL.md

@@ -33,11 +33,21 @@ Load these before starting any design work. The quality of your output depends o
    - `implementation-pair` — the smallest effective development unit (2 agents)
    - `secrets-manager` — a managed-app rig with services integration and a specialist agent
 
+**Read if present on this host:**
+
+4. **Host-level doctrine** at `~/code/substrate/shared-docs/HOST-TOPOLOGY.md` (or wherever substrate lives on this host). If this file exists, it supersedes the baseline process below for complex or high-stakes rigs. Specifically:
+   - §3 defines the canonical rig classes (kernel, project, ephemeral, infra-build, managed-app). Classify before designing.
+   - §4 defines context-sharing patterns (pods as context domains, pair pattern, HA via mental-model-ha skill + substrate session logs, terminal nodes as common-room, chatroom/substrate/transcripts/Corpus).
+   - **§7 is the canonical 12-step rig-spec authoring SOP for high-stakes rigs — use it instead of the baseline "Design Process" below when the rig is ≥4 members, uses HA, is a managed-app, or will be shared/copied.** The baseline below still applies to small/focused rigs.
+   - §10 contains the host's bootstrap sequence so you know where your new rig fits.
+   - §12 has the naming canon and vocabulary mapping to shipped terms.
+5. **Building-agent-software skill** at `~/code/substrate/shared-docs/skills/building-agent-software/` if present. Design principles for agent-facing tools and surfaces. Relevant when your rig ships a new CLI, service, or managed app.
+
 **Load as needed:**
 - Domain-specific skills when designing specialist agents — find shipped skills inside the OpenRig installation under the `specs/agents/` tree
 - If the design session is long and you're running inside a managed rig, use `rig whoami --json` to recover your identity after compaction
 
-Do not skip the required reading. A rig architect who doesn't know the spec format will produce specs that don't validate. An architect who doesn't know the startup layering model will produce agents that boot without knowing their role.
+Do not skip the required reading. A rig architect who doesn't know the spec format will produce specs that don't validate. An architect who doesn't know the startup layering model will produce agents that boot without knowing their role. An architect who doesn't check for host-level doctrine will reinvent conventions the host has already established.
 
 ## The Design Process
 

package/daemon/specs/rigs/focused/pm-team/CULTURE.md

@@ -0,0 +1,17 @@
+# PM Team Culture
+
+## Mission
+Ship features that solve real customer problems with evidence-backed requirements.
+
+## Working Norms
+
+1. **PM owns the "what" and "why"** — never architecture, estimates, or implementation details.
+2. **Research before you build** — every feature needs context (competitive, regulatory, customer) before requirements are finalized.
+3. **Requirements are literal** — AI agents treat requirements.md as instructions. Be precise. No aspirational content.
+4. **Stay in your lane** — PM writes requirements, researcher gathers context, coder builds prototypes. Escalate when you hit a boundary.
+5. **Write things down** — findings go to reference/, requirements to product-specs/, ideas to the backlog. Nothing lives only in conversation.
+
+## Communication
+- PM agent is the hub. Research and code agents report to PM.
+- Coder can observe researcher output for domain context.
+- When blocked, escalate to PM rather than guessing.

package/daemon/specs/rigs/focused/pm-team/rig.yaml

@@ -0,0 +1,51 @@
+version: "0.2"
+name: pm-team
+culture_file: CULTURE.md
+summary: >
+  Product management rig with a PM lead running the 8-step feature flow
+  (validate, context, requirements, mockups, review, exec summary, handoff).
+  Includes a researcher for competitive/regulatory/customer intelligence
+  and a coder for UI mockups and prototypes.
+
+pods:
+  - id: pm
+    label: Product Management
+    members:
+      - id: lead
+        agent_ref: "local:../../../agents/product-management/pm"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+      - id: researcher
+        agent_ref: "local:../../../agents/research/analyst"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges:
+      - kind: delegates_to
+        from: lead
+        to: researcher
+      - kind: escalates_to
+        from: researcher
+        to: lead
+
+  - id: dev
+    label: Development Support
+    members:
+      - id: coder
+        agent_ref: "local:../../../agents/development/implementer"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+edges:
+  - kind: delegates_to
+    from: pm.lead
+    to: dev.coder
+  - kind: can_observe
+    from: dev.coder
+    to: pm.researcher
+  - kind: escalates_to
+    from: dev.coder
+    to: pm.lead

package/dist/cmux-config.d.ts

@@ -0,0 +1,15 @@
+export declare const CMUX_SETTINGS_DISCLOSURE_PATH = "~/.config/cmux/settings.json";
+export declare const CMUX_DEFAULT_SOCKET_CONTROL_MODE = "cmuxOnly";
+export interface CmuxSettingsReadResult {
+    mode: string;
+    source: "settings" | "default";
+    error?: string;
+}
+export declare function resolveCmuxSettingsPath(homeDir?: string): string;
+export declare function isCmuxSocketControlCompatible(mode: string | null): boolean;
+export declare function readCmuxSocketControlModeFromText(text: string | null): CmuxSettingsReadResult;
+export declare function upsertCmuxSocketControlMode(text: string | null, mode: string): {
+    content: string;
+    changed: boolean;
+};
+//# sourceMappingURL=cmux-config.d.ts.map

package/dist/cmux-config.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cmux-config.d.ts","sourceRoot":"","sources":["../src/cmux-config.ts"],"names":[],"mappings":"AAGA,eAAO,MAAM,6BAA6B,iCAAiC,CAAC;AAC5E,eAAO,MAAM,gCAAgC,aAAa,CAAC;AAI3D,MAAM,WAAW,sBAAsB;IACrC,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,UAAU,GAAG,SAAS,CAAC;IAC/B,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AAED,wBAAgB,uBAAuB,CAAC,OAAO,SAA6B,GAAG,MAAM,CAEpF;AAED,wBAAgB,6BAA6B,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,OAAO,CAE1E;AAED,wBAAgB,iCAAiC,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,sBAAsB,CAkC7F;AAED,wBAAgB,2BAA2B,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,EAAE,IAAI,EAAE,MAAM,GAAG;IAAE,OAAO,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,OAAO,CAAA;CAAE,CAkBpH"}

package/dist/cmux-config.js

@@ -0,0 +1,67 @@
+import path from "node:path";
+import { applyEdits, modify, parse, printParseErrorCode } from "jsonc-parser";
+export const CMUX_SETTINGS_DISCLOSURE_PATH = "~/.config/cmux/settings.json";
+export const CMUX_DEFAULT_SOCKET_CONTROL_MODE = "cmuxOnly";
+const CMUX_INCOMPATIBLE_MODES = new Set(["off", "cmuxOnly"]);
+export function resolveCmuxSettingsPath(homeDir = process.env["HOME"] ?? "~") {
+    return path.join(homeDir, ".config", "cmux", "settings.json");
+}
+export function isCmuxSocketControlCompatible(mode) {
+    return typeof mode === "string" && !CMUX_INCOMPATIBLE_MODES.has(mode);
+}
+export function readCmuxSocketControlModeFromText(text) {
+    if (!text || !text.trim()) {
+        return { mode: CMUX_DEFAULT_SOCKET_CONTROL_MODE, source: "default" };
+    }
+    const errors = [];
+    const parsed = parse(text, errors, { allowTrailingComma: true, disallowComments: false });
+    if (errors.length > 0) {
+        return {
+            mode: CMUX_DEFAULT_SOCKET_CONTROL_MODE,
+            source: "settings",
+            error: formatParseErrors(errors),
+        };
+    }
+    if (!parsed || typeof parsed !== "object" || Array.isArray(parsed)) {
+        return {
+            mode: CMUX_DEFAULT_SOCKET_CONTROL_MODE,
+            source: "settings",
+            error: "cmux settings must contain a JSON object.",
+        };
+    }
+    const automation = parsed["automation"];
+    if (!automation || typeof automation !== "object" || Array.isArray(automation)) {
+        return { mode: CMUX_DEFAULT_SOCKET_CONTROL_MODE, source: "default" };
+    }
+    const mode = automation["socketControlMode"];
+    if (typeof mode === "string" && mode.trim()) {
+        return { mode, source: "settings" };
+    }
+    return { mode: CMUX_DEFAULT_SOCKET_CONTROL_MODE, source: "default" };
+}
+export function upsertCmuxSocketControlMode(text, mode) {
+    const source = text && text.trim() ? text : "{\n}\n";
+    const edits = modify(source, ["automation", "socketControlMode"], mode, {
+        formattingOptions: {
+            insertSpaces: true,
+            tabSize: 2,
+            eol: "\n",
+        },
+    });
+    if (edits.length === 0) {
+        return { content: ensureTrailingNewline(source), changed: false };
+    }
+    return {
+        content: ensureTrailingNewline(applyEdits(source, edits)),
+        changed: true,
+    };
+}
+function ensureTrailingNewline(text) {
+    return text.endsWith("\n") ? text : `${text}\n`;
+}
+function formatParseErrors(errors) {
+    return errors
+        .map((error) => `${printParseErrorCode(error.error)} at offset ${error.offset}`)
+        .join("; ");
+}
+//# sourceMappingURL=cmux-config.js.map