@fnndsc/chili 3.2.5

package/docs/_searchable.adoc

@@ -0,0 +1,187 @@
+= Architecture of "Searchable" Strings
+:toc: left
+:toclevels: 3
+
+The **"Searchable"** architecture is a core ChILI concept designed to unify resource identification and searching into a single, flexible string format. It allows users to specify resources by ID, Name, or complex query parameters seamlessly within CLI arguments and context strings.
+
+As of version 0.4.1 of cumin, searchables are implemented as a formal `Searchable` class providing type safety, validation, and a unified API for all searchable operations.
+
+== The Concept: "One String to Find Them All"
+
+In a traditional REST API, fetching a resource by ID (`GET /plugins/14/`) is distinct from searching for resources (`GET /plugins/?name=pl-dircopy`). The Searchable concept blurs this line for the CLI user.
+
+A "Searchable" string is an input argument that the system automatically interprets as either:
+1.  **A Direct ID/Name**: `"14"`, `"pl-dircopy"`
+2.  **An Explicit Query**: `"name_exact:pl-dircopy"`, `"version:1.0.2, min_creation_date:2023-01-01"`
+
+== Syntax Specification
+
+The explicit syntax is a comma-separated list of key-value pairs:
+
+`"key1: value1, key2: value2, ..."`
+
+*   **Keys**: Correspond directly to the Django filter fields supported by the ChRIS API (e.g., `name`, `name_exact`, `id`, `min_creation_date`).
+*   **Values**: The values to search for.
+*   **Separator**: A colon (`:`) separates key and value. A comma (`,`) separates pairs.
+
+=== Batch Operations (`++` Separator)
+
+For commands that support batch operations (such as `delete`), multiple searchables can be combined using the `++` separator:
+
+`"searchable1++searchable2++searchable3"`
+
+Each searchable is processed independently. For example:
+
+[source,bash]
+----
+chili plugins delete "id:77++id:33++name:pl-test"
+----
+
+This command will:
+1. Resolve `id:77` and delete plugin 77
+2. Resolve `id:33` and delete plugin 33
+3. Resolve `name:pl-test` and delete matching plugin(s)
+
+The implementation splits on `++` and iterates through each part (`pluginHandler.ts:83`).
+
+== Implementation Mechanism
+
+The logic resides in the `Searchable` class (`cumin/src/utils/searchable.ts`) which integrates with the existing parsing utilities (`cumin/src/utils/keypair.ts`) and ChRIS plugin operations (`cumin/src/plugins/chrisPlugins.ts`).
+
+=== The Searchable Class
+
+The `Searchable` class encapsulates all searchable logic in a type-safe, testable module:
+
+[source,typescript]
+----
+import { Searchable } from '@fnndsc/cumin';
+
+// Auto-detect type
+const s1 = Searchable.from("pl-dircopy");              // simple
+const s2 = Searchable.from("name:pl-dircopy");         // compound
+const s3 = Searchable.from("id:77++id:33");            // batch
+
+// Explicit constructors
+const simple = Searchable.simple("pl-dircopy");
+const compound = Searchable.compound("name:foo,version:1.0");
+const batch = Searchable.batch("id:77++id:33");
+
+// Type checking
+if (s1.isSimple()) { /* ... */ }
+if (s2.isCompound()) { /* ... */ }
+if (s3.isBatch()) { /* ... */ }
+
+// Convert to query parameters
+const params = s2.toQueryParams();  // { name: "pl-dircopy" }
+
+// Split batch into individual searchables
+const parts = s3.toBatchSearchables();  // [Searchable, Searchable]
+
+// Validate
+if (s1.validate()) { /* searchable is valid */ }
+----
+
+All ChRIS resource methods accept either strings or `Searchable` objects, providing backward compatibility while enabling explicit type safety when desired.
+
+=== 1. Type Detection (`Searchable.from`)
+
+When a string is passed to `Searchable.from()`, the system automatically detects the type:
+
+*   **Batch Mode**: If the string contains `++`, it is treated as a batch searchable.
+    *   Input: `"id:77++id:33"` -> Type: `batch`
+*   **Compound Mode**: If the string contains a colon (`:`) but no `++`, it is treated as a key-value search.
+    *   Input: `"id:14"` -> Type: `compound`
+*   **Simple Mode**: If the string contains neither `:` nor `++`, it is assumed to be a plain name.
+    *   Input: `"pl-dircopy"` -> Type: `simple`, normalized to `"name: pl-dircopy"`
+
+For backward compatibility, `pluginString_makeSearchable()` still exists but is deprecated in favor of the `Searchable` class.
+
+=== 2. Parsing (`Searchable.toQueryParams`)
+
+The Searchable instance provides parsed key-value pairs via `toQueryParams()`:
+
+[source,typescript]
+----
+const searchable = Searchable.from("name: foo, version: 1.0");
+const params = searchable.toQueryParams();
+// Result: { name: "foo", version: "1.0" }
+----
+
+Internally, this uses the existing `keyPairString_parse()` utility for compound searchables.
+
+=== 3. Normalization (`Searchable.toNormalizedString`)
+
+Before passing to the API, the searchable is normalized:
+
+[source,typescript]
+----
+const s1 = Searchable.simple("pl-dircopy");
+s1.toNormalizedString();  // "name: pl-dircopy"
+
+const s2 = Searchable.compound("name:foo,version:1.0");
+s2.toNormalizedString();  // "name:foo,version:1.0" (unchanged)
+----
+
+This normalized string is then passed through `options_toParams()`, merged with pagination options, and sent to the `@fnndsc/chrisapi` client as a standard HTTP Query String:
+
+`GET /api/v1/endpoint/?name=foo&version=1.0`
+
+=== 4. Resolution
+
+The API returns a list of matching objects. The system then extracts the relevant identifier (typically `id`) from the first result (or handles errors if multiple/zero results are found).
+
+==== Multiple Match Warning
+
+When a searchable resolves to more than one result, the system:
+
+1. Issues a warning: `"Multiple plugins conformed to '<searchable>'"`
+2. Continues execution using the **first match**
+3. Pushes the warning to the error stack for user visibility
+
+[source,typescript]
+----
+// From chrisPlugins.ts:214-219
+if (pluginList.hits.length > 1) {
+  errorStack.stack_push(
+    "warning",
+    `Multiple plugins conformed to "${searchable}.`
+  );
+}
+----
+
+This behavior helps users identify when their search criteria are too broad. Best practice is to use more specific searchables (e.g., `name_exact` instead of `name`, or include version constraints) to ensure deterministic results.
+
+== Integration Points
+
+The Searchable concept is integrated deeply into two main areas:
+
+=== Resource Commands
+
+Commands that operate on resources accept searchable strings as arguments.
+
+[source,bash]
+----
+chili plugin run "name_exact:pl-dircopy, version:2.0.1"
+----
+
+=== Context Initialization
+
+The Context parser (`chrisContextURL_parse` in `cumin`) supports searchables within the query string of a context URI.
+
+[source,bash]
+----
+chili "user@http://cube.org?plugin=name_exact:pl-dircopy" ...
+----
+
+When the parser encounters a key like `plugin` with a value containing a colon (`:`), it triggers the full resolution logic (API call -> Search -> Resolve ID) *before* setting the persistent session state.
+
+== Data Flow Summary
+
+1.  **User Input**: `"name_exact:foo"`
+2.  **CLI Parser**: Passes string to Resolver.
+3.  **Resolver**: calls `keyPairString_parse("name_exact:foo")`.
+4.  **Object**: `{ name_exact: "foo" }`.
+5.  **API Client**: `GET .../?name_exact=foo`.
+6.  **Response**: `[{ id: 42, name: "foo", ... }]`.
+7.  **Resolution**: Returns ID `42`.
+8.  **Action**: Command operates on Resource ID `42`.

