API Python¶

Cette page épuise les 62 symboles publics du __all__ de premier niveau de flower : signatures, paramètres, valeurs par défaut, sémantique, attributs et méthodes publics. Après lecture, vous n'aurez plus besoin d'ouvrir le code source pour retrouver un paramètre.

L'organisation suit ce qui vous intéresse, pas les fichiers de modules — pour savoir « comment empêcher le coordinateur de mettre lui-même la main à la pâte », allez à la couche hook ; pour savoir « comment le résultat de l'étape précédente est transmis à la suivante », allez au workflow. La terminologie suit systématiquement le glossaire.

Version 0.1.0, dépend de claude-agent-sdk>=0.2.152. Toutes les signatures correspondent au code source mot pour mot.

from flower import Runtime, Workflow, Step, coordinator, worker   # 顶层一次导入

Ce que contient cette page¶

Six valeurs par défaut qui mordent¶

Ces six lignes ne sont pas des détails : ce sont les six accidents les plus fréquents. Chacune est expliquée en entier dans la section correspondante.

Runtime¶

Code source : flower/core/runtime.py

Runtime est le cœur d'exécution. Il détient l'espace de travail, le session store, le workbench, la politique de résilience et la politique de handoff, et n'expose qu'un seul verbe : run une étape. Les nouvelles tentatives, la reprise après interruption, le handoff quand le contexte est plein — tout se fait à l'intérieur de cet unique appel.

Runtime¶

Runtime(
    *,
    workspace: str | Path,
    run_dir: str | Path = "runs",
    portable: bool = True,
    trim: TrimPolicy | bool = False,
    ephemeral: EphemeralPolicy | bool = True,
    keep_denials: int = 1,
    workbench: Workbench | bool = False,
    spill_threshold: int | None = 4000,
    resilience: Resilience | bool = True,
    handoff: HandoffPolicy | bool = True,
)

Les paramètres du constructeur sont tous keyword-only (* en tête), workspace est obligatoire.

Le session store est câblé en dur : c'est toujours PruningSessionStore(run_dir/"sessions.db", workspace=..., policy=<TrimPolicy>, ephemeral=<EphemeralPolicy>, prune=PrunePolicy(keep_denials=...)). Les paramètres du constructeur n'offrent pas de point d'entrée pour changer de backend — pour en changer, construisez vous-même un AgentSpec + build_options(session_store=...), ou écrasez rt.store après construction.

Les deux dernières étapes de la construction sont load_dotenv() et check_credentials(), cette dernière lève un RuntimeError en cas d'erreur. Sans identifiants, l'explosion a lieu à la construction, pas au run().

Attributs publics¶

