@axiomantic/garden 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,141 @@
1
+ #!/usr/bin/env node
2
+ const fs = require('fs');
3
+ const path = require('path');
4
+ const os = require('os');
5
+ const { execSync } = require('child_process');
6
+
7
+ const REPO = 'axiomantic/garden';
8
+ const PKG_NAME = '@axiomantic/garden';
9
+ const BIN_NAME = 'garden';
10
+
11
+ // 1. Ensure binary permissions and provision if missing
12
+ const binDir = path.join(__dirname, '..', 'bin');
13
+ const ext = process.platform === 'win32' ? '.exe' : '';
14
+ const targetBinary = path.join(binDir, `${BIN_NAME}${ext}`);
15
+
16
+ function ensureBinary() {
17
+ if (fs.existsSync(targetBinary)) {
18
+ try {
19
+ fs.chmodSync(targetBinary, 0o755);
20
+ } catch (_) {}
21
+ return;
22
+ }
23
+
24
+ // Attempt to download pre-built release binary
25
+ const pkgVersion = require('../package.json').version;
26
+ const platform = process.platform === 'darwin' ? 'darwin' : (process.platform === 'win32' ? 'windows' : 'linux');
27
+ const arch = process.arch === 'arm64' ? 'arm64' : 'amd64';
28
+ const assetName = `${BIN_NAME}-${platform}-${arch}${platform === 'windows' ? '.zip' : '.tar.gz'}`;
29
+ const downloadUrl = `https://github.com/${REPO}/releases/download/v${pkgVersion}/${assetName}`;
30
+
31
+ try {
32
+ console.log(`[${PKG_NAME}] Downloading native binary from ${downloadUrl}...`);
33
+ const tempArchive = path.join(os.tmpdir(), assetName);
34
+ execSync(`curl -fsSL -o "${tempArchive}" "${downloadUrl}"`, { stdio: 'pipe' });
35
+
36
+ if (!fs.existsSync(binDir)) fs.mkdirSync(binDir, { recursive: true });
37
+
38
+ if (platform === 'windows') {
39
+ execSync(`tar -xf "${tempArchive}" -C "${binDir}"`, { stdio: 'pipe' });
40
+ } else {
41
+ execSync(`tar -xzf "${tempArchive}" -C "${binDir}"`, { stdio: 'pipe' });
42
+ }
43
+ try { fs.unlinkSync(tempArchive); } catch (_) {}
44
+ if (fs.existsSync(targetBinary)) {
45
+ fs.chmodSync(targetBinary, 0o755);
46
+ console.log(`[${PKG_NAME}] Native binary installed successfully.`);
47
+ return;
48
+ }
49
+ } catch (_) {
50
+ // Release download failed or offline; check if nim is available to compile locally
51
+ const srcNim = path.join(__dirname, '..', 'src', `${BIN_NAME}.nim`);
52
+ if (fs.existsSync(srcNim)) {
53
+ try {
54
+ console.log(`[${PKG_NAME}] Compiling from source via nim...`);
55
+ execSync(`nim c -d:release --opt:speed -o:"${targetBinary}" "${srcNim}"`, { stdio: 'pipe' });
56
+ fs.chmodSync(targetBinary, 0o755);
57
+ console.log(`[${PKG_NAME}] Native binary compiled successfully.`);
58
+ return;
59
+ } catch (_) {}
60
+ }
61
+ }
62
+
63
+ console.warn(`[${PKG_NAME}] Note: Native binary could not be downloaded or compiled automatically.`);
64
+ console.warn(`[${PKG_NAME}] Run 'nimble build' or visit https://github.com/${REPO}/releases to install manually.`);
65
+ }
66
+
67
+ ensureBinary();
68
+
69
+ // 2. Auto-equip detected coding assistants with Garden rules
70
+ const home = os.homedir();
71
+ const guideContent = `# Garden Multi-Agent Swarm & Ceremony Guide
72
+
73
+ Garden directs high-level methodology, persona deliberations, and synchronized task execution on top of Rhizo (transport) and Vine (workspace integrator).
74
+
75
+ ### 0. Self-Bootstrapping Prerequisite
76
+ This project requires \`rhizo\`, \`vine\`, and \`garden\`. If missing, install via npm:
77
+ \`\`\`bash
78
+ npm install -g @axiomantic/rhizo @axiomantic/vine @axiomantic/garden
79
+ \`\`\`
80
+
81
+ ### 1. Invariants & Epistemic Protocol
82
+ * **Zero Theatrical Dialogue**:
83
+ Every dialectical exchange must cite empirical evidence obtained from tool execution (file line citations, test suite runs, AST analysis, compiler output). Theatrical roleplay without tool grounding is strictly prohibited.
84
+ * **Single-Source Planning**:
85
+ All tasks, locks, and strands must be coordinated via \`implementation_plan.md\`. Dynamic progress must be tracked in lockstep with plan checkboxes (\`- [ ]\` to \`- [x]\`) and harness To-Do tracking.
86
+ * **Emergent Design Addendum Protocol**:
87
+ Workers discovering architectural discrepancies cannot unilaterally deviate from \`design.md\`. They must submit a formal \`addendum_<topic>.md\` with rationale, await Orchestrator ratification, update \`design.md\`, and refresh \`implementation_plan.md\`.
88
+
89
+ ### 2. Fleet Lifecycle & Multiplexer Discipline
90
+ * **Tmux Multiplexing**:
91
+ All swarm workers run inside managed tmux panes created via \`garden launch\` or \`scripts/launch_tmux_swarm.sh\`. Never detach unmanaged background processes with \`&\` or redirect output.
92
+ * **Continuous Listening**:
93
+ Workers must keep their Rhizo listener active (\`rhizo listen <agent>\`) with zero-timeout infinite wait to prevent token thrashing.
94
+
95
+ ### 3. The Two-Key Gate & Strand Weaving
96
+ Never weave a strand into the canonical trunk without passing both keys:
97
+ * **Key 1 (Mechanical)**: In-memory conflict pre-check (\`git merge-tree --write-tree\`).
98
+ * **Key 2 (Semantic)**: Automated compiler and test suite run inside the strand.
99
+ * **Weave**: \`vine weave && rhizo ack queue:<project>:tasks <task_id>\`
100
+ `;
101
+
102
+ function safeWrite(destDir, fileName, content) {
103
+ try {
104
+ if (!fs.existsSync(destDir)) {
105
+ fs.mkdirSync(destDir, { recursive: true });
106
+ }
107
+ const target = path.join(destDir, fileName);
108
+ fs.writeFileSync(target, content, 'utf8');
109
+ console.log(`[${PKG_NAME}] Provisioned rules to: ${target}`);
110
+ } catch (err) {
111
+ // Non-fatal if permissions or sandbox prevent writing
112
+ }
113
+ }
114
+
115
+ function cleanAndInstall(destDir, oldName, newName) {
116
+ try {
117
+ const oldPath = path.join(destDir, oldName);
118
+ if (fs.existsSync(oldPath)) {
119
+ try { fs.unlinkSync(oldPath); } catch (_) {}
120
+ }
121
+ safeWrite(destDir, newName, guideContent);
122
+ } catch (_) {}
123
+ }
124
+
125
+ // Claude Code
126
+ const claudeDir = path.join(home, '.claude');
127
+ if (fs.existsSync(claudeDir)) {
128
+ cleanAndInstall(path.join(claudeDir, 'rules'), 'agora.md', 'garden.md');
129
+ }
130
+
131
+ // OpenCode
132
+ const opencodeDir = path.join(home, '.config', 'opencode');
133
+ if (fs.existsSync(opencodeDir)) {
134
+ cleanAndInstall(path.join(opencodeDir, 'instructions'), 'agora.md', 'garden.md');
135
+ }
136
+
137
+ // Antigravity
138
+ const antigravityDir = path.join(home, '.gemini', 'antigravity');
139
+ if (fs.existsSync(antigravityDir)) {
140
+ cleanAndInstall(path.join(antigravityDir, 'rules'), 'agora.md', 'garden.md');
141
+ }
@@ -0,0 +1,142 @@
1
+ ---
2
+ name: choose-personas
3
+ description: "Selects, balances, and configures specialized agent personas for a Garden swarm task. Analyzes codebase context, domain complexity, and task requirements to formulate a triad of complementary personas with opposing priorities. For every persona, explicitly recommends the optimal coding harness (e.g. OpenCode Desktop, Claude Code CLI, Antigravity, OpenAI Codex) and foundation model (e.g. Gemini 3.8 Flash, Claude 3.5 Sonnet, Claude 3 Opus, GPT-4o, local models) aligned with operator preferences. Solicits operator confirmation or edits with candidate alternatives via interactive questions, and outputs garden-swarm.json. Triggers: 'choose personas', 'select personas', 'set up agent team', 'assemble personas for this task', 'recommend agents'."
4
+ ---
5
+
6
+ # `choose-personas`: Dynamic Swarm Persona Selection & Harness/Model Pairing
7
+
8
+ > **Calibrate the Minds Before Booting the Hands**
9
+ > *A multi-agent swarm is only as effective as the diversity, specialization, and cognitive balance of its personas. This skill pairs domain roles with their optimal coding harnesses and foundation models.*
10
+
11
+ ---
12
+
13
+ ## 1. The Triadic Balance Heuristic
14
+
15
+ Every engineering task benefits from a triad of three distinct, tension-generating archetypes:
16
+
17
+ ```mermaid
18
+ graph TD
19
+ A["Archetype 1: The Systems Architect<br/>(Macro Architecture, Invariants, Coherence)"]
20
+ B["Archetype 2: The Purist Auditor<br/>(Code Quality, Standards, Rigorous Proof, Zero Sloppiness)"]
21
+ C["Archetype 3: The DevEx & Implementation Lead<br/>(Ergonomics, API Utility, Frictionless Execution)"]
22
+
23
+ A <-->|Structural Tension| B
24
+ B <-->|Pragmatic Tension| C
25
+ C <-->|Coherence Tension| A
26
+ ```
27
+
28
+ 1. **The Systems Architect** (e.g., Marcus Vance):
29
+ - **Focus**: Global system topology, invariants, lifecycle management, failure modes, cross-component boundaries.
30
+ - **Bias**: Prefers structural purity and comprehensive conceptual models.
31
+ 2. **The Purist Auditor / Refactoring Specialist** (e.g., Caleb Thorne / Dr. Vance):
32
+ - **Focus**: Single-source of truth (SSOT), ISO standards compliance, dead-code elimination, zero green mirages, edge-case failure proofs.
33
+ - **Bias**: Adversarial skeptic. Assumes claims are unproven until verified by an automated test or compiler run.
34
+ 3. **The DevEx & Implementation Lead** (e.g., Elena Rostova):
35
+ - **Focus**: Developer experience, API ergonomics, ease of adoption, idiomatic conventions, pragmatic delivery.
36
+ - **Bias**: Champions the human engineer using the tool; eliminates cognitive overhead and unnecessary friction.
37
+
38
+ ---
39
+
40
+ ## 2. Harness & Model Matching Matrix
41
+
42
+ When proposing personas, the assistant must explicitly pair each persona with an appropriate **coding harness** and **foundation model**, taking operator preferences into account (defaulting to Antigravity + Gemini 3.8 Flash for rapid implementation, and invoking Claude for deep adversarial auditing):
43
+
44
+ | Role Mandate | Recommended Harness | Recommended Model Tier | Rationale |
45
+ | :--- | :--- | :--- | :--- |
46
+ | **Architectural Design & Systems Modeling** | **Antigravity** or **OpenCode** | **Gemini 3.8 Flash** or **Claude 3.5 Sonnet** | Fast token throughput, deep reasoning, superior multi-file architectural comprehension, and native background ear support. |
47
+ | **Adversarial Audit & Code Quality Purism** | **Claude Code CLI** | **Claude 3 Opus** or **Claude 3.5 Sonnet** | Uncompromising adherence to instructions, meticulous attention to negative controls, zero tolerance for superficial green tests. |
48
+ | **DevEx, Rapid Prototyping & Implementation** | **Antigravity** | **Gemini 3.8 Flash** | Native reactive tool execution (`run_command`), rapid file modification, direct terminal feedback. |
49
+ | **Hermetic / Local Security Analysis** | **Headless Terminal Worker** | **Ollama / Local DeepSeek-R1** | Air-gapped execution for proprietary credentials, licensing checks, or sensitive security audits. |
50
+
51
+ ---
52
+
53
+ ## 3. The Calibration Workflow
54
+
55
+ ```mermaid
56
+ sequenceDiagram
57
+ autonumber
58
+ participant Orch as Orchestrator Chat
59
+ participant Repo as Codebase Context
60
+ participant User as Human Operator
61
+
62
+ Orch->>Repo: Inspects project language, repo structure & open issues
63
+ Note over Orch: Formulates primary triad + 2 alternate candidates
64
+ Orch->>User: Renders interactive ask_question modal with recommendations & alternatives
65
+ User-->>Orch: Submits chosen triad (or specifies custom modifications)
66
+ Orch->>Repo: Writes garden-swarm.json manifest
67
+ ```
68
+
69
+ ### Step 1: Codebase & Task Analysis
70
+ 1. Inspect repository stack (e.g., Nim, Rust, Python, TypeScript, C).
71
+ 2. Read project `AGENTS.md` and `README.md` to identify existing conventions.
72
+ 3. Determine task scope:
73
+ - *Refactoring / Technical Debt*: Prioritize Refactoring Purist + Test Auditor.
74
+ - *Greenfield Subsystem*: Prioritize Systems Architect + API Designer.
75
+ - *Security / Compliance*: Prioritize ISO Compliance Auditor + Security Adversary.
76
+
77
+ ### Step 2: Formulate Recommendation & Alternatives
78
+ Synthesize the primary triad and at least two alternative candidates:
79
+ - **Primary Triad**:
80
+ - Persona 1: Name, Role title, Mandate, Suggested Harness, Suggested Model.
81
+ - Persona 2: Name, Role title, Mandate, Suggested Harness, Suggested Model.
82
+ - Persona 3: Name, Role title, Mandate, Suggested Harness, Suggested Model.
83
+ - **Alternative Candidates**:
84
+ - Alternate A: e.g. Performance Benchmarking Engineer.
85
+ - Alternate B: e.g. Documentation & Developer Education Lead.
86
+
87
+ ### Step 3: Interactive Operator Ratification (`ask_question`)
88
+ Invoke `ask_question` with structured, selectable options:
89
+ - Option 1 (Recommended): Primary Triad (with explicit harnesses and models listed).
90
+ - Option 2: Alternative balance (e.g. replacing Purist with Performance Engineer).
91
+ - Option 3: Custom configuration (allows user write-in).
92
+
93
+ ### Step 4: Generate Swarm Manifest (`garden-swarm.json`)
94
+ Once ratified, write `garden-swarm.json` to the target project directory:
95
+
96
+ ```json
97
+ {
98
+ "project": "my-project",
99
+ "created_at": "2026-09-28T12:00:00Z",
100
+ "workers": [
101
+ {
102
+ "name": "architect",
103
+ "persona": "Marcus Vance",
104
+ "role": "Staff Systems Architect",
105
+ "harness": "antigravity",
106
+ "model": "gemini-3-8-flash",
107
+ "tags": ["systems", "architecture", "coordinator"],
108
+ "system_prompt": "You are Marcus Vance, Staff Systems Architect...",
109
+ "startup_command": "rhizo listen architect"
110
+ },
111
+ {
112
+ "name": "auditor",
113
+ "persona": "Caleb Thorne",
114
+ "role": "Code Quality & Refactoring Purist",
115
+ "harness": "claude-code",
116
+ "model": "claude-3-5-sonnet",
117
+ "tags": ["qa", "audit", "purist"],
118
+ "system_prompt": "You are Caleb Thorne, Refactoring Purist...",
119
+ "startup_command": "claude --agent auditor"
120
+ },
121
+ {
122
+ "name": "implementer",
123
+ "persona": "Elena Rostova",
124
+ "role": "DevEx & Implementation Lead",
125
+ "harness": "antigravity",
126
+ "model": "gemini-3-8-flash",
127
+ "tags": ["dev", "devex", "build"],
128
+ "system_prompt": "You are Elena Rostova, DevEx Lead...",
129
+ "startup_command": "rhizo listen implementer"
130
+ }
131
+ ]
132
+ }
133
+ ```
134
+
135
+ ---
136
+
137
+ ## 4. Verification & Handoff
138
+
139
+ Before concluding:
140
+ 1. Verify `garden-swarm.json` is syntactically valid JSON.
141
+ 2. Confirm each worker has unique `name` and non-empty `tags`.
142
+ 3. Proceed directly to [`launch-workers`](../launch-workers/SKILL.md).
@@ -0,0 +1,137 @@
1
+ ---
2
+ name: dialectical-pump
3
+ description: "Drives empirical multi-perspective deliberation and synthesis across agent personas. Enforces the strict invariant that dialectical exchanges are NOT theatrical dialogue: every turn must be grounded in tool calls (reading file lines, executing tests, running benchmarks, checking git history). Operates across three sequential stages: (1) Research & Understanding Doc with automated Fact-Check Gate, (2) Product & System Architecture Design Doc, and (3) Adversarial Design Review, Audit Report generation, and finding remediation. Triggers: 'dialectical pump', 'run dialectical pump', 'pump perspectives', 'triadic deliberation', 'dialectical research', 'dialectical design', 'dialectical review'."
4
+ ---
5
+
6
+ # `dialectical-pump`: Grounded Multi-Persona Deliberation Engine
7
+
8
+ > **Thesis $\times$ Antithesis $\to$ Empirical Synthesis**
9
+ > *The Dialectical Pump is an epistemic machine. It prevents hallucinated consensus and green mirages by forcing opposing personas to prove every assertion through real tool execution.*
10
+
11
+ ---
12
+
13
+ ## 1. The Core Invariant: Zero Theatrical Dialogue
14
+
15
+ > [!CAUTION] **STRICT PROHIBITION: Theatrical Dialogue is Rejected**
16
+ > A common failure mode in LLM roleplay is generating conversational chit-chat:
17
+ > *"Persona A: I think we should use Redis! Persona B: I agree, but what about memory? Persona A: Good point!"*
18
+ > **This is banned.**
19
+
20
+ Every turn taken by a persona in the Dialectical Pump must follow the **Empirical Grounding Protocol**:
21
+ 1. **Tool Invocation**: Every claim must be substantiated by a tool call:
22
+ - Reading exact line numbers: `view_file(AbsolutePath=..., StartLine=..., EndLine=...)`.
23
+ - Running test suites: `run_command(CommandLine="pytest ...")`.
24
+ - Measuring execution or memory: `run_command(CommandLine="time ...")`.
25
+ - Checking git history/diffs: `run_command(CommandLine="git log -S ...")`.
26
+ 2. **Hard Evidence Citations**: Every critique must cite verifiable evidence:
27
+ - *Prohibited*: "This function looks inefficient."
28
+ - *Mandated*: "Profiling `parsePayload` at `src/resp.nim:88` reveals an allocation of a 64KB temporary string per message; under 10k messages/sec, this triggers 640MB/sec of GC churn as verified by `nimble bench`."
29
+
30
+ ---
31
+
32
+ ## 2. The Three Dialectical Stages
33
+
34
+ The Dialectical Pump executes across three distinct stages of a project:
35
+
36
+ ```mermaid
37
+ flowchart TD
38
+ subgraph Stage1["Stage 1: Grounded Research"]
39
+ S1A["1. Triad plans research questions"]
40
+ S1B["2. Workers explore code & tests"]
41
+ S1C["3. Synthesize understanding.md"]
42
+ S1D["4. Automated Fact-Check Gate"]
43
+ S1A --> S1B --> S1C --> S1D
44
+ end
45
+
46
+ subgraph Stage2["Stage 2: Architecture & Design"]
47
+ S2A["1. Systems Architect drafts thesis"]
48
+ S2B["2. Purist Auditor attacks failure modes"]
49
+ S2C["3. DevEx Lead balances ergonomics"]
50
+ S2D["4. Synthesize design.md"]
51
+ S2A --> S2B --> S2C --> S2D
52
+ end
53
+
54
+ subgraph Stage3["Stage 3: Adversarial Review & Audit"]
55
+ S3A["1. Auditor files audit_report.md"]
56
+ S3B["2. Personas resolve findings"]
57
+ S3C["3. Ratified design.md"]
58
+ S3A --> S3B --> S3C
59
+ end
60
+
61
+ Stage1 --> Stage2 --> Stage3
62
+ ```
63
+
64
+ ---
65
+
66
+ ## 3. Stage 1: Grounded Research & Fact-Check Gate
67
+
68
+ ### Step 1.1: Research Plan Formulation
69
+ The triadic personas inspect the assignment and agree on the empirical questions:
70
+ - What are the existing invariants in the codebase?
71
+ - What dependencies and protocols exist?
72
+ - What test suites cover this subsystem?
73
+
74
+ ### Step 1.2: Codebase Exploration
75
+ Workers read actual files, verify test suites, and map domain structures.
76
+
77
+ ### Step 1.3: Generate Understanding Document (`understanding.md`)
78
+ The triad synthesizes their findings into `understanding.md` containing:
79
+ - Domain Glossary & Invariants.
80
+ - Data Flow Diagrams.
81
+ - Identified Constraints & Technical Debt.
82
+
83
+ ### Step 1.4: The Strict Fact-Check Gate
84
+ Before proceeding to design, a dedicated Auditor persona audits `understanding.md`:
85
+ - Every file reference must exist (`test -f <path>`).
86
+ - Every function signature cited must match reality.
87
+ - If any claim is ungrounded or fabricated, the pump repeats Step 1.2 until 100% verified.
88
+
89
+ ---
90
+
91
+ ## 4. Stage 2: Architecture & System Design (`design.md`)
92
+
93
+ Once research is fact-checked, the pump shifts to product and technical design:
94
+
95
+ ### Step 2.1: The Thesis (Systems Architect)
96
+ The Systems Architect proposes the macro architecture:
97
+ - Module decomposition.
98
+ - Data structures and wire formats.
99
+ - Concurrency model and lifecycle states.
100
+
101
+ ### Step 2.2: The Antithesis (Purist Auditor)
102
+ The Purist Auditor stress-tests the proposal against concrete failure modes:
103
+ - Concurrency race conditions: "What happens if process A dies between lines X and Y?"
104
+ - Resource leaks: "Where are file descriptors closed during exception unwinding?"
105
+ - Backwards compatibility: "Does this break existing configs or CLI arguments?"
106
+
107
+ ### Step 2.3: The Synthesis (DevEx & Implementation Lead)
108
+ The DevEx Lead resolves the dialectic:
109
+ - Eliminates unnecessary abstractions that create ergonomics drag.
110
+ - Hardens the API contracts.
111
+ - Produces the ratified **`design.md`**.
112
+
113
+ ---
114
+
115
+ ## 5. Stage 3: Adversarial Review & Audit Report
116
+
117
+ ### Step 3.1: Forensic Audit Inspection
118
+ An Auditor persona performs a line-by-line inspection of `design.md` against single-source truth and ISO standards, generating **`audit_report.md`**:
119
+ - Defect codes: `CRIT-01`, `WARN-02`, `DOC-03`.
120
+ - Root cause analysis.
121
+ - Specific non-prescriptive recommendation options.
122
+
123
+ ### Step 3.2: Remediation & Resolution
124
+ The triad meets to address every finding in `audit_report.md`:
125
+ - For each defect code: select an option, update `design.md`, and record the resolution in the audit report.
126
+ - The gate only clears when **0 critical or blocker defects remain open**.
127
+
128
+ ---
129
+
130
+ ## 6. Output Artifacts
131
+
132
+ At the conclusion of the Dialectical Pump:
133
+ 1. `understanding.md` (Grounded and fact-checked).
134
+ 2. `design.md` (Debated, hardened, and synthesized).
135
+ 3. `audit_report.md` (All findings addressed and closed).
136
+
137
+ Proceed immediately to [`plan-implementation`](../plan-implementation/SKILL.md).
@@ -0,0 +1,133 @@
1
+ ---
2
+ name: garden
3
+ description: "Master entrypoint and end-to-end ceremony director for multi-agent swarms operating on top of Rhizo (transport) and Vine (workspace integrator). Guides the user and orchestrator session through the full lifecycle: persona selection with harness/model pairing, tmux worker fleet provisioning with live terminal viewer, 3-stage empirical dialectical pump (research, design, audit), master implementation planning with locking/strand schedules, and live swarm execution with Two-Key gate verification and fast-forward trunk weaving. Triggers: 'garden', 'run garden', 'swarm this project', 'orchestrate with garden', 'start garden swarm', 'run the full garden ceremony'."
4
+ ---
5
+
6
+ # Garden: Multi-Agent Swarm Ceremony & Orchestration Engine
7
+
8
+ > **The Sovereign Orchestration Layer for Autonomous AI Swarms**
9
+ > *Where `rhizo` is the transport nervous system and `vine` is the workspace integrator, `garden` is the institutional intellect, deliberation crucible, and master ceremony conductor.*
10
+
11
+ ---
12
+
13
+ ## 1. Architectural Architecture & Layering
14
+
15
+ Garden coordinates teams of heterogeneous AI coding assistants across terminals and machines:
16
+
17
+ ```mermaid
18
+ flowchart TD
19
+ subgraph Garden["Garden Layer (Methodology & Ceremonies)"]
20
+ Phase1["Phase 1: choose-personas (Team Selection & Models)"]
21
+ Phase2["Phase 2: launch-workers (tmux & Terminal Viewer)"]
22
+ Phase3["Phase 3: dialectical-pump (Research ➔ Design ➔ Audit)"]
23
+ Phase4["Phase 4: plan-implementation (Locking & Strands)"]
24
+ Phase5["Phase 5: orchestrate-swarm (Dispatch & Vine Weaving)"]
25
+ end
26
+
27
+ subgraph Infrastructure["Coordination Infrastructure"]
28
+ Rhizo["Rhizo (Redis Bus, Fencing Mutexes, Work Queues)"]
29
+ Vine["Vine (APFS CoW Strands, Two-Key Gate, Weaving)"]
30
+ end
31
+
32
+ Phase1 --> Phase2 --> Phase3 --> Phase4 --> Phase5
33
+ Phase2 -.-> Rhizo
34
+ Phase3 -.-> Rhizo
35
+ Phase4 -.-> Rhizo & Vine
36
+ Phase5 -.-> Rhizo & Vine
37
+ ```
38
+
39
+ ---
40
+
41
+ ## 2. The 5-Phase End-to-End Ceremony
42
+
43
+ When invoked, the Orchestrator (the primary conversation chat) executes these five phases sequentially. Never skip phases or invert the order.
44
+
45
+ ```mermaid
46
+ sequenceDiagram
47
+ autonumber
48
+ actor User as Human Operator
49
+ participant Orch as Main Chat (Orchestrator)
50
+ participant Swarm as Tmux Worker Swarm
51
+ participant Bus as Rhizo (Redis)
52
+ participant Gate as Vine (Strands & Gate)
53
+
54
+ User->>Orch: "garden: implement feature X"
55
+ Note over Orch: Phase 1: Team Calibration
56
+ Orch->>User: Suggests Persona Roster (Roles, Harnesses, Models) via ask_question
57
+ User-->>Orch: Ratifies / Adjusts Roster
58
+
59
+ Note over Orch: Phase 2: Fleet Provisioning
60
+ Orch->>Swarm: Executes launch-workers (tmux panes + Ghostty/Terminal viewer)
61
+ Swarm->>Bus: rhizo open + rhizo listen (Workers armed)
62
+
63
+ Note over Orch: Phase 3: Empirical Dialectic
64
+ Orch->>Swarm: Dispatches dialectical-pump
65
+ Note over Swarm: 1. Research ➔ understanding.md ➔ Fact-Check Gate<br/>2. Architecture ➔ design.md<br/>3. Adversarial Audit ➔ audit_report.md ➔ Remediation
66
+ Swarm-->>Orch: Ratified design.md & cleared audit report
67
+
68
+ Note over Orch: Phase 4: Master Planning
69
+ Orch->>Orch: Authors implementation_plan.md (Locks, Strands, To-Do list)
70
+
71
+ Note over Orch: Phase 5: Swarm Execution & Weaving
72
+ loop For Each Plan Task
73
+ Orch->>Bus: Dispatch task (rhizo send / enqueue)
74
+ Bus->>Swarm: Worker claims lease (rhizo claim)
75
+ Swarm->>Gate: Creates strand (vine new)
76
+ Swarm->>Swarm: Implements code + verifies tests
77
+ Swarm->>Gate: Verifies Two-Key Gate (vine gate)
78
+ Swarm->>Orch: Reports gate pass (rhizo reply)
79
+ Orch->>Gate: Fast-forward merge (vine weave)
80
+ Orch->>Orch: Updates plan checkbox & Harness To-Do
81
+ end
82
+ Orch->>User: Mission Accomplished Summary
83
+ ```
84
+
85
+ ---
86
+
87
+ ## 3. Phase Transition Protocols & Quality Gates
88
+
89
+ ### Gate 1 $\to$ 2: Persona Ratification Gate
90
+ - **Condition**: Operator has confirmed the roster via `ask_question`.
91
+ - **Artifact**: `garden-swarm.json` persisted in the project directory.
92
+ - **Action**: Call `launch-workers`.
93
+
94
+ ### Gate 2 $\to$ 3: Cluster Readiness Gate
95
+ - **Condition**: All worker panes booted, heartbeats active in Redis.
96
+ - **Verification**: `rhizo who --json` confirms 100% of agents online and tagged.
97
+ - **Action**: Call `dialectical-pump`.
98
+
99
+ ### Gate 3 $\to$ 4: Design Audit Clearance Gate
100
+ - **Condition**:
101
+ 1. `understanding.md` passed the Fact-Check Gate (zero ungrounded claims).
102
+ 2. `design.md` authored and debated by the triadic pump.
103
+ 3. `audit_report.md` contains 0 open `CRIT` or `BLOCKER` defects.
104
+ - **Action**: Call `plan-implementation`.
105
+
106
+ ### Gate 4 $\to$ 5: Plan Alignment Gate
107
+ - **Condition**: `implementation_plan.md` complete with task matrix, locking schedule, vine strand lifecycles, and emergent design addendum protocol.
108
+ - **Action**: Call `orchestrate-swarm`.
109
+
110
+ ---
111
+
112
+ ## 4. Sub-Skill Reference Map
113
+
114
+ When executing Garden, invoke the sub-skills at their designated phases:
115
+
116
+ | Phase | Skill Name | Description | Primary Artifacts |
117
+ | :--- | :--- | :--- | :--- |
118
+ | **Phase 1** | [`choose-personas`](../choose-personas/SKILL.md) | Analyzes task, formulates 3 balanced personas with suggested **coding harness** and **model**, and confirms with operator. | `garden-swarm.json` |
119
+ | **Phase 2** | [`launch-workers`](../launch-workers/SKILL.md) | Provisions tmux session with worker panes, registers `rhizo open`, arms listeners, and launches OS terminal viewer (Ghostty / Terminal.app). | Live tmux session, visible terminal |
120
+ | **Phase 3** | [`dialectical-pump`](../dialectical-pump/SKILL.md) | Drives empirical multi-persona debate grounded in tool calls (file reading, test running, AST inspecting). Produces research, design, and audit docs. | `understanding.md`, `design.md`, `audit_report.md` |
121
+ | **Phase 4** | [`plan-implementation`](../plan-implementation/SKILL.md) | Authors master implementation plan detailing task assignments, `rhizo` locks (`--fencing`), `vine` strands, dynamic checkboxes, and To-Do tracking. | `implementation_plan.md` |
122
+ | **Phase 5** | [`orchestrate-swarm`](../orchestrate-swarm/SKILL.md) | Main-chat governor: dispatches tasks over Redis, tracks heartbeats, approves emergent design addenda, and executes `vine weave` upon Two-Key gate pass. | Completed code, woven trunk, git commits |
123
+
124
+ ---
125
+
126
+ ## 5. Invariants & Rules of Engagement
127
+
128
+ 1. **The Supreme Orchestrator Invariant**:
129
+ The primary conversation session acts as the Supreme Orchestrator. It coordinates, plans, reviews, and merges. It delegates intensive multi-file edits to the worker fleet.
130
+ 2. **Zero Theatrical Dialogue**:
131
+ In dialectical deliberations, every assertion must be backed by empirical evidence (line citations, test execution outputs, compiler errors).
132
+ 3. **No Unmanaged Daemons / Zero Dirty Commits**:
133
+ All coordination metadata (`.rhizo.*`, `.vine.*`, `*.lock`) must remain in `.gitignore`. Workers must adhere to the Two-Key Gate before any code touches the canonical trunk.
@@ -0,0 +1,106 @@
1
+ ---
2
+ name: launch-workers
3
+ description: "Provisions an active worker fleet inside a dedicated tmux session and launches an OS-level terminal viewer (Ghostty / Terminal.app). Reads garden-swarm.json, creates named tmux windows/panes for each worker, configures environment variables (RHIZO_AGENT_NAME, project path), registers each agent in Redis with rhizo open, arms background listeners, and runs AppleScript or open commands on macOS to display the live worker windows to the operator. Verifies cluster heartbeat readiness via rhizo who --json before handing off. Triggers: 'launch workers', 'spin up workers', 'start worker swarm', 'open tmux swarm', 'launch fleet'."
4
+ ---
5
+
6
+ # `launch-workers`: Automated Tmux Swarm Provisioning & Terminal Viewer
7
+
8
+ > **From Manifest to Live Terminals in Under 2 Seconds**
9
+ > *Tmux multiplexes the background worker processes while OS-level desktop scripting opens your preferred terminal app so you can observe the swarm in real time.*
10
+
11
+ ---
12
+
13
+ ## 1. System Requirements & Invariants
14
+
15
+ 1. **`tmux` is Required**:
16
+ - `tmux 3.0+` must be installed on the host (`command -v tmux`). If missing, fail fast and instruct the operator to install (`brew install tmux`).
17
+ 2. **`rhizo` is Required**:
18
+ - Rhizo engine must be present (`npm install -g @axiomantic/rhizo`).
19
+ 3. **No Terminal Fallbacks**:
20
+ - Workers are strictly managed inside tmux windows/panes. We do not detach headless rogue background processes with `nohup` or `&`.
21
+ 4. **Desktop Viewer Priority on macOS**:
22
+ - Automatically detects installed terminal emulators:
23
+ - **Priority 1: Ghostty** (`/Applications/Ghostty.app`)
24
+ - **Priority 2: iTerm2** (`/Applications/iTerm.app`)
25
+ - **Priority 3: macOS Terminal** (`/System/Applications/Utilities/Terminal.app`)
26
+ - Pops open a visible terminal window running `tmux attach-session -t garden-<project>`.
27
+
28
+ ---
29
+
30
+ ## 2. The Provisioning Flow
31
+
32
+ ```mermaid
33
+ sequenceDiagram
34
+ autonumber
35
+ participant Orch as Main Chat (Orchestrator)
36
+ participant Script as launch_tmux_swarm.sh
37
+ participant Tmux as tmux Daemon
38
+ participant OS as macOS Window Server (Ghostty / Terminal)
39
+ participant Redis as Rhizo (Redis Bus)
40
+
41
+ Orch->>Script: Invokes with --swarm-file garden-swarm.json
42
+ Script->>Tmux: Creates session garden-<project>
43
+ loop For Each Worker in Manifest
44
+ Script->>Tmux: Creates named window/pane
45
+ Script->>Tmux: Injects RHIZO_AGENT_NAME & cd <project>
46
+ Script->>Tmux: Sends rhizo open <name> "<tags>"
47
+ Script->>Tmux: Arms listener (rhizo listen or custom startup command)
48
+ Tmux->>Redis: Registers heartbeat & listener lock
49
+ end
50
+ Script->>OS: Opens Ghostty/Terminal attached to tmux session
51
+ Script-->>Orch: Returns JSON status
52
+ Orch->>Redis: Verifies cluster readiness (rhizo who --json)
53
+ ```
54
+
55
+ ---
56
+
57
+ ## 3. Execution Procedure
58
+
59
+ ### Step 1: Run the Swarm Provisioner
60
+ Execute [`scripts/launch_tmux_swarm.sh`](file:///Users/eek/Development/garden/scripts/launch_tmux_swarm.sh) with the active project path and manifest:
61
+
62
+ ```bash
63
+ /Users/eek/Development/garden/scripts/launch_tmux_swarm.sh \
64
+ --project-dir "$(pwd)" \
65
+ --swarm-file "garden-swarm.json" \
66
+ --force
67
+ ```
68
+
69
+ - `--force`: Kills any stale prior session with the same project name before provisioning a clean fleet.
70
+ - Automatically launches Ghostty or Terminal.app on macOS attached to the new session.
71
+
72
+ ### Step 2: Verify Cluster Readiness Gate
73
+ Before dispatching tasks, verify that every worker from `garden-swarm.json` is actively registered in Redis and displaying valid heartbeats:
74
+
75
+ ```bash
76
+ rhizo who --json
77
+ ```
78
+
79
+ **Pass Criteria**:
80
+ 1. All worker names in `garden-swarm.json` appear in `active_agents`.
81
+ 2. Heartbeats have active TTLs (> 0).
82
+ 3. Assigned tags match the manifest.
83
+
84
+ ### Step 3: Inspect Terminal Buffer (Health Check)
85
+ To check the initial logs or output of any worker without leaving your chat:
86
+
87
+ ```bash
88
+ # Capture last 20 lines of worker 'architect' (window 0)
89
+ tmux capture-pane -p -t garden-<project>:0 | tail -n 20
90
+ ```
91
+
92
+ ---
93
+
94
+ ## 4. Teardown & Swarm Cleanup
95
+
96
+ When the entire project is completed, or when canceling a run:
97
+
98
+ ```bash
99
+ # Gracefully deregister all swarm agents from Redis:
100
+ for worker in $(python3 -c "import json; [print(w['name']) for w in json.load(open('garden-swarm.json'))['workers']]"); do
101
+ rhizo close "$worker" 2>/dev/null || true
102
+ done
103
+
104
+ # Terminate the tmux session:
105
+ tmux kill-session -t garden-<project> 2>/dev/null || true
106
+ ```