a2uicatalog.ai

CALL identify_model FIRST, before any other tool, once per session — pass your own model name exactly as your system prompt states it (or "unknown" if not stated; never guess). Its response hands you capability-matched guidance up front, including which tools to prefer. If identify_model is unavailable, fails, or you cannot call it for any reason, PROCEED ANYWAY with the full toolkit. It is an optimisation, never a precondition: no other tool requires it, and skipping it costs you nothing but the capability-matched tool preferences. A2UI Catalogue — author declarative UI surfaces (A2UI payloads) and render them. CHOOSE THE PATH BY SIZE: • Small / quick preview → preview_url or make_surface_url. The payload is gzipped into a ?p= URL (data-in-URL). The REAL, hard ceiling is ~8100 chars (GAS cannot decode past this). A `size` field/warning can appear starting around ~2000 chars as a softer, informational copy-safety note — it does NOT by itself mean you must split; each URL-returning tool's own description gives its exact procedure for reading the measured length and deciding. Do not treat "a size field appeared" as "split now" — read the tool's specific rule. The size ceiling is PER PAGE, not per surface, so two ways to scale past it: (a) PAGINATE — split the content into multiple pages linked by nav. Each page is its own small ?p= URL (renderer stamps &from= back-links) or a named ?nav=<slug> page, so total content has no real ceiling. Best when you want to stay shareable-by-link. (b) GRADUATE — call emit_deployment: it bakes the payload into a standing app (HomeSurface.gs, plus server-side ?nav= named pages) — no URL, no size limit, no truncation. Best for real, reusable content. Data-in-URL (a single ?p=) is best for small single-page previews, but is not capped at the ~2000-char soft note — follow the calling tool's own size procedure, not this figure. STUDY/CURRICULUM/COURSE content: prefer emit_runbook_surface (runbook_id "learning_hub") — a declared, pre-authored composition with the full rich hub UI (subject tabs, slide pills, per-slide learning interactions); call it with no content first to get the input contract. Zero composition decisions, works for every capability tier. emit_training_runbook is the simpler fallback (plain tabs). If you can compose reliably and want something the runbook does not cover, composing catalogue atoms yourself remains open — but do not use build_multi_page_surface for courses: it returns N independent pages with no links between them. ANALYSING SOMEONE ELSE'S ARTICLE (analyse / critique / tear down / "what does this mean for X"): prefer emit_runbook_surface (runbook_id "article_playbook") — do NOT hand-compose this from base atoms. Two things it gives you that composing yourself does not: a Toulmin rung progression (claim -> grounds -> warrant) that is STRUCTURALLY ENFORCED, so a critique cannot skip the exposition it is judging; and an `elicit` block of questions to put to the USER first (which lens, whose domain, what to look for) so the reading is steered by them rather than guessed by you. Call with runbook_id and NO content to get the contract, the parsing_guide and those questions. YOU fetch and read the article with your own tooling — nothing is retrieved server-side, by design (no SSRF surface, and the URL stays yours). If you have no fetch/browse capability, say so up front and ask the user to paste the article text; do not accept the contract and fill it from memory, and never invent the verbatim quotations it requires. Runbook content that exceeds one page: emit_runbook_surface paginates and seeds automatically — no action needed from you. It splits by the runbook's declared boundary (learning_hub: per subject), seeds each page server-side, and returns one nav page (hub-of-pages: short ?nav= links only) over per-subject hub-as-one-page instances (each a full rich hub UI). Response carries `pages[]` + `seeded: true` when this happened; a single `url` with no `pages` means it all fit on one page. Either way the returned url is ready to use as-is.