tula v0.1.1

[hsnice16]

The install line pasted a second time — which is how most people fix a PATH problem — downloaded and re-verified the whole 21 MB archive to arrive at the file it already had. It recognises the version under ~/.tula/versions now and goes straight to relinking: 2.7s to 0.3s on a warm link, and from minutes to under a second on a cold one. The short cut needs the launcher symlink to be there already, not merely the directory. A directory is something anyone able to write under the install tree can put there before tula is ever installed, and a first install used to download over whatever it found — where adopting it would link an unread binary and say "already installed". TULA_FORCE=1 fetches and checks again regardless, and install-test.sh plants a version directory to prove the fast path declines it.

-s silenced curl's meter on every fetch, including the one that takes minutes, so a single downloading line stood unchanged for the whole transfer: 152 seconds of silence in one capture, between the first line and the next. The archive keeps the meter; the 386-byte checksum file does not. The download is GitHub's and is not faster — it is visibly moving. A transfer under 1 KB/s for 30 seconds is ended rather than waited on, which is the difference between a slow link and a dead one.

The banner carries a v before the version, as the tag and every git and npm line about the build already do, and the directory the shell was opened in. tula reads nothing from that directory; it is what tells two terminals apart. It is stripped of control characters and capped like any other text tula did not write — every byte but / and NUL is legal in a directory name, so a cloned repository can carry one named to repaint whatever draws it, and Ink writes text verbatim. Paths in the installer's report are written from home for the same reason the banner's is: the absolute form is mostly the reader's own username, and the part they would redact before pasting a screenshot.

release.yml skips npm packages already published rather than dying on the first one under set -e, which is what made v0.1.0's recovery uncertain after a token that could not bypass 2FA failed the job part-way through. AGENTS.md says which token types actually bypass it, since the claim that a token always does was disproved, and the pre-release table gains the release environment — naming it in the workflow does nothing until it exists.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
tula	Ready	Preview	Sep 6, 2026 6:52pm UTC