@compass-labs/api-sdk 2.2.16 → 2.2.17
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.md +182 -0
- package/dist/commonjs/lib/config.d.ts +2 -2
- package/dist/commonjs/lib/config.js +2 -2
- package/dist/esm/lib/config.d.ts +2 -2
- package/dist/esm/lib/config.js +2 -2
- package/package.json +1 -1
- package/src/lib/config.ts +2 -2
package/CLAUDE.md
CHANGED
|
@@ -36,6 +36,188 @@ SDK generation is handled by:
|
|
|
36
36
|
2. Regenerate `openapi.json` via `make update_openapi_json`
|
|
37
37
|
3. CI will regenerate and publish the SDK
|
|
38
38
|
|
|
39
|
+
## Claude Documentation Convention (MANDATORY)
|
|
40
|
+
|
|
41
|
+
**This convention is COMPULSORY. You MUST follow it for every plan, feature, or system you document. No exceptions.**
|
|
42
|
+
|
|
43
|
+
All documentation lives in `docs/` and follows a structured planning workflow with Linear ticket integration.
|
|
44
|
+
|
|
45
|
+
### Directory Structure
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
docs/
|
|
49
|
+
├── systems/ # Living docs for shipped systems
|
|
50
|
+
│ ├── <system-name>/
|
|
51
|
+
│ │ ├── README.md # Compiled from plan.md + all task files
|
|
52
|
+
│ │ └── diagram.excalidraw # Architecture / data flow diagram
|
|
53
|
+
│ └── ...
|
|
54
|
+
├── plans/ # Upcoming features and designs
|
|
55
|
+
│ ├── YYYY-MM-DD-<feature-name>/
|
|
56
|
+
│ │ ├── plan.md # Overall plan: overview, goals, architecture, scope
|
|
57
|
+
│ │ ├── diagram.excalidraw # Architecture diagram for the feature
|
|
58
|
+
│ │ ├── blockers.excalidraw # Dependency/blocker diagram between tasks
|
|
59
|
+
│ │ ├── 01-<task-name>.md # Task 1: detailed implementation spec
|
|
60
|
+
│ │ ├── 02-<task-name>.md # Task 2: detailed implementation spec
|
|
61
|
+
│ │ ├── 03-<task-name>.md # Task 3: detailed implementation spec
|
|
62
|
+
│ │ └── ... # As many tasks as needed
|
|
63
|
+
│ └── ...
|
|
64
|
+
├── TRACKER.yaml # Tracks plans AND individual tasks
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
### Planning Workflow (MANDATORY — follow every step)
|
|
68
|
+
|
|
69
|
+
#### Step 1: Create the Plan Folder
|
|
70
|
+
|
|
71
|
+
Create `docs/plans/YYYY-MM-DD-<feature-name>/` with:
|
|
72
|
+
|
|
73
|
+
1. **`plan.md`** — The overall plan document containing:
|
|
74
|
+
- Feature overview and goals
|
|
75
|
+
- Architecture decisions and rationale
|
|
76
|
+
- Scope and constraints
|
|
77
|
+
- List of tasks with brief descriptions
|
|
78
|
+
|
|
79
|
+
2. **`diagram.excalidraw`** — Architecture diagram showing how the feature works:
|
|
80
|
+
- System components involved
|
|
81
|
+
- Data flows
|
|
82
|
+
- External dependencies
|
|
83
|
+
- Create via Excalidraw MCP tools, then write the `.excalidraw` JSON file
|
|
84
|
+
|
|
85
|
+
3. **Individual task files** (`01-<task-name>.md`, `02-<task-name>.md`, etc.):
|
|
86
|
+
- Each file is a self-contained implementation spec for one step
|
|
87
|
+
- Numbered to indicate execution order
|
|
88
|
+
- Contains: what to build, acceptance criteria, files to modify, dependencies
|
|
89
|
+
- These are followed step-by-step during implementation
|
|
90
|
+
|
|
91
|
+
4. **`blockers.excalidraw`** — Blocker/dependency diagram showing:
|
|
92
|
+
- Which tasks block which other tasks
|
|
93
|
+
- The execution order and parallelization opportunities
|
|
94
|
+
- Critical path through the plan
|
|
95
|
+
- Create via Excalidraw MCP tools
|
|
96
|
+
|
|
97
|
+
#### Step 2: Create Linear Tickets
|
|
98
|
+
|
|
99
|
+
**You MUST create Linear tickets for every plan. This is not optional.**
|
|
100
|
+
|
|
101
|
+
**Before creating tickets, ASK the user for:**
|
|
102
|
+
- **Team**: Which Linear team should own these tickets?
|
|
103
|
+
- **Project**: Which Linear project should these tickets belong to?
|
|
104
|
+
- **Initiative**: Which Linear initiative (if any) should the project be linked to?
|
|
105
|
+
- **Priority**: What priority level? (1=Urgent, 2=High, 3=Normal, 4=Low)
|
|
106
|
+
- **Status**: What initial status should the parent ticket have? (e.g., Backlog, Todo, In Progress)
|
|
107
|
+
- **Assignee**: Who should be assigned? (or "me" for the current user)
|
|
108
|
+
|
|
109
|
+
**Do NOT guess these values. Always ask the user explicitly.**
|
|
110
|
+
|
|
111
|
+
1. **Parent ticket** — Create a Linear issue for the overall plan:
|
|
112
|
+
- Title: the feature name
|
|
113
|
+
- Description: contents of `plan.md` + the blockers diagram explanation
|
|
114
|
+
- Attach or reference the `blockers.excalidraw` diagram
|
|
115
|
+
- Link to the plan folder in the repo
|
|
116
|
+
- Set the team, project, initiative, priority, status, and assignee as specified by the user
|
|
117
|
+
|
|
118
|
+
2. **Sub-tickets** — Create a Linear sub-issue for EACH individual task file:
|
|
119
|
+
- Title: matches the task file name (e.g., "01 - Set up database schema")
|
|
120
|
+
- Description: full contents of the corresponding task `.md` file
|
|
121
|
+
- Set as child of the parent ticket
|
|
122
|
+
- Set blocker relationships matching `blockers.excalidraw`
|
|
123
|
+
- Link to the specific task file in the repo
|
|
124
|
+
- Inherit team, project, and priority from the parent ticket
|
|
125
|
+
- Set status to the team's initial/backlog status (first tasks may be set to "Todo" if unblocked)
|
|
126
|
+
|
|
127
|
+
#### Step 3: Update TRACKER.yaml
|
|
128
|
+
|
|
129
|
+
Add the plan AND all individual tasks to `docs/TRACKER.yaml`:
|
|
130
|
+
|
|
131
|
+
```yaml
|
|
132
|
+
plans:
|
|
133
|
+
- name: feature-name
|
|
134
|
+
path: plans/YYYY-MM-DD-feature-name/
|
|
135
|
+
status: planned # planned → in-progress → shipped
|
|
136
|
+
created: YYYY-MM-DD
|
|
137
|
+
started:
|
|
138
|
+
shipped:
|
|
139
|
+
linear_ticket: COM-XXX # Parent Linear ticket ID
|
|
140
|
+
tasks:
|
|
141
|
+
- name: task-1-name
|
|
142
|
+
file: 01-task-name.md
|
|
143
|
+
status: pending # pending → in-progress → done
|
|
144
|
+
linear_ticket: COM-XXX # Sub-ticket Linear ID
|
|
145
|
+
- name: task-2-name
|
|
146
|
+
file: 02-task-name.md
|
|
147
|
+
status: pending
|
|
148
|
+
linear_ticket: COM-XXX
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
#### Step 4: Implementation (follow tasks in order, keep everything in sync)
|
|
152
|
+
|
|
153
|
+
Work through task files in numbered order (unless blockers allow parallelization). **You MUST keep Linear ticket statuses and TRACKER.yaml in sync at every state change.** This is not just about creating tickets — you must actively maintain them throughout the plan lifecycle.
|
|
154
|
+
|
|
155
|
+
**When starting a task:**
|
|
156
|
+
- Update the sub-ticket status on Linear to the team's "In Progress" state
|
|
157
|
+
- Update `docs/TRACKER.yaml` task status to `in-progress`
|
|
158
|
+
- If this is the first task being started, also update the parent ticket and plan status to `in-progress`
|
|
159
|
+
|
|
160
|
+
**When completing a task:**
|
|
161
|
+
- Update the sub-ticket status on Linear to "Done" (or the team's completed state)
|
|
162
|
+
- Update `docs/TRACKER.yaml` task status to `done`
|
|
163
|
+
- Check if any previously blocked tasks are now unblocked and mention this
|
|
164
|
+
|
|
165
|
+
**When a task is blocked or has issues:**
|
|
166
|
+
- Add a comment on the Linear sub-ticket explaining the blocker
|
|
167
|
+
- Do NOT silently skip — communicate the issue
|
|
168
|
+
|
|
169
|
+
**At the start of every implementation session:**
|
|
170
|
+
- Check `docs/TRACKER.yaml` and the Linear board to understand current progress
|
|
171
|
+
- Resume from where the last session left off
|
|
172
|
+
|
|
173
|
+
#### Step 5: Shipping (move to systems)
|
|
174
|
+
|
|
175
|
+
When ALL tasks are complete:
|
|
176
|
+
|
|
177
|
+
1. **Compile README.md** — Create `docs/systems/<system-name>/README.md` by combining:
|
|
178
|
+
- The overview and architecture from `plan.md`
|
|
179
|
+
- Key details from each individual task file
|
|
180
|
+
- Final architecture decisions and operational notes
|
|
181
|
+
|
|
182
|
+
2. **Copy the architecture diagram** — Move `diagram.excalidraw` to `docs/systems/<system-name>/`
|
|
183
|
+
|
|
184
|
+
3. **Move the folder** — Move from `plans/` to `systems/`
|
|
185
|
+
|
|
186
|
+
4. **Update TRACKER.yaml** — Set plan status to `shipped` with `shipped:` date
|
|
187
|
+
|
|
188
|
+
5. **Update Linear** — Close the parent ticket and all sub-tickets
|
|
189
|
+
|
|
190
|
+
### Rules (ALL mandatory — do not skip any)
|
|
191
|
+
|
|
192
|
+
- Every plan folder MUST have: `plan.md`, `diagram.excalidraw`, `blockers.excalidraw`, and at least one task file
|
|
193
|
+
- Every plan MUST have a parent Linear ticket with sub-tickets for each task
|
|
194
|
+
- Diagrams use Excalidraw — create via the Excalidraw MCP tool, then write the `.excalidraw` JSON file
|
|
195
|
+
- When creating diagrams: use `create_element` for rectangles, text, arrows etc., then `query_elements` to get all elements, then write to `.excalidraw` file format
|
|
196
|
+
- The `.excalidraw` file is viewable in VS Code with the Excalidraw extension, or at excalidraw.com
|
|
197
|
+
- **NEVER create a plan without an architecture diagram AND a blockers diagram**
|
|
198
|
+
- **NEVER create a plan without corresponding Linear tickets**
|
|
199
|
+
- **ALWAYS update `docs/TRACKER.yaml` when creating, starting, completing tasks, or shipping a plan**
|
|
200
|
+
- **ALWAYS keep Linear ticket statuses in sync with TRACKER.yaml — every state change must be reflected in BOTH places**
|
|
201
|
+
- **NEVER change a task's status in TRACKER.yaml without also updating the corresponding Linear ticket (and vice versa)**
|
|
202
|
+
- **At the start of each session, check TRACKER.yaml and Linear to understand current plan progress before doing work**
|
|
203
|
+
|
|
204
|
+
### Plan Tracker (MANDATORY)
|
|
205
|
+
|
|
206
|
+
`docs/TRACKER.yaml` and Linear are the **dual source of truth** for plan progress. They MUST always agree. **You MUST update BOTH whenever you:**
|
|
207
|
+
|
|
208
|
+
| Event | TRACKER.yaml | Linear |
|
|
209
|
+
|-------|-------------|--------|
|
|
210
|
+
| Create plan | Add entry, `status: planned`, all tasks `pending` | Create parent + sub-tickets in Backlog |
|
|
211
|
+
| Start a task | Task `status: in-progress`, plan `status: in-progress` | Move sub-ticket to In Progress, parent to In Progress |
|
|
212
|
+
| Complete a task | Task `status: done` | Move sub-ticket to Done |
|
|
213
|
+
| Block on a task | No change (stays `in-progress`) | Add comment explaining blocker |
|
|
214
|
+
| Ship the plan | Plan `status: shipped`, `shipped:` date | Close parent + all sub-tickets |
|
|
215
|
+
|
|
216
|
+
Plan statuses: `planned` → `in-progress` → `shipped`
|
|
217
|
+
Task statuses: `pending` → `in-progress` → `done`
|
|
218
|
+
|
|
219
|
+
**Failure to keep TRACKER.yaml and Linear in sync is a violation of this convention.**
|
|
220
|
+
|
|
39
221
|
## Diagram Maintenance
|
|
40
222
|
|
|
41
223
|
When changing SDK generation configuration, update `widgets-sdk/diagram.excalidraw` and `docs/systems/widgets-sdk/diagram.excalidraw` if the changes affect how the TypeScript SDK is consumed by the widgets-sdk.
|
|
@@ -32,7 +32,7 @@ export declare const SDK_METADATA: {
|
|
|
32
32
|
readonly language: "typescript";
|
|
33
33
|
readonly openapiDocVersion: "0.0.1";
|
|
34
34
|
readonly sdkVersion: "2.0.0";
|
|
35
|
-
readonly genVersion: "2.
|
|
36
|
-
readonly userAgent: "speakeasy-sdk/typescript 2.0.0 2.
|
|
35
|
+
readonly genVersion: "2.832.2";
|
|
36
|
+
readonly userAgent: "speakeasy-sdk/typescript 2.0.0 2.832.2 0.0.1 @compass-labs/api-sdk";
|
|
37
37
|
};
|
|
38
38
|
//# sourceMappingURL=config.d.ts.map
|
|
@@ -32,7 +32,7 @@ exports.SDK_METADATA = {
|
|
|
32
32
|
language: "typescript",
|
|
33
33
|
openapiDocVersion: "0.0.1",
|
|
34
34
|
sdkVersion: "2.0.0",
|
|
35
|
-
genVersion: "2.
|
|
36
|
-
userAgent: "speakeasy-sdk/typescript 2.0.0 2.
|
|
35
|
+
genVersion: "2.832.2",
|
|
36
|
+
userAgent: "speakeasy-sdk/typescript 2.0.0 2.832.2 0.0.1 @compass-labs/api-sdk",
|
|
37
37
|
};
|
|
38
38
|
//# sourceMappingURL=config.js.map
|
package/dist/esm/lib/config.d.ts
CHANGED
|
@@ -32,7 +32,7 @@ export declare const SDK_METADATA: {
|
|
|
32
32
|
readonly language: "typescript";
|
|
33
33
|
readonly openapiDocVersion: "0.0.1";
|
|
34
34
|
readonly sdkVersion: "2.0.0";
|
|
35
|
-
readonly genVersion: "2.
|
|
36
|
-
readonly userAgent: "speakeasy-sdk/typescript 2.0.0 2.
|
|
35
|
+
readonly genVersion: "2.832.2";
|
|
36
|
+
readonly userAgent: "speakeasy-sdk/typescript 2.0.0 2.832.2 0.0.1 @compass-labs/api-sdk";
|
|
37
37
|
};
|
|
38
38
|
//# sourceMappingURL=config.d.ts.map
|
package/dist/esm/lib/config.js
CHANGED
|
@@ -28,7 +28,7 @@ export const SDK_METADATA = {
|
|
|
28
28
|
language: "typescript",
|
|
29
29
|
openapiDocVersion: "0.0.1",
|
|
30
30
|
sdkVersion: "2.0.0",
|
|
31
|
-
genVersion: "2.
|
|
32
|
-
userAgent: "speakeasy-sdk/typescript 2.0.0 2.
|
|
31
|
+
genVersion: "2.832.2",
|
|
32
|
+
userAgent: "speakeasy-sdk/typescript 2.0.0 2.832.2 0.0.1 @compass-labs/api-sdk",
|
|
33
33
|
};
|
|
34
34
|
//# sourceMappingURL=config.js.map
|
package/package.json
CHANGED
package/src/lib/config.ts
CHANGED
|
@@ -62,7 +62,7 @@ export const SDK_METADATA = {
|
|
|
62
62
|
language: "typescript",
|
|
63
63
|
openapiDocVersion: "0.0.1",
|
|
64
64
|
sdkVersion: "2.0.0",
|
|
65
|
-
genVersion: "2.
|
|
65
|
+
genVersion: "2.832.2",
|
|
66
66
|
userAgent:
|
|
67
|
-
"speakeasy-sdk/typescript 2.0.0 2.
|
|
67
|
+
"speakeasy-sdk/typescript 2.0.0 2.832.2 0.0.1 @compass-labs/api-sdk",
|
|
68
68
|
} as const;
|