Constantes de classe : INTERRUPTED = "interrupted-by-human", HANDOFF_DUE = "context-full-handoff", INTERRUPT_NOTE (le paragraphe ajouté après le message humain lors d'une reprise après interruption, expliquant qu'« un appel d'outil en vol renvoyant interrupted est un effet de bord normal de l'interruption, pas une panne d'environnement »).

Méthodes publiques¶

Runtime.run(...)¶

async def run(
    self,
    spec: AgentSpec,
    prompt: str,
    *,
    step_name: str | None = None,
    resume: str | None = None,
    fork: bool = False,
    resume_at: str | None = None,
    on_event: Callable[[Event], None] | None = None,
) -> StepResult

Chaque étape commence par remettre le niveau de contexte à zéro (self._ctx, self._warned = 0, False). Suit une boucle avec quatre sorties :

1. Succès → sortie de boucle.
2. Interruption humaine (result.error == INTERRUPTED) → non soumis à max_attempts, n'attend pas le réseau. resume la même session avec le message humain, attempt -= 1 (une interruption ne compte pas comme tentative ratée), prompt = message humain + INTERRUPT_NOTE. Sans session_id obtenu, il ne reste qu'à s'arrêter.
3. Contexte plein (result.error == HANDOFF_DUE, ou bien handoff.enabled avec un session_id obtenu et is_overflow(...) déclenché) → également non soumis à max_attempts. On vérifie d'abord len(result.retired) >= handoff.max_generations ; si dépassé, l'erreur est remplacée par un diagnostic et on sort ; sinon on écrit le document de handoff → resume=None, fork=False (session entièrement neuve) → le prompt devient h.prompt_block() → niveau de contexte remis à zéro → attempt -= 1.
4. Panne réessayable → sortie si not resilience.enabled or attempt >= max_attempts ; sortie aussi si classify(error) juge qu'il ne faut pas réessayer ; sinon émission d'un Event("retry"), wait_online() en attente du réseau, sleep(delay_for(attempt)) ; si un session_id a été obtenu, on reprend avec resume (le prompt devient resilience.resume_prompt), et result.resumed passe à True.

Clôture : écriture de ended_at, ajout à self.results, écriture de manifest.json.

manifest.json a une sémantique d'append : chaque écriture relit le disque et déduplique sur le champ run (sa propre ligne est remplacée, celles des autres sont conservées), donc lancer deux flower en parallèle sous le même run_dir est sûr — à condition que les run_id n'entrent pas en collision.

Les trois points d'observation du handoff (tous des Event("handoff"), distingués par payload["phase"]) : near (approche de warn_at, émis une seule fois par génération), writing (rédaction du handoff en cours, une dizaine de secondes), done (payload avec degraded / path / sections). Le tour qui écrit le handoff est exécuté avec replace(spec, max_budget_usd=None) — le handoff doit pouvoir être écrit, il ne peut pas se retrouver bloqué par le budget ; et avec on_event=None, ce tour n'est pas poussé vers l'UI.

Le handoff est écrit dans <workbench.notes>/交接-<步骤名>.md ; sans workbench, rien n'est écrit sur disque, le document est quand même transmis au successeur via le prompt, il est simplement introuvable après coup. Les anciens handoffs sont déplacés vers notes/archive/交接/<名>-<时间戳>.md.

StepResult¶

@dataclass
class StepResult:
    step: str
    session_id: str | None = None
    ok: bool = False
    cost_usd: float = 0.0
    num_turns: int = 0
    text: str = ""
    error: str | None = None
    started_at: float = 0.0
    ended_at: float = 0.0
    attempts: int = 1
    errors: list[str] = field(default_factory=list)
    resumed: bool = False
    retired: list[str] = field(default_factory=list)
    context: int = 0

L'intégralité des comptes d'une étape terminée.

Workflow¶

Source : flower/workflow/

Un workflow est un ensemble d'étapes enchaînées dans l'ordre, plus la façon dont l'état circule entre elles et le moment où l'on sort en avance. Le framework ne fournit aucun workflow tout prêt ; c'est vous qui l'écrivez — starter_flow n'est qu'un gabarit qui tourne.

Alias de type Ctx = dict[str, Any] (flower.workflow.base.Ctx, présent dans flower.workflow.__all__, absent du __all__ de premier niveau).

Step¶

@dataclass
class Step:
    name: str
    spec: AgentSpec
    prompt: str | Callable[[Ctx], str]

    resume_from: str | None = None
    fork: bool = False

    retries: int = 0
    gate: Callable[[StepResult, Ctx], bool] | None = None
    on_fail: str = "stop"
    when: Callable[[Ctx], bool] | None = None
    on_reject: Callable[[StepResult, Ctx], str] | None = None
    resume_prompt: str | Callable[[Ctx], str] | None = None
    reduce: Callable[[StepResult, Ctx], str] | None = None

La déclaration d'une étape. Step n'est pas lui-même une fonction — ce qui s'exécute réellement, c'est Runtime.run(step.spec, prompt, ...). Les trois premiers champs sont positionnels : Step("取词", terse, "读 seed.txt …") est une écriture valide.

Trois façons de raccorder les sessions (au sein d'un même run) :

on_reject change la sémantique des retries :

• Absent → la tentative suivante repart de zéro (même prompt, même resume_from).
• Présent → la tentative suivante reprend la session qui vient d'être refusée, le prompt est remplacé par sa valeur de retour, fork est forcé à False.
• Renvoie une chaîne vide → pas de renvoi, on retombe sur un départ de zéro.
• result.session_id vaut None → on retombe aussi sur un départ de zéro.

Les trois valeurs de on_fail :

Que ce soit passé ou non, ctx["_results"][name] = result est toujours écrit ; si result.session_id est non vide, il est aussi écrit dans ctx["_sessions"] avec lineage.remember(...).

Workflow¶

@dataclass
class Workflow:
    steps: list[Step]
    name: str = "workflow"
    context: Ctx = field(default_factory=dict)
    channel: Any = None
    workbench: Any = None
    continuous: bool = True

    async def run(
        self,
        runtime: Runtime,
        *,
        on_event: Callable[[Event], None] | None = None,
        on_step: Callable[[Step, StepResult], None] | None = None,
    ) -> Ctx

Exécute une suite de Step dans l'ordre et renvoie le ctx final. steps est positionnel, Workflow([...]) est valide.

Les clés privées que run() écrit dans le ctx (toutes préfixées par _, aucune collision possible avec un nom d'étape) :

Payload de Event("step") : {"index": i, "total": len(steps), "resumed": bool, "woke": int}.

Étiquettes de retry : la tentative 0 utilise step.name ; ensuite, avec on_reject, f"{name}#round{attempt+1}", sinon f"{name}#retry{attempt}". Dans le manifest, on voit d'un coup d'œil comment l'étape s'est terminée. Les noms suffixés n'entrent pas dans le lineage inter-processus — Lineage.remember utilise le nom d'origine.

runtime.on_session ne couvre que la ligne runtime.run, avec un try/finally qui garantit son retrait avant le gate. prompt_cur / resume_cur / fork_cur sont des variables locales, jamais réécrites dans step — le même objet Step peut être exécuté une seconde fois.

StepAbort¶

class StepAbort(Exception): ...

Levée par un gate = arrêt immédiat, pas de nouvelle tentative. Différence avec « renvoyer False » : False veut dire « pas cette fois, on refait un tour » ; StepAbort veut dire « refaire n'y changera rien ».

Après la levée : ctx["_aborted"] = str(exc), passed = False, sortie de la boucle de retry (les retries restants ne sont pas consommés), puis traitement comme un échec ordinaire via on_fail (par défaut "stop").

with_goal la lève à deux endroits : quand ctx["_runtime"] est introuvable, et quand le verdict est unreachable sans personne pour répondre.

clarify_step()¶

def clarify_step(
    channel: HumanChannel,
    *,
    brief_path: str | Path,
    prompt: str | Callable[[Ctx], str],
    name: str = "确认需求",
    spec: AgentSpec | None = None,
    instructions: str = "",
    always_ask: bool = False,
    on_fail: str = "stop",
    retries: int = 0,
    **spec_kw,
) -> Step

Produit un Step de clarification préalable : cerner le besoin → parser en Brief → geler et écrire sur disque dès que les quatre sections sont complètes.

Les champs du Step produit sont remplis ainsi :

• resume_prompt = CLARIFY_RESUME.
• when : always_ask=True → toujours True ; sinon, si Brief.load(brief_path) est complet, il est versé dans le ctx puis on renvoie False (saut) — même en sautant il faut le verser, sinon l'aval n'a pas le besoin.
• gate : Brief.parse(result.text) ; incomplet → écrit ctx[MISSING_KEY] et renvoie False ; complet → b.write(brief_path) pour geler, versement dans le ctx, renvoie True.
• reduce : renvoie ctx[BRIEF_KEY].prompt_block(), pas le texte brut du modèle — le texte brut peut charrier ce qu'il a écrit en plus.
• resume_from reste à None par défaut : l'étape suivante est une session neuve, elle ne reçoit que le brief, pas le questionnaire. Les questions-réponses de la clarification préalable ne sont jamais entrées dans le contexte du coordinateur ; elles n'y sont pas entrées puis élaguées.

Les trois versements dans le ctx : ctx[BRIEF_KEY] = b, ctx[name] = b.prompt_block(), ctx.pop(MISSING_KEY, None).

goal_step()¶

def goal_step(
    channel: HumanChannel,
    *,
    goal_path: str | Path,
    brief_key: str = "确认需求",
    name: str = "设定目标",
    spec: AgentSpec | None = None,
    instructions: str = "",
    always_set: bool = False,
    on_fail: str = "stop",
    retries: int = 0,
    **spec_kw: Any,
) -> Step

Produit un Step qui fixe l'objectif : le juge lit le brief, rédige l'objectif + la checklist de verdict, le tout parsé en Goal puis gelé et écrit sur disque. Même forme que clarify_step.

Il n'y a pas de paramètre can_run — pour que le juge qui fixe l'objectif puisse lancer des commandes, il faut passer can_run=True via **spec_kw. Sans cela, il n'a pas Bash et la règle de JUDGE_RULES « commence par regarder dans quel environnement tu es » n'est pas exécutable.

Au-delà du parsing et du gel, le gate fait une chose de plus : si l'objectif contient des entrées [此环境无法验证:…], il émet sur-le-champ, via ctx["_on_event"], un Event("task", payload={"unverifiable", "total", "path"}) en guise d'alerte — le sort de ces entrées est scellé au moment où l'on fixe l'objectif ; attendre le verdict, c'est avoir déjà dépensé le prix d'un tour de travail complet.

Aucun resume_prompt n'est défini — fixer l'objectif doit de toute façon renvoyer le brief en entier.

with_goal()¶

def with_goal(
    step: Step,
    channel: HumanChannel,
    *,
    goal_path: str | Path,
    spec: AgentSpec | None = None,
    rounds: int = 3,
    instructions: str = "",
    can_run: bool = False,
    name: str | None = None,
    **spec_kw: Any,
) -> Step

Pose un gardien d'objectif sur un Step existant : à la fin de chaque tour, le juge rend un verdict indépendant ; si l'objectif n'est pas atteint, le travail est renvoyé pour être poursuivi.

Le résultat est replace(step, retries=max(0, rounds - 1), gate=<新 gate>, on_reject=<新 on_reject>) — on utilise dataclasses.replace plutôt qu'une reconstruction champ par champ ; une reconstruction a déjà oublié resume_prompt une fois, sans lever la moindre erreur, avec pour seul effet de renvoyer l'intégralité du brief à chaque reprise.

Le gate est async, déroulé :

1. ctx["_runtime"] absent → lève StepAbort (« 拿不到 Runtime,无法判定目标 »). Ne pas faire semblant que ça passe.
2. ctx[ROUND_KEY] += 1.
3. Récupération de l'objectif : en priorité un Goal complet dans ctx[GOAL_KEY], sinon Goal.load(goal_path), sinon un Goal() vide.
4. await rt.run(judger, VERIFY_PROMPT..., step_name=f"{label}#{轮次}", on_event=...). Le juge est un Runtime.run indépendant, resume vaut toujours None — c'est toujours une session neuve ; step_name porte le numéro de tour, il n'entre donc pas dans le lineage inter-processus.
5. Verdict.parse(vr.text) est écrit dans ctx[VERDICT_KEY].
6. v.achieved → renvoie True.
7. Pas unreachable (y compris les cas ambigus avec v.ok=False) → en cas d'ambiguïté, on ajoute une reason par défaut et on renvoie False. Toute ambiguïté compte comme non atteint — on ne laisse pas un « ça a l'air bon » clore le travail.
8. unreachable → await channel.ask(...) pour interroger l'humain, trois options :
9. Personne ne répond (a.state != "answered") → lève StepAbort. Continuer à tourner à vide est le choix le plus cher.
10. « Accepter ce résultat et continuer ainsi » → renvoie True.
11. « Modifier l'objectif » → nouvelle question pour le nouvel objectif, g.amend(...).write(goal_path), mise à jour de ctx[GOAL_KEY], renvoie False.
12. Le reste (y compris une réponse libre tapée par l'humain) → traité comme « tu t'es trompé dans ton verdict », le propos de l'humain est consigné dans v.reason, renvoie False.

on_reject est synchrone : il renvoie ctx[VERDICT_KEY].feedback(), ou "" s'il n'y a pas de Verdict (on retombe alors sur un départ de zéro).

starter_flow()¶

def starter_flow(
    ask: str,
    *,
    workspace: str | Path = ".",
    run_dir: str | Path = "runs",
    new: bool = False,
    isolate: bool = False,
    clarify_only: bool = False,
    goal: bool = True,
    rounds: int = 3,
    judge_can_run: bool = False,
    max_asks: int | None = None,
    timeout_s: float | None = 1800.0,
    instructions: str = "",
    worker_prompt: str = "你负责实现。每改一处就跑一次验证,别攒到最后。",
    brief_name: str = "需求.md",
    goal_name: str = "目标.md",
    log_name: str = "问答记录.md",
) -> Workflow

Assemble un workflow en trois étapes qui tourne tel quel : clarifier le besoin → fixer l'objectif → travailler (avec gardien d'objectif). C'est ce qu'utilise la commande flower.

Assemblage fixe :

Workflow(name="starter", channel=ch, workbench=wb, steps=[...])
# ch = HumanChannel(log_path=<notes>/问答记录.md, amend_path=<brief_path>,
#                   max_asks=max_asks, timeout_s=timeout_s)
# 协调者 = coordinator("协调者", "", {"coder": worker(..., isolate=isolate)}, channel=ch)

Branches de comportement :

• isolate=True et workspace qui n'est pas un dépôt git → lève ValueError, sans attendre que l'outil Agent remonte l'erreur (à ce moment-là l'argent est déjà dépensé).
• Détection du réveil : si Brief.load(brief_path) existe et que complete() est vrai, c'est un réveil. Pas un réveil et ask vide → lève ValueError("要给一句诉求,例如 flower '帮我做一个 X'").
• Au réveil, cette phrase atterrit simultanément à trois endroits ; s'il en manque un, elle échoue silencieusement : ajoutée au brief (ch.amend(said, label="唤醒时追加"), sans réécriture si elle est déjà dans le fichier), transmise à goal_step(always_set=True) pour recalculer la checklist (sinon le juge lit toujours l'ancien objectif), et remise directement au coordinateur (son contexte contient l'ancien objectif ; sans elle, il travaille selon les anciens critères puis se fait juger selon les nouveaux).

wake_state()¶

def wake_state(
    workspace: str | Path = ".",
    *,
    run_dir: str | Path = "runs",
    isolate: bool = False,
    brief_name: str = "需求.md",
    goal_name: str = "目标.md",
) -> dict

Une sonde en lecture seule avant le départ, pas un octet écrit. Sert à dire à l'humain, avant que ça démarre vraiment, s'il s'agit d'une reprise ou d'un départ de zéro.

Le dict renvoyé :

L'emplacement du workbench n'est défini qu'ici et dans starter_flow : isolate=True → <ws>.parent/.flower-<ws.name> (hors du dépôt) ; sinon <ws>/.flower. Un programme pilote qui veut savoir où est le brief passe aussi par cette fonction — reconstruire le chemin à la main ne lève aucune erreur, ça échoue simplement en silence.

Fabriques de rôles¶

Source : flower/core/roles.py

Les cinq rôles sont tous des fonctions fabriques. Chaque rôle = un texte de règles injecté + un jeu d'outils + un jeu de hooks. worker() produit un AgentDefinition du SDK (destiné à un subagent) ; les quatre autres produisent un AgentSpec (qui ouvre sa propre session).

Les rôles eux-mêmes n'attachent aucun hook — l'interception des outils est montée automatiquement par Runtime._attempt selon spec.delegate_only, voir la couche hook.

Constantes internes de groupes d'outils (non exportées, mais elles décident des valeurs par défaut) :

COORDINATOR_TOOLS = ["Agent", "TodoWrite", "Read"]
WEB_TOOLS         = ["WebFetch", "WebSearch"]
WORKER_TOOLS      = ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "WebFetch", "WebSearch"]

coordinator()¶

def coordinator(
    name: str,
    instructions: str,
    workers: dict[str, AgentDefinition],
    *,
    channel: Any = None,
    can_read: bool = True,
    glance: bool = True,
    model: str | None = None,
    effort: str | None = None,
    max_turns: int | None = None,
    max_budget_usd: float | None = None,
    permission_mode: str = "acceptEdits",
    compact: Any = None,
    hooks: dict[str, Any] | None = None,
    env: dict[str, str] | None = None,
) -> AgentSpec

Fabrique le coordinateur qui vit sur le thread principal : il découpe la tâche, distribue le travail, lit les rapports, décide, mais ne met pas la main à la pâte. Les trois premiers paramètres sont positionnels.

Trois éléments sont figés dans l'AgentSpec produit : delegate_only=True, agents=workers, et workbench garde la valeur par défaut True d'AgentSpec.

Les outils web des workers sont fusionnés ici¶

Une fois la liste constituée, coordinator() parcourt les AgentDefinition.tools de chacun ; tout ce qui tombe dans WEB_TOOLS (WebFetch, WebSearch, roles.py:33) est également ajouté à l'allowed_tools du coordinateur lui-même (roles.py:523-526).

Raison : allowed_tools, tout comme disallowed_tools, est au niveau session. C'est la preuve la plus dure de tout le document sur ce point — cela ne concerne pas que le thread principal. Un outil absent de cette liste au niveau session passe aussi par l'approbation de permission quand c'est un subagent qui l'appelle ; en mode sans surveillance, personne n'approuve, le harness répond Claude requested permissions to use X, but you haven't granted it yet (toolDenialKind=user-rejected), et le modèle réessaie indéfiniment le même appel. Vécu en vrai : on avait ajouté WebFetch/WebSearch à l'exécutant, mais uniquement dans AgentDefinition.tools ; ce run novel a produit plus de vingt user-rejected et pas un seul mot écrit (roles.py:513-518).

Les deux champs ont la même nature au niveau session, mais les symptômes diffèrent : disallowed_tools échoue sur-le-champ, allowed_tools réessaie en silence jusqu'à la mort. Le second est plus difficile à diagnostiquer, parce que rien à l'écran ne ressemble à une erreur.

On ne fusionne que ce qui est en lecture seule et sans effet de bord. Write/Edit/Bash sont délibérément exclus : dès que le thread principal en est dispensé d'approbation, le mur « le coordinateur ne met pas la main à la pâte » de delegate_guard n'a plus de sens ; et de toute façon les Bash/Write des subagents passent déjà (462 autorisations mesurées, roles.py:520-522).

Le code source écrit noir sur blanc de ne pas utiliser disallowed_tools pour obtenir « coordonner sans agir » — c'est au niveau session, cela interdirait aussi les Bash/Write des subagents, voir l'avertissement de AgentSpec. La bonne méthode est celle d'ici : delegate_only=True + ne rien mettre dans allowed_tools, puis laisser delegate_guard n'intercepter que le thread principal via agent_id.

Si channel est fourni, les deux outils arrivent ensemble, ce n'est pas optionnel : dès que le serveur MCP est monté, les deux sont là, et allowed_tools n'étant pas exclusif, ils sont appelables qu'ils y figurent ou non. Sans surveillance, chaque ask va bloquer jusqu'au bout de timeout_s — dans ce cas, utiliser HumanChannel(timeout_s=0).

worker()¶

def worker(
    description: str,
    prompt: str,
    *,
    tools: list[str] | None = None,
    model: str = "inherit",
    effort: str | int | None = None,
    max_turns: int | None = None,
    permission_mode: str | None = None,
    skills: list[str] | None = None,
    discipline: bool = True,
    isolate: bool = False,
) -> AgentDefinition

Fabrique la définition du subagent qui fait réellement le travail. Les deux premiers paramètres sont positionnels. Retourne un AgentDefinition du SDK, à passer directement dans coordinator(workers={...}).

isolate=True exige que le workspace soit un dépôt git, sinon l'outil Agent renvoie directement "not in a git repository" — il n'y a pas de dégradation silencieuse. Et comme la marque est un attribut Python, un dataclasses.replace() sur l'AgentDefinition la perd : l'isolation devient silencieusement inopérante.

clarify()¶

def clarify(
    name: str,
    channel: Any,
    *,
    instructions: str = "",
    can_read: bool = True,
    model: str | None = None,
    effort: str | None = None,
    max_turns: int | None = None,
    max_budget_usd: float | None = None,
) -> AgentSpec

Fabrique le clarificateur : il tire le besoin au clair avant d'agir, ne fait rien, ne fait que poser des questions, et sort à la fin exactement quatre sections.

L'AgentSpec produit : allowed_tools = [channel.tool_name] + (les cinq outils si lecture autorisée), mcp_servers = channel.mcp_servers(), workbench=False (il n'a pas d'outil d'écriture, l'index n'a aucun sens pour lui), permission_mode hérite du "default" par défaut d'AgentSpec. Pas de Write / Edit / Bash / Agent, ni d'inbox (contrairement au coordinateur).

