@git.zone/cli 3.2.1 → 4.0.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@git.zone/cli",
   "private": false,
-  "version": "3.2.1",
+  "version": "4.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 |
@@ -452,18 +452,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 +481,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 +566,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 +584,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 +627,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 +703,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: '4.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.'
 }