Doramagic Project Pack ยท Human Manual

edgequake

EdegQuake ๐ŸŒ‹ High-performance GraphRAG inspired from LightRag written in Rust; Transform documents into intelligent knowledge graphs for superior retrieval and generation

Overview & System Architecture

Related topics: Core Pipeline & Data Flow, Configuration, Deployment & Operations

Section Related Pages

Continue reading this section for the full explanation and source context.

Related topics: Core Pipeline & Data Flow, Configuration, Deployment & Operations

Overview & System Architecture

Project Purpose & Scope

EdgeQuake is a production-grade Retrieval-Augmented Generation (RAG) framework written primarily in Rust, with companion web and protocol layers in TypeScript. The project is "inspired by LightRAG and designed to bring its powerful concepts to production-grade Rust infrastructure" Source: edgequake/README.md.

The repository is a multi-crate workspace organized around a single capability: ingesting documents, extracting entities and relationships, building a queryable knowledge graph, and serving natural-language answers grounded in that graph. Beyond the core engine, the repository ships:

  • A Next.js 16 / React 19 web console for graph exploration, document management, and streaming queries Source: edgequake_webui/README.md.
  • A Model Context Protocol (MCP) server that exposes the same capabilities to MCP-compatible agents Source: mcp/README.md.
  • A standalone Rust PDF-to-Markdown converter with optional vision-LLM OCR Source: legacy/edgequake-pdf/README.md.
  • Official TypeScript and PHP SDKs.

Releases follow a tight cadence (v0.12.4 through v0.12.11 documented in the community context), each shipping a Docker quickstart via quickstart.sh and a Docker Compose manifest.

System Components

The architecture is composed of loosely coupled crates and adjacent services. The edgequake-core crate holds the domain types โ€” Document, Entity, workspace/tenant request objects โ€” while the API server, storage adapters, and embedding providers live in sibling crates. The web console and MCP server sit in front of the HTTP API rather than in-process.

