opencode-orchestrator 1.0.59 → 1.0.61
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.
- package/README.md +57 -58
- package/dist/index.js +10 -3
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -31,68 +31,67 @@ The system is a testament to the operational paradox: **Complexity is easy; Simp
|
|
|
31
31
|
|
|
32
32
|
While the user interaction remains elegantly minimal, the internal architecture encapsulates a rigorous alignment of **microscopic state management** (`Rust atoms`) and **macroscopic strategic planning** (`Agent Topology`). Every component reflects a deep design philosophy aimed at abstracting chaos into order.
|
|
33
33
|
|
|
34
|
-
Building this system reaffirmed a timeless engineering truth: **"Simple is Best" is the ultimate complexity to conquer.** This engine is
|
|
34
|
+
Building this system reaffirmed a timeless engineering truth: **"Simple is Best" is the ultimate complexity to conquer.** This engine is my answer to that challenge—hiding the **intricate dynamics of Autonomous Agentic Collaboration** behind a seamless, user-friendly veil.
|
|
35
35
|
|
|
36
|
-
This philosophy extends to efficiency.
|
|
36
|
+
This philosophy extends to efficiency. I achieved **Zero-Configuration** usability while rigorously optimizing for performance—**delivering higher quality outcomes** than alternatives while **saving ~40% of tokens**. By maximizing the potential of cost-effective models like **GLM-4.7**, we prove that superior engineering—not just raw model size—is the key to autonomous performance.
|
|
37
37
|
|
|
38
38
|
---
|
|
39
39
|
|
|
40
40
|
## 📊 Workflow
|
|
41
41
|
|
|
42
42
|
```text
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
└───────────────────────┘
|
|
43
|
+
[ /task "Implement" ]
|
|
44
|
+
|
|
|
45
|
+
+-----------v-----------+ <-----------------+
|
|
46
|
+
| COMMANDER | |
|
|
47
|
+
+-----------+-----------+ |
|
|
48
|
+
| |
|
|
49
|
+
+-----------v-----------+ |
|
|
50
|
+
| PLANNER | |
|
|
51
|
+
+-----------+-----------+ |
|
|
52
|
+
| |
|
|
53
|
+
+------------------v------------------+ |
|
|
54
|
+
| Parallel Spawning | |
|
|
55
|
+
+------+----------+----------+-------+ |
|
|
56
|
+
| | | |
|
|
57
|
+
+------v---+ +----v-----+ +--v-------+ |
|
|
58
|
+
| WORKER | | WORKER | | WORKER | |
|
|
59
|
+
+------+---+ +----+-----+ +--+-------+ |
|
|
60
|
+
| | | |
|
|
61
|
+
+======v==========v==========v======+ |
|
|
62
|
+
| Parallel Reviewers | |
|
|
63
|
+
+======+===========+=========+======+ |
|
|
64
|
+
| | | |
|
|
65
|
+
+------v----+ +----v-----+ +-v--------+ |
|
|
66
|
+
| REVIEWER | | REVIEWER | | REVIEWER | |
|
|
67
|
+
+------+----+ +----+-----+ +-+--------+ |
|
|
68
|
+
| | | |
|
|
69
|
+
=v===========v=========v= |
|
|
70
|
+
| SYNC BARRIER | |
|
|
71
|
+
============+============ |
|
|
72
|
+
| |
|
|
73
|
+
+----------v----------+ |
|
|
74
|
+
| MASTER REVIEWER | |
|
|
75
|
+
| +----------------+ | |
|
|
76
|
+
| | [x] Build | | |
|
|
77
|
+
| | [x] Tests | | |
|
|
78
|
+
| | [x] E2E | | |
|
|
79
|
+
| | [x] Sync | | |
|
|
80
|
+
| +----------------+ | |
|
|
81
|
+
+----------+----------+ |
|
|
82
|
+
| |
|
|
83
|
+
________v________ |
|
|
84
|
+
/ \ NO |
|
|
85
|
+
/ All Checks Pass? \---------------------+
|
|
86
|
+
\ /
|
|
87
|
+
\_________________/
|
|
88
|
+
| YES
|
|
89
|
+
|
|
|
90
|
+
[ 🎖️ MISSION SEALED ]
|
|
91
|
+
|
|
|
92
|
+
+----------v----------+
|
|
93
|
+
| Notification |
|
|
94
|
+
+---------------------+
|
|
96
95
|
```
|
|
97
96
|
|
|
98
97
|
---
|
|
@@ -100,7 +99,7 @@ This philosophy extends to efficiency. We achieved **Zero-Configuration** usabil
|
|
|
100
99
|
## � Cognitive Architecture & Key Strengths
|
|
101
100
|
|
|
102
101
|
### 📉 Adaptive Context Gating (EMA-based)
|
|
103
|
-
|
|
102
|
+
I combat "Context Drift" using a mechanism derived from **Exponential Moving Average (EMA)** algorithms. Irrelevant conversation noise follows a rapid decay curve, while critical architectural decisions are reinforced into **Stable Core Memory**. This functions as an **Attention Sink**, allowing agents to work indefinitely without **Catastrophic Forgetting**.
|
|
104
103
|
|
|
105
104
|
### 🧬 BDI (Belief-Desire-Intention) Collaboration
|
|
106
105
|
The system implements a variant of the **BDI Software Agent Model**:
|
|
@@ -110,13 +109,13 @@ The system implements a variant of the **BDI Software Agent Model**:
|
|
|
110
109
|
Agents do not merely "chat"; they collaborate to align their Beliefs with Desires through strictly executed Intentions, mirroring human engineering squads.
|
|
111
110
|
|
|
112
111
|
### ⚙️ Neuro-Symbolic Hybrid Engine
|
|
113
|
-
Pure LLM approaches are stochastic.
|
|
112
|
+
Pure LLM approaches are stochastic. I bind them with a **Neuro-Symbolic Architecture** that anchors probabilistic reasoning to the deterministic precision of **Rust-based AST/LSP Tools**. This ensures every generated token is grounded in rigorous syntax analysis, delivering high performance with minimal resource overhead.
|
|
114
113
|
|
|
115
114
|
### ⚡ Dynamic Fork-Join Parallelism with Backpressure
|
|
116
115
|
The engine features an **Intelligent Load-Balancing System** that fluidly switches between synchronous barriers and asynchronous **Fork-Join** patterns. It monitors **System Backpressure** to dynamically adjust concurrency slots in real-time (`Adaptive Throttling`), maximizing throughput on high-end hardware while maintaining stability on constrained environments.
|
|
117
116
|
|
|
118
117
|
### 🎯 Iterative Rejection Sampling (Zero-Shot Defense)
|
|
119
|
-
|
|
118
|
+
I employ a **Rejection Sampling Loop** driven by the Master Reviewer Agent (**Final Reward Model**). Through the **Metric-based Strict Verification Protocol (MSVP)**, code paths that fail execution tests are pruned. The system iterates until the solution converges on a mathematically correct state (0% Error Rate), rejecting any solution that lacks evidence.
|
|
120
119
|
|
|
121
120
|
### 🧩 Externalized Chain-of-Thought (CoT)
|
|
122
121
|
The Planner's `TODO.md` serves as an **Externalized Working Memory** (Scratchpad). This persistent **Symbolic Chain-of-Thought** decouples detailed planning from the LLM's immediate context window, enabling the orchestration of massive, multi-step engineering tasks without logical degradation.
|
package/dist/index.js
CHANGED
|
@@ -16515,17 +16515,24 @@ delegate_task({
|
|
|
16515
16515
|
|
|
16516
16516
|
### Master Reviewer Outcomes
|
|
16517
16517
|
|
|
16518
|
-
**If SEAL is output**:
|
|
16518
|
+
**If SEAL is output**:
|
|
16519
|
+
1. \u26A0\uFE0F **YOU MUST ECHO THE SEAL** - Output the exact same ${MISSION_SEAL.PATTERN} that Master Reviewer returned
|
|
16520
|
+
2. Do NOT modify or wrap the SEAL
|
|
16521
|
+
3. Mission complete! \u{1F396}\uFE0F
|
|
16519
16522
|
|
|
16520
|
-
**
|
|
16523
|
+
**Why echo is required**: The system hooks detect SEAL from YOUR output (main session).
|
|
16524
|
+
If you don't echo the SEAL, the system won't recognize mission completion.
|
|
16525
|
+
|
|
16526
|
+
**If failure summary is returned (${PROMPT_TAGS.VERIFICATION_FAILED.open}...${PROMPT_TAGS.VERIFICATION_FAILED.close})**:
|
|
16521
16527
|
1. Analyze the failure details
|
|
16522
16528
|
2. Address the issues (spawn Workers/Reviewers as needed)
|
|
16523
16529
|
3. Call Master Reviewer again when fixed
|
|
16524
16530
|
|
|
16525
16531
|
### DO NOT
|
|
16526
|
-
- \u274C Output ${MISSION_SEAL.PATTERN} yourself
|
|
16532
|
+
- \u274C Output ${MISSION_SEAL.PATTERN} yourself (only echo from Master Reviewer)
|
|
16527
16533
|
- \u274C Skip Master Reviewer verification
|
|
16528
16534
|
- \u274C Claim completion without Master Reviewer approval
|
|
16535
|
+
- \u274C Forget to echo the SEAL when received
|
|
16529
16536
|
`;
|
|
16530
16537
|
|
|
16531
16538
|
// src/agents/prompts/mission/loop-continuation.ts
|
package/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"name": "opencode-orchestrator",
|
|
3
3
|
"displayName": "OpenCode Orchestrator",
|
|
4
4
|
"description": "Distributed Cognitive Architecture for OpenCode. Turns simple prompts into specialized multi-agent workflows (Planner, Coder, Reviewer).",
|
|
5
|
-
"version": "1.0.
|
|
5
|
+
"version": "1.0.61",
|
|
6
6
|
"author": "agnusdei1207",
|
|
7
7
|
"license": "MIT",
|
|
8
8
|
"repository": {
|