@functional-systems/lambdadb-cli 0.1.0 → 0.1.1-dev.7

package/CHANGELOG.md

@@ -2,7 +2,19 @@
 
 ## [Unreleased]
 
-## [0.1.0] - 2026-09-18
+### Added
+
+- A Homebrew formula for the published stable CLI, with a managed Node 24 runtime,
+  checksummed npm/lockfile inputs and isolated production dependencies.
+- Local Homebrew installation checks, installed CLI contracts and macOS/Linux PR
+  validation. Public tap publication remains a separate pending step.
+
+### Maintenance
+
+- Synchronize the 0.1.0 release history into develop and start the 0.1.1 development
+  line. Stable installs use npm's default channel; dev builds remain opt-in.
+
+## [0.1.0] - 2026-09-19
 
 ### Added
 

package/CONTRIBUTING.md

@@ -66,7 +66,7 @@ development base in that synchronization PR so develop retains a dev version.
 
 A separate `release/*` branch can be created from reviewed develop and target
 main when preparing rc/stable metadata while develop retains its automatic dev
-base. The first stable release uses `release/0.1.0` for this reason. Do not merge
+base. The first stable release used `release/0.1.0` for this reason. Do not merge
 stable package metadata into develop without setting its next dev base, because
 automatic development publication requires an `X.Y.Z-dev.N` version.
 

package/README.md

@@ -10,25 +10,26 @@ Requires Node.js 22.14 or newer and npm.
 
 ### Install from npm
 
-The verified development build is available on the `dev` channel:
+Install the stable channel:
 
 ```sh
-npm install --global @functional-systems/lambdadb-cli@dev
+npm install --global @functional-systems/lambdadb-cli
 lambdadb --version
 lambdadb --help
 ```
 
