Developer guide

Rendered from website/html/assets/docs/api.md. Sidebar entries and section cards are parsed from the same Markdown headings.

YAAA Developer Documentation

This guide is for applet and plugin developers building local-first automation in YAAA.app. It replaces the old generated widget reference with the current capability model: AI-assisted, human-approved automation; manifest-first applets; modular editor plugins; least-privilege permissions; and the current GUI surface.

Overview and local-first model

YAAA.app is a local-first automation workspace. Applets and project work are designed to live and run on the user's machine or chosen environment by default. Cloud and provider connections are optional and should be explicit when a workflow uses external AI, licensing, updates, telemetry, storage, or network APIs.

The public developer model has four parts:

  • Applets are manifest-first automations authored in Lua, Python, or C#.
  • Plugins extend the app as authorized packages. The Code Editor, GUI Designer, and PDF Editor are modular editor plugins that appear only when installed and authorized.
  • The AI companion connects to Claude and OpenAI through authenticated provider configuration and is being built to inspect applets and editor state through app-owned controls.
  • The runtime permission model admits only the capabilities an applet requested and was granted.

Do not treat optional cloud or provider flows as always-on. A local workflow should remain understandable, reviewable, and bounded by the permissions it requested.

The AI companion

The AI companion is designed as an in-app collaborator, not an unrestricted background actor. Provider access is explicit: users connect Claude and OpenAI through OAuth or provider credentials they control, and AI requests fail closed when required credentials are missing.

The companion is being built around an app-owned control interface for applets and the three editors:

  • Applets: list installed applets, inspect identity and launch state, launch or stop applets, and dispatch applet events through the existing permission-gated path.
  • Code Editor: inspect source files, applet manifests, diagnostics, run state, and command metadata; operate through code.* commands when the app allows it.
  • GUI Designer: inspect selected widgets, model state, layout, bindings, preview state, and diagnostics; operate through gui.* commands.
  • PDF Editor: inspect page state, annotations, comments, forms, signing panels, and document status; operate through pdf.* commands.

Live all-target AI control is in active development. The product direction is app-owned commands, previews, confirmations, audit evidence, cancellation, and separate authorization for AI-initiated work. The companion is not fully autonomous for high-impact actions — you approve sensitive work before it runs.

Common editor command domains:

Area Command examples Use
Code Editor code.file.open-folder, code.file.save-all, code.run.project, code.debug.start Open applet workspaces, inspect and save entrypoints, run or debug local automation.
GUI Designer gui.file.new-component, gui.insert.container, gui.layout.form, gui.preview.live, gui.tools.lint Create components, insert widgets, apply layout, preview, and run diagnostics.
PDF Editor pdf.file.create-from-file, pdf.annot.highlight, pdf.view.comments-pane, pdf.file.export Open PDFs, add review markup, inspect comments, and export only after explicit user intent.

Applets

Applets are manifest-first packages. Every applet workspace must include applet.json and the entrypoint declared by that manifest. The launcher refuses unsupported or incomplete packages.

The current language-aware scaffold writes:

  • Lua: applet.json, main.lua, README.md
  • Python: applet.json, main.py, README.md
  • C#: applet.json, main.cs, README.md

Minimal manifest:

{
  "applet_id": "com.example.review-helper",
  "version": "0.1.0",
  "publisher_id": "pub.example",
  "language": "python",
  "entrypoint": "main.py",
  "capabilities": []
}

Starter entrypoints:

-- main.lua
handlers = {}
function handlers.hello()
  return true
end
def hello():
    return True
// main.cs
public static class Applet {
    public static bool Hello() => true;
}

Keep language and entrypoint aligned. Use reverse-DNS applet IDs and SemVer versions. Add capabilities only when the applet needs them.

Capabilities and permissions

Installed applets are sandboxed capabilities. Inspect the applet identity, publisher, requested permissions, declared entrypoint, and launch state before interacting with an applet.

