Build the tool.
Hudson provides the workspace.
Canvas, side rails, commands, persistence, logging, and agent-ready infrastructure — already working together. Your team owns the model, renderer, and interactions that make the product yours.
The component below is a Hudson embed.
This is the real workspace shell, rendered from the SDK. Same chrome, canvas, app windows, command surface, and live decoration layer any Hudson app inherits.
Note. Every parameter on this sheet is read from the same manifest.ts the embedded workspace consumes.
A typed object names your app.
id, mode, intents, ports — Hudson reads it like a blueprint.
Intents become voice + ⌘K.
Each entry is indexed for fuzzy match, hotkeys, and the assistant.
Drop in primitives.
Frame, Nav, Panel, Canvas, Status — same chrome every app inherits.
Carry the workspace language forward.
Use platform-native Hudson primitives wherever the product needs another surface.
Apps own the work. Hudson owns the workspace.
Select a thing once; watch the canvas object, layer definition, and shell UX light up together. The deck is the map between what you touch and what Hudson knows.
Describe something. It appears on the canvas.
A virtual pen plotter renders your words in single-stroke drafting type, then dimensions the result like an engineering specimen. Download the SVG and use it however.
Speak. The chrome understands.
Every intent you declare is searchable — by keystroke, by ⌘K, and by voice. Hudson handles the loop: capture, transcribe, match, dispatch. Your app gets a typed call.
Every intent fuzzy-searched. Open with ⌘K, type three letters, hit return.
Tap-and-hold or hotword. Same intents, no extra wiring per surface.
Assistant reads the result back if the intent declares a voice reply.
Consistent primitives. Native implementations.
chrome: ["nav", "rails",
"status"],
actions: ["commands",
"intents"],
canvas: true,
};
Navigation, side rails, commands, status, canvas, and observability follow the same product vocabulary. Each surface implements those primitives in its native stack — SwiftUI on Apple platforms and React on the web. Hudson provides the workspace model; your team still owns each product implementation.
workspace vocabulary implemented per surface web → React / hudsonkit macOS → SwiftUI / HudsonKit iOS → SwiftUI / HudsonKit shared model · platform-native code
Four apps,
one kit.
Each ships independently — its own brand, its own scope, its own audience. They share Hudson the way print designers share a type system: identical bones, distinct identities.
The workspace around your tool, already handled.
Eight foundational components establish the workspace vocabulary. They compose and nest into the shell patterns Hudson apps share. If you've used one Hudson workspace, the interaction model is already familiar.
Chrome root. Hosts nav, panels, canvas, status.
Crumbs, ⌘K, install. Always pinned to top.
Manifest, inspector, file tree. Either side.
Pan/zoom workspace. Floating windows live here.
Live runtime: uptime, intents, logs, version.
Fuzzy-searches every intent. Voice + keys.
Slide-up shell. Natural-language → bash.
AI primitive. Reads capability map, dispatches commands.
From product spec to working workspace.
The boundary is straightforward: your team owns the domain model, renderer, and interactions. Hudson provides the canvas, rails, commands, persistence, logging, and agent context around them. Three commands get that contract running.
$ bun add hudsonkitAdd the workspace layer without replacing the product code your team owns.
$ hudson new my-appGenerate the app contract: provider, slots, hooks, commands, and intents.
$ bun devImplement your model, renderer, and interactions inside the normal dev loop.
Build what makes the product distinct. Keep the workspace solved.