Let agents discover and message channels on peer hosts
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 42/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- typescript
- Domaine
- distributed-systems
Piste de recherche
Start from the native channels/message tools and the local catalog they read, then compare with how human channel routing already reaches peer hosts through the injected delivery boundary. Read the related issues #10, #11, #13, #15 and the review evidence comment on #5 to understand the policy and boundary constraints before designing. Done means peer channels are discoverable with stable identity, messages deliver idempotently across two hosts with clear offline/reconnect outcomes, and the verification scenario (duplicate delivery, reconnect, renamed target) passes on real channels.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Human channel routing reaches peer hosts, but the native channels/message tools currently use the local catalog. #13 covers hosted-channel messaging; #11 and #15 cover different boundaries.
Acceptance
- Discover reachable peer channels with stable identity and enough project/host context to select the intended destination.
- Deliver attributed messages and optional agent invocations through the existing tailnet and collaborator-agent policy; expose a supported reply path.
- Preserve destination-host execution, idempotent delivery, and clear offline/reconnect outcomes.
- Verify with real channels/models on two hosts, including duplicate delivery/reconnect and a target whose name changes.
- Keep agents in different channels as messaging peers, not parent/child owners.
This is an extension beyond #10's baseline human collaboration check. Preserve the runtime-neutral channel and injected delivery boundary.
Related: #10, #11, #13, #15. Review evidence.
Tracked by #58.
- Langage dominant
- TypeScript
- Étoiles
- 1
- Forks
- 0
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Aucun guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de githubnext/ace2
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 94/100
githubnext/ace2#487 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
githubnext/ace2#486 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
githubnext/ace2#459 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
githubnext/ace2#437 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
githubnext/ace2#442 ·
Toutes les issues de githubnext/ace2
Issues similaires
-
bug priority: P2
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
wayfinder:task
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 1 jour
-
bug customer-reported data-plane question Service Attention Storage
Difficulté 2/5 1-3 heures Accessibilité débutants 69/100
Azure/azure-rest-api-specs#47397 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Claude thinking budget can shrink capped Haiku responses to 2,048 tokensPeut-être pris @DavyMassoneto l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
diegosouzapw/OmniRoute#17109 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
paperclipai/paperclip#16785 ·
Les mainteneurs répondent en général sous 1 jour