执行审计

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install auditoria-por-ejecucion
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 auditoria-por-ejecucion。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

执行审计（Auditoria por Ejecución）是一种 Openclaw 技能方法论，用于检查仓库、文档、报告、部署计划和安全审查中的声明是否真正得到了可执行证据的支持。它优先考虑命令和测试而非散文，将退出状态码和观察到的行为视为真相的主要来源。
该技能可防止虚假绿色的 CI 管道、误导性仪表板、未记录的存根、不受支持的外部审批以及基于过期报告得出的结论。它区分了已验证、未验证和被反驳的声明，同时保留证据、记录残余风险，并要求在将漏洞视为已关闭之前进行行为更改并通过测试。

应用场景

在依赖第三方仓库的测试、部署自动化、安全态势或已发布功能之前对其进行审计。
验证各种声明，例如测试通过、部署自动化、仪表板公开指标或服务获得公开批准。
调查打印失败消息但以代码 0 退出的 CI 门禁。
审查安全扫描结果、grep 查找结果、API 凭证、硬编码秘密以及潜在的误导性匹配。
检查所谓的已修复问题是否同时具有实际行为更改和通过的回归测试。
将本地功能与生产部署、API 可用性与经过身份验证的访问、技术能力与外部审批区分开来。
测量不应从文档中推断出的网络限制、DNS 行为、数值不变量、随机性和其他声明。
为工程审查、发布门禁或合规证据生成可审计的声明总账和观察清单。

工作原理

按权威性对证据来源进行排序：可执行命令和测试优先，规范的项目计划次之，技术文档第三，历史审计报告第四，README 最后。
将每个重要陈述转换为带有来源、验证命令、预期结果、成本、决策和残余风险的显式声明。
执行相关的门禁或测试，而不是从散文中推断其状态，然后记录精确的命令和退出状态码。
确认门禁在应该失败时失败；如果基础验证薄弱或针对损坏的数据运行，则成功的退出状态码是不够的。
分配三种状态之一：有证据执行时为 VERIFIED（已验证），未执行时为 UNVERIFIED（未验证），或者执行与声明相矛盾时为 REFUTED（被反驳）。
在责怪系统之前先检查测试框架。确认测试运行程序调用真实方法、使用有效夹具，并且其编辑方式不会改变结果。
在将本地缺陷泛化之前，阅读 grep 匹配的周围行并测试相邻的模块或系统组件。
在有意义的吞吐量下测量不变量，记录种子和随机数的使用情况，并在将不稳定的测量结果升级为诊断之前对其进行重复测量。
记录带有其来源层、产出组和文件行锚点的观察结果；当同一观察者执行读取和验证时，披露污染。
仅通过更改的行为、通过的测试和规范计划中的编号更新来关闭漏洞。保留被反驳的声明并明确记录任何推迟的事项。

配置指南

这是一个面向过程的 Openclaw 技能模块，而不是需要运行时依赖项的包。在代理的技能目录中安装或注册该技能，然后将其针对仓库或项目工作空间使用。
mkdir -p ~/.openclaw/skills/auditoria-por-ejecucion
cp SKILL.md ~/.openclaw/skills/auditoria-por-ejecucion/SKILL.md
在审计之前，检查可用的项目命令并识别规范的门禁：
find . -maxdepth 2 -type f ( -name 'package.json' -o -name 'Makefile' -o -name 'pyproject.toml' -o -name 'README*' ) -print
npm run
直接运行每个声明的验证命令并捕获其状态：
set +e
npm run verify:all
status=$?
printf 'exit_code=%s\n' "$status"
exit "$status"
使命令适应仓库的工具链。不要仅凭 README、旧审计、打印的裁决或呈现绿色的日志行就将声明标记为已验证。

数据架构

该技能将审计证据组织成两个互补的记录。
声明总账
字段 用途
ID 声明的稳定标识符
Claim 正在评估的精确陈述
Source 做出声明的文件、报告、问题或人员
Verification method 可执行命令、测试、检查或测量
Cost 验证所需的估计秒数或分钟数
Decision verificar 或 diferir
Result 观察到的输出、退出状态码和解释
Residual risk 仍然未知或可能不安全的内容
观察清单
字段 用途
ID 稳定的观察标识符
Source 证据的来源
Layer code、execution、reading、config、output 或 external docs
Group 产生观察结果的观察者或进程
Anchor 适用的精确 file:line 引用
Observation 具体、可复现的发现
每个声明都应分类为 VERIFIED、UNVERIFIED 或 REFUTED。最终摘要应报告每个状态的计数、解释推迟的检查、识别主要的残余风险，并在由同一观察者执行读取和验证时包含污染说明。未实现的功能必须保留 file:line 标注，而不是表现为已完成的功能。

