@venizia/ignis-docs 0.2.1-0 → 0.2.1-1

package/content/references/utilities/module.md

@@ -1,52 +1,105 @@
 ---
 title: Module Utility
-description: Pre-flight check that fails fast with an install instruction when an optional peer dependency is missing
+description: Loads an optional peer dependency with a clear install error, and without letting the bundler see the specifier
 difficulty: beginner
-lastUpdated: 2026-07-16
+lastUpdated: 2026-07-27
 ---
 
 # Module Utility
 
-A pre-flight check for optional peer dependencies. IGNIS helpers and components often depend on packages that are not bundled with the framework (`@connectrpc/connect` for gRPC, `@hono/swagger-ui` for the Swagger component, and so on). Calling `validateModule` before a lazy `import()` throws a clear, actionable error instead of a cryptic "Cannot find module" crash.
+`ModuleUtility` loads an optional peer dependency. IGNIS components depend on packages the framework does not bundle - `nodemailer` for mail, `node-vault` for secrets. Loading one through `ModuleUtility` buys you two things: a missing package throws an install instruction instead of a cryptic crash, and the specifier stays invisible to `Bun.build`.
 
 ## In one example
 
+This is how the secrets helper reaches `node-vault`:
+
 ```typescript
-import { validateModule } from '@venizia/ignis-helpers';
+import { ModuleUtility } from '@venizia/ignis-helpers';
+
+// Fails fast with a clear install instruction if the peer is absent.
+ModuleUtility.assertInstalled({
+  scope: 'HashiCorpVaultHelper',
+  modules: ['node-vault'],
+  allowRegistered: true,
+});
+
+// The specifier is a parameter, so Bun.build never sees it.
+const vault = await ModuleUtility.load({ module: 'node-vault' });
+const client = vault.default({ endpoint, apiVersion: 'v1' });
+```
 
-const GRPC_MODULES = ['@connectrpc/connect'];
+## Methods
 
