mindforge-cc 9.0.0 → 10.0.0

package/.mindforge/intelligence/skill-gap-analyser.md

@@ -1,40 +0,0 @@
-# MindForge Intelligence — Skill Gap Analyser
-
-## Purpose
-Identify required/recommended skills for a phase, compare with installed
-skills, and report gaps before planning.
-
-## Run points
-1. `/mindforge:plan-phase` start
-2. `/mindforge:discuss-phase`
-3. `/mindforge:health`
-
-## Analysis flow
-1. Extract work signals from roadmap/context/requirements/architecture.
-2. Map work categories to required/recommended skills.
-3. Validate skills in manifest + filesystem + status.
-4. Report missing/deprecated required skills and mitigation options.
-
-## Category -> skill mapping
-- UI/UX -> accessibility (required), performance (recommended)
-- Database changes -> database-patterns (required), data-privacy (if PII)
-- API endpoints -> api-design (required), security-review (if auth)
-- Auth/payments/PII -> security-review (required), data-privacy (required for PII)
-- Performance work -> performance (required)
-- New feature -> testing-standards (required), documentation (recommended)
-
-## Gap definition
-A required skill is a gap if:
-- not present in MANIFEST
-- manifest path missing
-- marked deprecated with no replacement
-
-## Output
-Produce `Skill Gap Analysis` section with:
-- required skills table
-- recommended skills table
-- explicit gap count and options
-
-## Health mode
-In `/mindforge:health`, include org-level recommendation list using recent
-phase patterns and missing capability frequencies.

package/.mindforge/intelligence/smart-compaction.md

@@ -1,71 +0,0 @@
-# MindForge Intelligence — Smart Context Compaction
-
-## Purpose
-Replace truncation with structured extraction so future sessions preserve reasoning,
-constraints, and in-progress state.
-
-## Triggering and level selection
-Day 2 threshold (`70%`) remains valid and now invokes Day 5 Level 1.
-Level selection uses both context usage and session depth.
-
-- Light session (`<5` tasks): use Level 1 even when context is high.
-- Moderate session (`5-10` tasks): use Level 2 at `80%+`.
-- Deep session (`10+` tasks): use Level 2 at `75%+`.
-- Level 3 at `90%+` or urgent near-limit state.
-
-## Levels
-### Level 1 — Lightweight
-Quick checkpoint: update `STATE.md` and `HANDOFF.json` with next task.
-
-### Level 2 — Structured extraction
-Capture:
-- decisions made
-- discoveries
-- implicit knowledge
-- quality signals
-- precise in-progress state
-
-### Level 3 — Emergency extraction
-Capture minimum viable continuation context before hard limit.
-
-## Level 2 extraction protocol
-### Block A — Decisions made
-For each decision: what, why, alternatives ruled out, impact area, ADR need.
-
-### Block B — Discoveries
-For each finding: fact, location, significance, assumption impact.
-
-### Block C — Current task state
-Record plan id, completed steps, remaining steps, current file, and inconsistency state.
-
-### Block D — Implicit knowledge
-Capture quirks, environment facts, and workarounds.
-
-A knowledge item qualifies as a **quirk** if either:
-1. It contradicts documentation or expected tool behavior.
-2. A new agent reading only plans/personas would not infer it.
-
-### Block E — Quality signals
-Capture failed assumptions, friction patterns, quality gate root causes, and next-plan suggestions.
-
-## Level 2 HANDOFF schema additions
-- `decisions_made[]`
-- `discoveries[]`
-- `implicit_knowledge[]`
-- `quality_signals[]`
-- `in_progress.current_state`
-
-## Session restart protocol
-When loading Level 2 handoff:
-1. Print compact summary counts.
-2. Preload `implicit_knowledge` before plan execution.
-3. If `in_progress.current_state` is inconsistent, block execution and ask to resolve first.
-4. If user asks to inspect first, print first 50 lines of the inconsistent file inline.
-
-## Compaction quality metric
-Write one entry to `.mindforge/metrics/compaction-quality.jsonl`:
-- `decisions_captured`
-- `discoveries_captured`
-- `implicit_knowledge_items`
-- `quality_signals_captured`
-- `next_session_continuation_success` (auto-inferred from next session, nullable initially)

package/.mindforge/memory/MEMORY-SCHEMA.md

