@christiandoxa/prodex 0.2.127 → 0.2.129

package/README.md

@@ -62,13 +62,19 @@ Check your installed version:
 prodex --version
 ```
 
-The current local version in this repo is `0.2.127`:
+The current local version in this repo is `0.2.129`:
 
 ```bash
-npm install -g @christiandoxa/prodex@0.2.127
-cargo install prodex --force --version 0.2.127
+npm install -g @christiandoxa/prodex@0.2.129
+cargo install prodex --force --version 0.2.129
 ```
 
+Dependency status in this repo:
+
+- The npm runtime dependency is already at the latest published `@openai/codex` release: `0.118.0`
+- `cargo update` currently produces no Rust lockfile changes on the Rust `1.94.1` compatible graph used by this project
+- `generic-array` remains pinned transitively by `crypto-common`, and `sha2 0.11` would require a wider RustCrypto compatibility jump than this release
+
 Switching from a Cargo-installed binary to npm?
 
 ```bash
@@ -209,10 +215,13 @@ prodex quota --all
 prodex quota --all --once
 prodex quota --profile main --detail
 prodex info
+prodex audit
+prodex audit --tail 20 --component profile
 prodex cleanup
 prodex doctor
 prodex doctor --quota
 prodex doctor --runtime
+prodex doctor --runtime --json
 ```
 
 If a runtime session looks stalled, inspect the latest runtime log:
@@ -222,8 +231,62 @@ prodex doctor --runtime
 tail -n 200 "$(cat /tmp/prodex-runtime-latest.path)"
 ```
 
+That pointer path lives in `/tmp` only when you keep the default runtime log directory. If you override the runtime log directory through policy or environment, use `prodex doctor --runtime --json` to read the active `log_path` and live broker metrics.
+
 Use `prodex cleanup` to remove stale local runtime logs, temporary login homes, dead broker leases and registries, plus old orphaned managed profile homes that are no longer tracked in state.
 
+## Runtime Policy
+
+Enterprise-style local deployments can pin runtime logging and proxy tuning in `$PRODEX_HOME/policy.toml` or `~/.prodex/policy.toml`.
+
+```toml
+version = 1
+
+[runtime]
+log_format = "json"
+log_dir = "runtime-logs"
+
+[secrets]
+backend = "file"
+# keyring_service = "prodex"
+
+[runtime_proxy]
+worker_count = 16
+active_request_limit = 128
+responses_active_limit = 96
+http_connect_timeout_ms = 5000
+stream_idle_timeout_ms = 300000
+```
+
+Notes:
+
+* Environment variables still win over `policy.toml`.
+* `prodex info` and `prodex doctor` show the active policy file, selected secret backend, and effective runtime log mode.
+* The default runtime log format remains `text`; set `log_format = "json"` or `PRODEX_RUNTIME_LOG_FORMAT=json` when you want machine-readable runtime logs.
+* Secret backend selection can be overridden with `PRODEX_SECRET_BACKEND` and `PRODEX_SECRET_KEYRING_SERVICE`.
+* `prodex audit` reads the local append-only audit log and supports `--tail`, `--component`, `--action`, `--outcome`, and `--json`.
+
+## Enterprise Hardening
+
+The current hardening is still local-first, but it now includes:
+
+- a secret-management abstraction for `auth.json` and exported profile bundles, plus global secret-backend selection via policy or environment
+- a stable live broker snapshot at `GET /__prodex/runtime/metrics`
+- a Prometheus scrape target at `GET /__prodex/runtime/metrics/prometheus`
+- `prodex info` and `prodex doctor --runtime --json` surfacing live broker metrics targets and the selected secret backend
+- enterprise audit logging for profile selection, rotation decisions, and admin-facing state changes, kept separate from transport behavior and discoverable via `prodex info` or `prodex doctor --runtime --json`
+- `prodex audit` as a local read-only CLI surface for browsing recent append-only audit events
+
+Current limitations:
+
+- local `auth.json` remains the compatibility source of truth for current Codex flows even when a non-file backend is selected
+- there is no keychain, Vault, or KMS-backed secret backend implementation yet
+- audit logs follow the resolved runtime log directory by default, or `PRODEX_AUDIT_LOG_DIR` when set
+- there is no central control plane, RBAC, SSO, or SCIM
+- `prodex doctor --runtime --json` is operationally useful, but it is not a full observability stack
+- the repo still assumes a per-host profile pool and local state ownership
+- runtime-store modularization is still in progress, so persistence and audit/event handling remain implementation details rather than a public API
+
 ## Notes
 
 * Managed profiles share persisted Codex state through Prodex-owned shared storage.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@christiandoxa/prodex",
-  "version": "0.2.127",
+  "version": "0.2.129",
   "description": "Safe multi-account auto-rotate for Codex CLI with isolated CODEX_HOME profiles",
   "license": "MIT",
   "bin": {
@@ -16,12 +16,12 @@
     "@openai/codex": "^0.118.0"
   },
   "optionalDependencies": {
-    "@christiandoxa/prodex-linux-x64": "0.2.127",
-    "@christiandoxa/prodex-linux-arm64": "0.2.127",
-    "@christiandoxa/prodex-darwin-x64": "0.2.127",
-    "@christiandoxa/prodex-darwin-arm64": "0.2.127",
-    "@christiandoxa/prodex-win32-x64": "0.2.127",
-    "@christiandoxa/prodex-win32-arm64": "0.2.127"
+    "@christiandoxa/prodex-linux-x64": "0.2.129",
+    "@christiandoxa/prodex-linux-arm64": "0.2.129",
+    "@christiandoxa/prodex-darwin-x64": "0.2.129",
+    "@christiandoxa/prodex-darwin-arm64": "0.2.129",
+    "@christiandoxa/prodex-win32-x64": "0.2.129",
+    "@christiandoxa/prodex-win32-arm64": "0.2.129"
   },
   "engines": {
     "node": ">=18"