flowchart LR
    subgraph Clients
        UI[Next.js WebUI<br/>edgequake_webui]
        MCP[MCP Server<br/>mcp]
        SDK[TS / PHP SDKs<br/>sdks/*]
    end
    subgraph EdgeQuake Engine [Rust Workspace: edgequake/]
        API[edgequake-api<br/>REST + OpenAPI]
        CORE[edgequake-core<br/>Document, Entity, Pipeline]
        LLM[edgequake-llm<br/>Providers + Embeddings]
        STORAGE[edgequake-storage<br/>Postgres + pgvector]
    end
    PDF[edgequake-pdf<br/>PDF โ†’ Markdown]
    PG[(PostgreSQL + pgvector + Apache AGE)]
    OLLAMA[(Ollama / OpenAI / Compatible)]

    UI -->|HTTP| API
    MCP -->|stdio / HTTP| API
    SDK -->|HTTP| API
    PDF --> CORE
    API --> CORE
    CORE --> LLM
    CORE --> STORAGE
    STORAGE --> PG
    LLM --> OLLAMA

Source: edgequake/README.md, edgequake_webui/README.md, mcp/README.md.

Core Data Model

The processing pipeline centers on three domain primitives:

  • Document โ€” a unit of text ingested into the system, carrying a lifecycle DocumentStatus (Pending โ†’ Processing โ†’ Processed/Failed). The status enum exposes can_process() for retry eligibility and is_terminal() for completion checks Source: edgequake/crates/edgequake-core/src/types/document.rs.
  • Entity โ€” a named, type-labeled node. Construction normalizes the name into a stable id and uppercases the type (PERSON, ORGANIZATION, โ€ฆ). Each entity aggregates provenance via a pipe-delimited source_id field Source: edgequake/crates/edgequake-core/src/types/entity.rs.
  • Workspace / Tenant โ€” CreateWorkspaceRequest carries LLM and embedding configuration per workspace, including entity_types domain presets (General, Manufacturing, Healthcare, Legal, Research) and the entity_types_strict flag controlling whether unknown types collapse to OTHER Source: edgequake/crates/edgequake-core/src/types/multitenancy/requests.rs.

The pipeline also runs a keyword_extractor step that prompts an LLM with a structured template to derive high- and low-level keywords from the user query before retrieval Source: edgequake/crates/edgequake-core/src/keyword_extractor.rs.

Storage, Retrieval & Integration Layer

Persistence is built on PostgreSQL with two extensions acting as the two halves of the graph-RAG storage substrate:

The MCP server (@modelcontextprotocol/sdk ^1.12.1) exposes tools such as document_upload_file accepting .txt, .md, and .pdf payloads, and operates against per-workspace knowledge graphs that are isolated server-side Source: mcp/README.md, mcp/package.json. The TypeScript SDK ships as a pnpm-managed package with tsup bundling and vitest for tests Source: sdks/typescript/package.json.

Known Limitations Highlighted by the Community

Several recent issues reflect recurring friction in this architecture and are worth noting for new operators:

  • Compile-time model catalog. The LLM/embedding model list served at /api/v1/models/* is compiled into the binary via include_str! and is not overridable at runtime, so adding a locally installed Ollama model currently requires rebuilding the image (issue #251).
  • Model name prefixing. OpenAI-compatible providers auto-prepend the provider name to the model string; users want the prefix skipped when the model already contains a / (issue #255).
  • Full-graph rebuild for new entity types. Adding custom entity types to existing documents currently rebuilds the entire knowledge graph rather than deriving only the new entities (issue #252).
  • Document re-upload flow. After updating to newer versions, replacing an existing document fails silently in the UI (issue #253).
  • UI/API version drift. The API reports v0.12.11 while the UI footer shows a different version (issue #250).

These issues all sit at the boundary between configuration, pipeline, and presentation layers shown in the architecture diagram above.

See Also

  • EdgeQuake Core Types โ€” edgequake/crates/edgequake-core/src/types/
  • MCP Server Specification โ€” mcp/docs/SPEC.md
  • pgvector Reference โ€” zz-reference/001-pgvector/
  • Apache AGE Reference โ€” zz-reference/002-apache-age/

Source: https://github.com/raphaelmansuy/edgequake / Human Manual

Core Pipeline & Data Flow

Related topics: Overview & System Architecture, Configuration, Deployment & Operations

Section Related Pages

Continue reading this section for the full explanation and source context.

Section Docker Quickstart

Continue reading this section for the full explanation and source context.

Section WebUI Development Setup

Continue reading this section for the full explanation and source context.

Section SDK Runtime Requirements

Continue reading this section for the full explanation and source context.

Related topics: Overview & System Architecture, Configuration, Deployment & Operations

Core Pipeline & Data Flow

Overview

EdgeQuake exposes a two-direction data flow. The ingestion pipeline turns raw documents (.txt, .md, .pdf) into a workspace-scoped knowledge graph of entities, relationships, chunks, and embeddings. The query pipeline turns a user question into keyword-augmented retrieval over that graph and renders a citation-backed answer. Both pipelines operate within a single workspace, the unit of isolation enforced by the API (edgequake/crates/edgequake-core/src/types/multitenancy/requests.rs). Each workspace owns its own LLM provider, embedding model, and entity-type vocabulary, so configuration cannot leak across graphs.

Ingestion Pipeline (Document โ†’ Graph)

Ingestion is reported to the UI as a sequence of typed stages so the client can render progress deterministically. Source: edgequake_webui/src/lib/utils/progress-formatter.ts:1-50 (ChunkProgress, PdfProgress, IngestionStage, IngestionProgress).

The conceptual flow is:

flowchart LR
    A[Upload .txt / .md / .pdf] --> B[Parse to Markdown]
    B --> C[Chunker]
    C --> D[Entity & Relation Extraction]
    D --> E[Embedding Generation]
    E --> F[(Graph + Vector Store)]
    F --> G[Workspace Graph]
  1. Parse โ€“ Plain text and Markdown are passed through; PDFs are converted to Markdown by edgequake-pdf, which performs character-level positioning, bold/italic detection, multi-column layout analysis, and optional GPT-4o-mini image OCR. Source: legacy/edgequake-pdf/README.md:1-40.
  2. Chunk โ€“ Documents are split into chunks with stable IDs derived from content. Each chunk carries tokens, chunk_order_index, source full_doc_id, optional file_path, and lineage position metadata (start_line, end_line, start_offset, end_offset). Source: edgequake/crates/edgequake-core/src/types/chunk.rs:1-80.
  3. Extract โ€“ LLM-based extraction produces entities and relationships; the entity_types request field constrains the schema (e.g., PERSON, ORGANIZATION, MANUFACTURING, HEALTHCARE, LEGAL, RESEARCH). Source: edgequake/crates/edgequake-core/src/types/multitenancy/requests.rs:1-80.
  4. Embed โ€“ Chunks and entities are vectorized by the workspace embedding model; the dimension is recorded on the chunk for later retrieval.
  5. Store โ€“ Entities, relationships, chunks, and embeddings are persisted in PostgreSQL with pgvector for vectors and Apache AGE for graph traversals (per the zz-reference/001-pgvector and zz-reference/002-apache-age indexes).

Entities are normalized to a stable id (uppercased, whitespace-collapsed) and accumulate source_ids with pipe separators so a single entity can be traced back to every chunk that produced it. Source: edgequake/crates/edgequake-core/src/types/entity.rs:1-60. This is the foundation of the lineage feature surfaced by the TypeScript SDK (client.lineage, client.provenance). Source: sdks/typescript/README.md:1-40.

Query Pipeline (Question โ†’ Answer)

Queries flow from the WebUI chat interface through the chat SDK resource, which proxies to /api/v1/query. The pipeline has three observable phases:

  1. Keyword extraction โ€“ The LLM is prompted to return JSON with high_level_keywords (2โ€“5 themes) and low_level_keywords (3โ€“8 specifics), following a few-shot template. Source: edgequake/crates/edgequake-core/src/keyword_extractor.rs:1-60.
  2. Hybrid retrieval โ€“ Keywords seed a combined vector + graph traversal; results are returned as a flat SourceReference[] tagged with source_type โˆˆ {entity, relationship, chunk}.
  3. Response shaping โ€“ The UI mapper reshapes sources into a QueryContext with separate entities, relationships, and chunks arrays; unknown source_type values fall back to the chunks bucket by the business rule BR0715. Source: edgequake_webui/src/lib/utils/source-mapper.ts:1-60.

Citations travel with the response and are rendered inline in the chat transcript. When a conversation is exported to Markdown, each assistant message is followed by a collapsible `

Configuration, Deployment & Operations

Overview

EdgeQuake is a production-grade Retrieval-Augmented Generation (RAG) framework that combines knowledge-graph construction, multi-mode retrieval, and LLM-driven answer synthesis. Configuration, deployment, and operations span the API server, the Next.js-based WebUI, the Model Context Protocol (MCP) server, and language-specific SDKs (TypeScript, PHP). This page documents how to install EdgeQuake, configure its providers and workspaces, and operate it reliably, with attention to failure modes that have surfaced in community discussions.

Deployment

Docker Quickstart

The recommended install path is the one-command Docker installer, which avoids cloning the repository. Source: EdgeQuake v0.12.11 release notes.

# Interactive install (Docker only)
curl -fsSL https://raw.githubusercontent.com/raphaelmansuy/edgequake/edgequake-main/quickstart.sh | sh

# Or with plain Docker Compose
curl -fsSL https://raw.githubusercontent.com/raphaelmansuy/edgequake/edgequake-main/docker-compose.quickstart.yml | docker compose -f - up

The Docker quickstart has shipped consistently from v0.12.4 through v0.12.11, indicating a stable installation contract.

WebUI Development Setup

The WebUI is a Next.js 16 application using React 19 and Tailwind CSS. Source: edgequake_webui/README.md.

cd edgequake_webui
bun install              # or npm install
cp .env.local.example .env.local
bun run dev

The WebUI expects the API server at NEXT_PUBLIC_API_URL (default http://localhost:8080).

SDK Runtime Requirements

The MCP server requires Node.js โ‰ฅ18 and depends on @modelcontextprotocol/sdk, edgequake-sdk, and zod. Source: mcp/package.json. The TypeScript SDK declares the same Node โ‰ฅ18 baseline and uses [email protected] as its package manager. Source: sdks/typescript/package.json.

Configuration

Workspace Configuration

A workspace is the unit of isolation in EdgeQuake. Each workspace owns one knowledge graph (entities, relationships, documents) and its own LLM/embedding configuration; workspaces cannot share data. Source: mcp/README.md.

The CreateWorkspaceRequest builder is the canonical API for provisioning a workspace. It exposes fluent methods such as with_llm_model (accepting either "gemma3:12b" or fully-qualified "ollama/gemma3:12b") and domain presets for entity types. Source: edgequake/crates/edgequake-core/src/types/multitenancy/requests.rs.

PresetAdded Entity Types
GeneralPERSON, ORGANIZATION, LOCATION, EVENT, CONCEPT, TECHNOLOGY, PRODUCT, DATE, DOCUMENT
ManufacturingMACHINE, COMPONENT, DEFECT, MEASUREMENT, PROCESS, MATERIAL
HealthcareSYMPTOM, DRUG, DIAGNOSIS, PROCEDURE, PATIENT, CONDITION
LegalCONTRACT, CLAUSE, PARTY, REGULATION, JURISDICTION, CASE
ResearchPAPER, METHOD, DATASET, HYPOTHESIS, FINDING, METRIC

The entity_types_strict flag controls whether unknown extracted labels are remapped to OTHER/CONCEPT (default true) or allowed through.

Provider and Model Resolution

LLM and embedding providers are wired through environment variables such as EDGEQUAKE_LLM_PROVIDER. Community issue #255 reports that when this variable is set to an OpenAI-compatible provider (e.g., openai), the backend currently prepends the provider name to the model string. A requested enhancement is to skip that prefix when the model string already contains a / (e.g., a fully-qualified openai/gpt-4o). Source: Issue #255 โ€” Skip provider prefixing when model contains /.

A separate community report (Issue #251) notes that the bundled model catalog served by /api/v1/models/* and consumed by the UI model picker is compiled into the binary via include_str! and is not overridable at runtime. Adding a locally installed Ollama model today requires rebuilding the image from source. Source: Issue #251 โ€” models.toml is not overridable at runtime.

Entity Name Normalization

Entities are normalized at construction time to provide stable identifiers. The Entity::new constructor normalizes the entity name, upper-cases the entity type, and stores source IDs pipe-delimited. Source: edgequake/crates/edgequake-core/src/types/entity.rs.

Operations

Version Reporting

The WebUI footer version can lag the API-reported version. Issue #250 documents a v0.12.11 release where the API correctly reported v0.12.11 while the UI displayed a stale value. Source: Issue #250 โ€” UI Displays Incorrect Application Version. Operators should rely on /health or an explicit version endpoint when auditing deployed builds.

Error Categorization

The WebUI classifies failures into six categories โ€” llm, embedding, storage, pipeline, network, and unknown โ€” each with a transient flag and a remediation suggestion. Source: edgequake_webui/src/lib/error-categories.ts.

flowchart LR
  A[Raw error] --> B{Regex match}
  B -->|rate limit / 429| C[llm ยท transient]
  B -->|dim mismatch| D[embedding ยท not transient]
  B -->|connect refused| E[network ยท transient]
  B -->|parse / chunk| F[pipeline ยท not transient]
  B -->|db error| G[storage ยท transient]
  B -->|no match| H[unknown]

Common triggers include rate.?limit, too.?many.?requests, quota.?exceeded, and HTTP 429 for LLM-side rate limiting.

Progress and Upload Failures

Ingestion progress is normalized through a single formatter that produces human-readable durations and ETAs (e.g., 1h 1m, (ETA: 2m 30s)). Source: edgequake_webui/src/lib/utils/progress-formatter.ts.

Issue #253 reports an upload flow in which the client indicates the document is missing, prompts to replace an existing record, and then surfaces no progress after the user confirms โ€” a symptom most consistent with a server-side pipeline failure mapped to the pipeline or unknown category above. Source: Issue #253 โ€” Upload document error.

Graph Mutation Without Full Rebuilds

Issue #252 requests the ability to derive new entity types from existing documents without rebuilding the graph and re-embedding everything. This is currently a limitation: introducing a new custom entity label requires a full rebuild. Source: Issue #252 โ€” Derive new entities without rebuilding. Operators planning schema changes should budget for re-embedding costs.

See Also

Source: https://github.com/raphaelmansuy/edgequake / Human Manual

SDKs, APIs & Integrations

Related topics: Overview & System Architecture, Configuration, Deployment & Operations

Section Related Pages

Continue reading this section for the full explanation and source context.

Section TypeScript SDK

Continue reading this section for the full explanation and source context.

Section Kotlin SDK

Continue reading this section for the full explanation and source context.

Section WebUI as a Reference Client

Continue reading this section for the full explanation and source context.

Related topics: Overview & System Architecture, Configuration, Deployment & Operations

SDKs, APIs & Integrations

EdgeQuake exposes its knowledge-graph and RAG pipeline to external consumers through three coordinated surfaces: a Rust HTTP REST/WebSocket API, official typed SDKs, and the Model Context Protocol (MCP) server. The WebUI itself is built against the same REST surface, so anything the UI can do is reproducible from a third-party client. This page maps out each surface, the available endpoints, and the known integration caveats reported by the community.

High-Level Integration Architecture

The diagram below shows how an operator or agent reaches EdgeQuake's storage and LLM pipeline. The same backend services (documents, entities, query, workspaces) are reached through three independent client paths that all terminate at the Rust API server.

flowchart LR
    User[Operator / Developer]
    Agent[LLM Agent / IDE]
    App[Custom Application]

    User -->|browser| WebUI[EdgeQuake WebUI<br/>Next.js]
    Agent -->|MCP stdio| MCPServer[edgequake-mcp<br/>TypeScript]
    App -->|REST/WS| APIServer[edgequake-api<br/>Rust Axum]

    WebUI -->|fetch| APIServer
    MCPServer -->|HTTPS| APIServer
    App -->|HTTPS| APIServer

    APIServer --> Core[edgequake-core<br/>pipeline & storage]
    Core --> PG[(PostgreSQL<br/>pgvector + Apache AGE)]

The MCP server in mcp/package.json declares its dependency on @modelcontextprotocol/sdk ^1.12.1 and edgequake-sdk ^0.1.0, confirming that the MCP server itself is a thin typed client over the same HTTP endpoints used by the WebUI.

The REST API Surface

EdgeQuake's API server is built in Rust using Axum and serves a versioned REST surface mounted under /api/v1. The main README documents the pipeline responsibilities โ€” ingestion, multi-mode retrieval, context assembly, and LLM answer generation โ€” and states that the API layer "exposes RESTful endpoints, OpenAPI documentation, [and] authentication (coming soon)" (edgequake/README.md). Because the API is OpenAPI-described, the typed SDKs listed below can be regenerated from the same schema.

The WebUI lists the endpoints it consumes in edgequake_webui/README.md, which provides the practical contract for any integrator:

Endpoint groupMethodsPurpose
/healthGETLiveness/readiness
/auth/*POST /auth/login, POST /auth/logoutSession management
/documentsGET, POST, DELETE /:idDocument CRUD and ingestion
/entities, /relationships, /graphGETKnowledge-graph inspection
/query, /chatPOSTRAG queries and streaming chat
/api/v1/models/*GETLLM/embedding model catalog

A known caveat surfaced by the community is that the model catalog is compiled into the binary via include_str! against models.toml and is therefore "never overridable at runtime" (raphaelmansuy/edgequake#251). Operators who add a local Ollama model must rebuild the image, or rely on the workspace-level LLM configuration exposed through the multi-tenancy request types in edgequake/crates/edgequake-core/src/types/multitenancy/requests.rs (with_llm_model, entity_types, entity_types_strict).

Official Client SDKs

EdgeQuake ships typed SDKs so that downstream applications do not have to hand-roll HTTP calls. The repository contains the following:

TypeScript SDK

Declared in sdks/typescript/package.json, the TypeScript package targets Node.js >= 18, ships ESM with sideEffects: false, and is published under Apache-2.0. It is the dependency that the MCP server itself imports ("edgequake-sdk": "^0.1.0" in mcp/package.json), making it the canonical JS/TS client.

Kotlin SDK

The Kotlin SDK described in sdks/kotlin/README.md highlights that it has "zero HTTP dependencies" (uses java.net.http.HttpClient, JDK 11+), ships "19 service clients" (health, documents, entities, relationships, graph, query, chat, auth, users, API keys, tenants, conversations, folders, tasks, pipeline, models, workspaces, PDF, costs), and uses Jackson for serialization. The SDK is multi-tenant aware โ€” every request can carry tenant, user, and workspace headers.

A minimal Kotlin example from the README:

val client = EdgeQuakeClient(
    EdgeQuakeConfig(baseUrl = "http://localhost:8080", apiKey = "your-api-key")
)
val health = client.health.check()

WebUI as a Reference Client

The Next.js WebUI in edgequake_webui/src/lib/api/edgequake.ts (referenced in edgequake_webui/README.md) is itself a working TypeScript reference implementation. Helper modules such as edgequake_webui/src/lib/export-conversation.ts (Markdown/JSON export, FEAT0727/FEAT0728) and edgequake_webui/src/lib/utils/progress-formatter.ts (ETA/duration formatting) demonstrate how to consume streaming ingestion progress โ€” a pattern SDK authors should replicate when wiring long-running ingestion from a CLI or notebook.

Model Context Protocol (MCP) Server

The MCP server (mcp/README.md, articles/016-mcp/README.md) is the integration path designed for LLM agents and IDE plugins such as Claude Desktop. It speaks the standard MCP stdio transport, so any MCP-compatible host can discover EdgeQuake tools automatically.

Exposed Tool Surface

The MCP README documents three core tools that wrap the HTTP API:

  • query โ€” natural-language retrieval, intended to trigger graph traversal such as Person --founded--> Organization --uses--> Technology.
  • document_upload_file โ€” uploads a local file. Supported extensions are .txt, .md/.markdown, and .pdf. The tool accepts optional title, metadata, and enable_gleaning arguments.
  • Workspaces are exposed as isolated knowledge graphs; "One workspace = One knowledge graph" and workspaces "cannot share data (isolation enforced server-side)" (mcp/README.md).

Sample Upload Invocation

{
  "tool": "document_upload_file",
  "arguments": {
    "file_path": "/Users/alice/projects/research/paper.md",
    "title": "Research Paper on Graph Neural Networks",
    "metadata": { "category": "research", "year": "2024" }
  }
}

The MCP server package is also where the keyword-extraction prompt lives conceptually โ€” see edgequake/crates/edgequake-core/src/keyword_extractor.rs, whose few-shot prompt instructs the LLM to emit JSON with high_level_keywords and low_level_keywords. Agents calling the query tool will indirectly trigger this prompt server-side.

Known Integration Issues

Two recurring community-reported issues affect every integration surface:

  1. Version drift between UI and API (raphaelmansuy/edgequake#250). The footer in the WebUI may display a different version than /health reports. SDK authors should treat /health (or /api/v1/version) as the source of truth and not parse UI strings.
  2. Document re-upload race (raphaelmansuy/edgequake#253). Confirming a replace on an existing document can fail silently after upgrading. Until this is fixed, SDK upload helpers should surface the server's error body and retry idempotently.
  3. Provider prefixing of model names (raphaelmansuy/edgequake#255). When the LLM provider is set to an OpenAI-compatible target, the backend auto-prepends the provider name. SDK users should pass fully-qualified model IDs (e.g. ollama/gemma3:12b) as supported by the with_llm_model builder in edgequake/crates/edgequake-core/src/types/multitenancy/requests.rs.

See Also

  • EdgeQuake main README โ€” architecture overview and quickstart.
  • MCP Server Specification โ€” full tool contract.
  • Model Context Protocol Spec โ€” protocol reference.
  • EdgeQuake WebUI โ€” reference TypeScript client implementation.

Source: https://github.com/raphaelmansuy/edgequake / Human Manual

Doramagic Pitfall Log

Source-linked risks stay visible on the manual page so the preview does not read like a recommendation.

medium Installation risk requires verification

May increase setup, validation, or first-run risk for the user.

medium Installation risk requires verification

May increase setup, validation, or first-run risk for the user.

medium Installation risk requires verification

May increase setup, validation, or first-run risk for the user.

medium Installation risk requires verification

May increase setup, validation, or first-run risk for the user.

Doramagic Pitfall Log

Found 14 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: identity.distribution | https://github.com/raphaelmansuy/edgequake

2. Installation risk: Installation risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: community_evidence:github | https://github.com/raphaelmansuy/edgequake/issues/252

3. Installation risk: Installation risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: community_evidence:github | https://github.com/raphaelmansuy/edgequake/issues/255

4. Installation risk: Installation risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: community_evidence:github | https://github.com/raphaelmansuy/edgequake/issues/251

5. Configuration risk: Configuration risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: community_evidence:github | https://github.com/raphaelmansuy/edgequake/issues/259

6. Configuration risk: Configuration risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: community_evidence:github | https://github.com/raphaelmansuy/edgequake/issues/250

7. Configuration risk: Configuration risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: community_evidence:github | https://github.com/raphaelmansuy/edgequake/issues/253

8. Capability evidence risk: Capability evidence risk requires verification

  • Severity: medium
  • Finding: README/documentation is current enough for a first validation pass.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: capability.assumptions | https://github.com/raphaelmansuy/edgequake

9. Runtime risk: Runtime risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a runtime risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: packet_text.keyword_scan | https://github.com/raphaelmansuy/edgequake

10. Maintenance risk: Maintenance risk requires verification

  • Severity: medium
  • Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: evidence.maintainer_signals | https://github.com/raphaelmansuy/edgequake

11. Security or permission risk: Security or permission risk requires verification

  • Severity: medium
  • Finding: no_demo
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: downstream_validation.risk_items | https://github.com/raphaelmansuy/edgequake

12. Security or permission risk: Security or permission risk requires verification

  • Severity: medium
  • Finding: no_demo
  • User impact: May increase setup, validation, or first-run risk for the user.
  • Recommended check: Reproduce the official install and quickstart path in an isolated environment.
  • Evidence: risks.scoring_risks | https://github.com/raphaelmansuy/edgequake

Source: Doramagic discovery, validation, and Project Pack records

Community Discussion Evidence

These external discussion links are review inputs, not standalone proof that the project is production-ready.

Sources 12

Count of project-level external discussion links exposed on this manual page.

Use Review before install

Open the linked issues or discussions before treating the pack as ready for your environment.

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using edgequake with real data or production workflows.

Source: Project Pack community evidence and pitfall evidence