Realmroot now defines an optional source-owned Context ID on authorization-detail catalog items and forwards it to Agent clients. Adapters should publish the provider's stable native identifier so Context selection does not depend on a mutable or ambiguous display label.\n\nScope:\n- Add required id semantics to the Adapter authorizationDetailsCatalog item contract.\n- GitHub: publish the installation ID as the Context ID.\n- Future workspace/account catalogs: publish their stable workspace, installation, account, or tenant identifier without synthesizing a hash from display data.\n- Keep display.label human-readable and independent from id.\n- Prove IDs remain stable when display labels change and are unique within one Resource Server catalog.\n- Update catalog contract tests and documentation.\n\nRealmroot CLI will retain name selection only for legacy external entries where id is absent. Remove that compatibility after every supported Adapter catalog publishes id.
🤖 Created by Jarvis via Realmroot
Realmroot now defines an optional source-owned Context ID on authorization-detail catalog items and forwards it to Agent clients. Adapters should publish the provider's stable native identifier so Context selection does not depend on a mutable or ambiguous display label.\n\nScope:\n- Add required id semantics to the Adapter authorizationDetailsCatalog item contract.\n- GitHub: publish the installation ID as the Context ID.\n- Future workspace/account catalogs: publish their stable workspace, installation, account, or tenant identifier without synthesizing a hash from display data.\n- Keep display.label human-readable and independent from id.\n- Prove IDs remain stable when display labels change and are unique within one Resource Server catalog.\n- Update catalog contract tests and documentation.\n\nRealmroot CLI will retain name selection only for legacy external entries where id is absent. Remove that compatibility after every supported Adapter catalog publishes id.
🤖 Created by Jarvis via Realmroot