-This checkout prepares `0.1.0`. Once its GitHub Release and npm publication are
-complete, install the stable version with:
+For reproducible CI runs, pin an exact published version such as
+`@functional-systems/lambdadb-cli@0.1.0`. To try development builds, explicitly use
+`@functional-systems/lambdadb-cli@dev`; this moving channel contains prereleases.
+Installed CLIs do not update themselves. See
+[RELEASING.md](RELEASING.md#current-status) for release status and
+[VALIDATION.md](VALIDATION.md) for verification results and remaining limitations.
 
-```sh
-npm install --global @functional-systems/lambdadb-cli@0.1.0
-```
+### Homebrew
 
-The `dev` channel contains prerelease versions. For reproducible CI runs, pin an
-exact published version instead of the moving `dev` tag. See
-[RELEASING.md](RELEASING.md#current-status) for release preparation status and
-[VALIDATION.md](VALIDATION.md) for verification results and remaining limitations.
+Homebrew support is being prepared for macOS and Linux. The formula and local
+installation checks are in [the maintainer guide](https://github.com/lambdadb/lambdadb-cli/tree/develop/packaging/homebrew#readme).
+The public tap is not published yet; use npm for installation today.
 
 ### Build from source
 

package/RELEASING.md

@@ -2,49 +2,37 @@
 
 ## Current status
 
-The `release/0.1.0` candidate prepares the first stable version from reviewed
-`develop` commit `c8947e9`. It changes package/lock versions and release documents;
-CLI runtime, dependencies, tests and workflows match the verified development build.
-The promotion PR targets `main` directly so `develop` keeps its automatic dev base.
-Merge with a merge commit, then obtain authorization for `v0.1.0` and a non-prerelease
-GitHub Release. Main promotion alone does not publish npm. After publication,
-verify `latest=0.1.0`, provenance and a clean consumer installation. Synchronize
-main back to develop through a PR that also sets the next development base.
-Stable publication has not yet been performed.
-
-The ordinary develop merge published `0.1.0-dev.5` through OIDC in
-[one successful workflow attempt](https://github.com/lambdadb/lambdadb-cli/actions/runs/35344153978).
-The new verification logic handled approximately three minutes of registry
-propagation without repeating the write or rerunning the workflow. A fresh npm
-installation passed 35 CLI contracts, integrity and provenance/signature checks.
-
-Bootstrap and initial OIDC publication were completed on 2026-09-18:
-
-- `0.1.0-dev.1` was published publicly from reviewed develop as the manual bootstrap.
-- `0.1.0-dev.4` was published by GitHub Actions with verified provenance for
-  commit `f2397ba`. Its registry installation passed all 35 CLI contract tests.
-- The repository variable `NPM_DEV_PUBLISH_ENABLED=true` enables eligible develop
-  pushes after Node 22/24 CI. Main promotion is required only for rc/stable.
-
-These are recorded validation milestones, not a continuously updated list of
-versions. Check npm for current dist-tags. At verification, `dev` pointed to
-`0.1.0-dev.4` and `latest` remained at the bootstrap `0.1.0-dev.1`: the first
-publication created both tags despite `--tag dev`, and removing `latest` returned
-HTTP 400. The next dev publication preserved `latest`. No stable version has been
-published; explicitly select `@dev` or an exact development version until a
-reviewed rc/stable release is available. Do not repeatedly delete the bootstrap
-tag or publish a placeholder to work around it.
-
-The CLI is licensed under [Apache-2.0](LICENSE), with matching package metadata.
-Publication, provenance and development-project smoke evidence are recorded in
-[VALIDATION.md](VALIDATION.md). Local bootstrap has no GitHub Actions provenance;
-the automated development artifact does.
-
-The workflow rejects private packages and missing license metadata. Explicit
-rc/stable releases also require matching tags, prerelease flags and dated
-changelog entries. Passing metadata validation does not establish live-service
-verification. Enabling automatic dev publication authorizes eligible develop
-pushes to publish after CI; rc/stable publication remains an explicit action.
+The first stable version, `0.1.0`, was published on 2026-09-19 through
+[GitHub Release v0.1.0](https://github.com/lambdadb/lambdadb-cli/releases/tag/v0.1.0)
+and the [OIDC release workflow](https://github.com/lambdadb/lambdadb-cli/actions/runs/35421226854).
+Tag and main release commit `c8d389f` have the same tree as the reviewed and
+live-tested candidate `658ea7c`. The workflow passed on attempt 1, including Node
+22/24 validation and tests of the exact publication tarball.
+
+Registry verification confirmed `latest=0.1.0` and `dev=0.1.0-dev.5`. A clean,
+unqualified npm install passed all 35 CLI contracts, version/help, integrity,
+provenance and signature checks. Version/tag and attestation metadata propagated
+separately; verification used read retries without republishing.
+
+The post-release synchronization brings main history back into develop with
+`0.1.1-dev.1` as the next development base. Its promotion PR must preserve shared
+ancestry with a merge commit. Once merged, the normal develop push workflow
+publishes a numbered `0.1.1-dev.N` build on `dev`; it does not move `latest`.
+No separate stable release or tag is needed for this maintenance step.
+
+Bootstrap `0.1.0-dev.1` and the first OIDC development builds were verified on
+2026-09-18. The ordinary develop merge published `0.1.0-dev.5` in
+[one successful attempt](https://github.com/lambdadb/lambdadb-cli/actions/runs/35344153978),
+handling approximately three minutes of registry propagation without another write.
+The bootstrap initially assigned `latest` to `0.1.0-dev.1`, and a removal attempt
+returned HTTP 400. The stable publication replaces that temporary tag state.
+Do not repeat bootstrap or change tags to work around propagation delays.
+
+These are dated validation milestones, not a continuously updated version list.
+Check npm for current dist-tags. Apache-2.0 licensing, publication, provenance,
+consumer checks and development-project smoke evidence are recorded in
+[VALIDATION.md](VALIDATION.md). Automatic dev publication is enabled;
+future stable/rc tags and GitHub Releases remain explicit release actions.
 
 ## Branch and version policy
 
@@ -264,6 +252,16 @@ live behavior, or exactly-once writes. A large result alone does not prove the
 service selected docsUrl; mock tests explicitly exercise that transport path.
 Use existing known development tag/alias refs for additional live ref evidence.
 
+## Homebrew handoff
+
+The stable formula is maintained in `packaging/homebrew/Formula/lambdadb-cli.rb`.
+It consumes the verified npm artifact and the lockfile from its immutable release
+commit. Development publication does not update Homebrew. After each stable npm
+release, follow the [Homebrew maintainer guide](https://github.com/lambdadb/lambdadb-cli/tree/develop/packaging/homebrew#readme) to
+update checksums, pass installation checks and prepare a tap PR. Tap publication
+is separate from this repository's npm workflow; no cross-repository write or
+automatic tap update is configured. The public tap has not been published yet.
+
 ## Design references
 
 - LambdaDB TypeScript client `RELEASING.md` and `publish.yaml`: canonical channels,

package/VALIDATION.md

@@ -1,14 +1,75 @@
 # Validation record
 
-Date: 2026-09-18. Local contract tests use loopback servers and synthetic
+Updated: 2026-09-19. Local contract tests use loopback servers and synthetic
 credentials. A separate authenticated development-project smoke is recorded below.
 
+## Homebrew preparation
+
+On 2026-09-19, macOS 26.4 arm64 / Homebrew 6.0.17 installed stable `0.1.0`
+from `packaging/homebrew/Formula/lambdadb-cli.rb` through a disposable local tap.
+The npm tarball SHA-256 was checked against the downloaded bytes, whose SHA-512
+matched registry integrity. The release lockfile resource is fixed to `c8d389f`.
+
+- Homebrew formula style, installation and `brew test` passed. The formula checks
+  CLI version, JSON configuration and mode 0600 without contacting a service.
+- A deliberately unusable `node` placed first on ambient PATH did not prevent
+  the installed wrapper from running; it selected Homebrew's Node 24.21.0.
+- All 35 CLI contracts from the stable release commit passed against the installed
+  Homebrew package. The harness uses the release commit's tests/examples so future
+  development-only features do not create false failures for an older stable CLI.
+- Simulated existing-formula and broken-executable-symlink cases both stopped the
+  harness before any installation or tap mutation.
+- The temporary CLI installation and tap were removed. The final harness disables
+  automatic dependency removal and cleanup, and does not persist developer mode.
+  Homebrew dependencies/caches remain: installing Node also upgraded the required
+  ca-certificates, openssl@3, readline, sqlite and xz packages during initial setup.
+  The existing fnm-managed Node and global npm CLI were not replaced.
+- Normal clean-install, lint, version/type checks, 59 source tests and 35 npm
+  installed-package contracts also passed. CLI runtime and SDK dependencies did
+  not change.
+
+macOS/Linux Homebrew CI is configured separately from runtime CI; current PR job
+results are the authority for hosted-runner coverage. No public tap repository
+was created and installation from a public tap remains unverified. No new npm
+version was published by this work. LambdaDB service smoke was not repeated for
+this packaging-only change; the stable candidate evidence below remains separate.
+
+## Stable 0.1.0 publication
+
+On 2026-09-19, [GitHub Release v0.1.0](https://github.com/lambdadb/lambdadb-cli/releases/tag/v0.1.0)
+and its annotated tag identified main commit
+`c8d389f3264d641ae6eafc7737fedd5ea046ddf1`. Its tree exactly matches the reviewed
+candidate `658ea7ccdce535bbd4f2e29ae06813e2f2e716e2` from PR #5, including the
+runtime verified by the installed-candidate development smoke below. That smoke
+was not repeated because release contents were unchanged.
+
+The [release-event workflow](https://github.com/lambdadb/lambdadb-cli/actions/runs/35421226854)
+passed on attempt 1. Node 22/24 validation and exact-tarball contracts passed;
+Trusted Publishing published `0.1.0` on `latest` at 04:27:06 UTC. Version/tag
+metadata and attestation metadata propagated separately. Verification retried
+reads only; no second publication or workflow rerun was needed.
+
+A clean, unqualified npm install with an isolated cache resolved to `0.1.0` and
+passed version/help plus all 35 CLI contract tests. The downloaded tarball digest,
+installed lockfile integrity and provenance subject matched. The decoded SLSA
+provenance identified this repository, `.github/workflows/publish.yaml`,
+`refs/tags/v0.1.0`, release commit `c8d389f` and workflow attempt 1.
+`npm audit signatures` reported no invalid or missing signatures.
+At verification, `latest=0.1.0` and `dev=0.1.0-dev.5`; the stable release replaced
+the initial bootstrap latest tag without changing the dev channel.
+
+The subsequent main-to-develop synchronization sets `0.1.1-dev.1` as the next
+base. Its local clean install, lint, types, version checks, 59 source tests and
+35 installed-package contracts passed. This maintenance change updates versions
+and documentation only; CLI runtime, dependencies, tests and workflows match
+`v0.1.0`. Its PR validation does not itself publish a new dev version.
+
 ## Stable 0.1.0 candidate
 
 Prepared `release/0.1.0` from reviewed develop commit
 `c8947e96308283ac593e712716f0732121bb1958`. Relative to that commit, only package
 versions and release documents change. Runtime source, dependencies, tests,
-examples and workflows are unchanged. Stable publication remains pending.
+examples and workflows are unchanged. This records the pre-publication candidate.
 
 On Node.js 24.15.0 / npm 11.12.1, a new worktree passed `npm ci`, lint, type
 checking, all 59 source tests, and 35 installed-package contract tests.
@@ -38,8 +99,8 @@ Target: `bench-recall` at
 Only documentation was updated after this live run; the final package is checked
 again with the installed-package contracts. This is development-service evidence
 for a bounded sample, not a latency/readiness guarantee or live tag/alias coverage.
-The stable npm artifact and release-event workflow remain unverified until the
-explicit publication and subsequent consumer/provenance checks.
+The stable npm artifact and release-event workflow were not verified at candidate
+preparation time; the subsequent publication evidence is recorded above.
 
 ## Public bootstrap and OIDC publication
 
@@ -74,7 +135,8 @@ At this verification, `dev=0.1.0-dev.4` and `latest=0.1.0-dev.1`. Bootstrap had
 created both tags despite `--tag dev`; a removal attempt for `latest` returned
 HTTP 400. The automated dev publication left `latest` unchanged. This observation
 does not establish a general version-count rule for npm. Bootstrap and OIDC setup
-are complete; main promotion and rc/stable publication remain unperformed.
+were complete at that stage; main promotion and stable publication followed as
+recorded above.
 
 ## Publication verification hardening
 
@@ -298,9 +360,6 @@ deployment state of an individual LambdaDB endpoint.
   receipt. Those capabilities are not implemented.
 - No Windows-specific permission or signal validation. POSIX modes and injected
   SIGINT/SIGTERM were checked on macOS; CI targets Linux.
-- No main promotion, explicit rc/stable publication or GitHub Release workflow
-  execution. Public bootstrap and automatic dev/OIDC publication are verified
-  above, including the five-minute verification behavior on an ordinary develop merge.
 - Mock large-response tests cover SDK routing/credential separation at 1 MiB;
   the live sample verifies combined content above 6 MiB. Neither is an exhaustive
   memory/size stress test. Imports buffer a maximum 64 MiB source file

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@functional-systems/lambdadb-cli",
-  "version": "0.1.0",
+  "version": "0.1.1-dev.7",
   "private": false,
   "description": "Project-scoped LambdaDB command-line tools",
   "type": "module",
@@ -52,5 +52,6 @@
   "bugs": {
     "url": "https://github.com/lambdadb/lambdadb-cli/issues"
   },
-  "license": "Apache-2.0"
+  "license": "Apache-2.0",
+  "gitHead": "3eefaaae29defacc80b1921aa31deace42f07afd"
 }