-export class MyGrpcController extends BaseGrpcController {
-  async configure() {
-    // Fails fast with a clear install instruction if the peer dep is absent
-    await validateModule({ scope: MyGrpcController.name, modules: GRPC_MODULES });
+| Method | Signature | What it does |
+|--------|-----------|---------------|
+| `load` | `load<T>(opts: { module: string }): Promise<T>` | Imports the module. Use this everywhere except a constructor |
+| `loadSync` | `loadSync<T>(opts: { module: string }): T` | Same, without awaiting - for a constructor or any path that cannot be async |
+| `assertInstalled` | `assertInstalled(opts: { modules: Array<string>; scope?: string; allowRegistered?: boolean }): void` | Presence check only. Resolves each module in order and throws on the first miss, without executing any of them |
+| `register` | `register(opts: { modules: Record<string, AnyType> }): void` | Hands the framework peers the application already holds. `load` and `loadSync` serve a registered specifier from memory, with no filesystem lookup |
 
-    const { ConnectRouter } = await import('@connectrpc/connect');
-    // ... register routes
-  }
-}
-```
+### `allowRegistered`
 
-## Functions
+`assertInstalled` reports what is on disk. Set `allowRegistered` to count a `register` entry as present too.
 
-| Function | Signature | What it does |
-|----------|-----------|---------------|
-| `validateModule` | `validateModule(opts: { scope?: string; modules: Array<string> }): Promise<void>` | Resolves each module in `modules`, in order, via `require.resolve`. Throws an `ApplicationError` on the first one that cannot be found. |
+Set it only where `load` or `loadSync` is what finally loads the module. A caller that resolves the specifier itself cannot see the registry - `pino.transport()` resolves inside a worker thread, and the gRPC adapter uses its own `createRequire`. For those, counting a registration as installed would replace a precise error with an opaque one.
 
 ## Error message format
 
 | `scope` | Message |
 |---------|---------|
-| provided | `[validateModule] <module> is required for <scope>. Please install '<module>'` |
-| omitted | `[validateModule] <module> is required. Please install '<module>'` |
+| provided | `[ModuleUtility.<method>] <module> is required for <scope>. Please install '<module>'` |
+| omitted | `[ModuleUtility.<method>] <module> is required. Please install '<module>'` |
+
+## Why not a plain import
+
+`Bun.build` resolves a literal specifier at bundle time. A literal `require('mailgun.js')` anywhere reachable from an entry point forces every consumer who compiles a binary to install that peer or list it in `external` - even a consumer who never touches mail.
+
+A `const` does not help. `minify: { syntax: true }` folds `const s = 'mailgun.js'; import(s)` straight back into a resolvable literal.
+
+Only a specifier that crosses a function boundary survives as a runtime import. That is the whole reason `ModuleUtility` takes the module name as a parameter.
+
+## Compiled binaries
+
+Runtime resolution needs a `node_modules` to resolve against. A `bun build --compile` binary usually runs without one - the deployment ships the executable and nothing else - so a peer the application genuinely installed is still unreachable at runtime, and the component that needs it dies at boot with the install hint.
+
+**Check the component's options first.** Every component that reaches a peer this way takes it through its own options:
+
+| Component | Option | You pass |
+|---|---|---|
+| Mail transports | `module` | the `nodemailer` or `mailgun.js` module |
+| gRPC component | `module` | `{ connect, protocol }` from `@connectrpc/connect` |
+| `HashiCorpVaultHelper` | `client` | an already-built vault client |
+| `DotenvVaultHelper` | `decode` | your own decode function |
+
+Prefer the option. It is typed, it lands where it is used, and no ordering can defeat it.
+
+`register` is the fallback for a peer the framework reaches with no options seam in between. The static import is what pulls the library into the binary; `register` is what lets the framework find it there:
+
+```typescript
+import { ModuleUtility } from '@venizia/ignis-helpers';
+import * as vault from 'node-vault';
+
+// At the entrypoint, before anything that reaches the peer runs.
+ModuleUtility.register({ modules: { 'node-vault': vault } });
+```
+
+The registry is keyed by specifier and the value is returned as-is: what you register under `node-vault` is exactly what `load({ module: 'node-vault' })` hands the caller. `import * as` gives the right shape for a CommonJS peer.
+
+Register before the consumer runs. Nothing enforces that ordering, which is the reason to prefer an options seam wherever one exists.
+
+`register` cannot help a consumer that resolves the specifier itself. A `pino` transport target loads inside a worker thread the registry never reaches, so `pino-pretty` and `pino-roll` must be installed on disk.
+
+Registration is only worth it for the compiled-binary case. An application running from source resolves its peers from `node_modules` already.
 
 ## Notes
 
-- **Resolution is rooted at `process.cwd()/node_modules`** via Node's `createRequire`, so peer dependencies installed in the consuming application resolve correctly even though this utility ships inside `packages/helpers/dist/`.
-- **Evaluated in order - first miss wins.** With multiple `modules`, the loop stops at the first unresolved one and throws; later entries are never checked.
-- **`async` for call-site consistency only.** Resolution itself is synchronous (`require.resolve`); the function returns a `Promise<void>` so every call site can `await` it uniformly.
-- **Call it once, at startup - not per request.** Place it in an initialisation hook (`configure`, `binding`, `boot`), before the guarded `import()`.
-- **Recommended pattern:** declare the dependency as `peerDependenciesMeta` with `optional: true` in `package.json`, call `validateModule` at the top of the method that needs it, and pass the feature or class name as `scope` so the thrown message pinpoints the caller.
+- **Resolution is rooted at `process.cwd()/node_modules`** via Node's `createRequire`, so peers installed in the consuming application resolve even though this utility ships inside `packages/helpers/dist/`.
+- **`assertInstalled` stops at the first miss.** Later entries are never checked.
+- **`assertInstalled` never executes the module** - it only locates the file. Reach for it when you want to fail at startup rather than on first use.
+- **Call it once, at startup, not per request.** Place it in an initialisation hook (`configure`, `binding`, `boot`).
+- **`register` wins over the filesystem.** `load` and `loadSync` check the registry first, so a registered peer is never resolved. `assertInstalled` ignores the registry unless you set `allowRegistered`.
+- **`register` never logs.** It runs at the entrypoint of a compiled binary, which is exactly where no logger provider exists yet.
+- **Recommended pattern:** declare the dependency in `peerDependenciesMeta` with `optional: true`, then load it through `ModuleUtility` and pass the feature or class name as `scope` so the thrown message pinpoints the caller.
 
 ## See also
 

package/content/references/utilities/request.md

@@ -71,7 +71,8 @@ export class FileController extends BaseRestController {
 - **`storage` defaults to `'memory'`**; `uploadDir` defaults to `'./uploads'` and is created recursively if it does not exist.
 - **`sanitizeFilename` is applied automatically** inside `createContentDispositionHeader` - callers do not need to sanitize twice. It also removes leading dots, collapses repeated dots, and strips `..` sequences to block directory traversal and hidden-file tricks.
 - **`createContentDispositionHeader` always emits both forms** (`filename="..."; filename*=UTF-8''...`) for maximum browser compatibility - older browsers read the ASCII fallback, modern ones read the UTF-8 form.
-- **`IRequestedRemark`** is a separately exported interface for describing a request: `{ id: string; url: string; method: string; [extra: string | symbol]: any }`. It is not consumed internally by `parseMultipartBody` or any other function on this page - it is a general-purpose shape for application code that needs to tag a request with an id, URL, method, and arbitrary extra fields.
+- **`IRequestedRemark`** is a separately exported interface for describing a request: `{ id: string; url: string; method: string; [extra: string | symbol]: any }`.
+  - It is not consumed internally by `parseMultipartBody` or any other function on this page - it is a general-purpose shape for application code that needs to tag a request with an id, URL, method, and arbitrary extra fields.
 
 ## See also
 

package/content/references/utilities/retry.md

@@ -0,0 +1,139 @@
+---
+title: Retry Utility
+description: Backoff-driven retry helpers - executeWithRetry retries on errors, executeWithRetryUntil retries until a result looks right
+difficulty: intermediate
+lastUpdated: 2026-07-18
+---
+
+# Retry Utility
+
+Two retry helpers. One retries when a call **throws**. The other retries when a call **succeeds but the result is not what you want yet**.
+
+## In one example
+
+```typescript
+import { executeWithRetry, executeWithRetryUntil } from '@venizia/ignis-helpers';
+
+// Retries because the call THREW
+const data = await executeWithRetry({
+  operation: 'fetch-remote-config',
+  execution: () => fetchConfig(),
+  maxAttempts: 5,
+});
+
+// Retries because the result is not YET what we want
+const order = await executeWithRetryUntil({
+  operation: 'wait-for-paid-order',
+  execution: () => orderRepository.findById({ id: orderId }),
+  until: result => result?.status === 'PAID',
+  maxAttempts: 5,
+});
+```
+
+## Which one do I need?
+
+| Function | Retries when | Typical use |
+|---|---|---|
+| `executeWithRetry` | `execution` throws | Flaky network calls, connection setup |
+| `executeWithRetryUntil` | `until(result)` returns `false` | Polling until data is fresh or a job is done. Powers the repository [`retry` option](/references/base/repositories/advanced#read-retry-replica-lag). |
+
+Both share the same backoff engine and the same habit: on exhaustion, log one `logger.warn` and hand back the LAST outcome.
+
+## `executeWithRetry`
+
+```typescript
+const executeWithRetry: <T>(opts: {
+  operation: string;
+  execution: (context: { attempt: number; signal?: AbortSignal }) => ValueOrPromise<T>;
+  maxAttempts?: number; // default 3
+  maxTotalMs?: number; // total budget across attempts and sleeps
+  perAttemptTimeoutMs?: number; // race each attempt against a timeout
+  backoff?: IRetryBackoffOptions;
+  shouldRetry?: (context: IRetryContext) => boolean;
+  onRetry?: (context: IRetryContext & { nextDelayMs: number }) => ValueOrPromise<void>;
+  signal?: AbortSignal;
+  logger?: ILogger;
+}) => Promise<T>;
+```
+
+The rules:
+
+- Every thrown error retries, unless `shouldRetry` returns `false` - then it rethrows immediately. Use this for permanent errors like a `400`.
+- Out of attempts or budget? The LAST error is thrown.
+- `signal` aborts between attempts and during sleeps. It is also passed to `execution` - a running promise cannot be cancelled from outside, so honor it inside if you can.
+
+## `executeWithRetryUntil`
+
+```typescript
+const executeWithRetryUntil: <T>(opts: {
+  operation: string;
+  execution: (context: { attempt: number; signal?: AbortSignal }) => ValueOrPromise<T>;
+  until: (result: T) => boolean; // return true to stop: "the result is good"
+  maxAttempts?: number; // default 3
+  maxTotalMs?: number; // stop starting NEW attempts after this much time
+  backoff?: IRetryBackoffOptions;
+  signal?: AbortSignal;
+  logger?: ILogger;
+}) => Promise<T>;
+```
+
+The rules:
+
+- A thrown error is never retried. It rethrows immediately. Only a successful call with a "not yet" result retries.
+- Out of attempts or budget? The LAST result is returned as-is. No error.
+- `maxTotalMs` never cuts a running read short. It only stops NEW attempts from starting. Zero or negative just means "no retries" - one call still runs.
+- `maxAttempts` below `1` throws before anything runs.
+- An aborted `signal` rejects the call - a cancelled caller does not want a stale result.
+
+Use it for any polling: waiting for a job status to flip, for a downstream service to come up, for a replica to catch up.
+
+## Backoff and jitter
+
+Both helpers wait between attempts using `IRetryBackoffOptions`:
+
+```typescript
+interface IRetryBackoffOptions {
+  strategy?: 'fixed' | 'linear' | 'exponential' | 'schedule'; // default exponential
+  initialDelayMs?: number; // default 250
+  multiplier?: number; // exponential growth factor, default 2
+  maxDelayMs?: number; // cap before jitter, default 30000
+  scheduleMs?: readonly number[]; // required for 'schedule'
+  jitter?: 'none' | 'full' | 'equal'; // default full
+}
+```
+
+| Strategy | Delay for attempt N |
+|---|---|
+| `fixed` | `initialDelayMs` |
+| `linear` | `initialDelayMs * N` |
+| `exponential` | `initialDelayMs * multiplier ** (N - 1)` |
+| `schedule` | `scheduleMs[N - 1]`, last entry repeats |
+
+| Jitter | Effect |
+|---|---|
+| `none` | delay used as-is |
+| `full` | random in `[0, delay)` |
+| `equal` | random in `[delay/2, delay)` |
+
+Prefer named constants? `RetryBackoffStrategies.EXPONENTIAL`, `RetryJitterModes.EQUAL`, etc.
+
+> [!NOTE]
+> These defaults (250ms, 30s cap) suit network retries. The repository `retry` option uses its own tighter defaults (50ms up to 500ms) - see [Read Retry](/references/base/repositories/advanced#read-retry-replica-lag).
+
+## Other exports
+
+| Export | What it does |
+|---|---|
+| `runWithTimeout({ operation, timeoutMs, execution })` | Races `execution` against a timeout. Omitted or `<= 0` means no timeout. |
+| `isRetryTimeoutError(error)` | `true` when the error is a timeout from `runWithTimeout`/`executeWithRetry`. |
+| `computeBackoffDelayMs({ attempt, backoff })` | The delay both helpers use, exposed for your own loops. |
+
+## See also
+
+- [Read Retry](/references/base/repositories/advanced#read-retry-replica-lag) - the repository `retry` option built on `executeWithRetryUntil`
+- [Repository Read Retry changelog](/changelogs/2026-07-18-repository-read-retry) - what shipped and why
+- [Utilities Overview](/references/utilities/)
+
+**Files:**
+
+- [`packages/helpers/src/utilities/retry.utility.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/helpers/src/utilities/retry.utility.ts)

