Related Pages

Related topics: System Architecture & Self-Evolution Engine, MCP Integration, Communication Gateway & Operations, Ecosystem: Cloud Community, Benchmarks, Showcase & Custom Skills

Overview & Quick Start

What is OpenSpace?

OpenSpace is an AI agent platform that learns, extracts, and self-evolves reusable skills from existing codebases. Rather than building applications from scratch, OpenSpace analyzes a reference project, distills architectural patterns into skills, then composes and refines those skills across iterations to build new target applications. Source: showcase/README.md.

The flagship demonstration of this skill-evolution approach is My Daily Monitor — an always-on live dashboard streaming processes, news, markets, schedules, and messages into one screen, with a built-in AI agent that has access to every data source on the dashboard. Source: showcase/README.md.

Key Capabilities

• Live Process & Terminal Monitor — dev servers, training jobs, SSH sessions, Docker containers with CPU/memory bars and crash detection.
• AI Agent with Tool Routing — context-aware tool selection across all data sources. Source: showcase/my-daily-monitor/src/components/InsightsPanel.ts.
• Real-time Streaming — auto-refreshing news, markets, HN/Reddit, Gmail, Calendar, Feishu feeds.
• Custom Keyword Monitors — user-defined keyword alerts that highlight matching news articles. Source: showcase/my-daily-monitor/src/components/MyMonitorsPanel.ts.

Skill Evolution Pipeline

OpenSpace's distinguishing feature is its iterative skill extraction and refinement process. The pipeline demonstrated in the showcase:

1. Reference Analysis — Analyze an existing open-source project (e.g., WorldMonitor).
2. Skill Extraction — OpenSpace extracts reusable patterns. The My Daily Monitor showcase was bootstrapped from 6 skills: codebase-pattern-analyzer, skill-template-generator, worldmonitor-reference, panel-component, data-service, and panel-grid-layout. Source: showcase/README.md.
3. Domain Adaptation — Apply the personal-monitor-domain skill to define target panels, data sources, APIs, and priority ordering.
4. Iterative Evolution — Each iteration adds panels, refines existing ones, fixes bugs, and extracts new skills. Skills self-evolve to become more specific and battle-tested.

graph LR
    A[Reference Codebase] --> B[Pattern Analysis]
    B --> C[Skill Extraction]
    C --> D[Domain Adaptation]
    D --> E[Initial Dashboard]
    E --> F[Iteration: New Panels]
    F --> G[Iteration: Skill Refinement]
    G --> H[Evolved Application]
    H --> I[New Skills Extracted]
    I --> D

Quick Start with My Daily Monitor

Installation

cd showcase/my-daily-monitor
npm install

Running the Development Server

npm run dev

This starts the Vite dev server with an embedded API plugin at http://localhost:5173. No separate backend is required — API routes are handled by the Vite middleware. Source: showcase/README.md.

Configuration

Click ⚙ Settings in the top-right corner to configure API keys for desired data sources. The preferences module stores user-specific settings including stock watchlists, news categories, keywords, and refresh intervals. Source: showcase/my-daily-monitor/src/config/preferences.ts.

Default configuration values include:

Architecture Overview

Panel System

All UI components extend a base Panel class that handles loading states, error handling, and content rendering. Examples include:

• SocialPanel — Aggregates Hacker News, Reddit, and V2EX posts with tab-based filtering. Source: showcase/my-daily-monitor/src/components/SocialPanel.ts.
• InsightsPanel — AI agent panel with tool routing across weather, stocks, news, schedule, and email. Source: showcase/my-daily-monitor/src/components/InsightsPanel.ts.
• MyMonitorsPanel — Custom keyword monitoring with localStorage persistence. Source: showcase/my-daily-monitor/src/components/MyMonitorsPanel.ts.
• CommandPalette — Cmd+K quick-search overlay with fuzzy search, keyboard navigation, and recent commands tracking. Source: showcase/my-daily-monitor/src/components/CommandPalette.ts.

Service Layer

Services use a circuit breaker pattern for resilient data fetching with built-in caching:

• fetchCommunityPosts() — Fetches aggregated social posts with 3-minute cache TTL. Source: showcase/my-daily-monitor/src/services/social.ts.
• fetchNews() — Fetches news via API proxy with 5-minute cache TTL. Source: showcase/my-daily-monitor/src/services/news.ts.
• analyzeProcessExit() — AI-powered analysis of process exits using OpenRouter. Source: showcase/my-daily-monitor/src/services/ai-summary.ts.