judge()¶

def judge(
    name: str,
    channel: Any,
    *,
    instructions: str = "",
    can_run: bool = False,
    model: str | None = None,
    effort: str | None = None,
    max_turns: int | None = None,
    max_budget_usd: float | None = None,
) -> AgentSpec

Fabrique le juge : soit il fixe l'objectif avant le départ, soit il rend le verdict du tour à la fin de chaque tour.

L'AgentSpec produit : allowed_tools = [channel.tool_name, "Read", "Glob", "Grep"] + (si can_run) ["Bash"], workbench=False, le reste comme clarify(). Pas de Write / Edit / Agent, ni d'inbox.

Arbitrage : can_run=True donne un verdict plus dur (il peut vraiment exécuter les commandes de recette), au prix de la capacité du juge à modifier l'espace de travail — Bash sait écrire des fichiers. Pour un verdict absolument neutre, ne pas l'activer.

oracle()¶

def oracle(
    name: str = "旁路问答",
    *,
    instructions: str = "",
    model: str | None = None,
    effort: str | None = None,
    max_turns: int | None = 12,
    max_budget_usd: float | None = 0.5,
) -> AgentSpec

Fabrique l'oracle : pendant que le run tourne encore, on lui demande « où en est-on ? », il jette un œil aux événements récents et au workbench puis répond. Ce qu'il dit n'entre pas dans le contexte de ce run.

