Limits and security

Stellar’s limits are choices, not pending items. Each one exists to close a concrete failure mode.

Consent and least privilege

Operations with a side effect on disk or on processes — writing a file, running a command, creating a card, opening a URL — require explicit approval in the default flow. The agent asks, with a declared reason; you decide.

A board can be put in autonomous mode. In that case automatic dispatch proceeds, but strictly respects the configured concurrency cap and the spawn-chain depth cap. Autonomy is not absence of rule.

Sandbox isolation

Commands run by agents on Linux are confined by a sandbox. The home directory outside the project root is masked, which prevents reading the host’s keys, credentials and dotfiles.

Gates require a sandbox

A task can declare gates — commands the app runs on its own after an accepted report, and whose stdout, stderr and exit code are recorded as evidence. The gate runs confined, and that is why declaring one on a system without a sandbox is refused at task creation, naming the fact and the honest way out: declare no gates and cover the same ground in the report, by running the commands yourself. Clearing a gate that already exists remains allowed — otherwise the machine would be stuck in a promise it cannot keep.

In practice, this hits macOS and Windows, where Stellar’s confinement does not exist (the sandbox is bubblewrap, on Linux). The refusal happens at declaration and not at execution, on purpose: a gates field that will never run is worse than an absent field — it promises evidence that does not exist, and the discovery would come late, in the report, as “gate did not run”.

Single writer, by design

The app opens one instance per database. Two writers collide on card identifiers on the first card created. It is not a bug: it is a premise, documented and defended. It is also the reason teamwork is a problem of concurrent writing — and not of kanban.

No telemetry

Nothing you do in Stellar is sent anywhere. There is no metrics server, and the app runs entirely without an account. What measures your work — rounds, times, cost per model — stays in your database, for you.

The exception is one request, and it is honest to name it instead of hiding it behind the sentence above: the app checks the GitHub releases to know whether there is a new version. It is a request, not telemetry — it carries nothing about your work, and the direction is the reverse (the app asks, no one is told). The alternative was the app saying “no news” forever, which is exactly what happened when the project left GitHub and the feed went absent in silence. Today the absence of a feed is a state of its own, with a declared reason, never an empty success — and the macOS install without a signature swaps the bundle, leaving a log of what it did.

What an agent report is worth

A report is a record, not a verified fact. When the claim has a consequence, it is checked: by running the gate in an isolated worktree, reading the line written in the database, repeating the measurement. Reporting on code that is not installed already cost a whole day of wrong conclusions — the build that runs may not be the repository’s code, and checking that is part of the work.