Widget catalogue

Pipelines

Inferred, then overridden.

A pipeline does not name a widget. It declares a semantic type, and the host infers the widget. This is normative: every host of .hutash manifests should produce equivalent default widgets for the same semantic types.

Non-graphical consumers — a CLI, a tool surface, an API client — ignore this table entirely and use only the semantic type and its properties to validate input.

Any control may carry an optional ui: {widget: <name>} block that overrides the inference. The block is advisory: deleting it from any manifest must not change the correctness of any invocation, only its presentation. An unrecognised widget name is ignored and the control falls back to its inferred default, so a manifest authored for a future host still renders on an older one — less precisely, but correctly.

Widgets that need an explicit override

Ten registered names are the inference table's own outputs and need no override: slider, number_input, pills, select, tag_select, textarea, text_input, toggle, dropzone, multi_dropzone. Seven more must be asked for.

How a control maps outward

Mechanical and complete — a tool surface can be generated from any manifest with no human step.

Pipeline types

These describe what flows into and out of a model, which is what makes chaining possible without hardcoding model-to-model connections. They appear only in inputs: and outputs:, never in controls:.

New pipeline types may be added; a consumer meeting an unknown one must treat it as opaque pass-through data rather than failing. New control types may not be added without a spec version bump — the five are a closed set, and anything that appears to need a sixth is a string or an enum with a widget override.

Applications

The vertical catalogue.

Twenty-nine widgets. A vertical composes its whole interface by naming them in vertical.yaml; it writes no interface code. Every prop listed is one a widget actually reads — a prop not listed is ignored.

