Lim Workspace

Lim Workspace is a developer-first AI + MCP workspace skeleton. It is designed to help you wire local profiles, local MCP servers, and a shared desktop/browser UI into one public starter repo.

What This Repo Is

• a runnable desktop and browser workspace skeleton
• a local-first AI profile and MCP server setup surface
• a public launcher hub for GitHub visitors
• a clean base for adding your own providers, servers, and workflows

Public Launchers

The canonical GitHub-friendly launchers live in ui_launchers/:

• ui_workspace_desktop_gui_launcher.py for the embedded desktop shell
• ui_workspace_browser_mode_launcher.py for browser mode that opens the local UI
• ui_workspace_web_server_launcher.py for the local HTTP API and browser-serving backend
• ui_workspace_smoke_test_launcher.py for the workspace smoke test
• ui_global_finance_mcp_server_launcher.py for the bundled Global Finance MCP server

The older run_*.cmd wrappers remain only for compatibility. New users and contributors should start from the ui_ launchers.

Repository Layout

• apps/desktop: desktop app entry layer
• apps/server: browser/server entry layer
• packages/desktop_ui: shared product UI
• packages/agent_runtime: AI orchestration runtime
• packages/mcp_gateway: MCP connection and tool registry layer
• packages/settings_service: profile, secrets, and local config handling
• servers: bundled MCP servers for the first product slice
• config/profiles: public AI profile templates
• config/mcp: public MCP server templates
• ui_launchers: public launcher entry points
• docs: public-facing docs for GitHub and search discoverability
• docs_internal: local-only internal notes, excluded from Git
• user_data: runtime-generated local data, excluded from Git

Public Positioning

• this repo is intended as a starter skeleton, not a polished end-user product
• public docs should help developers understand setup, extension points, and validation quickly
• general-user instructions should stay short and practical
• internal planning and implementation notes stay in docs_internal

Secret Policy

• real secrets must never be committed
• GitHub should contain .env.example, not .env
• non-secret AI and MCP settings belong in readable JSON files
• user-specific runtime files belong under user_data/
• local desktop testing may keep provider keys in user_data/profiles/*.json
• public template files must stay secret-free

Config Strategy

• .env: optional secret values and overrides
• config/profiles/*.json: public AI profile templates
• config/mcp/*.json: public MCP server templates
• user_data/profiles/*.json: local runtime AI profiles
• user_data/mcp/*.json: local runtime MCP configs
• browser/server mode defaults to 127.0.0.1:38761
• JSON should stay simple enough for developers to copy, edit, and extend

Docs

• docs/README.md is the public documentation hub
• docs/en/README.md and docs/ko/README.md explain the public doc layout
• docs/en/QUICK_START.md and docs/ko/QUICK_START.md stay intentionally short
• public docs should help both people and AI systems understand the skeleton quickly

Public Release Standards

• public release guidance should be easy to find from the repository root
• standard GitHub trust documents should exist for security, contribution, and release history
• the repository root should include SECURITY.md, CONTRIBUTING.md, and CHANGELOG.md
• public-facing docs should stay safe for publication and avoid private business context
• screenshots, logs, and sample JSON should stay secret-free

Current Status

The current workspace slice is wired up with:

• one working xAI Grok profile path
• one bundled global_finance MCP server path
• a setup-focused UI shared by desktop and browser launchers
• AI connection test, MCP connection test, manual tool test, and chat workflow

Validation

The workspace is currently validated through:

• desktop launcher startup
• browser mode launcher startup on 127.0.0.1:38761
• HTTP server startup and /api/health checks
• smoke tests in tests/
• real MCP tool discovery and chat flow validation

The next implementation phase should harden:

• broader onboarding
• safer connection permissions
• additional provider/server templates
• packaging and installer flow