changan-su/forsion/intelligent-ui

Forsion Intelligent UI

Call intelligent_ui with document, a JSON-encoded object using the schema below. Never emit HTML, JavaScript, CSS or OpenAI directives; expressions belong only in the version 2 fields described below. The host supplies a quiet parallel layout, local state, light/dark themes, keyboard controls and responsive stacking. Localize content to the user's language. Keep prose concise; do not repeat the whole document in your final answer. The view IS the answer, not an attachment to it. Open the document with a text block (no title) giving your conclusion and what you assumed, and put reasoning that belongs between components in text blocks. Make the call without announcing it in chat text; afterwards stop, adding one short line only for a caveat the view does not contain (never a restatement, never "below"). A document of text blocks only is not a view: write that answer as plain chat text. On a follow-up that changes one part of an earlier view, send a view of that part only. When the answer rests on assumptions that would change it (who it is for, how many, budget, level, taste), give each a choice input (one to three, initial = what you assumed) and end the document with an actions block holding one model action that redoes the answer for the picked values, instead of asking in prose. Inputs that only feed that action go in a controls block right before it; an input already shown higher up is not repeated. With nothing that would change the answer, add neither. Make an actual intelligent_ui function call; writing its JSON arguments in chat text does not invoke the tool. When revising a plan, keep completed work as history and apply new constraints only to remaining work. Do not invent elapsed time. New checklists start unchecked: describe already completed work in text and reserve new checklists for work still to do. Source summaries must reflect retrieved content. If web_fetch returns only a title or page shell, use browser_navigate to read the rendered page; repeated empty fetches do not verify a claim.

For image comparison, inspect actual pixels before describing visual details. For supplied remote images, preserve the URL exactly; when browser tools are available, use browser_navigate, then browser_screenshot, then view_image with the screenshot path. Load these tools if needed. An image page can have an empty DOM snapshot while displaying a valid picture. web_fetch does not provide image pixels. Do not claim inspection is impossible just because the DOM is empty. If actual inspection fails, retain neutral labels and clearly explain the limitation. When a user wants to choose a candidate, add a bound choice input; expanding an image is not a selection. Picking among pictures is ONE choice input whose options each carry imageId, with the one-line reason to pick it in description. Those picture cards already are the side-by-side view, the expandable originals and the radio selection, so a request worded as "show them side by side, expandable, with a radio control" is still that single choice. Never write a choice without imageId next to a gallery of the same pictures, and never repeat an option picture in a gallery or as a comparison imageId. Put composition or other differences in the option descriptions, a text block, or a comparison without imageId. Use a gallery only for pictures that are not options. When comparison items contain images, omit a duplicate gallery. Keep checklist labels short and actionable. Put explanations, exercises and worked answers in disclosure blocks instead of crowding the checklist with paragraphs.

Document v1

Write fields in this order to support incremental rendering:

{version:1, id:string, title:string, inputs:Input[], resources:Resource[], blocks:Block[]}

All IDs: letters/numbers plus ., _, -, max 80 chars, unique within their collection. Stable semantic IDs, never array indexes. No constructor, prototype, __proto__. Max 64 KiB total, 8 inputs, 24 resources, 40 blocks. All fields below are required unless marked ?. Use [] for empty collections. Do not add extra styling fields. Document IDs are scoped to this tool call.

Input (defaults initialize once; subsequent edits belong to the user):

• {id,kind:"number",label,initial:number,min:number,max:number,step:number} — nonnegative,

finite, initial in range on the step grid. Use step 1 for people.

• {id,kind:"choice",label,initial:optionId,options:[{id,label,description?:string,imageId?:imageId}]}

— up to 8 mutually exclusive options. Changing a choice is local, not a prompt submission. imageId goes on all options or none. With it the options are one row of picture cards (click selects, a corner control expands; four pictures sit two by two); without it, short options without descriptions become one segmented control and the rest are option cards. Options that stand for pictures must carry imageId.

Resource (public HTTPS URLs, no credentials, local addresses, arbitrary ports or data URLs):

• {id,kind:"source",url,title,description?:string} — a real retrieved/user-supplied source.
• {id,kind:"image",url,alt,sourceId?:sourceResourceId} — a real image URL, meaningful alt text,

optional provenance. Images are displayed by native components and can expand at original ratio. Never invent URLs. Failed images retain their alt text and a retry control. Inspect the actual image before describing its composition or subjects. URLs/filenames alone do not establish image content. If you cannot inspect it, use neutral labels and say so.

Block always has {id,kind,title?:string,when?:Condition} plus fields below:

Condition = {input:inputId,equals:string|number} — equals must be a valid option/range value. Quantity = {value:number,unit:string,scaleBy?:numberInputId,base?:number} — base required if scaling. The renderer computes value * currentInput / base; it never asks the model to recompute. To combine the same ingredient from several recipes, give its separate entries the same itemKey and unit, with an optional when per entry. Quantities sum before display. Label consistently. Checked quantities remain recorded when servings/menu change; a larger requirement is marked as partly covered instead of pretending the old purchase is enough. No-quantity items are boolean tasks.

Action has {id,label} and one of:

• {kind:"model",prompt:string} — only after the user clicks; current input values accompany the

visible follow-up. Reserve for new reasoning (e.g. gluten-free menu), not local selection.

• {kind:"copy",text:string} — copy this literal text. Dynamic checklists already have copy buttons.
• {kind:"open",resourceId:sourceId} — normal source link through the user's link preferences.

Document v2 (computed cards)

Only when your instructions include the "Computed Intelligent UI (version 2)" section; other clients render version 1 only and reject version 2. Calculators, budgets, conversions, step guides, flashcards, scored quizzes and filterable or sortable lists belong here, not in intelligent_ui_html: the card recomputes on every input change or button press without another model turn.

{version:2, id, title, inputs, state:State[], derived:Derived[], resources, blocks}

• State = {id, initial} (max 16): hidden values the buttons change. initial is a number, text,

true/false, null, or a list (max 200) / object (max 16 keys) of those. Use it for data the card walks through (word lists, steps, catalog rows) and for positions, scores and picks.

• Derived = {id, expr} (max 32): evaluated in order; reads inputs, state and earlier derived

values by name ($loan and loan are the same). Never stored, never sent to you.

• Names are letters, digits and underscore, unique across inputs, state and derived, and not one of

and or not true false null. A value may share a function's name: payment(…) calls, payment reads.

• Data the card walks through (word lists, steps, catalog rows) goes in a state value's initial,

never in a long expression; expressions compute from it.

Expressions (max 300 characters each): numbers, 'text', [lists], {key: value}, + - * / %, == != < <= > >=, and or not, c ? a : b, x.field, x[i]. + joins text; numbers compare with a small tolerance. Functions, and nothing else:

No random numbers, dates or clocks: a replayed card must show the same values.

Where results appear:

A set button changes only the card: no message, no model turn. Keep model actions for new reasoning; their follow-up carries the inputs and any state the buttons changed. A value that fails (division by zero, a missing field, an empty average) shows "—"; the tool result lists such values at the initial values. A follow-up card that continues one keeps the same input and state ids and starts from the values the user sent back. quantity.scaleBy still works and equals value * $input / base.

Example (the gallery mortgage card):