@@ -1,155 +0,0 @@
-# MindForge v2 — Knowledge Graph Schema
-
-## Overview
-
-The MindForge knowledge graph is built from five JSONL files — all append-only,
-all at `.mindforge/memory/`. Every entry has a consistent base schema plus
-type-specific fields.
-
-## Base schema (all entry types)
-
-```json
-{
-  "id":               "kb-uuid-v4",
-  "timestamp":        "ISO-8601",
-  "type":             "architectural_decision|code_pattern|bug_pattern|team_preference|domain_knowledge",
-  "topic":            "Short title (≤ 80 chars)",
-  "content":          "Full knowledge content (no limit)",
-  "source":           "Where this was captured: 'Phase 3 retro', 'Debug session 2026-01', 'Manual entry'",
-  "project":          "project-name from PROJECT.md",
-  "confidence":       0.0,
-  "tags":             ["tag1", "tag2"],
-  "linked_adrs":      ["ADR-007"],
-  "times_referenced": 0,
-  "last_referenced":  null,
-  "deprecated":       false,
-  "deprecated_by":    null
-}
-```
-
-## Type-specific schemas
-
-### `architectural_decision`
-
-Extended fields:
-
-```json
-{
-  "decision":     "Use argon2id for password hashing",
-  "rationale":    "bcrypt is showing its age; argon2id is the modern standard",
-  "alternatives": ["bcrypt", "scrypt", "pbkdf2"],
-  "phase_number": 3,
-  "adr_reference": "ADR-007"
-}
-```
-
-Capture trigger: Phase completion (ADR files extracted), `/mindforge:discuss-phase`
-
-### `code_pattern`
-
-Extended fields:
-
-```json
-{
-  "pattern_type": "good|anti-pattern",
-  "language":     "typescript",
-  "example_good": "// Code showing the correct pattern",
-  "example_bad":  "// Code showing the incorrect pattern (for anti-patterns)",
-  "applies_to":   ["auth", "database", "api"]
-}
-```
-
-Capture trigger: Smart compaction Block D, debug session root cause
-
-### `bug_pattern`
-
-Extended fields:
-
-```json
-{
-  "bug_category":   "auth|database|api|ui|performance|security",
-  "symptom":        "Login works in tests but fails in production with cookie errors",
-  "root_cause":     "httpOnly cookies require HTTPS; dev server was HTTP",
-  "fix":            "Enable HTTPS in dev or use secure: false in development only",
-  "prevention":     "Always configure cookie settings per-environment",
-  "severity_when_missed": "HIGH",
-  "recurrence_count": 1
-}
-```
-
-Capture trigger: Debug session completion, security findings, retrospective "what went wrong"
-
-### `team_preference`
-
-Extended fields:
-
-```json
-{
-  "preference_type": "style|tool|process|convention|architecture",
-  "applies_when":    "When implementing auth",
-  "preference":      "Always use argon2id, never bcrypt. See ADR-007.",
-  "strength":        "strong|moderate|weak",
-  "override_allowed": true
-}
-```
-
-Capture trigger: Retrospective "what should we keep doing", steering instructions,
-MINDFORGE.md changes from retrospective
-
-### `domain_knowledge`
-
-Extended fields:
-
-```json
-{
-  "domain":     "JWT security",
-  "tech_stack": ["node.js", "typescript"],
-  "knowledge":  "JWT access tokens should be short-lived (15 min). Refresh tokens in httpOnly cookies, not localStorage. Never decode JWT without verifying signature.",
-  "source_url": "https://auth0.com/docs/secure/tokens/json-web-tokens",
-  "verified_at": "2026-01-15"
-}
-```
-
-Capture trigger: Research engine output, `/mindforge:remember --add`
-
-## Confidence scoring
-
-Confidence (0.0–1.0) represents how strongly this knowledge should be applied:
-
-| Confidence | Meaning | How set |
-| :--- | :--- | :--- |
-| 0.9–1.0 | Strong team decision — always apply | Manual entry, strong steering, ADR |
-| 0.7–0.9 | Clear pattern — apply unless there's a reason not to | Retrospective, debug session |
-| 0.5–0.7 | Observed pattern — consider but verify | Smart compaction Block D |
-| 0.3–0.5 | Weak signal — informational only | Single observation |
-| < 0.3 | Hypothesis — don't apply proactively | Auto-captured, unverified |
-
-## Confidence reinforcement
-
-Each time an entry is referenced (retrieved and the advice was followed):
-
-```bash
-confidence = min(1.0, confidence + 0.05)
-times_referenced += 1
-```
-
-Each time an entry is contradicted (a different decision was made):
-
-```bash
-confidence = max(0.0, confidence - 0.10)
-```
-
-## Deprecation
-
-When a knowledge entry becomes outdated (e.g., team switches from argon2id to Passkeys):
-
-```json
-{
-  "deprecated": true,
-  "deprecated_by": "kb-uuid-of-newer-entry",
-  "deprecated_reason": "Superseded by WebAuthn/Passkeys approach (ADR-031)"
-}
-```
-
-Deprecated entries are never deleted — they are excluded from active retrieval
-but available for historical queries.