高级特性

退出状态码优先的验证，可检测虚假绿色门禁和在没有相应非零进程状态的情况下打印的裁决。
三状态证据处理，保留被反驳的结果而不是删除不便的发现。
框架优先的调试，以区分损坏的测试基础设施和损坏的应用程序代码。
通过观察层、产出组和污染说明进行独立性跟踪。
相邻测试，可防止一个模块中的缺陷被错误地泛化到整个系统。
基于流量的不变量测试，用于数值声明，包括随机种子和蒙特卡洛行为的可复现性检查。
针对功能、商业、部署、身份验证和外部审批声明的单独报告。
在宣称存在系统性瓶颈之前，对网络、DNS、API 和基础设施限制进行重复测量。
安全感知的 grep 查找结果处理，在报告表面上的秘密之前需要进行行级检查。
发布和交易安全门禁，区分软件在技术上能做什么与外部系统或审批允许做什么。
证据保留的漏洞管理，需要行为、测试和规范计划更新，而不是状态行编辑。

name: auditoria-por-ejecucion description: Usar cuando un repositorio, documento o informe declare una garantia que un gate deberia comprobar — "los tests pasan", "el deploy esta automatizado", "el panel muestra X", "esta publicado", "no hay vulnabilidades". Sirve para auditing de codigo de terceros, para revisar la propia documentacion del proyecto, y para no repetir la clase de fallo mas comun que existe en software: una afirmacion, un chequeo, y el hueco entre ambos. Medir ejecutando el comando; juzgar por codigo de salida y no por prosa. Nace de medir cuatro proyectos reales — alpha-beth-lab (validate_corpus.mjs imprimia "VERDICT: CORRUPT" y salia 0, y npm run verify:all pasaba entero con exit 0), GlobalCorp (README con 4 deploy stub, dos paneles de Grafana con metricas que el codigo nunca emite, scanners de seguridad con || true), Proyecto Sabermetria (claim-graph + observation-manifest + verification-economics) y Api openfootball (ledger con "Do not claim public marketplace approval without evidence").

Auditoria por ejecucion

La prosa afirma. El codigo hace. Cuando los dos discrepan, el codigo gana.

Este skill existe porque los cuatro proyectos de donde salen todos fallaron de la misma manera: no mintieron por descuido, mintieron porque nadie ejecuto el comando. Un gate que imprime un veredicto negativo y sale con codigo 0 es peor que no tener gate: un && y un CI lo leen como verde.

0. Orden de autoridad

Cuando dos fuentes discrepan, gana la de arriba:

Comandos ejecutables y tests — evidencia primaria. Ejecutalos; no infieras de la prosa.
El backlog/plan canonico del proyecto (registro, gates, matriz de brechas).
La documentacion tecnica (audit, architecture, runbooks).
Los informes de auditoria antiguos — solo historico. Contienen metricas y estados contradictorios. Nunca citarlos como estado actual.
El README — resumen, no fuente de verdad.

1. El codigo de salida es la verdad

Antes de reportar un gate como sano, correrlo y mirar el exit code. Imprimir VERDICT: FAIL y salir 0 es un defecto, no una excepcion.

Caso medido: research/validate_corpus.mjs de alpha-beth-lab imprimia VERDICT: CORRUPT — DO NOT COMPUTE ELS ON THIS sobre un corpus declarado corrupto, escribia el veredicto a disco y no tenia ni una llamada a process.exit. La cadena npm run verify:all (&& de 4 pasos) pasaba entera con exit 0 mostrando los FAIL, y encima corria SITE VERIFICATION: ALL CHECKS PASSED. assertClean existia y estaba probada. El script nunca la invocaba.

Corolario en la otra direccion: un gate que sale con codigo 0 tambien puede estar roto si su unica comprobacion fuerte pasa sobre datos corruptos. Verificar que el gate falla cuando debe.

2. Tres estados, no dos

Estado Significa Como se marca

VERIFICADO Ejecutado. Con comando y codigo de salida. ID + comando + exit code
NO VERIFICADO No ejecutado. > UNVERIFIED explicito
REFUTADO Ejecutado y el resultado fue contrario. Se conserva, no se borra

El estado "no verificado" no es vergonzoso. Lo vergonzoso es llamarlo verificado.

3. Ledger de claims

Una fila por afirmacion. El coste se cifra en segundos o minutos.

| ID | Afirmacion | Fuente | Como se verifica | Coste | Decision | Resultado | Riesgo residual |

