Back to Details

spring-explore

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Preflight: Spring MCP

预检查：Spring MCP

This skill is part of the Spring Agent Toolkit and is designed to work with the Spring MCP server (provided by the Amplicode IntelliJ plugin). Before doing anything else, check your tool list for any Spring MCP tool — they are exposed under the 
amplicode
MCP server (e.g. 
get_project_summary
, 
list_module_dependencies
, 
get_entity_details
); harnesses that flatten MCP tools into the tool list use the 
mcp__amplicode__
prefix on the same names.
  • If at least one Amplicode tool is available — MCP is connected. Proceed with the skill below.
  • If none are available — stop and invoke the 
    amplicode-install
     skill (bundled with the Spring Agent Toolkit). It installs the Amplicode plugin and walks the user through the «Настроить Spring Agent» welcome-screen button + MCP-client restart. After it completes, the MCP tools become available — resume this skill.
  • If 
    amplicode-install
    is not registered in your skill list, tell the user (in their language): "This skill needs the Amplicode IntelliJ plugin and its MCP server. Install it from https://amplicode.ru/marketplace into IntelliJ IDEA Ultimate/Community or GigaIDE, open any project, click «Настроить Spring Agent» on the Amplicode welcome screen, then restart your MCP client."
本技能属于Spring Agent Toolkit，旨在与Spring MCP server（由Amplicode IntelliJ插件提供）配合使用。在进行任何操作之前，请检查你的工具列表中是否有Spring MCP工具——它们在
amplicode
MCP服务器下暴露（例如
get_project_summary
、
list_module_dependencies
、
get_entity_details
）；将MCP工具整合到工具列表中的工具会在相同名称前添加
mcp__amplicode__
前缀。
  • 如果至少有一个Amplicode工具可用——MCP已连接。继续执行以下技能。
  • 如果没有可用的Amplicode工具——停止操作并调用**
    amplicode-install
    **技能（随Spring Agent Toolkit捆绑提供）。它会安装Amplicode插件，并引导用户完成«Настроить Spring Agent»欢迎屏幕按钮操作 + MCP客户端重启。完成后，MCP工具将可用——恢复执行本技能。
  • 如果你的技能列表中未注册
    amplicode-install
    ，请用用户的语言告知：“本技能需要Amplicode IntelliJ插件及其MCP服务器。请从https://amplicode.ru/marketplace安装到IntelliJ IDEA Ultimate/Community或GigaIDE中，打开任意项目，点击Amplicode欢迎屏幕上的«Настроить Spring Agent»，然后重启你的MCP客户端。”

Explore Application

探索应用

Collects primary project context in steps 0–6. Execute steps sequentially — each one builds on the results of the previous.
Important: if context has already been collected in the current conversation, do not repeat the exploration — use what is already known.
通过步骤0–6收集项目核心上下文。按顺序执行步骤——每个步骤都基于前一步的结果构建。
重要提示：如果当前对话中已收集上下文，请不要重复探索——使用已知的信息。

Step 0 — Predict involvement from the user's request

步骤0 — 从用户请求预判涉及范围

Tell the user: 
Step 0/6: Analyzing request...
Do NOT call any tools in this step.
Read the user's request and reason about what the implementation likely involves. Without calling any tools, make educated guesses based on naming conventions, domain language, and typical Spring Boot patterns:
  • Entities — what domain objects are likely involved? (e.g. "create order" → 
    Order
    , 
    OrderItem
    )
  • Repositories — which repositories probably exist for those entities?
  • Services — what service classes are likely needed?
  • Controllers — what REST controllers probably handle this area?
  • Other beans/components — mappers, validators, event listeners, configs, etc.
  • Files — what non-Java files are likely relevant? (e.g. DB migration scripts, 
    application.properties
    , Liquibase changelogs, HTML templates). Do not list Java classes here — they belong to the categories above.
