用途：在规划新项目、选择 @outfitter/* 包、设计 handler 架构时，提供一套栈式系统设计流程。核心目标是构建与传输层无关（transport-agnostic）的 handler 系统，使用 Result 类型和统一的错误分类。
主要流程：
- 理解需求：明确传输面（CLI、MCP、HTTP 或全部）、领域操作、失败模式、外部依赖。
- 设计 handler 层：为每个领域操作定义输入类型（Zod schema）、输出类型、可能的错误类型，并写出 Handler<Input, Output, Error1 | Error2> 签名。
- 映射错误到分类：将领域错误归入 10 类，如 not_found→NotFoundError、validation→ValidationError、conflict→ConflictError、permission→PermissionError、auth→AuthError、timeout→TimeoutError、network→NetworkError、rate_limit→RateLimitError、internal→InternalError、cancelled→CancelledError。
- 选择包：分三层。Foundation 层（contracts、types）无 @outfitter/* 依赖；Runtime 层（cli、mcp、daemon、config、logging、file-ops、state）可依赖 Foundation；Tooling 层（testing）可依赖前两层。所有项目都需要 @outfitter/contracts；CLI 应用加 @outfitter/cli；MCP 服务器加 @outfitter/mcp；文件操作需同时用 config（路径）和 file-ops（安全）。
- 设计上下文流：确定入口点、上下文内容（logger、config、signal、workspaceRoot）以及 requestId 的追踪方式。
约束：推荐 Result 类型而非异常；handler 设计为纯函数 (input, context) → Result；handler 签名中必须包含错误类型；不得在 handler 中写传输层逻辑；不得硬编码路径；不得跳过错误类型规划。
适用场景：新项目架构规划、包选型、handler 架构设计。限制：资料未提供具体安装命令、版本要求或运行环境细节。