"Context" is what a widget reads without being told: workflow (the form values and run state), media (playback position and the segment list), navigation (the current page), autosave (the open project's save state). A page carrying any media widget gets the media context automatically; autosave requires an open project.

The control vocabulary

Not preferences. Pick by the shape of the choice, not by taste, so the same question looks the same in every application.

action_button variants: primary — the one thing this page is for, at most one per view; secondary — a real alternative to it; ghost — tertiary, present but not competing; danger — destructive and hard to undo. A page with two primary buttons has told the user nothing about which one to press.

Inputs

Input widgets.

Every input widget takes bind: — the workflow input it fills. Widgets seed what they display: a select shows its first option whether or not the form holds a value, so every choice widget writes its displayed value into the form on mount, and never overwrites a user's choice.

Why describe_by and filter_by exist. "Hindi" says everything and "Fenrir" says nothing, so describe_by appends option fields after the label, em-dash separated, in the order given, skipping a field an option does not carry rather than leaving a dangling comma. filter_by exists because two questions' answers are not always independent: a voice selects the phonemizer, so an English voice given Hindi text returns a well-formed audio file of a fluent-sounding voice saying no words — the run succeeds, nothing warns, and only a listener can tell. Two deliberate tolerances: an option that does not declare the filter field is kept rather than hidden, so a manifest predating the field does not vanish from the picker; and a held value the filter no longer offers is replaced with one it does, because leaving it produces a form that looks correctly filled in while the run receives something the user never saw.

Media

Media widgets.

These share one media context — playback position and the segment list — which is what lets a player, a transcript and a waveform cooperate without knowing about each other. The page's YAML decides which are present.

The caption overlay is the style preview. Choosing a style swaps a class on the overlay and nothing else happens: same words, same frame, same moment, different look, instantly. Nothing is wired between the picker and the player — the style id travels in the media context. It resolves in falling order of authority: the live choice in context, then the bound workflow input named by style_input, then subtitle_style. The input matters because the picker usually lives in a tab and only the active tab is rendered, so reading the input directly is what puts yesterday's style on the captions at first paint.

Six styles are drawn: bold_pop, word_center (one word at a time), karaoke (whole line, spoken word lit), two_line, minimal, classic. An unknown id falls back to classic rather than vanishing, and a word-by-word style falls back to the whole line when the segments carry no word timings. These are approximations of what the encoder bakes in — sizes and positions are proportional to the same 1920×1080 reference the export is authored against, so the preview answers "is this the look I want" honestly; the export is the artefact, rendered once, on the style the user settled on.

An entry in sources naming an output is fetched from the run through the client (bearer token in a header, never a query string) and played from an object URL; an entry without one is the uploaded file. The player owns this list and publishes it, so a source_switcher in a side panel needs no copy of it. A named cut that cannot be fetched says so where the picture would be — it does not fall back to the original, because showing someone the source video and calling it the dub is worse than showing them nothing.

A vertical may own its own save format. The catalogue's write path takes text: a widget encodes its content and the project stores the bytes. That is right for SRT and wrong for anything that has to be generated, so save_endpoint hands the route the segments themselves — words intact — plus the style, the platform, and the SRT the widget encoded. {project_id} in the path is substituted. working_path names the file to read back, tried before save_path: SRT can say only when a cue starts and ends, so a project reopened from one lost its per-word timings and its style, and every animated style collapsed to one static cue per line. With neither prop the widget saves text to save_path exactly as before, and a missing, unparseable or foreign working file falls back to it — which is what opens every project made before the format existed.

Cues in the list are drawn in the chosen caption style, because a caption style is a property of the subtitles rather than of the player showing them — the look only (weight, letter case, the plate behind classic), not the size and not the outline, both of which need a 16:9 frame with a picture behind them. The row being edited is never styled. follow_playback never scrolls while a row is being edited.

draggable defaults false on audio_player and true on waveform_timeline, and that is the difference between them: retiming a cue is a subtitle-editing gesture, so place waveform_timeline directly when editing timing is the point, and audio_player when playing is. Similarly output_player is deliberately not a flag on audio_player: that widget owns the single audio element attached to the media context so the transport, the waveform and the subtitle list read one clock, and a generated voice-over is a different recording on a different clock. The absence of the shared clock is what output_player is for.

Hanu reads its context. The open project comes from the workflow inputs, the transcript size from the media context, the current page from the navigation context. A widget that had to be told what the user was doing would be told wrongly the first time a page was added, and a model grounded in the wrong project answers fluently and incorrectly with nothing on screen to contradict it. The system prompt is built on the backend, where the list of this app's workflows already exists. When the model names a workflow the app really has, the reply renders a button that starts it through the same run path every other control uses; a named workflow the app does not have is dropped server-side rather than rendered, because a button that cannot work looks like a feature. Memory-less: each turn is sent alone, and a failed turn is reported beside the transcript rather than inside it, because the model did not say it.

Display and layout

Structure widgets.

Reach for tabbed_panel instead of one overlay per panel when the panels are about the thing on screen: an overlay covers its own subject, and a caption style you cannot see against the video while you pick it is a style you pick twice. An overlay is still right for a panel that is not about the page underneath it — Settings and Models are the same wherever you opened them from. If you add a tab whose state must outlive a switch, lift that state to the page rather than making the panel persist.

Page-scale

Whole-page widgets.

Set create_button: false when a section_header already offers "New Project" — two controls with the same label is duplication. On a model card, six fields are read from the models endpoint: compatibility (a dot when compatible, a pill when degraded or incompatible), compatibility_note (its tooltip — the reason, "Needs 8GB, your GPU has 3.6GB usable"), hardware (what the catalogue says the model needs), license, size_mb (absent when unknown), and rating (a score out of 10, rendering nothing when there is no score, because a dash is a fact the app does not have dressed as one it does). hardware and compatibility are both shown on purpose: one is a claim about the model, the other a verdict about this machine, and either alone leaves the user unable to tell an unsupported model from an unsupported computer.

Actions

Action widgets.

What an export writes. It exports what is on screen — the edited segments, not the raw run output — for the output those segments are. The chosen format's own output decides first, then the panel's output, then the workflow's primary: output, then the first produced. The edits reach only a subtitle-editor output or one whose value is already timed text: handing them to every output wrote Podcast's transcript into a file named after its show notes, and left the notes unexportable.

One action, and it writes to disk. An export lands in the open project's folder; nothing is handed to a browser to drop in a downloads folder, separated from the project it belongs to. The button says what it does — Save for a text format, Render video for mp4, which is minutes of encoding and does not pretend to be instant. Neither says "download"; the word survives in the catalogue only where something really is fetched over a network, which is a model download. Afterwards the panel says where the file went and offers Open file and Open folder, which go through a backend endpoint because a vertical's interface has no route to the desktop shell.

A format carrying output names what it carries. When that output is a file the run already produced, it is kept as it stands; when it is text, that text is what gets serialized — which is what lets one panel offer every deliverable of a run instead of only the transcript. With a style chosen, the video render is animated: the style, the platform and the word-level segments go with the request and the backend builds a styled caption document from them, with the SRT riding along so a backend that does not recognise the style falls back to a plain burn-in. styled_format then leads the list and starts selected — reordered, not filtered, and followed only once, so someone who deliberately switched back does not have the choice taken away again.

Next

Keep going.

• Format referenceEvery file and every field, as the engine reads them.
• WalkthroughPackage a model from scratch, install it, and run it.