Build a preliminary gap list containing only what is genuinely required:
undefined
告知用户：
Step 0/6: 分析请求中...
本步骤请勿调用任何工具。
阅读用户的请求，推断实现可能涉及的内容。无需调用工具，基于命名规范、领域语言和典型Spring Boot模式做出合理猜测：
  • 实体——可能涉及哪些领域对象？（例如“创建订单”→ 
    Order
    、
    OrderItem
    ）
  • 仓库——这些实体可能对应哪些仓库？
  • 服务——可能需要哪些服务类？
  • 控制器——哪些REST控制器可能处理此领域？
  • 其他Bean/组件——映射器、验证器、事件监听器、配置等。
  • 文件——哪些非Java文件可能相关？（例如数据库迁移脚本、
    application.properties
    、Liquibase变更日志、HTML模板）。此处请勿列出Java类——它们属于上述类别。
构建仅包含真正必要内容的初步缺口列表：
undefined

Predicted involvement:

预判涉及范围：

  • Entities: Order, OrderItem, Customer
  • Repositories: OrderRepository, CustomerRepository
  • Services: OrderService
  • Controllers: OrderController
  • Other: OrderMapper
  • Files: src/main/resources/db/migration/V1__create_orders.sql, application.properties

This prediction drives steps 1–5 — skip anything irrelevant to the task.

---
  • 实体：Order, OrderItem, Customer
  • 仓库：OrderRepository, CustomerRepository
  • 服务：OrderService
  • 控制器：OrderController
  • 其他：OrderMapper
  • 文件：src/main/resources/db/migration/V1__create_orders.sql, application.properties

此预判将指导步骤1–5——跳过与任务无关的内容。

---

Step 1 — Define exploration goal and select paths

步骤1 — 定义探索目标并选择路径

Tell the user: 
Step 1/6: Selecting exploration paths...
Do NOT call any tools in this step.
Read the current conversation context — the user's request, any prior exploration results, remaining gaps — and formulate the key exploration goal in one sentence. Show it to the user:
undefined
告知用户：
Step 1/6: 选择探索路径中...
本步骤请勿调用任何工具。
阅读当前对话上下文——用户的请求、任何先前的探索结果、剩余缺口——并用一句话明确探索核心目标。将其展示给用户：
undefined

Exploration goal:

探索目标：

Understand the Order aggregate structure and verify what repositories and mappers already exist.

Using this goal, go through each exploration path below and explicitly decide: **include** or **skip**, with a one-line reason. Do this for every path — do not skip the evaluation itself.

**Project structure**
- **Fetch project summary** — include if the tech stack, Spring Boot version, or module structure are needed. Skip if the task is narrowly scoped to specific classes.
- **Detect persistence stack** — include if any entity-touching path below is selected AND the stack (JPA vs JDBC) is not yet known from the conversation. Call `list_module_dependencies`: dependency on `spring-boot-starter-data-jpa` / `hibernate` → JPA; `spring-boot-starter-data-jdbc` / `spring-data-jdbc` → JDBC; neither → no supported persistence layer, skip entity-touching paths.
- **List domain entities** — include ONLY if the domain area is completely unknown and you cannot predict which entities are involved. If entities are already named in the request or predictable from context — skip. Do NOT use to get entity structure or resolve FQNs.
- **List REST endpoints** — include only if you need to check what already exists to avoid duplication or understand conventions. Skip if the request fully defines all endpoints from scratch.

**Domain model**
- **Get entity description** — include if entity fields or annotations are needed. Apply only to predicted entities, not all entities. Route by stack: JPA → `get_entity_details`, see [`references/entity-description.md`](references/entity-description.md); JDBC → `get_jdbc_entity_details`, see [`references/entity-description-jdbc.md`](references/entity-description-jdbc.md).
- **Get deep model from entity** — include if relationships across multiple entities need to be traversed (e.g. nested resources, cascades). **JPA only** — for JDBC `get_jdbc_entity_details` already returns the full owned-children tree (`aggregates`) and inverse links (`referencedBy`); use the DDD path below instead. See [`references/deep-model-based-on-jpa.md`](references/deep-model-based-on-jpa.md).
- **Get DDD model from entity** — include if aggregate boundaries matter (e.g. URL design, cascade planning, DTO shaping). JPA: follow [`references/ddd-model-based-on-jpa.md`](references/ddd-model-based-on-jpa.md). JDBC: call `get_jdbc_entity_details` and read `aggregateRootFqn`, `aggregates`, `referencedBy` directly — Spring Data JDBC enforces aggregate boundaries at the framework level.

