@maadb/core 0.14.0 → 0.15.1

package/dist/skills/corpus-explorer.js

@@ -0,0 +1,223 @@
+// ============================================================================
+// Corpus Explorer skill — managed instruction generator (fully static).
+// ============================================================================
+export function generateCorpusExplorerSkill() {
+    return `# Mapping an Unfamiliar Project
+
+> Managed by the MAADb engine — do not edit (changes block future refreshes).
+> Project-specific corpus maps belong in \`_skills/local/corpus-map.md\`.
+> Never append session notes to this skill file.
+
+## Purpose
+
+You are an agent landing in a MAADB project you did not build and do not
+know. This skill is a staged exploration protocol that takes you from zero
+to a **written, typed map of the corpus** — what the record types are, how
+they connect, how dense the graph is, where it is broken — using cheap,
+bounded reads. The protocol front-loads index-backed tools and defers
+full-body reads to the end, so orientation cost stays flat even on large
+corpora.
+
+Audience: any agent with reader access. The final stage writes one overlay
+file, which needs writer access (skippable — report the map in chat instead).
+
+## When to load this skill
+
+- First session in a project whose \`maad_summary\` you have never seen.
+- You've been handed a task referencing types or records you can't place.
+- Before proposing schema or convention changes to an inherited corpus —
+  map first, judge second.
+- Periodically on long-lived projects, to refresh a stale corpus map.
+
+If \`maad_summary\` shows an **empty** project, stop — this skill maps
+existing data. Enter Architect mode instead (\`_skills/architect-core.md\`).
+
+## Ground rules
+
+- **Never** map a corpus by listing or reading files directly — all reads go
+  through MCP tools, and the index is faster than you.
+- Match read shape to need (\`hot\` → fields, \`warm\` → one section, \`cold\` →
+  full body). In this protocol, \`cold\` appears only in Stage 3, on a
+  handful of records.
+- Everything you write into the map must be grounded in a tool result from
+  **this** session; counts you intend to publish go through
+  \`maad_verify mode=count\` first.
+- Watch \`_meta.warnings[]\` on every response — orientation is exactly when
+  you want to notice degraded subsystems or drift signals early.
+
+## The protocol
+
+Six stages. Each produces a section of the final map; you can stop early
+and still hold a partial map (that's a feature — Stage 6 records what was
+*not* explored, and a truncated map that says so is still trustworthy).
+
+### Stage 0 — Bind and capabilities
+
+On multi-project servers: \`maad_projects\`, then \`maad_use_project\` (bindings
+are fixed per session). Then \`maad_describe\`: project overview, stats, and
+\`capabilities\` — notably whether relationship paths and semantic search are
+available in this deployment, which decides your Stage 4 toolkit.
+
+### Stage 1 — Summary: the shape
+
+\`maad_summary\` once. Extract into notes:
+
+- Type inventory with counts — your candidate class list.
+- Sample doc IDs per type — seeds for Stages 3–4.
+- Warnings: broken refs and validation errors reported here are your first
+  hygiene signal; carry them to Stage 5, don't chase them yet.
+
+Ask whether the project already has orientation overlays — via
+\`maad_describe\` / summary warnings, or by reading known managed paths
+through tools when the deployment exposes them (\`MAAD.md\`,
+\`_skills/local/corpus-map.md\`, \`_skills/local/ontology.md\`). An existing
+local overlay changes your job from *mapping* to *verifying and updating
+a map*. Do not walk the project tree on disk.
+
+### Stage 2 — Schema: the intended graph
+
+For each type from Stage 1: \`maad_schema <type>\`. Build two tables as you
+go:
+
+1. **Type table** — required fields, enums (the project's controlled
+   vocabularies), indexed fields (what the project's builders expected to
+   query — intent fossilized in config).
+2. **Edge table** — every \`ref\` / \`list[ref]\` field: source type, field
+   name, target type. This is the **intended** graph, before you've looked
+   at a single record.
+
+Note the file-strategy signal: types whose records are few but block-heavy
+are transaction-pattern (entries appended under parents — see
+\`_skills/schema-guide.md\`); their real "record count" is blocks, not files,
+and their parent ref is usually the corpus's highest-volume edge.
+
+### Stage 3 — Samples: the actual records
+
+Per type, cheapest first:
+
+- \`maad_get <sample-id> hot\` on 1–2 samples — do real records fill the
+  schema's fields? Sparse optional fields here foreshadow a sparse graph.
+- \`maad_query\` with a projection of 3–4 key fields, small limit — the
+  spread, not just the sample (status distributions, date ranges).
+- \`maad_get <id> cold\` on **one or two** records total, for narrative
+  texture: are bodies annotated (\`[[type:value|label]]\`)? Do they name
+  other records in prose?
+- \`maad_search primitive=entity limit=20\` (then other primitives that the
+  domain suggests) — is the annotation layer in active use, and with which
+  subtypes? Remember frontmatter string fields index as \`primitive=entity,
+  subtype=<field-name>\`, so search results mix field values and body
+  annotations; the subtype tells you which.
+- Where \`maad_describe\` said semantic search is enabled,
+  \`maad_semantic_search\` with 2–3 domain phrases is a cheap probe for
+  themes the schema doesn't capture. Degraded responses say so — fall back
+  without guessing.
+
+### Stage 4 — Related and paths: the realized graph
+
+Now compare the intended graph (Stage 2) with reality.
+
+1. **Measure edge usage with aggregates, not iteration.** For each edge in
+   the Stage 2 table: \`maad_aggregate docType=<source> groupBy=<ref-field>\`.
+   Group count ≈ how many distinct targets are actually referenced; a
+   near-empty result means a declared-but-unused edge. This also hands you
+   the **hubs** — target IDs with the largest groups.
+2. **Walk the hubs.** For the top 2–3 hubs: \`maad_related direction=both\`,
+   then
+
+   \`\`\`
+   maad_relationship_paths
+     startDocId: <hub>
+     direction: both
+     maxDepth: 2
+   \`\`\`
+
+   Organize by \`nodes[].distance\`. Check \`truncation.truncated\` /
+   \`limitsReached\` before concluding anything about reach — a truncated
+   traversal is a lower bound.
+3. **Probe the observed-vs-intended gap.** Re-run one hub's paths with
+   \`extractionKinds: ["ref", "mention"]\`. Many \`mention\` edges beyond the
+   \`ref\` edges = structure living in prose = densification opportunity
+   (that's the graph/ontology skill's Recipe 4 — record it, don't fix it
+   mid-mapping). Few mentions *and* few refs on a corpus whose bodies
+   clearly name other records (Stage 3) = links invisible to tooling
+   entirely; note that too.
+4. Cross-type detail questions that surface here ("which open cases belong
+   to which client industry?") are \`maad_join\` / ref-chain
+   \`maad_aggregate\` one-liners — use them to spot-check, resist per-record
+   loops.
+
+### Stage 5 — Integrity: where the graph is broken
+
+- \`maad_find_orphans\` — per-record broken-ref inventory (which ref fields
+  point at nonexistent targets).
+- \`maad_verify mode=integrity\` — the wider sweep (index/document drift,
+  schema drift) — cheap insurance that what you just mapped is what's
+  actually on disk, especially if the project sees external edits.
+
+Findings go **in the map**, not into ad-hoc repair: repair tools follow
+dry-run-then-confirm contracts and deserve a deliberate pass, and on
+read-only deployments mutation isn't yours to do (\`READ_ONLY\` — report,
+don't retry).
+
+### Stage 6 — Write the typed map
+
+Deliverable: \`_skills/local/corpus-map.md\` — a project-owned overlay file
+(engine refresh never touches it). Create or update; if one existed
+(Stage 1), preserve its history notes and update the snapshot. Suggested
+shape:
+
+\`\`\`markdown
+# Corpus Map — <project> (as of <date>)
+
+## Types
+| type | count* | pattern | purpose (one line) | key fields |
+
+## Edges (intended vs realized)
+| ref field | source → target | declared | usage (aggregate) | mention overflow? |
+
+## Annotation practice
+Primitives/subtypes in active use; whether doc-ID mentions are annotated.
+
+## Hubs
+Top hub records and what clusters around them (path-walk findings).
+
+## Hygiene
+Broken refs / orphans / drift found in Stage 5. Unfixed — inventory only.
+
+## Not explored
+Types sampled shallowly, truncated traversals, stages skipped.
+
+## Open questions
+Anything the corpus couldn't answer about itself.
+
+*counts verified via maad_verify mode=count on <date>
+\`\`\`
+
+The map is a **snapshot of project truth, owned by the project** — exactly
+what \`_skills/local/\` is for. It is not engine documentation; never put
+engine-version facts in it (they rot — \`MAAD.md\` owns those).
+
+If you lack writer access, deliver the same content as your session report.
+
+## After the map — handoffs
+
+- Sparse realized graph, rich mention/prose links → load the
+  graph/ontology skill (\`_skills/graph-ontology.md\`) and run its
+  densification recipe against the map's "mention overflow" column.
+- Schema gaps or evolution needs → Architect mode
+  (\`_skills/architect-core.md\` + \`_skills/schema-guide.md\`).
+- Broken refs / drift → a deliberate hygiene pass with the repair tools'
+  dry-run contracts; the map's Hygiene section is its worklist.
+
+## Non-goals / hand off to the host
+
+- No visualization: the map is markdown tables. Rendering it as an
+  interactive graph or dashboard is host-side work — never engine core.
+- No repair during mapping — inventory only (Stage 5).
+- No schema edits during mapping — the map may *recommend*; Architect
+  executes.
+- No file-system spelunking — if a question can't be answered through the
+  tool surface, that inability is itself a finding for the map.
+`;
+}
+//# sourceMappingURL=corpus-explorer.js.map

