Étiquettes
Référence unique pour chaque libellé utilisé dans les PR et les tickets. Sources de vérité :
.github/labeler.yml: configuration de correspondance chemin-étiquette utilisée paractions/labeler.github/label-policy.json: seuils de niveaux des contributeurs- Cette page : définitions, comportement, et ce qui est automatisé vs manuel
Lorsque les définitions entrent en conflit, mettez d’abord à jour le fichier source, puis synchronisez cette page.
Limites de propriété
Les labels sont des métadonnées portables. Ils doivent indiquer de quel type de travail il s’agit, quelle zone de code il affecte, quel est le niveau de risque pour la revue, et si la politique stale ou la politique de triage nécessite un traitement particulier.
L’automatisation du tableau de projet est une aide à la planification, pas une seconde file d’attente de revue de PR. Le planificateur issue-dashboard actuel est manuel et limité aux rapports. Le tableau doit répondre aux questions de planification plus lentes : ce qui est prêt à être pris en charge, quelles preuves de routage le maintiennent actif, à quel tracker ou jalon il appartient, et ce qui est bloqué. L’état natif des PR GitHub doit continuer à répondre aux questions de revue et de fusion à évolution rapide.
Conservez la séparation basée sur la fréquence de mise à jour :
- Les étiquettes portent leur propre classification durable : type de travail, périmètre/composant, risque de revue, taille de PR mesurée et exemption d’obsolescence.
- Les champs du tableau de projet conviennent à l’étape de planification des tickets, aux preuves de routage visibles, à l’état des dépendances, au motif d’exemption d’obsolescence et au regroupement de la feuille de route lorsque ces champs sont activement maintenus.
- L’état natif des PR GitHub gère l’état de revue qui change rapidement : décision de revue, vérifications requises, possibilité de fusion, conflits et approbations obsolètes.
Le tableau devrait réduire le travail des mainteneurs. Si un champ nécessite une maintenance manuelle après chaque push de PR ou chaque revue, préférez plutôt les labels, les jalons ou l’état natif de GitHub.
Les libellés peuvent suggérer un routage probable, mais ils ne constituent pas une appartenance. Un libellé channel:*, provider:*, tool:*, security ou docs identifie la surface qui nécessite probablement une attention. Les règles de preuve de routage visibles par les contributeurs figurent dans le contrat du tableau de projet.
Utilisez les assignees pour le travail actif. Utilisez les commentaires d’issue, les sections du corps d’issue, les champs publics ou les trackers liés comme preuve de routage lorsqu’un état spécial stale, tracker ou de décision différée nécessite une explication. status:blocked utilise la règle du blocker enregistré. Le contrat du tableau de projet définit les sources de preuve acceptées et les résultats de routage.
Orthographe canonique
Utilisez l’orthographe à deux-points sans espace pour les labels scopés : provider:openai, channel:telegram, security:policy, risk:high, size:XS, type:docs, et les labels similaires. Les labels de type phrase sans espace de noms restent de type phrase : good first issue, help wanted, trusted contributor et stale-candidate.
Les anciennes étiquettes dupliquées telles que provider: openai, channel: telegram ou tool: shell sont des candidats au nettoyage. Les étiquettes espacées actives telles que risk: high, size: XS et type: docs sont des candidats à la migration, maintenant que le paquet approuvé a créé ou confirmé les étiquettes canoniques sans espace.
Certaines étiquettes héritées peuvent rester actives pendant une migration progressive. Les applications nouvelles ou manuelles doivent utiliser les étiquettes canoniques sans espace, tandis que les références ouvertes héritées existantes peuvent rester jusqu’à ce que le paquet de migration des références ouvertes les traite. Migrez les issues/PR ouvertes vers l’étiquette canonique avant la suppression. Ne supprimez pas les étiquettes avec des références ouvertes, ne renommez pas largement les familles d’étiquettes, ni ne retirez les étiquettes de politique obsolète sans une décision de mainteneur pour ce lot de nettoyage.
Contrat d’automatisation
L’automatisation des étiquettes de PR en direct est répartie par source. pr-path-labeler.yml exécute actions/labeler à partir de .github/labeler.yml à l’ouverture, à la réouverture et à chaque mise à jour poussée de la PR. Comme ce workflow utilise sync-labels: true, les étiquettes gérées par .github/labeler.yml sont recalculées à partir de l’ensemble de fichiers actuel de la PR : les étiquettes de chemin correspondantes sont ajoutées, et les étiquettes de chemin qui ne correspondent plus sont supprimées.
Dependabot applique également les étiquettes configurées sur ses propres PR à partir de .github/dependabot.yml : les mises à jour Cargo reçoivent dependencies ; les mises à jour GitHub Actions et Docker reçoivent ci et dependencies. Ces étiquettes constituent les métadonnées initiales des PR Dependabot, et non le contrat synchronisé du path-labeler.
Aujourd’hui, .github/labeler.yml ne possède que les étiquettes de chemin et de portée telles que docs, ci, channel, provider:openai et tool:file. Il ne possède pas les étiquettes risk:*, size:*, type:*, de niveau de contributeur, de statut, de résolution, d’obsolescence ou de reprise.
L’automatisation de la taille peut recalculer les résultats à chaque mise à jour envoyée d’une PR afin que les libellés continuent de décrire le diff réellement examiné. #9345 gère le déploiement séparé du classifieur de risque. Sa phase de risque reste en mode rapport uniquement jusqu’à ce que les mainteneurs examinent les éléments recueillis et activent séparément les modifications. Les résultats en mode rapport uniquement doivent consigner le risque proposé, les éléments prouvant la règle correspondante, le risque actuel, l’état de risk:manual et l’état de domain:security, afin que les mainteneurs puissent auditer les divergences et les changements liés à la sécurité qui ont échappé aux deux déclencheurs. Toute automatisation future du risque doit respecter risk:manual comme un gel strict : elle ne peut pas ajouter, supprimer ou remplacer le libellé risk:* d’une PR tant qu’un mainteneur n’a pas supprimé la dérogation.
Protocole de nettoyage
Le nettoyage des étiquettes est une action de mainteneur, et non un effet secondaire de la revue normale d’une PR.
Utilisez cette séquence :
- Actualisez l’utilisation des étiquettes en temps réel avant d’agir.
- Répartir les candidats en suppressions sans historique, suppressions de doublons sans éléments ouverts, étiquettes actives à migrer en priorité et exclusions de politique.
- Pour les labels avec des refs ouvertes, après que le lot de nettoyage approuvé a créé ou confirmé le label canonique, ajoutez le label canonique à chaque issue/PR ouverte, supprimez le label hérité, vérifiez que le label hérité a zéro ref ouverte, puis supprimez-le.
- Ne supprimez pas les labels de gouvernance, les labels stale-policy, les labels contributor-tier ni les labels GitHub par défaut dans le cadre du nettoyage des module-label.
Chaque lot de nettoyage en direct nécessite l’approbation explicite d’un mainteneur pour les labels et les références d’issues/PR modifiés.
Retenues de politique
Certaines familles d’étiquettes sont intentionnellement exclues du nettoyage mécanique, même lorsqu’elles semblent incohérentes avec les préférences d’orthographe ou de taxonomie plus récentes. Elles ne doivent changer qu’après une décision de politique distincte et un paquet d’opération en direct exact.
| Famille | Action actuellement prise en charge par le mainteneur | Avant de modifier les labels en direct |
|---|---|---|
| Libellés de terminal et de résolution | Expliquez pourquoi la tâche a quitté la file d’attente active : non poursuivi, invalide, doublon ou explicitement refusé. | Préserver la signification historique de la clôture et les attentes des contributeurs ; définir tout paquet de renommage, d’alias, de migration ou de suppression avant de muter les étiquettes actives. Le remplacement et la supersession restent des processus documentés à moins qu’un paquet approuvé ultérieur ne crée ou ne mappe une étiquette active. |
| Étiquettes de statut et périmées | Gérer le cycle de vie des tickets et les comportements liés au statut stagnant, y compris le travail accepté, les blocages, l’implémentation active, status:stale, status:no-stale, et la gestion du statut stagnant des PR dans le backlog. | Traitez en priorité les politiques car l’automatisation peut protéger, avertir ou fermer les issues différemment. Ne changez pas ces labels comme un nettoyage cosmétique ou de labels de module ; gérez-les via un paquet de politique stale/lifecycle qui tient compte de l’automatisation et des règles d’évidence de routage. |
| Étiquettes de niveau de contributeur | Signalez la confiance des réviseurs et l’expérience des contributeurs à l’aide des seuils de .github/label-policy.json. | Mettez à jour le fichier de politique et ce guide ensemble ; ne supprimez ni ne renommez les niveaux en guise de nettoyage cosmétique, car les libellés affectent les personnes et le routage des revues. |
| Étiquettes par défaut GitHub | Préserver les points d’entrée familiers pour les contributeurs tels que bug, enhancement, documentation et question. | Remplacez ou retirez uniquement via une décision de taxonomie explicite destinée aux contributeurs. Les valeurs par défaut peuvent être utilisées par les modèles, les recherches, les liens externes et les intégrations. |
Le test pour conserver une étiquette sensible active est opérationnel : les mainteneurs peuvent-ils nommer une action réelle qui devient plus difficile si l’étiquette active disparaît ? Si oui, conservez-la ou remplacez-la délibérément. Si non, préservez le mappage historique dans le paquet d’audit et migrez ou supprimez via l’opération approuvée.
Étiquettes de type
Les libellés de type décrivent la catégorie générale de travail. Ils sont distincts des libellés de chemin tels que docs, ci ou dependencies.
Les applications nouvelles ou manuelles doivent utiliser les libellés canoniques sans espace ci-dessous lorsque le libellé live existe. Les références ouvertes héritées existantes peuvent conserver les libellés espacés jusqu’à ce que le paquet de migration des références ouvertes les prenne en charge ; voir Orthographe canonique.
type:tracker est l’orthographe canonique du marqueur de tracker pour les issues de coordination parentes actives. Ne créez pas et n’appliquez pas roadmap, type:roadmap ou un autre marqueur de tracker comme alias. Si l’étiquette type:tracker en direct n’existe pas encore, la création d’étiquette et toute migration de marqueur de tracker doivent se faire uniquement via un paquet distinct exact approuvé par le mainteneur.
| Étiquette | Objectif |
|---|---|
type:ci | Travaux de CI, de workflow ou d’automatisation de dépôt |
type:dependencies | Maintenance des dépendances ou du fichier de verrouillage |
type:docs | Travail uniquement ou principalement documentaire |
type:rfc | Problème ou proposition RFC ; protégé contre la fermeture pour obsolescence tant qu’il est actif |
type:refactor | Nettoyage de la structure du code ou réorganisation interne visant à préserver le comportement visible par l’utilisateur. |
type:test | Travail uniquement de test ou principalement de test |
type:tracker | Issue de coordination parent active pour une version, une feuille de route, un fil de discussion RFC/conception, un lot d’implémentation, une campagne de nettoyage ou un audit. Marqueur réservé aux issues ; il ne crée pas à lui seul de protection contre les issues périmées, d’attribution, d’acceptation ou de portée prête pour les contributeurs. |
Étiquettes de chemin
Appliqué automatiquement par pr-path-labeler.yml. Les globs se trouvent dans .github/labeler.yml ; en cas de divergence entre cette page et la configuration, considérez .github/labeler.yml comme la source opérationnelle et mettez à jour cette page.
Étiquettes de portée de base
| Étiquette | Correspondances |
|---|---|
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 (la commande 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 limité aux fichiers d’automatisation/configuration GitHub, et non à tous les chemins .github/**. Le matcher racine .github/*.json est intentionnel pour les métadonnées d’automatisation (par exemple .github/label-policy.json), donc des fichiers comme .github/assets/**, .github/ISSUE_TEMPLATE/**, .github/CODEOWNERS et .github/pull_request_template.md ne correspondent pas à ci.
Libellés supplémentaires des composants
Certaines surfaces ont des libellés de propriété de chemin plus étroits pour le routage des mainteneurs. Ces libellés sont synchronisés par .github/labeler.yml lorsque le diff de la PR touche les fichiers listés.
Les labels de chemin scopés ne garantissent pas un label de base de même préfixe. Comme pr-path-labeler.yml s’exécute avec sync-labels: true, les mainteneurs doivent considérer .github/labeler.yml comme la source de vérité pour les labels de base et scopés qu’une PR reçoit.
| Étiquette | Correspondances |
|---|---|
observability:log | crates/zeroclaw-log/src/**, crates/zeroclaw-runtime/src/observability/log.rs |
observability:otel | otel.rs, couverture de régression des fonctionnalités de dépendance OTel |
observability:prometheus | prometheus.rs |
runtime:wasm | plateforme d’exécution WASM et fichiers hôtes de plugins WASM first-party |
security:bubblewrap | bubblewrap.rs |
security:docker | docker.rs |
security:leak-detector | LeakDetector masquage et analyse des sorties sensibles |
security:pairing | sécurité d’appairage, API d’appairage de la passerelle, commande d’appairage Tauri et page d’appairage web |
security:policy | fichiers de politique de sécurité d’exécution, de politique IAM et de politique de configuration |
security:secrets | gestion des secrets d’exécution et de configuration |
security:traits | définitions partagées de traits et d’interfaces de sécurité |
memory:backend | sélection du backend de mémoire et fichiers d’implémentation du stockage |
Libellés de composants manuels
Certaines étiquettes de composants scopés sont des étiquettes de routage manuelles plutôt que des étiquettes de chemin synchronisées.
domain:architecture identifie les travaux liés à la responsabilité entre composants, à la source de vérité, à la direction des dépendances, aux interfaces/contrats et aux décisions d’architecture. Ne l’appliquez pas simplement parce qu’une issue est un RFC.
domain:security identifie une frontière effective d’authentification, d’autorisation, de gestion des identifiants et des secrets, de confinement, de permissions des outils, de politique de sécurité, d’identité cryptographique ou d’entrées non fiables. Appliquez-le lorsque le comportement modifié franchit cette frontière, y compris en dehors des chemins de sécurité canoniques. Ne l’appliquez pas uniquement parce qu’une PR traite de sécurité, modifie la documentation ou les tests de sécurité, met à jour une dépendance faisant l’objet d’un avis de sécurité ou effectue un durcissement générique sans modifier une frontière de confiance. L’étiquette reste manuelle, car la correspondance des chemins ne permet pas d’inférer de manière fiable cette conséquence.
domain:security est indépendant de risk:*. Une PR portant risk:high ou domain:security nécessite une revue approfondie et deux approbations indépendantes de la Core Team avant sa fusion. Une revue automatisée ne compte pas comme une approbation de la Core Team.
Les libellés de domaine et de surface produit en double suivants sont en attente de retrait. Ne les appliquez pas à de nouveaux travaux. Ils restent actifs uniquement jusqu’à ce qu’un paquet d’opérations distinct et exact migre les références ouvertes restantes et supprime les définitions.
| Libellé en cours de retrait | Remplacement canonique |
|---|---|
domain:channels | channel ainsi que le libellé channel:* approprié |
domain:ci | type:ci ; n’ajouter le ci associé au chemin que lorsque les fichiers modifiés correspondent à son contrat d’automatisation |
domain:code-quality | Libellés de portée précis et type:refactor le cas échéant |
domain:deps | dependencies et/ou type:dependencies |
domain:web-fetch | tool:web |
tauri | desktop ; Tauri reste un détail d’implémentation dans les chemins et les titres |
Les libellés de produit conservés sont intentionnellement distincts. cli est l’interface en ligne de commande destinée aux utilisateurs finaux, tandis que channel:cli est le canal de discussion interactif de la CLI. web est le tableau de bord du navigateur et le produit de chat web, tandis que tool:web est le groupe d’outils de récupération et de recherche web de l’agent. zerocode est l’application de terminal ZeroCode, hardware couvre les intégrations à l’hôte, les crates de support et l’arborescence du firmware, et desktop est le produit de bureau Tauri. Utilisez le libellé d’outil ou de produit applicable pour les tâches d’utilisation native de l’ordinateur en dehors de apps/tauri/** ; n’appliquez pas manuellement desktop synchronisé à une PR dont les chemins ne correspondent pas.
agent:prompt est destiné à la politique de prompt, de contexte et d’orientation des réponses visibles par le fournisseur. Utilisez-le lorsque le travail porte sur le contenu du system-prompt, les directives de formatage des appels d’outils, le contexte sensible au cache de prompt, l’orientation des réponses des canaux, ou d’autres surfaces d’instructions visibles par le modèle qui croisent les labels de base agent, channel, memory, provider ou runtime. Appliquez-le en plus des labels de base ou de scope applicables ; il ne les remplace pas. Ne l’appliquez pas à chaque modification de crates/zeroclaw-runtime/src/agent/** ; utilisez le label de base agent pour les modifications ordinaires du runtime de l’agent.
agent:loop est retiré. Pour le routage agent-loop, utilisez la base agent plus toute étiquette runtime, provider, channel, tool ou risk correspondante.
N’appliquez pas l’étiquette observability: runtime_trace héritée aux nouvelles issues ou PR. Utilisez observability:otel lorsque le travail concerne le traçage OpenTelemetry, ajoutez uniquement la base observability lorsque l’issue ou la PR correspond également à cette surface de base, et décidez de toute étiquette canonique future spécifique au traçage d’exécution dans un paquet de création/migration séparé.
N’appliquez pas security: leak_detector (hérité) aux nouvelles issues ou PRs. Utilisez security:leak-detector pour les travaux de masquage LeakDetector et d’analyse des sorties sensibles.
Les labels de sous-zones tels que gateway: api, gateway: sse, gateway:local_bridge et gateway:webhook_ingress restent reportés pour la migration en direct. Le nouveau routage doit utiliser le gateway de base jusqu’à ce qu’un paquet distinct crée des sous-labels canoniques sans espaces ou avec des tirets et migre les références, ou qu’il regroupe ces labels dans le gateway de base.
Étiquettes par canal
Chaque canal reçoit une étiquette channel:<name> en plus de l’étiquette de base channel lorsque la modification affecte les chemins des crates du canal. Les étiquettes de canaux inter-surface telles que channel:acp peuvent à la place être associées à l’étiquette de surface de base correspondante, comme gateway, docs ou les étiquettes de portée d’applications/web.
channel:core est le libellé de l’API de canal partagée et de l’orchestrateur. Utilisez-le pour travailler sur les contrats de traits de canal, l’orchestration de canaux, les hooks de livraison, le comportement de routage/session, la gestion des commandes runtime et le comportement inter-canaux qui serait trompeur sous un libellé de plateforme unique.
| Étiquette | Correspondances |
|---|---|
channel:acp | acp_channel.rs, acp_server.rs, zeroclaw-acp-bridge.rs, acp_session_store.rs, channels/acp.md, points d’entrée ACP gateway/app/web sélectionnés |
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 |
Étiquettes par fournisseur
Les libellés spécifiques au fournisseur correspondent aux fichiers sources dédiés au fournisseur. Le routeur de fournisseur a son propre libellé de portée, car le travail de routage et de répartition des modèles est un sous-domaine partagé des fournisseurs, et non l’intégration concrète d’un fournisseur. Les fichiers de registre ou de fabrique partagés ne doivent recevoir que le libellé de base provider ; les mainteneurs peuvent ajouter manuellement un libellé spécifique au fournisseur lorsqu’une modification d’un fichier partagé est vraiment limitée à un seul fournisseur.
| Étiquette | Correspondances |
|---|---|
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 |
Certaines étiquettes de fournisseurs décrivent des familles de fournisseurs qui partagent actuellement l’implémentation de fournisseur compatible OpenAI au lieu d’un fichier source dédié. Les mainteneurs peuvent les appliquer manuellement lorsqu’un problème ou une PR concerne vraiment cette famille : provider:groq, provider:kimi, provider:minimax, provider:moonshot et provider:qwen. N’ajoutez pas de fichiers de factory partagée ou de fournisseur compatible à ces règles de labeler ; cela sur-étiquetterait des modifications partagées non liées.
Étiquettes par groupe d’outils
Les outils sont regroupés par fonction logique plutôt qu’un label par fichier.
| Étiquette | Correspondances |
|---|---|
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 est une étiquette uniquement manuelle pour les problèmes de sérialisation et de nettoyage des schémas d’outils. N’ajoutez pas de fichiers de schémas généraux à .github/labeler.yml ; de nombreux fichiers de schéma sont des surfaces de configuration, de fournisseur ou d’API partagées et sur-étiquetteraient des modifications non liées.
Étiquettes de taille
Basé sur le nombre effectif de lignes modifiées, normalisé pour les PR ne contenant que de la documentation ou principalement des fichiers de verrouillage. Actuellement appliqué manuellement ; l’automatisation de la taille qui calculait auparavant ces valeurs a été supprimée lors de la simplification de la CI. Toute future automatisation de la taille devra respecter le contrat d’automatisation.
Les applications nouvelles ou manuelles doivent utiliser les libellés canoniques sans espace ci-dessous. Les références ouvertes héritées existantes peuvent conserver les libellés avec espaces jusqu’à ce que le paquet de migration des références ouvertes les gère ; voir Orthographe canonique.
| Étiquette | Seuil |
|---|---|
size:XS | ≤ 80 lignes |
size:S | ≤ 250 lignes |
size:M | ≤ 500 lignes |
size:L | ≤ 1000 lignes |
size:XL | > 1000 lignes |
Étiquettes de risque
Pour les PR, les étiquettes de risque décrivent le diff réellement soumis à revue : chemins modifiés, changement de comportement, exposition des limites de sécurité et difficulté de rollback. Pour les issues, les étiquettes de risque décrivent le rayon d’impact probable du correctif d’après le rapport, aident à trier la profondeur de revue et l’adéquation des contributeurs, et peuvent changer une fois qu’une PR concrète révèle le chemin d’implémentation réel. Actuellement appliquées manuellement. Toute automatisation future des risques doit suivre le contrat d’automatisation.
Les applications nouvelles ou manuelles doivent utiliser les libellés canoniques sans espace ci-dessous. Les références ouvertes héritées existantes peuvent conserver les libellés avec espaces jusqu’à ce que le paquet de migration des références ouvertes les gère ; voir Orthographe canonique.
| Étiquette | Signification |
|---|---|
risk:low | Documentation, localisation, jeux de données de test, références générées ou métadonnées mécaniques sans effet sur la production, la compatibilité, la compilation, la publication ou la gouvernance |
risk:medium | Modification ordinaire du comportement en production, y compris la plupart des travaux liés à l’environnement d’exécution, aux passerelles, aux fournisseurs, aux canaux, aux outils, à la configuration, aux applications et à la CI |
risk:high | Une frontière concrète liée à la confiance, aux identifiants, à la compatibilité, à la gouvernance ou à l’autorité de publication qui nécessite une revue approfondie et deux approbations indépendantes de la Core Team |
risk:manual | Dérogation du mainteneur qui fige les futurs remplacements automatisés des risques ; elle ne réduit pas les exigences de revue ou d’approbation |
risk:* décrit le diff réel et sa conséquence, et non l’emplacement général du composant. Une modification limitée aux tests, sans effet en production, au sein d’un périmètre à haut risque peut être risk:medium lorsque l’intégralité de ce périmètre limité aux tests peut être démontrée ; #9530 fait autorité pour cette exception.
Utilisez risk:manual chaque fois que le niveau de risque prévu par un mainteneur diffère du résultat automatique futur, y compris le déclassement démontrable de #9530, sans effet en production et limité aux tests. Appliquez risk:high avec risk:manual lorsqu’une modification non liée à la sécurité entraîne une conséquence concrète à haut risque — destructive, avec perte de données, modifiant le comportement par défaut de manière incompatible, liée à la gouvernance ou à la sécurité des mises en production, ou autre — en dehors des règles automatiques stables. Cela préserve le mécanisme d’escalade manuelle accepté au lieu de créer une autre famille de libellés. Consignez la justification dans la revue ou l’enregistrement de la PR.
En cas d’incertitude, classez dans la catégorie supérieure et demandez à un mainteneur de trancher. N’élargissez pas les règles automatiques de chemin uniquement pour éviter une décision lors de la revue.
Étiquettes de niveau de contributeur
Défini dans .github/label-policy.json. Basé sur le nombre de PR fusionnées de l’auteur, interrogé via l’API GitHub. Actuellement appliqué manuellement.
| Étiquette | PRs fusionnés minimum |
|---|---|
contributeur de confiance | 5 |
contributeur expérimenté | 10 |
principal contributor | 20 |
contributeur distingué | 50 |
Libellés de priorité
Les libellés de priorité indiquent l’urgence de planification pour les mainteneurs, et non la responsabilité ni l’état d’implémentation. Appliquez-les manuellement et réévaluez-les lorsque l’impact du problème ou le contexte de la version évolue.
| Étiquette | Signification |
|---|---|
priority:p0 | Blocage immédiat nécessitant l’attention urgente d’un mainteneur ; exclu de la gestion des issues obsolètes tant que la priorité reste d’actualité |
priority:p1 | Travail hautement prioritaire à planifier avant la file d’attente normale |
priority:p2 | Travail de priorité moyenne présentant un intérêt clair pour les mainteneurs |
priority:p3 | Travail suivi de priorité inférieure sans engagement urgent de planification |
Étiquettes d’état
Suit l’état du cycle de vie des RFC et des éléments de travail suivis. Appliqué manuellement, sauf indication contraire d’un workflow maintenu.
| Étiquette | Description |
|---|---|
status:accepted | RFC ou élément de travail ratifié par l’équipe. Cela n’exempte pas le problème du traitement des éléments obsolètes par lui-même. |
status:blocked | Le travail est valide mais en attente d’une dépendance externe, d’une décision du mainteneur ou d’un prérequis lié. Exempté du statut « obsolète » tant que le bloqueur est enregistré et non résolu. Ne pas associer à status:no-stale pour le même bloqueur. |
status:in-progress | Une PR ouverte cible activement ce problème. Réconcilier avec l’état actuel de la PR lors des passes d’obsolescence ; le label n’est pas une exemption permanente après la fermeture de la PR. |
status:stale | Le ticket se trouve dans le délai de réponse défini par la politique relative aux tickets obsolètes |
status:no-stale | Exemption explicite de péremption pour le travail accepté ou autrement de longue durée qui n’est pas déjà protégé par une autre exclusion de péremption. Politique cible : à utiliser uniquement lorsque le contrat de tableau de projet comporte une raison d’exemption de péremption visible par les contributeurs et des preuves de routage. Les trackers de release actifs et les trackers de RFC ou de conception actifs peuvent utiliser le tracker lui-même comme raison visible et surface de routage tant qu’ils restent actifs ; réexaminez-les lorsque le jalon se ferme, que le tracker s’écarte de l’état réel, que la RFC aboutit à une décision, est remplacée ou se ferme, ou que le ticket cesse de représenter une surface de décision de projet active. Les exemptions existantes auxquelles ces éléments manquent doivent être auditées et corrigées avant que les balayages de péremption cessent de les honorer. |
Politique de péremption des issues
Cette section constitue la source opérationnelle canonique concernant le délai d’inactivité des tickets, les activités qualifiantes, les exclusions et la réactivation. Les autres documents et compétences destinés aux mainteneurs doivent pointer vers cette section plutôt que d’en recopier les règles.
- Fenêtre d’entrée : Appliquer
status:staleune fois que 15 jours ou plus se sont écoulés sans activité qualifiante. - Fenêtre de réponse : Fermer uniquement lorsque 15 jours ou plus se sont écoulés depuis l’application de
status:staleet qu’aucune activité qualifiante n’est survenue par la suite. - Activité admissible : Un commentaire substantiel qui démontre la pertinence actuelle. Il doit confirmer le problème dans une version ou un commit récent, expliquer pourquoi le problème est indépendant de la version, ou apporter des éléments utiles tels qu’une reproduction, des journaux ou des détails d’erreur, des informations sur l’environnement, un cas d’utilisation concret concerné, la confirmation d’une régression ou une solution de contournement. Un
+1générique, un commentaire administratif, une modification d’étiquette, un événement de bot ou un événement de lien ne sont pas pris en compte. - Exclusions : N’appliquez pas la gestion des éléments obsolètes à
priority:p0,type:rfc,status:no-stale, aux problèmes associés à une PR ouverte, aux problèmes ayant au moins 10 réactions 👍 sur leur message initial, ni àstatus:blockedtant qu’un bloqueur enregistré reste non résolu. Si une exclusion commence alors qu’un problème portestatus:stale, supprimez le label stale. Lorsque l’exclusion prend fin, relancez le délai d’entrée à partir de cette date. - Réactivation : Supprimez
status:stalelorsqu’une activité admissible survient après l’application de l’étiquette ou lorsque l’issue est rouverte. Réinitialisez le délai à partir de cette activité ou de la date de réouverture. Après une clôture pour inactivité, de nouveaux éléments probants admissibles dans un commentaire justifient qu’un mainteneur rouvre l’issue et supprimestatus:stale; l’auteur du commentaire peut plutôt ouvrir une nouvelle issue avec le contexte mis à jour.
stale-candidate est distinct : il s’agit du signal d’élagage du backlog pour les PR dormantes et ne remplace pas status:stale pour les issues.
Étiquettes de résolution
Les libellés de résolution expliquent pourquoi un ticket ou une PR est fermé ou retiré de la file d’attente active. Il s’agit de résultats terminaux, et non de libellés de statut de cycle de vie, et ils doivent inclure suffisamment de contexte en commentaire pour qu’un mainteneur puisse comprendre la décision ultérieurement.
| Étiquette | Objectif |
|---|---|
wontfix | Demande valide ou signalement que le projet choisit explicitement de ne pas poursuivre. Utilisez une justification brève ; ne fermez pas sans explication. |
invalid | Non exploitable en tant que bug, demande de fonctionnalité, élément de support, RFC ou tâche de projet suivie. Expliquez l’incohérence ou l’exigence manquante. |
duplicate | Même problème sous-jacent qu’un autre ticket ou PR déjà suivi. Liez la cible canonique avant de fermer ou de rediriger la discussion. |
Ne créez ni n’appliquez de libellés proposés tels que status:wont-do ou status:wont-fix tant qu’un dossier de migration de libellés approuvé par un mainteneur n’a pas défini le plan exact de renommage, d’alias ou de suppression. Le libellé actuellement en vigueur pour le concept « Won’t Do » au niveau du tableau est wontfix.
Le remplacement (superseding) est un processus de substitution, pas actuellement un label actif. Utilisez Superseding PRs pour les règles de remplacement et les exigences d’attribution jusqu’à ce qu’un paquet de migration approuvé ultérieurement crée ou mappe un label de remplacement.
Étiquettes de tri
Appliqué manuellement : l’automatisation de réponse automatique qui gérait auparavant ces cas a été supprimée lors de la simplification de la CI.
| Étiquette | Objectif |
|---|---|
r:needs-repro | Rapport de bogue incomplet ; veuillez fournir un cas de reproduction déterministe. |
r:support | Utilisation / élément d’aide mieux géré en dehors du backlog de bugs |
needs-author-action | Une réponse de l’auteur est nécessaire avant que les mainteneurs puissent poursuivre la revue ou le processus de fusion. Pour les PR, appliquez-la avec les revues demandant des modifications lorsque l’étape suivante incombe à l’auteur, et retirez-la lorsque l’auteur envoie une mise à jour substantielle ou fournit les informations demandées. Pour les RFC, appliquez-la après un résultat REVISE, pendant que l’auteur prépare la révision ; retirez-la et rétablissez needs-maintainer-review lorsqu’une proposition stable révisée est prête pour que Core puisse intervenir. Cela ne constitue pas à lui seul un avertissement de péremption. |
needs-maintainer-review | Une décision, une revue ou une action de vote de la part des mainteneurs est en attente. Pour les RFC, utilisez cette étiquette tant qu’une discussion substantielle de Core ou une action de ratification est nécessaire ; supprimez-la lorsque la décision est consignée ou que la prochaine action passe à l’auteur ou à l’implémentation. Cette étiquette n’implique ni acceptation, ni prise en charge, ni protection contre le marquage comme obsolète. |
candidat obsolète | PR inactive candidate à la fermeture. Suivez la procédure d’inactivité dans Reviewer Playbook → PR backlog pruning. Les passes d’inactivité sur les issues utilisent status:stale à la place. |
Libellés de workflow
Appliquées manuellement pour rendre visible la coordination entre artefacts. Ces étiquettes n’impliquent ni responsabilité, ni acceptation, ni protection contre l’obsolescence.
| Étiquette | Objectif |
|---|---|
do-not-merge | Mise en attente explicite d’une PR par un mainteneur ou la gouvernance. Utilisez-la avec status:blocked lorsqu’une PR est bloquée par une dépendance externe, une décision de politique ou un prérequis que les mécanismes natifs de revue et de vérification de GitHub ne permettent pas d’imposer, en particulier lorsque la PR semble par ailleurs fusionnable. Lorsque vous l’appliquez, laissez un commentaire sur la PR qui précise le blocage, la condition à remplir pour supprimer do-not-merge et toute étiquette de blocage associée, ainsi que les vérifications requises avant la fusion ; les revues et les issues liées peuvent étayer cette consignation, mais ne la remplacent pas. Associez-la à needs-maintainer-review lorsqu’une PR à haut risque est explicitement orientée vers une autre approbation indépendante de la Core Team. Utilisez-la pour les travaux destinés à une ligne de version future qui ne doivent pas être intégrés à la ligne de version active. Ne l’appliquez pas simplement en cas de CI en attente, d’état de brouillon, de branche en retard, de revue ordinaire ou de CHANGES_REQUESTED actif. Supprimez-la uniquement lorsque la condition consignée est satisfaite et qu’un mainteneur a revérifié l’état actuel des revues natives, les vérifications requises, la possibilité de fusion, la Définition de terminé et la liste de contrôle de fusion des mainteneurs. |
follow-up | Périmètre volontairement séparé d’une issue ou d’une PR parente ; liez l’élément parent pour rendre la relation visible |
release-gate | Constat ou élément de travail à traiter pour la barrière de publication indiquée |
stacked | La PR dépend d’une autre PR ; incluez une référence explicite Depends on #... et fusionnez-la après sa base |
Étiquettes de prise en charge communautaire
Appliqué manuellement lorsque les mainteneurs souhaitent une contribution externe.
| Étiquette | Objectif |
|---|---|
good first issue | Travail XS/S de petite taille, autonome et bien documenté, sûr pour un nouveau contributeur, comportant des critères d’acceptation, des liens vers le code ou la documentation pertinents, ainsi qu’un mentor ou un contact désigné |
help wanted | Travail concret et débloqué pour lequel les mainteneurs souhaitent une aide externe et qu’ils peuvent examiner, généralement à risque faible ou moyen |
N’utilisez pas help wanted comme marqueur générique pour « valide mais sans personne assignée ». Si un problème est bloqué, dépendant de l’architecture, dépourvu de critères d’acceptation, susceptible de présenter un risque élevé ou en attente d’une décision de politique, laissez-le sans étiquettes de prise en charge jusqu’à ce que le blocage soit résolu ou qu’un mainteneur en rédige le périmètre manquant.
Déclencheurs de maintenance
Mettez à jour cette page lorsque :
- Un nouveau canal, fournisseur ou outil est ajouté à l’arborescence source (les étiquettes de chemin nécessitent de nouvelles entrées).
- Une politique d’étiquette ou un seuil a changé.
- Un nouveau workflow de triage est affiché ou un ancien est supprimé.
Les notes sur l’état de l’automatisation (« actuellement appliqué manuellement ») sont intentionnellement incluses afin qu’un futur mainteneur ne suppose pas que l’absence d’un workflow signifie que le niveau d’étiquette n’existe pas.