**Persistence**
- **Get entity repositories** — include if repositories for predicted entities are unknown or need to be verified. See [`references/entity-repositories.md`](references/entity-repositories.md).
- **Get entity components** — include if you need a full picture of all components (repositories, services, controllers) for an entity. See [`references/entity-components.md`](references/entity-components.md).

**Services**
- **Get entity services** — include if services for predicted entities are unknown or need to be verified. See [`references/entity-services.md`](references/entity-services.md).

**Mappers**
- **Get entity mappers** — include if the task involves DTOs and you need to know what mappers exist. See [`references/entity-mappers.md`](references/entity-mappers.md).

**DTOs**
- **Get entity DTOs** — include if you need to know what DTO classes already exist. See [`references/entity-dtos.md`](references/entity-dtos.md).

**REST layer**
- **Get entity controllers** — include if you need to find which controllers are associated with an entity. See [`references/entity-controllers.md`](references/entity-controllers.md).

Write out the evaluation explicitly, then produce the final plan from included paths only:

**Example** — for a request "Add a paginated endpoint returning all orders for a customer with order items and product names":
了解Order聚合结构并验证已存在的仓库和映射器。

基于此目标，逐一评估以下每条探索路径，并明确决定：**包含**或**跳过**，同时给出一行理由。请对每条路径进行评估——不要跳过评估本身。

**项目结构**
- **获取项目摘要**——如果需要技术栈、Spring Boot版本或模块结构则包含。如果任务范围仅限于特定类则跳过。
- **检测持久化栈**——如果选择了以下任何涉及实体的路径，且对话中尚未明确栈类型（JPA vs JDBC）则包含。调用`list_module_dependencies`：依赖`spring-boot-starter-data-jpa`/`hibernate`→ JPA；依赖`spring-boot-starter-data-jdbc`/`spring-data-jdbc`→ JDBC；两者都不依赖→无支持的持久化层，跳过涉及实体的路径。
- **列出领域实体**——仅当领域完全未知且无法预判涉及哪些实体时包含。如果请求中已提及实体或可从上下文预判则跳过。请勿用于获取实体结构或解析全限定名（FQN）。
- **列出REST端点**——仅当需要检查已存在的内容以避免重复或了解约定时包含。如果请求完全从头定义所有端点则跳过。

**领域模型**
- **获取实体描述**——如果需要实体字段或注解则包含。仅应用于预判的实体，而非所有实体。根据栈类型选择：JPA→`get_entity_details`，参见[`references/entity-description.md`](references/entity-description.md)；JDBC→`get_jdbc_entity_details`，参见[`references/entity-description-jdbc.md`](references/entity-description-jdbc.md)。
- **从实体获取深度模型**——如果需要遍历多个实体间的关系（例如嵌套资源、级联）则包含。**仅支持JPA**——对于JDBC，`get_jdbc_entity_details`已返回完整的子实体树（`aggregates`）和反向关联（`referencedBy`）；请改用下方的DDD路径。参见[`references/deep-model-based-on-jpa.md`](references/deep-model-based-on-jpa.md)。
- **从实体获取DDD模型**——如果聚合边界很重要（例如URL设计、级联规划、DTO塑造）则包含。JPA：遵循[`references/ddd-model-based-on-jpa.md`](references/ddd-model-based-on-jpa.md)。JDBC：调用`get_jdbc_entity_details`并直接读取`aggregateRootFqn`、`aggregates`、`referencedBy`——Spring Data JDBC在框架层面强制聚合边界。

