Etiquetas
Referencia única para cada etiqueta utilizada en PRs y issues. Fuentes de verdad:
.github/labeler.yml: configuración de etiquetas por ruta consumida poractions/labeler.github/label-policy.json: umbrales de nivel de contribuidor- Esta página: definiciones, comportamiento y qué está automatizado frente a qué es manual
Cuando las definiciones entren en conflicto, actualiza primero el archivo de origen y luego sincroniza esta página.
Límites de propiedad
Las etiquetas son metadatos portables. Deben responder qué tipo de trabajo es, qué área del código afecta, qué tan arriesgado es revisarlo y si la política de obsolescencia o la política de clasificación requieren un manejo especial.
La automatización del tablero del proyecto es una ayuda de planificación, no una segunda cola de revisión de PR. El planificador actual del issue-dashboard es manual y solo genera informes. El tablero debe responder a preguntas de planificación de evolución más lenta: qué está listo para tomar, qué evidencia de enrutamiento lo mantiene activo, a qué tracker o hito pertenece y qué está bloqueado. El estado nativo de PR de GitHub debe seguir respondiendo a las preguntas de revisión y fusión de evolución más rápida.
Mantén la división basada en la frecuencia de actualización:
- Las etiquetas implican su propia clasificación duradera: tipo de trabajo, alcance/componente, riesgo de revisión, tamaño de PR medido y exención de obsolescencia.
- Los campos del panel de proyecto son adecuados para la etapa de planificación de incidencias, la evidencia visible de enrutamiento, el estado de dependencias, el motivo de exención por inactividad y la agrupación de hoja de ruta cuando esos campos se mantienen activamente.
- El estado nativo de la PR de GitHub controla el estado de revisión que cambia rápidamente: decisión de revisión, comprobaciones requeridas, capacidad de fusión, conflictos y aprobaciones obsoletas.
El tablero debería reducir el trabajo de los maintainers. Si un campo requiriera mantenimiento manual después de cada push o revisión de PR, es preferible usar labels, milestones o el estado nativo de GitHub en su lugar.
Las etiquetas pueden sugerir un enrutamiento probable, pero no implican propiedad. Una etiqueta channel:*, provider:*, tool:*, security o docs identifica la superficie que probablemente necesite atención. Las reglas de evidencia de enrutamiento visibles para los colaboradores se encuentran en el Contrato del tablero del proyecto.
Usa los responsables asignados para el trabajo activo. Usa comentarios de la incidencia, secciones del cuerpo de la incidencia, campos públicos o rastreadores vinculados como evidencia de enrutamiento cuando un estado especial de obsolescencia, rastreador o decisión diferida necesite explicación. status:blocked usa la regla de bloqueador registrado. El contrato del tablero del proyecto define las fuentes de evidencia aceptadas y los resultados de enrutamiento.
Ortografía canónica
Usa la ortografía con dos puntos sin espacio para las etiquetas con ámbito: provider:openai, channel:telegram, security:policy, risk:high, size:XS, type:docs y etiquetas similares. Las etiquetas sin un espacio de nombres siguen con forma de frase: good first issue, help wanted, trusted contributor y stale-candidate.
Las etiquetas duplicadas heredadas como provider: openai, channel: telegram o tool: shell son candidatas a limpieza. Las etiquetas en vivo con espacio como risk: high, size: XS y type: docs son candidatas a migración ahora que el paquete aprobado ha creado o confirmado las etiquetas canónicas sin espacio.
Algunas etiquetas heredadas pueden seguir activas durante una migración por fases. Las aplicaciones nuevas o manuales deben usar las etiquetas canónicas sin espacios, mientras que las referencias abiertas heredadas existentes pueden permanecer hasta que el paquete de migración de referencias abiertas las procese. Migre los issues/PR abiertos a la etiqueta canónica antes de eliminarlas. No elimine etiquetas con referencias abiertas, no renombre de forma general familias de etiquetas ni quite etiquetas de política obsoleta sin una decisión de un mantenedor para ese lote de limpieza.
Contrato de automatización
La automatización de etiquetas de PR en vivo está dividida por origen. pr-path-labeler.yml ejecuta actions/labeler desde .github/labeler.yml cuando se abre o reabre un PR y en cada actualización enviada. Dado que ese flujo de trabajo usa sync-labels: true, las etiquetas gestionadas por .github/labeler.yml se recalculan a partir del conjunto actual de archivos del PR: se añaden las etiquetas de ruta que coinciden y se eliminan las etiquetas de ruta que ya no coinciden.
Dependabot también añade las etiquetas configuradas en sus propios PRs a partir de .github/dependabot.yml: las actualizaciones de Cargo reciben dependencies; las actualizaciones de GitHub Actions y Docker reciben ci y dependencies. Esas etiquetas son metadatos iniciales de los PRs de Dependabot, no el contrato sincronizado del path-labeler.
Hoy en día, .github/labeler.yml solo gestiona etiquetas de rutas y ámbitos como docs, ci, channel, provider:openai y tool:file. No gestiona las etiquetas risk:*, size:*, type:*, de nivel de colaborador, de estado, de resolución, de inactividad ni de asignación.
La automatización del tamaño puede volver a calcularse con cada actualización enviada de una PR, de modo que las etiquetas sigan describiendo el diff real que se está revisando. #9345 gestiona el despliegue independiente del clasificador de riesgos. Su fase de riesgos seguirá siendo solo informativa hasta que los mantenedores revisen las pruebas y habiliten por separado la mutación. La salida del modo de solo informe debe registrar el riesgo propuesto, las pruebas de las reglas coincidentes, el riesgo actual, el estado de risk:manual y el estado de domain:security, para que los mantenedores puedan auditar las discrepancias y el trabajo relacionado con la seguridad que haya escapado a ambos activadores. Cualquier automatización futura de riesgos debe respetar risk:manual como un bloqueo estricto: no puede añadir, eliminar ni reemplazar la etiqueta risk:* de una PR hasta que un mantenedor quite la anulación.
Protocolo de limpieza
La limpieza de etiquetas es una acción del maintainer, no un efecto secundario de la revisión normal de PR.
Usa esta secuencia:
- Actualiza el uso de etiquetas en vivo antes de actuar.
- Divide los candidatos en eliminaciones sin historial, eliminaciones de duplicados sin elementos abiertos, etiquetas activas que requieren migración previa y retenciones por políticas.
- Para las etiquetas con referencias abiertas, después de que el lote de limpieza aprobado cree o confirme la etiqueta canónica, agrega la etiqueta canónica a cada issue/PR abierto, quita la etiqueta heredada, verifica que la etiqueta heredada tenga cero referencias abiertas y, luego, elimínala.
- No elimine las etiquetas de gobernanza, las etiquetas de política de obsolescencia, las etiquetas de nivel de colaborador ni las etiquetas predeterminadas de GitHub como parte de la limpieza de etiquetas de módulo.
Cada lote de limpieza en vivo necesita la aprobación exacta del maintainer para las etiquetas y las referencias de issue/PR que se modifican.
Retenciones de política
Algunas familias de etiquetas están intencionalmente fuera de la limpieza mecánica, incluso cuando parecen inconsistentes con preferencias más recientes de ortografía o taxonomía. Solo deben cambiarse después de una decisión de política aparte y de un paquete exacto de operación en vivo.
| Familia | La acción del mantenedor actual que admite | Antes de cambiar las etiquetas en vivo |
|---|---|---|
| Etiquetas de terminal y resolución | Explica por qué el trabajo salió de la cola activa: no perseguido, inválido, duplicado o rechazado explícitamente. | Preserve el significado histórico de cierre y las expectativas de los colaboradores; defina cualquier paquete de cambio de nombre, alias, migración o eliminación antes de mutar etiquetas activas. La sustitución y la superación siguen siendo procesos documentados, salvo que un paquete aprobado posterior cree o asigne una etiqueta activa. |
| Estado y etiquetas obsoletas | Ciclo de vida de los issues de Drive y comportamiento de obsolescencia, incluyendo trabajo aceptado, bloqueadores, implementación activa, status:stale, status:no-stale y el manejo de obsolescencia del backlog de PR. | Trátalo como policy-first porque la automatización puede proteger, advertir o cerrar issues de forma diferente. No cambies estas labels como limpieza cosmética o de module-label; gestionalas mediante un paquete de policy stale/lifecycle que tenga en cuenta la automatización y las reglas de evidence de routing. |
| Etiquetas de nivel de colaborador | Indica la confianza de los revisores y la experiencia de los colaboradores mediante los umbrales de .github/label-policy.json. | Actualiza el archivo de directiva y esta guía juntos; no elimines ni renombres niveles como limpieza cosmética porque las etiquetas afectan a las personas y al enrutamiento de revisión. |
| Etiquetas predeterminadas de GitHub | Conserva puntos de entrada familiares para contribuyentes como bug, enhancement, documentation y question. | Reemplace o retire solo mediante una decisión explícita de taxonomía dirigida a los colaboradores. Los valores predeterminados pueden ser utilizados por plantillas, búsquedas, enlaces externos e integraciones. |
La prueba para mantener una etiqueta sensible activa es operativa: ¿pueden los mantenedores nombrar una acción real que se vuelva más difícil si la etiqueta activa desaparece? Si sí, consérvela o reemplácela deliberadamente. Si no, preserve la asignación histórica en el paquete de auditoría y migre o elimínela mediante la operación aprobada.
Etiquetas de tipo
Las etiquetas de tipo capturan la clase de trabajo de alto nivel. Son independientes de las etiquetas de ruta como docs, ci o dependencies.
Las aplicaciones nuevas o manuales deben usar las etiquetas canónicas sin espacios de abajo cuando exista la etiqueta en vivo. Las referencias abiertas heredadas existentes pueden mantener las etiquetas con espacios hasta que el paquete de migración de referencias abiertas las gestione; consulte Ortografía canónica.
type:tracker es la grafía canónica del marcador de seguimiento para problemas activos de coordinación con el elemento principal. No crees ni apliques roadmap, type:roadmap ni otro marcador de seguimiento como alias. Si la etiqueta en vivo type:tracker aún no existe, la creación de la etiqueta y cualquier migración de marcador de seguimiento deben realizarse solo mediante un paquete separado exacto aprobado por el mantenedor.
| Etiqueta | Propósito |
|---|---|
type:ci | Trabajo de CI, flujos de trabajo o automatización de repositorios |
type:dependencies | Mantenimiento de dependencias o del archivo lock |
type:docs | Trabajo exclusivo o principalmente de documentación |
type:rfc | Issue o propuesta de RFC; protegido del cierre por inactividad mientras esté activo |
type:refactor | Limpieza de la estructura del código o reorganización interna destinada a preservar el comportamiento visible para el usuario |
type:test | Trabajo solo de pruebas o principalmente de pruebas |
type:tracker | Problema de coordinación activa del elemento principal para una release, roadmap, hilo RFC/diseño, lote de implementación, limpieza o auditoría. Marcador solo de issue; por sí mismo no crea protección contra obsolescencia, asignación, aceptación ni alcance listo para contribución. |
Etiquetas de ruta
Aplicado automáticamente por pr-path-labeler.yml. Los globs se encuentran en .github/labeler.yml; cuando esta página y la configuración no coincidan, considera .github/labeler.yml como la fuente operativa y actualiza esta página.
Etiquetas de ámbito base
| Etiqueta | Coincidencias |
|---|---|
docs | docs/**, **/*.md, **/*.mdx, LICENSE, .markdownlint-cli2.yaml |
dependencies | Cargo.toml, **/Cargo.toml, Cargo.lock, **/Cargo.lock, deny.toml, .github/dependabot.yml |
ci | .github/codeql/**, .github/workflows/**, .github/*.yaml, .github/*.yml, .github/*.json, .githooks/** |
core | src/*.rs |
cli | src/main.rs, src/lib.rs, src/commands/**, src/alias_cli/**, src/cli_input.rs, src/memory/cli.rs (el comando zeroclaw memory), crates/zeroclaw-commands/**, crates/zeroclaw-runtime/src/cli_input.rs. |
agent | src/agent/**, crates/zeroclaw-runtime/src/agent/** |
channel | src/channels/**, crates/zeroclaw-channels/src/** |
gateway | src/gateway/**, crates/zeroclaw-gateway/src/** |
config | src/config/**, crates/zeroclaw-config/src/** |
cron | src/cron/**, crates/zeroclaw-runtime/src/cron/** |
daemon | src/daemon/**, crates/zeroclaw-runtime/src/daemon/** |
doctor | src/doctor/**, crates/zeroclaw-runtime/src/doctor/** |
health | src/health/**, crates/zeroclaw-runtime/src/health/** |
heartbeat | src/heartbeat/**, crates/zeroclaw-runtime/src/heartbeat/** |
integration | src/integrations/**, crates/zeroclaw-runtime/src/integrations/** |
memory | src/memory/**, crates/zeroclaw-memory/src/** |
security | src/security/**, crates/zeroclaw-runtime/src/security/** |
runtime | src/runtime/**, crates/zeroclaw-runtime/src/** |
quickstart | crates/zeroclaw-runtime/src/quickstart/**, crates/zeroclaw-gateway/src/api_quickstart.rs, apps/zerocode/src/quickstart_pane.rs, web/src/pages/quickstart/** |
desktop | apps/tauri/** |
hardware | src/hardware/**, src/peripherals/mod.rs, crates/zeroclaw-hardware/**, crates/zeroclaw-api/src/peripherals_traits.rs, firmware/** |
web | web/** |
zerocode | apps/zerocode/** |
provider | src/providers/**, crates/zeroclaw-providers/src/** |
service | src/service/**, crates/zeroclaw-runtime/src/service/** |
skills | src/skills/**, crates/zeroclaw-runtime/src/skills/** |
tool | src/tools/**, crates/zeroclaw-tools/src/** |
tunnel | src/tunnel/**, crates/zeroclaw-runtime/src/tunnel/** |
observability | src/observability/**, crates/zeroclaw-runtime/src/observability/** |
tests | tests/** |
scripts | scripts/** |
dev | dev/** |
ci está delimitado a archivos de automatización/configuración de GitHub, no a todas las rutas .github/**. El comparador raíz .github/*.json es intencional para metadatos de automatización (por ejemplo .github/label-policy.json), por lo que archivos como .github/assets/**, .github/ISSUE_TEMPLATE/**, .github/CODEOWNERS y .github/pull_request_template.md no coinciden con ci.
Etiquetas de componentes adicionales
Algunas superficies tienen etiquetas propiedad de ruta más estrechas para el enrutamiento de responsables de mantenimiento. Estas etiquetas se sincronizan mediante .github/labeler.yml cuando el diff del PR toca los archivos listados.
Las etiquetas de rutas acotadas no garantizan una etiqueta base con el mismo prefijo. Como pr-path-labeler.yml se ejecuta con sync-labels: true, los mantenedores deben tratar .github/labeler.yml como la fuente de verdad sobre qué etiquetas base y acotadas recibe un PR.
| Etiqueta | Coincidencias |
|---|---|
observability:log | crates/zeroclaw-log/src/**, crates/zeroclaw-runtime/src/observability/log.rs |
observability:otel | otel.rs, cobertura de regresión de la feature de dependencia de OTel |
observability:prometheus | prometheus.rs |
runtime:wasm | plataforma WASM en tiempo de ejecución y archivos del host de complementos WASM de primera parte |
security:bubblewrap | bubblewrap.rs |
security:docker | docker.rs |
security:leak-detector | Redacción de LeakDetector y análisis de salida sensible |
security:pairing | seguridad de emparejamiento, API de emparejamiento de gateway, comando de emparejamiento de Tauri y página web de emparejamiento |
security:policy | archivos de política de seguridad en tiempo de ejecución, política IAM y política de configuración |
security:secrets | gestión de secretos en tiempo de ejecución y de configuración |
security:traits | definiciones compartidas de trait e interfaz de seguridad |
memory:backend | selección del backend de memoria y archivos de implementación de almacenamiento |
Etiquetas manuales de componentes
Algunas etiquetas de componentes con ámbito son etiquetas de enrutamiento manual en lugar de etiquetas de ruta sincronizadas.
domain:architecture identifica el trabajo relacionado con la responsabilidad entre componentes, la fuente de verdad, la dirección de las dependencias, la interfaz/contrato y las decisiones de arquitectura. No lo apliques únicamente porque una incidencia sea un RFC.
domain:security identifica un límite efectivo de autenticación, autorización, gestión de credenciales, gestión de secretos, aislamiento, permisos de herramientas, política de seguridad, identidad criptográfica o entradas no confiables. Aplícalo cuando el comportamiento modificado cruce ese límite, incluso fuera de las rutas de seguridad canónicas. No lo apliques únicamente porque una PR trate sobre seguridad, modifique documentación o pruebas de seguridad, actualice una dependencia con un aviso de seguridad o realice un refuerzo genérico sin cambiar un límite de confianza. La etiqueta sigue siendo manual porque la coincidencia de rutas no puede inferir esta consecuencia de forma fiable.
domain:security es independiente de risk:*. Un PR que incluya risk:high o domain:security requiere una revisión exhaustiva y dos aprobaciones independientes de Core Team antes de la fusión. La revisión automatizada no cuenta como una aprobación de Core Team.
Las siguientes etiquetas duplicadas de dominio y superficie del producto están pendientes de retirada. No las apliques a trabajos nuevos. Seguirán activas únicamente hasta que un paquete de operaciones exacto e independiente migre las referencias abiertas restantes y elimine las definiciones.
| Etiqueta en desuso | Reemplazo canónico |
|---|---|
domain:channels | channel más la etiqueta channel:* correspondiente |
domain:ci | type:ci; añade ci asociado a la ruta solo cuando los archivos modificados coincidan con su contrato de automatización |
domain:code-quality | Etiquetas de ámbito concretas además de type:refactor cuando corresponda |
domain:deps | dependencies y/o type:dependencies |
domain:web-fetch | tool:web |
tauri | desktop; Tauri sigue siendo un detalle de implementación en las rutas y los títulos |
Las etiquetas de producto conservadas son deliberadamente distintas. cli es la interfaz de línea de comandos para usuarios finales, mientras que channel:cli es el canal de chat interactivo de CLI. web es el panel del navegador y el producto de chat web, mientras que tool:web es el grupo de herramientas de obtención y búsqueda web del agente. zerocode es la aplicación de terminal ZeroCode, hardware abarca las integraciones con el host, los crates de soporte y el árbol del firmware, y desktop es el producto de escritorio de Tauri. Usa la etiqueta de herramienta o producto aplicable para el trabajo nativo de uso del ordenador fuera de apps/tauri/**; no apliques manualmente desktop sincronizado a una PR cuyas rutas no coincidan.
agent:prompt es para el prompt visible para el proveedor, el contexto y la política de orientación de respuesta. Úsalo cuando el trabajo trate sobre contenido del system prompt, orientación de formato de llamadas a herramientas, contexto sensible a la caché de prompts, orientación de respuesta del canal u otras superficies de instrucciones visibles para el modelo que crucen las etiquetas base agent, channel, memory, provider o runtime. Aplícalo además de las etiquetas base o de ámbito aplicables; no las reemplaza. No lo apliques a todos los cambios en crates/zeroclaw-runtime/src/agent/**; usa la etiqueta base agent para cambios ordinarios del runtime del agente.
agent:loop está retirado. Para el enrutamiento de agent-loop, use agent base más cualquier etiqueta coincidente de runtime, proveedor, canal, herramienta o riesgo.
No apliques el legado observability: runtime_trace a nuevos issues o PRs. Usa observability:otel cuando el trabajo trate de trazado de OpenTelemetry, añade observability base solo cuando el issue o PR también coincida con esa superficie base, y decide cualquier futura etiqueta canónica específica de runtime trace en un paquete aparte de crear/migrar.
No apliques el heredado security: leak_detector a nuevos issues o PRs. Usa security:leak-detector para el trabajo de redacción de LeakDetector y de escaneo de salida sensible.
Las etiquetas de subárea de Gateway como gateway: api, gateway: sse, gateway:local_bridge y gateway:webhook_ingress siguen siendo retenciones para la migración en vivo. El enrutamiento nuevo debe usar la base gateway hasta que un paquete independiente cree subetiquetas canónicas sin espacios/guionadas y migre las referencias, o colapse esas etiquetas en la base gateway.
Etiquetas por canal
Cada canal recibe una etiqueta channel:<name> además de la etiqueta base channel cuando el cambio toca rutas del crate del canal. Las etiquetas de canal entre superficies, como channel:acp, pueden en su lugar emparejarse con la etiqueta base de la superficie correspondiente, como gateway, docs o etiquetas de ámbito de app/web.
channel:core es la API de canal compartida y la etiqueta del orquestador. Úsalo para trabajo en contratos de traits de canal, orquestación de canales, hooks de entrega, comportamiento de enrutamiento/sesión, manejo de comandos en tiempo de ejecución y comportamiento entre canales que sería engañoso bajo una sola etiqueta de plataforma.
| Etiqueta | Coincidencias |
|---|---|
channel:acp | acp_channel.rs, acp_server.rs, zeroclaw-acp-bridge.rs, acp_session_store.rs, channels/acp.md, puntos de entrada seleccionados del gateway/app/web de ACP |
channel:core | crates/zeroclaw-api/src/channel.rs, crates/zeroclaw-channels/src/lib.rs, crates/zeroclaw-channels/src/orchestrator/**, src/channels/mod.rs |
channel:bluesky | bluesky.rs |
channel:clawdtalk | clawdtalk.rs |
channel:cli | cli.rs |
channel:dingtalk | dingtalk.rs |
channel:discord | discord.rs, discord_history.rs |
channel:email | email_channel.rs, gmail_push.rs |
channel:imessage | imessage.rs |
channel:irc | irc.rs |
channel:lark | lark.rs |
channel:line | line.rs, channels/line.md |
channel:linq | linq.rs |
channel:matrix | matrix.rs |
channel:mattermost | mattermost.rs |
channel:mochat | mochat.rs |
channel:mqtt | mqtt.rs |
channel:nextcloud-talk | nextcloud_talk.rs |
channel:nostr | nostr.rs |
channel:notion | notion.rs |
channel:qq | qq.rs |
channel:reddit | reddit.rs |
channel:signal | signal.rs |
channel:slack | slack.rs |
channel:telegram | telegram.rs |
channel:twitter | twitter.rs |
channel:wechat | crates/zeroclaw-channels/src/wechat.rs |
channel:webhook | webhook.rs |
channel:wecom | wecom.rs, wecom_ws.rs |
channel:whatsapp | whatsapp.rs, whatsapp_storage.rs, whatsapp_web.rs |
Etiquetas por proveedor
Las etiquetas específicas del proveedor coinciden con los archivos fuente dedicados de cada proveedor. El enrutador de proveedores tiene su propia etiqueta con ámbito porque el trabajo de enrutamiento y despacho de modelos es una subárea compartida de proveedores, no una integración concreta de un proveedor. Los archivos compartidos de registro o fábrica deben recibir solo la etiqueta base provider; los mantenedores pueden añadir manualmente una etiqueta específica de proveedor cuando un cambio en un archivo compartido esté realmente acotado a un solo proveedor.
| Etiqueta | Coincidencias |
|---|---|
provider:anthropic | anthropic.rs |
provider:azure-openai | azure_openai.rs |
provider:bedrock | bedrock.rs |
provider:claude-code | claude_code.rs |
provider:compatible | compatible.rs |
provider:copilot | copilot.rs |
provider:gemini | gemini.rs, gemini_cli.rs |
provider:glm | glm.rs |
provider:kilocli | kilocli.rs |
provider:ollama | ollama.rs |
provider:openai | openai.rs, openai_codex.rs |
provider:openrouter | openrouter.rs |
provider:reliable | reliable.rs |
provider:router | router.rs |
provider:telnyx | telnyx.rs |
Algunas etiquetas de proveedor describen familias de proveedores que actualmente comparten la implementación de proveedor compatible con OpenAI en lugar de un archivo de origen dedicado. Los mantenedores pueden aplicarlas manualmente cuando un problema o PR trata realmente sobre esa familia: provider:groq, provider:kimi, provider:minimax, provider:moonshot y provider:qwen. No añada reglas de etiquetado para archivos de factoría compartida o de proveedor compatible; eso etiquetaría en exceso cambios compartidos no relacionados.
Etiquetas por grupo de herramientas
Las herramientas se agrupan por función lógica en lugar de tener una etiqueta por archivo.
| Etiqueta | Coincidencias |
|---|---|
tool:browser | browser.rs, browser_delegate.rs, browser_open.rs, text_browser.rs, screenshot.rs |
tool:cloud | cloud_ops.rs, cloud_patterns.rs |
tool:composio | composio.rs |
tool:cron | src/tools/cron_add.rs, src/tools/cron_list.rs, src/tools/cron_remove.rs, src/tools/cron_run.rs, src/tools/cron_runs.rs, src/tools/cron_update.rs, crates/zeroclaw-runtime/src/tools/cron_add.rs, crates/zeroclaw-runtime/src/tools/cron_common.rs, crates/zeroclaw-runtime/src/tools/cron_list.rs, crates/zeroclaw-runtime/src/tools/cron_remove.rs, crates/zeroclaw-runtime/src/tools/cron_run.rs, crates/zeroclaw-runtime/src/tools/cron_runs.rs, crates/zeroclaw-runtime/src/tools/cron_update.rs |
tool:delegate | crates/zeroclaw-runtime/src/tools/delegate.rs |
tool:file | src/tools/file_edit.rs, src/tools/file_read.rs, src/tools/file_write.rs, src/tools/glob_search.rs, src/tools/content_search.rs, crates/zeroclaw-tools/src/file_edit.rs, crates/zeroclaw-runtime/src/tools/file_read.rs, crates/zeroclaw-tools/src/file_write.rs, crates/zeroclaw-tools/src/glob_search.rs, crates/zeroclaw-tools/src/content_search.rs |
tool:google-workspace | google_workspace.rs |
tool:mcp | mcp_client.rs, mcp_deferred.rs, mcp_protocol.rs, mcp_tool.rs, mcp_transport.rs |
tool:memory | memory_forget.rs, memory_recall.rs, memory_store.rs |
tool:microsoft365 | microsoft365/** |
tool:pushover | pushover.rs |
tool:security | src/tools/security_ops.rs, src/tools/verifiable_intent.rs, crates/zeroclaw-runtime/src/tools/security_ops.rs, crates/zeroclaw-runtime/src/tools/verifiable_intent.rs |
tool:shell | src/tools/shell.rs, src/tools/node_tool.rs, src/tools/cli_discovery.rs, crates/zeroclaw-runtime/src/tools/shell.rs, crates/zeroclaw-gateway/src/node_tool.rs, crates/zeroclaw-tools/src/cli_discovery.rs |
tool:sop | src/tools/sop_advance.rs, src/tools/sop_approve.rs, src/tools/sop_execute.rs, src/tools/sop_list.rs, src/tools/sop_status.rs, crates/zeroclaw-runtime/src/tools/sop_advance.rs, crates/zeroclaw-runtime/src/tools/sop_approve.rs, crates/zeroclaw-runtime/src/tools/sop_execute.rs, crates/zeroclaw-runtime/src/tools/sop_list.rs, crates/zeroclaw-runtime/src/tools/sop_status.rs |
tool:web | web_fetch.rs, web_search_tool.rs, web_search_provider_routing.rs, http_request.rs |
tool:schema es una etiqueta solo manual para problemas de serialización y limpieza de tool-schema. No agregues archivos de esquema amplios a .github/labeler.yml; muchos archivos de esquema son configuración compartida, proveedores o superficies de API, y etiquetarían en exceso cambios no relacionados.
Etiquetas de tamaño
Basado en el recuento efectivo de líneas modificadas, normalizado para PRs de solo documentación y PRs con muchos archivos de bloqueo. Actualmente se aplica de forma manual; la automatización de tamaño que anteriormente calculaba estos valores se eliminó durante la simplificación de CI. La futura automatización de tamaño debe seguir el contrato de automatización.
Las aplicaciones nuevas o manuales deben usar las etiquetas canónicas sin espacios que se indican a continuación. Las referencias abiertas heredadas existentes pueden conservar las etiquetas con espacios hasta que el paquete de migración de referencias abiertas las procese; consulte Ortografía canónica.
| Etiqueta | Umbral |
|---|---|
size:XS | ≤ 80 líneas |
size:S | ≤ 250 líneas |
size:M | ≤ 500 líneas |
size:L | ≤ 1000 líneas |
size:XL | > 1000 líneas |
Etiquetas de riesgo
Para los PRs, las etiquetas de riesgo describen el diff real bajo revisión: rutas modificadas, cambio de comportamiento, exposición de límites de seguridad y dificultad de rollback. Para los issues, las etiquetas de riesgo describen el radio de impacto probable de la corrección según el reporte, ayudan a clasificar la profundidad de revisión y la idoneidad del contribuidor, y pueden cambiar una vez que un PR concreto muestre la ruta de implementación real. Actualmente se aplican manualmente. La futura automatización de riesgos debe seguir el contrato de automatización.
Las aplicaciones nuevas o manuales deben usar las etiquetas canónicas sin espacios que se indican a continuación. Las referencias abiertas heredadas existentes pueden conservar las etiquetas con espacios hasta que el paquete de migración de referencias abiertas las procese; consulte Ortografía canónica.
| Etiqueta | Significado |
|---|---|
risk:low | Documentación, localización, fixtures, referencias generadas o metadatos mecánicos sin efecto en producción, compatibilidad, compilación, lanzamiento o gobernanza |
risk:medium | Cambio de comportamiento habitual en producción, incluido la mayor parte del trabajo relacionado con el tiempo de ejecución, las puertas de enlace, los proveedores, los canales, las herramientas, la configuración, las aplicaciones y CI |
risk:high | Un límite concreto de confianza, credenciales, compatibilidad, gobernanza o autoridad de lanzamiento que requiere una revisión exhaustiva y dos aprobaciones independientes del Core Team |
risk:manual | Anulación del mantenedor que congela las futuras sustituciones automatizadas de riesgos; no reduce los requisitos de revisión o aprobación |
risk:* describe el diff real y su consecuencia, no la ubicación general del componente. Un cambio inocuo para producción y exclusivo de pruebas dentro de un límite de alto riesgo puede ser risk:medium cuando se pueda demostrar que el límite completo es exclusivo de pruebas; #9530 es la referencia autorizada para esa excepción.
Usa risk:manual siempre que el riesgo previsto por un mantenedor difiera de un resultado automático futuro, incluida la degradación exclusiva de las pruebas de #9530, demostrablemente inerte en producción. Aplica risk:high junto con risk:manual cuando un cambio que no sea de seguridad tenga una consecuencia destructiva, de pérdida de datos, de cambio incompatible del valor predeterminado, de gobernanza, de seguridad de la versión u otra consecuencia concreta de alto riesgo fuera de las reglas automáticas estables. Esto conserva la ruta de escalado manual aceptada en lugar de crear otra familia de etiquetas. Registra la justificación en el registro de la revisión o del PR.
Cuando haya incertidumbre, clasifica en la categoría superior y pide a un responsable de mantenimiento que resuelva el límite. No amplíes las reglas automáticas de rutas simplemente para evitar una decisión de revisión.
Etiquetas de nivel de colaborador
Definido en .github/label-policy.json. Basado en el conteo de PRs fusionados del autor consultado desde la API de GitHub. Actualmente se aplica manualmente.
| Etiqueta | Mínimo de PRs fusionados |
|---|---|
colaborador de confianza | 5 |
contributor experimentado | 10 |
contributor principal | 20 |
colaborador distinguido | 50 |
Etiquetas de prioridad
Las etiquetas de prioridad expresan la urgencia de planificación de los mantenedores, no la responsabilidad ni el estado de implementación. Aplíquelas manualmente y vuelva a evaluarlas cuando cambie el impacto del problema o el contexto de la versión.
| Etiqueta | Significado |
|---|---|
priority:p0 | Bloqueador inmediato que requiere la atención urgente de los mantenedores; excluido de la gestión de incidencias inactivas mientras la prioridad siga vigente |
priority:p1 | Trabajo de alta prioridad que se debe programar antes de la cola normal |
priority:p2 | Trabajo de prioridad media con un interés claro del mantenedor |
priority:p3 | Trabajo registrado de menor prioridad sin un compromiso de planificación urgente |
Etiquetas de estado
Realiza un seguimiento del estado del ciclo de vida de los RFC y los elementos de trabajo monitoreados. Se aplica manualmente, a menos que un flujo de trabajo mantenido indique lo contrario.
| Etiqueta | Descripción |
|---|---|
status:accepted | RFC o elemento de trabajo ratificado por el equipo. Esto no exime al issue del tratamiento por inactividad por sí mismo. |
status:blocked | El trabajo es válido pero está a la espera de una dependencia externa, una decisión del responsable o un prerrequisito vinculado. Exento de marcarse como inactivo mientras el bloqueante esté registrado y sin resolver. No combinar con status:no-stale para el mismo bloqueante. |
status:in-progress | Un PR abierto está abordando activamente este issue. Reconcilia con el estado actual del PR durante las pasadas de obsolescencia; la etiqueta no es una exención permanente después de que el PR se cierre. |
status:stale | El problema está en la ventana de respuesta definida por la política de problemas obsoletos |
status:no-stale | Exención explícita de obsolescencia para trabajo aceptado o de larga duración que no esté ya protegido por otra exclusión de obsolescencia. Política objetivo: úsala únicamente cuando el contrato del tablero del proyecto tenga una razón de exención de obsolescencia visible para los colaboradores y evidencia de enrutamiento. Los rastreadores de lanzamiento activos y los rastreadores de RFC o de diseño activos pueden usar el propio rastreador como la razón visible y la superficie de enrutamiento mientras permanezcan activos; revísalos cuando el hito se cierre, el rastreador se desvíe del estado actual, la RFC llegue a una decisión, sea reemplazada o se cierre, o cuando el issue deje de representar una superficie activa de decisión del proyecto. Las exenciones existentes que carezcan de esos datos deben auditarse y repararse antes de que los barridos de obsolescencia dejen de respetarlas. |
Política de incidencias inactivas
Esta sección es la fuente operativa canónica para la temporización de inactividad de issues, la actividad que califica, las exclusiones y la reactivación. Otros documentos y skills para responsables del proyecto deberían enlazar aquí en lugar de copiar estas reglas.
- Ventana de entrada: Aplica
status:staleuna vez transcurridos 15 días o más sin actividad válida. - Ventana de respuesta: Cerrar solo cuando hayan transcurrido 15 días o más desde que se aplicó
status:staley no haya habido ninguna actividad que cumpla los requisitos después. - Actividad calificadora: Un comentario sustantivo que demuestra relevancia actual. Debe confirmar el problema en una versión o commit actual, explicar por qué el problema es independiente de la versión, o añadir evidencia útil como una reproducción, registros o detalles del error, información del entorno, un caso de uso afectado concreto, confirmación de regresión, o una solución alternativa. Un
+1genérico, comentario administrativo, cambio de etiqueta, evento de bot, o evento de enlace no califica. - Exclusiones: No aplicar el tratamiento de inactividad a
priority:p0,type:rfc,status:no-stale, una incidencia con un PR vinculado abierto, una incidencia con 10 o más reacciones 👍 en la publicación inicial, ostatus:blockedmientras un bloqueador registrado siga sin resolverse. Si una exclusión comienza mientras una incidencia tiene la etiquetastatus:stale, elimina la etiqueta de inactividad. Cuando la exclusión termine, reinicia el reloj de entrada desde esa fecha. - Reactivación: Eliminar
status:stalecuando ocurra actividad calificada después de que se aplicó la etiqueta o cuando el issue sea reabierto. Reiniciar el conteo desde esa actividad o fecha de reapertura. Después de un cierre por inactividad, nueva evidencia calificada en un comentario es motivo para que un mantenedor reabra el issue y eliminestatus:stale; el comentarista puede en su lugar abrir un nuevo issue con el contexto actualizado.
stale-candidate es independiente: es la señal de poda del backlog de PRs inactivos y no reemplaza status:stale para los issues.
Etiquetas de resolución
Las etiquetas de resolución explican por qué se cierra o se retira de la cola activa un problema o PR. Son resultados finales, no etiquetas de estado del ciclo de vida, y deben incluir suficiente contexto en los comentarios para que un mantenedor futuro pueda entender la decisión.
| Etiqueta | Propósito |
|---|---|
wontfix | Solicitud válida o informe que el proyecto decide explícitamente no abordar. Usa una justificación breve; no cierres sin avisar. |
invalid | No procesable como error, solicitud de funcionalidad, elemento de soporte, RFC o trabajo de proyecto rastreado. Explica la discrepancia o el requisito faltante. |
duplicate | El mismo problema subyacente que otro issue o PR ya registrado. Enlaza el destino canónico antes de cerrar o redirigir la discusión. |
No crees ni apliques etiquetas de terminal propuestas como status:wont-do o status:wont-fix hasta que un paquete de migración de etiquetas aprobado por un maintainer defina el plan exacto de cambio de nombre, alias o eliminación. La etiqueta activa actual para el concepto “Won’t Do” a nivel de tablero es wontfix.
La sustitución es un proceso de reemplazo, no una etiqueta activa actualmente. Usa Superseding PRs para conocer las reglas de reemplazo y los requisitos de atribución hasta que un paquete de migración aprobado posteriormente cree o asigne una etiqueta de sustitución.
Etiquetas de triaje
Se aplica manualmente: la automatización de respuesta automática que solía gestionar estos casos se eliminó durante la simplificación de CI.
| Etiqueta | Propósito |
|---|---|
r:needs-repro | Informe de error incompleto; se solicita una reproducción determinista |
r:support | Uso / elemento de ayuda mejor manejado fuera de la lista de seguimiento de errores |
needs-author-action | Se necesita una respuesta del autor antes de que los mantenedores puedan continuar con la revisión o el proceso de merge. Para los PR, aplica esto con revisiones de request-changes cuando el siguiente paso dependa del autor, y elimínalo cuando el autor envíe una actualización sustancial o proporcione la información solicitada. Para los RFC, aplícalo después de un resultado REVISE mientras el autor prepara la revisión; elimínalo y restablece needs-maintainer-review cuando una propuesta estable revisada esté lista para que Core actúe. Esto no es, por sí solo, una advertencia de obsolescencia. |
needs-maintainer-review | Hay pendiente una decisión, revisión o acción de votación de los mantenedores. En los RFC, usa esta etiqueta mientras sea necesario un debate sustancial de Core o una acción de ratificación; quítala cuando se registre la decisión o la siguiente acción pase al autor o a la implementación. Esta etiqueta no implica aceptación, asignación de responsabilidad ni protección contra la obsolescencia. |
candidato-obsoleto | PR inactiva candidata a cerrarse. Sigue la secuencia de inactividad de Guía del revisor → Depuración del backlog de PR. Para los issues, las comprobaciones de inactividad usan status:stale en su lugar. |
Etiquetas del flujo de trabajo
Aplicadas manualmente para hacer visible la coordinación entre artefactos. Estas etiquetas no implican propiedad, aceptación ni protección contra la obsolescencia.
| Etiqueta | Propósito |
|---|---|
do-not-merge | Bloqueo explícito por parte del mantenedor o de gobernanza en una PR. Úsala junto con status:blocked cuando una PR esté bloqueada por una dependencia externa, una decisión de política o un prerrequisito que el estado nativo de revisiones y comprobaciones de GitHub no haga cumplir, especialmente cuando, por lo demás, parezca lista para fusionarse. Al aplicarla, deja un comentario en la PR que indique el bloqueo, la condición para quitar do-not-merge y cualquier etiqueta de bloqueo complementaria, así como las comprobaciones necesarias antes de la fusión; las revisiones y las incidencias enlazadas pueden respaldar ese registro, pero no lo sustituyen. Combínala con needs-maintainer-review cuando una PR de alto riesgo se derive explícitamente para obtener otra aprobación independiente del Core Team. Úsala para trabajos destinados a líneas futuras que no deban incorporarse a la línea de lanzamiento activa. No la apliques simplemente por una CI pendiente, el estado de borrador, una rama atrasada, una revisión ordinaria o un CHANGES_REQUESTED activo. Quítala solo después de que se haya resuelto la condición registrada y un mantenedor vuelva a comprobar el estado actual de las revisiones nativas, las comprobaciones obligatorias, la posibilidad de fusión, la Definición de terminado y la lista de comprobación de fusión. |
seguimiento | Alcance separado deliberadamente de una incidencia o PR principal; enlaza el elemento principal para que la relación sea visible |
release-gate | Hallazgo o elemento de trabajo que debe conciliarse para la puerta de versión indicada |
stacked | El PR depende de otro PR; incluye una referencia explícita Depends on #... y fusiónalo después de su base |
Etiquetas de recogida de la comunidad
Aplicado manualmente cuando los maintainers desean una contribución externa.
| Etiqueta | Propósito |
|---|---|
good first issue | Tarea XS/S pequeña, autónoma y bien documentada, segura para un nuevo colaborador, con criterios de aceptación, enlaces relevantes a código o documentación, y un mentor o contacto designado |
help wanted | Trabajo accionable y desbloqueado en el que los maintainers quieren ayuda externa y pueden revisar, normalmente con riesgo de problemas bajo o medio |
No utilices help wanted como marcador genérico para “válido pero sin asignar”. Si una incidencia está bloqueada, depende de la arquitectura, carece de criterios de aceptación, es probablemente de alto riesgo o está a la espera de una decisión de política, déjala sin etiquetas de asignación hasta que se resuelva el bloqueo o un responsable de mantenimiento defina el alcance que falta.
Activadores de mantenimiento
Actualiza esta página cuando:
- Se ha añadido un nuevo canal, proveedor o herramienta al árbol de origen (las etiquetas de ruta necesitan nuevas entradas).
- Se ha cambiado una directiva de etiquetas o un umbral.
- Se muestra un nuevo flujo de trabajo de triaje o se elimina uno antiguo.
Las notas de estado de automatización («actualmente aplicadas manualmente») se incluyen deliberadamente para que un futuro mantenedor no asuma que la ausencia de un flujo de trabajo significa que la capa de etiquetas no existe.