@x12i/static-memorix

Static mock server that provides full API parity for the Memorix Explorer Fastify API plus a memorix-service–compatible /api/metadata/* surface. No MongoDB, Catalox, or Redis required — state lives in ./mocks/**/*.json and is flushed to disk (debounced) on mutation.

Ships with a complete reference demo app (FlowState — a small task manager) at GET /demo that exercises every read/write path in the API, plus a dev inspector at GET /inspect for browsing data and metadata. See guides/demo-app.md for the FlowState walkthrough.

Platform alignment

This package tracks the public Memorix 3.0.0 platform libraries:

| Dependency | Role | |------------|------| | @x12i/memorix-format@^3.0.0 | memorix-record/2 revision helpers (checkExpectedRevision / nextRevision) | | @x12i/memorix-metadata@^3.0.0 | Pack contracts, multi-agent resolution, abstracts, custom kinds | | @x12i/memorix-metadata-runtime@^3.0.0 | Install + unified effective-metadata client | | @x12i/memorix-mapping@^3.0.0 | Deterministic mapping AST |

Role: local/CI mock for /api/explorer/* and /api/metadata/* (default port 5100). It is not a substitute for memorix-service (ports 5000–5099): relationships materialize/discover, Memory pulls, pipelines, intelligence, and /api/data abstract reverse-write stay on the real service.

Product ebooks: https://ebooks.memorix.x12i.com

Quick start

Install once, then run one command:

npm install --global @x12i/static-memorix
static-memorix

Then open http://localhost:5100/demo (reference app) or http://localhost:5100/inspect (data/metadata inspector). The command prints the Demo, Inspect, API, Health, and JSON paths when it starts. No database or additional configuration is required.

New here? Follow the tutorials — start with Get started, then tasks, metadata packs, and KnowX.

To create an editable demo in your own directory instead of using the bundled read-only seeds:

static-memorix create-demo
static-memorix --mocks-dir ./memorix-demo

The first command creates ./memorix-demo with demo.html, seed data, metadata, write descriptors, and its own README. It refuses to overwrite an existing path. The second command serves that folder, and all UI create/edit/ delete operations persist their routed JSON files inside it.

Choose a different destination or port if needed:

static-memorix create-demo --dir ./my-project-fixtures
static-memorix --mocks-dir ./my-project-fixtures --port 8080

Useful options:

static-memorix --port 8080
static-memorix --help
static-memorix --version

Stop a server started by the CLI:

static-memorix stop                 # port 5100
static-memorix stop --port 8080

If a requested port is occupied, the CLI explains these stop and alternate-port options instead of returning only EADDRINUSE.

memorix-explorer remains available as a short alias for the static-memorix command — both point at the same binary.

Run from this repository

npm install
npm run build
npm start                 # listens on :5100 (PORT / HOST / MOCKS_DIR env-overridable)
# dev (no build): npm run dev

# open the demo or inspector UI in your browser
open http://localhost:5100/demo
open http://localhost:5100/inspect

Health:

curl localhost:5100/health
curl "localhost:5100/api/explorer/health?includeInventory=1"

Run from CLI or code

Installed CLI, using the default port 5100:

npx @x12i/static-memorix

Or, after a global install:

static-memorix

Override the port from the shell:

PORT=8080 npx @x12i/static-memorix

Start it programmatically (explicit options take precedence over environment defaults):

import { startServer } from "@x12i/static-memorix";

const app = await startServer({ port: 5100, host: "127.0.0.1" });
// await app.close();

For code-level tests without binding a port:

import { buildServer } from "@x12i/static-memorix";

const app = await buildServer();
const response = await app.inject({ method: "GET", url: "/health" });
await app.close();

See guides/running-the-service.md for all CLI, environment, lifecycle, and programmatic examples.

src/
  cli.ts / server.ts / config.ts / types.ts
  engine/          # query, records, write, inventory, …
  routes/          # /api/explorer + /api/metadata
  storage/         # InMemoryStore + fs
  metadata/        # pack bootstrap + scope
mocks/             # Explorer fixtures + metadata-packs
guides/ tutorials/ code-agent-instructions/ ai-assistants/
tests/
dist/              # compiled output (npm bin → dist/cli.js)

Architecture

src/ (TypeScript) ──build──▶ dist/
Fastify Router
  /api/explorer/*  +  /api/metadata/*  +  /health  +  /demo  +  /inspect
        │                    │
        │                    └─ UnifiedMetadataClient (@x12i/memorix-metadata-runtime)
        │                         └─ mocks/metadata-packs/*.json (ops bootstrap)
Query & Interceptor Engine (mingo + narrative virtual filters)
    ┌────────────┬──────────────────┬──────────────┐
Inventory/Lenses  Snapshots/Aliases   Records Writer
    └────────────┴──────────────────┴──────────────┘
               InMemoryStore (state matrix)
                         │ debounced disk flush
          ./mocks/metadata  &  ./mocks/data

Routes

| Group | Endpoints | |------|-----------| | Health | GET /health, GET /api/explorer/health?includeInventory=1 | | Metadata | /api/metadata/packs, /raw, /effective, /kinds, /kinds/:kind, /abstracts, /definition, POST /validate\|install\|publish | | Inventory | /inventory/collections, /summary, /issues, /graph (query sourceLens=db-first\|catalox-first) | | Snapshots | /snapshots/:objectType/:recordId[.../associated[/:propertyName]], /snapshots/:objectType/associated-properties, /associations/plan\|apply\|verify | | Records | /records/collection, /full, /item, /content, /raw-collection, /raw-item, /workspace, POST /records/write, DELETE /records/item | | Lists | /lists, /lists/:listId, /lists/:listId/records, /lists/suggest, mutations POST/PATCH/PUT/DELETE | | Narratives | /narratives, /:entity, /:entity/raw, /:entity/:key, /:entity/:key/records, mutations POST/PATCH/DELETE | | Object Types | /object-types, /:name, /:name/root-property-catalog, POST .../compute | | Write | POST /records/write (validate / dryRun / add / upsert / patch / replace / delete) | | Agents | GET /agents | | Auth shim | POST /api/explorer/auth/token | | Demo | GET /demo — serves mocks/demo.html | | Inspect | GET /inspect — serves mocks/inspect.html (dev data/metadata browser) | | Write descriptors | GET /write-descriptors — list fixture write descriptors |

Metadata, agents, abstracts & mappings

This package ships a memorix-service–compatible /api/metadata/* surface on the Memorix 3.0.0 metadata stack (see Platform alignment):

| Package | Role | |---------|------| | @x12i/memorix-metadata@^3.0.0 | Declarative contracts, multi-agent resolution, metadata-only abstract unions | | @x12i/memorix-metadata-runtime@^3.0.0 | Install + unified effective-metadata client | | @x12i/memorix-mapping@^3.0.0 | Deterministic mapping AST + execution |

Dual surface: Explorer fixtures (mocks/metadata/{agents,object-types,lists,…} + mocks/data) power /api/explorer/*. Declarative packs (mocks/metadata-packs/) power /api/metadata/*. Do not assume Explorer lists appear as pack views.

• Agents & inheritance — effective metadata from ordered agentIds[] (x-memorix-agent-ids or default ops). Child agents inherit and override.
• Object & content types — declared in agent metadata packs, not in @x12i/memorix-format.
• Abstracts — virtual unions (GET /api/metadata/abstracts). Bootstrapped ops includes People and KnowXEntity. No abstract collections / abstract recordId.
• Mappings — pack definitions resolved via effective metadata; not pipelines or services.
• Custom kinds — kindDeclarations + extensions (e.g. acme.ui-tabs). Store/resolve only; engines do not interpret them.

GET /api/metadata/kinds
GET /api/metadata/kinds/acme.ui-tabs
GET /api/metadata/definition?kind=acme.ui-tabs&id=employee-detail
POST /api/metadata/install   # body: { packId|pack, confirm: true }
POST /api/metadata/publish   # body: { confirm: true }

The ops pack is bootstrapped at startup. API install/publish still require explicit confirm:true (intelligence never auto-installs).

Client pattern: (1) resolve effective metadata for scope → (2) drive UI from views/writes/custom kinds → (3) address data with concrete types via /api/explorer (abstract reverse-write lives on full memorix-service).

Ebook: Metadata, Agents, Abstracts · coding agents: code-agent-instructions/ · chat assistants: ai-assistants/.

Query conventions

• filter=prop:op:val — op ∈ eq,ne,gt,gte,lt,lte,in,nin,exists,regex (in/nin use | separators). Repeatable / ;-separated.
• Virtual narrative filter: filter=narrativeId:eq:website-refresh rewrites the query to evaluate doc.narratives['website-refresh'].
• sort=priority:desc&sort=recordId:asc (mingo sort).
• searchText= / q= full-text substring match.
• limit (max 500), offset/skip, includeTotal=1.
• target=memory to query the memory tier (fourth data tier alongside entities/events/knowledge).

Identity keys

The mock server accepts the following identity keys across fetch/write engines:

• recordId — entities
• entityId — entities
• eventId — events
• knowledgeId — knowledge
• memoryId — memory

Endpoints like /records/full and /records/content require exactly one identity key per request. Memory collections are keyed by memoryId; the unprefixed ./mocks/data/memory/memory.json is the seed and routed writes use the active Catalox-prefixed filename.

Content types

Content type is open (memorix-record/2 does not fix an enum — installed metadata decides which content types exist per object type). Drop a ./mocks/data/<objectType>/<contentType>.json file anywhere and it loads, composes through /records/full, and is writable through a write descriptor whose targetCollection is <objectType>/<contentType> — no code change needed. snapshots | analysis | decisions | events | memory are only the well-known defaults that are always initialized (even to []); they are not an exhaustive list.

GET /records/full?entityName=X&recordId=Y composes every content type the store has for that recordId, keyed by its actual content-type name ({ recordId, entityName, contentTypes: { snapshots, analysis, knowx, … } }) — not a fixed {snapshot, analysis, decisions, memory} shape.

KnowX seeds (bundled mocks)

KnowX is a native content type (knowx), not a siloed graph DB. One abstract projection: KnowXEntity (in the ops pack). data.kind is NODE or EDGE. Provenance (docHash + span) is mandatory; epistemic.state ≠ extraction confidence.

| Path | Role | |------|------| | mocks/data/{product,users,marketing,admin}/knowx.json | NODE facets on the same recordId as snapshots | | mocks/data/assertions/knowx.json | EDGE claims (assigned-to, blocked-by) | | mocks/data/assertions/workflow.json | Review assignment siblings (hypothesis EDGEs) | | mocks/data/assertions/confirmations.json | Accept/reject siblings | | mocks/metadata/write-descriptors/*-knowx-write.json | Write contracts targeting <ot>/knowx | | assertions-workflow-write / assertions-confirmations-write | Review sibling writes |

curl 'http://localhost:5100/api/explorer/records/full?entityName=product&recordId=t1'
# → contentTypes.snapshots + contentTypes.knowx (kind: NODE)

curl 'http://localhost:5100/api/explorer/records/collection?entityName=assertions&contentType=knowx'
# → EDGE rows (ASSERTION-1, …)

curl 'http://localhost:5100/api/explorer/records/full?entityName=assertions&recordId=ASSERTION-2'
# → knowx (hypothesis) + workflow sibling

curl -H 'x-memorix-agent-ids: ops' http://localhost:5100/api/metadata/abstracts

This mock does not materialize four-field relationship links or run KnowX pipelines — use memorix-service for that. See guides/using-the-api.md and code-agent-instructions/04-knowx.md.

Snapshot alias translation

Client associated.data|discovery|analysis|{custom} maps to storage associatedData | associatedInferred/associatedDiscovery | associatedAnalysis | associated{Custom}. Raw associated* fields are stripped from the returned document and recomposed into a normalized associated bucket.

Write engine

POST /api/explorer/records/write accepts an operation and routes the payload through the write descriptor's JSON schema.

Operations

| Operation | Behavior | |-----------|----------| | add | Append. Auto-generates an identity if missing. | | upsert | Update existing by identity key, or append. | | patch | Update existing by identity key. No-op if missing. | | replace | Replace the entire collection (use with caution). | | delete | Remove every record matching the supplied identity keys. Returns the removed records. |

Required-field semantics

The schema.required array is enforced fully for add and replace. For upsert, patch, and delete, only the identity field (recordId, or memoryId on the memory tier) is required. This allows partial updates like {recordId, status} without resupplying every required field — the pattern the demo UI uses for every inline edit.

Preconditions (optimistic concurrency)

POST /api/explorer/records/write accepts an optional precondition, checked with the real checkExpectedRevision/nextRevision helpers from @x12i/memorix-format@^3.0.0:

{ "writeDescriptorId": "...", "operation": "patch", "precondition": { "kind": "revision", "revision": 3 }, "input": { "recordId": "wi-100", "status": "blocked" } }

| precondition.kind | Applies to | Behavior | |---|---|---| | "absent" | add, upsert (insert branch) | Fails 409 WRITE_NOT_ABSENT if a record with that identity already exists. | | { kind: "revision", revision } | upsert/patch/delete (update branch) | Fails 409 WRITE_STALE_REVISION if the stored record's revision doesn't match exactly; fails 404 WRITE_NOT_FOUND if the record doesn't exist. |

Opt-in and backward compatible: omitting precondition preserves the pre-3.0 blind-write behavior exactly. When a precondition is supplied and the write succeeds against a record that has a numeric revision field, the engine bumps it server-side (nextRevision) — the response's results reflect the actual stored record, including the new revision, not an echo of your input.

REST-style delete

For ergonomics, you can also delete a single record with:

DELETE /api/explorer/records/item?entityName=product&recordId=t1&writeDescriptorId=product-task-write

Returns { ok: true, count: <n>, removed: [<record>…] } and flushes immediately.

Inspector UI

mocks/inspect.html (served at GET /inspect) is a developer tooling UI — not an end-user product. Toggle Data vs Metadata modes:

• Left nav of object types / lists (data) or fixture + pack metadata groups
• Center grid of rows for the selected source
• Right detail panel with Auto UI (generic field renderer) and JSON (view / edit / save where write APIs allow)

Open http://localhost:5100/inspect while the server is running.

Demo app

The mocks/demo.html reference UI (served at GET /demo) is a complete task manager that uses the Explorer API for every read and mutation. It demonstrates:

• Multi-collection reads (3 parallel records/collection calls + a users collection)
• Filter / search / sort via query params
• Create via modal → POST /records/write op=add
• Edit via inline pills/dropdowns → POST /records/write op=upsert (partial updates)
• Delete via button → DELETE /records/item
• Cross-collection move (delete on old area + add on new area)
• Optimistic UI with rollback on failure

Full implementation walkthrough: guides/demo-app.md.

Environment

| Var | Default | Notes | |-----|---------|-------| | PORT | 5100 | Listen port for demo + inspect + API (--port overrides; use 5100–5120 locally — 5000–5099 is reserved for memorix mono-repo) | | HOST | 0.0.0.0 | Listen host | | MOCKS_DIR | bundled <package>/mocks | Fixture root | | DISK_FLUSH_DEBOUNCE_MS | 300 | Debounce before disk flush | | MEMORIX_ORG_ID | memorix | Organization prefix for DB routing | | MEMORIX_AGENT_ID | default-agent | Agent prefix for catalox DB routing | | MEMORIX_DEPLOYMENT_PROFILE | default | Deployment profile; ebook forces org/agent to ebooks | | MEMORIX_EXPLORER_ENABLE_METADATA_WRITES | false | Allow list & narrative mutations | | MEMORIX_EXPLORER_ENABLE_PIPELINE_WRITES | false | Allow pipeline writes | | MEMORIX_EXPLORER_ENABLE_REGISTRY_WRITES | false | Allow registry writes |

For mutation-capable installed deployments, set MOCKS_DIR to a writable, persistent directory. Routing configuration is process-scoped and resolved on first import; use one process per organization/agent context and one writer per prefix.

DB Router Simulation

The mock server does not connect to MongoDB, but it tricks the frontend into thinking it is talking to the routed tenant databases.

• The GET /api/explorer/health response includes a dynamic memorixDb field constructed as <orgId>-memorix-entities + <orgId>-memorix-events.
• The agent-scoped catalox DB is reflected in the cataloxDb field as <agentId>-memorix-catalox.

These strings are derived from MEMORIX_ORG_ID, MEMORIX_AGENT_ID, and the MEMORIX_DEPLOYMENT_PROFILE (which, when set to ebook, forces both IDs to ebooks).

File-backed routing

Those routed database names also select JSON files. The separator is --:

mocks/data/product/neo-memorix-entities--snapshots.json
mocks/data/product/neo-memorix-events--events.json
mocks/data/memory/neo-agent-memorix-catalox--memory.json
mocks/metadata/lists/neo-agent-memorix-catalox--my-plate.json

For MEMORIX_ORG_ID=neo and MEMORIX_AGENT_ID=neo-agent, entity-like collections use the first prefix, events use the second, and memory plus metadata use the Catalox prefix. If a routed file does not exist, the server loads its unprefixed counterpart as seed data, but all mutations are written to the routed filename. This provides database-style isolation without a database and preserves existing fixtures.

The health response exposes the resolved values under fileRouting. See guides/managing-json-files.md for the complete precedence and migration rules.

Feature Flag Enforcement

The mock server enforces the following feature-flag gates with error responses:

• List/narrative mutations (POST/PATCH/PUT/DELETE /lists, /narratives) require MEMORIX_EXPLORER_ENABLE_METADATA_WRITES=true.
• Pipeline writes (if implemented) require MEMORIX_EXPLORER_ENABLE_PIPELINE_WRITES=true.
• Registry writes (if implemented) require MEMORIX_EXPLORER_ENABLE_REGISTRY_WRITES=true.

Record writes (POST /records/write, DELETE /records/item) are not feature-flagged — they're always on, gated only by the write descriptor contract.

When a flag is disabled or unset, the mock returns { ok: false, error: "..." } matching the production Fastify error shape (typically 403/404).

The "memory" Target

The API has expanded its domain model to include a fourth tier of data: memory. The mock's querying and writing engines now support target=memory and memoryId as a valid primary key alongside recordId, entityId, eventId, and knowledgeId.

• Folder structure: ./mocks/data/memory/memory.json (seeded with example memories).
• Runtime memory writes persist to the active <agent>-memorix-catalox--memory.json route.
• Inventory engine accepts target=memory and includes memory collections in the simulated inventorySummary.
• Records engine accepts target=memory and supports memoryId for fetching.
• Write engine validates and persists memoryId on memory-tier records.
• Startup validation (MemorixRecordArraySchema mock) allows memoryId without throwing schema errors.

Documentation

• tutorials/ — hands-on walkthroughs (get started → tasks → metadata → KnowX)
• guides/running-the-service.md — installation, configuration, env vars
• guides/using-the-api.md — endpoint reference, query language, write operations
• guides/managing-json-files.md — fixture structure, schemas, how the store works
• guides/demo-app.md — FlowState reference UI walkthrough
• code-agent-instructions/ — coding-agent rules for required/custom metadata, data, and KnowX
• ai-assistants/ — ≤5k-char chat assistants (generate metadata / create data) + knowledge files

Release history

v3.5.1

• create-demo README notes Memorix platform @x12i/memorix-*@^3.0.0 alignment.

v3.5.0

• Docs aligned with the Memorix platform 3.0.0 lineup: explicit dependency table, mock-vs-memorix-service scope, and refreshed site / tutorial / code-agent / AI-assistant READMEs.
• Changelog and install guidance now point at @x12i/[email protected] as the forward version line (versions only progress).

v3.4.0

• Bumped all Memorix library dependencies to ^3.0.0: @x12i/memorix-format, @x12i/memorix-mapping, @x12i/memorix-metadata, @x12i/memorix-metadata-runtime.
• Confirmed hard-rule parity with the platform (virtual abstracts, explicit metadata install, KnowX provenance, custom kinds store/resolve only).

v3.2.0

• Added memorix-service–compatible /api/metadata/* using @x12i/memorix-metadata, @x12i/memorix-metadata-runtime, and @x12i/memorix-mapping.
• Bootstraps the ops pack (agents, abstracts including KnowXEntity, mappings, custom kind acme.ui-tabs). Known packs live under mocks/metadata-packs/.
• Explicit confirm:true on metadata install/publish; intelligence never auto-installs.
• KnowX review siblings: assertions/workflow + assertions/confirmations fixtures and write descriptors; provenance-required write examples.
• New code-agent-instructions/ for authoring metadata packs and data.
• New ai-assistants/ chat instruction packs (generate metadata / create data).
• New tutorials/ hands-on path (get started → tasks → metadata → KnowX).
• Rethemed leftover assets/findings fixtures and docs away from security jargon toward office equipment and FlowState tasks.

v3.1.0

• Seeded KnowX knowledge fixtures in the bundled mocks: NODE facets on FlowState subjects (product / users / marketing / admin) and EDGE claims under a new assertions object type.
• Added *-knowx-write descriptors and documented compose / query / write examples in the API guides. FlowState UI is unchanged (fixtures are knowledge/API only).

v3.0.0

• Breaking: GET /records/full now composes every content type the store has for a recordId, keyed by its actual content-type name, instead of a fixed { snapshot, analysis, decisions, memory } shape (note the snapshot → snapshots key rename too). Consumers reading contentTypes.snapshot/.analysis/.decisions by those fixed names need to switch to reading whatever keys are present.
• Content type is now open: the loader discovers ./mocks/data/<objectType>/<contentType>.json files dynamically instead of only recognizing snapshots | analysis | decisions | events | memory. New content types (e.g. knowx, workflow, confirmations) work with zero code changes — see Content types. raw-collection/raw-item no longer reject content-type names outside that well-known set either.
  • GET /records/collection?contentType=... is now honored — it was silently ignored by qp() before and always served snapshots.
• Added optional, opt-in precondition support to POST /records/write ({kind:"absent"} / {kind:"revision", revision}), enforced with the real checkExpectedRevision/nextRevision helpers from @x12i/memorix-format. See Preconditions. On a precondition-checked write, a versioned record's revision is now bumped server-side, and results in the response reflect the actual stored record rather than echoing the input payload.
• None of the above requires any change to existing callers that don't pass precondition or read records/full by the old fixed keys.

v2.0.1

• Updated guides and create-demo instructions to use static-memorix as the primary command (with memorix-explorer still documented as an alias).

v2.0.0

• Renamed the package from @x12i/static-memorix-explorer-api to @x12i/static-memorix. Install and import under the new name going forward; see Install → Renamed package.
• Added the static-memorix CLI command, matching the new package name. memorix-explorer remains available as a short alias; the old static-memorix-explorer-api and mock-memorix-explorer-api aliases were retired as part of the rename.
• Updated repository, homepage, and issue-tracker URLs to github.com/x12i/static-memorix.
• No functional, API, or behavior changes — this is a naming-only release.

v1.5.1

• Replaced personal names in the bundled demo users with generic sample names.
• Added regression coverage to keep personal identifiers out of generated demos.

v1.5.0

• Added memorix-explorer stop [--port <number>] with safe managed-process tracking and stale-PID cleanup.
• Added actionable port-conflict output with stop and alternate-port commands.
• Changed create-demo instructions to relative, user-owned paths such as ./memorix-demo; package or maintainer filesystem paths are never exposed.
• Added lifecycle and occupied-port integration coverage.

v1.4.0

• Added memorix-explorer create-demo to create a user-owned, writable demo.
• Added --dir for the generated demo destination and --mocks-dir for serving any fixture directory directly from the CLI.
• Generated demos include UI, metadata, seed data, write descriptors, and a local usage README.
• Demo creation is atomic, refuses overwrites, and excludes routed state that may have been generated inside a previously used global installation.
• Installed CLI aliases now use a configuration-first launcher so fixture paths are resolved before the server loads.

v1.3.2

• Added the short memorix-explorer CLI command.
• Added --help/-h and --version/-v commands.
• Startup now prints clickable Demo, API, Health, and JSON locations.
• Reworked Quick Start documentation around install-once, run-one-command use.

v1.3.1

• Rejected unsafe routing IDs, object types, and metadata keys before path use.
• Changed malformed and empty JSON handling from silent fallback to explicit startup failure, preventing accidental data loss.
• Made JSON persistence atomic through same-directory temporary-file renames.
• Made list deletion restart-safe with routed tombstones.
• Fixed installed npm CLI execution through symlink-aware entry detection.
• Added packed-install, restart, traversal, corruption, and atomic-write checks.
• Documented writable MOCKS_DIR, process isolation, and single-writer limits.

v1.3.0

• Added database-routing parity through deterministic JSON filename prefixes.
• Added separate entity, event, and Catalox/metadata prefix resolution.
• Added migration-safe fallback from missing routed files to unprefixed seeds; writes always persist to the selected routed file.
• Added resolved fileRouting prefixes to the health response.
• Updated metadata discovery to ignore other routed tenants.
• Added routed persistence and prefix regression coverage.

v1.2.0

• Added native --port and --host CLI options.
• Added the canonical static-memorix-explorer-api executable while retaining mock-memorix-explorer-api as a compatibility alias.
• Published TypeScript declarations for buildServer(), startServer(), configuration exports, and server options.
• Corrected the supported Node.js runtime to Node 20 or newer for Fastify 5.
• Expanded CLI, programmatic, test, precedence, and lifecycle documentation.

v1.1.1

• Changed the default listen port from 4300 to 5030.
• Added safe programmatic APIs: buildServer() and startServer(options).
• Importing the package no longer starts a listener as a side effect.
• Added CLI, environment override, programmatic startup, and injected-test examples.

v1.1.0

• Added: delete operation to the write engine (POST /records/write body operation:"delete").
• Added: REST-style DELETE /api/explorer/records/item endpoint.
• Added: Operation-aware schema validation — upsert/patch/delete only require the identity field, not every required field.
• Added: Complete demo application (mocks/demo.html) wired entirely through the Explorer API — Create/Edit/Delete/Move with optimistic UI.
• Added: users object type + collection.
• Added: Per-area task write descriptors (product/marketing/admin-task-write).
• Added: Per-area narratives and enriched task snapshots (notes, chat, assigneeId).
• Removed: obsolete /api/state flow and mocks/db.json (replaced by Explorer API writes).
• Docs: full demo walkthrough (guides/demo-app.md) and refreshed endpoint tables.

v1.0.0

• Initial implementation of mock Memorix Explorer API.
• Health, inventory, snapshots, records, lists, narratives, object types, write engine (add/upsert/patch/replace), agents, auth shim.