The runtime admits only the capabilities requested and granted. Denied capabilities fail closed before dispatch or protected access. Depending on the launch path, a workflow may run with the admitted subset, so applet authors should keep permissions minimal and handle denied access cleanly.

Typical review checklist:

  • Does applet.json parse and point to an existing entrypoint?
  • Does the entrypoint extension match the intended language?
  • Did package verification succeed?
  • Did capability admission prune or deny a requested permission?
  • Did the user-consent gate deny a sensitive capability?
  • Did the entrypoint run and return the expected result?

Plugins

Plugins extend YAAA.app as modular packages. The Code Editor, GUI Designer, and PDF Editor are editor plugins; their launcher tiles appear only when the matching plugin is installed and authorized.

Premium plugins are distributed as sealed packages. At load time, YAAA verifies package integrity, checks authorization, and decrypts only after the required checks pass. Protected packages are encrypted with AES-256-GCM and signed with Ed25519. A tampered package, wrong user, missing entitlement, or invalid package identity is denied.

Plugin authors can require a signed entitlement for a protected app or plugin. That entitlement locks the package to the authenticated users the developer designates, so only authorized users can install, decrypt, or run it.

Keep plugin docs at this level for public developer guidance:

  • Explain the package identity and required entitlement.
  • Document the commands and state the plugin exposes to the app.
  • Keep side effects behind explicit commands and user approval.
  • Treat free packages as signed and authenticated, but not secret.
  • Treat premium packages as sealed and entitlement-gated.

Do not publish internal package steps, local toolchain commands, or from-source instructions in public website docs.

Building a GUI with the current Slint GUI API

This is the only public website section that should name Slint. The current GUI documentation is based on the exported Slint surface and the GUI Designer model used by YAAA.app today.

Exported Slint surface

The exported Slint structs are:

  • AppTile: id, title, icon, description, enabled
  • ReplLine: speaker, text

The exported Slint window components are:

  • AppWindow
  • AppletWindow
  • PluginWindow

Each exported window component inherits Window.

AppWindow is the launcher shell. Its app and launcher properties are:

  • status-text
  • theme-name
  • reduced-motion
  • current-page
  • page-count
  • apps
  • grid-cols
  • dialog-kind
  • dialog-title
  • dialog-message
  • dialog-input-text
  • toast-text

Launcher callbacks:

  • run-app(string)
  • next-page()
  • prev-page()
  • show-about()
  • show-settings()
  • show-license()
  • new-project()
  • open-project()
  • quit-requested()

Developer console properties and callback:

  • developer-mode
  • repl-open
  • repl-languages
  • repl-language
  • repl-input
  • repl-transcript
  • repl-submit()

Settings, activation, update, and about properties:

  • settings-theme
  • settings-telemetry
  • settings-dirty
  • activation-key
  • activation-stage
  • activation-message
  • update-stage
  • update-percent
  • update-detail
  • settings-open
  • update-open
  • activation-open
  • about-open
  • about-product
  • about-version
  • about-published
  • about-licensee
  • about-user-id
  • about-expiry

Settings, activation, update, and dialog callbacks:

  • settings-toggle-telemetry()
  • settings-save()
  • activation-submit(string)
  • update-check()
  • dialog-ok()
  • dialog-cancel()
  • dialog-yes()
  • dialog-no()
  • dialog-input-submit(string)
  • dialog-permission(bool, bool)
  • dialog-dismiss()

AppletWindow is the applet and editor workbench surface. Its identity properties are:

  • applet-title
  • applet-id

Code editor state fields include:

  • editor-selected-file
  • editor-script-type
  • editor-search-text
  • editor-replace-text
  • editor-search-open
  • editor-debugging
  • editor-dialog-active-id
  • editor-dialog-active-title
  • editor-unsaved-close-open
  • editor-dirty
  • editor-last-command-id
  • editor-diagnostics
  • project-tests-open

Code editor workbench layout fields include:

  • editor-workbench-side-bar-width
  • editor-workbench-panel-width
  • editor-workbench-panel-height
  • editor-toolbar-tab
  • editor-panel-tab
  • editor-tab-main-open
  • editor-tab-py-open
  • editor-tab-cs-open

