oros — Cursor Rules

version: 1 project: name: "oros" description: > Oros (f.k.a. “kavachat") is an evolving codebase for a multi-LLM chat application that interacts with blockchain tasks. Currently, it focuses on bridging user prompts to GPT-based AI, proxying requests through a stateless Golang server, and rendering a React frontend. In the long term, Oros may expand to encompass many single and multi-chain agentic blockchain actions (using one or more LLMs/deModels), long-term memory and user-shared context, and expansion to different user-interfaces /entry points (TG, mobile,etc). marketing: "Oros: bring deAI to any dApp". repos: • name: "oros" description: "Core codebase containing the stateless API proxy (Go) + React web app." context: # Summarize the main system architecture, early-stage development, and # how we see the future expansion of the project. overview: > The project’s current architecture has three main components: 1) A Golang Proxy that sits between the frontend and the LLM. This is a stateless server exposing HTTP endpoints and routing user chat requests to a remote LLM (e.g., GPT-4o). It also handles partial application logic, such as prompt engineering, streaming responses, and code injection prevention. 2) A React Frontend that provides a chat interface. Users can send messages, connect wallets, and see real-time streaming replies from the proxy. 3) Tests that aim to cover critical behaviors, integration points, and resilience. The codebase includes unit tests (Go and TypeScript), plus integration tests verifying correct LLM responses, and a Docker-based environment for end-to-end checks. future: • Incorporating multi-LLM support (community open models + GPT, deModels). • Adding ephemeral or partial memory for conversation context. • Expanding to multi-chain interactions. • Evolving to multi-chain AI agent that can propose on-chain transactions, orchestrate bridging, etc. • Expanding to other user-interfaces/entry points (TG, mobile,etc). guidingPrinciples: • testCoverage: > Build robust, readable tests for the proxy, the UI, and any integration endpoints. Achieve high coverage for critical paths, ensuring behavior is documented and future refactors remain safe. • architectureClarity: > Keep the stateless proxy design straightforward. Defer complex session logic or advanced memory to future expansions. Maintain minimal dependencies for faster iteration. • incrementalImprovements: > Prioritize small, frequent PRs with clear commit histories. Integrate new features behind flags or environment configs to ensure stability for production usage. • userFocus: > Present a user-friendly chat UI. The impetus is smooth interactions with the LLM and eventually bridging real blockchain tasks. Keep the developer experience in mind with clear docs and function signatures. workflow: codeReviews: > • Create a short-lived feature branch off of main or dev. • Open a Pull Request with a succinct description, referencing the relevant issue or user story. • Tag relevant reviewers (product lead, lead engineer, or others if domain-specific knowledge is needed). • Ensure tests pass. • Merge with a squash commit if approved. versioning: > We follow semantic versioning for major releases. However, as the codebase is still early, we might do frequent minor or patch releases with v0.x.x. ciProcess: > GitHub Actions / any CI pipeline runs: • Linting • Tests (unit, integration) • Build steps for both Go and React • Docker build for local e2e tests communication: • platforms: > • Slack for day-to-day engineering + urgent matters. • GitHub issues and PRs for tasks, feedback, bug tracking. • Regular stand-ups or asynchronous updates for the core team. • feedbackLoop: > • Provide inline PR commentary for code-level suggestions. • Larger architectural changes should be proposed to team in docs/architecture or an ADR (Architecture Decision Record). faq: • "What is the main goal of this stage of dev?" answer: > Solidify core functionality (chat proxy + tests + minimal UI) and ensure we can easily expand to multi-LLM or multi-chain usage. • "Are we storing conversation data or user sessions in the backend?" answer: > Currently, the proxy is stateless. Any partial memory or session logic is either ephemeral in the UI or a future enhancement. notes: • > This .cursorrules file is living documentation. Update it as the architecture evolves (e.g., multi-LLM or memory logic), so new developers grasp the purpose, flow, and higher-level context of Oros.