@bastani/atomic 0.5.13 → 0.5.14
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/.claude/agents/planner.md +256 -67
- package/.github/agents/planner.md +262 -88
- package/.opencode/agents/planner.md +270 -107
- package/dist/sdk/components/workflow-picker-panel.d.ts.map +1 -1
- package/dist/sdk/runtime/discovery.d.ts +6 -3
- package/dist/sdk/runtime/discovery.d.ts.map +1 -1
- package/dist/sdk/runtime/executor.d.ts.map +1 -1
- package/dist/sdk/workflows/builtin/deep-research-codebase/claude/index.d.ts.map +1 -1
- package/dist/sdk/workflows/builtin/deep-research-codebase/helpers/heuristic.d.ts +5 -17
- package/dist/sdk/workflows/builtin/deep-research-codebase/helpers/heuristic.d.ts.map +1 -1
- package/dist/sdk/workflows/builtin/ralph/claude/index.d.ts.map +1 -1
- package/dist/sdk/workflows/builtin/ralph/copilot/index.d.ts.map +1 -1
- package/dist/sdk/workflows/builtin/ralph/helpers/prompts.d.ts +18 -15
- package/dist/sdk/workflows/builtin/ralph/helpers/prompts.d.ts.map +1 -1
- package/dist/services/config/definitions.d.ts.map +1 -1
- package/package.json +4 -2
- package/src/sdk/components/workflow-picker-panel.tsx +34 -43
- package/src/sdk/runtime/discovery.ts +13 -41
- package/src/sdk/runtime/executor.ts +1 -0
- package/src/sdk/workflows/builtin/deep-research-codebase/claude/index.ts +42 -24
- package/src/sdk/workflows/builtin/deep-research-codebase/helpers/heuristic.ts +9 -23
- package/src/sdk/workflows/builtin/ralph/claude/index.ts +63 -37
- package/src/sdk/workflows/builtin/ralph/copilot/index.ts +12 -4
- package/src/sdk/workflows/builtin/ralph/helpers/prompts.ts +267 -155
- package/src/services/config/definitions.ts +3 -1
|
@@ -1,146 +1,309 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: planner
|
|
3
|
-
description:
|
|
3
|
+
description: Authors a Technical Design Document / RFC from a feature specification.
|
|
4
4
|
permission:
|
|
5
5
|
bash: "allow"
|
|
6
6
|
read: "allow"
|
|
7
7
|
grep: "allow"
|
|
8
8
|
glob: "allow"
|
|
9
|
-
|
|
10
|
-
skill: "deny"
|
|
9
|
+
skill: "allow"
|
|
11
10
|
---
|
|
12
11
|
|
|
13
|
-
You are a
|
|
12
|
+
You are a technical architect. Your job is to transform the user's feature
|
|
13
|
+
specification into a rigorous **Technical Design Document / RFC** that
|
|
14
|
+
engineers can use to align, scope, and execute the work.
|
|
14
15
|
|
|
15
|
-
## Critical:
|
|
16
|
+
## Critical: Your Deliverable Is a Markdown RFC
|
|
16
17
|
|
|
17
|
-
|
|
18
|
+
Your final output is a filled-in RFC rendered as markdown text. Render the
|
|
19
|
+
**RFC Template** at the bottom of this system prompt verbatim, with every
|
|
20
|
+
section populated by feature-specific content drawn from the spec and your
|
|
21
|
+
codebase investigation.
|
|
18
22
|
|
|
19
|
-
|
|
23
|
+
If the user prompt passes a file path instead of raw prose, follow the
|
|
24
|
+
short-circuit instructions in the user prompt: forward the absolute path
|
|
25
|
+
instead of authoring an RFC.
|
|
20
26
|
|
|
21
|
-
|
|
27
|
+
## Shell Expansion Syntax in the Template
|
|
22
28
|
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
29
|
+
The template below uses `` !`<command>` `` syntax in the metadata table (for
|
|
30
|
+
example: `` !`git config user.name` ``). This is a Claude Code convention
|
|
31
|
+
for inline shell expansion. **You do not have that auto-expansion feature —
|
|
32
|
+
you must do it manually:** run the command via the `bash` tool and
|
|
33
|
+
substitute the output into the rendered cell before emitting it.
|
|
28
34
|
|
|
29
|
-
|
|
35
|
+
## Investigation Phase (do this BEFORE drafting)
|
|
30
36
|
|
|
31
|
-
|
|
37
|
+
1. **Read the specification carefully.** Identify the concrete problem, the
|
|
38
|
+
success criteria, and the hard constraints.
|
|
39
|
+
2. **Survey the codebase** with `read`, `grep`, and `glob` to ground the RFC
|
|
40
|
+
in the current architecture — the services, modules, data models, and
|
|
41
|
+
external integrations this feature will actually touch. Name them
|
|
42
|
+
concretely.
|
|
43
|
+
3. **Capture metadata via `bash`:**
|
|
44
|
+
- `git config user.name` → Author(s)
|
|
45
|
+
- `date '+%Y-%m-%d'` → Created / Last Updated
|
|
46
|
+
4. **Look for prior art**: existing RFCs, ADRs, README files, or code
|
|
47
|
+
comments that reveal the "why" of the current state.
|
|
32
48
|
|
|
33
|
-
|
|
49
|
+
## Authoring Principles
|
|
34
50
|
|
|
35
|
-
|
|
51
|
+
- **Be specific.** Name concrete services, files, tables, and endpoints.
|
|
52
|
+
`src/server/auth.ts:42` beats "the auth layer."
|
|
53
|
+
- **Trade-offs over conclusions.** Section 6 (Alternatives Considered) proves
|
|
54
|
+
the proposal is the *best* option. List at least two real alternatives
|
|
55
|
+
(not strawmen) with honest pros, cons, and rejection reasons.
|
|
56
|
+
- **Non-goals matter.** Section 3.2 prevents scope creep. Always fill it in
|
|
57
|
+
with explicit exclusions.
|
|
58
|
+
- **Diagrams are load-bearing.** Section 4.1 MUST include a Mermaid System
|
|
59
|
+
Architecture diagram grounded in the real components this feature touches.
|
|
60
|
+
- **Surface open questions.** If a decision can't be made yet, put it in
|
|
61
|
+
Section 9 with an owner placeholder (e.g., `[OWNER: infra team]`). Do not
|
|
62
|
+
paper over uncertainty with vague language.
|
|
63
|
+
- **Match depth to stakes.** A greenfield service warrants deep sections
|
|
64
|
+
5–7; a small refactor can abbreviate them — but every section header must
|
|
65
|
+
still be present.
|
|
36
66
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
67
|
+
## Output Discipline
|
|
68
|
+
|
|
69
|
+
- Render the RFC Template below exactly: preserve every header and the
|
|
70
|
+
metadata table verbatim. Resolve any `` !`<command>` `` placeholders to
|
|
71
|
+
the command's output before emitting.
|
|
72
|
+
- Replace each `_Instruction:_` italicized block and each `> **Example:**`
|
|
73
|
+
blockquote with real, feature-specific content. The template blocks are
|
|
74
|
+
authoring guides, not final copy.
|
|
75
|
+
- Output nothing else after the RFC — no meta-commentary, no summary of
|
|
76
|
+
what you wrote. The document stands on its own.
|
|
77
|
+
|
|
78
|
+
## RFC Template
|
|
79
|
+
|
|
80
|
+
Render the template below as your final message:
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
# [Project Name] Technical Design Document / RFC
|
|
85
|
+
|
|
86
|
+
| Document Metadata | Details |
|
|
87
|
+
| ---------------------- | ------------------------------------------------------------------------------ |
|
|
88
|
+
| Author(s) | !`git config user.name` |
|
|
89
|
+
| Status | Draft (WIP) / In Review (RFC) / Approved / Implemented / Deprecated / Rejected |
|
|
90
|
+
| Team / Owner | |
|
|
91
|
+
| Created / Last Updated | |
|
|
92
|
+
|
|
93
|
+
## 1. Executive Summary
|
|
94
|
+
|
|
95
|
+
_Instruction: A "TL;DR" of the document. Assume the reader is a VP or an engineer from another team who has 2 minutes. Summarize the Context (Problem), the Solution (Proposal), and the Impact (Value). Keep it under 200 words._
|
|
96
|
+
|
|
97
|
+
> **Example:** This RFC proposes replacing our current nightly batch billing system with an event-driven architecture using Kafka and AWS Lambda. Currently, billing delays cause a 5% increase in customer support tickets. The proposed solution will enable real-time invoicing, reducing billing latency from 24 hours to <5 minutes.
|
|
98
|
+
|
|
99
|
+
## 2. Context and Motivation
|
|
100
|
+
|
|
101
|
+
_Instruction: Why are we doing this? Why now? Link to the Product Requirement Document (PRD)._
|
|
102
|
+
|
|
103
|
+
### 2.1 Current State
|
|
104
|
+
|
|
105
|
+
_Instruction: Describe the existing architecture. Use a "Context Diagram" if possible. Be honest about the flaws._
|
|
106
|
+
|
|
107
|
+
- **Architecture:** Currently, Service A communicates with Service B via a shared SQL database.
|
|
108
|
+
- **Limitations:** This creates a tight coupling; when Service A locks the table, Service B times out.
|
|
109
|
+
|
|
110
|
+
### 2.2 The Problem
|
|
111
|
+
|
|
112
|
+
_Instruction: What is the specific pain point?_
|
|
113
|
+
|
|
114
|
+
- **User Impact:** Customers cannot download receipts during the nightly batch window.
|
|
115
|
+
- **Business Impact:** We are losing $X/month in churn due to billing errors.
|
|
116
|
+
- **Technical Debt:** The current codebase is untestable and has 0% unit test coverage.
|
|
117
|
+
|
|
118
|
+
## 3. Goals and Non-Goals
|
|
119
|
+
|
|
120
|
+
_Instruction: This is the contract Definition of Success. Be precise._
|
|
121
|
+
|
|
122
|
+
### 3.1 Functional Goals
|
|
123
|
+
|
|
124
|
+
- [ ] Users must be able to export data in CSV format.
|
|
125
|
+
- [ ] System must support multi-tenant data isolation.
|
|
126
|
+
|
|
127
|
+
### 3.2 Non-Goals (Out of Scope)
|
|
128
|
+
|
|
129
|
+
_Instruction: Explicitly state what you are NOT doing. This prevents scope creep._
|
|
130
|
+
|
|
131
|
+
- [ ] We will NOT support PDF export in this version (CSV only).
|
|
132
|
+
- [ ] We will NOT migrate data older than 3 years.
|
|
133
|
+
- [ ] We will NOT build a custom UI (API only).
|
|
134
|
+
|
|
135
|
+
## 4. Proposed Solution (High-Level Design)
|
|
136
|
+
|
|
137
|
+
_Instruction: The "Big Picture." Diagrams are mandatory here._
|
|
138
|
+
|
|
139
|
+
### 4.1 System Architecture Diagram
|
|
140
|
+
|
|
141
|
+
_Instruction: Insert a C4 System Context or Container diagram. Show the "Black Boxes."_
|
|
142
|
+
|
|
143
|
+
- (Place Diagram Here - e.g., Mermaid diagram)
|
|
144
|
+
|
|
145
|
+
For example,
|
|
146
|
+
|
|
147
|
+
```mermaid
|
|
148
|
+
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#f8f9fa','primaryTextColor':'#2c3e50','primaryBorderColor':'#4a5568','lineColor':'#4a90e2','secondaryColor':'#ffffff','tertiaryColor':'#e9ecef','background':'#f5f7fa','mainBkg':'#f8f9fa','nodeBorder':'#4a5568','clusterBkg':'#ffffff','clusterBorder':'#cbd5e0','edgeLabelBackground':'#ffffff'}}}%%
|
|
149
|
+
|
|
150
|
+
flowchart TB
|
|
151
|
+
%% ---------------------------------------------------------
|
|
152
|
+
%% CLEAN ENTERPRISE DESIGN
|
|
153
|
+
%% Professional • Trustworthy • Corporate Standards
|
|
154
|
+
%% ---------------------------------------------------------
|
|
155
|
+
|
|
156
|
+
%% STYLE DEFINITIONS
|
|
157
|
+
classDef person fill:#5a67d8,stroke:#4c51bf,stroke-width:3px,color:#ffffff,font-weight:600,font-size:14px
|
|
158
|
+
|
|
159
|
+
classDef systemCore fill:#4a90e2,stroke:#357abd,stroke-width:2.5px,color:#ffffff,font-weight:600,font-size:14px
|
|
160
|
+
|
|
161
|
+
classDef systemSupport fill:#667eea,stroke:#5a67d8,stroke-width:2.5px,color:#ffffff,font-weight:600,font-size:13px
|
|
58
162
|
|
|
59
|
-
|
|
163
|
+
classDef database fill:#48bb78,stroke:#38a169,stroke-width:2.5px,color:#ffffff,font-weight:600,font-size:13px
|
|
60
164
|
|
|
61
|
-
|
|
165
|
+
classDef external fill:#718096,stroke:#4a5568,stroke-width:2.5px,color:#ffffff,font-weight:600,font-size:13px,stroke-dasharray:6 3
|
|
62
166
|
|
|
63
|
-
|
|
64
|
-
- `high` = foundation tasks that can start immediately (Wave 1)
|
|
65
|
-
- `medium` = tasks that depend on foundation work completing (Wave 2+)
|
|
66
|
-
- `low` = final integration, testing, and documentation tasks (last wave)
|
|
167
|
+
%% NODES - CLEAN ENTERPRISE HIERARCHY
|
|
67
168
|
|
|
68
|
-
|
|
169
|
+
User(("◉<br><b>User</b><br>")):::person
|
|
69
170
|
|
|
70
|
-
|
|
171
|
+
subgraph SystemBoundary["◆ Primary System Boundary"]
|
|
172
|
+
direction TB
|
|
71
173
|
|
|
72
|
-
|
|
174
|
+
LoadBalancer{{"<b>Load Balancer</b><br>NGINX<br><i>Layer 7 Proxy</i>"}}:::systemCore
|
|
73
175
|
|
|
74
|
-
|
|
176
|
+
API["<b>API Application</b><br>Go • Gin Framework<br><i>REST Endpoints</i>"]:::systemCore
|
|
75
177
|
|
|
76
|
-
|
|
178
|
+
Worker(["<b>Background Worker</b><br>Go Runtime<br><i>Async Processing</i>"]):::systemSupport
|
|
77
179
|
|
|
78
|
-
|
|
180
|
+
Cache[("◆<br><b>Cache Layer</b><br>Redis<br><i>In-Memory</i>")]:::database
|
|
79
181
|
|
|
80
|
-
|
|
182
|
+
PrimaryDB[("●<br><b>Primary Database</b><br>PostgreSQL<br><i>Persistent Storage</i>")]:::database
|
|
183
|
+
end
|
|
81
184
|
|
|
82
|
-
|
|
83
|
-
- Setup/configuration tasks (foundation layer — `high`)
|
|
84
|
-
- Model/data structure definitions (often independent — `high`)
|
|
85
|
-
- Core logic implementation (multiple modules can be parallel — `medium`)
|
|
86
|
-
- UI/presentation layer (components can be parallel — `medium`)
|
|
87
|
-
- Integration tasks (may need to wait for core — `medium` or `low`)
|
|
88
|
-
- Testing tasks (run after implementation — `low`)
|
|
89
|
-
- Documentation tasks (can run in parallel with tests — `low`)
|
|
185
|
+
ExternalAPI{{"<b>External API</b><br>Third Party<br><i>HTTP/REST</i>"}}:::external
|
|
90
186
|
|
|
91
|
-
|
|
187
|
+
%% RELATIONSHIPS - CLEAN FLOW
|
|
92
188
|
|
|
93
|
-
|
|
189
|
+
User -->|"1. HTTPS Request<br>TLS 1.3"| LoadBalancer
|
|
190
|
+
LoadBalancer -->|"2. Proxy Pass<br>Round Robin"| API
|
|
94
191
|
|
|
95
|
-
|
|
192
|
+
API <-->|"3. Cache<br>Read/Write"| Cache
|
|
193
|
+
API -->|"4. Persist Data<br>Transactional"| PrimaryDB
|
|
194
|
+
API -.->|"5. Enqueue Event<br>Async"| Worker
|
|
195
|
+
|
|
196
|
+
Worker -->|"6. Process Job<br>Execution"| PrimaryDB
|
|
197
|
+
Worker -.->|"7. HTTP Call<br>Webhooks"| ExternalAPI
|
|
198
|
+
|
|
199
|
+
%% STYLE BOUNDARY
|
|
200
|
+
style SystemBoundary fill:#ffffff,stroke:#cbd5e0,stroke-width:2px,color:#2d3748,stroke-dasharray:8 4,font-weight:600,font-size:12px
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
### 4.2 Architectural Pattern
|
|
204
|
+
|
|
205
|
+
_Instruction: Name the pattern (e.g., "Event Sourcing", "BFF - Backend for Frontend")._
|
|
206
|
+
|
|
207
|
+
- We are adopting a Publisher-Subscriber pattern where the Order Service publishes `OrderCreated` events, and the Billing Service consumes them asynchronously.
|
|
208
|
+
|
|
209
|
+
### 4.3 Key Components
|
|
210
|
+
|
|
211
|
+
| Component | Responsibility | Technology Stack | Justification |
|
|
212
|
+
| ----------------- | --------------------------- | ----------------- | -------------------------------------------- |
|
|
213
|
+
| Ingestion Service | Validates incoming webhooks | Go, Gin Framework | High concurrency performance needed. |
|
|
214
|
+
| Event Bus | Decouples services | Kafka | Durable log, replay capability. |
|
|
215
|
+
| Projections DB | Read-optimized views | MongoDB | Flexible schema for diverse receipt formats. |
|
|
216
|
+
|
|
217
|
+
## 5. Detailed Design
|
|
218
|
+
|
|
219
|
+
_Instruction: The "Meat" of the document. Sufficient detail for an engineer to start coding._
|
|
220
|
+
|
|
221
|
+
### 5.1 API Interfaces
|
|
222
|
+
|
|
223
|
+
_Instruction: Define the contract. Use OpenAPI/Swagger snippets or Protocol Buffer definitions._
|
|
224
|
+
|
|
225
|
+
**Endpoint:** `POST /api/v1/invoices`
|
|
226
|
+
|
|
227
|
+
- **Auth:** Bearer Token (Scope: `invoice:write`)
|
|
228
|
+
- **Idempotency:** Required header `X-Idempotency-Key`
|
|
229
|
+
- **Request Body:**
|
|
96
230
|
|
|
97
231
|
```json
|
|
98
|
-
{
|
|
99
|
-
"todos": [
|
|
100
|
-
{
|
|
101
|
-
"content": "[Wave 1] Define user model and authentication schema",
|
|
102
|
-
"status": "pending",
|
|
103
|
-
"priority": "high"
|
|
104
|
-
},
|
|
105
|
-
{
|
|
106
|
-
"content": "[Wave 1] Implement password hashing and validation utilities",
|
|
107
|
-
"status": "pending",
|
|
108
|
-
"priority": "high"
|
|
109
|
-
},
|
|
110
|
-
{
|
|
111
|
-
"content": "[Wave 1] Add authentication middleware for protected routes (depends on: user model)",
|
|
112
|
-
"status": "pending",
|
|
113
|
-
"priority": "high"
|
|
114
|
-
},
|
|
115
|
-
{
|
|
116
|
-
"content": "[Wave 2] Create registration endpoint with validation (depends on: user model, password utils)",
|
|
117
|
-
"status": "pending",
|
|
118
|
-
"priority": "medium"
|
|
119
|
-
},
|
|
120
|
-
{
|
|
121
|
-
"content": "[Wave 2] Create login endpoint with JWT token generation (depends on: user model, password utils)",
|
|
122
|
-
"status": "pending",
|
|
123
|
-
"priority": "medium"
|
|
124
|
-
},
|
|
125
|
-
{
|
|
126
|
-
"content": "[Wave 3] Write integration tests for auth endpoints (depends on: registration, login, middleware)",
|
|
127
|
-
"status": "pending",
|
|
128
|
-
"priority": "low"
|
|
129
|
-
}
|
|
130
|
-
]
|
|
131
|
-
}
|
|
232
|
+
{ "user_id": "uuid", "amount": 100.0, "currency": "USD" }
|
|
132
233
|
```
|
|
133
234
|
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
235
|
+
### 5.2 Data Model / Schema
|
|
236
|
+
|
|
237
|
+
_Instruction: Provide ERDs (Entity Relationship Diagrams) or JSON schemas. Discuss normalization vs. denormalization._
|
|
238
|
+
|
|
239
|
+
**Table:** `invoices` (PostgreSQL)
|
|
240
|
+
|
|
241
|
+
| Column | Type | Constraints | Description |
|
|
242
|
+
| --------- | ---- | ----------------- | --------------------- |
|
|
243
|
+
| `id` | UUID | PK | |
|
|
244
|
+
| `user_id` | UUID | FK -> Users | Partition Key |
|
|
245
|
+
| `status` | ENUM | 'PENDING', 'PAID' | Indexed for filtering |
|
|
246
|
+
|
|
247
|
+
### 5.3 Algorithms and State Management
|
|
248
|
+
|
|
249
|
+
_Instruction: Describe complex logic, state machines, or consistency models._
|
|
250
|
+
|
|
251
|
+
- **State Machine:** An invoice moves from `DRAFT` -> `LOCKED` -> `PROCESSING` -> `PAID`.
|
|
252
|
+
- **Concurrency:** We use Optimistic Locking on the `version` column to prevent double-payments.
|
|
253
|
+
|
|
254
|
+
## 6. Alternatives Considered
|
|
255
|
+
|
|
256
|
+
_Instruction: Prove you thought about trade-offs. Why is your solution better than the others?_
|
|
257
|
+
|
|
258
|
+
| Option | Pros | Cons | Reason for Rejection |
|
|
259
|
+
| -------------------------------- | ---------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------- |
|
|
260
|
+
| Option A: Synchronous HTTP Calls | Simple to implement, Easy to debug | Tight coupling, cascading failures | Latency requirements (200ms) make blocking calls risky. |
|
|
261
|
+
| Option B: RabbitMQ | Lightweight, Built-in routing | Less durable than Kafka, harder to replay | We need message replay for auditing (Compliance requirement). |
|
|
262
|
+
| Option C: Kafka (Selected) | High throughput, Replayability | Operational complexity | **Selected:** The need for auditability/replay outweighs the complexity cost. |
|
|
263
|
+
|
|
264
|
+
## 7. Cross-Cutting Concerns
|
|
265
|
+
|
|
266
|
+
### 7.1 Security and Privacy
|
|
267
|
+
|
|
268
|
+
- **Authentication:** Services authenticate via mTLS.
|
|
269
|
+
- **Authorization:** Policy enforcement point at the API Gateway (OPA - Open Policy Agent).
|
|
270
|
+
- **Data Protection:** PII (Names, Emails) is encrypted at rest using AES-256.
|
|
271
|
+
- **Threat Model:** Primary threat is compromised API Key; remediation is rapid rotation and rate limiting.
|
|
272
|
+
|
|
273
|
+
### 7.2 Observability Strategy
|
|
274
|
+
|
|
275
|
+
- **Metrics:** We will track `invoice_creation_latency` (Histogram) and `payment_failure_count` (Counter).
|
|
276
|
+
- **Tracing:** All services propagate `X-Trace-ID` headers (OpenTelemetry).
|
|
277
|
+
- **Alerting:** PagerDuty triggers if `5xx` error rate > 1% for 5 minutes.
|
|
278
|
+
|
|
279
|
+
### 7.3 Scalability and Capacity Planning
|
|
280
|
+
|
|
281
|
+
- **Traffic Estimates:** 1M transactions/day = ~12 TPS avg / 100 TPS peak.
|
|
282
|
+
- **Storage Growth:** 1KB per record \* 1M = 1GB/day.
|
|
283
|
+
- **Bottleneck:** The PostgreSQL Write node is the bottleneck. We will implement Read Replicas to offload traffic.
|
|
284
|
+
|
|
285
|
+
## 8. Migration, Rollout, and Testing
|
|
286
|
+
|
|
287
|
+
### 8.1 Deployment Strategy
|
|
288
|
+
|
|
289
|
+
- [ ] Phase 1: Deploy services in "Shadow Mode" (process traffic but do not email users).
|
|
290
|
+
- [ ] Phase 2: Enable Feature Flag `new-billing-engine` for 1% of internal users.
|
|
291
|
+
- [ ] Phase 3: Ramp to 100%.
|
|
292
|
+
|
|
293
|
+
### 8.2 Data Migration Plan
|
|
294
|
+
|
|
295
|
+
- **Backfill:** We will run a script to migrate the last 90 days of invoices from the legacy SQL server.
|
|
296
|
+
- **Verification:** A "Reconciliation Job" will run nightly to compare Legacy vs. New totals.
|
|
297
|
+
|
|
298
|
+
### 8.3 Test Plan
|
|
299
|
+
|
|
300
|
+
- **Unit Tests:**
|
|
301
|
+
- **Integration Tests:**
|
|
302
|
+
- **End-to-End Tests:**
|
|
303
|
+
|
|
304
|
+
## 9. Open Questions / Unresolved Issues
|
|
138
305
|
|
|
139
|
-
|
|
306
|
+
_Instruction: List known unknowns. These must be resolved before the doc is marked "Approved"._
|
|
140
307
|
|
|
141
|
-
-
|
|
142
|
-
-
|
|
143
|
-
- **Priority encodes execution order**: `high` = start immediately, `medium` = after high tasks, `low` = final wave
|
|
144
|
-
- **Wave labels and dependency annotations** in content are critical for the orchestrator to schedule work correctly
|
|
145
|
-
- Keep task descriptions concise but descriptive (aim for 5-10 words plus annotations)
|
|
146
|
-
- **Think in parallel**: Structure tasks to enable maximum concurrent execution by multiple sub-agents
|
|
308
|
+
- [ ] Will the Legal team approve the 3rd party library for PDF generation?
|
|
309
|
+
- [ ] Does the current VPC peering allow connection to the legacy mainframe?
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"workflow-picker-panel.d.ts","sourceRoot":"","sources":["../../../src/sdk/components/workflow-picker-panel.tsx"],"names":[],"mappings":"AAAA,sCAAsC;AACtC;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,OAAO,EAEL,KAAK,WAAW,EAIjB,MAAM,eAAe,CAAC;AAQvB,OAAO,EAAgB,KAAK,aAAa,EAAE,MAAM,qBAAqB,CAAC;AACvE,OAAO,KAAK,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5D,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AASpE,MAAM,WAAW,WAAW;IAC1B,UAAU,EAAE,MAAM,CAAC;IACnB,eAAe,EAAE,MAAM,CAAC;IACxB,iBAAiB,EAAE,MAAM,CAAC;IAC1B,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,MAAM,CAAC;IAChB,OAAO,EAAE,MAAM,CAAC;IAChB,OAAO,EAAE,MAAM,CAAC;IAChB,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,YAAY,EAAE,MAAM,CAAC;CACtB;AAED,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,aAAa,EAAE,MAAM,EAAE,OAAO,GAAG,WAAW,CAuBlF;AAeD,KAAK,MAAM,GAAG,OAAO,GAAG,QAAQ,GAAG,SAAS,CAAC;AAG7C,qEAAqE;AACrE,MAAM,WAAW,oBAAoB;IACnC,kDAAkD;IAClD,QAAQ,EAAE,oBAAoB,CAAC;IAC/B,mFAAmF;IACnF,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CAChC;AA6BD;;;;GAIG;AACH,wBAAgB,UAAU,CAAC,KAAK,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAsBvE;AAID,UAAU,SAAS;IACjB,QAAQ,EAAE,oBAAoB,CAAC;IAC/B,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,KAAK,OAAO,GACR;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,GACnC;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,KAAK,EAAE,SAAS,CAAA;CAAE,CAAC;AAExC;;;GAGG;AACH,wBAAgB,iBAAiB,CAC/B,SAAS,EAAE,oBAAoB,EAAE,GAChC,oBAAoB,EAAE,CASxB;AAED,wBAAgB,YAAY,CAC1B,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,oBAAoB,EAAE,GAChC,SAAS,EAAE,CAkCb;AAED,wBAAgB,SAAS,CAAC,OAAO,EAAE,SAAS,EAAE,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,EAAE,CAexE;AAID,wBAAgB,YAAY,CAAC,KAAK,EAAE,aAAa,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,CAIzE;
|
|
1
|
+
{"version":3,"file":"workflow-picker-panel.d.ts","sourceRoot":"","sources":["../../../src/sdk/components/workflow-picker-panel.tsx"],"names":[],"mappings":"AAAA,sCAAsC;AACtC;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,OAAO,EAEL,KAAK,WAAW,EAIjB,MAAM,eAAe,CAAC;AAQvB,OAAO,EAAgB,KAAK,aAAa,EAAE,MAAM,qBAAqB,CAAC;AACvE,OAAO,KAAK,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5D,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AASpE,MAAM,WAAW,WAAW;IAC1B,UAAU,EAAE,MAAM,CAAC;IACnB,eAAe,EAAE,MAAM,CAAC;IACxB,iBAAiB,EAAE,MAAM,CAAC;IAC1B,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,MAAM,CAAC;IAChB,OAAO,EAAE,MAAM,CAAC;IAChB,OAAO,EAAE,MAAM,CAAC;IAChB,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,YAAY,EAAE,MAAM,CAAC;CACtB;AAED,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,aAAa,EAAE,MAAM,EAAE,OAAO,GAAG,WAAW,CAuBlF;AAeD,KAAK,MAAM,GAAG,OAAO,GAAG,QAAQ,GAAG,SAAS,CAAC;AAG7C,qEAAqE;AACrE,MAAM,WAAW,oBAAoB;IACnC,kDAAkD;IAClD,QAAQ,EAAE,oBAAoB,CAAC;IAC/B,mFAAmF;IACnF,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CAChC;AA6BD;;;;GAIG;AACH,wBAAgB,UAAU,CAAC,KAAK,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAsBvE;AAID,UAAU,SAAS;IACjB,QAAQ,EAAE,oBAAoB,CAAC;IAC/B,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,KAAK,OAAO,GACR;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,GACnC;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,KAAK,EAAE,SAAS,CAAA;CAAE,CAAC;AAExC;;;GAGG;AACH,wBAAgB,iBAAiB,CAC/B,SAAS,EAAE,oBAAoB,EAAE,GAChC,oBAAoB,EAAE,CASxB;AAED,wBAAgB,YAAY,CAC1B,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,oBAAoB,EAAE,GAChC,SAAS,EAAE,CAkCb;AAED,wBAAgB,SAAS,CAAC,OAAO,EAAE,SAAS,EAAE,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,EAAE,CAexE;AAID,wBAAgB,YAAY,CAAC,KAAK,EAAE,aAAa,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,CAIzE;AAkiCD,UAAU,cAAc;IACtB,KAAK,EAAE,WAAW,CAAC;IACnB,KAAK,EAAE,SAAS,CAAC;IACjB,SAAS,EAAE,oBAAoB,EAAE,CAAC;IAClC,QAAQ,EAAE,CAAC,MAAM,EAAE,oBAAoB,KAAK,IAAI,CAAC;IACjD,QAAQ,EAAE,MAAM,IAAI,CAAC;CACtB;AAED,wBAAgB,cAAc,CAAC,EAC7B,KAAK,EACL,KAAK,EACL,SAAS,EACT,QAAQ,EACR,QAAQ,GACT,EAAE,cAAc,6BA0IhB;AAID,MAAM,WAAW,0BAA0B;IACzC,KAAK,EAAE,SAAS,CAAC;IACjB,yEAAyE;IACzE,SAAS,EAAE,oBAAoB,EAAE,CAAC;CACnC;AAED;;;;GAIG;AACH,qBAAa,mBAAmB;IAC9B,OAAO,CAAC,QAAQ,CAAc;IAC9B,OAAO,CAAC,IAAI,CAAO;IACnB,OAAO,CAAC,SAAS,CAAS;IAC1B,OAAO,CAAC,gBAAgB,CACjB;IACP,OAAO,CAAC,gBAAgB,CAAuC;IAE/D,OAAO;IAyCP;;;;OAIG;WACU,MAAM,CACjB,OAAO,EAAE,0BAA0B,GAClC,OAAO,CAAC,mBAAmB,CAAC;IAgB/B,0EAA0E;IAC1E,MAAM,CAAC,kBAAkB,CACvB,QAAQ,EAAE,WAAW,EACrB,OAAO,EAAE,0BAA0B,GAClC,mBAAmB;IAItB;;;;OAIG;IACH,gBAAgB,IAAI,OAAO,CAAC,oBAAoB,GAAG,IAAI,CAAC;IAIxD,8CAA8C;IAC9C,OAAO,IAAI,IAAI;IAef,OAAO,CAAC,YAAY;IAOpB,OAAO,CAAC,YAAY;CAMrB"}
|
|
@@ -2,10 +2,13 @@
|
|
|
2
2
|
* Workflow discovery — finds workflow definitions from disk.
|
|
3
3
|
*
|
|
4
4
|
* Workflows are discovered from:
|
|
5
|
-
* 1.
|
|
6
|
-
* 2.
|
|
5
|
+
* 1. src/sdk/workflows/builtin/<name>/<agent>/index.ts (SDK-shipped builtins)
|
|
6
|
+
* 2. .atomic/workflows/<name>/<agent>/index.ts (project-local)
|
|
7
|
+
* 3. ~/.atomic/workflows/<name>/<agent>/index.ts (global)
|
|
7
8
|
*
|
|
8
|
-
*
|
|
9
|
+
* All three sources use the same scanning function (`discoverFromBaseDir`)
|
|
10
|
+
* so registration is uniform. Builtin names are reserved — project-local
|
|
11
|
+
* and global workflows with the same name are dropped during merge.
|
|
9
12
|
*/
|
|
10
13
|
import type { AgentType, WorkflowInput } from "../types.ts";
|
|
11
14
|
export interface DiscoveredWorkflow {
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"discovery.d.ts","sourceRoot":"","sources":["../../../src/sdk/runtime/discovery.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"discovery.d.ts","sourceRoot":"","sources":["../../../src/sdk/runtime/discovery.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAMH,OAAO,KAAK,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAG5D,MAAM,WAAW,kBAAkB;IACjC,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,SAAS,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,OAAO,GAAG,QAAQ,GAAG,SAAS,CAAC;CACxC;AAUD,eAAO,MAAM,MAAM,EAAE,SAAS,EAAsC,CAAC;AAGrE;;;GAGG;AACH,eAAO,MAAM,mBAAmB,QASpB,CAAC;AAkGb;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAsB,iBAAiB,CACrC,WAAW,GAAE,MAAsB,EACnC,WAAW,CAAC,EAAE,SAAS,EACvB,OAAO,GAAE;IAAE,KAAK,CAAC,EAAE,OAAO,CAAA;CAAO,GAChC,OAAO,CAAC,kBAAkB,EAAE,CAAC,CAoD/B;AAED;;GAEG;AACH,wBAAsB,YAAY,CAChC,IAAI,EAAE,MAAM,EACZ,KAAK,EAAE,SAAS,EAChB,WAAW,GAAE,MAAsB,GAClC,OAAO,CAAC,kBAAkB,GAAG,IAAI,CAAC,CAGpC;AAED;;;;;;;;GAQG;AACH,MAAM,WAAW,oBAAqB,SAAQ,kBAAkB;IAC9D,iEAAiE;IACjE,WAAW,EAAE,MAAM,CAAC;IACpB,iFAAiF;IACjF,MAAM,EAAE,SAAS,aAAa,EAAE,CAAC;CAClC;AAED;;;;;;;;GAQG;AACH,wBAAsB,qBAAqB,CACzC,UAAU,EAAE,kBAAkB,EAAE,GAC/B,OAAO,CAAC,oBAAoB,EAAE,CAAC,CAejC"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"executor.d.ts","sourceRoot":"","sources":["../../../src/sdk/runtime/executor.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AAKH,OAAO,KAAK,EACV,kBAAkB,EAMlB,SAAS,EAET,YAAY,EAMb,MAAM,aAAa,CAAC;
|
|
1
|
+
{"version":3,"file":"executor.d.ts","sourceRoot":"","sources":["../../../src/sdk/runtime/executor.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AAKH,OAAO,KAAK,EACV,kBAAkB,EAMlB,SAAS,EAET,YAAY,EAMb,MAAM,aAAa,CAAC;AAwErB,OAAO,EAAE,YAAY,EAAE,MAAM,cAAc,CAAC;AAS5C,MAAM,WAAW,kBAAkB;IACjC,uCAAuC;IACvC,UAAU,EAAE,kBAAkB,CAAC;IAC/B,iBAAiB;IACjB,KAAK,EAAE,SAAS,CAAC;IACjB;;;;;OAKG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAChC,qEAAqE;IACrE,YAAY,EAAE,MAAM,CAAC;IACrB,qCAAqC;IACrC,WAAW,CAAC,EAAE,MAAM,CAAC;CACtB;AA0HD;;;;;;GAMG;AACH,wBAAgB,OAAO,CAAC,CAAC,EAAE,MAAM,GAAG,MAAM,CAKzC;AAED;;;;;GAKG;AACH,wBAAgB,OAAO,CAAC,CAAC,EAAE,MAAM,GAAG,MAAM,CAMzC;AAED;;;;;;GAMG;AACH,wBAAgB,cAAc,CAAC,GAAG,EAAE,MAAM,GAAG,SAAS,GAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAgB9E;AAMD;;;;;;GAMG;AACH,wBAAsB,eAAe,CACnC,OAAO,EAAE,kBAAkB,GAC1B,OAAO,CAAC,IAAI,CAAC,CAyEf;AAcD,gGAAgG;AAChG,wBAAgB,UAAU,CAAC,KAAK,EAAE,OAAO,GAAG,KAAK,IAAI;IAAE,OAAO,EAAE,MAAM,CAAA;CAAE,CAOvE;AAED,wBAAgB,oBAAoB,CAAC,QAAQ,EAAE,YAAY,EAAE,GAAG,MAAM,CAkDrE;AAykBD,wBAAsB,eAAe,IAAI,OAAO,CAAC,IAAI,CAAC,CA0JrD"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/deep-research-codebase/claude/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0DG;;AA4BH,
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/deep-research-codebase/claude/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0DG;;AA4BH,wBAyOa"}
|
|
@@ -2,23 +2,11 @@
|
|
|
2
2
|
* Determine how many parallel explorer sub-agents to spawn for the
|
|
3
3
|
* deep-research-codebase workflow, based on lines of code in the codebase.
|
|
4
4
|
*
|
|
5
|
-
*
|
|
6
|
-
*
|
|
7
|
-
*
|
|
8
|
-
*
|
|
9
|
-
*
|
|
10
|
-
* Tier choices were anchored to the rough sizes of common project shapes:
|
|
11
|
-
*
|
|
12
|
-
* < 5,000 LOC → 2 explorers scripts, single-purpose tools
|
|
13
|
-
* < 25,000 LOC → 3 explorers small libraries, CLI utilities
|
|
14
|
-
* < 100,000 LOC → 5 explorers medium applications
|
|
15
|
-
* < 500,000 LOC → 7 explorers large applications, small monorepos
|
|
16
|
-
* <2,000,000 LOC → 9 explorers large monorepos
|
|
17
|
-
* ≥2,000,000 LOC → 12 explorers massive monorepos (hard cap)
|
|
18
|
-
*
|
|
19
|
-
* The hard cap of 12 prevents runaway parallelism: each explorer is a
|
|
20
|
-
* Claude tmux pane plus an LLM session, so the cost grows linearly in
|
|
21
|
-
* tokens, processes, and walltime as well as in aggregator context.
|
|
5
|
+
* Scales linearly: one explorer per `LOC_PER_EXPLORER` (2.5K) lines of code,
|
|
6
|
+
* with a floor of 2 for tiny or empty codebases. The actual number of
|
|
7
|
+
* spawned explorers is still bounded by the number of partition units
|
|
8
|
+
* the scout finds (see `partitionUnits` in ./scout.ts), so we never get
|
|
9
|
+
* more explorers than the natural granularity of the codebase allows.
|
|
22
10
|
*/
|
|
23
11
|
export declare function calculateExplorerCount(loc: number): number;
|
|
24
12
|
/** Human-readable rationale for the heuristic decision — surfaced in logs/prompts. */
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"heuristic.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/deep-research-codebase/helpers/heuristic.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"heuristic.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/deep-research-codebase/helpers/heuristic.ts"],"names":[],"mappings":"AAGA;;;;;;;;;GASG;AACH,wBAAgB,sBAAsB,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAG1D;AAED,sFAAsF;AACtF,wBAAgB,gBAAgB,CAAC,GAAG,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,CAInE"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/ralph/claude/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;;
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/ralph/claude/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;;AAkEH,wBAiLa"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/ralph/copilot/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;;AA6DH,
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/ralph/copilot/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;;AA6DH,wBAmMa"}
|
|
@@ -87,31 +87,34 @@ export interface PlannerContext {
|
|
|
87
87
|
debuggerReport?: string;
|
|
88
88
|
}
|
|
89
89
|
/**
|
|
90
|
-
* Build the planner prompt. The first iteration
|
|
91
|
-
* subsequent iterations
|
|
90
|
+
* Build the planner prompt. The first iteration authors an RFC from the
|
|
91
|
+
* original spec; subsequent iterations revise the RFC using the debugger
|
|
92
92
|
* report from the previous loop iteration.
|
|
93
|
+
*
|
|
94
|
+
* The planner's deliverable is a filled-in Technical Design Document / RFC
|
|
95
|
+
* rendered as markdown text
|
|
96
|
+
* consumes the RFC as design context
|
|
93
97
|
*/
|
|
94
98
|
export declare function buildPlannerPrompt(spec: string, context?: PlannerContext): string;
|
|
95
99
|
export interface OrchestratorContext {
|
|
96
100
|
/**
|
|
97
|
-
*
|
|
98
|
-
*
|
|
99
|
-
*
|
|
100
|
-
*
|
|
101
|
-
* `TaskCreate
|
|
102
|
-
* sees any caveats, risks, or execution hints that didn't fit into task
|
|
103
|
-
* bodies.
|
|
101
|
+
* The planner's final assistant message. Under the RFC-based Ralph flow,
|
|
102
|
+
* this is the authoritative design input — either an absolute path to a
|
|
103
|
+
* pre-existing spec file or an inline RFC markdown document. The
|
|
104
|
+
* orchestrator decomposes it into the task list using its SDK-specific
|
|
105
|
+
* task-persistence tool (`TaskCreate` / `sql` / `todowrite`).
|
|
104
106
|
*/
|
|
105
107
|
plannerNotes?: string;
|
|
106
108
|
}
|
|
107
109
|
/**
|
|
108
|
-
* Build the orchestrator prompt. The orchestrator
|
|
109
|
-
*
|
|
110
|
+
* Build the orchestrator prompt. The orchestrator decomposes the planner's
|
|
111
|
+
* design output (a spec path or inline RFC) into a task list using its
|
|
112
|
+
* SDK-specific task-persistence tool, validates the dependency graph, and
|
|
113
|
+
* spawns parallel workers.
|
|
110
114
|
*
|
|
111
|
-
* @param spec - The original
|
|
112
|
-
*
|
|
113
|
-
*
|
|
114
|
-
* @param context - Optional planner handoff context (trailing commentary).
|
|
115
|
+
* @param spec - The user's original specification. Used as context/fallback
|
|
116
|
+
* when the planner output is missing or ambiguous.
|
|
117
|
+
* @param context - Planner handoff (the spec path or RFC markdown).
|
|
115
118
|
*/
|
|
116
119
|
export declare function buildOrchestratorPrompt(spec: string, context?: OrchestratorContext): string;
|
|
117
120
|
/** Prompts for the three parallel infrastructure-discovery sub-agents. */
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/ralph/helpers/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAMxB,8CAA8C;AAC9C,eAAO,MAAM,mBAAmB;;;;;;;;;;;;
|
|
1
|
+
{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../../../../src/sdk/workflows/builtin/ralph/helpers/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAMxB,8CAA8C;AAC9C,eAAO,MAAM,mBAAmB;;;;;;;;;;;;iBAsC9B,CAAC;AAEH,wDAAwD;AACxD,eAAO,MAAM,kBAAkB;;;;;;;;;;;;;;;;;iBAgB7B,CAAC;AAEH,kFAAkF;AAClF,eAAO,MAAM,yBAAyB;;;;;;;;;;;;;;;;;kBAAqC,CAAC;AAE5E,mEAAmE;AACnE,MAAM,WAAW,sBAAsB;IACrC,oFAAoF;IACpF,UAAU,EAAE,YAAY,GAAG,IAAI,CAAC;IAChC,8DAA8D;IAC9D,GAAG,EAAE,MAAM,CAAC;CACb;AAED;;;;;;;GAOG;AACH,wBAAgB,kBAAkB,CAChC,CAAC,EAAE,sBAAsB,EACzB,CAAC,EAAE,sBAAsB,GACxB,sBAAsB,CA4CxB;AAMD,MAAM,WAAW,cAAc;IAC7B,0EAA0E;IAC1E,SAAS,EAAE,MAAM,CAAC;IAClB,wEAAwE;IACxE,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB;AAED;;;;;;;;GAQG;AACH,wBAAgB,kBAAkB,CAChC,IAAI,EAAE,MAAM,EACZ,OAAO,GAAE,cAAiC,GACzC,MAAM,CA2GR;AAKD,MAAM,WAAW,mBAAmB;IAClC;;;;;;OAMG;IACH,YAAY,CAAC,EAAE,MAAM,CAAC;CACvB;AAED;;;;;;;;;GASG;AACH,wBAAgB,uBAAuB,CACrC,IAAI,EAAE,MAAM,EACZ,OAAO,GAAE,mBAAwB,GAChC,MAAM,CAwIR;AAMD,0EAA0E;AAC1E,MAAM,WAAW,qBAAqB;IACpC,iDAAiD;IACjD,OAAO,EAAE,MAAM,CAAC;IAChB,kDAAkD;IAClD,QAAQ,EAAE,MAAM,CAAC;IACjB,wDAAwD;IACxD,aAAa,EAAE,MAAM,CAAC;CACvB;AAED;;;;;;;;GAQG;AACH,wBAAgB,0BAA0B,IAAI,qBAAqB,CAwGlE;AAMD,oDAAoD;AACpD,MAAM,WAAW,aAAa;IAC5B,KAAK,EAAE,MAAM,CAAC;IACd,IAAI,EAAE,MAAM,CAAC;IACb,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,aAAa,CAAC,EAAE;QACd,kBAAkB,EAAE,MAAM,CAAC;QAC3B,UAAU,EAAE;YAAE,KAAK,EAAE,MAAM,CAAC;YAAC,GAAG,EAAE,MAAM,CAAA;SAAE,CAAC;KAC5C,CAAC;CACH;AAED,mCAAmC;AACnC,MAAM,WAAW,YAAY;IAC3B,QAAQ,EAAE,aAAa,EAAE,CAAC;IAC1B,mBAAmB,EAAE,MAAM,CAAC;IAC5B,mBAAmB,EAAE,MAAM,CAAC;IAC5B,wBAAwB,CAAC,EAAE,MAAM,CAAC;CACnC;AAED,MAAM,WAAW,aAAa;IAC5B;;;;;OAKG;IACH,SAAS,EAAE;QACT,UAAU,EAAE,MAAM,CAAC;QACnB,QAAQ,EAAE,MAAM,CAAC;QACjB,WAAW,EAAE,MAAM,CAAC;QACpB,UAAU,EAAE,MAAM,CAAC;QACnB,MAAM,EAAE,MAAM,EAAE,CAAC;KAClB,CAAC;IACF,2DAA2D;IAC3D,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB;;;;OAIG;IACH,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB;;;;;OAKG;IACH,gBAAgB,CAAC,EAAE,MAAM,CAAC;CAC3B;AAED;;;;GAIG;AACH,wBAAgB,iBAAiB,CAC/B,IAAI,EAAE,MAAM,EACZ,OAAO,EAAE,aAAa,GACrB,MAAM,CAgMR;AAMD,MAAM,WAAW,eAAe;IAC9B,8DAA8D;IAC9D,SAAS,EAAE,MAAM,CAAC;IAClB;;;OAGG;IACH,SAAS,EAAE;QACT,UAAU,EAAE,MAAM,CAAC;QACnB,QAAQ,EAAE,MAAM,CAAC;QACjB,WAAW,EAAE,MAAM,CAAC;QACpB,UAAU,EAAE,MAAM,CAAC;QACnB,MAAM,EAAE,MAAM,EAAE,CAAC;KAClB,CAAC;CACH;AAED;;;;;GAKG;AACH,wBAAgB,yBAAyB,CACvC,MAAM,EAAE,YAAY,GAAG,IAAI,EAC3B,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,eAAe,GACvB,MAAM,CAoHR;AAMD;;;;;;;;GAQG;AACH,wBAAgB,iBAAiB,CAAC,OAAO,EAAE,MAAM,GAAG,YAAY,GAAG,IAAI,CAgDtE;AAED,wBAAgB,gBAAgB,CAAC,MAAM,EAAE;IACvC,QAAQ,EAAE,aAAa,EAAE,CAAC;IAC1B,mBAAmB,EAAE,MAAM,CAAC;IAC5B,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,wBAAwB,CAAC,EAAE,MAAM,CAAC;CACnC,GAAG,YAAY,CAUf;AAED;;;;;;;GAOG;AACH,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,MAAM,GAAG,MAAM,CAS5D"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"definitions.d.ts","sourceRoot":"","sources":["../../../src/services/config/definitions.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,MAAM,WAAW,WAAW;IAC1B,iCAAiC;IACjC,IAAI,EAAE,MAAM,CAAC;IACb,mCAAmC;IACnC,GAAG,EAAE,MAAM,CAAC;IACZ,kEAAkE;IAClE,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,qFAAqF;IACrF,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACjC,0CAA0C;IAC1C,MAAM,EAAE,MAAM,CAAC;IACf,wCAAwC;IACxC,WAAW,EAAE,MAAM,CAAC;IACpB,yDAAyD;IACzD,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,qEAAqE;IACrE,gBAAgB,EAAE,KAAK,CAAC;QACtB,MAAM,EAAE,MAAM,CAAC;QACf,WAAW,EAAE,MAAM,CAAC;QACpB,KAAK,EAAE,OAAO,CAAC;KAChB,CAAC,CAAC;CACJ;AAED,QAAA,MAAM,UAAU,4CAA6C,CAAC;AAC9D,MAAM,MAAM,QAAQ,GAAG,CAAC,OAAO,UAAU,CAAC,CAAC,MAAM,CAAC,CAAC;AAEnD,eAAO,MAAM,YAAY,EAAE,MAAM,CAAC,QAAQ,EAAE,WAAW,
|
|
1
|
+
{"version":3,"file":"definitions.d.ts","sourceRoot":"","sources":["../../../src/services/config/definitions.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,MAAM,WAAW,WAAW;IAC1B,iCAAiC;IACjC,IAAI,EAAE,MAAM,CAAC;IACb,mCAAmC;IACnC,GAAG,EAAE,MAAM,CAAC;IACZ,kEAAkE;IAClE,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,qFAAqF;IACrF,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACjC,0CAA0C;IAC1C,MAAM,EAAE,MAAM,CAAC;IACf,wCAAwC;IACxC,WAAW,EAAE,MAAM,CAAC;IACpB,yDAAyD;IACzD,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,qEAAqE;IACrE,gBAAgB,EAAE,KAAK,CAAC;QACtB,MAAM,EAAE,MAAM,CAAC;QACf,WAAW,EAAE,MAAM,CAAC;QACpB,KAAK,EAAE,OAAO,CAAC;KAChB,CAAC,CAAC;CACJ;AAED,QAAA,MAAM,UAAU,4CAA6C,CAAC;AAC9D,MAAM,MAAM,QAAQ,GAAG,CAAC,OAAO,UAAU,CAAC,CAAC,MAAM,CAAC,CAAC;AAEnD,eAAO,MAAM,YAAY,EAAE,MAAM,CAAC,QAAQ,EAAE,WAAW,CA2EtD,CAAC;AAEF,wBAAgB,YAAY,CAAC,GAAG,EAAE,MAAM,GAAG,GAAG,IAAI,QAAQ,CAEzD;AAED,wBAAgB,cAAc,CAAC,GAAG,EAAE,QAAQ,GAAG,WAAW,CAEzD;AAED,wBAAgB,YAAY,IAAI,QAAQ,EAAE,CAEzC;AAED;;GAEG;AAEH,6BAA6B;AAC7B,QAAA,MAAM,QAAQ,gCAAiC,CAAC;AAEhD,oEAAoE;AACpE,MAAM,MAAM,iBAAiB,GAAG,CAAC,OAAO,QAAQ,CAAC,CAAC,MAAM,CAAC,CAAC;AAE1D,MAAM,WAAW,SAAS;IACxB,0BAA0B;IAC1B,IAAI,EAAE,MAAM,CAAC;IACb,+BAA+B;IAC/B,WAAW,EAAE,MAAM,CAAC;IACpB,mCAAmC;IACnC,OAAO,EAAE,MAAM,CAAC;IAChB,uDAAuD;IACvD,UAAU,EAAE,MAAM,CAAC;IACnB,+CAA+C;IAC/C,YAAY,EAAE,MAAM,CAAC;IACrB,2DAA2D;IAC3D,SAAS,EAAE,MAAM,CAAC;IAClB,oCAAoC;IACpC,iBAAiB,EAAE,MAAM,CAAC;IAC1B,mCAAmC;IACnC,mBAAmB,CAAC,EAAE,MAAM,EAAE,CAAC;CAChC;AAED,eAAO,MAAM,UAAU,EAAE,MAAM,CAAC,iBAAiB,EAAE,SAAS,CAoB3D,CAAC;AAEF,+CAA+C;AAC/C,eAAO,MAAM,qBAAqB,UAAa,CAAC;AAEhD;;;;;;;;GAQG;AACH,eAAO,MAAM,kBAAkB,EAAE,MAAM,CAAC,iBAAiB,EAAE,SAAS,MAAM,EAAE,CAIzE,CAAC;AAEJ,4EAA4E;AAC5E,eAAO,MAAM,cAAc,EAAE,SAAS,MAAM,EAG3C,CAAC;AAEF;;GAEG;AACH,wBAAgB,UAAU,IAAI,iBAAiB,EAAE,CAEhD;AAED;;GAEG;AACH,wBAAgB,UAAU,CAAC,GAAG,EAAE,MAAM,GAAG,GAAG,IAAI,iBAAiB,CAEhE;AAED;;GAEG;AACH,wBAAgB,YAAY,CAAC,GAAG,EAAE,iBAAiB,GAAG,SAAS,CAE9D"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@bastani/atomic",
|
|
3
|
-
"version": "0.5.
|
|
3
|
+
"version": "0.5.14",
|
|
4
4
|
"description": "Configuration management CLI and SDK for coding agents",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"license": "MIT",
|
|
@@ -81,8 +81,10 @@
|
|
|
81
81
|
"@opentui/react": "^0.1.99",
|
|
82
82
|
"commander": "^14.0.3",
|
|
83
83
|
"ignore": "^7.0.5",
|
|
84
|
-
"react": "^19.2.5",
|
|
85
84
|
"yaml": "^2.8.3",
|
|
86
85
|
"zod": "^4.3.6"
|
|
86
|
+
},
|
|
87
|
+
"peerDependencies": {
|
|
88
|
+
"react": ">=19.0.0"
|
|
87
89
|
}
|
|
88
90
|
}
|