StartOS start-cli 1.0.1

What's Changed

• s9pk init-package initializes a git repository in the new package. Packages are

their own git repos - the template ships a .gitignore and GitHub Actions workflows - so init-package now runs git init in the scaffold. No commit is made; your first commit is yours.

• s9pk pack no longer requires a committed git repository. It still stamps the

manifest with the repo's commit hash when one exists (suffixed -modified if the tree is dirty), but a freshly scaffolded package - a git init with no commit yet, or a non-git directory - now builds with the hash simply omitted, instead of failing with fatal: not a git repository. The hash appears once you make your first commit. This is what lets a brand-new package build immediately after init-package.

• s9pk init-workspace no longer fails when a .startos exists above the target.

A leftover global ~/.startos (or any enclosing workspace) used to trip a "Cannot create a workspace inside an existing one" guard and block workspace creation anywhere under it. Nesting is now allowed: init-workspace just creates the workspace, paying no attention to outer ones. When building, signing, or reading config, start-cli walks up from the current directory and uses the nearest .startos/, so a nested workspace transparently overrides an outer one (conceptually a deep merge of every .startos/ on the path). The one refusal that remains is running inside a package repo - a workspace holds package repos; it isn't one. (There is no automatic migration from an older global ~/.startos; copy developer.key.pem to a workspace's .startos/build-key yourself to reuse a signing key.)

• Better "no workspace" errors when building/signing. s9pk pack (and therefore

make / make publish) needs a workspace signing key; when none is found above the cwd it now explains that packaging happens inside a workspace (which also brings the AI guide) and points to init-workspace. If you're inside a package repo, the error names the parent directory to run it in (cd <parent> && start-cli s9pk init-workspace), so an existing package repo is one command away from building. The init-workspace-inside-a-package-repo refusal points at the same parent.

• --version now reports start-cli's own version (1.0.1) rather than the StartOS

platform version it was previously wired to.

start-cli Checksums

SHA-256

f3d28590104b1ae6d7f31668ab17a3c6f1bbe91d252b00253b5fd8f60f9cb4cc  start-cli_aarch64-linux
54d0b0841f4d9e8bbd6a3bc99ee04e9e93f48ad8bea24cb4666f55d53b45d288  start-cli_aarch64-macos
bf47ae600ca007f396f2bc684e636cd13baf138729a4176fc858acb28f20c3b9  start-cli_riscv64-linux
82a042a0a1c351dd054d6f95c368471098d2492793d864dc3a7aa15905389e17  start-cli_x86_64-linux
5b7b2d1a2aeb8a6a0df384db94d84d419f17aae7133590fc1accb59a3f411a6d  start-cli_x86_64-macos

BLAKE-3

7af6da7135b3c7d56543b88ea9e7d16820c639b10f1bd8b79333b18b518a52b6  start-cli_aarch64-linux
84f8bd3e98fcc3b19b6392e6b4432d8f5366848218ed371439aa0250aaa28599  start-cli_aarch64-macos
c55f99a8282ea98872b74377d4a8e212f5b4241c141d3362eaaba0a6b12efb3e  start-cli_riscv64-linux
67b92f6d4794755df52ec346d9a7fd9a5acff1dd9a27efc68ad85c50d9ad9499  start-cli_x86_64-linux
568e933e3d87688c576fc87daf26b2df149142158a8898838130b3a5876c76a3  start-cli_x86_64-macos

start-cli packages Checksums

SHA-256

26e554eb5590daf8951a4930e9eccec5e2f9dd8031f6171d29585867fd293354  start-cli-1.0.1-7d5f386_aarch64.deb
cc2d60eaa174cdcf2560e7a0591cd42b1e5cb0e7c4455f7acdaa48f93a62f389  start-cli-1.0.1-7d5f386_riscv64.deb
ce6074897a1e3715f5c08140d46ff8fc4cd0f438b6feb7ef75e64eb9f3d0eb9e  start-cli-1.0.1-7d5f386_x86_64.deb

BLAKE-3

dff3421b362f7f5be1596665f62f60e4b3ab7bf241c0a1e8ea9dc26339ec55a4  start-cli-1.0.1-7d5f386_aarch64.deb
bdef819f4dc3b1ff73d4ebb1b7192ab255ff8771a5744bf41530812478618998  start-cli-1.0.1-7d5f386_riscv64.deb
c1b02bceb28ec58ea7cef0c3133227bb15e73bd283ef858c4935f6b4111d82c7  start-cli-1.0.1-7d5f386_x86_64.deb