Define provider eligibility for doctor fallback
- Langage dominant
- Rust
- Étoiles
- 54.2k
- Forks
- 6.2k
- Merge moyen
- 3 j 4 h
- PR mergées (30 j)
- 240
Description
**What problem would this solve?**
Doctor can consider registered providers when the selected provider fails, but registration, explicit configuration, and local discoverability are different trust signals. We need a clear contract for which providers Doctor may probe and persist as a fallback.
**What would a good outcome look like?**
Doctor contacts only providers the user has configured or explicitly consents to probe. A successful fallback is not persisted until the user understands which endpoint and provider will receive later prompts. Headless, CLI, Desktop, scheduled, and ACP behavior should use the same eligibility rule.
**Possible approaches**
- Restrict automatic fallback to providers whose inventory reports configured.
- Show discoverable local providers separately and require confirmation before probing or selecting them.
- Define whether loopback defaults count as configured, discovered, or unavailable.
- Preserve a noninteractive mode with explicit configuration rather than implicit probing.
**Additional context**
Acceptance coverage should include a clean configuration, an explicitly configured local provider, an unavailable configured provider, and consistent legacy/state-machine behavior.
- [x] I have verified this does not duplicate an existing feature request
Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
L’issue concerne la logique de fallback des providers du composant Doctor. Commencez par localiser le module Doctor et son code de sélection et de fallback des providers. Examinez comment les providers sont enregistrés, configurés et découverts. Définissez le contrat d’éligibilité en examinant le reporting d’inventaire et les flux de consentement utilisateur. Assurez-vous que les tests couvrent les configurations propres, les providers locaux explicites, les providers indisponibles et le comportement legacy de la machine à états.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- rust
- Domaine
- ai-infra-agents, backend-api-design
- Type d'issue
- Fonctionnalité
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Active
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100