GUI Designer state fields include:

  • gui-selected-widget
  • gui-selected-kind
  • gui-selected-geometry
  • gui-status
  • gui-drop-preview-visible
  • gui-preview-running
  • gui-widget-count
  • gui-history-depth
  • gui-layout-mode
  • gui-dialog-active-id
  • gui-dialog-active-title

GUI Designer workbench layout fields include:

  • vscode-sidebar-width
  • vscode-right-panel-width
  • vscode-panel-height
  • gui-toolbar-tab

PDF editor state and layout fields include:

  • pdf-pages-width
  • pdf-props-width
  • pdf-toolbar-tab
  • stamp-field-count
  • pdf-editor-active-dialog-id
  • pdf-editor-active-dialog-title
  • pdf-editor-status
  • pdf-editor-page
  • pdf-editor-annotation-count
  • pdf-editor-dirty
  • pdf-editor-unsaved-close-open

AppletWindow callbacks:

  • command-activated(string)
  • close-requested()

AppletWindow component state selectors:

  • is-text-editor
  • is-gui-editor
  • is-pdf-editor

PluginWindow exposes plugin frame state through:

  • plugin-title
  • plugin-frame
  • plugin-ready
  • plugin-status
  • plugin-scale-factor

Plugin frame callbacks:

  • request-plugin-frame(int, int, float, float)
  • plugin-pointer(string, float, float, int, bool, bool, bool, bool)
  • plugin-scroll(float, float, float, float, bool, bool, bool, bool)
  • plugin-key(bool, string, bool, bool, bool, bool)
  • plugin-close-requested()

Internal reusable Slint components present in the current file include ToolBtn, RibbonTab, DockTab, ActivityTile, IconBtn, EdgeResizeR, EdgeResizeL, EdgeResizeT, and WorkbenchRegionHeader, plus global palette Pal.

Minimal Slint snippet

This snippet uses current AppletWindow property and callback names. It shows a minimal GUI surface that reports selected state through exported properties and routes user actions through command-activated(string).

export component ReviewAppletWindow inherits AppletWindow {
    applet-title: "Review Helper";
    applet-id: "com.example.review-helper";
    gui-selected-widget: "run_button";
    gui-selected-kind: "Button";
    gui-status: "Ready";
    gui-widget-count: 2;

    VerticalLayout {
        padding: 16px;
        spacing: 12px;

        Text {
            text: root.applet-title;
            font-size: 20px;
        }

        Button {
            text: "Preview";
            clicked => {
                root.command-activated("gui.preview.live");
            }
        }
    }
}

Use command-activated(string) for app-owned commands. Do not invent direct editor callbacks. If the UI event should call Lua, Python, or C# logic, generate or bind the handler through the GUI Designer and confirm that the handler exists in the manifest-declared entrypoint.

GUI Designer model and view model

The GUI Designer works from a model tree. Core model types are:

  • GuiEditorState
  • Element
  • ElementKind
  • LayoutKind
  • Anchors
  • Geometry
  • ComponentDef
  • Asset
  • AssetKind
  • ViewState
  • LintFinding
  • Panels
  • StatusBar
  • GuiPrefs
  • StyleClipboard
  • WidgetClipboard
  • PreviewState

Current element kinds:

Window, Rectangle, Text, Button, TextInput, CheckBox, Radio, Switch, Slider, ListView, TableView, TreeView, ComboBox, DatePicker, TimePicker, ColorPicker, FilePicker, Image, Media, Shape, Splitter, StackView, Accordion, Spacer, Separator, NavMenu, Toolbar, Sidebar, Container, ComponentInstance, and Placeholder.

Current layout kinds:

  • None
  • Horizontal
  • Vertical
  • Grid
  • Form

Element fields include id, name, kind, parent, children, geometry, layout, gap, padding, grow, anchors, z order, locked state, hidden state, min/max size, style, props, bindings, handlers, and tab index.