package/docs/_state.adoc

@@ -0,0 +1,68 @@
+= ChILI Context & State Management
+:toc: left
+:toclevels: 2
+
+The ChRIS Interactive Line Interface (ChILI) implements a robust "Context" system to provide a stateful, shell-like experience over the stateless ChRIS REST API. This design allows the CLI to remember "who you are," "where you are," and "what you are doing" across multiple sessions, users, and CUBE instances.
+
+== The Concept: "Where am I and Who am I?"
+
+The "Context" is a state management mechanism that persists critical session information. It allows a user to navigate the ChRIS filesystem, switch between different user identities, or connect to different ChRIS backends (CUBEs) without needing to re-authenticate or re-specify parameters for every command.
+
+It answers three fundamental questions:
+1.  **Who is acting?** (Current User)
+2.  **Where are they acting?** (Current ChRIS URL/CUBE instance)
+3.  **What are they working on?** (Current Folder, Feed, or Plugin)
+
+== Data Structure Hierarchy
+
+The context is organized hierarchically to support multi-tenancy and multi-backend operations.
+
+*   **`FullContext`**: The root state object. It maintains a registry of all known users.
+    **   **`UserContext`**: For each specific user (e.g., "alice", "bob"), it stores a map of all CUBE URLs they have interacted with.
+        ***   **`URLContext`**: The leaf node of the state tree. For a specific *User* at a specific *CUBE URL*, it persists the following session details:
+            ****   `folder`: The current working directory path (e.g., `/home/alice/data`).
+            ****   `feed`: The ID of the active feed.
+            ****   `plugin`: The ID of the active plugin instance.
+            ****   `token`: The active authentication token for this session.
+
+== Persistence
+
+This state is not ephemeral. It is persisted to the local filesystem (typically in `~/.chris/` or a similar configuration directory managed by `cumin`).
+
+*   **Session Continuity**: You can set a working directory (`chili context set --ChRISfolder /tmp`), close your terminal, open a new one days later, and `chili chefs ls` will still list the contents of `/tmp`.
+*   **Multi-Tasking**: You can seamlessly switch contexts. For example, you can work as user "dev" on a local testing CUBE, then switch context to user "prod_admin" on a remote production CUBE, and ChILI will instantly recall the correct tokens and working directories for each environment.
+
+== CLI Usage
+
+The context is managed via the `chili context` command group.
+
+=== Viewing State
+
+[source,bash]
+----
+# View the current active context (User, URL, Folder, etc.)
+chili context get
+
+# View details for a specific context aspect
+chili context get --ChRISuser
+chili context get --ChRISurl
+
+# View the entire stored state tree (all users, all URLs)
+chili context get --full
+----
+
+=== Modifying State
+
+[source,bash]
+----
+# Switch active user (if previously authenticated)
+chili context set --ChRISuser alice
+
+# Switch active CUBE instance
+chili context set --ChRISurl https://chris.example.org/api/v1/
+
+# Change current working directory (cd equivalent)
+chili context set --ChRISfolder /home/alice/analysis/
+----
+
+This architecture effectively turns the stateless ChRIS API into a stateful, interactive environment, significantly reducing the friction of repetitive tasks and complex workflows.