API Routes

The server-side routes aggregate external APIs with caching. The social route fetches from HN, Reddit, and V2EX (currently disabled due to content quality issues) with an 8-second fetch timeout and 3-minute cache. Source: showcase/my-daily-monitor/server/routes/social.ts.

Skill Management Frontend

The OpenSpace frontend provides a web interface for managing extracted skills, with features including:

• Skill Version Drawer — Displays execution quality metrics including effective rate, completion rate, applied rate, and fallback rate. Source: frontend/src/components/skill-detail/SkillVersionDrawer.tsx.
• Graph Visualization — Shows skill lineage and evolution graphs with score and generation tooltips.
• Internationalization — Full i18n support with English and Chinese translations. Source: frontend/src/i18n/zh.json.

Known Issues & Workarounds

The community has reported several operational issues relevant to deployment:

• MCP Integration — Some agents with OpenSpace MCP tools available never call them, resulting in zero skill scores. Source: GitHub Issue #84.
• Timeout Issues — Tasks delegated through OpenClaw may exceed the MCP server timeout. Source: GitHub Issue #73.
• API Key Access — API keys for the cloud service are managed through the open-space.cloud profile settings. Source: GitHub Issue #88.
• Platform Compatibility — Windows users may encounter _is_pid_alive errors, and macOS launchd deployments may experience EOFError loops in interactive mode. Sources: GitHub Issue #90, GitHub Issue #87.

See Also

• showcase/README.md — Full showcase documentation
• frontend/src/i18n/zh.json — Internationalization configuration
• GitHub Issue #84 — MCP tool invocation issues
• GitHub Issue #85 — litellm version pinning

Related Pages

Related topics: Overview & Quick Start, MCP Integration, Communication Gateway & Operations, Ecosystem: Cloud Community, Benchmarks, Showcase & Custom Skills

System Architecture & Self-Evolution Engine

Overview

OpenSpace is an agent platform that performs self-evolving code generation: rather than emitting one-off scripts, it extracts, tracks, and re-uses skills across runs, building a lineage of improved versions over time. The System Architecture & Self-Evolution Engine is the combination of (a) the runtime that drives task execution, (b) the persistence layer that records skill lineage and execution analyses, and (c) the showcase project (my-daily-monitor) that demonstrates the engine end-to-end.

The core idea is summarized directly in the showcase documentation:

*Zero human code was written. The entire project — every panel, service, style, and API route — was generated and iteratively evolved by OpenSpace with no manual coding involved.* — showcase/README.md

The engine therefore treats every project as a living artifact that gets re-injected into future tasks as input context.

High-Level Architecture

flowchart LR
    A[User / MCP Client] -->|task instruction| B(OpenSpace Runtime)
    B -->|skill retrieval| C[(Skill Store / SQLite)]
    B -->|generated code + artifacts| D[Target Project]
    D -->|execution traces| E[Execution Analyzer]
    E -->|analysis records| C
    C -->|lineage + stats| F[Frontend Dashboard]
    F -->|visualization| G[Skill Evolution Graph]
    B -->|MCP streamable-http| H[OpenClaw / external agent]

The runtime reads from a skill store, generates code for the target project, captures execution traces, and writes analyses back. The frontend renders the resulting lineage graph so operators can inspect how each skill evolved.

Source: frontend/src/api/types.ts, showcase/README.md

Skill Lineage & Data Model

The self-evolution loop is built around a typed Skill entity. Each skill carries a lineage, an origin, a generation counter, and aggregated execution metrics. The relevant TypeScript types from the frontend API client make this explicit:

Source: frontend/src/api/types.ts

The SkillLineage graph is what the frontend visualizes. Nodes carry origin, generation, tags, score, effective_rate, and total_selections, and the UI hook useSkillEvolutionGraphData filters them by origin, tag, and pinned IDs before rendering:

// frontend/src/hooks/useSkillEvolutionGraphData.ts
const visibleNodeIds = new Set<string>();
const filteredNodes = lineage.nodes.filter((node) => {
  if (pinnedSkillIds.has(node.skill_id)) return true;
  if (originFilter !== 'all' && node.origin !== originFilter) return false;
  // tag + visibility filtering follows...
});