package/.mindforge/memory/engine/capture-protocol.md

@@ -1,36 +0,0 @@
-# MindForge v2 — Knowledge Capture Protocol
-
-## Purpose
-
-The Capture Engine automatically extracts valuable engineering knowledge from session artifacts to ensure that project-specific wisdom is preserved beyond a single handoff.
-
-## Capture Triggers
-
-MindForge monitors the following lifecycle events for knowledge extraction:
-
-1. **Phase Completion**: Extracting architectural decisions from `PROJECT.md` and phase retrospectives.
-2. **Hardened Debugging**: Capturing "root cause -> fix" patterns from completed debug reports.
-3. **Manual Command**: Using `/mindforge:remember --add` to explicitly record team preferences or domain knowledge.
-4. **ADR Generation**: Parsing newly created Architecture Decision Records.
-
-## Extraction Logic
-
-The extraction process (via `knowledge-capture.js`) involves:
-
-- **Structural Parsing**: Identifying standardized headings (e.g., "Decision", "Root Cause", "Pattern").
-- **Deduplication**: Checking for existing entries with similar content to prevent knowledge bloat.
-- **Initial Confidence**: Assigning a default confidence score (usually 0.5) to newly captured entries.
-- **Auto-Tagging**: Inferring tags based on the file path and content context (e.g., `#nodejs`, `#security`).
-
-## Inhibitors (What NOT to capture)
-
-To prevent the knowledge base from becoming "noisy", the system ignores:
-
-- Transient session state (e.g., local file counts).
-- Intermediate debugging steps that didn't lead to a fix.
-- Content marked with `#no-capture` or inside blocks labeled "Confidential".
-
-## Retention Policy
-
-- **Append-only**: Entries are never physically deleted.
-- **Deprecation**: Outdated entries are marked as `deprecated: true` and replaced by newer entries with the same `source_id`.

package/.mindforge/memory/engine/global-sync-spec.md

@@ -1,42 +0,0 @@
-# MindForge v2 — Global Knowledge Sync Specification
-
-## Purpose
-
-Allow knowledge to flow between projects via a machine-level global store.
-Team members can promote project-specific insights to their global knowledge base,
-which loads into every future project's session start.
-
-## Storage locations
-
-- **Project-local:** `.mindforge/memory/knowledge-base.jsonl` (per repo)
-- **Global (machine):** `~/.mindforge/global-knowledge-base.jsonl` (per developer)
-
-## Sync rules
-
-- Promotion is MANUAL — nothing is auto-promoted to global. Use `/mindforge:remember --promote [ID]`.
-- Loading is AUTOMATIC — global entries load at every session start if relevant.
-- Project entries take precedence over global entries (same ID = local wins).
-- Global entries receive a metadata flag `global: true` but are ranked alongside project entries based on relevance.
-
-## What should be promoted to global
-
-Good candidates for global promotion:
-
-- Language-agnostic security practices ("always validate input before database queries")
-- Technology-specific best practices learned through experience ("argon2id over bcrypt")
-- Universal debugging patterns ("check the timezone mismatch before blaming async code")
-- Cross-project architectural preferences ("Repository pattern over active record")
-
-## Global entry metadata
-
-When promoted to global, entries gain:
-
-```json
-{
-  "global": true,
-  "promoted_at": "ISO-8601",
-  "promoted_from_project": "saas-app",
-  "promoted_by": "git-config-user-email",
-  "global_applicability": "all|typescript|nodejs|react|[specific]"
-}
-```

package/.mindforge/memory/engine/retrieval-spec.md