package/docs/pacs.adoc

@@ -0,0 +1,101 @@
+= PACS Commands in Chili
+:toc:
+:toclevels: 2
+:sectnums:
+
+== Overview
+
+`chili` is the CLI layer where PACS interactions become user-facing commands. It handles context management, tabular output, and decoding/presentation of PACS query results, while delegating business logic to `salsa`/`cumin`. The goal is to give an operator a concise, line-friendly workflow: pick a PACS server, launch a query, and view its structured results (studies with nested series) without touching raw JSON.
+
+== PACS Servers
+
+- `chili pacsservers list [--identifier <id>] [--limit <n>] [--offset <n>]`
+- `chili pacsservers fieldslist`
+
+== PACS Context
+
+- `chili context set --pacsserver <id|identifier>` (stores PACS server target)
+- `chili context get --pacsserver` (displays current PACS server)
+- Inline override on commands: `--pacsserver <id|identifier>`
+
+== PACS Queries
+
+- **Create**: `chili pacsqueries create "<query>" [--title <title>] [--description <desc>] [--pacsserver <pacs>]`
+  - `<query>` can be JSON (`{"PatientID":"12345"}`) or comma-separated `key:value` pairs (`PatientID:12345,StudyDate:20251003`).
+  - On success prints: `Created PACS query id=<ID> status=<status> pacs=<pacs> title="<title>"`.
+- **List**: `chili pacsqueries list [--pacsserver <pacs>] [--fields ...] [--table|--csv]`
+  - Filters to current/override PACS server. Use `fieldslist` to discover columns.
+- **Fields**: `chili pacsqueries fieldslist`
+- **Decode result**: `chili pacsqueries decode <queryId> [--raw]`
+  - Decodes the query `result` payload (base64 → zlib/gzip → JSON/text).
+  - Renders studies with nested series when JSON is present.
+  - `--raw` prints the decoded JSON prettified.
+
+== PACS Retrieves
+
+- **Pull**: `chili pacsretrieve pull <queryId>`
+  - Triggers a PACS retrieve to pull DICOM data from PACS to ChRIS.
+  - Creates a retrieve record and initiates the external service.
+  - Prints: `Created PACS retrieve id=<ID> query=<queryId> status=<status>`.
+- **Report**: `chili pacsretrieve report <queryId>`
+  - Shows detailed status report with series-level progress.
+  - Displays studies, series descriptions, and file counts (`Pulling (X/Y images)`).
+  - Automatically detects completion when all series are pulled.
+  - Example output:
+  ```
+  Query ID: 123
+  Retrieve ID: 456
+  Retrieve Status: Retrieving / Completed
+
+  Study 1
+    Description: XR-Wrist 3+ Views Left
+    PA: Pulled (1 images)
+    OBLIQUE: Pulling (50/220 images)
+    LATERAL: Pending (0/180 images)
+  ```
+- **Cancel**: `chili pacsretrieve cancel <retrieveId>`
+  - Cancels (deletes) an in-progress retrieve.
+  - Note: Partially-pulled data may remain in ChRIS.
+
+== Typical Flow
+
+=== Query Only
+
+```bash
+chili context set --pacsserver PACSDCM
+chili pacsservers list --table
+chili pacsqueries create "PatientID:4456554" --title "PID 4456554"
+chili pacsqueries list --fields id,title,status,pacs_id,query
+chili pacsqueries decode <id>
+```
+
+=== Query + Retrieve with Monitoring
+
+```bash
+# 1. Set PACS context
+chili context set --pacsserver PACSDCM
+
+# 2. Create query
+chili pacsqueries create "PatientID:4456554" --title "Patient scan"
+# Returns: Created PACS query id=123
+
+# 3. See what's available on PACS
+chili pacsqueries decode 123
+
+# 4. Pull DICOM data to ChRIS
+chili pacsretrieve pull 123
+# Returns: Created PACS retrieve id=456
+
+# 5. Monitor progress
+chili pacsretrieve report 123
+# Shows series-level status: Pending / Pulling / Pulled
+
+# 6. Cancel if needed
+chili pacsretrieve cancel 456
+```
+
+== Notes
+
+- Commands rely on existing ChRIS auth/token; ensure `chili connect` is done.
+- Decoding/parsing happens client-side; no changes to the PACS service.
+- The CLI prints only at the presentation layer; underlying intents remain quiet for programmatic reuse.

