amd/gaia

The Telegram adapter is a real remote-access surface running with near-zero coverage: src/gaia/messaging/telegram.py (310 L) implements a polling bot with per-user AgentSDK sessions, a user allowlist, streaming via message edits, and media ingest (ingest.py → VLM extraction / RAG indexing) — and it has 3 unit tests (test_telegram_adapter.py, test_telegram_background.py, test_telegram_sessions.py, roughly one test each). The allowlist is the adapter's only access control; nothing asserts that a non-allowlisted user is actually refused. Scope: Allowlist enforcement tests: allowed user gets a session; unknown user is refused and the refusal is logged (this is the security-relevant path — first priority). Session isolation: two users get distinct AgentSDK sessions; state does not bleed between them. Streaming-edit flow: response chunks update one message; terminal state is a single final message (mock the bot API and assert the outgoing call shapes, per the CLAUDE.md boundary-tes

The tool surface that lets an agent install and load skills at runtime — including the security refusal that blocks un-audited skill code — has no dedicated tests. src/gaia/agents/tools/skill_library_tools.py is 646 lines exposing 7 @tools (list_skills, search_skill_hub, install_skill, remove_skill, load_skill, unload_skill, skill_status), and a repo-wide grep for SkillLibraryToolsMixin / skill_library_tools under tests/ returns zero files. Coverage today is incidental, via test_agent_lazy_skill_prompt.py and test_skills_consume.py. The part that makes this more than a coverage checkbox: _refuse_ungated_code (~line 134) is the load-time enforcement of the skills audit gate. If a refactor breaks that refusal, an agent will happily load a skill whose bundled code never cleared the audit — and no test fails. The mixin ships in the flagship agent (GaiaAgent composes it), so this is a shipping product path, not an internal utility. Scope: tests/unit/test_skill_library_tools.py cover

The Email agent's public hub page (https://amd-gaia.ai/hub/email) states that npm is its "only supported install path" and that there is no PyPI wheel. That is not accurate — gaia hub install email also installs the same 0.6.0 build, via a third mechanism that is neither pip nor npm: it fetches a roughly 76MB stripped ELF binary sidecar into the user's GAIA agents directory. Both paths were tested and both succeeded. Correct the page to describe both supported paths, or state which is preferred and why. 🔍 Technical details Page: https://amd-gaia.ai/hub/email Quoted claim: "Ships as an npm client plus a frozen binary sidecar — npm is its only supported install path (there is no PyPI wheel)." Verified working alternative: gaia hub install email, which pulls a ~76MB stripped ELF binary sidecar into the GAIA agents directory — a third install mechanism, not pip and not npm. Both gaia hub install email and the npm path were tested; both delivered version 0.6.0.

Drift between gaia --help, subcommand --help, and the docs site. Filing as one issue because the work is uniform. Specifics connectors and telegram top-level subcommands exist in gaia --help but have no section in docs/reference/cli.mdx. connectors is required for the documented gaia email flow, so the docs chain is broken. gaia memory bootstrap flags — --system, --reset-system, --infer exist on the binary but are not documented. Likely fell through the memory-v2 merge (#606). docs/guides/telegram.mdx documents a gaia telegram --token <TOKEN> flag that the binary doesn't expose, AND labels itself a "v0.18.2 scaffold" even though the current build is 0.17.6 and gaia telegram --help already exposes real start/stop/status subcommands. Fix Add connectors and telegram sections to cli.mdx. Document the three memory bootstrap flags. Rewrite docs/guides/telegram.mdx against the actual subcommands; remove the phantom --token flag and the "v0.18.2" framing. Severity rationale P1 — affects

docs/connectors/google.mdx and docs/connectors/github.mdx describe upstream credential setup procedurally ("go into Google Cloud Console, click Credentials, click Create…") instead of linking to the upstream provider's documentation for the relevant flow. Why this matters Third-party credential UIs change. Paraphrased instructions silently rot every time Google or GitHub reorganizes their console. Upstream docs are owned by the provider and reflect the current UI. Fix For each step that references a third-party UI: Keep the GAIA-side context (what this credential is for, what scopes to grant, where to paste the result). Replace paraphrased click-through instructions with a link to the upstream provider's documentation for that flow. If screenshots are kept, date them or call out that they may drift. Apply the same pattern to any future connector page (Microsoft, Slack, etc.). Severity rationale P1 — pages are at the start of the onboarding flow for any connector-based feature, an