@@ -1,44 +0,0 @@
-# MindForge v2 — Knowledge Retrieval Specification
-
-## Purpose
-
-The Retrieval Engine is responsible for identifying and loading the most relevant pieces of long-term memory into the current session context to improve agent performance and consistency.
-
-## Components
-
-- **Indexer (`knowledge-indexer.js`)**: Handles the scoring and ranking of knowledge entries.
-- **Session Loader (`session-memory-loader.js`)**: Orchestrates the loading of relevant memories at the start of a session.
-
-## Scoring Logic (TF-IDF + Heuristics)
-
-Relevance is calculated using a multi-factor scoring model:
-
-1. **Text Search (TF-IDF)**:
-    - Tokenizes the query and knowledge text.
-    - Calculates Term Frequency (TF) and Inverse Document Frequency (IDF).
-    - Entries must have a positive TF-IDF score to be considered relevant if keywords are present.
-
-2. **Confidence & Recency**:
-    - **Confidence Score**: Boosts entries with higher confidence levels (reinforced over time).
-    - **Recency Decay**: Prefer more recent knowledge entries, especially for bug patterns.
-
-3. **Tag Overlap**:
-    - Queries can include required tags (e.g., `#typescript`).
-    - Entries with matching tags receive a significant boost.
-
-4. **Inhibitors**:
-    - Deprecated entries are never retrieved.
-    - Low-confidence "noise" entries are filtered out.
-
-## Context Injection
-
-During session start, the loader:
-1. Performs a broad search based on the current project's primary technology stack and recent activities.
-2. Selects the top `N` (default 5-10) most relevant entries.
-3. Injects them into the agent's secondary context (e.g., as a dedicated "Memory context" block).
-
-## SDK Interface
-
-```typescript
-const relevantKnowledge = await memory.query("query string", ["#tag1"], 5);
-```

package/.mindforge/memory/sync-manifest.json

@@ -1,6 +0,0 @@
-{
-  "pattern-library.jsonl": {
-    "lastSync": "2026-04-11T15:30:35.299Z",
-    "localCount": 1
-  }
-}

package/.mindforge/metrics/METRICS-SCHEMA.md

@@ -1,42 +0,0 @@
-# MindForge Metrics — Schema Reference
-
-## Files
-- `session-quality.jsonl`
-- `phase-metrics.jsonl`
-- `skill-usage.jsonl`
-- `compaction-quality.jsonl`
-
-All files are append-only JSONL.
-
-## session-quality.jsonl fields
-- session_id, date, phase, developer_id
-- tasks_attempted, tasks_completed, tasks_failed
-- verify_pass_rate, quality_gates_failed
-- security_findings, context_compactions
-- skills_loaded_count, antipatterns_detected
-- session_quality_score, session_quality_score_raw
-
-Score formula:
-- base 100
-- minus task/gate/security/antipattern penalties
-- bonus for zero gate failures and zero security findings
-- keep both raw and clamped (`0-100`) score for trend analysis
-
-## phase-metrics.jsonl fields
-- phase lifecycle and delivery coverage
-- difficulty score
-- security and UAT outcomes
-- phase_quality_score
-
-## skill-usage.jsonl fields
-- date, phase, plan
-- skill_name, skill_version
-- trigger_type (`text_match|file_path_match|file_name_match`)
-- trigger_keyword
-- task_outcome, verify_passed_first_try
-
-## compaction-quality.jsonl fields
-- date, compaction_level, context_pct_at_compaction
-- decisions_captured, discoveries_captured
-- implicit_knowledge_items, quality_signals_captured
-- next_session_continuation_success (auto-inferred where possible)

package/.mindforge/metrics/quality-tracker.md

@@ -1,32 +0,0 @@
-# MindForge Metrics — Quality Tracker
-
-## Trend windows
-- short: last 5 sessions
-- medium: last 20 sessions
-- long: all sessions
-
-## Key targets
-- Verify pass rate > 85% (warning < 75%)
-- Task failure rate < 10% (warning > 20%)
-- Compactions < 1 per 8 tasks (warning > 2 per session)
-
-## Early warnings
-- quality score drop >= 10 points over 3 sessions
-- any CRITICAL security finding after clean streak
-- compaction overhead > 2/session
-- stale skills not triggered in 10 sessions
-
-## Quality metrics -> agent behaviour adjustment
-Automatic adjustments at session start:
-
-- If verify pass rate < 75% over last 3 sessions:
-  tighten verify-step determinism checks before execution.
-- If last-session task failure rate > 20%:
-  halve estimated scope and suggest splitting.
-- If compaction frequency > 2/session:
-  proactively summarize every 4 tasks.
-- If security findings trend worsens over 3 phases:
-  force-load `security-review` for all tasks in current phase.
-
-Always report adjustment to user:
-`Quality signal detected: [signal]. Adjusting behaviour: [adjustment].`