**持久化**
- **获取实体仓库**——如果预判实体的仓库未知或需要验证则包含。参见[`references/entity-repositories.md`](references/entity-repositories.md)。
- **获取实体组件**——如果需要了解实体对应的所有组件（仓库、服务、控制器）的完整信息则包含。参见[`references/entity-components.md`](references/entity-components.md)。

**服务**
- **获取实体服务**——如果预判实体的服务未知或需要验证则包含。参见[`references/entity-services.md`](references/entity-services.md)。

**映射器**
- **获取实体映射器**——如果任务涉及DTO且需要了解已存在的映射器则包含。参见[`references/entity-mappers.md`](references/entity-mappers.md)。

**DTO**
- **获取实体DTO**——如果需要了解已存在的DTO类则包含。参见[`references/entity-dtos.md`](references/entity-dtos.md)。

**REST层**
- **获取实体控制器**——如果需要查找与实体关联的控制器则包含。参见[`references/entity-controllers.md`](references/entity-controllers.md)。

明确写出评估结果，然后仅根据包含的路径生成最终计划：

**示例**——针对请求“添加一个分页端点，返回某个客户的所有订单，包含订单项和产品名称”：

Path evaluation:

路径评估：

  • Fetch project summary: INCLUDE — need Spring Boot version and module structure
  • Detect persistence stack: INCLUDE — entity-touching paths selected and stack unknown from conversation
  • List domain entities: SKIP — Order, Customer, OrderItem, Product are predictable from the request
  • List REST endpoints: INCLUDE — need to check if an orders endpoint already exists
  • Get entity description: INCLUDE — need Order, OrderItem, Product fields for response DTO design
  • Get deep model: SKIP — relationship structure is clear: Order → OrderItem → Product
  • Get DDD model: SKIP — no cascade planning needed, just a read endpoint
  • Get entity repositories: INCLUDE — need to verify OrderRepository exists and supports pagination
  • Get entity components: SKIP — repositories are sufficient, no need for full component chain
  • Get entity services: SKIP — no service layer changes expected
  • Get entity mappers: INCLUDE — need to know if OrderMapper already exists before creating DTOs
  • Get entity DTOs: INCLUDE — need to know if OrderDto already exists
  • Get entity controllers: SKIP — will check via "List REST endpoints" instead
  • 获取项目摘要：包含——需要Spring Boot版本和模块结构
  • 检测持久化栈：包含——已选择涉及实体的路径，且对话中未知栈类型
  • 列出领域实体：跳过——可从请求中预判Order、Customer、OrderItem、Product
  • 列出REST端点：包含——需要检查是否已存在订单相关端点
  • 获取实体描述：包含——需要Order、OrderItem、Product的字段以设计响应DTO
  • 获取深度模型：跳过——关系结构明确：Order → OrderItem → Product
  • 获取DDD模型：跳过——无需级联规划，仅需一个读取端点
  • 获取实体仓库：包含——需要验证OrderRepository是否存在并支持分页
  • 获取实体组件：跳过——仅需仓库，无需完整组件链
  • 获取实体服务：跳过——预计无需修改服务层
  • 获取实体映射器：包含——在创建DTO前需要了解OrderMapper是否已存在
  • 获取实体DTO：包含——需要了解OrderDto是否已存在
  • 获取实体控制器：跳过——将通过“列出REST端点”检查

Exploration plan:

探索计划：

  1. Fetch project summary
  2. Detect persistence stack
  3. List REST endpoints (filter to order-related controllers)
  4. Get entity description for Order, OrderItem, Product
  5. Get entity repositories for Order
  6. Get entity mappers for Order
  7. Get entity DTOs for Order

---
  1. 获取项目摘要
  2. 检测持久化栈
  3. 列出REST端点（过滤订单相关控制器）
  4. 获取Order、OrderItem、Product的实体描述
  5. 获取Order的实体仓库
  6. 获取Order的实体映射器
  7. 获取Order的实体DTO