L'AgentSpec produit : allowed_tools = ["Read", "Glob", "Grep"] (pas de channel — il ne pose pas de questions, il y répond), workbench=True (le seul des cinq rôles à ouvrir le workbench sans être coordinateur — c'est justement pour aller lire les livrables et les notes).

Les cinq textes de règles¶

Les cinq constantes sont dans __all__ : on peut les import telles quelles pour les lire, les concaténer, les modifier.

Définition d'agent¶

Source : flower/core/agent.py

AgentSpec est la déclaration complète d'un agent spécialisé ; build_options la compile en ClaudeAgentOptions du SDK. C'est un AgentSpec que produisent les fabriques de rôles — pour une composition hors fabrique, on le construit directement.

AgentSpec¶

@dataclass
class AgentSpec:
    name: str
    instructions: str
    allowed_tools: list[str] = field(default_factory=lambda: ["Read", "Glob", "Grep"])
    disallowed_tools: list[str] = field(default_factory=list)
    model: str | None = None
    effort: str | None = None
    max_turns: int | None = None
    max_budget_usd: float | None = None
    permission_mode: str = "default"
    agents: dict[str, Any] | None = None
    mcp_servers: dict[str, Any] = field(default_factory=dict)
    hooks: dict[str, Any] | None = None
    compact: CompactPolicy | None = None
    env: dict[str, str] = field(default_factory=dict)
    glance: bool = False
    workbench: bool = True
    delegate_only: bool = False