package/.mindforge/models/model-registry.md

@@ -1,48 +0,0 @@
-# MindForge v2 — Model Registry
-# Version: v2.0.0-alpha.3
-
-MindForge v2 uses a tiered multi-model architecture. Models are selected based on the task persona and difficulty tier.
-
-## 1. Primary Reasoning Tier (Tier 1)
-Used for complex architecture, planning, and high-stakes reasoning.
-
-- **Anthropic Claude 3.5 Opus** (`claude-3-opus-20240229`)
-  - Strengths: Deepest reasoning, highly reliable for planning.
-  - Persona mapping: `architect`, `planner`.
-  - Setting: `PLANNER_MODEL`.
-
-- **OpenAI GPT-4o** (`gpt-4o`)
-  - Strengths: Fast reasoning, excellent tool use, adversarial insight.
-  - Persona mapping: `reviewer`, `security-reviewer`.
-  - Setting: `REVIEWER_MODEL`.
-
-## 2. Execution Tier (Tier 2)
-Used for the bulk of code implementation and transformation tasks.
-
-- **Anthropic Claude 3.5 Sonnet** (`claude-3-5-sonnet-20240620`)
-  - Strengths: Balanced speed/quality, best-in-class coding.
-  - Persona mapping: `developer`, `qa-engineer`.
-  - Setting: `EXECUTOR_MODEL`.
-
-- **Google Gemini 1.5 Pro** (`gemini-1.5-pro`)
-  - Strengths: 1M context window, deep codebase research.
-  - Persona mapping: `research-agent`.
-  - Setting: `RESEARCH_MODEL`.
-
-## 3. High-Security/Privacy Tier (Tier 3)
-Used for tasks involving authentication, PII, or financial operations.
-
-- **Anthropic Claude 3.5 Opus** (`claude-3-opus-20240229`)
-  - Setting: `SECURITY_MODEL`.
-
-## 4. Utility/Quick Tier (Tier 4)
-Used for low-ambiguity tasks and micro-transformations.
-
-- **Anthropic Claude 3.5 Haiku** (`claude-3-5-haiku-20241022`)
-  - Setting: `QUICK_MODEL`.
-
-## 5. Fallback Chain
-If a primary model is unavailable (API key missing or 429), follow these defaults:
-1. `gpt-4o` → `claude-3-5-sonnet`
-2. `claude-3-opus` → `gpt-4o`
-3. `gemini-1.5-pro` → `claude-3-5-sonnet` (limited context)

package/.mindforge/models/model-router.md

@@ -1,30 +0,0 @@
-# MindForge v2 — Model Router
-# Version: v2.0.0-alpha.3
-
-## Routing Logic
-
-The MindForge router resolves which model to use at task dispatch time using this algorithm:
-
-1. **Check Persona:** Map the task `<persona>` to a setting key.
-   - `developer` → `EXECUTOR_MODEL`
-   - `architect` → `PLANNER_MODEL`
-   - `security-reviewer` → `SECURITY_MODEL`
-   - `qa-engineer` → `QA_MODEL`
-   - `research-agent` → `RESEARCH_MODEL`
-   - `debug-specialist` → `DEBUG_MODEL`
-   - `unknown` → `EXECUTOR_MODEL`
-
-2. **Check Tier Override:**
-   - If `tier == 3` (Security/Privacy), force `SECURITY_MODEL` regardless of persona.
-
-3. **Check Budget Bias:**
-   - If `difficulty < 2.0` and `MODEL_PREFER_CHEAP_BELOW_DIFFICULTY` is set:
-     - Use `QUICK_MODEL` instead of the resolved model.
-
-4. **Resolve Model ID:**
-   - Read the setting key from `MINDFORGE.md`.
-   - Use baked-in defaults if not present.
-
-5. **Verify Availability:**
-   - Check if matching `[PROVIDER]_API_KEY` is present in environment.
-   - If missing: Apply fallback chain from `model-registry.md`.

