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

package/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 ## [Unreleased]
 
+### 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
+
+- First stable release of the project-scoped LambdaDB CLI: configure, doctor,
+  collection list/describe/create, JSONL ordinary/bulk import, query and ID fetch.
+- Explicit branch/tag/alias read targets, noninteractive commands, versioned JSON
+  output and documented exit codes, including partial and unknown write outcomes.
+- Reuse of TypeScript SDK 0.5.1 for authentication, transport, read retries,
+  pagination, bulk transfers and large response downloads.
+- Apache-2.0 licensing, installed-package contract tests, opt-in development-project
+  smoke tests and provenance-enabled npm publication.
+
 ### Fixed
 
 - Development publication verifies registry propagation for up to five minutes,

package/CONTRIBUTING.md

@@ -14,9 +14,6 @@ not LambdaDB collection branches or refs.
 4. Address review feedback and pass both required CI checks before merging.
 5. Delete the short-lived branch after verifying the merge.
 
-For the initial MVP, `feat/cli-mvp` targets the initial `develop` commit. The
-review includes the CLI implementation, tests, documentation and CI setup.
-
 ## Local and CI validation
 
 ```sh
@@ -67,8 +64,11 @@ commit so the shared branch ancestry is preserved. After promotion, synchronize
 `develop`, especially release-only changes or hotfixes. Include the next intended
 development base in that synchronization PR so develop retains a dev version.
 
-A separate `release/*` branch is optional when stabilization must proceed while
-new work continues on `develop`. It is not required for the initial release.
+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 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.
 
 The first npm bootstrap, rc/stable tags and GitHub Releases remain explicit
 release actions. Subsequent dev publication is automatic once enabled.

package/README.md

@@ -10,17 +10,19 @@ Requires Node.js 22.14 or newer and npm.
 
 ### Install from npm
 
-After the first development version is published, install 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
 ```
 
-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
+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.
 
 ### Build from source

package/RELEASING.md

@@ -2,33 +2,37 @@
 
 ## Current status
 
-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
 

package/VALIDATION.md

@@ -1,8 +1,76 @@
 # 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.
 
+## 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. 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.
+`RELEASE_TAG=v0.1.0 RELEASE_PRERELEASE=false npm run check:version -- --release`
+passed and selected `latest`. CI results for the final commit belong to the
+promotion PR; local success is not a substitute for those required checks.
+
+A newly packed `0.1.0` tarball was installed into an isolated temporary consumer.
+Its executable reported `0.1.0` and was selected with `LAMBDADB_TEST_CLI` while
+running `node --test --test-reporter=tap test/live/cli.test.mjs`. The launcher used
+the maintainer's existing opt-in development settings and the in-memory variable
+mapping described below; it did not change or copy `.env.local` into the worktree.
+Target: `bench-recall` at
+`https://internal-dev-aws-apne2-v3-c05a2b5d492a.lambdadb.ai`.
+
+- Doctor and temporary collection creation passed within the first second.
+- Two ordinary documents with 3 MiB payloads each and one bulk document were
+  accepted at approximately 3 seconds. Acceptance did not imply search visibility.
+- Query and ID fetch on `branch:main` returned all three documents with exact
+  contents at approximately 69 seconds, without a pending-write overlay.
+- The live test passed in 69.6 seconds. Cleanup was accepted, then an independent
+  SDK get returned `ResourceNotFoundError` for
+  `cli-smoke-b854ef72-1448-42ae-8c9a-ce5c0441f104`, confirming its absence.
+- The source `.env.local` was byte-for-byte unchanged, and the temporary consumer
+  and tarball were removed. No key or signed URL is recorded here.
+
+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 were not verified at candidate
+preparation time; the subsequent publication evidence is recorded above.
+
 ## Public bootstrap and OIDC publication
 
 On 2026-09-18, the maintainer authorized the public bootstrap
@@ -36,7 +104,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
 
@@ -57,11 +126,18 @@ A read-only probe used the actual npm CLI and new bounded-read flags to verify
 the existing `0.1.0-dev.4` manifest/tag. Only its preflight and accepted write were
 simulated; the probe performed no registry mutation.
 
-The changed publication path has not yet run on an actual develop merge; PR CI
-cannot publish. The next reviewed merge must verify the normal push-to-publication
-flow without a manual rerun. The LambdaDB live smoke was not rerun because CLI
-runtime source is unchanged; the prior development-project evidence below remains
-separate from npm checks.
+The [ordinary develop merge workflow](https://github.com/lambdadb/lambdadb-cli/actions/runs/35344153978)
+published `0.1.0-dev.5` from `c8947e96308283ac593e712716f0732121bb1958`
+on attempt 1. Node 22/24 validation and exact-artifact tests passed. Publication
+succeeded at 12:22:09 UTC; registry verification completed at 12:25:10 UTC with
+`result=published`. The approximately 181-second propagation delay required only
+read retries, with no manual rerun or repeated publication.
+
+A fresh npm `@dev` install with an isolated cache passed all 35 CLI contract tests,
+version/help, tarball/lockfile integrity checks and npm signature verification.
+Provenance identified the expected repository, develop ref, workflow, source
+commit and attempt 1. `dev=0.1.0-dev.5`; `latest` remained `0.1.0-dev.1`.
+These registry checks are separate from the development-service smoke below.
 
 ## Initial local automation validation (before publication)
 
@@ -253,9 +329,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; the new five-minute verification behavior awaits its first 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-dev.5",
+  "version": "0.1.1-dev.6",
   "private": false,
   "description": "Project-scoped LambdaDB command-line tools",
   "type": "module",
@@ -53,5 +53,5 @@
     "url": "https://github.com/lambdadb/lambdadb-cli/issues"
   },
   "license": "Apache-2.0",
-  "gitHead": "c8947e96308283ac593e712716f0732121bb1958"
+  "gitHead": "397fbfbe6977fbd4fbb3977eca73887a4899d564"
 }