用途：laneweaverTMS Feature Workflow 是面向 laneweaverTMS 的编排指南，用于端到端实现跨数据库、后端与前端的新功能，本身不重复各专项技能内容，而是协调其他技能与智能体。
适用场景：实现跨多层的新功能；新增实体或资源；规划功能实现顺序；决定应调用哪些技能或智能体。
实施前置检查：明确功能需求（用户故事、验收标准）、数据库 Schema（新表、字段、ENUM）、API 端点（REST 端点及请求响应结构）、前端组件（页面、组件、可复用模式）、领域知识（货运术语与业务逻辑）。
分步工作流：第一步数据库 Schema，调用 schema-migration-agent，隔离 500KB erd.sql 上下文，迁移文件生成于 supabase/migrations/，并遵循 supabase:laneweaver-database-design 约定（UUID 主键、审计字段、软删除、手动 FK 索引）。第二步 Models，使用 golang-orchestrator:backend-service-patterns，在 /internal/models/ 创建带标签的 Go 结构体。第三步 Repository，SQL 查询须包含 WHERE deleted_at IS NULL，多表用事务，复杂过滤用 QueryBuilder，处理 pgx.ErrNoRows。第四步 Service，方法开头校验请求，返回 ValidationErrors，贯穿 context.Context。第五步 Handler，用 Echo 的 c.Bind()，返回 APIResponse 包装，添加 Swagger/OpenAPI 注解。第六步 Router，在 Setup 中按 RESTful 注册。第七步前端，调用 frontend-component-agent，配合 svelte5-runes 与 shadcn-svelte-skill。
实现顺序规则：数据库先于 Go 代码，Models 先于 Repository，Repository 先于 Service，Service 先于 Handler，Handler 先于 Router，后端先于前端。
常用模式：新增实体 CRUD 按上述七步；给已有实体加字段需迁移、模型、查询与 DTO；新增状态工作流需 ENUM、常量校验与状态机逻辑，可参考 load-lifecycle-patterns。
应避免：跳过数据库迁移、在 handler 写业务逻辑、到处裸 SQL、忽略软删除、先做前端。货运术语可查 freight-domain-glossary。具体实现细节应调用对应专项技能，而非凭记忆实现。官方未提供收费、平台与效果信息。