# Python 3.11 环境（conda / venv 均可）
conda create -n autoplayqa python=3.11 -y
conda activate autoplayqa
pip install -r requirements.txt

# adb 需在 PATH（Android SDK platform-tools 默认安装位置）
$env:PATH = "$env:LOCALAPPDATA\Android\Sdk\platform-tools;$env:PATH"

no backticks — this line. Actually original: "详见 [`docs/MCP_INTEGRATION.md`]。"

Codex CLI 在 `~/.codex/config.toml` 添加：

GXP2

然后直接告诉智能体："接着设备，开设置，把亮度调到 50%，完成后存成任务"。

**MCP 工具清单**

| 类别 | 工具 |
| -- | -- |
| 设备| `list_devices`、`connect_device` / `disconnect_device` / `enable_wireless` / `pair_device`（无线 adb） |
| 感知 | `screebshot`（返回 PNG 路径可看）、`screenshot_marked`（set-of-marks 标注即 `click_index` 配合） —— 默认归一化短边 720p省 token，`full_relation=true` 取原始；识别与元素表 coordinate是 device 原始像素）、`ui_dump`、`find_text`（dump+OCR 免费定位）、`ocr`、`find_template`（ OpenCV matching 定位图标/贴图）/ `capture_template` / `list_templates`、`detect_objects`（YOLO 检测+分类）/ `list_yolo_classes`、`classify_scene` returns scene `taxomy` |
| 动作 | `click` / `click_index`（点上次 `click` — "index" tool）、`swipe`、`input_text`、`press_key` |
| 录制 | `formation` ... |

Row recording: "`calibrate_touch`（触摸面板→显示像素校准）、`record_gestures_start` / `record_gestures_stor`（getevent 真手指的手势录，产物落 `outputs/reedings/<时间戳>/`）、`record_actions_start` / `record_actions_stor`（智能体动 日志：自主探索自录/agent 交接归档）`

监控: "`start_monitor` / `get_new_frams` / `stop_monitor`（后台按固定间隔持续截图存盘，智能体按游标取路径自己挑帧；默认 `sentinel=true` 挂哨兵，drop the三个返回值都带 `sentinel` 统计，`stop_monitor` 附哨兵那一轮的报告路径）`

任务: "`get_task_schema`、`list_tasks`、`get_task`（附 `_steps`/`_step_outline` 步号导航）、`save_task`（返回 `lint_warnings`）、`run_task`（同步阻塞至跑完返回；`export_to` 次导出）、`start_task` / `get_run_status`（后台跑长任务 + 轮询进度）、`list_suites` / `run_suite`（套件连跑：登录一次连跑，可后台，也用 `get_run_status` 轮询，含 case 进度）、`validate_task` / `lint_saved_task`（不落盘校验 / 对已存任务检查）、`get_step_labels` / `list_includes` / `list_custom_actions`（步号映射/共享片段/已注册 action）、`clear_replay_cache`「

### 方式二：本地 CLI

GXP3

<p align="center"><img src="docs/images/cli_demo.svg" width="680" alt="局部 CLI 会话一瞥：启动检测设备、task run 逐步识别命中、watchdog 记 finding 与报告路径（示意图）"></p>

*实时 CLI 会话一瞥（**输出为示意**，非真实截图）。*

