configs/ - profils de contexte optionnels

Ces fichiers JSON sont des profils de contexte optionnels, sans réponses préétablies. Ce ne sont pas des modes du produit Flounder et ils ne sont pas chargés par défaut. Ils existent pour les cas où un opérateur souhaite délibérément donner au modèle un cadre familier pour une classe de cible.

Chacun est un échafaudage projectContext pour cette classe : le type d'actifs, les capacités de l'attaquant, les limites de confiance, les invariants et les domaines d'attention qu'une pile connue a tendance à avoir. Le modèle garde la maîtrise de la stratégie d'audit et le framework exige toujours une preuve d'exécution.

Non utilisé par défaut — et c'est délibéré

Le framework ne les charge jamais de lui-même. Un flounder run / flounder map / flounder audit par défaut ne contient aucune connaissance préétablie de bugs : l'exécution est aveugle et ancrée dans l'exécution, donc le modèle doit énumérer la surface d'attaque à partir de la source réelle avant qu'un essai d'audit puisse trouver quoi que ce soit. Donner au modèle une liste préécrite des endroits où les bugs vivent habituellement le biaise vers les zones listées et l'éloigne de celles qui ne le sont pas, et risque de transformer l'audit en simple vérification de checklist plutôt qu'en lecture. C'est l'inverse de la façon dont cet outil est destiné à trouver des bugs inédits, donc les profils restent désactivés sauf si vous les demandez.

Ils existent pour les cas où ce compromis en vaut la peine : une classe de vulnérabilité bien connue où l'amorçage de la surface commune est réellement utile, un budget plafonné qui a besoin d'une longueur d'avance sur la focalisation / l'exclusion du périmètre, ou un cadrage rapide du périmètre pour une pile familière. Les profils Solidity/EVM et ZK sont des exemples courants à fort signal. Dans ces situations, activez-les :

flounder run --config ./configs/solidity-contract-audit.default.json \
        --target my-protocol --source ./contracts --corpus ./docs

Ce qu'un profil change réellement

--config <file> fusionne dans la configuration d'exécution (applyConfigOverrides), puis les drapeaux de ligne de commande la remplacent — donc --target / --source / --corpus / --max-steps que vous passez en CLI l'emportent sur le fichier. Depuis projectContext, seuls summary, focusAreas et outOfScope atteignent actuellement le modèle (intégrés dans sa note de périmètre). Les champs plus riches ci-dessous sont de la documentation / de l'échafaudage aujourd'hui — ils enregistrent le modèle de menace pour un auteur humain mais ne sont pas encore injectés dans le prompt.

{
  "targetName": "…",
  "sourcePaths": [],          // usually left empty; pass the real target via --source
  "corpusPaths": [],          // usually left empty; pass the project's own docs via --corpus
  "thinkingLevel": "xhigh",
  "projectContext": {
    "summary": "…",            // ── injected into the model's scope note
    "focusAreas": ["…"],       // ── injected
    "outOfScope": ["…"],       // ── injected
    "criticalAssets": ["…"],         // scaffold only (declared, not yet prompted)
    "attackerCapabilities": ["…"],   // scaffold only
    "trustBoundaries": ["…"],        // scaffold only
    "securityInvariants": ["…"],     // scaffold only
    "scenarioGuidance": ["…"]        // scaffold only
  }
}

Laissez sourcePaths / corpusPaths vides dans le profil et passez la cible réelle et les spécifications / documentations propres au projet en ligne de commande. Un profil est un cadre, pas un substitut au matériel réel de la cible.

La limite qu'un profil ne doit pas franchir

Un profil est du contexte, jamais un verdict. Il peut dire au modèle où regarder ; il ne peut pas dire au modèle ce qu'il trouvera. La confirmation ne vient toujours que de l'exécution — une découverte est réelle parce qu'une preuve de concept (PoC) a été exécutée, jamais parce qu'elle correspondait à un profil. (Le scenarioGuidance des profils le dit carrément : « N'écrivez pas de règles de bugs statiques qui prétendent établir des découvertes. »)

Étendre ce répertoire

C'est l'emplacement optionnel des packs de contexte par domaine. Pour en ajouter un, restez générique par rapport à une classe et sans réponses préétablies : capturez la surface d'attaque et les invariants qu'une classe a tendance à avoir, jamais un bug connu spécifique dans une cible spécifique. Tout ce qui est spécifique à une cible appartient au --corpus de cet audit, pas ici.