package/docs/pathMapper.md

@@ -0,0 +1,246 @@
+# PathMapper Implementation
+
+## Overview
+
+The `PathMapper` singleton class implements hierarchical path mapping from logical ChRIS paths to physical storage locations, with aggressive prefix caching to optimize repeated resolutions.
+
+## Architecture
+
+### Problem Solved
+
+**Before:** Every path resolution walked the entire tree from root, causing redundant API calls:
+```
+/home/user/public/feed_4 → 4 API calls
+/home/user/public/feed_5 → 4 API calls (redundant!)
+/home/user/public/feed_6 → 4 API calls (redundant!)
+```
+
+**After:** Hierarchical prefix caching eliminates redundant operations:
+```
+/home/user/public/feed_4 → 4 API calls (initial resolution)
+/home/user/public/feed_5 → 1 API call  (reuses cached prefix!)
+/home/user/public/feed_6 → 1 API call  (reuses cached prefix!)
+```
+
+### Key Design Decisions
+
+1. **Path-Level Caching**: Cache complete logical → physical mappings
+2. **Incremental Resolution**: Find longest cached prefix, resolve only the suffix
+3. **Intermediate Caching**: Cache every path segment for maximum reuse
+4. **TTL-Based Expiration**: 30-second TTL balances freshness vs performance
+5. **Singleton Pattern**: Single source of truth for all path mappings
+
+## API
+
+### Core Methods
+
+```typescript
+import { pathMapper_get } from '@fnndsc/chili';
+
+const mapper = pathMapper_get();
+
+// Resolve logical path to physical location
+const result = await mapper.logical_toPhysical('/home/user/public/feed_4');
+if (result.ok) {
+  console.log(result.value); // '/SHARED/feed_4'
+}
+
+// Invalidate cache when links change
+mapper.cache_invalidate('/home/user/public');
+
+// Clear all cached mappings
+mapper.cache_clear();
+
+// Get performance statistics
+const stats = mapper.stats_get();
+console.log(`Hit rate: ${stats.hitRate * 100}%`);
+```
+
+### Statistics
+
+```typescript
+interface CacheStats {
+  hits: number;       // Number of cache hits
+  misses: number;     // Number of cache misses
+  size: number;       // Current cache size
+  hitRate: number;    // Hit rate (0-1)
+}
+```
+
+## Performance Characteristics
+
+### Time Complexity
+
+| Operation | Without Cache | With Cache | Improvement |
+|-----------|---------------|------------|-------------|
+| First resolution | O(depth) | O(depth) | - |
+| Repeated resolution | O(depth) | **O(1)** | ✅ |
+| Prefix reuse | O(depth) | **O(suffix)** | ✅ |
+
+### Real-World Example
+
+Resolving 1000 files in `/home/user/feeds/feed_123/files/`:
+
+**Without caching:**
+- 1000 × 6 components = 6,000 API calls
+
+**With PathMapper:**
+- First file: 6 API calls (cache miss)
+- Remaining 999 files: 1 API call each (prefix reuse)
+- **Total: 1,005 API calls (83% reduction)**
+
+## Implementation Details
+
+### Resolution Algorithm
+
+```
+logical_toPhysical(logicalPath):
+  1. Check exact cache hit → return if found
+  2. Find longest cached prefix
+  3. Resolve only the uncached suffix
+  4. Cache all intermediate segments
+  5. Return final physical path
+```
+
+### Example Resolution
+
+```
+Input: '/home/user/public/feed_4'
+Cache state: { '/home/user/public': '/SHARED' }
+
+Step 1: Check exact cache for '/home/user/public/feed_4' → miss
+Step 2: Find longest prefix:
+  - Check '/home/user/public/feed_4' → miss
+  - Check '/home/user/public' → HIT! ✓
+Step 3: Resolve suffix 'feed_4' from '/SHARED':
+  - Check if '/SHARED/feed_4' is a link → no
+Step 4: Cache '/home/user/public/feed_4' → '/SHARED/feed_4'
+Step 5: Return '/SHARED/feed_4'
+```
+
+## Cache Management
+
+### When to Invalidate
+
+Call `cache_invalidate()` when:
+- Links are created: `mapper.cache_invalidate(parentDir)`
+- Links are deleted: `mapper.cache_invalidate(parentDir)`
+- Links are modified: `mapper.cache_invalidate(linkPath)`
+
+### TTL Behavior
+
+- Default TTL: 30 seconds
+- Expired entries are removed on access
+- Balances freshness vs performance
+
+### Memory Considerations
+
+- Cache grows with unique paths accessed
+- Each entry: ~100 bytes (path strings + metadata)
+- 10,000 paths ≈ 1 MB memory
+- TTL ensures bounded growth
+
+## Testing
+
+Comprehensive test suite with 31 tests covering:
+
+✅ Singleton pattern enforcement
+✅ Basic path resolution
+✅ Link resolution (single and multiple)
+✅ Caching behavior
+✅ **Prefix reuse optimization** (key feature)
+✅ Cache invalidation
+✅ TTL expiration
+✅ Error handling
+✅ Statistics tracking
+✅ Edge cases (malformed paths, deep nesting, etc.)
+
+Run tests:
+```bash
+npm test -- pathMapper.test.ts
+```
+
+## Integration
+
+### Automatic Usage
+
+The existing `logical_toPhysical()` function now delegates to PathMapper:
+
+```typescript
+// Old code continues to work unchanged
+import { logical_toPhysical } from '@fnndsc/chili';
+
+const result = await logical_toPhysical('/home/user/files');
+// Automatically uses PathMapper under the hood
+```
+
+### Direct Usage
+
+For advanced scenarios requiring cache control:
+
+```typescript
+import { pathMapper_get } from '@fnndsc/chili';
+
+const mapper = pathMapper_get();
+
+// Batch operations with cache awareness
+for (const file of manyFiles) {
+  const result = await mapper.logical_toPhysical(file.logicalPath);
+  // ...
+}
+
+// Check performance
+const stats = mapper.stats_get();
+console.log(`Resolved ${stats.hits + stats.misses} paths with ${stats.hitRate * 100}% hit rate`);
+```
+
+## Migration Notes
+
+### Backward Compatibility
+
+✅ **Fully backward compatible**
+- Existing `logical_toPhysical()` calls work unchanged
+- Same function signature and return type
+- No breaking changes
+
+### Performance Impact
+
+- **First access**: Identical to previous implementation
+- **Subsequent accesses**: Up to 83% faster for common patterns
+- **Memory overhead**: ~1 MB per 10,000 unique paths
+
+### Future Enhancements
+
+Potential improvements:
+1. **LRU eviction**: Limit cache size with least-recently-used eviction
+2. **Persistent cache**: Serialize cache to disk across sessions
+3. **Metrics export**: Export detailed performance metrics
+4. **Link prefetching**: Proactively fetch links for common paths
+
+## Files
+
+```
+chili/
+├── src/
+│   ├── path/
+│   │   └── pathMapper.ts       # PathMapper implementation (new)
+│   ├── utils/
+│   │   └── cli.ts              # Updated to use PathMapper
+│   └── utils.ts                # Exports PathMapper
+├── tests/
+│   └── pathMapper.test.ts      # Comprehensive test suite (new)
+└── docs/
+    └── pathMapper.md           # This document
+```
+
+## References
+
+- Original implementation: `chili/src/utils/cli.ts` (lines 133-258, now replaced)
+- Issue: Unacceptable lag in path resolution due to repeated tree walking
+- Solution: Hierarchical prefix caching with singleton pattern
+
+---
+
+**Author:** Claude + User collaboration
+**Date:** 2025-01-31
+**Status:** ✅ Implemented and tested