| Comando                                                                                                           | Descripción                                     |
| ---------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| `device list` / `agent list` / `agent select <i\|id\|all>`                                                       | Gestión de dispositivos y agentes               |
| `device connect <ip[:port]>` / `device disconnect [addr]` / `device tcpip <id>` / `device pair <addr> <code>`    | Conexión adb inalámbrica                        |
| `click <x> <y>` / `drag <x1> <y1> <x2> <y2> [ms]` / `input <text>`                                               | Acciones directas                               |
| `action "<instrucción>"` o escribir directamente en lenguaje natural                                             | Análisis local: regex de coordenadas explícitas → localización de texto por dump/OCR (p. ej. "haz clic en el botón de configuración") |
| `task list` / `task show <name>` / `task run <name>`                                                             | Gestión y ejecución de tareas (`show` primero imprime el esquema del flujo ordenado por número de paso y luego el texto original) |
| `task suites` / `task suite <name> [device]`                                                                     | Ejecución de suites: un solo inicio de sesión para ejecutar múltiples casos; si falla, reintentar según la política |
| `task resume <name> <node>`                                                                                      | El agente entrega el paso y continúa la ejecución posterior |
| `task renumber <name>`                                                                                           | Recalcula los números de paso según el grafo actual y los escribe de vuelta al archivo |
| `task lint <name>`                                                                                               | Chequeo de robustez de tareas (W001-W007, solo avisos, no bloquea) |
| `task health [name] [--days N]`                                                                                  | Agrega `node_stats` entre ejecuciones para ver la tendencia de deterioro de anclas |
| `task handoffs [name] [--days N]`                                                                                | Agrega los registros de acciones de entrega del agente y sugiere qué nodos de entrega pueden consolidarse como nodos deterministas |
| `task cache status` / `task cache clear`                                                                         | Ver / vaciar la caché de anclas de reproducción |
| `record on/off/status` + `task save <name>`                                                                      | Grabar sesión → tarea borrador de reproducción |
| `record gestures start/stop/status [device]`                                                                     | Grabación de gestos reales con getevent (multitáctil / pulsación larga / deslizamiento segmentado + calibración táctil) |
| `debug on/off`                                                                                                   | Volcado de depuración (anotaciones de capturas, candidatos de reconocimiento, trace) |

## Motor de tareas (núcleo)

Las tareas son máquinas de estados con compuerta de reconocimiento (`task/task_definitions/*.json`): cada nodo primero **reconoce** (coincidencia de controles `ui_text` / `ocr` / coincidencia de iconos `template` / características ORB `feature` / detección de objetos `yolo` / escena de pantalla completa `scene` / `blank_screen` / `always`) para confirmar la interfaz; solo si hay coincidencia se ejecuta la acción, y luego se sondea la lista de candidatos `next` para saltar — quien reconozca primero, gana (soporte natural para ramas de diálogos emergentes); en caso de tiempo de espera, se va al nodo de recuperación `on_timeout`.

GXP4

GXP5