---

Step 2 — Load references

步骤2 — 加载参考文档

Tell the user: 
Step 2/6: Loading relevant references...
Do NOT call any tools in this step.
Based on the exploration plan from step 1, load only the references needed for the selected paths that have not already been loaded in this conversation. After loading, proceed directly to step 3 — do NOT search files, glob, or explore the project structure manually. All project information must be obtained exclusively via MCP tools in steps 3–5.
Selected pathReference to load
Get entity description (JPA)
references/entity-description.md
Get entity description (JDBC)
references/entity-description-jdbc.md
Get deep model from entity
references/deep-model-based-on-jpa.md
Get DDD model from entity
references/ddd-model-based-on-jpa.md
Get entity repositories
references/entity-repositories.md
Get entity components
references/entity-components.md
Get entity services
references/entity-services.md
Get entity mappers
references/entity-mappers.md
Get entity DTOs
references/entity-dtos.md
Get entity controllers
references/entity-controllers.md
If none of the paths require references — skip this step and proceed to step 3.
告知用户：
Step 2/6: 加载相关参考文档中...
本步骤请勿调用任何工具。
基于步骤1的探索计划，仅加载所选路径需要的、且当前对话中尚未加载的参考文档。加载完成后直接进入步骤3——请勿手动搜索文件、匹配路径或探索项目结构。所有项目信息必须在步骤3–5中通过MCP工具获取。
所选路径需加载的参考文档
获取实体描述（JPA）
references/entity-description.md
获取实体描述（JDBC）
references/entity-description-jdbc.md
从实体获取深度模型
references/deep-model-based-on-jpa.md
从实体获取DDD模型
references/ddd-model-based-on-jpa.md
获取实体仓库
references/entity-repositories.md
获取实体组件
references/entity-components.md
获取实体服务
references/entity-services.md
获取实体映射器
references/entity-mappers.md
获取实体DTO
references/entity-dtos.md
获取实体控制器
references/entity-controllers.md
如果没有路径需要参考文档——跳过本步骤直接进入步骤3。

Step 3 — Build unified exploration plan

步骤3 — 构建统一探索计划

Tell the user: 
Step 3/6: Building exploration plan...
Do NOT call any tools in this step.
Using the selected paths from step 1 and the processes described in the loaded references, build a single unified numbered plan of MCP calls to execute in steps 4–5. Each item must be a concrete MCP tool call, not a category name.
undefined
告知用户：
Step 3/6: 构建探索计划中...
本步骤请勿调用任何工具。
使用步骤1中选择的路径以及已加载参考文档中描述的流程，构建一个统一的、编号的MCP调用计划，将在步骤4–5中执行。每个条目必须是具体的MCP工具调用，而非类别名称。
undefined

Unified exploration plan:

统一探索计划：

  1. get_project_summary
  2. list_project_endpoints
  3. list_all_domain_entities (regexPattern=Owner) — resolve FQN
  4. get_entity_details (Owner FQN)
  5. get_entity_details (Pet FQN)
  6. get_entity_details (Visit FQN)
  7. list_entity_repositories (Owner FQN)
  8. list_entity_repositories (Pet FQN)
  9. list_entity_repositories (Visit FQN)

---
  1. get_project_summary
  2. list_project_endpoints
  3. list_all_domain_entities (regexPattern=Owner) — 解析FQN
  4. get_entity_details (Owner FQN)
  5. get_entity_details (Pet FQN)
  6. get_entity_details (Visit FQN)
  7. list_entity_repositories (Owner FQN)
  8. list_entity_repositories (Pet FQN)
  9. list_entity_repositories (Visit FQN)

---

Step 4 — Execute exploration plan via subagent

步骤4 — 通过子代理执行探索计划

Tell the user: 
Step 4/6: Executing exploration plan...
Spawn a subagent and pass it the following instructions:
Execute the exploration plan below by calling each MCP tool in order.
Use MCP tools directly (e.g. get_entity_details, list_entity_repositories).

