.cursorrules
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.