@git.zone/cli 3.2.1 → 5.0.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@git.zone/cli",
   "private": false,
-  "version": "3.2.1",
+  "version": "5.0.0",
   "description": "A comprehensive CLI tool for enhancing and managing local development workflows with gitzone utilities, focusing on project setup, version control, code formatting, and template management.",
   "main": "dist_ts/index.js",
   "typings": "dist_ts/index.d.ts",
@@ -41,15 +41,17 @@
   "devDependencies": {
     "@git.zone/tsbuild": "^4.4.2",
     "@git.zone/tsrun": "^2.0.6",
-    "@git.zone/tstest": "^3.6.7",
-    "@types/node": "^26.1.1"
+    "@git.zone/tstest": "^4.0.0",
+    "@types/node": "^26.2.0"
   },
   "dependencies": {
+    "@aws-sdk/client-s3": "3.1095.0",
     "@git.zone/tsdoc": "^2.1.1",
     "@git.zone/tspublish": "^1.11.7",
     "@push.rocks/commitinfo": "^1.0.13",
     "@push.rocks/early": "^4.0.4",
     "@push.rocks/projectinfo": "^5.1.0",
+    "@push.rocks/smartbucket": "4.13.0",
     "@push.rocks/smartcli": "^4.0.20",
     "@push.rocks/smartconfig": "^6.0.1",
     "@push.rocks/smartdelay": "^3.0.5",
@@ -76,6 +78,7 @@
   },
   "files": [
     "ts/**/*",
+    "ts_migration/**/*",
     "ts_web/**/*",
     "dist/**/*",
     "dist_*/**/*",

package/readme.hints.md

@@ -161,19 +161,22 @@ Known remaining gaps are listed in `readme.plan.md`.
 
 ### Why data accumulated
 
-`gitzone services clean` never actually worked for MongoDB or MinIO. Service
-containers write as their own uid — mongod as 999 with `drwx------` on
-subdirectories, MinIO as root under `.minio.sys` — so a recursive delete run as
-the invoking user removed only the part of the tree it owned. For MongoDB the
-result was a half-deleted WiredTiger dataset that crash-looped on the next start
-(`WiredTigerHS.wt file is corrupted or missing`), kept alive indefinitely by
-`restart: unless-stopped`. Users hit a failing `clean`, gave up, and the data
-stayed. This was the root cause of multi-GB accumulation, not a missing feature.
-
-`DockerContainer.removeDataDirectory` fixes it: try a native delete, and if the
-directory survives, empty it from a short-lived `--user 0` container that mounts
-only that directory. It verifies the directory is gone and throws otherwise — a
-partial delete is worse than no delete.
+`gitzone services clean` historically failed for service data written by a
+container uid. A recursive delete run as the invoking user removed only the
+part of the tree it owned. For MongoDB the result was a half-deleted WiredTiger
+dataset that crash-looped on the next start (`WiredTigerHS.wt file is corrupted
+or missing`), kept alive indefinitely by `restart: unless-stopped`. Users hit a
+failing `clean`, gave up, and the data stayed. This was the root cause of
+multi-GB accumulation, not a missing feature.
+
+`DockerContainer.removeDataDirectory` fixes it by persisting a deletion intent
+and atomically renaming the canonical path to a tokenized quarantine before any
+recursive delete. Native deletion runs there; if the quarantine survives, a
+short-lived root container mounts only that directory. The helper uses
+shell-free Docker argv, stopped creation, exact configuration and label
+inspection, and an immutable-ID fence before execution or cleanup. Interrupted
+cleanup resumes the recorded quarantine, so partial work is never mistaken for
+a usable canonical dataset.
 
 ### Identifying tool-owned resources
 
@@ -182,7 +185,7 @@ Follows the `git.zone.*` label convention already established by
 
 ```text
 git.zone.tool=gitzone-services
-git.zone.service=mongodb|minio|elasticsearch
+git.zone.service=mongodb|objectstorage|elasticsearch
 git.zone.project-path=<abs path>
 git.zone.data-path=<abs path>
 git.zone.safe-to-prune=true
@@ -190,11 +193,12 @@ git.zone.safe-to-prune=true
 
 Data directories are additionally claimed by a marker at
 `<project>/.nogit/.gitzone-services.json`. The marker deliberately lives outside
-the bind-mounted directory so it can never confuse mongod, MinIO or
+the bind-mounted directory so it can never confuse mongod, ObjectStorage or
 Elasticsearch at runtime.
 
-Nothing is ever matched by image or by bare name pattern. Containers predating
-labels are only identified when exactly one registry entry claims their name.
+Nothing is ever matched by image or by bare name pattern. MongoDB and
+Elasticsearch containers predating labels are identified only when exactly one
+registry entry claims their name. ObjectStorage always requires exact labels.
 
 ### Prune safety model (`classes.servicepruner.ts`)
 
@@ -212,13 +216,86 @@ Invariants, enforced at plan time and again at apply time:
 
 - A data directory is never removed while any running container bind-mounts it
   or an overlapping path (`helpers.pathsOverlap`).
-- A path must match `<project>/.nogit/{mongodata,miniodata,esdata}` exactly
+- A path must match `<project>/.nogit/{mongodata,objectstoragedata,esdata}` exactly
   (`isSafeServiceDataPath`); this is an allowlist, checked after resolution.
-- Ownership must be proven by marker or registry entry.
-- Staleness is re-checked at apply time, so a project started between plan and
-  apply aborts the removal.
-- An unreachable Docker daemon disables all container and data reclamation, so
-  ambiguity never reads as absence.
+- Ownership must be proven by marker or registry entry. ObjectStorage is
+  stricter: an exact marker entry is required for deletion, but an exactly
+  label-owned canonical container can repair a missing marker before removal.
+- Data-directory staleness is re-checked at apply time. Container removal
+  separately rechecks immutable identity, running state, ownership, and legacy
+  classification before mutation.
+- An unreachable Docker daemon disables container, data, and registry
+  reclamation, so ambiguity never reads as absence.
+
+Legacy `.nogit/miniodata` is deliberately outside the allowlist. Marker
+migration retains that path with `safeToPrune: false`; registry migration
+retains the legacy container reference separately. The service and general
+Docker pruners reject legacy MinIO containers, and service prune rejects
+bind-operation helpers again at apply time.
+
+### ObjectStorage migration and lifecycle
+
+`objectstorage` is the canonical service identifier and `s3` is its user-facing
+alias. Persisted `minio` and `s3` entries migrate to the same canonical flat
+array value because `@git.zone/cli.services` remains a tsdeploy capability
+input. New CLI input does not accept the provider name `minio`.
+
+The active container is `<project>-objectstorage`, its data path is
+`.nogit/objectstoragedata`, and its image is pinned by manifest-list digest.
+Ports `9000` and `3000` are published as the configured API and UI ports on
+`127.0.0.1`. `S3_ADMIN_PASSWORD`, `S3_REGION`, and `S3_UI_PORT` are
+ObjectStorage-specific runtime fields. Existing generic fields such as
+`S3_ENDPOINT`, `S3_HOST`, and `S3_USESSL` are preserved rather than silently
+rewritten; internal reconciliation always targets loopback explicitly.
+
+Startup first rejects legacy `<project>-minio` containers, registry-retained
+alternate legacy names, and `.nogit/miniodata`, then proves exact labels on any
+canonical same-name container. Exact container proof can repair a missing valid
+data marker; invalid or foreign markers remain blocking. Drift reconciliation
+covers the complete runtime contract, including
+the exact set of `OBJST_*` and `UI_PORT` controls while allowing unrelated image
+environment, and all subsequent Docker mutations use the discovered immutable
+ID. A shared 30-second deadline bounds Docker setup, `/readyz`, authenticated
+bucket lookup/creation, and verification. SmartBucket provides its own bounded,
+idempotent client cleanup. A pre-existing ID enters rollback only after `docker
+start` succeeds; an uncertain pre-existing start remains adoptable because
+state inspection cannot prove which concurrent invocation caused the transition.
+
+The v2 marker and global registry schemas separate canonical ObjectStorage from
+legacy MinIO evidence. Legacy evidence is detection-only: never activate it,
+reinterpret its disk data, pass it to lifecycle methods, or make it reclaimable.
+Migration validates every selected store before the first write, then revalidates
+each store at its own apply boundary. Closed-schema selection, marker, and
+registry state rejects malformed, foreign, conflicting, or future shapes.
+Runtime config validates known fields while preserving unknown fields. The
+global registry uses a shared atomic-mkdir transaction lock, fresh raw reads,
+fsynced same-directory
+replacement writes, and compare-delete for unregister operations. Lock ownership
+is token-checked and release first renames to an invocation tombstone. Stale locks
+are never broken automatically; the error reports the exact lock path for manual
+inspection after the recorded process is known to be gone.
+
+The same lock primitive protects runtime-config migration and saves, marker
+migration and ownership recording, and each service's start/delete data-path
+critical section. Runtime config saves compare the bytes loaded by that instance
+with the current file before replacement, so a stale command cannot overwrite a
+newer port or credential change. Marker writers re-read inside the lock and merge
+claims. Start and stop refresh config inside a global per-project/service lock.
+Data deletion rechecks labeled stopped containers and all configured mounts
+inside that lock; a preserved stopped container blocks its project's data from
+becoming reclaimable. Before recursive deletion, an exact persisted intent
+atomically moves the canonical directory to a tokenized quarantine. Interrupted
+or partial cleanup resumes only that recorded path and cannot leave a corrupt
+canonical dataset. Every service startup rejects a pending deletion intent so a
+fresh canonical directory cannot strand quarantined data.
+
+Bind-operation helpers use one deterministic Docker name per host target as an
+atomic helper-level lock. Each create adds a random invocation label and a
+stable ownership-spec label. Uncertain creates are polled within the rollback
+deadline and may be removed only when the invocation label matches. A later
+operation may remove an old stopped canonical helper by non-forced immutable-ID
+removal; fresh, running, or noncanonical occupants fail closed. This lock covers
+the root helper operations, not the entire service start/clean command.
 
 ### MongoDB auth modes
 
@@ -389,8 +466,8 @@ The project has been fully migrated from @push.rocks/smartfile v11 to v13, which
 
 **Packages:**
 
-- `@push.rocks/smartfile` v13.0.1 - File representation classes (SmartFile, StreamFile, VirtualDirectory)
-- `@push.rocks/smartfs` v1.1.0 - Filesystem operations (read, write, exists, stat, etc.)
+- `@push.rocks/smartfile` v13.1.3 - File representation classes (SmartFile, StreamFile, VirtualDirectory)
+- `@push.rocks/smartfs` v1.6.0 - Filesystem operations (read, write, exists, stat, etc.)
 
 **Key API Changes:**
 

package/readme.md

@@ -56,7 +56,7 @@ gitzone release
 | `release` | Turn pending changelog entries into a versioned release and publish targets |
 | `format` | Plan or apply project formatting and standardization |
 | `config` | Inspect, update, and migrate `.smartconfig.json` |
-| `services` | Manage local MongoDB, MinIO, and Elasticsearch containers |
+| `services` | Manage local MongoDB, ObjectStorage, and Elasticsearch containers |
 | `tools` | Manage the global `@git.zone` toolchain |
 | `template` | Scaffold projects from built-in templates |
 | `meta` | Manage multi-repository workspaces |
@@ -133,23 +133,28 @@ Commit flags:
 
 ## Release Workflow
 
-`gitzone release` performs the release core once, then publishes to configured targets.
+`gitzone release` releases from `main`. Running it on another branch fails before release metadata or ref mutation unless the bare `--merge` flag is explicitly supplied.
+
+`--merge` is intentionally strict: the source and existing `main` worktree must be clean, the source must be linearly rebased onto current remote `main`, and the Git target must push both the branch and tag. GitZone pins the single configured push URL, compare-and-swap fast-forwards local `main`, updates its verified worktree, and lease-pushes that exact source commit before creating release metadata. It rejects diverged or merged history, local replacement refs or grafts, stale worktrees, incomplete shallow history, changed destinations, and remote races. If the pre-release push fails, GitZone restores local `main` only when doing so cannot overwrite concurrent work. This plumbing-level integration intentionally does not run merge hooks or write `ORIG_HEAD`.
+
+`gitzone release` performs the release core once, then publishes to configured targets. An active Git target must succeed before npm or Docker publication can start.
 
 The release core is not configurable plumbing. It always follows the same professional release transaction:
 
-1. Run configured preflight checks.
-2. Read `changelog.md` `## Pending` entries.
-3. Infer or accept a semver bump.
-4. Update version files and baked commit info.
-5. Move pending changelog entries into the new version section.
-6. Create the local release commit.
-7. Create the local release tag.
+1. Verify the release branch, clean state, and `main` worktree ownership.
+2. Read `changelog.md` `## Pending` entries and infer or accept a semver bump.
+3. Run configured tests.
+4. With `--merge`, fast-forward and lease-push `main` before release metadata is created.
+5. Update version files and baked commit info.
+6. Move pending changelog entries into the new version section.
+7. Create the local release commit and tag on `main`.
+8. Run the configured release build, require a clean tree, and revalidate the release checkout.
 
 Targets decide what happens after that:
 
 | Target | What it does |
 | --- | --- |
-| `git` | Pushes the release commit and tags, often triggering remote CI release builds |
+| `git` | Atomically pushes the exact `main` release commit and new tag, often triggering remote CI release builds |
 | `npm` | Publishes the package to configured npm registries |
 | `docker` | Delegates container builds and pushes to `tsdocker` |
 
@@ -160,6 +165,9 @@ gitzone release --plan
 # Release to configured targets
 gitzone release
 
+# From a clean feature branch already rebased onto current main
+gitzone release --merge
+
 # Release only to npm
 gitzone release --target npm
 
@@ -179,15 +187,16 @@ Release flags:
 | --- | --- |
 | `-y`, `--yes` | Run without interactive confirmation |
 | `-t`, `--test` | Enable preflight tests |
-| `-b`, `--build` | Enable preflight build |
+| `-b`, `--build` | Enable the release build after local release metadata is created |
 | `-p`, `--push` | Enable the `git` target |
 | `--target <csv>` | Use only selected targets, e.g. `git,npm` |
 | `--npm` | Enable the `npm` target |
 | `--docker` | Enable the `docker` target |
 | `--no-publish` | Keep release core and `git` target only |
-| `--no-build` | Disable preflight build for this run |
+| `--no-build` | Disable the post-metadata release build for this run |
+| `--merge` | Fast-forward and lease-push a cleanly rebased feature branch into `main`, then release from `main` |
 | `--major`, `--minor`, `--patch` | Override inferred semver level |
-| `--plan` | Show resolved workflow only |
+| `--plan` | Show the resolved workflow without fetching or mutating refs, files, the index, or worktrees |
 
 ## Standard Changelog
 
@@ -223,7 +232,6 @@ CLI workflow config lives under `@git.zone/cli` in `.smartconfig.json`. Docker b
     "release": {
       "confirmation": "prompt",
       "preflight": {
-        "requireCleanTree": true,
         "test": false,
         "build": true
       },
@@ -452,18 +460,21 @@ Formatters include cleanup, smartconfig normalization, dependency license checks
 
 Supported services:
 
-| Service | Aliases |
+| Service | Lifecycle/log aliases |
 | --- | --- |
 | MongoDB | `mongo`, `mongodb` |
-| MinIO | `minio`, `s3` |
+| ObjectStorage (S3-compatible) | `objectstorage`, `s3` |
 | Elasticsearch | `elasticsearch`, `es` |
 
+Service-selection commands such as `set`, `enable`, and `disable` also accept
+`elastic`; lifecycle and log commands do not.
+
 ```bash
 # Start configured services
 gitzone services start
 
 # Enable specific services non-interactively
-gitzone services set mongodb,minio
+gitzone services set mongodb,objectstorage
 
 # Check status
 gitzone services status
@@ -478,21 +489,81 @@ gitzone services compass
 gitzone services logs mongo 50
 ```
 
-Service config is stored in `.nogit/env.json`. Data is stored below `.nogit/`, so it stays out of Git.
-
-GitZone derives new MinIO bucket names from the project name using S3 naming
-rules. When loading older configuration it repairs only the exact generated
+Service config is stored in `.nogit/env.json`. Newly created config files use
+owner-only permissions; writes are atomic and reject a stale in-memory snapshot
+rather than overwriting a concurrent change. MongoDB, ObjectStorage, and
+Elasticsearch data is stored in `.nogit/mongodata`,
+`.nogit/objectstoragedata`, and `.nogit/esdata`, so it stays out of Git.
+
+ObjectStorage uses `S3_PORT` for its local S3 API and `S3_UI_PORT` for its
+management UI. `S3_REGION` defaults to `us-east-1`; `S3_ADMIN_PASSWORD` is a
+separate randomly generated password for the UI's `admin` user. Startup rejects
+empty credentials, `admin`/`admin` S3 defaults, the default admin password, and
+an admin password reused as either S3 credential. `gitzone services config
+--json` replaces those three ObjectStorage credential values with `"***"`.
+Other fields are unchanged, including MongoDB and Elasticsearch passwords and
+credential-bearing URLs, so the complete output must still be treated as
+sensitive.
+
+GitZone runs a digest-pinned ObjectStorage image with both the S3 API and
+management UI published on loopback. `S3_HOST`, `S3_ENDPOINT`, `S3_USESSL`, and
+the other generic S3 consumer fields remain user-controlled; service startup
+always reconciles the local managed instance through `127.0.0.1` and its
+configured local ports.
+
+GitZone derives new bucket names from the project name using S3 naming rules.
+When loading older configuration it repairs only the exact generated
 `<project>-documents` value if that value is invalid; custom bucket names are
-never rewritten. `services start minio` validates custom names, recreates a
-container whose configured credentials or ports drifted, authenticates the
-configured alias, creates the bucket idempotently, and verifies it before
-reporting success. Before GitZone starts, recreates, or executes inside an
-existing MinIO container, current-project ownership must be proven by exact
-GitZone labels or one unambiguous legacy registry claim. Every lifecycle
-operation after discovery uses the container's immutable id. If startup fails,
-GitZone stops only containers that this invocation started; it never stops a
-container that was already running. Invalid custom names do not block read-only
-or recovery commands such as `status`, `logs`, `stop`, `remove`, and `clean`.
+never rewritten. `services start s3` validates the bucket and credentials,
+recreates an owned container when its pinned image, ports, data bind, controlled
+product environment, restart policy, command, entrypoint, user, or health check
+drifted, waits for management readiness, then creates and verifies the bucket
+through an authenticated S3 client. A GitZone-label mismatch is an ownership
+conflict and blocks mutation rather than being treated as repairable drift.
+Container setup, management readiness, and the S3 operations share one deadline;
+SmartBucket cleanup has its own bounded close. Docker mutations use the
+container's immutable ID after exact-name discovery.
+On failure, GitZone stops a pre-existing container only after that invocation's
+start returned successfully. A newly created ID remains invocation-owned across
+an uncertain start and can be stopped safely; an uncertain pre-existing start is
+left adoptable rather than risking stopping another concurrent invocation. A
+canonical container created but not yet started remains stopped for a safe retry.
+
+### Migrating legacy MinIO state
+
+Persisted `minio` and `s3` service selections are rewritten to the canonical
+`objectstorage` value. `S3_CONSOLE_PORT` is migrated to `S3_UI_PORT` when the
+values do not conflict. The runtime migration also adds the separate admin
+password and region fields and repairs only the exact invalid bucket name that
+older GitZone versions generated. Legacy registry and data-marker entries are
+retained as preserved migration evidence, not converted into active
+ObjectStorage ownership. Every selected migration store is preflighted before
+the first write. Closed-schema service selection, marker, and registry stores
+reject malformed, conflicting, foreign, or future state without rewriting it.
+Runtime config validates and migrates its known fields while preserving unknown
+application fields.
+
+If `<project>-minio`, a registry-retained alternate legacy container name, or
+`.nogit/miniodata` still exists, ObjectStorage startup stops before mutating the
+ObjectStorage container. In an untargeted `services start`, an earlier enabled
+service such as MongoDB may already have started. GitZone never reuses, removes,
+cleans, or prunes legacy MinIO state because its disk layout is not compatible
+with ObjectStorage. Recovery is explicit:
+
+1. Export every required bucket with the existing MinIO tooling.
+2. Stop and rename the legacy container, then move `.nogit/miniodata` to a preserved backup location.
+3. Run `gitzone services start s3` to create the canonical service.
+4. Import through an external S3 client and verify the required objects before disposing of the backup.
+
+An existing `.nogit/objectstoragedata` directory without a valid ownership
+marker blocks creation of a new container and direct cleanup. One exception is
+an existing container whose immutable identity and exact canonical GitZone
+labels prove that directory belongs to this project; startup or removal repairs
+the missing marker before proceeding. An invalid or foreign marker always
+blocks mutation. Without that exact container proof, preserve or move the
+directory, verify its provenance outside GitZone, start a fresh canonical
+service, and import required objects through S3. Do not synthesize a marker for
+unverified data.
 
 ### Consuming a service programmatically
 
@@ -503,6 +574,13 @@ script can read a live connection string without parsing human output:
 gitzone services status --json | jq -r '.services.mongodb.connectionString'
 ```
 
+The ObjectStorage status key is `.services.objectstorage`; the former
+`.services.minio` key no longer exists. Preserved predecessor evidence is
+reported separately under `.legacy`. `minioDataDirectory` and `minioDataExists`
+are always emitted; `minioContainer` is present only when container evidence
+exists. Consumers must treat this as a breaking response-schema change rather
+than interpreting legacy evidence as an active service.
+
 ### Cleanup levels
 
 Cleanup is tiered, from fully resumable to irreversible:
@@ -514,10 +592,26 @@ Cleanup is tiered, from fully resumable to irreversible:
 | `gitzone services clean` | removed | **removed** | irreversible; needs a typed `yes` or `--yes` |
 | `gitzone services prune` | see below | see below | machine-wide; dry run unless `--apply` |
 
-`clean` and `prune` remove data written by the container user (mongod runs as
-uid 999, MinIO as root) by escalating to a short-lived privileged container
-scoped to that one directory. They either remove a directory completely or fail
-— a partial delete would leave a corrupt database behind.
+`clean` and `prune` first persist an exact deletion intent, then atomically rename
+the canonical directory to a tokenized sibling quarantine before deleting any
+contents. Native deletion is attempted there. If container-owned files remain,
+GitZone uses a short-lived root container scoped to that quarantine; Docker's
+`--privileged` mode is not used. The helper reserves one deterministic name per
+bind target, carries a random invocation label, is created stopped, and is
+inspected by immutable ID before execution or cleanup. Old stopped helpers can
+be recovered only after their complete runtime envelope, bind target, age, and
+immutable ID are proven; running, fresh, or noncanonical occupants block the
+operation. If interruption or helper failure leaves bytes, the persisted intent
+lets the next `clean` or `prune --apply` resume the same quarantine. A partial
+failure therefore never leaves a corrupt directory at the canonical service
+path. Startup refuses to create fresh service data while such an intent remains.
+
+Service start, stop, container removal, and data removal share one interprocess
+lock per project and service. Startup refreshes runtime config and project
+activity inside that lock, while prune rechecks activity and stopped as well as
+running service containers after acquiring it. Concurrent lifecycle commands
+therefore serialize rather than deleting a directory or container while another
+command prepares, mounts, starts, or stops it.
 
 ### Reclaiming space across projects
 
@@ -541,9 +635,18 @@ with: its directory is gone, or it has been inactive past the threshold with no
 container running. Anything ambiguous — an unlabeled container claimed by more
 than one project, an unreachable Docker daemon, a directory still mounted by a
 running container — is reported and skipped rather than reclaimed. Containers
-are identified by the `git.zone.tool=gitzone-services` label or by an
-unambiguous registry claim, never by image or name pattern, so pruning cannot
-touch containers created by anything else.
+are identified by an exact canonical GitZone label envelope. An unambiguous
+registry claim is used only for older MongoDB and Elasticsearch containers with
+no `git.zone.*` labels at all. ObjectStorage has no unlabeled predecessor
+fallback; partial, missing, or conflicting GitZone labels fail closed. Removal
+revalidates and uses the container's immutable ID, never its mutable name, so
+pruning cannot touch a same-name replacement. If Docker becomes unavailable,
+registry claims are preserved as well as containers and data.
+
+Legacy MinIO containers and registry references are reported as preserved
+migration resources and are never prune candidates. `.nogit/miniodata` is
+deliberately outside the prune allowlist; current-project `status` reports its
+presence, while machine-wide prune leaves it untouched.
 
 ### MongoDB authentication
 
@@ -608,11 +711,11 @@ make it look like an older version is installed when it is not:
 
 ```bash
 gitzone --version
-# 2.25.0
-# resolved from: /home/you/.local/share/pnpm/store/v11/links/@git.zone/cli/2.25.0/…
+# 3.2.1
+# resolved from: /home/you/.local/share/pnpm/store/v11/links/@git.zone/cli/3.2.1/…
 
 gitzone --version --json
-# {"version":"2.25.0","resolvedFrom":"…"}
+# {"version":"3.2.1","resolvedFrom":"…"}
 ```
 
 `gitzone tools update` also removes inert copies of managed packages left behind

package/readme.plan.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-Implement the `gitzone services` command to manage MongoDB and MinIO containers for development projects.
+Implement the `gitzone services` command to manage MongoDB, ObjectStorage, and Elasticsearch containers for development projects.
 
 ## Tasks
 
@@ -33,7 +33,7 @@ Implement the `gitzone services` command to manage MongoDB and MinIO containers
 
 - [x] Implement ServiceManager class
   - [x] Manage MongoDB containers
-  - [x] Manage MinIO containers
+  - [x] Manage ObjectStorage containers
   - [x] Handle container lifecycle
   - [x] Generate project-specific container names
   - [x] Manage data directories in `.nogit/`
@@ -41,9 +41,9 @@ Implement the `gitzone services` command to manage MongoDB and MinIO containers
 
 ### Commands Implementation
 
-- [x] `start` command - Start services (mongo|s3|all)
-- [x] `stop` command - Stop services (mongo|s3|all)
-- [x] `restart` command - Restart services (mongo|s3|all)
+- [x] `start` command - Start enabled services or target mongo|objectstorage|s3|elasticsearch
+- [x] `stop` command - Stop all services or target mongo|objectstorage|s3|elasticsearch
+- [x] `restart` command - Stop all then start enabled services, or restart target mongo|objectstorage|s3|elasticsearch
 - [x] `status` command - Show service status
 - [x] `config` command - Show current configuration
 - [x] `compass` command - Show MongoDB Compass connection string
@@ -55,7 +55,7 @@ Implement the `gitzone services` command to manage MongoDB and MinIO containers
 
 - [x] Add `@push.rocks/smartshell` to main plugins.ts
 - [x] Add `@push.rocks/smartnetwork` to main plugins.ts
-- [x] Add `@push.rocks/smartinteraction` to main plugins.ts
+- [x] Add `@push.rocks/smartinteract` to main plugins.ts
 - [x] Register services command in `gitzone.cli.ts`
 
 ### Features
@@ -67,13 +67,13 @@ Implement the `gitzone services` command to manage MongoDB and MinIO containers
 - [x] Status display (running/stopped/not installed)
 - [x] Interactive confirmations for destructive operations
 - [x] Colored console output
-- [x] MinIO bucket auto-creation
+- [x] ObjectStorage bucket auto-creation and authenticated verification
 - [x] MongoDB Compass connection string with network IP
 
 ### Testing
 
-- [ ] Test service start/stop operations
-- [ ] Test configuration creation and updates
+- [x] Test service start/stop operations
+- [x] Test configuration creation and updates
 - [ ] Test port collision handling
 - [ ] Test data persistence
 - [ ] Test MongoDB Compass connection string generation
@@ -89,19 +89,30 @@ Implement the `gitzone services` command to manage MongoDB and MinIO containers
   "MONGODB_PORT": "random-port",
   "MONGODB_USER": "defaultadmin",
   "MONGODB_PASS": "defaultpass",
+  "MONGODB_URL": "derived connection URL",
+  "MONGODB_AUTH_ENABLED": true,
   "S3_HOST": "localhost",
   "S3_PORT": "random-port",
-  "S3_CONSOLE_PORT": "s3-port+1",
-  "S3_USER": "defaultadmin",
-  "S3_PASS": "defaultpass",
-  "S3_BUCKET": "project-name-documents"
+  "S3_UI_PORT": "first available port at or above s3-port+1",
+  "S3_ACCESSKEY": "defaultadmin",
+  "S3_SECRETKEY": "defaultpass",
+  "S3_ADMIN_PASSWORD": "random-secret",
+  "S3_REGION": "us-east-1",
+  "S3_BUCKET": "project-name-documents",
+  "S3_ENDPOINT": "localhost",
+  "S3_USESSL": false,
+  "ELASTICSEARCH_HOST": "localhost",
+  "ELASTICSEARCH_PORT": "9200",
+  "ELASTICSEARCH_USER": "elastic",
+  "ELASTICSEARCH_PASS": "elastic",
+  "ELASTICSEARCH_URL": "derived connection URL"
 }
 ```
 
 ## Command Examples
 
 ```bash
-gitzone services start          # Start all services
+gitzone services start          # Start all enabled services
 gitzone services start mongo    # Start only MongoDB
 gitzone services stop           # Stop all services
 gitzone services status         # Check service status
@@ -121,7 +132,7 @@ Implementation completed: 2025-08-14
 
 Successfully implemented the `gitzone services` command in TypeScript, providing a complete replacement for the `services.sh` shell script. The implementation includes:
 
-1. **Complete Docker service management** for MongoDB and MinIO containers
+1. **Complete Docker service management** for MongoDB, ObjectStorage, and Elasticsearch containers
 2. **Smart configuration management** with automatic port assignment and conflict avoidance
 3. **MongoDB Compass support** with network IP detection for remote connections
 4. **Project isolation** using project-specific container names
@@ -129,7 +140,9 @@ Successfully implemented the `gitzone services` command in TypeScript, providing
 6. **Interactive confirmations** for destructive operations
 7. **Comprehensive command set** including start, stop, restart, status, config, compass, logs, remove, and clean commands
 
-The module is fully integrated into the gitzone CLI and ready for testing.
+The module is integrated into the gitzone CLI and covered by unit tests. A real
+authenticated Docker smoke still requires an explicitly isolated harness; it
+must never run against user-managed containers.
 
 ## Destructive-command audit — remaining items
 

package/ts/00_commitinfo_data.ts

@@ -3,6 +3,6 @@
  */
 export const commitinfo = {
   name: '@git.zone/cli',
-  version: '3.2.1',
+  version: '5.0.0',
   description: 'A comprehensive CLI tool for enhancing and managing local development workflows with gitzone utilities, focusing on project setup, version control, code formatting, and template management.'
 }