Decision ∈ {verificar, diferir}. "Diferir" es legitimo cuando el riesgo del error es bajo — pero se escribe el riesgo residual, no se omite la fila.
Resumen honesto del ledger: cuantos verificados, cuantos diferidos y por que, y cual es el riesgo residual principal ("la precision NO esta validada contra resultados reales" / "no existe edge validado"). 4. Manifiesto de observaciones con independencia

Una fila por observacion, con la capa y el grupo que la produjo:

| ID | Fuente | Capa | Grupo | Ancla (file:line) | Observacion |

Capa: codigo / ejecucion / lectura / config / output / docs externas.
Grupo: quien produjo la observacion. Sirve para detectar que dos confirmaciones no son independientes.
Contamination notes (seccion obligatoria): si el mismo observador hizo la lectura y la verificacion, se declara y se mitiga separando fases — leer ANTES de verificar por codigo.

Ejemplo textual: "Grupo ejecucion y lectura ejecutados por el mismo observador — mitigado por separacion de fases".

5. Sospecha del harness primero

Cuando un verificador falla, la primera hipotesis es que el verificador esta roto, no lo verificado. Y documentar que el harness fue editado antes de producir el resultado final.

Caso medido: el reporte deia "MotorEstadistico crashea en todos los pares". El motor importado y corrido pasaba. El harness llamaba a calcular_probabilidad_poisson, un metodo inexistente.

6. Un grep que encuentra algo hay que leerlo

Falso positivo de seguridad clasico: grep hardcoded_api_key -> 2 hits que parecian claves reales. Eran "your_api_key_here" en docstrings. Antes de reportar un hallazgo de grep, leer las lineas.

7. Prueba el vecindario antes de acusar al sistema

Un bug verificado en un modulo no prueba que el sistema este roto. Medir el entorno distingue "un archivo mal" de "todo el sistema mal" — y esa distincion cambia por completo la prioridad del trabajo.

Caso medido: el predictor de un proyecto daba probabilidades que sumaban 1 + draw. El otro motor daba 0.5193 + 0.2345 + 0.2462 = 1.0. Un archivo mal, no el sistema.

8. Invariantes numericos: volumen, no juicio

Un invariante se demuestra con volumen. "Suma 1" verificado con 15.000 pares y 15.000 fallos es un hecho; con 3 ejemplos es una anécdota. Para reproducibilidad: contar usos de np.random y seeds — 37 usos y 0 seeds significa Monte Carlo no reproducible.

9. Cerrar una brecha es comportamiento + test

Nunca marcar una brecha cerrada editando solo su linea de estado. Cerrar = un cambio de comportamiento + un test que pase + un registro numerado en el plan. Un stub documentado como feature es una regresion.

Todo lo no implementado lleva un callout con file:line.

10. Afirmaciones separadas

"Funcional" y "rentable" son afirmaciones separadas y se reportan por separado. Lo mismo para: "funciona en local" / "esta desplegado"; "el gate existe" / "el gate cablea su veredicto al exit code"; "la API responde" / "la API responde con tus credenciales".

11. No afirmes lo externo sin evidencia

Si un tercero —proveedor, plataforma, marketplace, aprobacion— no ha aprobado, se reporta pendiente/privado nombrando el bloqueo externo. Nunca "aprobado".

Caso medido: un pipeline de trading con cuatro gates secuenciales, regla "[REGLA INQUEBRANTABLE: No avanzar sin pasar el anterior. NO EXCEPCIONES.]", y el trading en vivo hard-bloqueado en el motor, no solo en el CLI. La separacion entre "lo que puedo hacer" y "lo que me dejan hacer" es una feature de seguridad, no una limitacion.

12. No afirmes una restriccion sin medirla

Regla adoptada tras refutar la propia: "never assert a network constraint you have not measured". Un allowlist de cuatro dominios derivado por intuicion; al medir, 28 de 64 hosts resolvian.

Igual con las cifras del propio estado: un snapshot es un snapshot. Repetir la medicion antes de escalarla a diagnostico. (Un RCODE 5 transitorio de DNS me llevo a "cuello de botella gravisimo" en una sesion; al repetir, ambos resolvers respondian y la API dava 200.)

Checklist de una linea

¿Ejecute el comando? ¿Lei el exit code? ¿El gate falla cuando debe? ¿Separo verificado / no verificado / refutado? ¿Declaro la contaminacion de mis propias observaciones? ¿Cierro con comportamiento + test o solo con una linea de estado?

SameDayDesk Task Result

使用 Scavio 进行网站爬取