package/.mindforge/monorepo/cross-package-planner.md

@@ -1,114 +0,0 @@
-# MindForge — Cross-Package Planner
-
-## Purpose
-When a phase spans multiple packages in a monorepo, coordinate execution
-so that shared dependencies are built and tested before packages that
-depend on them.
-
-## Execution order algorithm
-
-```
-Given: a set of packages involved in the current phase
-       and their inter-package dependencies
-
-Algorithm: topological sort of package dependency graph
-
-Input: WORKSPACE-MANIFEST.json dependency_order
-Output: ordered list of packages to process
-
-Example:
-  Phase touches: @myapp/api, @myapp/shared, @myapp/web
-  Dependencies: api→shared, web→shared, web→api
-  Topological order: shared → api → web
-  
-  Execution: 
-    Wave 1: process @myapp/shared (no dependencies on other changed packages)
-    Wave 2: process @myapp/api (depends on Wave 1: shared)
-    Wave 3: process @myapp/web (depends on Wave 2: api + Wave 1: shared)
-```
-
-## Per-package PLAN file routing
-
-When PLAN files are created for a monorepo phase, each plan specifies its target package:
-
-```xml
-<task type="auto">
-  <n>Add auth middleware to API</n>
-  <package>@myapp/api</package>
-  <working-dir>apps/api</working-dir>
-  <files>
-    apps/api/src/middleware/auth.ts
-    apps/api/src/middleware/auth.test.ts
-  </files>
-  <action>...</action>
-  <verify>cd apps/api && npm test -- --testPathPattern=auth.middleware</verify>
-  <done>Auth middleware tests passing in apps/api</done>
-</task>
-```
-
-## Cross-package test execution
-
-After all packages in the phase are processed:
-```bash
-# Run tests across all affected packages
-AFFECTED_PACKAGES=$(cat .planning/WORKSPACE-MANIFEST.json | \
-  node -e "const m=JSON.parse(require('fs').readFileSync('/dev/stdin','utf8')); \
-  console.log(m.packages.map(p=>p.path).join(' '))")
-
-for PKG_PATH in ${AFFECTED_PACKAGES}; do
-  echo "Testing ${PKG_PATH}..."
-  cd "${PKG_PATH}" && npm test && cd -
-done
-
-# Run integration tests from root (if configured)
-[ -f "package.json" ] && npm run test:integration 2>/dev/null || true
-```
-
-## Affected package detection (revised)
-
-```bash
-# CORRECTED: Match against declared package paths, not assume 2-level depth
-detect_affected_packages() {
-  local MANIFEST=".planning/WORKSPACE-MANIFEST.json"
-
-  if [ ! -f "${MANIFEST}" ]; then
-    echo "Run /mindforge:workspace detect first"
-    return 1
-  fi
-
-  # Get list of changed files
-  CHANGED_FILES=$(git diff --name-only HEAD~1 2>/dev/null || git diff --cached --name-only)
-
-  # For each package in manifest, check if any changed file is within that package
-  node -e "
-    const fs = require('fs');
-    const manifest = JSON.parse(fs.readFileSync('${MANIFEST}', 'utf8'));
-    const changedFiles = \`${CHANGED_FILES}\`.split('\n').filter(Boolean);
-
-    const affected = new Set();
-    manifest.packages.forEach(pkg => {
-      // Check if any changed file is within this package's path
-      const pkgPath = pkg.path.replace(/\/$/, ''); // remove trailing slash
-      changedFiles.forEach(file => {
-        if (file.startsWith(pkgPath + '/') || file === pkgPath) {
-          affected.add(pkg.name);
-        }
-      });
-    });
-
-    // Also add packages that depend on affected packages
-    manifest.packages.forEach(pkg => {
-      if (pkg.dependencies && pkg.dependencies.some(dep => affected.has(dep))) {
-        affected.add(pkg.name);
-      }
-    });
-
-    console.log([...affected].join('\n'));
-  "
-}
-```
-
-This correctly handles:
-- Packages at any nesting depth (`libs/shared/utils/` → 3 levels deep)
-- Packages whose path is a prefix of another (avoid false matches)
-- Transitive dependencies (packages that depend on changed packages)