wehub-resource-sync
09e9f3545f
3.7 KiB
otmP3b (GeneratePromptSuggestions) mode → surface map
Evidence record for the suggest_prompts mode enum (field-4 C0 of the
SUGGEST_PROMPTS / otmP3b request). Backs the MCP suggest_prompts tool's
surface labels and the client cap (_notebook_payloads._PROMPT_SUGGESTIONS_MODE_MAX = 10).
Investigated live 2026-07-01 (#1726); supersedes the earlier output-only #1612 guess.
Map
| mode | surface · format | how established |
|---|---|---|
| 1 | Audio · Deep Dive | browser-verified — opened the Audio Overview Customize dialog headless (Playwright + stored storage_state auth), clicked the "Deep Dive" format card, decoded the otmP3b request's trailing mode |
| 2 | Audio · Brief | browser-verified (Brief card) |
| 3 | Video · Explainer | real web capture — otmP3b request while customizing a Video Explainer |
| 4 | Chat · ask (default) | client live-probe — returns "ask about the content" chat questions; the web chat default |
| 5 | Audio · Critique | browser-verified (Critique card) |
| 6 | Audio · Debate | browser-verified (Debate card); output = debate scaffolding |
| 7 | — unidentified | no UI surface sends it; excluded from the tool |
| 8 | Quiz | client live-probe — returns quiz-generation prompts |
| 9 | Flashcards | client live-probe — returns flashcard prompts |
| 10 | Video · Short | real web capture — controlled pair (same notebook + source, mode 3 vs 10) |
| 0, 11+ | INTERNAL (server error) | out of range |
Two axes (why the labels are honest)
There are two different measurements, and they are consistent, not contradictory:
- Surface axis (#1726): which mode a studio Customize dialog SENDS for its
format's suggestions. This is request-side wiring — the
otmP3bmode the UI emits per format. It's how the labels are assigned (a card labeled "Deep Dive" sends mode 1, so mode 1 = the Audio Deep Dive suggestion surface). - Output axis (#1612, 2026-06-20 live A/B): what the backend RETURNS per mode. Modes 5/6/8/9 (critique / debate / quiz / flashcards) are format-distinctive in the returned text; modes 1/2/3/10 return content-direction prompts (persona / format / topic) that read ~like the mode-4 default.
Reconciliation: for deep-dive / brief / explainer / short, NotebookLM steers the
format via content direction, not format jargon — so those surfaces' suggestion
text is general by design, even though the surface (which mode the format's
dialog sends) is distinct and verified. The tool's surface labels therefore name
the surface (the format whose dialog sends the mode), not a promise about the
returned tone. Modes 5/6/8/9 also differ in output; 1/2/3/10 are the "same shape,
different surface" cases.
Not exposed / not supported
- Mode 7: no UI surface sends it; unmapped.
- data-table / infographic / mind map / slide deck: their Customize dialogs
exist but fire NO
otmP3b(no suggestion surface). Modes 8/9 (quiz/flashcards) are backend-reachable via this RPC but the web UI doesn't wire their dialogs to it — still valid to expose since the RPC serves them. - Report suggestions: a separate RPC (
GET_SUGGESTED_REPORTS/ciyUvf), nototmP3b.
Method (reproducible)
Headless Playwright loaded the authenticated app via the repo's storage_state
auth (browser.new_context(storage_state=…)), navigated to a notebook, and clicked
each artifact's button[aria-label="Customize {Type}"] chevron (NOT the card body —
that generates). For Audio, each format card inside the dialog was clicked while
capturing the otmP3b request post-data (f.req → trailing mode int). Video modes
came from real browser network captures (otmP3b requests). Chat/quiz/flashcards
were client live-probes of client.notebooks.suggest_prompts(mode=…).