package/content/references/utilities/schema.md

@@ -64,5 +64,5 @@ this.defineRoute({
 
 **Files:**
 
-- [`packages/core/src/utilities/schema.utility.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/utilities/schema.utility.ts)
-- [`packages/core/src/base/models/common/types.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/base/models/common/types.ts)
+- [`packages/core-server/src/utilities/schema.utility.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/utilities/schema.utility.ts)
+- [`packages/core-server/src/base/models/common/types.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/base/models/common/types.ts)

package/content/references/utilities/statuses-reference.md

@@ -11,14 +11,14 @@ Exhaustive reference for `Statuses`, its specialized subclasses, and the `Bindin
 
 **Files:**
 
-- [`packages/core/src/common/statuses.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/common/statuses.ts)
-- [`packages/core/src/common/bindings.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/common/bindings.ts)
+- [`packages/core-server/src/common/statuses.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/common/statuses.ts)
+- [`packages/core-server/src/common/bindings.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/common/bindings.ts)
 
 ## `Statuses`
 
 A static class of `'NNN_NAME'` status code constants, grouped by an HTTP-inspired numeric prefix, plus `Set` groupings and validator methods.
 
-`Source ->` [`packages/core/src/common/statuses.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/common/statuses.ts)
+`Source ->` [`packages/core-server/src/common/statuses.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/common/statuses.ts)
 
 ### Status code scheme
 
@@ -227,7 +227,7 @@ export class UserTypes {
 
 Organizes dependency-injection binding keys by artifact type. Distinct from `Statuses` - not a lifecycle catalog.
 
-`Source ->` [`packages/core/src/common/bindings.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/common/bindings.ts)
+`Source ->` [`packages/core-server/src/common/bindings.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/common/bindings.ts)
 
 ### `BindingNamespaces`
 

package/content/references/utilities/statuses.md

@@ -7,7 +7,7 @@ lastUpdated: 2026-07-16
 
 # Statuses
 
-`Statuses` is a static catalog of lifecycle status codes - a shared vocabulary so every entity in an app uses the same strings for "draft", "active", "failed", and so on.
+`Statuses` is a static catalog of lifecycle status codes - a shared vocabulary. Every entity in an app uses the same strings for "draft", "active", "failed", and so on.
 
 ## In one example
 
@@ -30,8 +30,8 @@ if (Statuses.isActive(job.status)) {
 
 - **HTTP-inspired numeric prefix.** Each status is a `'NNN_NAME'` string (e.g. `'302_SUCCESS'`). The leading digit groups statuses into six phases.
 - **Group sets for classification.** Every phase has a matching `*_SCHEME_SET` (a `Set<string>`) plus a validator method (`isActive`, `isFailed`, etc.) that just checks set membership.
-- **Specialized classes narrow the catalog.** `MigrationStatuses`, `CommonStatuses`, `UserStatuses`, and `RoleStatuses` each expose a small, named subset of `Statuses` values for a specific use case - they don't invent new status strings.
-- **A separate constant catalog for DI.** `BindingNamespaces` and `CoreBindings` (in the same file area) are unrelated to entity lifecycle - they're the namespace/key strings the container uses for dependency injection.
+- **Specialized classes narrow the catalog.** `MigrationStatuses`, `CommonStatuses`, `UserStatuses`, and `RoleStatuses` each expose a small, named subset of `Statuses` values for a specific use case. None of them invent new status strings.
+- **A separate constant catalog for DI.** `BindingNamespaces` and `CoreBindings` (in the same file area) are unrelated to entity lifecycle. They're the namespace/key strings the container uses for dependency injection.
 
 **The six phases**
 
@@ -118,5 +118,5 @@ await userRepository.create({
 
 **Files:**
 
-- [`packages/core/src/common/statuses.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/common/statuses.ts)
-- [`packages/core/src/common/bindings.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core/src/common/bindings.ts)
+- [`packages/core-server/src/common/statuses.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/common/statuses.ts)
+- [`packages/core-server/src/common/bindings.ts`](https://github.com/VENIZIA-AI/ignis/blob/main/packages/core-server/src/common/bindings.ts)

package/dist/mcp-server/tools/github/list-project-files.tool.d.ts

@@ -11,7 +11,7 @@ declare const OutputSchema: z.ZodObject<{
 }, z.core.$strip>;
 export declare class ListProjectFilesTool extends BaseTool<typeof InputSchema, typeof OutputSchema> {
     readonly id = "listProjectFiles";
-    readonly description = "\nLists files and directories within the Ignis GitHub repository.\n\nPURPOSE:\nExplore the project structure, discover source code files, and navigate the monorepo.\nPrimary tool for understanding codebase layout before reading specific files.\n\nWHEN TO USE:\n- To understand overall project structure\n- To find location of specific modules (e.g., \"where are the controllers?\")\n- To get list of files in a directory before using viewSourceFile\n- To find configuration files, examples, or documentation\n\nWHEN NOT TO USE:\n- When searching for specific code patterns or keywords (use searchCode instead)\n- When you need to read a file's content (use viewSourceFile instead)\n- For documentation content (use searchDocs, listDocs, getDocContent instead)\n\nWORKFLOW:\n1. Start at root: listProjectFiles()\n2. Explore a package: listProjectFiles({ directoryPath: \"packages/core/src\" })\n3. Identify a file of interest\n4. Read the file: viewSourceFile({ filePath: \"packages/core/src/application.ts\" })\n";
+    readonly description = "\nLists files and directories within the Ignis GitHub repository.\n\nPURPOSE:\nExplore the project structure, discover source code files, and navigate the monorepo.\nPrimary tool for understanding codebase layout before reading specific files.\n\nWHEN TO USE:\n- To understand overall project structure\n- To find location of specific modules (e.g., \"where are the controllers?\")\n- To get list of files in a directory before using viewSourceFile\n- To find configuration files, examples, or documentation\n\nWHEN NOT TO USE:\n- When searching for specific code patterns or keywords (use searchCode instead)\n- When you need to read a file's content (use viewSourceFile instead)\n- For documentation content (use searchDocs, listDocs, getDocContent instead)\n\nWORKFLOW:\n1. Start at root: listProjectFiles()\n2. Explore a package: listProjectFiles({ directoryPath: \"packages/core-server/src\" })\n3. Identify a file of interest\n4. Read the file: viewSourceFile({ filePath: \"packages/core-server/src/application.ts\" })\n";
     readonly inputSchema: z.ZodObject<{
         directoryPath: z.ZodDefault<z.ZodString>;
     }, z.core.$strip>;

package/dist/mcp-server/tools/github/list-project-files.tool.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"list-project-files.tool.d.ts","sourceRoot":"","sources":["../../../../mcp-server/tools/github/list-project-files.tool.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,QAAQ,EAAE,MAAM,cAAc,CAAC;AAsCxC,QAAA,MAAM,WAAW;;iBAEf,CAAC;AAEH,QAAA,MAAM,YAAY;;;;;iBAOhB,CAAC;AAEH,qBAAa,oBAAqB,SAAQ,QAAQ,CAAC,OAAO,WAAW,EAAE,OAAO,YAAY,CAAC;IACzF,QAAQ,CAAC,EAAE,sBAAsB;IACjC,QAAQ,CAAC,WAAW,0/BAAoB;IACxC,QAAQ,CAAC,WAAW;;sBAAe;IACnC,QAAQ,CAAC,YAAY;;;;;sBAAgB;IAE/B,OAAO,CAAC,IAAI,EAAE,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,GAAG,OAAO,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,YAAY,CAAC,CAAC;IAuBvF,OAAO;;;;;;;;CASR"}
+{"version":3,"file":"list-project-files.tool.d.ts","sourceRoot":"","sources":["../../../../mcp-server/tools/github/list-project-files.tool.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,QAAQ,EAAE,MAAM,cAAc,CAAC;AAsCxC,QAAA,MAAM,WAAW;;iBAEf,CAAC;AAEH,QAAA,MAAM,YAAY;;;;;iBAOhB,CAAC;AAEH,qBAAa,oBAAqB,SAAQ,QAAQ,CAAC,OAAO,WAAW,EAAE,OAAO,YAAY,CAAC;IACzF,QAAQ,CAAC,EAAE,sBAAsB;IACjC,QAAQ,CAAC,WAAW,wgCAAoB;IACxC,QAAQ,CAAC,WAAW;;sBAAe;IACnC,QAAQ,CAAC,YAAY;;;;;sBAAgB;IAE/B,OAAO,CAAC,IAAI,EAAE,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,GAAG,OAAO,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,YAAY,CAAC,CAAC;IAuBvF,OAAO;;;;;;;;CASR"}

package/dist/mcp-server/tools/github/list-project-files.tool.js

@@ -25,9 +25,9 @@ WHEN NOT TO USE:
 
 WORKFLOW:
 1. Start at root: listProjectFiles()
-2. Explore a package: listProjectFiles({ directoryPath: "packages/core/src" })
+2. Explore a package: listProjectFiles({ directoryPath: "packages/core-server/src" })
 3. Identify a file of interest
-4. Read the file: viewSourceFile({ filePath: "packages/core/src/application.ts" })
+4. Read the file: viewSourceFile({ filePath: "packages/core-server/src/application.ts" })
 `;
 const DIRECTORY_PATH_DESCRIPTION = `
 The path to the directory you want to list, relative to the project root.
@@ -36,7 +36,7 @@ If omitted, it defaults to the root of the repository.
 EXAMPLES:
 - "." (or omitted) -> lists the root directory
 - "packages" -> lists the contents of the 'packages' directory
-- "packages/core/src" -> lists the source files of the core package
+- "packages/core-server/src" -> lists the source files of the core package
 `;
 const InputSchema = zod_1.z.object({
     directoryPath: zod_1.z.string().default('.').describe(DIRECTORY_PATH_DESCRIPTION),

package/dist/mcp-server/tools/github/search-code.tool.js

@@ -43,7 +43,7 @@ QUERY SYNTAX:
 - Multiple terms: "inject service" - files containing both terms
 - Exact phrase: "\\"dependency injection\\"" - exact phrase match
 - File extension: "extension:ts middleware" - only TypeScript files
-- Path filter: "path:packages/core createTool" - search in specific path
+- Path filter: "path:packages/core-server createTool" - search in specific path
 
 EXAMPLES:
 - "class Application" - find Application class definition

package/dist/mcp-server/tools/github/verify-dependencies.tool.js

@@ -32,7 +32,7 @@ The path to the package directory from the repository root.
 This directory must contain a 'package.json' file.
 
 EXAMPLES:
-- "packages/core"
+- "packages/core-server"
 - "packages/helpers"
 - "examples/5-mins-qs"
 `;

package/dist/mcp-server/tools/github/view-source-file.tool.js

@@ -32,7 +32,7 @@ HOW TO OBTAIN:
 - Navigate from root directory down to the specific file
 
 EXAMPLES:
-- "packages/core/src/application.ts"
+- "packages/core-server/src/application.ts"
 - "examples/5-mins-qs/src/index.ts"
 - "package.json"
 `;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@venizia/ignis-docs",
-  "version": "0.2.1-0",
+  "version": "0.2.1-1",
   "description": "Interactive documentation site and MCP (Model Context Protocol) server for the Ignis Framework. Includes a VitePress-powered documentation site with guides, API references, and best practices. Ships an MCP server (CLI: ignis-docs-mcp) with 11 tools for AI assistants to search docs, browse source code, verify dependencies, and access real-time framework knowledge. Built with Mastra MCP SDK and Fuse.js fuzzy search.",
   "keywords": [
     "ai",
@@ -96,40 +96,41 @@
     "access": "public"
   },
   "scripts": {
-    "force-update": "sh ./scripts/force-update.sh",
+    "docs:build": "sh ./scripts/docs-build.sh",
+    "docs:check-sidebar": "bun scripts/check-sidebar.ts",
+    "docs:clean": "sh ./scripts/docs-clean.sh",
+    "docs:dev": "vitepress dev site",
+    "docs:preview": "vitepress preview site",
     "eslint": "eslint --report-unused-disable-directives .",
+    "force-update": "sh ./scripts/force-update.sh",
     "lint": "bun run eslint && bun run prettier:cli",
     "lint:fix": "bun run eslint --fix && bun run prettier:fix",
-    "prettier:cli": "prettier \"**/*.{js,ts}\" -l",
-    "prettier:fix": "bun run prettier:cli --write",
-    "docs:dev": "vitepress dev site",
-    "docs:clean": "sh ./scripts/docs-clean.sh",
-    "docs:build": "sh ./scripts/docs-build.sh",
-    "docs:preview": "vitepress preview site",
-    "rebuild": "sh ./scripts/mcp-rebuild.sh no-version",
-    "mcp:rebuild": "bun run rebuild",
     "mcp:build": "sh ./scripts/mcp-build.sh",
     "mcp:clean": "sh ./scripts/mcp-clean.sh",
-    "mcp:start": "bun run mcp-server/index.ts",
     "mcp:dev": "bun --watch mcp-server/index.ts",
-    "prepublishOnly": "bun run mcp:rebuild"
+    "mcp:rebuild": "bun run rebuild",
+    "mcp:start": "bun run mcp-server/index.ts",
+    "prepublishOnly": "bun run mcp:rebuild",
+    "prettier:cli": "prettier \"**/*.{js,ts}\" -l",
+    "prettier:fix": "bun run prettier:cli --write",
+    "rebuild": "sh ./scripts/mcp-rebuild.sh no-version"
   },
   "dependencies": {
     "@mastra/core": "^1.51.0",
     "@mastra/mcp": "^1.14.0",
-    "cytoscape": "^3.33.4",
+    "cytoscape": "^3.34.0",
     "cytoscape-cose-bilkent": "^4.1.0",
-    "dayjs": "^1.11.20",
+    "dayjs": "^1.11.21",
     "debug": "^4.4.3",
     "fast-glob": "^3.3.3",
     "fuse.js": "^7.5.0",
     "gray-matter": "^4.0.3",
-    "zod": "^4.3.6"
+    "zod": "^4.4.3"
   },
   "devDependencies": {
     "@braintree/sanitize-url": "^7.1.2",
     "@types/bun": "^1.3.14",
-    "@venizia/dev-configs": "^0.1.0",
+    "@venizia/dev-configs": "^0.2.0-1",
     "eslint": "^10.7.0",
     "prettier": "^3.9.5",
     "tsc-alias": "^1.9.1",