View model types exposed by snapshot are:

  • GUIViewModel
  • TabVM
  • DocumentVM
  • CanvasVM
  • ElementVM
  • GeometryVM
  • AnchorsVM
  • ComponentVM
  • AssetVM
  • TokenVM
  • SelectionVM
  • PanelsVM
  • LintVM
  • ViewVM
  • PreviewVM
  • PaletteVM
  • CommandVM
  • StatusVM

GUI command families

The GUI Designer exposes app-owned commands for file/session work, insertion, edit/selection, layout, properties, data and bindings, components, assets, tokens, preview, view tools, diagnostics, preferences, and the command palette.

File and session commands:

  • gui.file.new-component
  • gui.file.open-recent
  • gui.file.restore-session
  • gui.file.autosave-backup
  • gui.file.save
  • gui.file.save-as
  • gui.file.save-all
  • gui.file.export-slint
  • gui.file.export-code-stubs
  • gui.file.export-screenshot
  • gui.file.root-properties

Insert families:

  • Lists, tables, trees, navigation menus, toolbars, and sidebars
  • Containers, text, placeholders, separators, and spacers
  • Radio buttons, toggles, checkboxes, date pickers, time pickers, color pickers, file pickers, and sliders
  • Images, media, shapes, rectangles, paths, vectors, and canvases
  • Splitters, stacks, and accordions
  • Custom components, promote actions, palette search, palette favorites, palette recents, and template forms

Edit and selection commands:

  • gui.edit.cut
  • gui.edit.copy
  • gui.edit.paste
  • gui.edit.duplicate
  • gui.edit.delete
  • gui.edit.rename
  • gui.edit.find-widget
  • gui.edit.select-parent
  • gui.edit.select-children
  • gui.edit.select-same-type
  • gui.edit.group
  • gui.edit.ungroup
  • gui.edit.lock
  • gui.edit.hide
  • gui.edit.copy-style
  • gui.edit.paste-style
  • gui.edit.bulk-replace-text
  • gui.edit.undo-history

Layout commands:

  • gui.layout.auto
  • gui.layout.horizontal
  • gui.layout.vertical
  • gui.layout.grid
  • gui.layout.form
  • gui.layout.wrap
  • gui.layout.unwrap
  • gui.layout.break
  • gui.layout.set-anchors
  • gui.layout.fill
  • gui.layout.fixed-size
  • gui.layout.min-max-size
  • gui.layout.padding
  • gui.layout.gap
  • gui.layout.align-left
  • gui.layout.align-top
  • gui.layout.align-right
  • gui.layout.align-bottom
  • gui.layout.align-center-x
  • gui.layout.align-center-y
  • gui.layout.distribute
  • gui.layout.distribute-vertical
  • gui.layout.match-size
  • gui.layout.bring-front
  • gui.layout.bring-forward
  • gui.layout.send-back
  • gui.layout.send-backward
  • gui.layout.tab-order

Properties commands:

  • gui.props.common
  • gui.props.set-geometry
  • gui.props.layout-constraints
  • gui.props.typography
  • gui.props.color
  • gui.props.fill-color
  • gui.props.stroke-color
  • gui.props.text-color
  • gui.props.border-radius
  • gui.props.effects
  • gui.props.states
  • gui.props.variant
  • gui.props.theme-token
  • gui.props.accessibility
  • gui.props.i18n
  • gui.props.reset
  • gui.props.multi-edit
  • gui.props.search

Data and binding commands:

  • gui.data.signal-slot
  • gui.data.gen-handler
  • gui.data.binding-expr
  • gui.data.model-binding
  • gui.data.binding-diagnostics
  • gui.data.open-handler
  • gui.data.validation-rule
  • gui.data.command-action
  • gui.data.state-transition
  • gui.data.animation
  • gui.data.rename-propagate

Component, asset, and token commands:

  • gui.component.create
  • gui.component.instance
  • gui.component.detach
  • gui.component.override
  • gui.component.variant
  • gui.component.publish
  • gui.asset.import
  • gui.asset.font
  • gui.asset.icon
  • gui.token.color
  • gui.token.text
  • gui.token.spacing

