hub: Bring your own agent, Mitglieder erstellen Joins für eigene Agenten (§3.1, §6.1, #470)
tsk-ma408933n5qd done Maity Coder Claude 006 (maity-coder-claude-006)
Vertrag #470 (gemergt): docs/api.md §3.1 "Bringing your own agent", §6.1 policy.member_agents und member_agents_max, 403-Gründe member_join_limit und member_agents_max. Entscheidung in context/members.md (cef4255e). Oliver wartet darauf, sein Freund will drei Agenten mitbringen. Opus-Niveau, weil es um Rechte geht.
- POST/GET/DELETE joins: Ein Mensch mit Trust member (nicht guest, kein Agent) darf das, wenn policy.member_agents on ist. GET und DELETE nur für die eigenen Joins.
- Grenzen exakt wie im Vertrag: eigenes oder neues Profil, Trust member oder guest, die vier Rollen, reports_to = Caller, keine Areas und Capabilities. new_instance/replaces nur, wenn die Mitgliedschaft jetzt innerhalb der Grenzen liegt.
- Zählung: eigene Profile mit aktiver Mitgliedschaft oder offenem Erst-Join, jedes einmal. Zählung und Insert unter dem Projekt-Lock.
- Exchange (§3.3) prüft unter dem Lock erneut den Creator, die Grenzen des Ziels und die Zählung. Bei Fehlschlag ist der Join ungültig, Antwort not_found. Ein beförderter Creator behält den Join, bei off bleiben offene Joins gültig.
- Policy-Felder: Migration mit Default on und 3, PATCH nur project:admin, member_agents mit reason.
Tests: jede Grenze, Eskalationsversuche (Trust admin, Rolle ops/proxy, fremdes Profil, new_instance auf einen beförderten Agenten), Ersatz bei vollem Limit, zwei gleichzeitige Joins um den letzten Platz, Entfernen oder Herabstufen des Creators vor dem Exchange, off mit offenem Join, guest und Agent verweigert. sqlite, PostgreSQL und MariaDB. Migration: Nummer beim Merge auf den main-Kopf setzen, ich nenne sie.