package/package.json

@@ -0,0 +1,92 @@
+{
+  "name": "@fnndsc/chili",
+  "version": "3.2.5",
+  "description": "ChILI handles Intelligent Line Interactions: A CLI and library for ChRIS, acting as the controller layer for business logic and user presentation.",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/FNNDSC/chili.git"
+  },
+  "homepage": "https://github.com/FNNDSC/chili#readme",
+  "bugs": {
+    "url": "https://github.com/FNNDSC/chili/issues"
+  },
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "type": "module",
+  "exports": {
+    ".": "./dist/index.js",
+    "./utils": "./dist/utils.js",
+    "./*": "./dist/*",
+    "./package.json": "./package.json"
+  },
+  "bin": {
+    "chili": "./dist/index.js"
+  },
+  "scripts": {
+    "build": "tsc && chmod +x ./dist/index.js",
+    "start": "node dist/index.js",
+    "test": "jest",
+    "test:coverage": "jest --coverage --coverageProvider=v8",
+    "clean": "rm -rf dist types fnndsc-chili*tgz",
+    "build:cumin": "cd ../cumin && npm run build",
+    "build:chili": "npm run clean && npm install && npm run build",
+    "build:all": "npm run build:cumin && npm run build:chili && npm run pack",
+    "pack": "npm pack",
+    "install:local": "npm i --ignore-scripts $(npm pack | tail -1)",
+    "deploy": "npm run build:all && npm run install:local"
+  },
+  "files": [
+    "dist/**/*",
+    "docs/**/*"
+  ],
+  "keywords": [
+    "chris",
+    "cli",
+    "repl"
+  ],
+  "author": "FNNDSC <dev@babyMRI.org>",
+  "license": "MIT",
+  "dependencies": {
+    "@fnndsc/cumin": "^3.2.4",
+    "@fnndsc/salsa": "^3.2.4",
+    "@fortawesome/fontawesome-free": "^6.6.0",
+    "@fortawesome/fontawesome-svg-core": "^6.6.0",
+    "@fortawesome/free-solid-svg-icons": "^6.6.0",
+    "@mermaid-js/mermaid-cli": "^11.12.0",
+    "archy": "^1.0.0",
+    "asciidoctor": "^3.0.4",
+    "axios": "^1.6.0",
+    "chalk": "^4.1.2",
+    "cli-highlight": "^2.1.11",
+    "cli-progress": "^3.12.0",
+    "cli-table3": "^0.6.3",
+    "commander": "^12.1.0",
+    "figlet": "^1.7.0",
+    "js-yaml": "^4.1.0",
+    "marked": "^9.1.0",
+    "marked-terminal": "^6.1.0",
+    "node-fetch": "^3.3.2",
+    "omelette": "^0.4.17",
+    "open": "^10.1.0",
+    "table": "^6.8.1"
+  },
+  "devDependencies": {
+    "@types/archy": "^0.0.36",
+    "@types/cli-progress": "^3.11.6",
+    "@types/figlet": "^1.5.8",
+    "@types/jest": "^30.0.0",
+    "@types/js-yaml": "^4.0.5",
+    "@types/marked-terminal": "^6.1.1",
+    "@types/node": "^24.10.1",
+    "@types/node-fetch": "^2.6.11",
+    "@types/omelette": "^0.4.4",
+    "jest": "^30.2.0",
+    "ts-jest": "^29.4.5",
+    "typescript": "^5.5.2"
+  },
+  "overrides": {
+    "glob": "^10.0.0",
+    "inflight": "npm:@aashutoshrathi/word-wrap@^1.2.6",
+    "node-domexception": "npm:undici-types@^6.19.8"
+  }
+}