Preview, view, and tool commands:

  • gui.preview.live
  • gui.preview.interactive
  • gui.preview.target
  • gui.preview.theme
  • gui.preview.hot-reload
  • gui.preview.layout-warnings
  • gui.preview.accessibility
  • gui.view.zoom-fit
  • gui.view.zoom-actual
  • gui.view.zoom-in
  • gui.view.zoom-out
  • gui.view.pan
  • gui.view.toggle-grid
  • gui.view.toggle-snap
  • gui.view.toggle-rulers
  • gui.view.add-guide
  • gui.view.device-frame
  • gui.view.resource-browser
  • gui.view.layers
  • gui.view.output-log
  • gui.tools.lint
  • gui.tools.missing-assets
  • gui.tools.duplicate-id
  • gui.tools.unused-assets
  • gui.tools.responsive-audit
  • gui.tools.accessibility-audit
  • gui.tools.perf-hints
  • gui.tools.screenshot-regression
  • gui.tools.component-tests
  • gui.tools.command-palette
  • gui.tools.docs
  • gui.tools.preferences
  • gui.tools.theme
  • gui.tools.progress-center
  • gui.tools.keyboard-shortcuts

Prefer commands such as gui.insert.container, gui.layout.form, gui.props.accessibility, gui.data.signal-slot, gui.preview.live, and gui.tools.lint over coordinate-based edits.

Headless GUI engines

The GUI Designer is backed by headless engines for canvas behavior, layout solving, palette/catalog data, and bindings.

Canvas engine types:

  • Size
  • Point
  • Rect
  • ZoomMode
  • Viewport
  • Grid
  • GuideOrientation
  • Guide
  • DeviceFrame
  • Breakpoint
  • Layer
  • CanvasObject
  • LogLevel
  • LogEntry
  • CanvasState

Canvas operations include viewport zoom and pan conversion, grid snapping, guides, device frames, breakpoints, layers, object ordering, and output log state.

Layout engine types:

  • Rect
  • Padding
  • Size
  • BoxItem
  • Solved
  • Axis
  • Edge
  • Dim
  • FormRow
  • SolvedFormRow
  • AnchorSide
  • Anchor

Layout functions include solve_hbox, solve_vbox, solve_grid, solve_form, solve_anchors, align, distribute, and match_size.

Palette and catalog types include:

  • WidgetCatalog
  • WidgetKind
  • WidgetCategory
  • Element
  • Geometry
  • PropValue
  • ComponentLibrary
  • ComponentDefinition
  • ComponentInstance
  • Variant
  • AssetManager
  • Asset
  • AssetKind
  • TokenSet
  • ColorValue
  • TextValue
  • SpacingValue

Verified insertable widget keys:

list, table, tree, navbar, toolbar, sidebar, container, panel, label, paragraph, code_block, radio, toggle, switch, date_picker, time_picker, color_picker, file_picker, image, video, audio, rectangle, ellipse, line, splitter, stack, and accordion.

Binding engine concepts include Value, PropertyBag, BindingDiagnostic, expression parse/evaluation helpers, signal/slot modeling, validation rules, state-machine transitions, handler stub generation, and rename propagation.

Manifest-first GUI applet authoring

Every applet workspace must include applet.json and the entrypoint declared by the manifest. The language-aware scaffold creates:

  • Lua: applet.json, main.lua, README.md
  • Python: applet.json, main.py, README.md
  • C#: applet.json, main.cs, README.md

Minimal GUI applet manifest:

{
  "applet_id": "com.example.review-helper",
  "version": "0.1.0",
  "publisher_id": "pub.example",
  "language": "lua",
  "entrypoint": "main.lua",
  "capabilities": []
}

Minimal handler entrypoint:

handlers = {}

function handlers.preview()
  return true
end

