AI Decision System
Replayable, offline-verifiable records for AI-assisted go/no-go decisions: experiment promotions, typed model answers and human-approved actions.
翻譯準備中
尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證正在載入完整 README。 以下為已儲存的摘錄。
A single project brief becomes a fully staffed AI office. One orchestrator (Nova) and 10 specialist employees — architect, backend, frontend, design, QA, data, security, docs, DevOps, coordination — decompose it into a task graph, work it in parallel with real file/shell tool access, and commit real results, all visualized as a live office floor you can watch in real time.
Submit one brief — "build a landing page," "write API docs," "audit this repo for security issues" — and:檢視完整 README ↗A single project brief becomes a fully staffed AI office. One orchestrator (Nova) and 10 specialist employees — architect, backend, frontend, design, QA, data, security, docs, DevOps, coordination — decompose it into a task graph, work it in parallel with real file/shell tool access, and commit real results, all visualized as a live office floor you can watch in real time.
Submit one brief — "build a landing page," "write API docs," "audit this repo for security issues" — and:
It's a real, running multi-agent system, not a mockup — the screenshots below are from the live deployment.
| Office floor (live agent state) | Dashboard (usage, mesh graph, work graph) |
|---|---|
| Agent | Role | Department |
|---|---|---|
| Nova | Orchestrator — decomposes briefs, assigns work, triages escalations | Orchestration |
| Kael | Solutions Architect — system design, schemas, API contracts | Engineering |
| Priya | Backend Developer — server implementation, endpoints, business logic | Engineering |
| Devraj | Frontend Developer — UI implementation from design specs | Engineering |
| Simran | UI/UX Designer — design tokens, component states, UX flows | Design |
| Arjun | QA Engineer — test plans, execution, bug reports | Engineering |
| Meera | Data/Analytics — queries, metrics, aggregation | Data |
| Raghav | Security Reviewer — auth review, vulnerability flags | Engineering |
| Tanya | Technical Writer — docs, READMEs, onboarding guides | Data |
| Farhan | DevOps Engineer — CI/CD, deploy pipelines, infra | Operations |
| Isha | Project Coordinator — task breakdown, dependency mapping | Operations |
Each seat is pinned to a specific LLM provider + model (see shared/src/llm/assignments.ts), so 11 agents working concurrently spread across separate rate-limit buckets instead of all hammering one API.
The system is split across three places, each doing the one thing it's actually good at:
flowchart TB
subgraph Client["Browser"]
UI["Office floor · Dashboard · Status board<br/>(Next.js + Three.js)"]
end
subgraph Vercel["Vercel / Netlify — serverless frontend"]
API["Next.js API routes<br/>/api/tasks · /api/agents · /api/brief · /api/escalations"]
Tick["/api/cron/nova-tick<br/>escalation triage + QA pass"]
end
subgraph GHA["GitHub Actions"]
Cron["nova-tick.yml — 5-min schedule<br/>(Vercel's own cron is daily-only)"]
end
subgraph Railway["Railway — persistent worker"]
Dispatch["dispatch loop — polls for ready tasks"]
Runner["AgentRunner — per-agent tool-use loop<br/>read_file · write_file · run_command"]
Git["single-committer git module"]
end
subgraph Supabase["Supabase"]
PG[("Postgres — tasks, messages,<br/>escalations, memory, usage")]
RT["Realtime<br/>(postgres_changes)"]
end
subgraph LLMs["Multi-provider LLM router"]
Groq["Groq"]
NVIDIA["NVIDIA NIM"]
OpenRouter["OpenRouter"]
end
UI <-->|REST| API
UI <-->|live push| RT
API <--> PG
Cron -->|HTTPS, bearer secret| Tick
Tick --> PG
Dispatch --> PG
Dispatch --> Runner
Runner --> Git
Runner --> PG
RT -.->|subscribes to| PG
Runner --> LLMs
Tick --> LLMs
API --> LLMs
Why split this way: the frontend's API routes are stateless request/response — a perfect fit for serverless. Nova's periodic reasoning (escalation triage, QA) is idempotent against Postgres, so a fresh serverless invocation every 5 minutes is safe — that's /api/cron/nova-tick, pinged by a GitHub Actions schedule instead of Vercel's own cron (which is daily-only on the free tier). But an employee's actual work — editing real files and making real git commits against one working tree — can't be a stateless function call; it needs a long-lived process holding a real checkout. That's the one thing that runs on Railway instead.
sequenceDiagram
actor You
participant Nova
participant DB as Supabase (Postgres)
participant Worker as Railway worker
participant Agent as Employee agent
participant LLM as LLM provider
You->>Nova: Submit brief
Nova->>LLM: Decompose into task graph
Nova->>DB: Insert tasks + dependencies
Worker->>DB: Poll for ready tasks
DB-->>Worker: Task ready (deps satisfied)
Worker->>Agent: Start tool-use loop
loop Until done or escalated
Agent->>LLM: Reason + choose next tool call
Agent->>Agent: read_file / write_file / run_command
end
Agent->>Worker: mark_task_done or escalate
Worker->>DB: Commit result, update status
DB-->>You: Realtime push — office floor updates live
Nova->>DB: (every 5 min) triage escalations, run QA pass
| Layer | Choice |
|---|---|
| Frontend | Next.js 14 (App Router), TypeScript, Tailwind, Three.js (3D office floor) |
| Backend API | Next.js API routes (serverless) |
| Persistent worker | Node.js + TypeScript, Docker, deployed on Railway |
| Database + Realtime | Supabase (Postgres + postgres_changes) |
| LLM providers | NVIDIA NIM, Groq, OpenRouter — routed with per-agent fallback chains |
| Hosting | Vercel (primary) + Netlify (mirror) |
| CI | GitHub Actions |
| Desktop wrapper | Electron (optional, npm run electron) |
| Path | What it is |
|---|---|
/shared | Hive types, agent roster, LLM router/providers/assignments, design tokens — imported by both the frontend and the worker so schema and roster never drift apart |
/frontend | Next.js app — office floor UI, dashboard, status board, all API routes, and the nova-tick cron endpoint |
/daemon | The Railway worker — dispatch loop, AgentRunner tool-use loop, single-committer git module |
/electron | Native desktop wrapper — spawns the frontend and worker locally and shows the frontend in a window |
.github/workflows/nova-tick.yml | 5-minute GitHub Actions schedule that pings /api/cron/nova-tick |
cp .env.example .env
# fill in at least one of NVIDIA_API_KEY / GROQ_API_KEY / OPENROUTER_API_KEY,
# a Supabase project's SUPABASE_URL / SUPABASE_SERVICE_ROLE_KEY /
# NEXT_PUBLIC_SUPABASE_URL / NEXT_PUBLIC_SUPABASE_ANON_KEY, and PROJECT_WORKDIR
npm install
npm run build:shared
npm run dev:frontend # Next.js app at localhost:3000
npm run dev:daemon # persistent worker, polls Supabase for ready tasks
Only one provider is required to run at all; configuring more just adds rate-limit headroom, since every agent's assignment has fallbacks on the other providers (shared/src/llm/assignments.ts).
npm run build # shared + frontend + daemon production builds
npm run electron # spawns the frontend + worker, opens a native window
frontend, vercel.json handles the monorepo build) or Netlify; set the Supabase + LLM provider env vars from .env.example.Dockerfile to Railway (or any Docker host); it only needs outbound HTTPS to Supabase and the LLM providers, plus a writable volume for PROJECT_WORKDIR if you want commit history to survive restarts.APP_URL (your deployed frontend URL) and CRON_SECRET (matching the one set on the frontend) as GitHub Actions repo secrets so .github/workflows/nova-tick.yml can ping /api/cron/nova-tick every 5 minutes.No license file yet — all rights reserved by default until one is added.