Start9Labs/start-technologies start-cli/v1.0.1

start-cli v1.0.1

on GitHub

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