make-app-service

make-app-service

对于管理员联系反馈，请复用 make-app-auth/references/access-help.md 中描述的已发布身份验证命名空间代理。保留已完成的拒绝状态码和响应正文（包括 reason 和 permissionKey）、Cookie 以及受信任的转发主机和协议；不要要求先成功完成业务请求才能联系帮助，也不要添加宽泛的网关代理。

在 apps/service 中进行 Make App Service API 相关工作时使用此技能。

make-app-service 负责 apps/ui 与 apps/service 之间的 Service API 契约、精简的 Make Data API 编排、Service 路由结构、Make 适配器运行时配置语义、Make 响应直通、Service 端验证、边界日志记录以及 Service API 测试。

它不负责记录操作行为（make-app-actions）、排序行为（make-app-sort）、筛选行为（make-app-filter）、分组行为（make-app-group）、Make AI 助手传输语义（make-ai-assistant）、UI 布局（makeui）、身份验证实现（make-app-auth）、单应用权限逻辑（make-app-permission）、运行时构建/启动契约（make-app-runtime）、DSL 建模（makedsl）、Make CLI 执行（makecli）或 CanvasTable 渲染/编辑（canvas-table-integration）。

快速开始

1. 检查 apps/docs/api.md、apps/service/src、apps/service/src/config.ts 或主机项目中的等效配置入口、现有测试，以及主机项目声明的数据流。
2. 保持主机 API 契约不变。更改 Service 路由或响应结构时，须在更改之前或同时更新 apps/docs/api.md。
3. 对于 Make Deploy 的默认路由拆分，已发布的面向浏览器的 Service 路由应视为 /api/**。不带前缀的 /app/**、/auth/** 或 /health 路由可能仅用于本地兼容；除非部署路由实际暴露了这些路由，否则不要将其记录为已发布的 UI 契约。
4. 实现前先对每条路由进行分类。普通直连 Make 代理须保留已完成请求的 2xx、4xx 和 5xx 状态码、Content-Type 及响应正文；文件下载还须保留 Content-Disposition 并以流的方式传输字节。**Make AI 助手是错误处理方面的明确例外：**须遵循所选适配器下文定义的安全公共错误契约，而非通用的原始错误透传。仅当 apps/docs/api.md 将真正的聚合／规范化路由注明为非代理路由时，该路由才能定义自己的成功结果；普通的 Make 已完成错误须保持不变。
5. 对于新的 Make POC Service，默认使用平台分层源码目录：app.ts、server.ts、config.ts、logger.ts、make-client/、services/、utils/；测试应与其覆盖的路由／适配器／辅助函数放在一起。
6. 不要将本地 DSL/YAML 用作已发布运行时的数据源。运行时 Schema 和数据来自 Make／后端 API，或主机 Service 适配器。
7. 使用共享适配器处理 Make Meta/Data/Preset 调用、候选 API、查找、文件和 Schema 规范化。应从规范化的运行时配置构建 Make 适配器 URL 和 appKey，而不是从路由本地的域名或 UI 输入构建。
8. 通过 make-app-permission 实现默认的单应用权限代理，包括 /api/make/app/principal/permission；生成或重构 Make App 时不得遗漏该代理。
9. 分别保留经过权限裁剪的 Schema 集合：分别规范化 fields 和 createFields；缺少 createFields 时，创建集合应为空，不得回退到 fields。保留未知的响应属性，包括 editableFields，但其权限语义交由 make-app-permission 处理。
10. 如果缓存 Schema，应按租户、主体／会话、App 和访问代次隔离经过权限裁剪的结果，并提供明确的权限刷新失效机制。
11. 对于 Make 记录操作，应在实现编辑 UI 之前实现文档规定的 record-write-permission 路由，并实现用于批量编辑的 records/bulk 路由；使用 make-app-actions 处理目标、权限、单请求语义以及既定的完整 UI-Service 响应契约。保留其成功、HTTP 200 部分拒绝和全选 403 的映射；其他已完成的 HTTP 错误须保留状态码、Content-Type 和响应正文，包括 reason、permissionKey 及管理员联系方式，不得包装成通用的 code/message。
12. 对于可取消或可被后续请求取代的请求，应将请求作用域的 AbortSignal 从 Service 边界传递到每个下游适配器；实现前请阅读 references/service-api-contracts.md。
13. 如果 Make App Service 更改涉及 Make AI 助手、AI助手、AI 对话框、SSE、Agent Gateway 或 @qfei-design/make-ai-assistant，请先使用 make-ai-assistant 处理 Make App AI Chat 协议。随后 Service 仅实现其文档规定的路由处理器、代理适配器、配置校验、日志记录、取消机制和测试。
14. 为每个更改过的路由、适配器、校验路径和错误路径添加或更新 Service 测试。
15. 仅阅读下方映射中所需的参考文件。

主题参考索引

任务 / 主题	阅读
服务路由形式和 UI-Service 响应约定	references/service-api-contracts.md
请求取消、客户端断开处理、下游 AbortSignal 传递	references/service-api-contracts.md
Schema 缓存刷新、进行中请求复用与取消的组合场景	references/service-api-contracts.md、references/testing-and-safety.md
Service 文件夹结构、分层、日志、错误	references/service-layering.md
Make Data API 适配器规则、Schema fields / createFields、记录、文件、查找、候选项	references/make-data-adapter.md
测试要求、约定检查、安全审查	references/testing-and-safety.md
单应用权限代理、Make IAM 主体权限、应用范围权限载荷	使用 make-app-permission
身份验证代理、Cookie、统一登录、401/403 行为	使用 make-app-auth
Service 构建输出、端口 3000、dist/server.js、package 脚本、发布就绪状态	使用 make-app-runtime
UI 布局、表单、详情显示、视觉状态	使用 makeui
CanvasTable 中 Make 字段 / 表格渲染	使用 canvas-table-integration
记录排序、可排序能力、Preset 排序、记录排序	使用 make-app-sort
高级筛选包行为和 Preset 筛选	使用 make-app-filter
记录分组、可分组能力、Preset 分组、record-groups、groupFilter	使用 make-app-group
记录操作预检查、严格选择目标、单请求批量更新	使用 make-app-actions
Make App AI 助手、AI 助手、AI 对话框、SSE、Agent Gateway、助手能力、接口域配置	对已确认的 /api/make/app/ai/v1/** 18 项操作协议，使用 make-ai-assistant。Service 负责路由、校验、日志、取消和运行时配置使用

范围边界

• make-app-service 定义由 Service 负责的应用 API，例如架构、记录、候选项、查找选项、文件代理和精简的自定义编排。
• 每个新的 Make App Service 都使用 make-app-observability 设置默认请求 Trace ID：在边界处验证或创建该 ID，返回 X-Log-Id，将安全上下文写入日志，并且仅向 Make Gateway 转发已验证的跟踪标头。此 Skill 负责路由和适配器实现，而 make-app-observability 负责跨边界不变量和审计。
• 可以记录路由名称、查询/请求体结构、响应封装和适配器行为。
• 可以定义 Service 端 Make 适配器配置语义，以及 Service 源代码中使用的环境变量名称，例如 MAKE_APP_KEY 和 MAKE_API_BASE_URL；部署注入则由运行时/运维负责。
• 不得决定身份验证实现或 OAuth/会话机制；这些属于 make-app-auth。但仍可挂载并记录主机契约要求的 App Service 身份验证代理路径。对于使用 gatewayBaseUrl: "/api/make" 的 Make Deploy Service 前置应用，通常为 /api/make/auth/** 和 /api/make/oauth/**。
• 不得定义单应用权限逻辑、IAM 权限匹配、路由守卫、操作按钮或字段可编辑性；这些属于 make-app-permission。但应提供该权限代理所需的 Service 分层、日志、测试和文档。
• 不得决定构建输出、Service 端口、Docker/K8s 入口点、包脚本、工作区清单或发布就绪状态；这些属于 make-app-runtime。
• 不得定义业务模型、实体、字段含义、关系或 DSL YAML；这些属于 makedsl。
• 不得决定 UI 布局、组件选择、Drawer 布局或 CanvasTable 渲染；这些属于 makeui 和 canvas-table-integration。
• 不得定义 Make AI 助手 SSE 事件语义或能力协商；这些属于 make-ai-assistant。当前 Make App AI 适配器不携带 Artifact 负载。
• 不得硬编码环境到域名的映射。Make API 基础 URL、网关路由和密钥注入由运行时配置、后端/运维或 Make 工具提供。

默认 Service 职责

审批新建、bpmDefinitionKey、启动字段、首次发起和流程状态传输使用 make-app-approval。Service 保留对象顶层 key 及记录系统状态/锁字段；审批新建的可写字段来自权威启动配置，普通新建仍用原 createFields/IAM 合同，已有记录编辑仍用原更新链路。不要让普通源字段交集二次裁掉审批授权，也不要信任客户端声明的审批模式。

当 UI 需要以下能力，且主机项目尚无等效路由时，生成或重构的 Make App Service 代码应提供这些能力：

• 公共健康状态/配置：供已发布 UI 访问的 /api/health、/api/config；/health 可作为本地或 k8s 探针兼容路由存在
• 运行时架构：/api/schema、/api/entities/:entityKey/fields
• 默认单应用权限：通过 make-app-permission 提供 /api/make/app/principal/permission
• 仅当主机要求且 make-ai-assistant 有明确规定时，才提供 Make App AI 助手路由：公开精确的 /api/make/app/ai/v1/** 18 项操作许可列表，涵盖 capabilities、分页 Agents、多会话聊天、反馈、消息/历史记录、响应事件/快照/取消、上传/分块/完成以及内容字节；绝不可使用通用代理
• 记录：列表、获取、新建、更新、删除、单元格更新
• 当列表可写时的记录操作：行写入权限预检，以及单请求批量字段更新，通过 make-app-actions 实现
• 当前用户 Entity Preset：获取，以及启用筛选或排序时的稀疏筛选/排序更新
• 查找选项和安全的查找关系更新
• 用户候选项和部门候选项
• 文件上传/删除/下载代理
• 按需提供精简的自定义编排，例如创建 OCR 结果

保持路由处理函数精简。将 Make/后端调用放在适配器模块中，将跨路由的业务编排放在 services/ 中，将纯架构/值辅助函数放在 utils/ 中。

Hard rules

• apps/docs/api.md 是 UI-Service 契约的来源。更改 Service 路由行为时，必须同步更新该文件。
• 对于使用 gatewayBaseUrl: "/api/make" 的 Make Deploy Service 前置应用，apps/docs/api.md 必须记录 /api/make/** 下发布后的浏览器路径，例如 /api/make/auth/**、/api/make/oauth/** 和 /api/make/app/**。除非 deploy HTTPRoute 暴露了不带前缀的 /app/**，否则不要将其记录为发布路径。较旧的 /api 项目只能将 /api/auth/** 和 /api/app/** 保留为明确标注的旧版契约。
• 新生成的 Make POC Service，以及非平凡的 apps/service 生成代码或重构代码，必须采用分层、组件化的源代码结构，而不是扁平的路由／适配器／辅助函数文件。对于新的 Make POC Service，默认采用平台目录结构：app.ts、server.ts、config.ts、logger.ts、用于 Make／后端适配器的 make-client/、用于多步骤编排的 services/、用于纯辅助函数的 utils/，以及就近放置的测试。
• 如果扁平的 apps/service/src 目录将路由注册、Make 请求构建、架构规范化、查找／文件编排、配置解析、日志记录和辅助函数混在一起，则对于生成的 POC 工作来说，这是就绪状态缺陷。将其拆分后再报告 Service 已完成。
• app.ts 或 routes/ 中的路由处理程序只负责验证输入、调用 Service／适配器、映射由 Service 管理的预检错误、记录安全的边界上下文，并发送文档规定的响应。普通的直接 Make 代理必须原样保留已完成响应的 HTTP 状态、Content-Type 和正文，适用于 2xx、4xx 和 5xx；选定的 Make AI 助手适配器则遵循其明确规定的安全错误契约。不要在路由处理程序中直接构建原始 Make 负载、解析架构变体、编排记录查找、映射文件代理或执行自定义工作流步骤。
• 面向 UI 的聚合路由只有在 apps/docs/api.md 明确标注其为非代理路由时，才能采用有文档说明的规范化成功响应结构。从 references/service-api-contracts.md 中的默认路由响应模式表开始，然后记录任何特定宿主的例外及其迁移方式。普通的已完成 Make 错误保持不变；选定的 Make AI 助手错误契约是另行记录的例外。
• Service 路由处理程序必须先验证查询参数／正文／路径参数，再调用 Make 适配器；客户端输入无效时返回 400。
• Service 适配器负责 Make 请求细节，例如 appKey、X-Make-Target、Make 响应码检查、分页转换、文件正文映射，以及使用已准备好的登录／会话转发上下文。身份验证／会话机制和共享转发辅助函数属于 make-app-auth；发布／运行时代理标头契约属于 make-app-runtime。
• 根据端点契约解析成功响应。现有身份验证 current-context 使用方遵循 make-app-auth/references/service-fronted-mode.md#current-context-consumption；不要复用 Meta/Data 信封解析器。
• Make 驱动的记录读取 API 必须通过 Service Make 适配器调用 Make gateway Data API。发布环境使用 k8s 内部的 /make/data/v1/record；当 MAKE_APP_LOCAL_PREVIEW=true 时，本地预览使用 makecli configure resolve --target local-preview --output=json 的 make_api_origin 字段加上 /api/make/data/v1/record。这适用于记录列表、记录详情、查找目标记录读取，以及任何读取 Make 记录的自定义 Service 路由。
• Service Make 适配器必须将传入请求已建立的登录上下文转发给 Make gateway，以供 Make 驱动的数据读取和写入使用。至少要在宿主使用 Cookie／统一登录身份验证时保留浏览器 Cookie 会话标头；只有在宿主契约已使用 bearer 身份验证时，才保留已有的 Authorization 标头；并通过共享的身份验证／运行时辅助函数应用宿主 gateway 上下文标头，例如 X-Forwarded-Host 和 X-Forwarded-Proto。不要在此处自行制定身份验证策略：身份验证机制使用 make-app-auth，但调用 gateway 前不得丢弃登录上下文。
• 发布／运行时 Service API 绝不能将 makecli 用作数据源。不要通过运行 shell 命令调用 makecli、npx makecli，也不要使用本地 makecli 配置或 makecli JSON 标准输出，为架构、记录、候选项、查找选项、文件或自定义 API 数据提供服务。在线 Service 容器中没有 makecli，因此运行时数据必须来自 Make gateway／API 适配器。
• Make 驱动的 Service 配置必须从部署注入的 MAKE_APP_KEY 读取权威 appKey；生成的生产代码不得自行创建、硬编码该值，也不得允许 UI 输入覆盖其作用域。只有当 Service 在调用适配器前验证查询或正文中的 appKey 与 MAKE_APP_KEY 完全一致时，有文档说明的协议路由才能在查询参数或正文中携带 appKey。
• 如果调用 Make Meta/Data API 的 Service 缺少 MAKE_APP_KEY，配置加载必须失败，并给出明确且不含机密信息的错误，然后才能报告 Service 已就绪。本地测试夹具可以显式注入 MAKE_APP_KEY。
• 新生成的 Service 代码从 apps/service/src/config.ts 或宿主等效文件读取 Make 适配器运行时配置。MAKE_API_BASE_URL 是首选的发布 gateway 源站环境变量；MAKE_SERVER_URL 仅作为兼容别名。本地预览通过 makecli configure resolve --target local-preview --output=json 获取其公共 gateway 源站，而不是使用部署环境变量。
• 对于 Make 驱动的 Service，如果既未配置 MAKE_API_BASE_URL，也未配置 MAKE_SERVER_URL，配置加载必须失败，并给出明确且不含机密信息的错误，然后才能报告 Service 已就绪。
• 发布环境中的 MAKE_API_BASE_URL／MAKE_SERVER_URL 值必须是严格的 k8s gateway 源站，例如 http://make-gateway.make-dev。新生成的 Service 代码不得在此环境变量中包含 /make、/api/make、/meta、/data、/auth 或其他服务路径作用域。本地预览必须将解析输出作为 make_api_origin 使用；如果较旧的 makecli 回退逻辑返回或读取了带路径作用域的公共 /api/make API 基址，只能在本地预览适配器内部对其进行规范化。
• Make 平台适配器负责管理服务路径作用域。生成的 Service 代码根据显式运行时模式推导上游 URL：本地预览使用公共 gateway 源站加 /api/make/**；发布环境使用 k8s gateway 源站加 /make/**，例如 http://make-gateway.make-dev/make/meta/** 和 http://make-gateway.make-dev/make/data/**。
• 对于 Make App AI 助手适配器，遵循 make-ai-assistant：浏览器通过同源地址调用固定的 /api/make/app/ai/v1/** 18 个操作系列；本地预览 Service 上游使用 make_api_origin 加 /api/make/app/ai/v1/**；发布环境 Service 上游使用 MAKE_API_BASE_URL 或其兼容别名 MAKE_SERVER_URL 中的严格源站加 /make/app/ai/v1/**。Service 必须从 MAKE_APP_KEY 读取已部署的作用域，并拒绝任何与其不同的查询或正文 appKey；每个非 GET／HEAD 请求都必须包含一个 HTTP(S) 同源 Origin，并根据选定的 Host 进行检查。不要添加仅供助手使用的 AI Gateway／Agent Gateway 源站、令牌、环境变量或硬编码域名。将裸 JSON 对象、空的 204 响应、Make-AI-Api-Version、SSE 和字节数据保留为不同的成功模式，并且不要在宿主验证器中缩小有效协议 DTO 的范围。对于 AI 错误，按其 HTTP 状态保留符合架构、范围受限的扁平 {code,message,requestId?,details?}，包括可扩展的未知代码；格式错误或非公开的上游错误应转换为安全的 Service 错误，不泄露原始诊断信息。绝不能将有效的公开类型错误重新映射为 502。
• 如果同一 Service 还会调用其他 gateway 服务，这些适配器必须基于同一 gateway 源站，定义各自明确的服务作用域。不要从 MAKE_API_BASE_URL 中剥离 /make，也不要通过滥用带路径作用域的基址来访问无关服务。
• 集群内部从 Service 到 gateway 的调用不得使用面向浏览器的 /api/make 前缀。/api/make/** 用于同源浏览器访问、Service 入口和本地预览公共 gateway 调用；发布环境 Service 内部上游 URL 使用 gateway 源站加 /make。
• Service 源代码不得硬编码具体的 Make 开发／测试／生产域名，不得推断命名空间内的 gateway 地址，也不得将部署环境映射到域名。
• 发布环境中的运行时 Service 代码启动或为已发布应用提供架构／数据服务时，不得依赖 apps/dsl/**、/dsl/** 或复制的 *.yaml 文件。
• 在 UI 看到架构之前，架构 API 必须先规范化后端架构变体。处理已知变体，例如 entity.properties.fields、entity.fields 或宿主文档规定的等效形式；并保留用于排序和分组的字段 capabilities.sortable／capabilities.groupable。
• 权限裁剪后的架构规范化必须将 fields 和 createFields 作为独立集合。分别规范化每个集合；缺失或无效的 createFields 必须变为 []，绝不能回退到 fields。当宿主契约要求无损转发时，将 editableFields 保留为响应元数据，但不得用它推导当前编辑行为。
• 架构缓存和并发请求复用不得在不同主体之间共享经过权限裁剪的实体。按租户、主体／会话身份、应用和访问代次设置缓存键（或使用请求级缓存），并提供失效／重新加载路径，以便权限刷新在数据刷新之前调用。
• 记录列表和详情属于不同的契约。如果 Make 提供单条记录调用，不要通过调用列表并猜测第一行来实现详情。
• 实体预设 GET／PATCH 路由必须使用 Make Preset /preset/v1/entity 适配器及 MakeService.GetResource／MakeService.UpdateResource，保留已建立的登录上下文，并且只更新已提交的维度。维度语义使用 make-app-sort、make-app-filter 和 make-app-group。
• 预设排序和记录排序必须共用结构验证，并依据当前运行时架构的 capabilities.sortable === true 对字段进行权威验证。在调用 Make 之前，拒绝无效、重复、不可排序或超过五条的规则。
• 稀疏预设更新必须保留其他维度：保存排序时不得发送筛选条件／分组；保存筛选条件时不得发送排序／分组；保存分组时不得发送筛选条件／排序。
• 用户和部门候选项必须来自 GET /api/users、GET /api/departments 等 Service 路由或宿主等效路由；生成的 Service 不得使用本地演示数组。
• 查找选项 API 必须通过架构元数据解析目标对象／字段，并返回 { options, total }。默认情况下，不得向选择器 UI 暴露完整的目标记录。
• 文件路由必须通过 Service 代理上传／删除／下载。当 Service 下载代理可用时，UI 不应暴露原始后端文件 URL。
• <img src> 等浏览器资源标签无法附加 Authorization。当 Make 文件下载需要 bearer 令牌时，应通过 Service 下载代理保留面向浏览器的 URL，先验证当前 App 会话，并仅由 Service 适配器附加部署注入的令牌。不得将 Make 令牌或原始 /data/v1/download/** URL 放入 UI 状态、公共配置、JSX 或日志。
• 在路由／适配器入口、成功和失败时添加边界日志。对令牌、Cookie、Authorization、API 密钥、签名下载查询字符串以及不必要的个人数据进行脱敏。
• 对于可取消或可被新任务取代的工作，客户端断开连接时必须通过请求作用域的 AbortSignal 中止下游工作。不要仅仅忽略过期响应，也不要将预期中的 AbortError 视为面向用户的 5xx 故障。
• 必须为路由契约、无效输入、适配器负载、直接 Make 响应状态／正文透传，以及此技能新增的任何架构／值规范化编写测试。
• 如果缺少 make-app-permission 默认的主体权限代理及其必需测试，不得报告生成或重构的 Make App Service 已完成。
• 对于 record-write-permission 和 records/bulk，遵循 make-app-actions： 使用一次 Make /data/v1/permission 调用预先检查完整目标；在 JavaScript Number 强制转换和通用 Make 错误映射之前，从原始响应中无损解析显式选择场景下 HTTP 200／业务码 20000032 的拒绝响应及其 noPermissionRecordIds；全选场景下的 403 拒绝响应不得包含 ID；复用该目标进行一次 Make /data/v1/field 调用；绝不拆分诊断信息或循环执行单条记录更新。

默认路由基线

除非宿主项目已有等效路由的文档说明，否则新建 Make App Service 项目时优先采用这些 UI-Service 契约：

GET    /api/health
GET    /health
GET    /api/config
GET    /api/make/app/principal/permission
GET    /api/schema
GET    /api/entities/:entityKey/fields
GET    /api/entities/:entityKey/preset
PATCH  /api/entities/:entityKey/preset
GET    /api/entities/:entityKey/records
GET    /api/entities/:entityKey/records/:recordID
POST   /api/entities/:entityKey/records
POST   /api/make/app/entities/:objectKey/record-write-permission
POST   /api/make/app/entities/:objectKey/records/bulk
PATCH  /api/entities/:entityKey/records/:recordID
DELETE /api/entities/:entityKey/records/:recordID
PATCH  /api/entities/:entityKey/records/:recordID/cells/:fieldKey
GET    /api/users
GET    /api/departments
GET    /api/lookup-options
POST   /api/entities/:entityKey/records/:recordID/files/:fieldKey
DELETE /api/entities/:entityKey/records/:recordID/files/:fieldKey
GET    /api/files/download/*

查询关系更新路由为可选项，仅当 UI 需要可编辑的查询关系，且 Service 能安全保留完整的 qfei_relation 快照时才应生成。

协作规则

• 与 makeui 协作：本技能提供 Service 契约和规范化的 API 格式；makeui 决定 UI 的渲染方式。
• 与 make-app-permission 协作：本技能提供 Service 分层和测试；make-app-permission 负责主体权限路由、IAM 上游路径、App 范围载荷和前端权限契约。
• 与 canvas-table-integration 协作：本技能提供架构、记录和候选项 API，并负责 Service 端断开连接时取消下游请求；表格渲染、编辑 UI 和浏览器端虚拟分页调度由 canvas 技能负责。
• 与 make-app-sort 协作：本技能实现并测试 Preset/records 路由和 Make 适配器；make-app-sort 负责可排序规则、草稿/保存时机和表头关联。
• 与 make-app-filter 协作：本技能实现并测试 Preset/records 路由和 Make 适配器；make-app-filter 负责包级筛选行为、状态恢复和保存时机。
• 与 make-app-group 协作：本技能实现并测试 Preset group、record-groups、records groupFilter 和 Make 适配器；make-app-group 负责可分组规则、groupFilter 组合、分组数据时机和 CanvasTable 分组流程协调。
• 与 make-app-actions 协作：本技能实现并测试 record-write-permission、records/bulk、严格的目标解析、Make 适配器和错误映射；make-app-actions 负责选择意图、操作时机、权限键选择、冻结快照和 UI 反馈。
• 与 make-ai-assistant 协作：本技能实现 Make App AI 路由处理程序、代理适配器、运行时配置校验、安全日志、AbortSignal 传播和 Service 测试；make-ai-assistant 负责包集成、v1 的 18 项操作 DTO/响应/流语义、多会话行为和接口域规则。
• 与 make-app-auth 协作：本技能可以保留由 Service 提供支持的应用路由结构，但身份验证代理和会话行为由 auth 负责。
• 与 make-app-runtime 协作：本技能编写 Service 源码和测试；运行时构建/启动/端口检查由 runtime 负责。