build_options()¶

def build_options(
    spec: AgentSpec,
    *,
    cwd: str | Path | None = None,
    session_store: SessionStore | None = None,
    resume: str | None = None,
    fork: bool = False,
    resume_at: str | None = None,
    use_plugin: bool = True,
    portable: bool = True,
    add_dirs: list[str] | None = None,
    flush: str = "eager",
    prelude: str = "",
) -> ClaudeAgentOptions

Compile un AgentSpec en ClaudeAgentOptions du SDK. C'est ce qu'appelle Runtime._attempt en interne ; c'est aussi le point d'entrée si l'on pilote le SDK soi-même (sans Runtime).

Correspondances :

PLUGIN_DIR est le répertoire plugin/ à la racine du dépôt (trois niveaux au-dessus de flower/core/agent.py). Après une installation pip, ce répertoire n'existe pas forcément ; le code le teste avec is_dir().

CompactPolicy¶

@dataclass
class CompactPolicy:
    mode: str = "auto"
    window: int | None = None

    def env(self) -> dict[str, str]: ...

Le tableau de bord de l'auto-compact ; son produit est un jeu de variables d'environnement à injecter dans le sous-processus. L'algorithme de compact lui-même est dans le binaire du harness et n'est pas modifiable ; la seule chose modifiable est « déclencher ou non ».

HandoffPolicy¶

@dataclass
class HandoffPolicy:
    enabled: bool = True
    window: int = field(default_factory=default_window)
    headroom: int = 50_000
    max_generations: int = 8

    @property
    def at(self) -> int: ...        # max(10_000, window - headroom)
    @property
    def warn_at(self) -> int: ...   # max(1_000, at - 20_000)

L'objet de politique qui, quand le contexte est presque plein, « écrit un document de handoff et repart sur une nouvelle session » au lieu de compacter.

default_window()¶

def default_window() -> int

Devine la fenêtre de contexte à partir de la chaîne du nom de modèle dans les variables d'environnement ANTHROPIC_MODEL ou ANTHROPIC_DEFAULT_OPUS_MODEL :

La valeur par défaut est agressive. Surestimer n'est pas une erreur dure : l'API renvoie prompt is too long, Runtime reconnaît ce signal (le is_overflow interne) et déclenche un handoff sur-le-champ — mais le handoff de cette génération-là est une version dégradée.

Documents¶

Sources : brief.py · handoff.py · goal.py

Quatre dataclasses, toutes sur le même principe : « parser une réponse du modèle en un nombre fixe de sections, puis écrire sur disque ». Forme commune : parse() parse, missing() / complete() vérifient la complétude, to_markdown() pour l'humain, prompt_block() pour le modèle en aval, write() / load() pour l'écriture et la relecture.

Brief¶

@dataclass
class Brief:
    goal: str = ""
    accept: str = ""
    bounds: str = ""
    unknowns: str = ""
    path: Path | None = field(default=None, compare=False)

Le brief, exactement quatre sections, dans l'ordre fixe goal → accept → bounds → unknowns ; les noms de sections en chinois sont respectivement 「目标」(objectif), 「验收标准」(critères d'acceptation), 「边界」(limites), 「未知与假设」(inconnues et hypothèses).

Règles de parsing (là où se concentrent les pièges) :

• Au retrait des blocs délimités, **en cas de `` ou de_~non refermé, tout est jeté à partir de là** — en conditions réelles, le clarificateur colle parfois tout le code dans sa réponse. Quand la sortie du modèle est tronquée, aucune des sections suivantes n'est parsée,complete()vaut doncFalse`, et le gate renvoie à la case départ.
• La regex de titre tolère ## 目标 / **目标** / 目标: / 3. 边界, et tolère aussi que le corps suive directement le titre.
• La table d'alias est compilée par longueur décroissante, sinon « 未知 » avalerait « 未知与假设 » en premier.
• En cas de répétition d'une même section, on prend la première qui a du contenu.
• Si, en éditant le brief à la main, on recopie le placeholder "(未填)" de to_markdown(), la section compte toujours comme manquante.

