Stack Architecture Design
Design transport-agnostic handler systems with proper Result types and error taxonomy.
Process
Step 1: Understand Requirements
Gather information about:
- Transport surfaces — CLI, MCP, HTTP, or all?
- Domain operations — What actions does the system perform?
- Failure modes — What can go wrong? (maps to error taxonomy)
- External dependencies — APIs, databases, file system?
Step 2: Design Handler Layer
For each domain operation:
- Define input type (Zod schema)
- Define output type
- Identify possible error types (from taxonomy)
- Write handler signature:
Handler<Input, Output, Error1 | Error2>
Example:
// Input schema
const CreateUserInputSchema = z.object({
email: z.string().email(),
name: z.string().min(1),
});
// Output type
interface User {
id: string;
email: string;
name: string;
}
// Handler signature
const createUser: Handler<unknown, User, ValidationError | ConflictError>;
Step 3: Map Errors to Taxonomy
Map domain errors to the 10 categories:
| Domain Error |
Stack Category |
Error Class |
| Not found |
not_found |
NotFoundError |
| Invalid input |
validation |
ValidationError |
| Already exists |
conflict |
ConflictError |
| No permission |
permission |
PermissionError |
| Auth required |
auth |
AuthError |
| Timed out |
timeout |
TimeoutError |
| Connection failed |
network |
NetworkError |
| Limit exceeded |
rate_limit |
RateLimitError |
| Bug/unexpected |
internal |
InternalError |
| User cancelled |
cancelled |
CancelledError |
Step 4: Choose Packages
Packages are organized into three tiers:
Package Tiers
┌─────────────────────────────────────────────────────────────────┐
│ TOOLING TIER │
│ Build-time, dev-time, test-time packages │
│ @outfitter/testing │
└─────────────────────────────────────────────────────────────────┘
▲
│ depends on
┌─────────────────────────────────────────────────────────────────┐
│ RUNTIME TIER │
│ Application-specific packages for different deployment targets │
│ @outfitter/cli @outfitter/mcp @outfitter/daemon │
│ @outfitter/config @outfitter/logging @outfitter/file-ops │
│ @outfitter/state │
└─────────────────────────────────────────────────────────────────┘
▲
│ depends on
┌─────────────────────────────────────────────────────────────────┐
│ FOUNDATION TIER │
│ Zero-runtime-dependency core packages │
│ @outfitter/contracts @outfitter/types │
└─────────────────────────────────────────────────────────────────┘
| Tier |
Packages |
Dependency Rule |
| Foundation |
contracts, types |
No @outfitter/* deps |
| Runtime |
cli, mcp, daemon, config, logging, file-ops, state |
May depend on Foundation |
| Tooling |
testing |
May depend on Foundation + Runtime |
Package Selection
| Package |
Purpose |
When to Use |
@outfitter/contracts |
Result types, errors, Handler contract |
Always (foundation) |
@outfitter/types |
Type utilities, collection helpers |
Type manipulation |
@outfitter/cli |
CLI commands, output modes, formatting |
CLI applications |
@outfitter/mcp |
MCP server, tool registration |
AI agent tools |
@outfitter/config |
XDG paths, config loading |
Configuration needed |
@outfitter/logging |
Structured logging, redaction |
Logging needed |
@outfitter/daemon |
Background services, IPC |
Long-running services |
@outfitter/file-ops |
Secure paths, atomic writes, locking |
File operations |
@outfitter/state |
Pagination, cursor state |
Paginated data |
@outfitter/testing |
Test harnesses, fixtures |
Testing |
Selection criteria:
- All projects need
@outfitter/contracts (foundation)
- CLI applications add
@outfitter/cli (includes UI components)
- MCP servers add
@outfitter/mcp
- File operations need both
@outfitter/config (paths) and @outfitter/file-ops (safety)
Step 5: Design Context Flow
Determine:
- Entry points — Where is context created? (CLI main, MCP server, HTTP handler)
- Context contents — Logger, config, signal, workspaceRoot
- Tracing — How requestId flows through operations
Output Templates
Architecture Overview
Project: {PROJECT_NAME}
Transport Surfaces: {CLI | MCP | HTTP | ...}
Directory Structure:
├── src/
│ ├── handlers/ # Transport-agnostic business logic
│ │ ├── {handler-1}.ts
│ │ └── {handler-2}.ts
│ ├── commands/ # CLI adapter (if CLI)
│ ├── tools/ # MCP adapter (if MCP)
│ └── index.ts # Entry point
└── tests/
└── handlers/ # Handler tests
Dependencies:
├── @outfitter/contracts # Foundation (always)
├── @outfitter/{package-2} # {reason}
└── @outfitter/{package-3} # {reason}
Handler Inventory
| Handler |
Input |
Output |
Errors |
Description |
getUser |
GetUserInput |
User |
NotFoundError |
Fetch user by ID |
createUser |
CreateUserInput |
User |
ValidationError, ConflictError |
Create new user |
deleteUser |
DeleteUserInput |
void |
NotFoundError, PermissionError |
Remove user |
Error Strategy
Domain Errors → Stack Taxonomy:
{domain-error-1} → {stack-category} ({ErrorClass})
- When: {condition}
- Exit code: {code}
{domain-error-2} → {stack-category} ({ErrorClass})
- When: {condition}
- Exit code: {code}
Implementation Order
- Foundation — Install packages, create types
- Core handlers — Implement business logic with tests
- Transport adapters — Wire up CLI/MCP/HTTP
- Testing — Integration tests across transports
Constraints
Always:
- Recommend Result types over exceptions
- Map domain errors to taxonomy categories
- Design handlers as pure functions (input, context) → Result
- Consider all transport surfaces upfront
- Include error types in handler signatures
Never:
- Suggest throwing exceptions
- Design transport-specific logic in handlers
- Recommend hardcoded paths
- Skip error type planning
- Couple handlers to specific transports
Related Skills
outfitter-stack:stack-patterns — Reference for all patterns
outfitter:tdd — TDD implementation methodology
outfitter-stack:stack-templates — Templates for components
1---2name: stack-architecture3version: 0.1.04description: Design stack-based systems using @outfitter/* packages. Use when planning new projects, choosing packages, designing handler architecture, or when "architecture", "design", "structure", "plan handlers", or "error taxonomy" are mentioned.5context: fork6agent: stacker7allowed-tools: Read Grep Glob8---910# Stack Architecture Design1112Design transport-agnostic handler systems with proper Result types and error taxonomy.1314## Process1516### Step 1: Understand Requirements1718Gather information about:1920- **Transport surfaces** — CLI, MCP, HTTP, or all?21- **Domain operations** — What actions does the system perform?22- **Failure modes** — What can go wrong? (maps to error taxonomy)23- **External dependencies** — APIs, databases, file system?2425### Step 2: Design Handler Layer2627For each domain operation:28291. Define input type (Zod schema)302. Define output type313. Identify possible error types (from taxonomy)324. Write handler signature: `Handler<Input, Output, Error1 | Error2>`3334**Example:**3536```typescript37// Input schema38const CreateUserInputSchema = z.object({39 email: z.string().email(),40 name: z.string().min(1),41});4243// Output type44interface User {45 id: string;46 email: string;47 name: string;48}4950// Handler signature51const createUser: Handler<unknown, User, ValidationError | ConflictError>;52```5354### Step 3: Map Errors to Taxonomy5556Map domain errors to the 10 categories:5758| Domain Error | Stack Category | Error Class |59|--------------|----------------|-------------|60| Not found | `not_found` | `NotFoundError` |61| Invalid input | `validation` | `ValidationError` |62| Already exists | `conflict` | `ConflictError` |63| No permission | `permission` | `PermissionError` |64| Auth required | `auth` | `AuthError` |65| Timed out | `timeout` | `TimeoutError` |66| Connection failed | `network` | `NetworkError` |67| Limit exceeded | `rate_limit` | `RateLimitError` |68| Bug/unexpected | `internal` | `InternalError` |69| User cancelled | `cancelled` | `CancelledError` |7071### Step 4: Choose Packages7273Packages are organized into three tiers:7475#### Package Tiers7677```78┌─────────────────────────────────────────────────────────────────┐79│ TOOLING TIER │80│ Build-time, dev-time, test-time packages │81│ @outfitter/testing │82└─────────────────────────────────────────────────────────────────┘83 ▲84 │ depends on85┌─────────────────────────────────────────────────────────────────┐86│ RUNTIME TIER │87│ Application-specific packages for different deployment targets │88│ @outfitter/cli @outfitter/mcp @outfitter/daemon │89│ @outfitter/config @outfitter/logging @outfitter/file-ops │90│ @outfitter/state │91└─────────────────────────────────────────────────────────────────┘92 ▲93 │ depends on94┌─────────────────────────────────────────────────────────────────┐95│ FOUNDATION TIER │96│ Zero-runtime-dependency core packages │97│ @outfitter/contracts @outfitter/types │98└─────────────────────────────────────────────────────────────────┘99```100101| Tier | Packages | Dependency Rule |102|------|----------|-----------------|103| **Foundation** | `contracts`, `types` | No @outfitter/* deps |104| **Runtime** | `cli`, `mcp`, `daemon`, `config`, `logging`, `file-ops`, `state` | May depend on Foundation |105| **Tooling** | `testing` | May depend on Foundation + Runtime |106107#### Package Selection108109| Package | Purpose | When to Use |110|---------|---------|-------------|111| `@outfitter/contracts` | Result types, errors, Handler contract | Always (foundation) |112| `@outfitter/types` | Type utilities, collection helpers | Type manipulation |113| `@outfitter/cli` | CLI commands, output modes, formatting | CLI applications |114| `@outfitter/mcp` | MCP server, tool registration | AI agent tools |115| `@outfitter/config` | XDG paths, config loading | Configuration needed |116| `@outfitter/logging` | Structured logging, redaction | Logging needed |117| `@outfitter/daemon` | Background services, IPC | Long-running services |118| `@outfitter/file-ops` | Secure paths, atomic writes, locking | File operations |119| `@outfitter/state` | Pagination, cursor state | Paginated data |120| `@outfitter/testing` | Test harnesses, fixtures | Testing |121122**Selection criteria:**123124- All projects need `@outfitter/contracts` (foundation)125- CLI applications add `@outfitter/cli` (includes UI components)126- MCP servers add `@outfitter/mcp`127- File operations need both `@outfitter/config` (paths) and `@outfitter/file-ops` (safety)128129### Step 5: Design Context Flow130131Determine:132133- **Entry points** — Where is context created? (CLI main, MCP server, HTTP handler)134- **Context contents** — Logger, config, signal, workspaceRoot135- **Tracing** — How requestId flows through operations136137## Output Templates138139### Architecture Overview140141```142Project: {PROJECT_NAME}143Transport Surfaces: {CLI | MCP | HTTP | ...}144145Directory Structure:146├── src/147│ ├── handlers/ # Transport-agnostic business logic148│ │ ├── {handler-1}.ts149│ │ └── {handler-2}.ts150│ ├── commands/ # CLI adapter (if CLI)151│ ├── tools/ # MCP adapter (if MCP)152│ └── index.ts # Entry point153└── tests/154 └── handlers/ # Handler tests155156Dependencies:157├── @outfitter/contracts # Foundation (always)158├── @outfitter/{package-2} # {reason}159└── @outfitter/{package-3} # {reason}160```161162### Handler Inventory163164| Handler | Input | Output | Errors | Description |165|---------|-------|--------|--------|-------------|166| `getUser` | `GetUserInput` | `User` | `NotFoundError` | Fetch user by ID |167| `createUser` | `CreateUserInput` | `User` | `ValidationError`, `ConflictError` | Create new user |168| `deleteUser` | `DeleteUserInput` | `void` | `NotFoundError`, `PermissionError` | Remove user |169170### Error Strategy171172```173Domain Errors → Stack Taxonomy:174175{domain-error-1} → {stack-category} ({ErrorClass})176 - When: {condition}177 - Exit code: {code}178179{domain-error-2} → {stack-category} ({ErrorClass})180 - When: {condition}181 - Exit code: {code}182```183184### Implementation Order1851861. **Foundation** — Install packages, create types1872. **Core handlers** — Implement business logic with tests1883. **Transport adapters** — Wire up CLI/MCP/HTTP1894. **Testing** — Integration tests across transports190191## Constraints192193**Always:**194- Recommend Result types over exceptions195- Map domain errors to taxonomy categories196- Design handlers as pure functions (input, context) → Result197- Consider all transport surfaces upfront198- Include error types in handler signatures199200**Never:**201- Suggest throwing exceptions202- Design transport-specific logic in handlers203- Recommend hardcoded paths204- Skip error type planning205- Couple handlers to specific transports206207## Related Skills208209- `outfitter-stack:stack-patterns` — Reference for all patterns210- `outfitter:tdd` — TDD implementation methodology211- `outfitter-stack:stack-templates` — Templates for components