Los pasos que requieren juicio inteligente usan la acción `agent`: el motor se suspende y devuelve `status=agent_required` + el texto de la instrucción; el agente completa ese paso con las herramientas del dispositivo y luego continúa con `run_task(start_after=<nodo>)`. El formato completo está en `get_task_schema` o `action/action_schema.py`; el diagrama de secuencia de la entrega de ida y vuelta está en [docs/MCP\_INTEGRATION.md](docs/MCP_INTEGRATION.md#agent-交接识别到人类判断步骤怎么办).

**Número de paso (step)**: un nodo puede llevar un número de paso `step` **solo de lectura** que indica el orden de ejecución — la ruta principal (desde `entry` siguiendo `next[0]`) usa enteros `1, 2, 3…`, las ramas de respaldo (`on_timeout` / `next[1:]`) usan números con punto como `2.1`, `2.1.1`, y los nodos inalcanzables usan `?`. La tarea es un grafo, no una lista; leer el JSON de arriba a abajo no revela el orden de ejecución. El número de paso permite que una persona/agente ubique de un vistazo la posición de un nodo en el flujo. **El motor no lo lee**, es puramente para navegación. El número de paso se calcula en tiempo real desde el grafo: el CLI `task renumber <name>` lo recalcula según el grafo actual y escribe `step` de vuelta al archivo (colocado al inicio del nodo); `task show <name>` primero imprime el esquema del flujo ordenado por número de paso y luego el texto original; el MCP `get_task` además devuelve `_steps` (mapeo nombre→número de paso) + `_step_outline` (lista del flujo). Después de editar una tarea, vuelve a ejecutar renumber para refrescar, sin dejar números antiguos desalineados.

**Ejecución en segundo plano (tareas largas)**: `run_task` bloquea de forma síncrona, solo retorna al terminar y no muestra progreso intermedio; la experiencia de tareas largas / humo de flujo completo es deficiente. Cambia a `start_task` para obtener inmediatamente el `run_id`, y luego sondea con `get_run_status(run_id)`: devuelve `status` (running / agent\_required / done / error) + `current_node` + `steps` + `elapsed_s`; en estado final adjunta el resultado completo con la misma estructura que `run_task` (`steps` / `findings` / `report` / `handoff`). El motor es un singleton; solo se permite una ejecución en segundo plano a la vez; en `agent_required`, completa ese paso según `result.handoff` y continúa con `start_task(start_after=<nodo>)`.

**Ejecución de suites (suite)**: múltiples casos comparten un solo arranque en frío + inicio de sesión y se ejecutan de forma continua (`task/task_definitions/suites/*.json`; MCP `list_suites` / `run_suite`, CLI `task suites` / `task suite <name>`). El JSON de suite declara la lista `cases` + `resume_after` (nodo para saltar el preámbulo y continuar directamente) / `case_entry` (entrada del cuerpo del caso) / `landing` (spec de reconocimiento para verificar la pantalla de aterrizaje entre dos casos) — **los tres campos son obligatorios, sin valores predeterminados del framework**; `validate_suite` valida antes de ejecutar y reporta error si falta algún campo. El primer caso hace el arranque en frío completo; los casos siguientes usan `resume_after` para saltar el inicio de sesión repetido, pero cada caso sigue siendo una ejecución independiente (directorio de findings independiente / `report.json`); si un caso falla (se cuelga / se bloquea / la pantalla de aterrizaje no coincide), se maneja según `on_case_failure`: `restart_retry` (predeterminado, reintenta con arranque en frío) / `restart_continue` (sin reintento, el siguiente caso arranca en frío normalmente) / `abort` (termina la suite, los casos restantes se marcan como omitidos).

GXP6

**Nodos compartidos (includes)**: los nodos compartidos como el manejo de diálogos emergentes comunes se colocan en `task/task_definitions/common/*.json` (solo contienen `"nodes"`, referencia de un solo nivel); las tareas los incluyen con `"includes": ["common/popups.json"]`. Las referencias `next`/`on_timeout` entre archivos se validan de forma integral sobre la tabla de nodos fusionada; solo se ejecuta si todo pasa (carga atómica). Los nodos con nombre duplicado reportan error por defecto (strict); con `"on_conflict": "overwrite"`, el cargador sobrescribe — el archivo principal se fusiona al final, por lo que las tareas pueden especializar nodos compartidos. Al guardar la tarea se conservan las referencias; las actualizaciones de los archivos include surten efecto en la próxima ejecución de las tareas que los referencian.

**Pasos complejos deterministas (custom)**: lógica determinista de múltiples pasos entre una acción atómica adb individual y la suspensión del agente (sin necesidad de juicio inteligente), escrita como handler de Python registrado con `@register("nombre")` en `task/custom_actions/`; las tareas la referencian con `{"type": "custom", "name": "swipe_until", "params": {...}}` y se valida que esté registrada al cargar. Incorporados: `swipe_until` (deslizar repetidamente hasta que el reconocimiento acierte; buscar objetivo en listas / páginas con scroll), `launch_app` (despertar y encender pantalla + abrir la aplicación, apertura de arranque en frío), `gm_command` (enviar comandos desde el panel GM, manejo automático del método de entrada), `ensure_checkbox` (llevar el interruptor al estado objetivo), `set_text_field` (vaciar y luego ingresar texto). Un nuevo `task/custom_actions/<módulo>.py` se descubre y registra automáticamente dentro del paquete (escaneo por nombre con `pkgutil`), sin necesidad de editar `__init__.py` manualmente; si el import del módulo falla, lanza error directamente (fail-fast), sin convertirse silenciosamente en "no registrado" en tiempo de ejecución.

**Omitir tras reportar (bug-skip)**: tras detectar y reportar un bug, se puede saltar a un nodo de recuperación específico para continuar probando sin abortar. Anotación en dos niveles — `skip_to` del watchdog (salta al acertar, prioridad máxima, supera a `fail_task`) + `on_finding` a nivel de tarea (objetivo de respaldo global, también cubre bugs sin watchdog como crashes de logcat / ANR). Restricciones clave: **solo salta si se registra un nuevo finding** (cada watchdog salta como máximo una vez por ronda, deduplicado con el conjunto seen), y **la fuente de activación es solo coincidencia de watchdog + crash de logcat / ANR** — un simple tiempo de espera de reconocimiento (bloqueo, sin bug) nunca salta, sigue usando `on_timeout`. Al cargar se valida que los nodos referenciados por `skip_to` / `on_finding` existan.

En una tarea se ve así (los ejemplos centrales anteriores eran flujo puro, sin estos campos — `watchdogs` / `on_finding` a nivel de tarea, `finding` a nivel de nodo):

GXP7

* `watchdogs[0].skip_to`: durante el combate, OCR detecta «Error de red» → registra finding y salta a `回到主界面` para continuar probando;
* `watchdogs[1].fail_task`: pantalla negra → juzga la tarea como fallida directamente (no tiene `skip_to` como respaldo);
* `on_finding` a nivel de tarea: bugs sin watchdog correspondiente como crashes de logcat / ANR, todos con respaldo a `回到主界面`;
* Nodo `战斗失败弹窗.finding`: la rama anómala se auto-reporta al entrar, sin depender del watchdog.

**Lista blanca de diálogos emergentes benignos (popups)**: el campo `popups` de la tarea lista explícitamente los diálogos emergentes benignos conocidos (acuerdos de usuario, alertas del juego, etc., ruido esperado) y su reconocimiento + acción de eliminación (solo `click` / `key` / `gesture`). **Solo se escanea y elimina cuando el reconocimiento está atascado**, **sin registrar finding** (la captura de pantalla es un cuello de botella de rendimiento, por lo que no se añade costo por paso); los diálogos emergentes no listados en la lista blanca seguirán atascándose hasta el tiempo de espera / ser descubiertos por el watchdog — a diferencia del fork que traga diálogos emergentes silenciosamente, este proyecto insiste en "las anomalías se descubren, no se auto-curan en silencio". Los nombres de los diálogos emergentes eliminados se devuelven en `result["popups_dismissed"]`.

**Respaldo BACK para diálogos emergentes desconocidos (back\_fallback)**: si tras agotar la lista blanca sigue atascado, significa que lo que cubre la pantalla es algo **no previsto**. El motor primero fija el finding `unknown_popup_backoff` en ese fotograma actual (primero deja evidencia — BACK podría borrar la escena), luego presiona BACK una vez, y usa diferencia de píxeles para confirmar que la pantalla realmente cambió antes de dar una ronda más de reconocimiento. **Solo desatasca, no salta** (saltar es trabajo del bug-skip); si el nodo tiene `on_timeout` propio, cede completamente el paso a la rama de recuperación escrita por el autor, por lo que solo cubre los callejones sin salida que originalmente fallarían seguro. El config `engine.back_fallback` está activado por defecto; `"back_fallback": false` en el JSON de la tarea lo desactiva individualmente.

**Salud de anclas (node\_stats / task health / task lint)**: el motor cuenta las fuentes de coincidencia por nodo — coincidencia directa, recuperación por tiempo de espera, asistencia de diálogos emergentes, respaldo BACK, deriva de anclas — y produce `result["node_stats"]` que se escribe en `report.json`. Los nodos que en una ronda solo pasan gracias a respaldos repetidos, o cuyos anclas se desplazan continuamente, registran un finding de advertencia `anchor_rot_suspect`: **esto es deterioro de anclas de la tarea, no un bug del juego** (umbrales `engine.rot_suspect_timeouts` / `engine.drift_tolerance_px`). El CLI `task health [name] [--days N]` agrega offline los `node_stats` de ejecuciones históricas para ver tendencias; `task lint <name>` (que `save_task` también ejecuta automáticamente al guardar) examina escrituras "válidas pero frágiles" — nodos muertos sin rama de recuperación, ramas que parecen errores pero no reportan, tareas de arranque en frío sin lista blanca de diálogos emergentes, coordenadas fijas escritas a mano cuando hay anclas, tareas enteras con cero aserciones QA; por defecto solo avisa, el config `lint.strict: true` puede cambiarlo para rechazar el guardado.

## Crear tareas

Cuatro formas, ordenadas por nivel de recomendación:

| Forma                        | Cómo hacerlo                                                                                                                                                                                                                                                          | Escenario de uso        |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| **Grabación por observación (recomendada)** | Dile al agente "yo hago el recorrido manualmente y tú grabas", luego demuestra el flujo en el teléfono; el agente sincroniza capturas/reconocimiento de cada paso vía MCP y produce directamente una tarea dirigida por reconocimiento con anclas verificadas en dispositivo real. El flujo completo (incluida captura táctil precisa con getevent, calibración al cambiar de dispositivo) está en `.claude/skills/live-record/SKILL.md` | Sabes operar pero no explicar los pasos; flujo largo |
| **Generación por exploración del agente** | Describe el objetivo (p. ej. "abre la configuración, sube el brillo al 50% y guárdalo como tarea"); el agente usa `screenshot`/`ui_dump`/`find_text` para confirmar anclas paso a paso y ejecutar, luego `save_task` para guardar y `run_task` para verificar. Selección de canales / aserciones QA / iteración de reproducción en `.claude/skills/author-task/SKILL.md` | Puedes expresar el objetivo con lenguaje |
| **JSON escrito a mano**      | Escribe directamente `task/task_definitions/*.json` según el formato de `get_task_schema` (o `action/action_schema.py`); cómo elegir canales y qué aserciones QA añadir en `.claude/skills/author-task/SKILL.md`                                                                                                                       | Conoces el formato, flujo simple |
| **Borrador por grabación CLI** | En el CLI: `record on` → ejecuta comandos para operar → `record off` → `task save <name>`, genera un borrador de reproducción ciega (reconocimiento `always` + acciones literales), y luego se lo entregas al agente para reescribirlo como versión dirigida por reconocimiento                                                                                                                              | Registrar rápidamente el esqueleto offline |

Independientemente del método, escribir tareas sigue la misma convención: para anclas de reconocimiento prioriza `ui_text` (interfaces del sistema) / `ocr` (texto de superficie única del juego) / `template` (iconos, texturas y otros elementos sin texto) / `feature` (anclas con textura rica que cambian ligeramente) / `yolo` (detección de objetos entrenada, resistente a deformación y oclusión) / `scene` (solo responde "dónde estoy", no produce coordenadas); las acciones usan `"target": "recognized"` sin coordenadas fijas; los nodos de ramas anómalas como diálogos emergentes añaden el campo `finding`, y a nivel de tarea se añaden `watchdogs` como aserciones negativas — este proyecto se posiciona como herramienta de QA; las anomalías deben reportarse con evidencia, no omitirse silenciosamente.

### Orquestación visual: PipelineEditor

Las tareas no solo se escriben, también se dibujan. `pipeline_editor/` (FastAPI + React, distribuido con este repositorio) es un editor visual web para el JSON de tareas; modifica directamente `task/task_definitions/<nombre-de-tarea>.json`, sin guardar copias:

* 🎨 **Orquestación en lienzo**: arrastra y conecta para orquestar la máquina de estados — línea sólida = `next` (con prioridad de reconocimiento anotada en el borde), línea discontinua naranja = `on_timeout`; los nodos introducidos por `includes` tienen fondo gris con candado y son de solo lectura, se eliminan automáticamente al guardar, nunca se consolidan en el archivo principal
* ✅ **Validación de verdad + lint**: al detenerse 0.8 segundos, envía automáticamente el grafo actual al backend para ejecutar en seco `task_loader.resolve_task` y `lint_task`; el editor **no replica ninguna regla de validación** — los errores que ves en el lienzo son los que reportará el motor
* 🎯 **ROI / plantilla desde captura**: haz clic en la mira junto al campo `roi`, arrastra un rectángulo sobre la captura de pantalla completa del dispositivo real para escribir las coordenadas, y puedes incluso "probar lectura OCR / probar coincidencia de plantilla" en el momento para ver el cuadro de acierto y la puntuación; el campo `template` puede recortar una nueva plantilla directamente de la captura y guardarla en disco
* ▶️ **Resaltado de ejecución en dispositivo real**: hilo en segundo plano ejecuta el motor, WebSocket empuja cada paso, el lienzo resalta en tiempo real el nodo actual + la trayectoria visitada; al detener se usa el cierre limpio cooperativo del motor, con report y cadena de evidencia completos
* 🤝 **Colaboración MCP**: el backend incrusta un servidor MCP de superficie de edición en `/mcp`; en cuanto el agente guarda, el lienzo del usuario se recarga automáticamente en ~2 segundos (si hay modificaciones sin guardar, aparece un banner de conflicto) — la persona dibuja, la IA edita el JSON; escriben el mismo archivo y pasan por la misma validación

Con un solo comando desde la raíz del repositorio (backend :8930 + frontend :5173, abre en el navegador la dirección que imprime):

GXP8

Las dependencias del frontend se instalan una vez la primera vez (`cd pipeline_editor\frontend; npm install`); las del backend ya están integradas en el `requirements.txt` raíz. La guía de uso completa está en [`pipeline_editor/README.md`](pipeline_editor/README.md) (documentación en `pipeline_editor/docs/`).

## Estructura de directorios

GXP9

*Las dependencias solo van de arriba hacia abajo: la capa de percepción / ejecución no puede importar la capa de tareas; la capa base no puede importar capas superiores. El proyecto en sí no hace ninguna llamada a LLM — la inteligencia siempre está del lado del agente externo.*

GXP10

## Pruebas

GXP11

Ninguno de los dos conjuntos depende de un dispositivo real (los subprocess están todos mockeados); el alcance de ejecución conjunta lo define `testpaths` en el `pytest.ini` raíz.

## Acerca de

* **Posicionamiento**: **framework** de automatización de pruebas QA para juegos Android. Proporciona percepción de dispositivo determinista (ojos) y operación (manos), y un motor de tareas con compuerta de reconocimiento; el juicio y la orquestación se delegan al agente de IA externo; el proyecto en sí no hace llamadas a grandes modelos, cero tokens.
* **General vs. específico**: el lado del framework son capacidades generales independientes del juego (canales de percepción / backends de acción / motor de tareas / recopilación de evidencia de findings / interfaces MCP y CLI); **la parte específica del juego la proporciona la parte integradora** — las tareas y suites en `task/task_definitions/`, las imágenes de plantilla en `task/templates/`, los modelos YOLO en `task/models/`, y las etiquetas de escena registradas con `register_scene_probe`, son todos activos locales / del proyecto integrador, por defecto no se incluyen en el repositorio.
* **Plataforma / stack tecnológico**: Windows + Android (ADB, emulador / dispositivo real); Python 3.11; OCR local rapidocr, coincidencia de plantillas OpenCV / coincidencia de características ORB, detección de objetos YOLO (onnxruntime, opcional), clasificación de escenas por reglas, volcado uiautomator, captura de fotogramas por defecto con flujo scrcpy.
* **Forma de integración**: servidor MCP (Claude Code / Codex plug-and-play) o CLI interactivo local.
* **Orientación de diseño**: herramienta de pruebas QA — las anomalías son descubrimientos de prueba; hay que reportarlas con evidencia (aserciones de watchdogs / finding de nodo / monitoreo de crashes / evidencia de grabadora de vuelo), no omitirlas silenciosamente.

## Agradecimientos y referencias

Este proyecto es una implementación independiente (Python + React, sin reutilización de código). A continuación se documentan las referencias **verificables** del registro de iteración de ingeniería, con agradecimiento:

* **[MaaFramework](https://github.com/MaaXYZ/MaaFramework)**:
  La fuente de la idea del motor de tareas — el JSON de tareas organiza el flujo como «confirmación por reconocimiento → ejecución de acción → sondeo de candidatos `next` (quien acierte primero gana)», con tiempo de espera que va a la rama de recuperación; la primera versión del motor se construyó siguiendo su idea de Pipeline; las capacidades posteriores de nodo como reconocimiento combinado (`all_of`/`any_of`), repetición a nivel de acción (`repeat`) y bloques `defaults` a nivel de tarea también se inspiran en sus características de pipeline.
* **[better-genshin-impact](https://github.com/babalae/better-genshin-impact)**:
  Siguiendo sus prácticas de ingeniería se implementaron tres cosas: **centinela de ventana vacía** (cuando la tarea termina / durante la entrega del agente, el monitoreo de fotogramas en segundo plano continúa verificando pantalla blanca y crashes), **push de resultados de findings** (al finalizar la ejecución se envía un resumen por IM / webhook), y **manifest de modelos** (registro versionado de modelos YOLO en `models.json`).
* **[MaaPipelineEditor](https://github.com/kqcoxn/MaaPipelineEditor)**:
  El paradigma de interacción del orquestador visual `pipeline_editor/` de este repositorio se referencia de él (orquestación con conexiones en lienzo, panel de propiedades, sincronización JSON en tiempo real, herramientas auxiliares de reconocimiento integradas); ver [pipeline\_editor/README.md](pipeline_editor/README.md#致谢与借鉴).