Handoff¶

@dataclass
class Handoff:
    doing: str = ""
    decided: str = ""
    deadends: str = ""
    next: str = ""
    scene: str = ""
    step: str = ""
    path: Path | None = field(default=None, compare=False)

Le document de handoff écrit lors d'un handoff, cinq sections.

Seules deux sections sont obligatoires : doing et next — exiger que « les impasses » soit non vide pousserait le modèle à inventer.

Dans le même module, trois membres non exportés mais sémantiquement essentiels : is_overflow(*texts) détecte prompt is too long, context length exceeded, maximum context length, too many total text bytes, input length and max_tokens exceed, etc., et transforme une « erreur dure » en « handoff immédiat » ; HANDOFF_PROMPT est le prompt qui fait écrire le handoff par la session courante elle-même (avec les deux placeholders {used} et {window}, ce n'est pas un nouveau rôle — elle seule possède ce contexte) ; degraded(step, prompt, *, why="") fabrique mécaniquement un document quand le handoff n'a pas pu être écrit, en fourrant dans scene les 1200 premiers caractères de la tâche d'origine.

Goal¶

@dataclass
class Goal:
    statement: str = ""
    checks: list[str] = field(default_factory=list)
    path: Path | None = None

L'objectif et la liste de verdict du gardien d'objectif.

Verdict¶

@dataclass
class Verdict:
    state: str = ""
    reason: str = ""
    failed: list[str] = field(default_factory=list)

Le résultat d'un tour de verdict du juge, exactement trois sections : conclusion / justification / items non passés.

Ordre de reconnaissance de parse :

1. D'abord, prendre la section de titre 「结论」/「判定」.
2. En l'absence de section de titre, sur le texte entier après strip : fullmatch(r"1|true") → atteint ; fullmatch(r"0|false") → pas encore.
3. Sinon, chercher dans le texte de conclusion le premier mot trouvé selon la table des mots d'état (les mots longs d'abord). 「无法验证 / 没法验证 / 验证不了 / 无法判定 / unverifiable」 sont tous rangés sous unreachable — vécu en vrai : plateforme cible macOS, exécution dans un conteneur Linux, le juge a regardé la branche du code source et a prononcé la réussite.
4. Toujours rien → chercher un \b1\b isolé → atteint, \b0\b → pas encore.
5. Rien ne correspond → state="", ok=False.

unreachable et not_yet sont deux conclusions différentes : la première emprunte la voie « s'arrêter et demander à un humain », pas celle de « refaire un tour ».

Couche hook¶

Source : flower/core/guard.py

Cette couche est la frontière d'exécution de flower : quels outils le thread principal n'a pas le droit de toucher, comment rogner un résultat trop long, quel rôle part dans un worktree indépendant — tout est imposé par les hooks du SDK, pas par le prompt. La raison est directe : un prompt est une suggestion, le modèle peut l'ignorer. Mesuré : même avec un system prompt qui écrit explicitement « n'utilise pas de worktree », l'injection d'isolate_guard s'applique quand même (le modèle passe None, ce qui atterrit est 'worktree').

Neuf exports : cinq fabriques de guard qui retournent un HookMatcher (whitelist_guard peut retourner None), un assembleur, un fusionneur, deux fonctions de marquage d'isolation. Il n'y a pas besoin de les brancher à la main — Runtime les monte automatiquement d'après l'AgentSpec. Le branchement manuel n'est nécessaire que si l'on pilote le SDK soi-même (sans passer par Runtime).

La détection du thread principal passe par une seule fonction : _is_main_thread(data) = not data.get("agent_id") — les données de tool-lifecycle hook d'un subagent portent un agent_id, celles du thread principal non. Tous les guards « n'intercepter que le thread principal » reposent sur cette ligne.

Constantes de groupes d'outils (niveau module, non exportées, mais elles déterminent les matchers par défaut) :

HANDS_ON   = "Bash|Write|Edit|NotebookEdit"
WRITE_ONLY = "Write|Edit|NotebookEdit"
BULKY      = "Bash|Read|Grep|Glob|WebFetch|WebSearch"

Aide-mémoire : quel guard sur quel événement SDK¶

Le corollaire clé de ce tableau : avec Runtime(workbench=False), workbench_hooks n'est pas installé du tout ; et pour un coordinateur en delegate_only=True, whitelist_guard est également sauté — le thread principal n'a plus le moindre mur. Voir l'avertissement de la section Runtime.

whitelist_guard()¶

def whitelist_guard(allowed: list[str] | None, *, role: str = "这个角色") -> HookMatcher | None

Rendre allowed_tools réellement exclusif pour les quatre outils qui mettent la main à la pâte.

• Monté sur PreToolUse, le matcher est "|".join(banned), où banned = ceux de Bash Write Edit NotebookEdit qui ne sont pas dans allowed.
• En cas de correspondance : permissionDecision: "deny", avec un texte du genre : « XX n'a pas YY. C'est intentionnel, ce n'est pas une configuration oubliée. Écris ta conclusion dans le corps de ta réponse, le framework ira la chercher là — n'essaie pas de contourner par une autre formulation. »
• N'intercepte que le thread principal de la session, les subagents passent — les outils d'un subagent sont déterminés par AgentDefinition.tools.
• Retourne None quand il n'y a rien à intercepter (par exemple un rôle comme worker() qui a la panoplie complète) ; l'appelant décide alors de l'installer ou non.

Pourquoi il doit exister : allowed_tools est une liste de dispense d'approbation, pas une liste blanche exclusive. Deux preuves mesurées : un juge à qui l'on avait donné un objectif a lancé 11 fois Bash ; dans la sonde à $0.1, un agent avec allowed_tools=["Read"] appelait quand même Write/Bash. Donc le « pas d'outil d'écriture » de clarify() / judge() tient à ce hook, pas à la liste blanche elle-même.

L'avantage est qu'il dérive d'allowed_tools : judge(can_run=True) conserve donc automatiquement Bash tout en interceptant Write/Edit — sans interrupteur supplémentaire.

delegate_guard()¶

def delegate_guard(*, tools: str = HANDS_ON, allow_glance: bool = False) -> HookMatcher

Le thread principal met la main à la pâte → refus, avec l'indication du chemin à suivre.

