You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`pkg/transport` (client abstraction and HTTP orchestration)
195
+
-`pkg/model` (model runtime type, depends on protocol)
196
+
-`pkg/request` (request interface and types, depends on model, protocol, providers)
197
+
-`pkg/client` (client abstraction and HTTP orchestration)
197
198
-`pkg/agent` (high-level agent functionality)
199
+
-`pkg/mock` (mock implementations for testing)
198
200
- Lower layers must not import higher layers
199
201
- Shared types should be defined in the lowest layer that needs them
200
202
- Use interfaces to invert dependencies when needed
201
203
202
-
**Example**: `pkg/providers` can import from `pkg/models`, `pkg/capabilities`, and `pkg/config`, but not from `pkg/transport` or `pkg/agent`. The `pkg/transport` layer orchestrates providers through interfaces.
204
+
**Example**: `pkg/request` can import from `pkg/model`, `pkg/protocol`, `pkg/providers`, and `pkg/config`, but not from `pkg/client` or `pkg/agent`. The `pkg/client` layer executes requests through the `request.Request` interface.
203
205
204
206
### Implementation Guide Refactoring Order
205
207
**Principle**: When creating implementation guides for refactoring, always structure changes to proceed from lowest-level packages to highest-level packages following the dependency hierarchy.
@@ -212,14 +214,16 @@ All documentation should be written in a clear, objective, and factual manner wi
212
214
- Each step should result in a compilable state
213
215
- Higher-level packages should only be refactored after all their dependencies are complete
214
216
215
-
**Example**: When refactoring to a protocol-based architecture, update in this order:
217
+
**Example**: When refactoring architecture, update in this order:
216
218
1.`pkg/config` (configuration structures if needed)
217
-
2.`pkg/protocols` (foundational protocol types)
218
-
3.`pkg/capabilities` (capability system updates)
219
-
4.`pkg/models` (model and format handling)
220
-
5.`pkg/providers` (provider implementations)
221
-
6.`pkg/transport` (client orchestration)
222
-
7.`pkg/agent` (high-level interface)
219
+
2.`pkg/protocol` (foundational protocol types)
220
+
3.`pkg/response` (response parsing types)
221
+
4.`pkg/providers` (provider implementations)
222
+
5.`pkg/model` (model runtime type)
223
+
6.`pkg/request` (request interface and types)
224
+
7.`pkg/client` (client orchestration)
225
+
8.`pkg/agent` (high-level interface)
226
+
9.`pkg/mock` (mock implementations)
223
227
224
228
### Parameter Encapsulation
225
229
**Principle**: If more than two parameters are needed for a function or method, encapsulate the parameters into a structure.
@@ -370,10 +374,10 @@ tests/
370
374
│ ├── duration_test.go # Tests for pkg/config/duration.go
371
375
│ ├── options_test.go # Tests for pkg/config/options.go
372
376
│ └── agent_test.go # Tests for pkg/config/agent.go
0 commit comments