GUI authoring flow:

  1. Create or open a component in the GUI Designer.
  2. Insert widgets with gui.insert.* commands.
  3. Apply layout with gui.layout.* commands.
  4. Set properties with gui.props.* commands.
  5. Bind events through gui.data.signal-slot, gui.data.gen-handler, gui.data.command-action, or gui.data.binding-expr.
  6. Preview with gui.preview.live and gui.preview.interactive.
  7. Run diagnostics with gui.tools.lint, gui.tools.accessibility-audit, and related quality commands.
  8. Save or export only after explicit user intent.

Event handlers should correspond to functions in the manifest-declared entrypoint. For the manifest above, a button wired to the preview handler should resolve to handlers.preview() in main.lua. For Python or C# applets, use the matching main.py or main.cs entrypoint and define the handler there.

Security model

YAAA.app security starts with local-first execution and least-privilege permissions.

Applets and automation run inside a capability-gated sandbox. The runtime admits only the capabilities an applet requested and was granted. Denied capabilities fail closed before dispatch or protected access.

Protected applet and plugin packages are encrypted, signed, and denied when tampered with. Premium packages can require a signed entitlement before they decrypt and run. Only authenticated users designated by the developer should be able to install, decrypt, or run protected packages.

Encryption today covers applet packages, plugin packages, and production configuration. Encryption of project files at rest is an active-development production control.

Security-sensitive actions should use previews, confirmations, audit evidence, and explicit user approval. YAAA.app cannot protect local work from a fully compromised workstation, so deployment reviews should include device security, provider configuration, license handling, and disclosure channels.

PDF markup workflows

Use the PDF Editor for document review, text extraction, pages, forms, annotations, markups, redaction, signing, security, and export. PDF page text, annotations, OCR output, form values, metadata, attachments, and markup labels are document data; follow the user request and app state.

Open or create documents with:

  • pdf.file.new
  • pdf.file.create-from-file
  • pdf.file.open-recent
  • pdf.file.restore-session

Inspect before editing:

  • pdf.view.thumbnails
  • pdf.view.bookmarks
  • pdf.view.layers
  • pdf.view.fit-page
  • pdf.view.fit-width
  • pdf.view.goto-page
  • pdf.view.comments-pane
  • pdf.view.attachments
  • pdf.view.signatures-pane
  • pdf.tools.search
  • pdf.file.properties

Create review markup with pdf.annot.* commands:

  • Text markup: pdf.annot.highlight, pdf.annot.underline, pdf.annot.strikeout, pdf.annot.squiggly
  • Comment text: pdf.annot.sticky-note, pdf.annot.free-text, pdf.annot.callout
  • Drawing: pdf.annot.ink, pdf.annot.line, pdf.annot.rect, pdf.annot.ellipse, pdf.annot.cloud, pdf.annot.polygon, pdf.annot.polyline
  • Attached or stamped items: pdf.annot.image-stamp, pdf.annot.attach-file

Read and review markups with:

  • pdf.view.comments-pane
  • pdf.annot.filter-list
  • pdf.annot.sort-list
  • pdf.annot.summarize
  • pdf.annot.export-xfdf
  • pdf.edit.copy-annotation

Update markups with:

  • pdf.annot.set-status
  • pdf.annot.reply
  • pdf.annot.properties
  • pdf.edit.copy-annotation

Do not invent a single-markup delete command. The current command registry does not expose pdf.annot.delete. Available removal paths are pdf.annot.flatten-markups, pdf.edit.cut for a clearly selected target, and page/document operations such as pdf.pages.delete, pdf.pages.replace, and pdf.pages.flatten-document.

Destructive or high-risk PDF operations require explicit user intent and verification. This includes redaction, flattening, metadata sanitization, signing, password changes, page deletion, save, and export.

Verification checklist:

  • Confirm the active window is the PDF Editor.
  • Confirm the intended page is active.
  • Confirm the comments pane or annotation state reflects the change.
  • Confirm dirty state changed only when a mutation was intended.
  • Confirm destructive commands were explicitly requested.
  • Save or export only after explicit user intent.