• Monté sur PreToolUse, le matcher est exactement tools.
• Le thread principal appelle un de ces quatre outils → deny, et le motif indique quoi faire ensuite : déléguer à un subagent via l'outil Agent, en écrivant dans la tâche l'objectif et les critères d'acceptation, et en lui demandant d'écrire les productions longues dans .flower/artifacts/ et de ne renvoyer que chemins et conclusions.
• Les subagents passent systématiquement.

La différence avec whitelist_guard est la formulation : les deux interceptent le même ensemble d'outils, mais celui-ci dit « délègue », ce qui est plus juste. Un rôle en delegate_only=True n'installe donc que celui-ci ; installer les deux enverrait au modèle deux consignes contradictoires.

Le critère de passage d'allow_glance=True et le « ce résultat sera-t-il rogné » sont la même fonction (is_ephemeral) — l'ensemble laissé passer doit être égal à l'ensemble qui expire ; modifier l'un oblige à modifier l'autre.

spill_guard()¶

def spill_guard(
    workbench: Workbench,
    *,
    threshold: int = 4000,
    tools: str = BULKY,
    main_only: bool = False,
) -> HookMatcher

Les résultats d'outil qui dépassent le seuil sont spillés sur-le-champ, le contexte ne garde qu'un pointeur d'une ligne — plutôt que d'attendre que le contexte soit plein pour compacter après coup.

• Monté sur PostToolUse, retourne {"hookSpecificOutput": {"hookEventName": "PostToolUse", "updatedToolOutput": <rogné>}}.
• Le nom du fichier de spill est les 16 premiers caractères du sha256 du contenu + .txt ; dans le contexte il est remplacé par un pointeur d'une ligne + les 400 premiers caractères.
• updatedToolOutput doit conserver la structure de sortie de l'outil d'origine, donc on ne remplace que les champs chaîne trop longs du dict ; on ne touche jamais aux listes (elles peuvent contenir des blocs image). Une structure incorrecte est rejetée (le texte original reste, sans erreur).
• La lecture du fichier de spill lui-même doit être laissée passer — sinon « lis-le avec Read » est une phrase creuse : le texte relu est à nouveau spillé, boucle infinie. Rencontré en conditions réelles : le modèle a essayé cinq formulations pour contourner.

index_guard()¶

def index_guard(workbench: Workbench) -> HookMatcher

Dès qu'on écrit quelque chose dans le workbench, INDEX.md est rafraîchi, et l'agent suivant sait dès son ouverture que ça existe.

Monté sur PostToolUse, matcher "Write|Edit". Si tool_input["file_path"] résolu tombe sous workbench.root, appelle workbench.refresh(). Retourne toujours {} — il ne modifie rien, il n'a que des effets de bord.

isolate_guard()¶

def isolate_guard(agents: dict[str, AgentDefinition], *, on_inject: Any = None) -> HookMatcher

Attribue à chaque subagent, selon son rôle, un git worktree indépendant : c'est l'isolation.

Monté sur PreToolUse, matcher "Agent". L'injection n'a lieu que si trois conditions sont réunies : tool_name == "Agent", tool_input n'a ni cwd ni isolation, et le rôle correspondant au subagent_type est marqué par isolated(). Dans ce cas il retourne permissionDecision: "allow" + updatedInput (met isolation à "worktree").

isolation et cwd sont mutuellement exclusifs dans l'outil Agent — si le modèle a lui-même spécifié un cwd, on le respecte. « Faut-il isoler » est une propriété du rôle, pas un interrupteur global, ni une décision prise à chaque délégation ; un rôle qui n'a pas besoin d'isolation ne se voit ajouter aucun octet.

Activer l'isolation impose de sortir le workbench du dépôt. Un agent isolé ne peut pas écrire dans le checkout partagé, donc le workbench doit pointer hors du dépôt via home=. starter_flow(isolate=True) utilise <ws>.parent/.flower-<ws.name>, Runtime(workbench=True) utilise <run_dir>/workbench — les deux sont hors du dépôt, mais ce ne sont pas le même répertoire, ne les mélangez pas.

isolated() / wants_isolation()¶

def isolated(agent: AgentDefinition, flag: bool = True) -> AgentDefinition
def wants_isolation(agent: AgentDefinition | None) -> bool

Marquer une définition de subagent comme « a besoin d'un espace de travail indépendant », et relire ce marquage.

Le marquage est un attribut côté Python _flower_isolate posé via object.__setattr__, pas un champ de dataclass — le SDK sérialise avec asdict(), qui ne reconnaît que les champs déclarés, donc ce marquage ne fuit pas jusqu'au CLI (mesuré).

Le coût : un dataclasses.replace() sur une AgentDefinition perd ce marquage, et l'isolation devient silencieusement inopérante.

worker(isolate=True) passe en interne par isolated().

workbench_hooks()¶

def workbench_hooks(
    workbench: Workbench,
    *,
    delegate_only: bool = True,
    spill_threshold: int | None = 4000,
    agents: dict[str, AgentDefinition] | None = None,
    allow_glance: bool = False,
) -> dict[str, list[HookMatcher]]

Installe en une fois les quelques hooks dont le workbench a besoin. C'est ce qu'appelle Runtime._attempt.

Ce qui est produit :

• PreToolUse : delegate_only=True → [delegate_guard(allow_glance=allow_glance)] ; s'il y a un rôle marqué → ajout d'isolate_guard(agents).
• PostToolUse : toujours [index_guard(workbench)] ; si spill_threshold est vrai → ajout de spill_guard(workbench, threshold=spill_threshold).
• Les clés d'événement dont la liste est vide sont supprimées, on ne retourne pas de liste vide.

merge_hooks()¶

def merge_hooks(*groups: dict[str, list[Any]] | None) -> dict[str, list[Any]]

Concatène plusieurs groupes de configuration de hooks par nom d'événement.

Utilise extend, sans déduplication — passer deux fois le même guard l'installe deux fois. Runtime s'en sert pour fusionner spec.hooks, workbench_hooks(...) et whitelist_guard.

Workbench¶

Source : flower/core/workbench.py

Workbench¶

@dataclass
class Workbench:
    workspace: Path
    dirname: str = ".flower"
    max_index_entries: int = 40
    home: Path | None = None

Le répertoire de travail où l'on écrit sur disque : trois sous-répertoires + un index. L'index est injecté dans le system prompt, donc l'agent sait à chaque tour ce qu'il a en main.

