Uses an agent team to orchestrate multiple agents (including dynamically expanded call chain tracing workers), automatically completing a full security audit of a Java Web project in 5 stages. An agent-7-x quality inspector pool is used for on-demand parallel verification, with all stages uniformly following the "complete one, verify one" pattern.
Terminology Definition
In this pipeline, "risk" refers only to the following two categories:
- Authentication risk: route has no authentication (❌) or authentication can be bypassed (🔓)
- Component vulnerability risk: component version defects matching known CVEs
The following are not within the "risk" scope of this pipeline:
- Code quality (non-standard naming, high cyclomatic complexity, etc.)
- Architecture design (lack of rate limiting, lack of logging, etc.)
- Business logic (race conditions, logic errors, etc.)
Input
User provides:
- source_path: source code directory path
- output_path: output directory path (default
{source_path}_audit）
Process Overview
阶段1: 信息收集（并行）
├─ 路由提取子流程（侦查 → 并行执行 → 合并，对抗大型多模块项目漏路由）
│ ├─ agent-1-recon: 模块侦查与任务分配（不解析参数，仅切分逻辑模块） → agent-7-x 校验 → 通过后关闭
│ ├─ agent-1-1/1-2/.../1-N: /java-route-mapper 并行提取各逻辑模块路由+参数 → 每个完成后立即 agent-7-x 校验 → 通过后关闭
│ └─ agent-1-merge: 合并主索引/README，跨模块对账 → agent-7-x 校验 → 通过后关闭
├─ agent-2-auth-audit: /java-auth-audit → 路由鉴权映射 → agent-7-x 校验 → 通过后关闭
└─ agent-3-vuln-scanner: /java-vuln-scanner → 组件漏洞 → agent-7-x 校验 → 通过后关闭
↓ 上述三组全部校验通过后（agent-2/3 与路由子流程并行，路由子流程完成以 agent-1-merge 通过为准）
阶段2: 交叉筛选（并行）
├─ agent-4a-risk-classifier: 路由分级（P0/P1/P2） → agent-7-x 校验 → 通过后关闭
└─ agent-4b-vuln-aggregator: 漏洞汇总（组件漏洞+鉴权绕过） → agent-7-x 校验 → 通过后关闭
↓ 两个校验全部通过后
阶段3: 调用链追踪（分批并行）
├─ agent-5-route-tracer: 读取 P0+P1 全部高危路由（P0+P1=0 时启用 P2 兜底），分批创建追踪任务 → 通过后关闭
└─ agent-5-1/5-2/.../5-N: /java-route-tracer 并行追踪各批次路由（含鉴权风险透传） → 每个完成后立即 agent-7-x 校验 → 通过后关闭
↓ 全部 worker 校验通过后
阶段4: 漏洞深度检测（按需并行）
├─ agent-6a-sql-auditor: /java-sql-audit → SQL注入检测（含可利用前置条件） → agent-7-x 校验 → 通过后关闭
├─ agent-6b-xxe-auditor: /java-xxe-audit → XXE注入检测（含可利用前置条件） → agent-7-x 校验 → 通过后关闭
├─ agent-6c-upload-auditor: /java-file-upload-audit → 文件上传漏洞检测（含可利用前置条件） → agent-7-x 校验 → 通过后关闭
├─ agent-6d-fileread-auditor: /java-file-read-audit → 文件读取漏洞检测（含可利用前置条件） → agent-7-x 校验 → 通过后关闭
└─ agent-6e-deserialization-auditor: /java-deserialization-audit → 反序列化漏洞检测（含可利用前置条件） → agent-7-x 校验 → 通过后关闭
↓
阶段5: 汇总报告
└─ agent-7-x: 整合所有校验结果，生成最终 quality_report.md → 完成后关闭
Key design:
- Worker concurrency upper limit =
{max_concurrent_agents}(default 5, confirmed by the user at startup; valid range 2~10): the total number of workers running simultaneously at any stage (including agent-1-N, agent-3, agent-2, agent-4a/4b, agent-5-N, agent-6x) must not exceed this value.Sole exception: the lead itself and reconnaissance-type agents (agent-1-recon, agent-5-route-tracer) are not counted toward the limit (they are single-point coordinators and do not have their own concurrency contention). - Independent quality inspector pool: quality inspectors (agent-7-x)do not occupy worker slots, use an independent concurrency pool, upper limit =
ceil({max_concurrent_agents} / 2)(default 5 → 3, minimum 1, maximum 5). The lead adopts "dual-pool scheduling": the worker pool runs at full capacity with{max_concurrent_agents}workers; after any worker completes,immediately take over the output from the completed worker, spawn a replacement worker to fill the worker pool; at the same time, spawn a quality inspector on demand in the quality inspector pool to asynchronously verify that worker's output. The upper bound of total active agents in the system ≈{max_concurrent_agents} × 1.5, requiring sufficient local resources. - Complete one, verify one (asynchronous parallel): after a worker completes, it is immediately replaced,without waiting for its own verification to pass; quality inspectors verify in parallel in an independent pool, and when verification fails, the item is recorded in a rework list,without blocking the main queue from advancing. Before each stage enters the next stage, the following must be satisfied: (a) all workers in this stage have completed; (b) the quality inspector pool is empty (all verifications completed); (c) the rework list is empty (failed workers have been rerun and passed re-verification).
- Each agent is closed immediately after passing verification to release resources; quality inspectors are closed when there are no pending verification tasks in the current stage, and are respawned on demand in the next stage.
- Resource-constrained degradation: if at startup
max_concurrent_agents≤ 3, the QA pool upper limit degenerates to 1, and it switches to "semi-synchronous" mode—the worker pool retains{max_concurrent_agents} - 1slots for workers, and 1 slot rotates to QA (to avoid the two pools competing for resources at extremely low concurrency).
Execute instructions
Team lead responsibilities
- Parse the user-input source_path and output_path
- Ask for startup parameters (must be completed before creating any agent):
max_concurrent_agents(global concurrency upper limit): default value 5, valid range 210. Example prompt: "Please enter the upper limit on the number of concurrent agents (default 5, recommended 210; if local resources are tight, use 23; if the server has ample resources, use 810):" If the user presses Enter, the default 5 is used. All subsequent references to the "global concurrency upper limit" use this value.- Once this parameter is determined, write it to
{output_path}/scripts/pipeline_config.json, for reference in subsequent stages:{"max_concurrent_agents": 5, "audit_scope": "pending_recon"}
- ⚠️ Placeholder replacement rules (effective globally): When passing a prompt to any agent, you must replace in the templateallplaceholders (
{source_path}、{output_path}、{project_name}、{batch_id}、{batch_content}、{max_concurrent_agents}etc.) with actual values.It is forbidden to pass unreplaced{xxx}placeholders to sub-agents. - Create the output directory structure (create all subdirectories at once, including the routing subprocess's
.status/anddecompiled/cache/）：
After recon QA passes, the leadadditionally executes: according tomkdir -p {output_path}/route_mapper/.status {output_path}/auth_audit {output_path}/vuln_report {output_path}/cross_analysis {output_path}/route_tracer {output_path}/sql_audit {output_path}/xxe_audit {output_path}/file_upload_audit {output_path}/file_read_audit {output_path}/deserialization_audit {output_path}/decompiled/cache {output_path}/scripts {output_path}/qa_reports_recon_{ts}.mdtask allocation table, pre-create for each agent-1-N{output_path}/route_mapper/{module_name}/and{output_path}/decompiled/agent-1-{N}/. Workers must not create directories other than their own module directory. - Create agent team
- Use TaskCreate to create tasks and set dependencies (⚠️
task-1.Nitems expressed as N, such as , aredynamically expanded templates, and N is determined only after recon QA passes; the lead expands according to_recon_{ts}.mdintotask-1-1 / task-1-1q / task-1-2 / task-1-2q / ...specific tasks,task-1.mdepends onall task-1-{N}q passingrather than worker completion):
task-1.0: agent-1-recon 路由侦查与任务分配 (pending)
task-1.0q: agent-7-x 校验 agent-1-recon (blockedBy: [1.0], 分配给空闲检员)
task-1.N: agent-1-1/.../1-N 并行路由提取 + 逐个校验 (blockedBy: [1.0q], 每个 worker 完成后立即由 agent-7-x 校验，通过后关闭该 worker)
task-1.m: agent-1-merge 合并主索引 (blockedBy: [1.N])
task-1.mq: agent-7-x 校验 agent-1-merge (blockedBy: [1.m], 分配给空闲检员)
task-2: agent-2-auth-audit 鉴权检查 (blockedBy: [1.mq]) # 依赖 merge 通过，保证鉴权映射对账目标稳定
task-3: agent-3-vuln-scanner 组件漏洞扫描 (pending)
task-5: agent-7-x 校验 agent-2 (blockedBy: [2], 分配给空闲检员)
task-6: agent-7-x 校验 agent-3 (blockedBy: [3], 分配给空闲检员)
task-7: agent-4a-risk-classifier 无鉴权路由分级 (blockedBy: [1.mq,5,6])
task-8: agent-4b-vuln-aggregator 漏洞汇总 (blockedBy: [1.mq,5,6])
task-9: agent-7-x 校验 agent-4a (blockedBy: [7], 分配给空闲检员)
task-10: agent-7-x 校验 agent-4b (blockedBy: [8], 分配给空闲检员)
task-11: agent-5-route-tracer 路由分批与调度 (blockedBy: [9,10])
task-12: agent-5-N 并行调用链追踪 + 逐个校验 (blockedBy: [11], 每个 worker 完成后立即由 agent-7-x 校验，通过后关闭该 worker)
task-13: 负责人汇总阶段3覆盖率 (blockedBy: [12], 全部 worker 校验通过后计算追踪覆盖率)
task-14: agent-6a-sql-auditor SQL注入检测 (blockedBy: [13], 按需启动)
task-15: agent-6b-xxe-auditor XXE注入检测 (blockedBy: [13], 按需启动)
task-16: agent-6c-upload-auditor 文件上传漏洞检测 (blockedBy: [13], 按需启动)
task-17: agent-6d-fileread-auditor 文件读取漏洞检测 (blockedBy: [13], 按需启动)
task-17e: agent-6e-deserialization-auditor 反序列化漏洞检测 (blockedBy: [13], 按需启动)
task-18: agent-7-x 逐个校验 agent-6x (每个 agent-6x 完成后立即由空闲检员校验，通过后关闭)
task-19: agent-7-x 最终汇总 quality_report.md (blockedBy: [18], 仅等待实际启动的 agent-6x 全部校验通过)
- Stage 1 scheduling：
- 7.1 Startup: start in parallel
agent-1-recon、agent-3-vuln-scanner；agent-2-auth-auditdepends onagent-1-mergestart after validation passes(to ensure the authentication mapping reconciliation target is stable; see 7.5 below for details) - 7.2 Routing subprocess：
agent-1-reconcompletes → spawn QA as needed to validate the reconnaissance report (full module set reconciliation, SKIP reasons, agent allocation coverage, mandatory exclusive rules) → close recon after passing- 7.2a User audit scope confirmation (must be executed after recon QA passes and before workers start)：
- The lead reads
_recon_{recon_id}.md's "Layer 1: Physical Module List" table, presents the following information to the user, and asks about the audit scope:=== 已识别物理模块 === 编号 模块名 路径 类型 框架 预估路由 状态 1 admin webapps/admin WAR Struts2+Spring ~150 待审计 2 biz webapps/biz WAR Struts2 ~600 待审计 3 ROOT webapps/ROOT SKIP - 0 已跳过(static_assets) 4 upload webapps/upload SKIP - 0 已跳过(file_storage) 请输入要排除的模块编号（多个用逗号分隔，如 "2"；直接回车 = 全部审计）： - Granularity constraint: only WAR-type physical modules may be excluded; SKIP modules are not audited anyway;route-level, namespace-level, or package-prefix-level filtering is not accepted(preserve the integrity of the agent-2/4a/5 intelligent grading mechanism)
- User input parsing:
- Enter / empty input → audit all (default)
- Number list → mark the corresponding modules as
SKIP，skip_reason="user_exclusion", and remove the corresponding agent-1-N from the task assignment table - Input out of range or non-numeric → report an error and ask again; after at most 2 retries, conservatively handle as "audit all"
- OwnerUpdate in place
_recon_{recon_id}.md：- In the Layer 1 module list, for excluded modules, the
skip_reasoncolumn is filled withuser_exclusion - In the Agent task assignment table, delete the corresponding agent-1-N row (renumber consecutively), and append a section at the end of the file
## 用户审计范围确认, recording the original N value, exclusion list, and confirmation timestamp
- In the Layer 1 module list, for excluded modules, the
- Update pipeline_config.json: write the
audit_scopefield, for example{"max_concurrent_agents": 5, "audit_scope": {"included": ["admin"], "excluded": ["biz"], "user_confirmed_at": "ISO8601"}} - Restart recon QA for one review (on the modified recon sheet); only after passing does it proceed to the next step
- The lead reads
- The owner pre-creates a module output directory and an exclusive decompilation directory for each agent-1-N：
mkdir -p {output_path}/route_mapper/{module_name} {output_path}/decompiled/agent-1-{N} - The owner reads the "Agent Task Assignment" table of
{output_path}/route_mapper/_recon_{recon_id}.md(recon_id is generated by recon and is unique), and according to the agent_id and module list in the tableDual-pool scheduling spawns in parallelagent-1-1、agent-1-2、…、agent-1-N：- Worker pool: always maintain
{max_concurrent_agents}agent-1-N workers running simultaneously (spawn all{max_concurrent_agents}at once in the first batch, then immediately spawn the next candidate each time one completes) - QA pool: runs independently, with an upper limit of
ceil({max_concurrent_agents} / 2); whenever a worker completes, assign an idle QA to verify its output (if all are busy, queue and wait,the worker pool continues to advance without waiting） - The owner itself does not occupy a slot in either pool; agent-2/3 have not yet started at this time (agent-2 depends on merge), agent-3 exclusively occupies 1 worker slot (sharing the worker pool with this sub-process; the actual number of workers available to the routing sub-process =
{max_concurrent_agents} - 1） - Each worker calls
/java-route-mapperbut only processes the list of module paths it is responsible for
- Worker pool: always maintain
- Verification failure handling: worker outputs that fail QA verification are added to the "rework list", recording the failure reason; the current wave's main queuecontinues to advance without blocking; after that worker closes, when the worker pool has an empty slot, the owner respawns a worker with the same agent_id to rerun (rerun count ≤ 2; if exceeded, stop the pipeline for manual intervention)
- All workers complete + QA pool empty + rework list empty → start
agent-1-mergemerge the main index → close after QA verification passes
- 7.3 agent-3: immediately after completion, verify by an idle QA; close after passing
- 7.4 agent-2 startup：
agent-1-mergeAfter verification passes, start agent-2-auth-audit; immediately after agent-2 completes, close it and have the QA pool verify asynchronously - 7.5 Enter Phase 2: all workers in the routing sub-process complete + QA pool empty + rework list empty, and both agent-3 and agent-2 have completed and passed verification → close this phase's QA and start in parallel
agent-4aandagent-4b - 7.6 Degradation strategyIf recon QA has cumulatively failed ≥ 2 times,do not degrade to single-agent mode(this would reintroduce the missed-routing problem in large projects); instead switch to "conservative splitting" — one worker per WAR, one worker per
struts-*.xmlone worker per WS endpoint, and split Spring by controller package prefix; if conservative splitting still cannot confirm the full set,stop the pipeline and require manual confirmation, and do not proceed to downstream
- 7.1 Startup: start in parallel
- Phase 2 scheduling: once agent-4a and agent-4b each complete, they are immediately verified by an idle verifier; after both pass, start agent-5-route-tracer (dispatcher)
- Phase 3 scheduling: after agent-5 completes in batches, the leaddual-pool scheduling spawns agent-5-1/5-2/.../5-N for parallel tracing: the worker pool maintains
{max_concurrent_agents}agent-5-N instances (agent-5-route-tracer does not count toward slots); the verifier pool cap isceil({max_concurrent_agents} / 2)for asynchronous verification; when a worker completes it is immediately replaced without waiting for verification. Failed workers are added to the rework list (≤ 2 reruns); when all workers are complete + the verifier pool is empty + the rework list is empty → the lead summarizes coverage - Phase 4 scheduling: the lead reads the call chain report and starts agent-6x by sink type with dual-pool scheduling (worker pool cap
{max_concurrent_agents}, verifier pool capceil({max_concurrent_agents} / 2)); when a worker completes it is immediately replaced without waiting for verification; agent-6x with no corresponding sink is skipped and directly marked completed.agent-6e-deserialization-auditorstartup condition is: the call chain report containsDESERIALIZEsink, orvuln_report/cross_analysis/component_vulnerabilities.mdmatches deserialization-related components such as Fastjson, XStream, Shiro RememberMe, Log4j/JNDI, JDBC, CommonsCollections, etc. - Verifier pool scheduling strategy：
- Independent pool operation: the verifier pool and the worker poolrun concurrently without occupying each other's slots, verifier pool cap =
ceil({max_concurrent_agents} / 2)(default 5 → 3) - Create on demand: only after an agent completes is a verifier spawned to verify that agent's output; do not pre-create in batches ahead of time
- Verifier naming rules:
agent-7-{序号}, the sequence number starts at 1 and increments; numbering can be reused across phases - When there is a new verification need, prioritize assigning it to an existing idle verifier; if all are busy and the pool cap has not been reached, spawn a new verifier; when the pool is full, new verification tasks enter a waiting queue
- All verifiers have identical capabilities and consistent verification standards
- After all verifications for the current phase are complete and the waiting queue is empty, close that phase's verifiers; the next phase re-spawns on demand
- Resource-constrained degradation: if
{max_concurrent_agents}≤ 3, the verifier pool cap is fixed at 1, and the mode changes to "semi-synchronous" (worker pool{max_concurrent_agents} - 1slots, with the verifier occupying the last 1 slot) to avoid the two pools competing for resources
- Agent lifecycle management：
- After each agent completes its task, it is immediately closed to release the worker pool slot (without waiting for its own verification to pass); the lead uses the SendMessage tool to send
type: "shutdown_request"to that agent - The lead waits for the agent's response
type: "shutdown_response", confirming the agent has closed - If no response is received within 30 seconds, log a warning and continue the subsequent process (to avoid blocking)
- Worker outputs that fail validation are added to the "rework list", and when a slot in the worker pool is free, the same agent_id is respawned (≤ 2 times); after a successful rerun, it is removed from the rework list
- agent-7-x quality inspector shuts down after all validations in the current stage are complete and the waiting queue is empty; it is respawned on demand in the next stage
- Hard constraints for entering the next stage: all workers in this stage complete + quality inspector pool empty + rework list empty (all three satisfied simultaneously)
General execution requirements (passed to each agent)
执行要求：
1. 输出目录已由负责人预先创建，禁止自行创建或修改目录结构，直接写入指定目录
2. 先扫描源代码目录结构，识别项目的模块组成、技术栈和代码分布
3. 根据扫描结果，使用 TaskCreate 自行规划详细的 todo 子任务列表
4. 按照你规划的任务列表逐项执行，每完成一项用 TaskUpdate 标记为 completed
5. 全部完成后，自查输出文件的完整性和数量，确认无遗漏后通知团队负责人
6. **生命周期管理**：
- 完成任务并通知负责人后，等待负责人发送的 shutdown_request
- 收到 shutdown_request 后：
a. 确认所有输出文件已写入磁盘
b. 清理临时资源（如有）
c. 使用 SendMessage 发送 type: "shutdown_response" 给负责人
d. 停止运行
全程自主规划、自主执行，无需等待确认。
Agent detailed instructions
Agent-1-recon: Route Reconnaissance Agent (route extraction and allocation agent)
Purpose: To counter the issue of missed routes when a single agent scans large multi-module projects (multiple WARs / Maven multi-submodules / giant Struts projects) serially. The recon agent does not parse parameters; it only splits logical modules and produces task allocation sheets.
角色: agent-1-recon (路由侦查员)
源代码: {source_path}
输出目录: {output_path}/route_mapper/（已创建，直接写入侦查单 + .status/ 状态目录骨架；侦查员**不得**预创建各 `{module_name}/` 子目录，那是负责人在 QA 通过后按分配单创建）
反编译输出目录: {output_path}/decompiled/（已创建，仅本侦查阶段如需小规模反编译可写入 decompiled/cache/，正式 worker 阶段每个 worker 独占 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本必须写入此目录，禁止 /tmp）
任务: 扫描源码，按框架感知切分「物理模块（WAR/子模块）→ 逻辑模块（Struts namespace / Spring 路径前缀 / WS endpoint）」，按分配规则产出任务分配单
Reconnaissance execution steps
-
Coarse scan of physical modules (must list the complete set)
# 全集锚点（一级子目录全集，必须 ls 一次并粘贴原始输出到侦查单） ls -1 {source_path}/webapps/ 2>/dev/null || ls -1 {source_path}/ # WAR / Web 模块锚点（同时覆盖：① 部署形态 webapps/*/WEB-INF；② Maven 源码形态 **/src/main/webapp/WEB-INF；③ 显式打包为 war 的 pom） # ⚠️ 不要加 -maxdepth，否则 module/src/main/webapp/WEB-INF（深度=5+）会被漏掉 find {source_path} -name WEB-INF -type d -not -path '*/target/*' -not -path '*/build/*' grep -rl '<packaging>war</packaging>' {source_path} --include=pom.xml 2>/dev/null"complete set - WAR subset" must == the module names of all SKIP rows in the table (diff is empty). The raw output of all three commands must be pasted into the reconnaissance sheet.
-
Split logical modules module by module according to the framework
Framework Basis for splitting Anchor command Struts2 multiple struts-*.xml Each sub-configuration file → 1 logical module ls {WEB-INF/classes}/struts*.xml; ls {WEB-INF/classes}/struts/*.xmlStruts2 single file with multiple namespaces Cluster by <package namespace>clusteringgrep -E 'namespace=' {struts.xml}Spring MVC Cluster by @RequestMappingclass prefix (/admin/**、/api/**)grep -rE '@(Controller|RestController|RequestMapping)' --include=*.java --include=*.classJAX-RS / CXF Cluster by @Pathclass prefix /<jaxws:endpoint>Parse cxf-servlet.xml、applicationContext*.xmlServlet Cluster by web.xmlof<servlet-mapping>url-pattern prefixParse web.xml -
Estimate the number of routes for each logical module (count only, do not parse parameters)
- Struts2:
grep -c '<action ' {struts子配置} - Spring MVC:
grep -c '@\(Get\|Post\|Put\|Delete\|Request\)Mapping' {目标包} - JAX-RS:
grep -c '@Path' {目标包} - Conservative upper bound for wildcards: if the module contains Struts2
*_*/executeInterface/ reflective dispatch, the estimated value is changed toclass_count × avg_method_count(estimate class_count viafind {pkg} -name '*.class' | wc -l; take 8 as the conservative average method count), and mark "wildcard upper-bound estimate" in the remarks column. Anyupper bound ≥ 150 module is automatically listed as mandatory exclusive; small wildcard modules with an upper bound < 150 are allowed to participate in merging with small modules of the same framework (after merging, the total upper bound for a single agent is ≤ 150).
- Struts2:
-
Generate the Agent task allocation sheet according to the allocation rules
Execution order (mandatory, no skipping steps):
- Wheneverthe estimated routes of a layer-1 physical module > 150, the layer-2 logical module drill-down must first be completed (expand into namespace / package prefix / endpoint-level entries according to the "Split logical modules module by module according to the framework" table above);physical modules that have not been drilled down are prohibited from directly entering the allocation rules of this step。
- The decision unit of the allocation rules is the **"logical module"** (namespace / package prefix / endpoint / single file), not the physical module (WAR / submodule).
- Only when the physical module as a whole has ≤ 150 routes and no wildcards may the shortcut of "give the entire WAR to 1 agent" be used (without drill-down).
Allocation rules (mandatory):
- Single logical module ≥ 150 routes → exclusively occupies 1 agent
- Contains wildcard /
executeInterface/ Struts2*_*dual wildcard → Determine based on the wildcard upper-bound estimate: upper bound ≥ 150 → forced exclusive occupancy; upper bound < 150 → allowed to merge with small modules of the same framework (after merging, total upper bound ≤ 150)- ⚠️ The granularity of "forced exclusive occupancy" is the "logical module" level; it is prohibited to elevate this to the "physical module (WAR)" level. Even if a WAR contains a namespace with wildcards, only that namespace is allowed to exclusively occupy 1 agent; the remaining namespaces are still allocated individually per this rule, and it is prohibited to have the entire WAR handled by 1 agent on the grounds that "the WAR contains wildcards".
- Counterexample (prohibited): a certain WAR contains N namespaces, some of which contain
*_*→ the entire WAR is exclusively occupied by 1 agent. - Correct example (required): that WAR → expand at layer 2 into N namespace logical modules → wildcard namespaces with upper bound ≥ 150 each exclusively occupy one, small wildcard namespaces with upper bound < 150 merge with other small modules, and the rest follow the merge/exclusive rules → produce agent-1-1 ~ agent-1-N.
- The real purpose of this rule:The number of wildcard routes cannot be statically and precisely estimated(using
class_count × 8upper bound), when the upper bound ≥ 150 a single agent is prone to overload (approaching the 200 hard upper bound), so exclusive occupancy is forced; when the upper bound < 150 the merge risk is controllable. It is not "avoiding cross-agent coordination of wildcards".
- Small modules of the same framework (< 80 routes) may be merged into one agent, with total routes per agent ≤ 150
- Hard upper bound on the number of routes handled by a single agent = 200(including the wildcard upper-bound estimate). If in any allocation plan an agent's estimated routes > 200, it must continue to be further split into ≥ 2 agents by namespace / package prefix / endpoint, and it is prohibited to keep the entire module handled by a single agent on the grounds that "the module as a whole is strongly related". This upper bound covers all allocation results at layer 1 and layer 2; any violation is deemed a failure of the reconnaissance ticket
- Overall WAR routes ≤ 150 and no wildcards → assign the whole WAR to 1 agent
- Two preconditions for a whole WAR being handled by a single agent(both must be satisfied, neither can be missing): (a) the physical module's estimated routes ≤ 150; (b) the physical modulecompletely contains nowildcard /
executeInterface/ reflective dispatch. If either is not satisfied, the whole WAR by a single agent is prohibited, and it must drill down to layer 2 and then be reallocated per this rule - WebService (JAX-WS / CXF / Axis endpoint) is treated as an ordinary logical module, with an independent agent_id, and the output directory named
route_mapper/{war_name}_ws_{service_name}/, written by that worker itself; do not reserve a sharedwebservice/directory, to avoid conflicts from multiple workers writing to the same directory - Pure static / file_storage / empty directory → SKIP (only registered in the main index, no agent allocated, skip_reason must be filled in)
agent_id naming (mandatory):
agent-1-{序号}, with the sequence number increasing consecutively starting from 1 (e.g.,agent-1-1、agent-1-2, ...). It is prohibited to useagent#1、agent_1and other such forms.recon_id (mandatory): file name format
_recon_{YYYYMMDDHHMMSS}_{8位随机hex}.md(precision to the second + random suffix, to avoid collisions on reruns); when multiple_recon_*.mdappear in the same directory, merge Only the latest one may be used(sorted by the filename time field, and it must be consistent with the worker.status/*.jsonin therecon_idfield).
Output: Task Assignment Sheet {output_path}/route_mapper/_recon_{YYYYMMDDHHMM}.md
# 路由侦察与任务分配单
项目: {project}
生成时间: {timestamp}
## 锚点命令原始输出（禁止改写）
```
$ ls -1 {webapps_path}/
{原样输出}
$ find {source_path} -name WEB-INF -type d
{原样输出}
```
## 第 1 层：物理模块清单（必须 == ls 全集）
| # | 模块 | 路径 | 类型 | 主框架 | 配置文件 | 预估路由 | 源码形态 | skip_reason |
|---|------|------|------|------|--------|--------|--------|------------|
| 1 | admin | webapps/admin | WAR | Struts2+Spring | struts.xml, applicationContext.xml | ~150 | .class | - |
| 2 | biz | webapps/biz | WAR | Struts2 | struts/*.xml (8 个) | ~600 | .class | - |
| 3 | ROOT | webapps/ROOT | SKIP | - | - | 0 | 静态 JSP | static_assets_no_WEB-INF |
| 4 | upload | webapps/upload | SKIP | - | - | 0 | - | file_storage |
## 第 2 层：逻辑模块（仅对预估路由 > 150 的物理模块下钻）
| 父模块 | 逻辑模块 | 识别依据 | 预估路由 | 含通配符 |
|--------|---------|---------|--------|---------|
| admin | /device | Struts2 namespace=/device | 60 | 否 |
| admin | /channel | Struts2 namespace=/channel | 50 | 否 |
| admin | WS:UserSvc | jaxws endpoint | 40 | 否 |
| biz | struts-modA | struts/struts-modA.xml | 80 | 是 |
| biz | struts-modB | struts/struts-modB.xml | 70 | 否 |
| biz | struts-core | struts/struts-core.xml | 90 | 否 |
| ... | | | | |
## Agent 任务分配
| Agent ID | 处理模块 | 模块路径列表 | 预估路由 | 输出目录 | 备注 |
|-------------|---------|-------------|--------|---------|------|
| agent-1-1 | admin/device + admin/channel + admin/WS:UserSvc | webapps/admin/WEB-INF/classes/{device,channel,ws} | 150 | route_mapper/admin/ | 同 WAR 内合并 |
| agent-1-2 | biz/struts-modA | biz/WEB-INF/classes/modA 包 | 80 | route_mapper/biz_modA/ | 含通配符，独占 |
| agent-1-3 | biz/struts-modB | biz/WEB-INF/classes/modB 包 | 70 | route_mapper/biz_modB/ | 独占 |
| agent-1-4 | biz/struts-core | biz/WEB-INF/classes/core 包 | 90 | route_mapper/biz_core/ | 独占 |
| ... | | | | | |
| - | ROOT, upload | - | 0 | - | SKIP（skip_reason） |
总执行 agent 数: {N}
Recon Self-Check List (if it fails, entering the worker stage is prohibited; the recon agent must first self-check, and then agent-7-x reviews it)
- module list layer 1 row count ==
ls -1output row count (reconciliation of the complete set of first-level subdirectories) - all SKIP lines have non-empty
skip_reason - Task Assignment Table "Handled Modules" union == all WAR-type modules
- every WAR module has an explicit agent owner
- all modules containing wildcards / executeInterface are exclusively assigned to an agent
- the layer 2 drill-down covers all physical modules with routes > 150
- any agent in the assignment table handling routes > 100 must correspond to a layer 2 logical module row(if there is no layer 2 row, directly assigning the entire WAR to an agent is considered a failure; typical anti-pattern: 1 agent takes on all namespaces of a certain WAR)
- any agent in the assignment table is estimated to have routes ≤ 200(hard upper bound; the same applies when estimating upper bounds involving wildcards); exceeding it means failure and requires continued splitting
- "mandatory exclusivity" all occurs at the logical module level(namespace / package prefix / endpoint); there must be no row where the entire WAR is assigned to 1 agent on the grounds of "physical module containing wildcards"
Degradation strategy: if the recon self-check fails more than 1 time,degrading to single-agent mode is prohibited(the more complex the project, the more it must not fall back to a single agent, which would reintroduce the missed-route problem in large projects). Instead, use "conservative splitting": one worker per WAR, one worker per struts-*.xml , one worker per WS endpoint, and Spring split by controller package prefix; if the complete set still cannot be confirmed after conservative splitting,stop the pipelineand require manual review.
Agent-1-N: Route Extractor (Worker Template)
The person in charge generates a prompt for each worker using the following template, replacing all {source_path}、{output_path}、{project_name}、{worker_id}、{module_name}、{module_paths} with the actual values from the recon sheet (⚠️ all placeholders must be replaced):
角色: agent-1-{worker_id} (路由提取员)
技能: /java-route-mapper
源代码: {source_path}
输出目录: {output_path}/route_mapper/{module_name}/（已由负责人创建，直接写入；禁止写其他模块子目录或主索引根目录；禁止生成 java-route-mapper 的 OUTPUT_TEMPLATE_INDEX.md / 项目级 README.md，主索引由 agent-1-merge 统一生成）
反编译输出目录: {output_path}/decompiled/agent-1-{worker_id}/（已由负责人创建，独占；禁止写 decompiled/ 根目录或其他 worker 的子目录；可只读访问 decompiled/cache/ 下其他 worker 已反编译的 class，但禁止写入）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本必须写入此目录，禁止写入 /tmp 或其他临时目录）
状态文件: {output_path}/route_mapper/.status/agent-1-{worker_id}.json（完成后必须原子写入：先写 .tmp 再 mv）
recon_id: {recon_id}（侦查单文件名中的 ID，必须原样回写到 status JSON）
输入范围：
- **可写入扫描目标**：{module_paths}（仅这些模块的路由可被纳入本 worker 输出）
- **只读访问允许**：本 WAR 的 web.xml、struts.xml/struts-*.xml 主配置、applicationContext*.xml、所有公共基类（AbstractAction、BaseController 等）、依赖 jar；这些上下文必须读取以保证路由解析正确，但禁止把其他 worker 负责模块的路由写入本 worker 输出
- **禁止访问**：其他 WAR 的 WEB-INF；其他 worker 的 route_mapper 子目录
任务: 严格按 /java-route-mapper 的 CRITICAL 1~6 规则提取上述模块的全部 HTTP 路由和参数结构
强制约束（违反任一即校验失败）:
1. 输出隔离: 仅写 route_mapper/{module_name}/ 与 decompiled/agent-1-{worker_id}/，禁止写其他模块、主索引或共享 webservice/ 目录
2. 通配符强制展开: 通配符路由（Struts2 *_*、Spring 路径变量、JAX-RS @PathParam）必须穷举展开
2b. **网关方法 sub_function 强制展开**：若识别到 dispatch 模式方法（典型签名 `executeInterface(String code, String json)` / `dispatch(String action, …)` / `invoke(String type, …)`，或方法体含 `switch(code)` 链、`if-else` 字符串比对链、`Map<String, Handler>` 路由分发、反射 `Method.invoke(handlers.get(code))`），**必须穷举每个 dispatch 分支并把每个 sub_function 作为一个独立接口块输出**，每个 sub_function 占一条 `=== [N] === ` 条目，路径以 `?code={subFunctionName}` 或 `?action={subFunctionName}` 形式标注；禁止以 1 个网关方法名代表多个业务接口。状态 JSON 中此类 endpoint 必须额外提供 `sub_functions: [{"name": "...", "params": "..."}]` 数组，且 `actual_route_count` 计入每个 sub_function（即网关方法计为 N 条而非 1 条）
3. 完整输出: 禁止使用 "..."、"等"、"其他" 省略；禁止只输出"关键接口"
4. 接口块格式: 每个接口必须以独立 === [N] === 块输出，N 为该模块内连续编号
5. 主索引豁免: 不执行 java-route-mapper 中"生成主索引 / 项目级 README"的步骤；只产出本模块详情文件
6. 路由数超载自检: 实际路由数 actual_route_count 若超过侦查单预估的 1.5 倍且 > 100，立即停止写出并在 .status/ 写 status="overflow"，由负责人重新触发 recon 拆分
7. 状态汇报: 完成后写 .status/agent-1-{worker_id}.json：
{
"schema_version": 1,
"agent_id": "agent-1-{worker_id}",
"recon_id": "{recon_id}",
"module_name": "{module_name}",
"module_paths": [...],
"status": "success" | "overflow" | "failed",
"attempt": <number>, // 第几次尝试（从 1 开始）
"actual_route_count": <number>, // 必须为 JSON number，禁止 "200+" 这类字符串
"estimated_route_count": <number>, // 来自侦查单
"frameworks": [...],
"output_files": [...], // 相对 output_path 的路径
"output_file_sha256": {"file": "hash"},// 用于 merge 检测重跑
"completed_at": "ISO8601",
"error_message": null | "..."
}
8. 数字字段强类型: route_count 等数字字段禁止用字符串如 "2000+"、"50+"，不知道精确值就反编译查清楚
9. 省略词零容忍: 禁止出现 +（作数量后缀）、等、估算、潜在、大致、远超、主要方法、...略、部分
Agent-1-merge: Route Merger
角色: agent-1-merge (路由合并员)
源代码: {source_path}
输出目录: {output_path}/route_mapper/（已创建，仅写主索引 README + 跨模块统计；禁止改写任何 worker 产物）
输入: 最新一份 _recon_*.md（按文件名时间字段排序取末尾）+ 所有 .status/agent-1-*.json + route_mapper/{module_name}/ 子目录
任务:
1. 选取最新侦查单（拒绝同时存在多份且时间戳无法排序的情况，遇此停止并报错）
2. 读取 .status/ 下全部 agent-1-*.json：
- 校验 schema_version=1
- 所有 status 必须为 "success"（出现 "overflow"/"failed"/缺失即报错并停止）
- recon_id 必须全部等于步骤 1 选取的侦查单 ID（防止读到旧重跑结果）
- 所有 output_files 真实存在且 sha256 与 status 中记录一致
3. 与侦查单 Agent 分配表对账，diff 必须为空（侦查单分配的所有 agent_id 都有对应 .status/ 文件 + 对应模块子目录 + 对应 WS 子目录）
4. 生成主索引 README:
- 模块清单（与侦查单一致，含 SKIP 模块及 skip_reason）
- 每模块路由数与详情文件链接（相对路径）
- 跨模块路由总数
- WebService 索引（聚合各 worker 的 `*_ws_*` 子目录链接，不创建共享目录）
5. 生成 README 的「实际 vs 预估」对账表，actual_route_count vs estimated_route_count，偏差 > 50% 须附说明
6. 严禁修改任何 worker 的产物文件，仅写主索引
强制约束:
- 不重新扫描源码，仅基于 worker 产物聚合
- 主索引必须符合 java-route-mapper 的 OUTPUT_TEMPLATE_INDEX.md 规范
- 链接必须为子目录相对路径
Agent-2-auth-audit: Authorization Inspector
角色: agent-2-auth-audit (鉴权检查员)
技能: /java-auth-audit
源代码: {source_path}
输出目录: {output_path}/auth_audit/（已创建，直接写入）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
任务: 识别鉴权框架，检查每条路由的鉴权状态，检测鉴权绕过漏洞
Agent-3-vuln-scanner: Component Scanner
角色: agent-3-vuln-scanner (组件扫描员)
技能: /java-vuln-scanner
源代码: {source_path}
输出目录: {output_path}/vuln_report/（已创建，直接写入）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
任务: 扫描项目依赖中的已知漏洞（CVE），生成触发点检测报告
Agent-4a-risk-classifier: High-Risk Route Classifier
When the person in charge creates agent-4a, read references/agent_4a_instructions.md to obtain the complete execution steps and output template,and after replacing all placeholders such as {output_path}、{source_path} with actual values, use it as the prompt instruction for agent-4a.
Agent-4b-vuln-aggregator: Vulnerability Aggregator
When the person in charge creates agent-4b, read references/agent_4b_instructions.md to obtain the complete execution steps and output template,and after replacing all placeholders such as {output_path}、{source_path} with actual values, use it as the prompt instruction for agent-4b.
Agent-5-route-tracer: Call Chain Tracing Assigner
When the person in charge creates agent-5, read references/agent_5_instructions.md to obtain the complete execution steps, intelligent selection strategy, and output template,and after replacing all placeholders such as {output_path}、{source_path} with actual values, use it as the prompt instruction for agent-5.
The person in charge receives trace_batch_plan.md Then: close agent-5 → spawn agent-5-1~5-N in parallel (using the Worker template below) → after each worker completes, agent-7-x verifies → after all pass, aggregate coverage (>= 90%) → proceed to phase 4.
Agent-5-N-worker: Call chain tracing executor (Worker template)
The lead uses the following template for each worker to generate the prompt, replacing all of {source_path}、{output_path}、{project_name}、{batch_id} and {batch_content} with actual values (⚠️ all placeholders in the template must be replaced, none may be omitted):
角色: agent-5-{batch_id} (调用链追踪执行员)
技能: /java-route-tracer
源代码: {source_path}
输出根目录: {output_path}/route_tracer/（已创建）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
输入: 以下为你负责追踪的路由批次，来自 {output_path}/cross_analysis/trace_batch_plan.md
{batch_content}
任务: 对以上路由逐条执行调用链追踪，并在每个报告中透传鉴权风险信息
⚠️ 输出文件命名强制规范（必须严格遵守，禁止自创命名）:
- 每条路由必须先创建子目录，再在子目录内写入报告文件
- 目录结构: {output_path}/route_tracer/{route_name}/
- 单方法路由文件名: {project_name}_trace_{route_id}_{YYYYMMDD}.md
- 多方法路由文件名: {project_name}_trace_{method_name}_{YYYYMMDD}.md + 索引文件 {project_name}_trace_all_methods_{YYYYMMDD}.md
- route_name 取路由路径转下划线（去掉前导斜杠），如 /api/upload → api_upload
- 禁止: 直接在 route_tracer/ 根目录平铺文件、使用序号前缀（如 01_xxx.md）、省略子目录
Key requirement: Auth risk pass-through
When each worker generates the call chain report, it must add an auth risk section at the top of the report:
## 鉴权状态判定
- **鉴权状态**：❌无鉴权
- **鉴权绕过漏洞**：
- 存在 Shiro 权限绕过（H-AUTH-001）：路径穿越 `/admin/;/user`
- 存在组件漏洞绕过（CVE-2020-1938）：Tomcat AJP 协议注入
- **风险等级**：🔴 极高（无鉴权 + 存在绕过方式）
Pass-through logic：
- Obtain the auth bypass vulnerabilities relevant to this batch from the "Auth risk information" section in the batching plan
- For P0 routes: mark ❌No auth, and if a global auth bypass vulnerability exists, mark it as well
- For P1 routes: mark 🔓Auth bypassable, and attach the specific bypass method
- For P2 routes (P2 fallback mode only): mark ✅Has auth, no bypass information pass-through, and vulnerability detection focuses on code-layer vulnerabilities after auth
- This information will be read by the agent-6 series and used to determine the exploitability of vulnerabilities
Agent-6a-sql-auditor: SQL injection auditor
角色: agent-6a-sql-auditor (SQL注入审计员)
等待: 所有 agent-5-N 调用链追踪完成，且调用链中存在 SQL 相关 sink
技能: /java-sql-audit
源代码: {source_path}
输出目录: {output_path}/sql_audit/（已创建，直接写入）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
输入: {output_path}/route_tracer/ 下含 SQL sink 的调用链报告（含鉴权风险信息）
任务: 基于调用链做精准 SQL 注入检测（非全量扫描），减少误报，并在漏洞报告中体现可利用前置条件
Key requirement: Exploitability preconditions
When generating each SQL injection vulnerability report, an exploitability preconditions section must be added:
## 可利用前置条件
- **鉴权要求**：❌无需鉴权
- **或鉴权绕过**：
- 存在 Shiro 权限绕过（H-AUTH-001）
- 存在组件漏洞绕过（CVE-2020-1938）
- **其他条件**：参数可控
- **综合判定**：🔴 可直接利用（无鉴权门槛）
Agent-6b-xxe-auditor: XXE injection auditor
角色: agent-6b-xxe-auditor (XXE注入审计员)
等待: 所有 agent-5-N 调用链追踪完成，且调用链中存在 XML 解析 sink
技能: /java-xxe-audit
源代码: {source_path}
输出目录: {output_path}/xxe_audit/（已创建，直接写入）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
输入: {output_path}/route_tracer/ 下含 XML 解析 sink 的调用链报告（含鉴权风险信息）
任务: 基于调用链做精准 XXE 注入检测（非全量扫描），减少误报，并在漏洞报告中体现可利用前置条件
Key requirement: Exploitability preconditions(same as agent-6a)
Agent-6c-upload-auditor: File upload auditor
角色: agent-6c-upload-auditor (文件上传审计员)
等待: 所有 agent-5-N 调用链追踪完成，且调用链中存在文件上传 sink
技能: /java-file-upload-audit
源代码: {source_path}
输出目录: {output_path}/file_upload_audit/（已创建，直接写入）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
输入: {output_path}/route_tracer/ 下含文件上传 sink 的调用链报告（含鉴权风险信息）
任务: 基于调用链做精准文件上传漏洞检测（非全量扫描），减少误报，并在漏洞报告中体现可利用前置条件
Key requirement: Exploitability preconditions(same as agent-6a)
Agent-6d-fileread-auditor: File read auditor
角色: agent-6d-fileread-auditor (文件读取审计员)
等待: 所有 agent-5-N 调用链追踪完成，且调用链中存在文件读取 sink
技能: /java-file-read-audit
源代码: {source_path}
输出目录: {output_path}/file_read_audit/（已创建，直接写入）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
输入: {output_path}/route_tracer/ 下含文件读取 sink 的调用链报告（含鉴权风险信息）
任务: 基于调用链做精准文件读取漏洞检测（非全量扫描），减少误报，并在漏洞报告中体现可利用前置条件
Key requirement: Exploitability preconditions(same as agent-6a)
Agent-6e-deserialization-auditor: Deserialization auditor
角色: agent-6e-deserialization-auditor (反序列化审计员)
等待: 所有 agent-5-N 调用链追踪完成，且调用链中存在 DESERIALIZE sink，或组件漏洞报告命中反序列化相关组件
技能: /java-deserialization-audit
源代码: {source_path}
输出目录: {output_path}/deserialization_audit/（已创建，直接写入）
反编译输出目录: {output_path}/decompiled/cache/（已创建，直接写入，阶段2+ 多 agent 共享缓存，避免重复反编译；agent-1-N worker 阶段使用各自独占目录 decompiled/agent-1-{N}/）
脚本目录: {output_path}/scripts/（所有运行时生成的临时脚本、中间文件必须写入此目录，禁止写入 /tmp 或其他临时目录）
输入:
- {output_path}/route_tracer/ 下含 DESERIALIZE sink 的调用链报告（含鉴权风险信息）
- {output_path}/vuln_report/ 下的组件漏洞报告
- {output_path}/cross_analysis/component_vulnerabilities.md（如存在）
任务: 基于调用链和组件证据做精准反序列化漏洞检测，确认入口可达性、用户可控性、组件/JDK/gadget 条件和 payload 可测试性；组件版本命中只能作为输入证据，不能直接判定漏洞成立
Key requirement: Exploitability preconditions(same as agent-6a), and additionally include:
- Component/JDK condition: clarify whether the version satisfies it
- gadget condition: clarify whether a usable gadget exists in the classpath
- Network condition: clarify whether DNS/LDAP/RMI outbound network access is required
- Payload constraints: output only low-damage verification payloads for authorized testing purposes
Mapping between Sink types and agents:
| Sink type | Feature keywords | Agent |
|---|---|---|
| SQL concatenation | Statement.execute, executeQuery, executeUpdate, sql.*\+, StringBuilder.*append.*sql, StringBuffer.*append.*sql, String.format.*sql, concat.*sql, MyBatis.*\$\{, createQuery.*\+, HQL.*\+ |
agent-6a-sql-auditor |
| XML parsing | DocumentBuilder.parse, SAXParser, XMLReader, XMLReaderFactory, SAXBuilder, SAXReader, TransformerFactory, SchemaFactory, XMLInputFactory, Unmarshaller, JAXBContext |
agent-6b-xxe-auditor |
| File upload | MultipartFile, transferTo, ServletFileUpload, DiskFileItemFactory, FileItem, getOriginalFilename, new File.*fileName, Paths.get.*fileName |
agent-6c-upload-auditor |
| File read | BufferedReader, FileReader, FileInputStream, Scanner.*File, Scanner.*Path, Files.readAllLines, Files.readAllBytes, Files.lines, new File.*\+, Paths.get.*\+ |
agent-6d-fileread-auditor |
| Deserialization | DESERIALIZE, ObjectInputStream, readObject, readUnshared, readExternal, XMLDecoder, JSON.parseObject, JSON.parse, new XStream, fromXML, DriverManager.getConnection, DataSource.getConnection, rememberMe, CookieRememberMeManager, JndiLookup, \$\{jndi:, commons-collections, InvokerTransformer, TiedMapEntry |
agent-6e-deserialization-auditor |
Decision logic:
- The lead reads all call chain reports under
{output_path}/route_tracer/all call chain reports under - Search the reports for the above feature keywords (regular expression matching supported)
- For agent-6e, also read
{output_path}/vuln_report/and{output_path}/cross_analysis/component_vulnerabilities.md; if deserialization-related components are hit, then even if the call chain does not contain theDESERIALIZEsink, also start agent-6e to confirm the trigger point - Only start agents with corresponding sink or component evidence; if there is no corresponding evidence, skip that agent and directly mark the task as completed
- Preferred solution: directly read the Sink Identification sectionin the java-route-tracer output report; this section has already completed the full Sink classification
Agent-7-x-quality-checker: quality checker pool (dynamically spawned on demand, runs throughout the entire workflow)
角色: agent-7-x-quality-checker（质检员池，按需 spawn）
命名: agent-7-1, agent-7-2, ..., agent-7-N，序号递增
校验依据: 使用 Skill 工具加载对应 skill（如 /java-route-mapper），从加载的 skill 上下文中提取输出规范作为校验标准
校验报告目录: {output_path}/qa_reports/（每次校验写入 qa_report_{被校验agent名称}.md）
最终汇总: {output_path}/quality_report.md（由最后一个质检员汇总生成）
工作模式: 每个 agent 完成后立即校验（完成一个、校验一个），负责人将校验任务分配给空闲质检员
Core principle: immediately close and release the slot after each worker completes, and perform verification asynchronously; before this stage enters the next stage, all verifications must pass and the rework list must be cleared, to avoid passing erroneous data downstream.
Quality checker pool scheduling strategy:
- Runs as an independent pool: the quality checker pool and the worker pool run concurrently without occupying each other's slots; pool upper limit =
ceil({max_concurrent_agents} / 2)(default 5 → 3, minimum 1, maximum 5);{max_concurrent_agents}≤ 3 degrades to semi-synchronous mode (see key design item 5 for details) - Create on demand: after an agent completes its task, the person in charge immediately spawns a quality checker to verify its output; do not pre-create them in batches in advance
- Stage 1: routing sub-workflow (agent-1-recon → multiple agent-1-N → agent-1-merge) immediately spawns a quality checker on demand to verify each item as soon as it is completed; after agent-2/3 each complete, spawn a quality checker on demand for verification
- Stage 2: after agent-4a/4b each complete, spawn a quality checker on demand in sequence
- Stage 3: after each agent-5-N worker completes, spawn a quality checker on demand (subject to the quality checker pool upper limit; verification tasks exceeding the upper limit enter the waiting queue)
- Stage 4: after each agent-6x completes, spawn a quality checker on demand
- When there is a new verification request, prioritize assigning it to an existing idle quality checker; if all are busy and the pool upper limit has not been reached, spawn a new quality checker; when the pool is full, enter the waiting queue, worker pooldoes not block and continues to advance
- All quality checkers have exactly the same capabilities and consistent verification standards
- After each quality checker completes verification, write the complete verification report to
{output_path}/qa_reports/qa_report_{被校验agent名称}.md, then notify the person in charge of the result (pass/fail + report file path),sending the report body in the message is prohibited - After all verifications in the current stage are completed and the waiting queue is cleared, close all quality checkers for that stage; respawn on demand in the next stage
Verification trigger timing (unified across all stages: verify each one as it completes)
| Trigger point | Verification target | Assigned to | Operation after verification passes | Handling of failure |
|---|---|---|---|---|
| After agent-1-recon completes | _recon_*.md task assignment sheet |
Idle checker | Close agent-1-recon | The person in charge notifies agent-1-recon to read qa_reports/qa_report_agent-1-recon.md and supplement |
| After each agent-1-N completes | That worker's route_mapper/{module} output + .status JSON | Idle checker | Close that worker | The person in charge notifies that worker to read qa_reports/qa_report_agent-1-{N}.md and supplement |
| After agent-1-merge completes | Main index README + reconciliation with the reconnaissance sheet | Idle checker | Close agent-1-merge | The person in charge notifies agent-1-merge to read qa_reports/qa_report_agent-1-merge.md and supplement |
| After agent-2 completes | java-auth-audit output | Idle inspector | Close agent-2 | The person in charge notifies agent-2 to read qa_reports/qa_report_agent-2.md and supplement |
| After agent-3 completes | java-vuln-scanner output | Idle inspector | Close agent-3 | The person in charge notifies agent-3 to read qa_reports/qa_report_agent-3.md and supplement |
| After agent-4a completes | high_risk_routes.md |
Idle inspector | Close agent-4a | The person in charge notifies agent-4a to read qa_reports/qa_report_agent-4a.md and supplement |
| After agent-4b completes | component_vulnerabilities.md + auth_bypass_vulnerabilities.md |
Idle inspector | Close agent-4b | The person in charge notifies agent-4b to read qa_reports/qa_report_agent-4b.md and supplement |
| After agent-5 completes in batches | trace_batch_plan.md batching plan |
The person in charge checks on their own | Close agent-5, spawn workers | Notify agent-5 to re-batch |
| After each agent-5-N completes | That worker's route_tracer output (including the authentication risk section) | Idle inspector | Close that worker | The person in charge notifies that worker to read qa_reports/qa_report_agent-5-{N}.md and supplement |
| After each agent-6x completes | The corresponding audit output (including exploitability preconditions) | Idle inspector | Close that agent-6x | The person in charge notifies that agent-6x to read qa_reports/qa_report_{agent-6x名称}.md and supplement |
| After all agent-6x checks pass | Cross-skill data consistency | Any inspector | Generate quality_report.md → close agent-7-x | — |
General verification method
For each verification:
- Read
references/quality_check_templates.md, find the corresponding stage'smandatory fill-in verification checklist table - Use the Skill tool to load the skill corresponding to the agent being verified (e.g.
/java-route-mapper), and extract the output specification from the skill context as the verification standard - Read the actual output file
- Following the template tablefill in row by rowthe "Actual" and "Status" columns of each verification item; omitting any field is prohibited
- Fill in the "Final Judgment" section: status (pass/fail), proportion of passed items (M/N), specific missing items for failed items and repair requirements
- Write the complete verification report to the file
{output_path}/qa_reports/qa_report_{被校验agent名称}.md(e.g.qa_report_agent-1.md、qa_report_agent-5-2.md） - Notify the person in charge of the verification result: send only "pass/fail" + the report file path,including the body of the verification report in the message is prohibited
- After the person in charge receives a failed notification, send to the corresponding agent: "Verification failed, please read
{output_path}/qa_reports/qa_report_{你的名称}.mdto obtain the complete verification report, supplement each failed item according to the list, and resubmit"
Output format requirements: The quality inspector's verification result must strictly follow the references/quality_check_templates.md table template and be filled in item by item; summarizing in one sentence or omitting the verification process is not allowed.
The specific verification items and output templates for each stage have been uniformly collected in references/quality_check_templates.md ; the quality inspector verifies item by item according to the mandatory fill-in table in that file.
Final summary: generate quality_report.md
After all agent-6x verifications pass, the person in charge assigns the summary task to any idle verifier. The verifier reads the references/quality_check_templates.md "Final Quality Report Template" at the end, integrates the verification results of all stages to generate {output_path}/quality_report.md, then shuts down agent-7-x, completing the entire pipeline.
Output directory structure
{output_path}/
├── route_mapper/ # 阶段1 - 路由子流程
│ ├── _recon_*.md # agent-1-recon 任务分配单（_recon_{YYYYMMDDHHMMSS}_{rand}.md）
│ ├── .status/ # agent-1-N worker 状态 JSON 与错误文件
│ ├── {module_name}/ # 每个 agent-1-N 写入自己负责的模块子目录（含 *_ws_* 形式的 WebService 模块）
│ └── README.md # agent-1-merge 主索引
├── auth_audit/ # 阶段1 - agent-2-auth-audit
├── vuln_report/ # 阶段1 - agent-3-vuln-scanner
├── cross_analysis/ # 阶段2 - agent-4a & agent-4b
│ ├── high_risk_routes.md # agent-4a 输出
│ ├── trace_batch_plan.md # agent-5 分批方案
│ ├── component_vulnerabilities.md # agent-4b 输出
│ └── auth_bypass_vulnerabilities.md # agent-4b 输出
├── route_tracer/ # 阶段3 - agent-5-1/5-2/.../5-N 并行输出（含鉴权风险透传）
├── sql_audit/ # 阶段4 - agent-6a-sql-auditor（含可利用前置条件）
├── xxe_audit/ # 阶段4 - agent-6b-xxe-auditor（含可利用前置条件）
├── file_upload_audit/ # 阶段4 - agent-6c-upload-auditor（含可利用前置条件）
├── file_read_audit/ # 阶段4 - agent-6d-fileread-auditor（含可利用前置条件）
├── deserialization_audit/ # 阶段4 - agent-6e-deserialization-auditor（含可利用前置条件）
├── decompiled/ # 反编译输出
│ ├── cache/ # 阶段1 之外的共享缓存（agent-2/3/4/5 等共享）
│ └── agent-1-{N}/ # 阶段1 worker 独占目录（避免多 WAR 同名 class 互相覆盖）
├── scripts/ # 临时脚本目录（多 agent 共享，所有运行时生成的脚本必须写入此目录，禁止写入临时目录）
├── qa_reports/ # 质检员校验报告（qa_report_{agent名称}.md，每次校验一份）
└── quality_report.md # 阶段5 - agent-7-x-quality-checker
Skill output specification references
During agent-7-x verification, use the Skill tool to load the corresponding skill to obtain the output specification:
| Verification target | Load Skill |
|---|---|
| agent-1-recon output | (no corresponding skill; verify according to the "Reconnaissance Self-Check List" in this SKILL.md) |
| agent-1-N output | /java-route-mapper |
| agent-1-merge output | /java-route-mapper（OUTPUT_TEMPLATE_INDEX.md） |
| agent-2-auth-audit output | /java-auth-audit |
| agent-3-vuln-scanner output | /java-vuln-scanner |
| agent-5-route-tracer output | /java-route-tracer |
| agent-5-N output | /java-route-tracer |
| agent-6a-sql-auditor output | /java-sql-audit |
| agent-6b-xxe-auditor output | /java-xxe-audit |
| agent-6c-upload-auditor output | /java-file-upload-audit |
| agent-6d-fileread-auditor output | /java-file-read-audit |
| agent-6e-deserialization-auditor output | /java-deserialization-audit |