1. Project Overview
Project Name: VibeQuest
One-Sentence Summary:
VibeQuest turns AI-assisted coding into structured learning by making users study, verify, and defend generated CKB/Fiber code before completing a quest.
Project Type: AI Learning Platform / Gamified CKB Onboarding Product / CKB-Fiber Education DApp
Live Product and Repositories:
Frontend Demo: https://vibequest-web-seven.vercel.app
Frontend Repository: https://github.com/buidlLabs3/vibequest-web
Backend Repository: https://github.com/buidlLabs3/vibequest-core
Product Architecture: https://github.com/buidlLabs3/vibequest-web/blob/main/docs/product-architecture.md
Recorded Walkthrough: https://github.com/buidlLabs3/vibequest-web/blob/main/demo.webm
2. Builder Profile
VibeQuest is being built by xbeach. I handle product direction, frontend, backend, AI learning flow, CKB/Fiber integration direction, deployment, and demo preparation.
Contact email: [email protected]
Telegram: @OXbeach
GitHub organization: https://github.com/buidlLabs3
The current product already has a deployed Next.js frontend, Rust backend, OpenAI-powered learning and quest generation, MongoDB persistence, wallet-based identity flow, a dashboard, code workbench, and ship-gate structure. The Spark request is to turn this working prototype into a sharper, reviewable MVP.
3. Product Background
AI-assisted coding is now part of how people build. Many new builders ask AI to generate code, run it, modify it, and continue. That workflow is not going away, but it creates a serious gap: people often ship code they cannot explain.
That gap is especially risky in CKB and Fiber. CKB uses cells, lock scripts, type scripts, witnesses, transaction structure, and asset logic. Fiber introduces payment channels, invoices, payment proofs, and off-chain state assumptions. A learner can ask AI to generate a paywall, payout split, receipt verifier, or cell proof flow, but still fail to understand what the code trusts, what can be replayed, and what must be verified.
VibeQuest makes AI-assisted building safer by turning it into a learning loop: generate, inspect, test, explain, and record progress.
4. Focused MVP Scope
The current VibeQuest MVP is focused on two narrowed learning areas: CKB Cell Model and Fiber Payment Models.
The CKB Cell Model path teaches how cells, OutPoints, lock/type scripts, witnesses, transaction evidence, wallet proof, and verifier logic connect to generated code. The goal is to help learners understand what a CKB-based app is actually trusting before they accept or modify AI-generated code.
The Fiber Payment Models path teaches how invoices, payment proof, channel state, receipt binding, replay risk, and paid-access logic connect to practical application flows. The goal is to help learners understand how payment-related evidence should be scoped to the right user, content, run, cell, amount, and state.
These two areas form the core MVP because they cover the most important learning problem VibeQuest is solving: helping users move from AI-generated output to real understanding of proof boundaries.
The current product loop is:
AI lesson → checkpoint → lesson-based code quest → generated verifier/test files → workbench verification → boss challenge → completion record
5. Product Solution
VibeQuest is a gamified learning workbench where users learn by doing. A learner selects a path, generates a structured lesson module, studies the concept, answers a checkpoint, asks the AI tutor questions, writes notes, unlocks a practical quest, inspects generated code, runs verification checks, solves a boss challenge, and records progress.
The product’s main idea is simple: AI is the execution layer, but understanding is the progression layer.
A user can use AI to generate code, but VibeQuest only rewards progress when the user proves they understand the generated code. The boss challenge is tied to the generated verifier and denial tests, not generic trivia.
For the first MVP path, learners should answer questions like: What does this verifier trust? Is the trusted value coming from CKB transaction evidence, wallet proof, or frontend JSON? Which field would an attacker mutate first? Does the denial test prove replay prevention?
6. User Experience and Architecture
A user opens VibeQuest and starts by choosing a learning path, speciality, goal, and pace. The current MVP is centered on CKB Cell Model and Fiber Payment Models, but the learner experience is personalized by background: vibecoder, backend developer, frontend developer, security auditor, or product/community learner.
VibeQuest is not a static quiz site or a repository of pre-written lessons. The learning structure is fixed enough to keep the product reviewable, but the actual lesson content, checkpoint questions, tutor answers, code quests, denial tests, code explainers, and boss challenges are generated dynamically by AI from the learner profile and active lesson.
The product flow is:
Learner profile → AI-generated learning path → checkpoint → lesson-based code quest → generated verifier/test files → Workbench verification → boss challenge → completion record
Each generated learning path contains five modules. Each module includes a deep explanation, code lens, checkpoint question, wrong-answer feedback, tutor context, reference trail, and a quest bridge. The learner must pass the checkpoint before generating the related practice quest.
Once unlocked, the quest is generated from that completed lesson’s concept, checkpoint, misconception, and practice bridge. In the Workbench, the learner inspects generated files, runs file checks, asks questions about the code, and answers a boss challenge tied to the generated verifier and denial tests.
The frontend is built with Next.js and TypeScript. It owns the learning interface, dashboard, workbench, wallet flow, and ship gate. The backend is built with Rust and Axum. It owns AI generation, output validation, wallet proof validation, persistence, quest state, and reward-claim preparation. MongoDB stores users, learning sessions, generated lessons, quest runs, tutor messages, notebook records, completion states, and reward claims.
Product architecture: https://github.com/buidlLabs3/vibequest-web/blob/main/docs/product-architecture.md
7. Technical Approach and Current Progress
VibeQuest is built as a working AI learning product with a Next.js frontend and Rust backend. The product currently supports AI-generated learning paths, interactive checkpoints, tutor questions, lesson-based code quests, a code Workbench, generated file verification, boss challenges, MongoDB activity records, wallet-based identity, and a recorded demo walkthrough.
The backend treats AI output as a draft artifact, not as trusted product content. A generated lesson or quest must match the required structure before it is accepted. For lessons, this means five coherent modules with clear explanations, checkpoints, misconceptions, and practice bridges. For quests, this means generated implementation files, test files, denial paths, CKB/Fiber proof signals, a code explainer, and a boss challenge tied to the generated code.
If the AI response is incomplete, too generic, or does not meet the required structure, VibeQuest does not silently load placeholder content. The user is asked to regenerate. This keeps the MVP honest and easier to evaluate: every accepted quest must be specific enough for a learner to inspect, test, and defend.
The core technical principle is that learners should not only receive AI-generated code, they should prove they understand the trust boundary behind it. A completed quest must show that the learner can explain what the verifier trusts, what can be replayed or mutated, and which denial test proves the unsafe path is blocked.
8. Funding Request and Budget
Total requested: $1,000
Product and development work: $600
Frontend refinement, backend hardening, AI learning flow improvements, quest generation improvements, dashboard organization, workbench verification, and end-to-end testing.
OpenAI/API usage: $150
Lesson generation, quest generation, tutor interaction, repeated testing, and demo preparation.
Hosting and infrastructure: $100
Vercel hosting, backend deployment, MongoDB usage, and operational testing during the grant period.
CKB/Fiber polish and QA: $100
CKB/Fiber reference integration, wallet flow polish, ship-gate clarity, and ecosystem-specific testing.
Documentation and demo material: $50
README verification guide, walkthrough preparation, architecture documentation, proposal revision, and demo recording.
The AI cost model is controlled by design. VibeQuest does not call AI on every page load or refresh. AI calls happen when a learner generates a new learning path, asks the tutor, turns a completed lesson into a quest, or creates a custom quest. Accepted lessons, quests, tutor notes, and progress records are stored in MongoDB, so users can resume and review without repeated model calls.
After the Spark grant, ongoing costs will be managed through compact prompts, persistence, rate limits, low-cost hosting tiers, and usage monitoring. If beta usage grows, the project can support ongoing operation through ecosystem sponsorship, beta cohorts, or paid learning tracks.
9. Milestones and Deliverables
Milestone 1: CKB Cell Learning Path and Dashboard
Funding requested: $300
This milestone focuses on one learning path: Understanding CKB Cells and Proof Boundaries.
Deliverables:
Five dynamically AI-generated lessons for the CKB Cell path, created from the learner’s selected profile, goal, speciality, and pace. These are not static lessons.. Each lesson includes explanation, code lens, checkpoint, correct answer, wrong answers, feedback, tutor context, and quest bridge. Dashboard shows completed lessons, incomplete lessons, tutor questions, notebook reflections, and related quests. Learners can resume a saved learning path.
Acceptance criteria:
A reviewer can generate the CKB Cell path, see at least five modules, complete a checkpoint, ask a tutor question, write a note, and confirm the dashboard records the activity.
Milestone 2: Lesson-Based Quest Workbench and Verification
Funding requested: $350
This milestone turns completed lessons into practical code quests generated from the lesson’s concept, checkpoint, misconception, and practice bridge.
Deliverables:
Lesson-to-quest generation from completed lessons. AI-authored implementation file and test file. At least one valid test case and at least two denial-path test cases. Workbench display for generated files. Generated file verification checks. Code explainer tied to active generated files. Boss challenge tied to the generated verifier and denial test.
Acceptance criteria:
A reviewer can complete a lesson, generate a related quest, open generated code in Workbench, run file checks, answer a boss challenge, and see the quest completion state update. The boss challenge must test understanding of the generated code, not generic CKB trivia.
Milestone 3: CKB/Fiber Polish, Verification Guide, and Public Demo
Funding requested: $350
This milestone makes the MVP easy for reviewers and the CKB community to test.
Deliverables:
Clear public demo flow for one complete CKB Cell learning path. Recorded walkthrough showing lesson generation, checkpoint, quest generation, workbench verification, boss challenge, and completion. README verification instructions. Product architecture documentation. Clear CKB/Fiber reference links in the product. Ship gate state that explains what is complete, pending, and reward-claim ready. Frontend and backend checks passing.
Acceptance criteria:
A reviewer can follow the public demo or recorded walkthrough and verify the complete learning loop without private instructions.
10. Verification Plan
A reviewer can verify the product through this flow:
Open the frontend demo, connect wallet, choose the CKB Cell learning path, generate the five-module learning path, open a lesson, answer the checkpoint, generate the lesson-based quest, inspect generated files in Workbench, run generated file checks, answer the boss challenge, confirm completion state, and open the dashboard to confirm progress was recorded.
For technical verification:
Frontend: npm run lint and npm run build
Backend: cargo test
Repositories: public GitHub repos
Walkthrough: https://github.com/buidlLabs3/vibequest-web/blob/main/demo.webm
Expected output: the learning path appears with five modules, the quest is generated from a completed lesson, generated code and tests appear in Workbench, verification checks run, the boss challenge is tied to the generated code, and completion is recorded in the dashboard.
11. Current State vs. Funded Work
The current state is a working prototype with deployed frontend, deployed backend, AI generation, MongoDB persistence, wallet identity flow, learning modules, quest generation, workbench checks, dashboard records, and ship gate structure.
The funded work is the product-quality layer. It narrows the MVP, improves clarity, improves learning depth, strengthens generated quests, improves verification, and makes the demo easy for reviewers to test.
The main difference after this revision is focus. Instead of claiming broad ecosystem coverage immediately, VibeQuest will prove one complete CKB learning path first, then expand.
12. CKB Ecosystem Alignment and Final Summary
VibeQuest supports CKB onboarding by helping learners understand the concepts that matter when building real applications: cells, OutPoints, lock scripts, type scripts, witness data, transaction evidence, wallet proof, replay risk, Fiber invoice context, and proof-bound reward claims.
Many future builders will enter ecosystems through AI-assisted workflows. If CKB wants more builders, it also needs learning tools that meet users where they are. VibeQuest turns AI-assisted coding into a structured path toward understanding, safer development, and better ecosystem onboarding.
The requested $1,000 supports three clear milestones: learning path and dashboard, quest workbench and verification, and CKB/Fiber polish with public demo material.