Format d'auto-description d'un script : # desc: une phrase dans les 8 premières lignes (les marqueurs // et -- sont aussi reconnus), avec repli sur le premier commentaire non vide ou la première ligne de la docstring (tronquée à 100 caractères).

Les trois règles injectées par prompt_block() :

1. Les scripts destinés à être relancés vont dans scripts/, avec # desc: en première ligne.
2. Les productions de plus de 2000 caractères vont dans artifacts/, la conversation ne reçoit que le chemin et la conclusion.
3. Les décisions clés vont dans notes/, un fichier par décision.

Quand external=True, prompt_block() insère en plus une phrase « accède-y par chemin absolu ».

Un subagent n'hérite pas de l'index. Celui-ci passe par le system_prompt.append au niveau de la session, alors qu'un subagent a son propre system prompt (mesuré à $0.2461). Les deux points « écrire les productions longues dans artifacts/ » et « où se trouve le workbench » doivent donc être retransmis par le coordinateur dans le brief de tâche — c'est le seul canal, ce n'est pas de la redondance. WORKER_RULES ne l'écrit délibérément pas : le vrai chemin est généré par Workbench, le coder en dur serait faux.

Session store¶

Source : sqlite.py · trim.py · prune.py

Trois niveaux d'héritage : SqliteSessionStore ← TrimmingSessionStore ← PruningSessionStore. Runtime utilise toujours le niveau le plus externe ; les politiques des trois niveaux se pilotent par les paramètres du constructeur.

Chaque niveau s'occupe d'une chose : écrire sur disque, trimmer selon le volume et la valeur, pruner selon « est-ce une erreur ». Le trim et le prune ont tous deux lieu au moment de load() (c'est-à-dire quand le resume réinjecte l'historique dans le modèle) ; l'enregistrement brut dans SQLite n'est pas modifié d'un octet.

SqliteSessionStore¶

class SqliteSessionStore(SessionStore):
    def __init__(self, path: str | Path) -> None

Implémente le protocole SessionStore du SDK, trois tables entries / meta / summaries. La clé de store est project_key/session_id[/subpath] — le transcript d'un sous-agent se distingue par le subpath.

Le _next_mtime interne garantit une stricte monotonie — list_sessions et le sidecar de summary partagent cette horloge, sinon le chemin rapide de détection de staleness du SDK se trompe.

TrimPolicy¶

@dataclass
class TrimPolicy:
    keep_recent: int = 20
    min_chars: int = 2000
    spill_dirname: str = ".flower/spill"
    enabled: bool = True

Les deux répertoires de spill ne sont pas le même. spill_guard écrit dans <workbench.root>/spill/ (qui peut être hors de l'espace de travail) ; TrimPolicy.spill_dirname écrit dans <workspace>/.flower/spill/ (qui doit être dans l'espace de travail). Ils correspondent respectivement au « rognage sur-le-champ » et au « rognage au resume » ; la différence de répertoire est intentionnelle, ne les fusionnez pas.

EphemeralPolicy¶

@dataclass
class EphemeralPolicy:
    enabled: bool = True
    keep_recent: int = 6
    max_chars: int = 2000
    text: str = "[{cmd} 的结果已过期(第 {age} 轮前),当前状态可能已变。需要请重新执行]"

Politique d'expiration des résultats de commandes éphémères.

Ne s'applique qu'aux résultats de l'outil Bash, et seulement si la commande correspond à la liste blanche des commandes éphémères. Read n'en fait pas partie — le contenu d'un fichier ne se dégrade pas avec le temps au point d'induire en erreur. Le contenu expiré n'est pas spillé, il est jeté.

is_ephemeral()¶

def is_ephemeral(cmd: str) -> bool

Détermine si une commande Bash est une commande éphémère. Le critère de passage de delegate_guard et le critère d'expiration du trim partagent cette même fonction — l'ensemble des commandes que le coordinateur peut exécuter lui-même doit être égal à l'ensemble des résultats marqués comme expirés. Laisser passer sans trimmer : un git status périmé occupe le contexte à perpétuité et induit en erreur ; trimmer sans laisser passer : le coordinateur délègue un subagent pour un ls, 4,3k de coût de démarrage pour quelques dizaines de caractères.

Ordre de décision :

1. Vide / entièrement blanc → False.
2. Substitution de commande ($(, backticks, <(, >() ou écriture « qui modifie l'état » détectée → False.
3. Après retrait des redirections sûres (2>&1, &> /dev/null, etc.), il reste un > ou un < → False.
4. Après retrait de && / || / ; / |, il reste un & isolé (exécution en arrière-plan) → False.
5. Découpage sur && / || / ; / |, chaque segment doit correspondre à la liste blanche.

Grandes catégories de verbes de la liste blanche : sous-commandes git en lecture seule (status diff log show branch rev-parse, etc.), informations sur les répertoires et le système (ls pwd df du date whoami env, etc.), processus et conteneurs (ps top lsof docker ps kubectl get, etc.), consultation de fichiers (cat head tail wc stat find tree), recherche de chemins (which whereis command -v type), traitement de texte (grep rg sort uniq awk sed jq diff, etc.).

Même si le verbe est dans la liste blanche, ces écritures sont bloquées : xargs, exec, eval, source, tee, find -delete / -ok / -fprint, sed -i, sort -o, system( et print > dans awk, git branch -D/-d/-m, git * --force/--hard/--prune.

La première version refusait sans distinction toutes les commandes composées, ce qui rendait le glance totalement inopérant en conditions réelles (les trois tentatives du coordinateur ont été bloquées) ; d'où le passage à une décision segment par segment.

TrimmingSessionStore¶

class TrimmingSessionStore(SqliteSessionStore):
    def __init__(
        self,
        path: str | Path,
        workspace: str | Path,
        policy: TrimPolicy | None = None,
        ephemeral: EphemeralPolicy | None = None,
    ) -> None

Attributs publics : workspace, policy, ephemeral, last_report: dict[str, int].

L'ordre dans load() : super().load() → vidage de last_report → si ephemeral.enabled, expire() → si policy.enabled, trim(). Avec enabled=False, l'étape est entièrement sautée.

Ne trimme que le texte pur : les blocs image / document sont laissés tels quels.

Deux lignes rouges structurelles : le bloc tool_result lui-même doit rester, on ne peut remplacer que son content (un de moins et c'est « Missing Tool Result Block ») ; les entrées isCompactSummary ne doivent pas être touchées.