Source: frontend/src/hooks/useSkillEvolutionGraphData.ts

The internationalization strings confirm the operator-facing surface: *"evolution graph"*, *"version lineage"*, *"no lineage graph"* messages, and labels like *"effective rate"*, *"applied rate"*, *"fallback rate"*, *"diff"*, and *"change summary"* show that each version exposes a content diff against its parent. Source: frontend/src/i18n/en.json, frontend/src/i18n/zh.json

Execution Analysis & Feedback Loop

Every task run produces an ExecutionAnalysis that is persisted alongside the skill and consumed on subsequent runs. The i18n catalog describes what each analysis carries:

*"Completed: {{value}} · Tool issues: {{toolIssues}} · Suggestions: {{suggestions}}"* — frontend/src/i18n/en.json

This indicates each analysis records a completion outcome, any tool-level problems, and improvement suggestions. These analyses are aggregated into recent_analyses on each Skill record and feed the evolution heuristics (selection, applied, completion, and fallback counters). Source: frontend/src/api/types.ts

In the showcase, the AI agent panel makes the same feedback structure observable from the client side. The InsightsPanel defines a list of tools (weather, news, stocks, email, etc.) and routes a user question to whichever tool's keywords match, then feeds the resulting context to the model:

// showcase/my-daily-monitor/src/components/InsightsPanel.ts
const TOOLS: ToolDef[] = [
  { name: 'weather', keywords: ['weather', 'temperature', ...], fetch: ... },
  // ...
];

Source: showcase/my-daily-monitor/src/components/InsightsPanel.ts

The panel also persists mdm-agent-history (capped at MAX_HISTORY = 20) and mdm-agent-tasks, mirroring how the engine itself persists run history against each skill. Source: showcase/my-daily-monitor/src/components/InsightsPanel.ts

Showcase Demonstration

The showcase project, My Daily Monitor, is the canonical reference for what the self-evolution engine can build. It bootstraps from the open-source WorldMonitor project, extracts six seed skills (codebase-pattern-analyzer, skill-template-generator, worldmonitor-reference, panel-component, data-service, panel-grid-layout), and then evolves them iteratively while adding new panels. Source: showcase/README.md

The generated project uses a layered architecture:

• Panel layer — Panel base class (loading/error states) extended by SocialPanel, InsightsPanel, and 20+ other panels. Source: showcase/my-daily-monitor/src/components/SocialPanel.ts, showcase/my-daily-monitor/src/components/CommandPalette.ts
• Service layer — fetchCommunityPosts, fetchNews, and others wrap their HTTP calls in a circuit breaker with cache TTLs (e.g. 3 minutes for community posts, 5 minutes for news). Source: showcase/my-daily-monitor/src/services/social.ts, showcase/my-daily-monitor/src/services/news.ts
• Edge API layer — Vite middleware (e.g. server/routes/social.ts) that fans out to free external APIs (HN, Reddit) with an 8-second FETCH_TIMEOUT and a 3-minute in-process cache. Source: showcase/my-daily-monitor/server/routes/social.ts
• Configuration layer — preferences.ts stores watchlists, calendar IDs, email labels, GitHub repos, Feishu chat IDs, and refresh interval, all under a single typed object. Source: showcase/my-daily-monitor/src/config/preferences.ts

Known Operational Issues

Community reports (linked below) highlight practical boundaries of the engine:

• MCP tool non-invocation — when OpenSpace is exposed as an MCP server to other agents (e.g. OpenClaw), the host agent may register the OpenSpace tools but never call them, leaving every skill at score 0. See issue #84.
• MCP task timeout — delegating long tasks through OpenClaw to OpenSpace can exceed the host's timeout, even when OpenSpace alone executes them quickly. See issue #73.
• Interactive mode vs. daemon — running the CLI as a launchd service triggers an EOFError loop because input() has no TTY, producing runaway log growth. See issue #87.
• Platform portability — _is_pid_alive is not portable to Windows; the communication gateway fails to start with WinError 87. See issue #90.
• Supply-chain hygiene — litellm must stay outside the 1.82.7 / 1.82.8 window (PYSEC-2026-2); the pin was relaxed in issue #85.

These issues do not change the engine's data model but are important when operating it as an MCP server in mixed-platform environments.

See Also