package/dist/skills/corpus-explorer.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"corpus-explorer.js","sourceRoot":"","sources":["../../src/skills/corpus-explorer.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,wEAAwE;AACxE,+EAA+E;AAE/E,MAAM,UAAU,2BAA2B;IACzC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwNR,CAAC;AACF,CAAC"}

package/dist/skills/graph-ontology.d.ts

@@ -0,0 +1,2 @@
+export declare function generateGraphOntologySkill(): string;
+//# sourceMappingURL=graph-ontology.d.ts.map

package/dist/skills/graph-ontology.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"graph-ontology.d.ts","sourceRoot":"","sources":["../../src/skills/graph-ontology.ts"],"names":[],"mappings":"AAIA,wBAAgB,0BAA0B,IAAI,MAAM,CAwPnD"}

package/dist/skills/graph-ontology.js

@@ -0,0 +1,253 @@
+// ============================================================================
+// Graph / Ontology skill — managed instruction generator (fully static).
+// ============================================================================
+export function generateGraphOntologySkill() {
+    return `# Working the Project as a Typed Graph
+
+> Managed by the MAADb engine — do not edit (changes block future refreshes).
+> Project-specific ontology conventions belong in \`_skills/local/ontology.md\`.
+> Findings and densification notes go there too — never append them to this file.
+
+## Purpose
+
+You are an agent operating on a MAADB project. This skill teaches you to
+treat the project as a **typed information graph**: to read structure that
+already exists, to choose the right traversal tool for each question, and to
+**densify** the graph — promoting links that live only in prose into typed,
+queryable structure. The engine gives you bounded graph primitives; you are
+the query planner and the ontologist.
+
+Audience: any agent with at least reader access. Densification recipes
+(Recipes 4–5) additionally need writer access and — for schema changes — the
+Architect channel described in \`_skills/architect-core.md\`.
+
+## When to load this skill
+
+- You need to answer connection questions: "how is X related to Y?",
+  "what depends on this record?", "walk the chain from case to industry."
+- You are building a report or view that spans record types.
+- You notice the project is **link-poor**: records reference each other in
+  body text but \`maad_related\` returns little — structure exists in prose
+  but not in the graph.
+- You are establishing or extending naming/linking conventions for a project
+  (light ontology work).
+
+For first-contact orientation in a project you don't know at all, load
+\`_skills/corpus-explorer.md\` first — it ends where this skill begins.
+
+## The graph model — what an edge is
+
+The engine derives edges from markdown; SQLite rows are derived data and
+reindex rebuilds them. There are exactly two edge kinds:
+
+1. **\`ref\` edges** — frontmatter fields of type \`ref\` (or \`list\` with
+   \`item_type: ref\`). Typed by the **field name** (\`client\`, \`parent_case\`,
+   \`assigned_attorney\`). This is the *intentional* graph: schema-declared,
+   validated, queryable, joinable. Evidence origin is the field; source
+   line/block evidence is null.
+2. **\`mention\` edges** — inline annotations \`[[type:value|label]]\` whose
+   value is a doc ID with a registered prefix (e.g.
+   \`[[identifier:cli-001|the client]]\`). This is the *observed* graph:
+   extracted from prose, carrying line and block evidence, but not schema-
+   validated. Plain prose that names a record without an annotation creates
+   **no edge at all**.
+
+The density gradient — prose → annotated mention → typed ref — is the core
+of this skill. Each promotion step makes a link more queryable and more
+verifiable.
+
+## Choosing the traversal tool
+
+| Question shape | Tool | Why |
+|---|---|---|
+| "What touches this one record?" (1 hop) | \`maad_related\` | Cheapest neighborhood read; direction \`outgoing\` / \`incoming\` / \`both\` (default \`both\`) |
+| "How does A connect to B?" / "what's within N hops?" / "show me the evidence" | \`maad_relationship_paths\` | Bounded multi-hop BFS, deterministic, cycle-safe, returns per-edge evidence and per-node distance |
+| "Give me these fields from many records *and* their ref targets" | \`maad_join\` | One call instead of query → get → get (N+1) chains |
+| "Roll up a metric across a ref hop" ("cases per client industry") | \`maad_aggregate\` with a ref-chain \`groupBy\` (\`"client->industry"\`) | Group-by resolves refs at query time; never iterate records to count |
+| "Where is this record *mentioned* in prose?" | \`maad_search\` with \`primitive=identifier\` and \`value=<docId>\` (or \`primitive=entity\` + matching \`subtype\`), or \`maad_relationship_paths\` with \`extractionKinds: ["ref","mention"]\` | Mentions are opt-in on path traversal; search requires \`primitive\` and finds the raw extracted objects |
+
+Two defaults that will bite you if unexamined:
+
+- \`maad_related\` defaults to direction \`both\`; \`maad_relationship_paths\`
+  defaults to \`outgoing\`. When a path result looks mysteriously empty, check
+  direction first — dependency questions ("what refs this?") need
+  \`incoming\` or \`both\`.
+- \`maad_relationship_paths\` traverses **\`ref\` edges only by default**.
+  Mentions are opt-in via \`extractionKinds: ["ref", "mention"]\`. If you are
+  probing the *observed* graph, you must opt in.
+
+Bounds (validated, over-cap values are rejected, not clamped): \`maxDepth\`
+default 2, cap 4 · \`maxNodes\` 50/100 · \`maxEdges\` 100/200 · \`maxPaths\`
+25/50. If a response trips the byte-size guard, narrow with \`fieldLabels\`
+or \`extractionKinds\`, or lower the limits — don't retry as-is.
+
+## Recipes
+
+### Recipe 1 — Typed neighborhood of one record
+
+Goal: everything structurally connected to \`cas-012\`, with meaning.
+
+1. \`maad_get cas-012 hot\` — its own typed fields.
+2. \`maad_related docId=cas-012 direction=both\` — 1-hop adjacency; note the
+   **field names** on each edge (they are your edge types).
+3. Where you need target detail for several neighbors of the same type,
+   don't loop \`maad_get\` — use \`maad_join\` on the source type with
+   \`refFields\` (Recipe 6).
+4. Only escalate to \`maad_relationship_paths\` if 1 hop is insufficient.
+
+### Recipe 2 — Connection between two specific records
+
+Goal: does \`cas-012\` connect to \`con-007\`, and through what?
+
+\`\`\`
+maad_relationship_paths
+  startDocId: cas-012
+  targetDocId: con-007
+  direction: both
+  maxDepth: 3
+\`\`\`
+
+Read the result as claims with proof: each edge carries \`fieldLabel\`,
+extraction kind, and canonical evidence (source line + block for mentions;
+field origin for refs). When you report the connection, cite the doc IDs on
+the path — and for mention-backed hops, treat the link as *observed, not
+validated* and say so.
+
+A \`state: missing\` node on a path is a **broken ref** — the edge exists but
+the target doesn't. Report it (and see Recipe 7); missing targets are
+terminal, so real connectivity may be wider than what a broken hop shows.
+
+### Recipe 3 — Bounded exploration outward from a hub
+
+Goal: the working set within 2 hops of a central record.
+
+\`\`\`
+maad_relationship_paths
+  startDocId: cli-001
+  direction: both
+  maxDepth: 2
+  fieldLabels: [client, parent_case]     # optional: only these edge types
+\`\`\`
+
+Use \`nodes[].distance\` to organize the result into rings. Check
+\`truncation.truncated\` and \`limitsReached\` **before** summarizing — a
+truncated traversal is a lower bound, not a census, and your summary must
+say which limit was hit if one was.
+
+### Recipe 4 — Promote prose links to typed structure (densification)
+
+Goal: links that exist only in narrative become schema-typed refs.
+
+1. **Find candidates.** Probe the observed graph:
+   \`maad_relationship_paths\` from key records with
+   \`extractionKinds: ["ref","mention"]\`, \`maxDepth: 1\` — every \`mention\`
+   edge is a candidate. Corpus-wide, \`maad_search\` with
+   \`primitive=identifier\` and \`value=<docId>\` (required \`primitive\` —
+   omit it and the call fails \`INVALID_PRIMITIVE\`) inventories where each
+   hub is mentioned. (Prose links with no annotation at all are invisible
+   to tools — surfacing those is judgment work while reading \`cold\` bodies.)
+2. **Decide if the link is structural.** Promote when the relationship is:
+   queried or filtered on; needed in joins/aggregates; integrity-relevant
+   (should break loudly if the target vanishes); or cardinality-stable
+   (every case has a client). Leave as mention/prose when it's incidental
+   commentary.
+3. **Type it.** If a suitable \`ref\` field exists in the schema, done. If
+   not, this is a schema change — an **additive** new \`ref\` field (with
+   \`target\` and \`index: true\`) via the Architect channel
+   (\`_skills/architect-core.md\`): registry/schema edits go through the
+   deployment's approved channel, then \`maad_reload\`. Never write schema
+   files through record tools.
+4. **Set the field.** \`maad_update\` per record (sequential; pass
+   \`expectedVersion\` when you hold a read), or \`maad_bulk_update\` for a
+   genuine batch. Keep the prose mention — you are adding structure, not
+   rewriting narrative.
+5. **Verify.** \`maad_related\` on a sample now shows the edge with the new
+   field label; \`maad_find_orphans docType=<type>\` catches typo'd targets
+   immediately.
+6. **Record the convention** in \`_skills/local/ontology.md\` (Recipe 5) so
+   the next agent types new records the same way.
+
+### Recipe 5 — Light ontology, MAADB-style
+
+An ontology here is **conventions, not a reasoner**:
+
+- **Classes** = registered doc types.
+- **Typed predicates** = \`ref\` field names. Name them as relations
+  (\`parent_case\`, \`assigned_attorney\`), not generically (\`link1\`, \`related\`).
+  The field name is the only edge label the graph has — spend it well.
+- **Controlled vocabularies** = \`enum\` fields.
+- **Annotation vocabulary** = the 11 fixed primitives plus registry
+  \`extraction.subtypes\` (e.g. \`attorney: entity\`). Subtypes make
+  \`maad_search\` domain-aware without engine changes.
+
+The ontology's *documentation* lives in \`_skills/local/ontology.md\` — a
+project-owned overlay file you create and maintain (it survives engine
+refreshes). Keep it short and normative: one table of types, one table of
+ref fields with their meaning and cardinality, the subtype vocabulary, and
+the annotation policy ("always annotate doc-ID mentions in prose as
+\`[[identifier:<docId>|label]]\`" is the single highest-leverage rule, because
+it feeds Recipe 4's candidate pipeline).
+
+Schema *changes* implied by ontology work are Architect work — hand off to
+\`_skills/architect-core.md\`; do not duplicate its channel rules here.
+
+### Recipe 6 — Cross-type reports and views
+
+Row-level view ("open cases with client name and industry"):
+
+\`\`\`
+maad_join
+  docType: case
+  filters: { status: open }
+  refs: [client]
+  fields: [title, status, opened_at]
+  refFields: { client: [name, industry] }
+\`\`\`
+
+Rollup ("case count by client industry"):
+
+\`\`\`
+maad_aggregate
+  docType: case
+  groupBy: "client->industry"
+  filters: { status: open }
+\`\`\`
+
+Compose the two into a markdown report (summary table from \`aggregate\`,
+detail table from \`join\`) and — if the report should persist — write it as a
+record via \`maad_create\` in a report-ish doc type if the project has one.
+Ground every number you state: \`maad_verify mode=count\` (or \`mode=field\`)
+before presenting totals as fact. Rendering to anything richer than
+markdown, and publishing anywhere, is host work (see Non-goals).
+
+### Recipe 7 — Graph hygiene
+
+Run before *and* after densification passes:
+
+- \`maad_find_orphans\` — records whose ref fields point at nonexistent
+  targets (broken refs, per-record detail).
+- \`maad_verify mode=integrity\` — the broader sweep (index drift, schema
+  drift, broken refs) after pulls or external edits.
+- \`maad_validate\` after any schema evolution — see \`_skills/schema-guide.md\`
+  § versioning for the migrate-or-grandfather discipline.
+
+A densification pass that introduces broken refs has made the graph *worse*
+— typed-but-wrong beats untyped only if you catch it, which is why Recipe 4
+ends in \`maad_find_orphans\`.
+
+## Non-goals / hand off to the host
+
+- **No visualization here.** Emitting a small inline Mermaid/DOT sketch in
+  chat from path output is fine as ordinary agent output; anything
+  interactive, rendered, served, or saved as an artifact belongs to
+  host-side skills — never to \`@maadb/core\`.
+- **No query language.** You compose bounded primitives; there is no Cypher
+  and none is coming.
+- **No inference engine.** Do not invent transitive/derived edges and
+  present them as data — a multi-hop path is evidence of connection, not a
+  new fact. If a derived relationship matters, promote it explicitly
+  (Recipe 4) so it becomes a real, validated edge.
+- **No schema writes through record tools** — Architect channel only.
+`;
+}
+//# sourceMappingURL=graph-ontology.js.map

package/dist/skills/graph-ontology.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"graph-ontology.js","sourceRoot":"","sources":["../../src/skills/graph-ontology.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,yEAAyE;AACzE,+EAA+E;AAE/E,MAAM,UAAU,0BAA0B;IACxC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsPR,CAAC;AACF,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maadb/core",
-  "version": "0.14.0",
+  "version": "0.15.1",
   "description": "Markdown As A Database — treats markdown as the canonical data store, builds a queryable index, and gives LLMs deterministic read/write access.",
   "repository": {
     "type": "git",
@@ -48,10 +48,10 @@
     "node": ">=24.0.0"
   },
   "dependencies": {
-    "@modelcontextprotocol/sdk": "1.29.0",
+    "@modelcontextprotocol/sdk": "1.30.0",
     "better-sqlite3": "12.11.1",
     "gray-matter": "~4.0.3",
-    "js-yaml": "~4.3.0",
+    "js-yaml": "~4.3.1",
     "pino": "10.3.1",
     "simple-git": "3.36.0"
   },