Collect and return ALL results in full — do not summarize or truncate.

Secret redaction: if any returned value belongs to a key that looks like a credential
(`password`, `passwd`, `secret`, `token`, `api-key`, `apikey`, `access-key`, `private-key`,
`credentials`, `client-secret`, `auth`, or similar), replace only the value with `[REDACTED]`
and keep the key and surrounding structure intact. Never echo credential values verbatim.

Plan:
<paste the numbered plan from step 3 here>
Wait for the subagent to complete and collect all results before proceeding.
告知用户：
Step 4/6: 执行探索计划中...
生成一个子代理并传递以下指令：
按顺序调用每个MCP工具，执行下方的探索计划。
直接使用MCP工具（例如get_entity_details、list_entity_repositories）。

完整收集并返回所有结果——请勿总结或截断。

敏感信息脱敏：如果返回值属于类似凭证的键（`password`、`passwd`、`secret`、`token`、`api-key`、`apikey`、`access-key`、`private-key`、`credentials`、`client-secret`、`auth`或类似），仅将值替换为`[REDACTED]`，保留键和周围结构不变。切勿直接输出凭证值。

计划：
<粘贴步骤3中的编号计划>
等待子代理完成并收集所有结果后再继续。

Step 5 — Build exploration report

步骤5 — 构建探索报告

Tell the user: 
Step 5/6: Building exploration report...
Do NOT call any tools in this step — reason only from subagent results.
Synthesize all findings collected across all exploration cycles into a single report. Include only what is genuinely valuable for the task — omit noise and obvious defaults.
Structure:
undefined
告知用户：
Step 5/6: 构建探索报告中...
本步骤请勿调用任何工具——仅基于子代理的结果进行推理。
将所有探索周期收集到的发现整合为一份报告。仅包含对任务真正有价值的内容——省略冗余信息和明显的默认配置。
结构：
undefined

Exploration Report

探索报告

Stack: Java 21 · Spring Boot 3.x · Maven Persistence: JPA <!-- JPA · JDBC · none — required when any entity-touching path ran -->
Domain model:
  • Order (id, status, totalAmount) → has many OrderItem → references Product
  • Customer (id, name, email)
Repositories:
  • OrderRepository — extends JpaRepository, supports pagination
  • CustomerRepository — extends JpaRepository
Services:
  • OrderService — handles order creation and status transitions
Mappers:
  • OrderMapper (MapStruct) — maps Order ↔ OrderDto
DTOs:
  • OrderDto, OrderItemDto — already exist
REST API (relevant endpoints):
  • GET /orders — paginated list
  • POST /orders — create order
Notable findings:
  • SecurityConfig present — all endpoints require authentication
  • No mapper for Customer — will need to create one

---
技术栈： Java 21 · Spring Boot 3.x · Maven 持久化： JPA <!-- JPA · JDBC · none — 当执行任何涉及实体的路径时必填 -->
领域模型：
  • Order (id, status, totalAmount) → 包含多个OrderItem → 关联Product
  • Customer (id, name, email)
仓库：
  • OrderRepository — 继承JpaRepository，支持分页
  • CustomerRepository — 继承JpaRepository
服务：
  • OrderService — 处理订单创建和状态转换
映射器：
  • OrderMapper (MapStruct) — 映射Order ↔ OrderDto
DTO：
  • OrderDto、OrderItemDto — 已存在
REST API（相关端点）：
  • GET /orders — 分页列表
  • POST /orders — 创建订单
重要发现：
  • 存在SecurityConfig — 所有端点需要认证
  • 无Customer映射器 — 需要创建一个

---

Step 5.5 — Formulate implicit assumptions

步骤5.5 — 明确隐含假设