• showcase/README.md — full showcase walkthrough and skill evolution narrative
• frontend/src/api/types.ts — canonical Skill / Lineage / ExecutionAnalysis types
• frontend/src/hooks/useSkillEvolutionGraphData.ts — graph filtering and rendering logic

Related Pages

Related topics: Overview & Quick Start, System Architecture & Self-Evolution Engine, Ecosystem: Cloud Community, Benchmarks, Showcase & Custom Skills

MCP Integration, Communication Gateway & Operations

Overview

OpenSpace exposes its agent runtime, hosted skills, and outbound tool backends through a layered set of surfaces. The MCP server (openspace/mcp_server.py) lets external agents (e.g., nanobot, openclaw) call OpenSpace as a tool provider; the dashboard server (openspace/dashboard_server.py) serves the operator UI; and the communication gateway (under openspace/communication/) bridges long-lived messaging channels (Feishu, IM, etc.) into OpenSpace task sessions. Together these three subsystems implement the *Integration* and *Operations* half of OpenSpace — anything that crosses a process or trust boundary.

A companion surface is the host skill bundle (openspace/host_skills/), which teaches the agent *when* to use MCP tools rather than just *that* they exist. The two skills — skill-discovery and delegate-task — wrap search_skills, execute_task, fix_skill, and upload_skill behind policy. Source: openspace/host_skills/README.md:1-40.

MCP Server: Transports & Endpoints

The MCP server supports three transports. The choice of transport is purely an agent-runtime concern; the tool surface is identical.

Source: openspace/host_skills/README.md:18-32. The integration guide recommends stdio for the simplest local setup, SSE for nanobot running OpenSpace as a standalone server, and streamable-http for openclaw when an HTTP transport is required.

The MCP configuration block in openspace/config/config.json (documented in openspace/config/README.md) controls request timeout, sandboxing, and session eagerness:

Source: openspace/config/README.md:6-14.

Host Skills & MCP Tool Surface

The agent never sees a raw tool catalog — it sees host skills that gate the four MCP primitives:

flowchart LR
    A[External Agent<br/>nanobot / openclaw] -->|MCP request| B[openspace-mcp<br/>mcp_server.py]
    B --> C[Host Skill Router]
    C -->|search_skills| D[skill-discovery]
    C -->|execute_task| E[delegate-task]
    C -->|fix_skill| E
    C -->|upload_skill| E
    D --> F[(Local + Cloud<br/>skill index)]
    E --> G[Skill Sandbox]
    G --> H[Backends:<br/>shell, gui, mcp, web, system]
    H -->|result| G
    G -->|report| A

Source: openspace/host_skills/README.md:1-40. The router decides per task whether to follow a skill locally, delegate to a sub-skill, or skip — making execute_task the chokepoint through which all tool traffic flows.

The OPENSPACE_BACKEND_SCOPE environment variable restricts which backends are reachable (default shell,gui,mcp,web,system), and OPENSPACE_HOST_SKILL_DIRS lists extra directories to scan for skills. Source: openspace/config/README.md:18-30.

Communication Gateway

The communication gateway runs as a separate process and feeds inbound messages into OpenSpace task sessions via the runtime manager (openspace/communication/runtime_manager.py) and session store (openspace/communication/session_store.py). Configuration is intentionally safe-by-default: loopback-only binding, channels disabled, and deny-by-default access control until allowed_users is populated.

cp openspace/config/config_communication.json.example \
   openspace/config/config_communication.json

Source: openspace/config/README.md:38-46. The gateway model is *not* set in this file; it inherits OPENSPACE_MODEL from openspace/.env, so LLM credentials do not need to be duplicated.

Operations, Security & Known Failure Modes

Security is enforced through layered overrides. The global security block defines allow_shell_commands, blocked_commands (split per platform: common, linux, darwin, windows), and sandbox_enabled. Each backend (shell, mcp, gui, web) inherits but can override the global policy. Source: openspace/config/README.md:24-34.

Several recurring operational issues are documented in the issue tracker:

• MCP tools registered but never invoked (Issue #84) — OpenClaw v2026.4.24 with OpenSpace v1.26.0 over streamable-http on port 8083; the connection succeeds but execute_task is never selected. Cause is typically host-side tool routing, not the MCP server.
• Timeout when delegating from openclaw (Issue #73) — runs locally in seconds but exceeds the openclaw control-web timeout. Raise the control-web timeout or raise mcp.timeout in openspace/config/config.json.
• EOFError loop under launchd (Issue #87) — interactive input() has no TTY when launched as a macOS daemon, spinning CPU and filling logs to 100 GB+. Run with --no-input or wire a real PTY in the LaunchAgent plist.
• Windows gateway start failure (Issue #90) — _is_pid_alive uses os.kill(pid, 0), which raises WinError 87 on Windows. Replace with a platform-specific probe (e.g., psutil.pid_exists).
• litellm supply-chain pin (Issue #85) — both pyproject.toml and requirements.txt pin litellm>=1.70.0,<1.82.7 to avoid PYSEC-2026-2; bump the upper bound to <1.83.0 once validated.
• Missing API key entry (Issue #88) — users cannot locate the "API Keys" menu on open-space.cloud to provision OPENSPACE_API_KEY for MCP server access.

Source: GitHub issues #84, #73, #87, #90, #85, #88.

See Also

• openspace/host_skills/README.md — host-skill setup for nanobot and openclaw
• openspace/config/README.md — full configuration reference
• Main README — quick-start and Path A (agent integration)
• frontend/src/api/types.ts — skill lineage and metrics type contracts exposed by the dashboard server

Related Pages

Related topics: Overview & Quick Start, System Architecture & Self-Evolution Engine, MCP Integration, Communication Gateway & Operations

Ecosystem: Cloud Community, Benchmarks, Showcase & Custom Skills

Overview

The OpenSpace ecosystem extends the core skill engine with a cloud community, a benchmark / lineage frontend, a showcase repository demonstrating end-to-end usage, and a framework for custom skills. Together these parts let users publish skills to a shared library, observe how skills evolve, study full applications built with OpenSpace, and teach their agents new capabilities through the host-skill protocol.

flowchart LR
  Agent[OpenSpace Agent] -->|execute_task| Core[Skill Engine]
  Core -->|search_skills| Cloud[(Cloud Community)]
  Core -->|fix_skill / upload_skill| Cloud
  Cloud -->|download| Local[(Local Skill Store)]
  Core -->|record| Rec[Workflow Recordings]
  Rec --> FE[Frontend Dashboard]
  Core -->|lineage graph| FE
  Showcase[showcase/my-daily-monitor] -->|reference patterns| Core
  Showcase -->|domain skill| Core
  HostSkills[openspace/host_skills] -->|delegate-task| Core
  HostSkills -->|skill-discovery| Cloud

Source: openspace/host_skills/README.md, frontend/README.md

Cloud Community

The cloud layer is exposed through two host skills — skill-discovery and delegate-task — which together teach the agent when to call which MCP tool:

Source: openspace/host_skills/README.md:1-30

Skills auto-evolve inside execute_task via three mutation paths — FIX (repair a defect), DERIVED (split a skill into more specific ones), and CAPTURED (freeze a working procedure). Each evolution produces a new version that can be uploaded with upload_skill. Source: openspace/host_skills/README.md:22-26

Community note: Issue #88 reports that the *API Keys* / *Developer* menu is missing from the cloud profile UI, which currently blocks users from minting a key for open-space.cloud. Without that key, the upload_skill path cannot authenticate. Source: Issue #88

Benchmarks & Evolution Graph

The frontend dashboard visualises skill quality, lineage, and workflow outcomes:

• Skill lineage — each node carries generation, origin, tags, effective_rate, total_selections, and an is_active flag. Source: frontend/src/hooks/useSkillEvolutionGraphData.ts:1-60
• Filters — by origin (allOrigins) and by tag set (allTags), with alwaysVisibleSkillIds to pin anchor nodes. Source: frontend/src/hooks/useSkillEvolutionGraphData.ts:62-110
• Workflow sessions — replay recordings from logs/recordings and logs/trajectories, surfacing *mean success rate*, iterations, and skill selections. Source: frontend/src/i18n/en.json:workflows

Run it locally with the two-process setup: openspace-dashboard --host 127.0.0.1 --port 7788 plus the Vite dev server on 127.0.0.1:3888. Source: frontend/README.md:1-50

Community note: Issue #84 observes that downstream agents receive the MCP tools but never invoke them, so *all skills show score 0*. This directly affects the effectiveness metrics rendered by the lineage graph and is a common first-run symptom of misconfigured MCP wiring. Source: Issue #84

Issue #82 proposes SOHH as an external evaluator that could be featured alongside this graph to give skills a non-zero baseline. Source: Issue #82

Showcase — My Daily Monitor

showcase/my-daily-monitor is the canonical end-to-end project that OpenSpace generated through iterative skill evolution. The showcase README documents a four-stage pipeline:

1. Codebase ingestion — read the open-sourced worldmonitor dashboard.
2. Skill extraction — six initial skills (codebase-pattern-analyzer, skill-template-generator, worldmonitor-reference, panel-component, data-service, panel-grid-layout).
3. Domain adaptation — personal-monitor-domain re-targets panels for *personal* daily use.
4. Iterative evolution — each iteration adds panels, refines services, and produces new skill versions.

Source: showcase/README.md:1-80

The runtime is a vanilla TypeScript Vite app. index.html performs flash-free theme initialisation; vite.config.ts registers an embedded API plugin so backend routes (server/routes/*.ts) run in the same dev process as the SPA. Source: showcase/README.md:18-60

Selected sub-systems:

• Tech Community panel — SocialPanel.ts aggregates Hacker News and Reddit (V2EX is wired but commented out for quality reasons). The matching server route social.ts uses an 8-second AbortSignal.timeout and a 3-minute in-memory cache keyed by source. Source: showcase/my-daily-monitor/server/routes/social.ts:1-90
• Insights AI agent — InsightsPanel.ts routes user prompts to a TOOLS array of keyword-matched fetchers (weather, schedule, stocks, etc.). Each tool is a ToolDef with keywords and a fetch() lambda; the agent only pulls data relevant to the question, which keeps latency low. Source: showcase/my-daily-monitor/src/components/InsightsPanel.ts:1-90
• Command palette — Cmd+K overlay registered via registerCommands(commands) with fuzzy search, recent-command tracking (MAX_RECENT_COMMANDS = 3), and arrow / Enter / Escape keyboard navigation. Source: showcase/my-daily-monitor/src/components/CommandPalette.ts:1-60

Configuration is centralised in preferences.ts: stocks watchlist, news keywords, GitHub repos, Feishu chat IDs, calendar IDs, email labels, and a refreshIntervalMs (default 60 000 ms). Source: showcase/my-daily-monitor/src/config/preferences.ts:1-30

Community note: Issue #73 reports that delegating work to OpenSpace through an external orchestrator (OpenClaw) frequently exceeds the MCP timeout, even when the same task completes instantly when OpenSpace runs standalone. The 8-second per-fetch timeout in social.ts illustrates how internal components already implement the short-deadline discipline that helps when calls are nested. Source: Issue #73

Custom Skills & Known Failure Modes

Custom skills follow the host-skill contract: each skill ships an MCP tool definition plus a SKILL.md that tells the agent when to call it. The delegate-task skill is the canonical meta-skill — it composes execute_task, search_skills, fix_skill, and upload_skill into a single loop that can repair itself. Source: openspace/host_skills/README.md:18-26

Common failure modes observed in the community that affect the ecosystem surface:

Source: Issue #84, Issue #85, Issue #87, Issue #88, Issue #90

See Also

• Core Skill Engine & Execution Model
• MCP Server Integration
• Frontend Dashboard User Guide
• Showcase: My Daily Monitor Deep Dive

Doramagic Pitfall Log

Found 20 structured pitfall item(s), including 3 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.

1. Configuration risk: Configuration risk requires verification

• Severity: high
• 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/HKUDS/OpenSpace/issues/84

2. Configuration risk: Configuration risk requires verification

• Severity: high
• 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/HKUDS/OpenSpace/issues/98

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

• Severity: high
• Finding: Project evidence flags a security or permission 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/HKUDS/OpenSpace/issues/73

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/HKUDS/OpenSpace/issues/73

5. 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/HKUDS/OpenSpace/issues/72

6. 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/HKUDS/OpenSpace/issues/87

7. 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/HKUDS/OpenSpace/issues/100

8. 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: capability.host_targets | https://github.com/HKUDS/OpenSpace

9. 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/HKUDS/OpenSpace

10. 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/HKUDS/OpenSpace

11. 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/HKUDS/OpenSpace

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: downstream_validation.risk_items | https://github.com/HKUDS/OpenSpace