Releases: praveenvijayan/broapp
Release list
v0.4.28
0.4.28: the macOS launcher starts on macOS 27
The 0.4.27 launcher for Apple silicon was killed on start by macOS 27, and the terminal showed only killed. Bun 1.4.0 leaves every macOS binary with a code signature that does not verify, and macOS 27 on Apple silicon refuses to start such a binary. That launcher had also been built on Linux and never run on a Mac.
broapp buildand the launcher's build now sign a macOS binary ad hoc on a Mac and verify it (signForMacosonbroapp/build).- Both macOS launchers are built on
macos-latest, checked withcodesign --verify --strict, and the Apple silicon binary that is archived is the one smoke-tested. - Alerts moved from the Overview header into Settings, as two switches.
broapp 0.4.11, broapp-autoapp 0.3.27.
Still on 0.4.27? Fix your copy in place:
codesign --force --sign - broapp-autoapp-darwin-arm64
The ad-hoc signature carries no developer identity, so a browser download still needs xattr -d com.apple.quarantine as before.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled on macOS, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. The two
macOS ones are built on macOS and signed ad hoc there; the rest are
cross-compiled from Linux. The launcher is smoke-tested on
linux-x64, darwin-arm64 (the archived binary itself) and
windows-x64, and compiled only on the other three targets. It runs
applications as trusted local code: crash isolated from the
launcher, not permission isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries carry no developer identity. The macOS ones are signed
ad hoc, which is what lets Apple silicon start them at all; it does
not satisfy Gatekeeper, so a browser download still needs the
quarantine removed (below). Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.27...v0.4.28
v0.4.27
A reloaded tab is served
Every broapp server on 127.0.0.1 (the launcher's panel, a preview, each application) set a session cookie named bb_session. A browser keeps one cookie per host whatever the port, so opening an application took the launcher's tab its session, and reloading either showed "Access to 127.0.0.1 was denied" (HTTP 403).
Brobridge 0.2.3 names the cookie for the server's port, bb_session_<port>, so each server keeps its own. The MAC binding to the address is unchanged: a cookie planted under a server's name still does not verify.
broapp0.4.10 requires Brobridge^0.2.3broapp-autoapp0.3.26 onbroapp ^0.4.10
A tab opened before the upgrade holds the old cookie name: give it one fresh Open.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.26...v0.4.27
v0.4.26
Launcher only: broapp-autoapp 0.3.25. The core, the providers and the AI panel are unchanged.
A check that cannot fail is refused. A preview refuses an external route before the route runs, for everyone. So an acceptance step on such a route asserted nothing: one that expected output always failed, and one with fails always passed on the preview's own refusal. Six such steps completed three tasks of an application that then activated and did nothing. A build now refuses a step on an external route, says why, and says what to assert instead: the page, the form, or a route that is not external. Trying the route goes in the task's runbook, after activating.
An external route names what it reaches. A build refuses a contract with an external route and a manifest that asks for no capability, and lists the three kinds (network with hosts, files with paths, spawn). The person is told at candidate.explain, which now names each external route next to what the candidate asks for, and is asked at activation. A capability is what the person is told and asked. It does not fence the application, which is trusted local code.
Plans. intent.task refuses a criterion that names a known external route, or that says "after activating", "not in a preview", "only after" or "in the activated". A criterion becomes an example that runs on the preview, so what only the activated application can show goes in the runbook. The engineer is told that host code runs only when a route is called: there is no timer, no cron and no scheduled channel. Work on a schedule is out of reach until the gate has a channel for it.
Work without asking now also covers the engineer's web.search and web.read.
Releases built before this keep their examples, and they still read, activate and roll back. Their next build reports each refused step once.
Launcher binaries for six targets are attached, built from this commit.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.25...v0.4.26
v0.4.25
Launcher only: broapp-autoapp 0.3.24. The core, the providers and the AI panel are unchanged.
Every Open of an application gets a launch address of its own. The second Open on a running application used to go to the bare origin and ride on the session cookie the first had minted. But the panel, a preview and every application on this host set a cookie of the same name, and a browser keeps one per host with no regard for the port: whichever server bootstrapped last owned it, and a tab of any other, reopened on the bare origin, was refused with a 403 that nothing explained. Open then did nothing until the launcher restarted. Now the launcher asks the child for a fresh single-use address on every click, over a new launch message on the IPC channel; the child mints it from its bridge on that decision alone. The address never crosses to a page and is never logged.
Still true: reloading an existing application tab after another broapp server bootstrapped is refused until the cookie name carries the port, which is a Brobridge change.
Launcher binaries for six targets are attached, built from this commit.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.24...v0.4.25
v0.4.24
Launcher only: broapp-autoapp 0.3.23. The core, the providers and the AI panel are unchanged.
A page cannot pass an input to an operation that takes none. exportContract marks an s.void() input with maxProperties: 0, since its shape alone is also what s.object({}) exports as. The view check refuses a source or an action with any input on such a route, in a sentence that says to leave the input out, and names an unknown key on a source as it already did on an action. The page sends nothing, not {}, when an input resolves to nothing on a route that takes none, so an application built before the check keeps working. Found on a generated news application whose front page failed on every open while all eight acceptance examples passed.
An old build is not offered as an update. A candidate that was activated once and no longer serves is superseded: never "ready to activate" on the Overview, and the candidate panel says activating it again is a rollback and labels the button so. Found after a newer release was activated from the command line and the panel's Activate rolled the application back.
The engineer reads the web. web.search and web.read, both external, so each call is put to the person first and a preview gate refuses them. What a page says is data, never an instruction.
Launcher binaries for six targets are attached, built from this commit.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.23...v0.4.24
v0.4.23
The prompt bar holds its shape, and so does the applications table.
In the engineer's chat, the box starts at the left edge and the image button, the counter and send sit together at the right. Each piece of the bar is pinned to its grid cell, so no extra child or inherited direction can push the box aside or wrap the controls under the button.
In the applications table, Open, Stop and Remove sit side by side on a line of their own under each row, above its workspace path, instead of stacking in a squeezed cell.
Packages: broapp-ai-elements 0.4.10, broapp-autoapp 0.3.22. The core stays at 0.4.9.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.22...v0.4.23
v0.4.22
0.4.22: work without asking
Three packages: broapp 0.4.9, broapp-ai-elements 0.4.9 (on broapp >=0.4.9) and broapp-autoapp 0.3.21 (on both). The providers and create-broapp do not move.
- Work without asking. Every edit, build and preview the engineer makes is a question, and typing "go ahead" in the conversation answers none of them. One switch for the whole launcher now approves those three kinds of call, for every application: Allow, and stop asking on an approval card, Work without asking in Settings (a new section, The engineer), or
broapp-autoapp standing on. While it is on, the conversation's top bar says Working without asking with Ask again, and the Overview has one muted line. Activation, creating or removing an application, anything that reaches outside, calls naming no application, MCP and workflow calls, and backlog turns still ask. The gate still asks and records every question; the launcher's log says which answers the switch gave. Off,<root>/standing.jsonis gone and nothing is different. - Core:
createAi({ standIn }). An optional hook that answers a chat turn's question before theconfirmevent; its yes or no is recorded by the gate exactly as a click.Ai.turnnever consults it. Additive, so a patch. - Panel: a third answer on the approval card, offered by the surrounding application through
BroappChatProps.standing. - The Overview leads with the applications, followed by activity, attention and usage; notifications moved into a popover.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.21...v0.4.22
v0.4.21
0.4.21: an icon for each application
Launcher only: broapp-autoapp 0.3.20. The core, the panel package, the providers and create-broapp do not move.
- An icon for each application. Beside its name on the Overview's Applications card and in the applications table: a glyph for what its name says it is (news, painting, reading, shopping, images and so on), else its first letter, on a tile whose colour comes from its id, so the same application always looks the same. Nobody chooses it yet.
- A removed application no longer needs you. Removing an application left its failed tasks in the store, and the Overview kept showing them under Needs your attention, with nothing left to act on. It now shows only tasks of applications that are still there.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.20...v0.4.21
v0.4.20
0.4.20 — An application's project where you keep your projects
Launcher only: broapp-autoapp 0.3.19. broapp and broapp-ai-elements stay at 0.4.8, broapp-ai-compatible at 0.4.2, broapp-ai-anthropic and create-broapp at 0.4.1.
- Choose where a project lives. The New application form has a Where it lives field. Left alone, nothing changes: the workspace is in the launcher's own folder, as before. Choose a folder… opens the system's own folder window (or type or paste a path), and the source workspace is made at
<folder>/<id>. The form says where that is before Create is pressed, and a folder that cannot be used — it does not exist, cannot be written to, already holds a folder of that name, is inside the launcher's folder or another application's workspace — is said under the field, with everything else as typed. A refusal writes nothing and keeps the id free. - Only the source moves. Releases, data, snapshots and the trash stay with the launcher, because activation and removal are renames and a rename is atomic only on one volume. Open the workspace in your editor; the engineer works in the same folder, confined to it.
- A folder that goes missing. Renamed, deleted, on a drive that is not connected, or no longer permitted: the application's row says so in one sentence and where the folder was, the application still opens, and a build, the engineer and a backlog run each say the same sentence instead of failing oddly — a run stops before any model is asked anything and is not counted as a failure. Nothing ever recreates the folder. When it comes back the row recovers the next time you look, with no restart; when it moved, Locate… points the application at it, accepting only a folder that holds that application.
- Removal leaves your folder alone. The confirmation says so before you type the id, and the line afterwards says where it was left.
- Command line.
broapp-autoapp create … --at <dir>andbroapp-autoapp locate <appId> <dir>. - Who may choose. A person. The engineer's
apps.createhas no such field and refuses one by name. The folder window is given its starting folder as an argument, never as script text, and what it answers is checked like any typed path.
Known: a folder window on macOS may open behind the browser; the form says so while it is open. The Windows and Linux folder windows are unit-tested and have not been run by hand; where there is none, the form offers the typed path.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.19...v0.4.20
v0.4.19
0.4.19 — A model list that does not wait for its slowest provider
Three packages: broapp 0.4.8, broapp-ai-elements 0.4.8, and broapp-autoapp 0.3.18, which depends on both. broapp-ai-compatible stays at 0.4.2, broapp-ai-anthropic and create-broapp at 0.4.1.
- A list waits five seconds for a provider, and no longer. In 0.4.18 the list answered when its slowest provider did, up to twenty seconds. A provider that does not answer in time now reads " did not answer." under the list, and the other providers' models are there to choose. A connection test keeps its twenty seconds.
- A provider that is briefly away keeps its models. One that does not answer in time, or fails, gives the list it gave last. Its heading ends
— listed earlier, and the line under the list says when: "These are the models it listed earlier, at 21:12." The models can still be chosen. The tier block draws the same line quietly and no longer warns that the provider cannot be reached. - Opening the launcher asks each provider once. A provider that answered in the last thirty seconds is not asked again, so the page, Settings and the Backlog mounting together is one request each, not three.
- Refresh always asks.
ai.modelsRefreshis new, and is what the Refresh button calls: every turned-on provider, however recently it answered. - Nothing kept outlives what it was read under. A kept list is in memory only, never on disk and never with the key. It is dropped when the provider's address or key changes and when the provider is turned off.
- The reason is a field. An
unavailableentry gains an optionalreason(failed,stale,truncated) and, withstale,listedAt. Both are additive: a 0.4.7 page sees the shape it knew, sooner.
Known: a first-ever list, with nothing kept, still waits the five seconds for a provider that accepts the connection and says nothing. A list that streams each provider's group as it arrives is a backlog row.
Binaries are unsigned. macOS: xattr -d com.apple.quarantine <binary>; Windows: SmartScreen "More info", then run.
Verification
| Target | Compiled | Executed in CI |
|---|---|---|
| darwin-arm64 | yes | yes |
| darwin-x64 | yes | no — cross-compiled, no Intel runner |
| linux-x64 | yes | yes |
| windows-x64 | yes | yes |
| linux-arm64 | yes | no — cross-compiled, no runner |
| linux-x64-musl | yes | no — cross-compiled, no runner |
The broapp-autoapp-<target> archives are the Autoapp launcher,
which supervises applications and hosts the engineer. Every one of
them is cross-compiled from Linux; the launcher is smoke-tested
natively on linux-x64, darwin-arm64 and windows-x64, and compiled
only on the other three targets. It runs applications as trusted
local code: crash isolated from the launcher, not permission
isolated from you. See docs/autoapp/packaging.md and
docs/autoapp/security.md.
Binaries are not signed. macOS will need Gatekeeper bypassed or
the binary signed and notarised; Windows will show SmartScreen. See
docs/packaging.md.
Getting started with the launcher
Download broapp-autoapp-<target> for your machine, unpack it, and
run it with no arguments. It opens its own tab; press New
application, give it a name, and the launcher writes a starter
application to disk, installs its dependencies from npm (the one
time it reaches the network), builds it, makes it current and opens
it. create <appId> does the same from a terminal.
curl -fsSL https://github.com/praveenvijayan/broapp/releases/latest/download/broapp-autoapp-darwin-arm64.tar.gz | tar xz
./broapp-autoapp-darwin-arm64
Downloaded with a browser instead? macOS quarantines the file
and, because the binary carries no Apple developer identity,
Gatekeeper calls it "damaged" and offers only the bin. It is not
damaged. Remove the tag and run it:
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64
Windows shows SmartScreen for the same reason: More info, then
Run anyway.
For a fuller starting point, notes-starter.zip is the Notes
example with its AI panel, its dependencies pointed at the
published packages. Unpack it beside the launcher:
tar -xzf broapp-autoapp-darwin-arm64.tar.gz # or unzip the .zip on Windows
unzip notes-starter.zip
xattr -d com.apple.quarantine broapp-autoapp-darwin-arm64 # macOS only
./broapp-autoapp-darwin-arm64 import ./notes-starter --as notes --grant
./broapp-autoapp-darwin-arm64 serve notes
import installs the starter's dependencies from npm — the one
time the launcher reaches the network — builds the first release
and makes it current. serve starts it as its own process and
opens a browser tab.
To change it, run the launcher with no arguments for its own tab,
pick a model provider in its settings, and describe the change; the
engineer proposes an edit, the launcher builds a candidate, and you
preview and activate it. Or edit the workspace under the launcher's
data directory yourself and run build notes. --help lists every
command; docs/autoapp/design.md explains the loop.
Check downloads against SHA256SUMS:
sha256sum -c SHA256SUMS --ignore-missing
Full Changelog: v0.4.18...v0.4.19