Compétence FY MultiAgent Flow (FY-Flow)
Micro-noyau de développement collaboratif multi-agent piloté par contrat (FY-Flow) — Aligné sur le paradigme AutoGen, prévient efficacement les excès de pouvoir, la fragmentation des tâches et les états suspendus.
Protocole de passerelle d'entrée unifiée (Unified Gateway Protocol)
Toutes les instructions appelant cette compétence sont uniformément redirigées vers cette passerelle d'entrée, avec la répartition et la décision selon les deux branches suivantes :
1. Matrice de répartition à deux branches
| Type de branche | Caractéristiques de déclenchement et instructions | Mécanisme de traitement et contrat de réponse | Scénario typique |
|---|---|---|---|
| Branche A : Opérations de console système | /fy-flow help/fy-flow start/fy-flow status/fy-flow kanban/fy-flow trace | Passage direct au moteur d'exploitation sous-jacent (0 pré-niveau), exécute directement le script correspondant et affiche l'état du système. | Affichage du manuel d'aide, SOP d'initialisation, démarrage du tableau Kanban, inspection du tableau de bord, diagramme de lien hors ligne |
| Branche B : Développement métier et intentions interactives | Langage naturel pour les besoins, modifications de code, développement de fonctionnalités, corrections de bugs, dépannage, /fy-flow auto | Exécution forcée préalable des [Trois questions de classification et découpage à responsabilité unique] , et affichage explicite de l'en-tête double standard sur la première ligne de la réponse :`【Classification de tâche : L0 Réponse instantanée / L1 Tâche légère / L2 Développement standard】 | 【Responsabilité unique : Ticket conforme / Besoin composite à décomposer en N tâches atomiques】` |
2. Flux de décision [Trois questions de classification] pour les besoins métier
[Saisie du besoin métier]
│
├─► 1. Va-t-il y avoir des modifications de fichiers du dépôt (code/doc/conf) ?
│ ├─ Non ──► 2. La conclusion doit-elle être tracée a posteriori comme base pour l'ingénierie ?
│ │ ├─ Non ───────────────► 【L0 Réponse instantanée】(pas de ticket, réponse directe, 0 latence CLI, brouillon dans le dossier brouillon)
│ │ └─ Oui ───────────────► 【L1 Tâche légère】(création du ticket, arrêt en attente de démarrage → après autorisation humaine, complété par un seul rôle)
│ │
│ └─ Oui ──► 3. Nécessite-t-il une collaboration multi-rôle, la modification de code métier critique ou la modification de bibliothèques de base communes ?
│ ├─ Non ───────────────► 【L1 Tâche légère】
│ └─ Oui ───────────────► 【L2 Tâche de développement standard】(création du ticket, arrêt en attente de démarrage → après autorisation humaine, collaboration multi-rôle)
- Correspondance de classification passerelle et classification élastique CCP :
- 【L0 Réponse instantanée】 : Pas de ticket, réponse directe, 0 surcoût de machine d'état ;
- 【L1 Tâche légère】 : Correspond à CCP Tier-3 (Fast-Path, pas de rapport physique, écriture directe des justificatifs dans le tableau Kanban) ;
- 【L2 Développement standard】 : Correspond automatiquement à CCP Tier-2 (optimisation locale, temps de travail ≤ 4,0 h, pas de rapport physique) ou CCP Tier-1 (contrainte forte de l'architecture centrale et du contrat d'interface) selon l'ampleur et le contrat.
- Pour toutes les demandes métier L1/L2, la passerelle applique une vérification de responsabilité unique (temps de travail ≤ 8,0 h, livrable atomique unique). Les demandes transversales orthogonales doivent être décomposées en tickets.
- Ligne rouge infranchissable pour l'autorisation de démarrage : La création du ticket marque la fin de l'état de planification de la session en cours ; le ticket doit strictement rester à l'état [En attente] ; sans instruction explicite d'autorisation de démarrage de l'utilisateur humain (par exemple "Démarrer", "Commencer le développement", "Confirmer l'exécution"), il est strictement interdit de passer automatiquement à l'état [En cours].
- L'ID de tâche d'exécution (par exemple
T0001) traverse directement la passerelle pour entrer dans la machine d'état ; il est interdit de créer un deuxième ticket.
Tableau de référence rapide des commandes principales (CLI Command Quick Reference)
| Scénario métier | CLI unifiée (cli.py) | Script spécialisé sous-jacent | Rôle principal et paramètres |
|---|---|---|---|
| Création d'un ticket de tâche | python3 scripts/cli.py task create ... | python3 scripts/quick_task.py create ... | --name "..." --assignee "..." --stage "Sprint 2.1 Ajustement du menu" --type "A" --target "..." --criteria "..." [--in-scope "fichier # raison"] |
| Validation d'entrée/sortie de porte d'étape | python3 scripts/check_stage_gate.py ... | python3 scripts/check_stage_gate.py ... | --action start/close --stage "Sprint 2.1 Ajustement du menu" (validation à la demande, vérification automatique des dépendances antérieures) |
| Dispatching codé | python3 scripts/cli.py dispatch --task-id T00xx --format codex | python3 scripts/dispatch_task.py | Vérifie les dépendances et la concurrence, passe à [En cours], affiche les paramètres JSON directement utilisables par l'outil sous-agent Codex |
| Avancement de la transition de tâche | python3 scripts/transition_task.py ... | python3 scripts/transition_task.py ... | --task-id T00xx --role DEV --from-status En cours --to-status En revue --token <token> --summary "Description des modifications principales" --remarks "..." (la soumission à la revue exige --summary pour injecter automatiquement le diff et l'instantané de justificatif) |
| Validation finale humaine | python3 scripts/cli.py task accept ... | python3 scripts/quick_task.py accept ... | --task-id T00xx (Réservé à l'utilisateur humain, interdiction de signature par l'agent) |
| Démarrage du tableau Kanban | python3 scripts/cli.py kanban | python3 scripts/start_kanban_server.py | Démarre par défaut sur http://127.0.0.1:32886/ |
| Inspection de santé | python3 scripts/cli.py status | python3 scripts/heartbeat.py | Affiche la santé du tableau de bord, les tickets bloqués et les indicateurs de performance (inclut la cognition itinérante du sous-agent et les alertes > 600s) |
| Synchronisation de la pile technique / Recalcul du profil | - | scripts/update_agent_tech_stacks.py | --force-recalc force le recalcul du profil de capacité technique expert et rafraîchit l'exportation du sous-agent, résout le problème de profil obsolète après migration de la pile technique |
| Vérification de continuité | python3 scripts/cli.py ccp ... | python3 scripts/cli.py ccp ... | --task-id T00xx --stage En revue Vérifie la continuité du contexte |
| Diagramme de lien complet | python3 scripts/cli.py trace | python3 scripts/generate_trace_html.py | Analyse hors ligne la trace de la session, génère en quelques secondes un diagramme de lien complet au format HTML (0 Token) |
| Test incrémental intelligent | python3 scripts/cli.py test | scripts/run_tests.py | Détecte automatiquement les modifications Git, exécute uniquement les tests unitaires pertinents (en quelques secondes), les modifications de documentation sont automatiquement exemptées, --all pour une régression complète |
Matrice des droits d'écriture et des intervalles de transition des 8 sous-agents experts
[!IMPORTANT] Règle d'isolement physique et contrôle par jeton (Dispatch Token Gating) :
- L'agent principal (PM Yan Manager) est strictement interdit de se faire passer pour un développeur et d'écrire du code métier dans la session principale ! L'hôte Codex doit utiliser un véritable outil de sous-agent pour dispatcher ; les autres hôtes peuvent utiliser leurs propres outils de sous-agent.
- Dispatching codé et contrôle par jeton : Le dispatching d'une tâche génère un
dispatch_tokenexclusif viacli.py dispatch. Les rôles de développement professionnel (DEV/FRONTEND/REVIEWER/QA) doivent obligatoirement utiliser--token <token>lors des transitions ; la machine d'état vérifie de manière stricte l'existence du jeton, empêchant ainsi les simulations et les faux positifs.
Contrat de dispatching automatique pour le bureau Codex
Après autorisation explicite de démarrage par l'utilisateur, l'agent principal exécute dans le répertoire du projet cible :
python3 .agents/skills/fy-flow/scripts/dispatch_task.py --task-id <ID> --format codex.
La sortie standard est un objet JSON unique contenant tool, arguments, task_id et role ; les informations de diagnostic transitent par la sortie d'erreur standard.
L'agent principal doit immédiatement passer arguments tel quel comme paramètre d'un véritable appel à l'outil collaboration.spawn_agent,
attendre le retour du sous-agent, puis continuer à dispatcher les experts revue et test selon l'état actuel de la tâche. Ne pas réécrire, copier ou résumer manuellement le message de dispatching ;
ne pas imprimer le JSON comme si le dispatching était terminé, et ne pas faire exécuter le travail d'expert par l'agent principal. Si l'hôte Codex actuel ne dispose pas
d'outil de sous-agent, signaler clairement l'absence de capacité de l'hôte, laisser la tâche dans son état actuel, et ne pas falsifier de reçu d'expert.
L'expert déjà dispatché ne doit exécuter que le exit_contract.required_cli présent dans le message, et ne doit pas recréer de ticket ou redémarrer.
Comme l'autorisation de l'utilisateur couvre cette exécution, le dispatching peut être poursuivi dans la même session après la création du ticket ; seul le cas sans autorisation de démarrage doit rester en [En attente].
| Identifiant du sous-agent | Nom du rôle | Responsabilités principales | Intervalles de transition d'état légitimes | Contrat de sortie |
|---|---|---|---|---|
@flow-pm | Yan Manager (Chef de projet) | Décomposition des besoins, classification et création de tickets | En attente -> En cours / Demande de validation | Le scénario de création de ticket s'arrête en [En attente] en attendant l'autorisation de démarrage ; demande de validation humaine |
@flow-architect | Qian Architect (Architecte système) | Architecture globale du système, contrat d'interface et choix techniques | En attente -> En cours -> Terminé | Produit un document ADR et un plan d'architecture |
@flow-dev | Li Dev (Ingénieur développeur) | Codage principal back-end / full-stack et implémentation de tests unitaires | En attente -> En cours -> En revue | Doit exécuter les tests unitaires, générer un rapport de développement, fournir --summary pour la soumission à la revue |
@flow-frontend | Ma Frontend (Ingénieur développeur frontend) | Implémentation des composants Web/UI et de l'expérience frontend | En attente -> En cours -> En revue | Vérifier le rendu des composants et l'interaction, générer un rapport, fournir --summary pour la soumission à la revue |
@flow-reviewer | Zhou Reviewer (Expert en revue de code) | Convention de code, analyse de sécurité et contrôle qualité | En revue -> En test / En revue -> Terminé (Passage direct sans QA si les justificatifs Tier-3 sont frais et non dérivés) / En revue -> Retourné | Analyse statique sans alerte, produire un avis de revue |
@flow-qa | Zhang QA (Ingénieur test) | Tests d'intégration ciblés et validation de sortie (exécuter uniquement les tests liés à la tâche en cours, interdiction des scripts complets) | En test -> Terminé / En test -> Retourné | Rédiger des cas de test ciblés, enregistrer le temps de travail réel |
@flow-docs | Li Wentong (Ingénieur documentation) | Gestion des documents livrables et manuel utilisateur | En attente -> En cours -> Terminé | Suivre la norme GB/T 7713 académique et d'ingénierie |
@flow-devops | Lv Gaite (Administrateur DevOps) | Fusion de branches, construction de release et protection de l'historique Git | En attente -> En cours -> Terminé | Vérifier la réussite du pipeline, résoudre le blocage de la PR |
Index des entités des spécifications modulaires (consulter le fichier de spécification spécifique selon les besoins)
Lorsque et seulement lorsque l'on entre dans un scénario métier spécifique, l'agent doit appeler view_file pour consulter le fichier Markdown correspondant de la spécification :
- Premier chargement / SOP de démarrage à froid : Consulter
references/02-bootstrap/01-initialization_sop.md - Création de tâche / Décision de responsabilité unique : Consulter
references/01-gateway/01-task_classification.md - Transition de tâche / Règles de porte / Permissions de rôle : Consulter
references/03-engine/01-state_flow_rules.md - Transfert de contexte / Handoff inter-agent (CCP) : Consulter
references/04-ccp/01-ccp_protocol_spec.md - Opérations du tableau Kanban / Déblocage automatique de PR : Consulter
references/05-kanban/01-kanban_operations.md - Fusion de branches Git / Journal d'audit et métriques : Consulter
references/06-governance/01-git_and_audit_spec.md