Tell the user: 
Step 5.5/6: Formulating implicit assumptions...
Do NOT call any tools in this step — reason only from subagent results and the user's request.
Based on the exploration report and the user's request, identify everything the user did not explicitly say but likely expects from the implementation. These are implicit assumptions — unstated requirements, conventions, and design decisions the user probably takes for granted.
Focus on:
  • Behavioral expectations — e.g. "user probably expects soft delete, not hard delete", "pagination assumed to be offset-based"
  • Security/access control — e.g. "endpoint likely should require authentication like all others in this project"
  • Validation — e.g. "fields like email and price are likely expected to be validated"
  • Error handling — e.g. "returning 404 on missing entity is likely expected, not 500"
  • Conventions — e.g. "response format likely expected to match existing endpoints (camelCase, wrapped in data field)"
  • Related side effects — e.g. "creating an order probably expected to update inventory or send a notification"
  • DTO shape — e.g. "response probably expected to include nested items, not just IDs"
Output all assumptions explicitly so they can be validated or corrected:
undefined
告知用户：
Step 5.5/6: 明确隐含假设中...
本步骤请勿调用任何工具——仅基于子代理的结果和用户的请求进行推理。
基于探索报告和用户的请求，找出用户未明确说明但可能期望实现的内容。这些是隐含假设——用户可能视为理所当然的未声明需求、约定和设计决策。
重点关注：
  • 行为预期——例如“用户可能期望软删除而非硬删除”、“分页默认应为基于偏移量的”
  • 安全/访问控制——例如“端点可能需要像项目中其他所有端点一样进行认证”
  • 验证——例如“email和price等字段可能需要验证”
  • 错误处理——例如“实体不存在时应返回404而非500”
  • 约定——例如“响应格式应与现有端点一致（驼峰命名、包裹在data字段中）”
  • 相关副作用——例如“创建订单可能需要更新库存或发送通知”
  • DTO结构——例如“响应应包含嵌套的订单项，而非仅ID”
明确输出所有假设，以便验证或修正：
undefined

Implicit assumptions:

隐含假设：

  1. The new endpoint should require authentication — all existing endpoints use SecurityConfig with auth required.
  2. Response format should match existing endpoints — camelCase JSON, no wrapper object.
  3. Pagination is expected to be offset-based (Pageable) — consistent with other list endpoints.
  4. Missing entity should return 404, not 500 — standard REST convention followed elsewhere.
  5. Price field is expected to be validated as positive — consistent with other monetary fields in the domain.
  6. OrderItem list in response should include product name and quantity — implied by "order details" framing.

If no implicit assumptions can be identified — state that explicitly:
  1. 新端点需要认证——所有现有端点都使用要求认证的SecurityConfig。
  2. 响应格式应与现有端点一致——驼峰命名JSON，无包装对象。
  3. 分页应为基于偏移量的（Pageable）——与其他列表端点一致。
  4. 实体不存在时返回404而非500——遵循其他地方使用的标准REST约定。
  5. Price字段应验证为正数——与领域中其他货币字段一致。
  6. 响应中的OrderItem列表应包含产品名称和数量——由“订单详情”的表述隐含。

如果无法识别隐含假设——明确说明：

Implicit assumptions: none identified — the request is fully specified.

隐含假设：未识别到任何隐含假设——请求已完全明确。


---

---

Step 6 — Decide on next cycle

步骤6 — 决定是否进入下一周期

Tell the user: 
Step 6/6: Evaluating next cycle...
Do NOT call any tools in this step — reason only from subagent results.
Predict the value of an additional cycle (0–100): how critical are the remaining gaps, and are they resolvable via MCP? Show score and reasoning:
undefined
告知用户：
Step 6/6: 评估下一周期中...
本步骤请勿调用任何工具——仅基于子代理的结果进行推理。
预测额外探索周期的价值（0–100）：剩余缺口的关键程度如何，是否可通过MCP解决？展示分数和理由：
undefined

Additional cycle value: 87/100 → additional exploration cycle required.

额外周期价值：87/100 → 需要进行额外的探索周期。


**Score > 80** — go to **Step 1**. **Score ≤ 80** — stop.

**分数>80**——回到**步骤1**。**分数≤80**——停止探索。