저장소 정보는 아직 수집하지 않았습니다.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
최근 완료된 8시간 회차 사이 GitHub 스타 증가량 순
DeepSeek Harness Remote: DeepSeek Harness 실행 PC와 모바일·PC를 안전하게 연결해 어디서나 작업 이어받기
Mac 전체를 한 문장으로
Ayakaleaf Pro는 무료 오픈소스로 직접 호스팅하는 Overleaf alternative다
오픈소스, 로컬 우선 작업 관리 도구 오프라인 작동 모든 기기 동기화 라즈베리 파이 실행 구독료 없음
MS Office 친숙 사용자용 오픈소스 오피스, 다중 플랫폼 최적화
메이커가 쓴 소개는 위의 한 줄이 전부입니다. 더 자세한 내용은 저장소 README에서 읽을 수 있습니다. 저장소 README ↗
README 전체를 불러오는 중입니다.
README 전문 보기 ↗Add your files. Corpus Wiki sorts them out, writes simple pages for your team and keeps them up to date.
Features · How it works · Use cases · NVIDIA + Nebius · MCP · Run it locally · Architecture
[!NOTE] Hackathon: Corpus Wiki is a submission to the Nebius Global AI Hackathon. It is a working prototype: upload a PDF, Word or Markdown file, NVIDIA Nemotron drafts what it changes, Change control applies it or asks a person, and only the wiki lines that changed are rewritten.
Every AI step in Corpus Wiki runs on open NVIDIA Nemotron models served by Nebius Token Factory. One NEBIUS_API_KEY powers reading, writing, checking, seeing and searching.
| NVIDIA model | What it does in Corpus Wiki |
|---|---|
Nemotron 3 Ultra nvidia/Nemotron-3-Ultra-550b-a55b | The rare judgment calls: planning articles, approving new ones, deciding the topic tree, curating page structure |
Nemotron 3 Super nvidia/nemotron-3-super-120b-a12b | The everyday work: reconciling each upload into a ChangeSet, writing wiki lines, fact-checking them, defining glossary terms, finding entities, research |
Nemotron 3 Nano nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B | Bulk linking of knowledge, where volume matters more than depth |
Nemotron 3.5 Super VL nvidia/Nemotron-3.5-Super-VL | Vision: reads images, diagrams and video frames from uploads, and helps Composer pick and draw illustrations |
Also on Token Factory: Qwen/Qwen3-Embedding-8B embeddings find claims that say the same thing in different words, and DeepSeek-V4.1-Flash handles the high-volume yes/no duplicate checks.
How Token Factory accelerated the build
response_format: json_schema makes Nemotron return valid ChangeSets, so the pipeline never parses free text.reasoning_effort can be set per role on /settings, trading speed for depth where it matters.Also on Nebius AI Cloud: video rendering. Each narrated video renders as a Nebius Serverless AI job on a CPU VM (cpu-d3, 8 vCPUs). The job runs our render image from Nebius Container Registry (headless Chromium, HyperFrames, ffmpeg), uploads the MP4 and poster, then calls the app back. The VM is billed only while the job runs, so the web app stays small and serverless. See Video rendering on Nebius Serverless AI.
Details, code locations and configuration: How it uses NVIDIA Nemotron on Nebius Token Factory.
Corpus Wiki is an MCP server. MCP (Model Context Protocol) is the open standard that lets AI tools such as Claude, Cursor and ChatGPT call outside apps. Point any MCP client at /api/mcp and your agent can search the wiki, read sourced claims, add notes and files, and rewrite pages.
read (search knowledge, open articles, claims, sources, entities), write (add notes, files and links, create and rewrite articles, answer exceptions, undo a ChangeSet), delete, spaces and settings. A new key starts with read only./.well-known/, dynamic client registration, PKCE, and a 403 step-up when a call needs a scope the token lacks. Personal keys made in Settings work too.Connect from Claude Code:
claude mcp add --transport http corpus-wiki https://<your-deployment>/api/mcp
Code: app/api/mcp/route.ts (the endpoint), lib/mcp/server.ts and lib/mcp/tools/ (the tools), app/oauth/ and app/.well-known/ (sign-in), lib/agents/scopes.ts (scopes). Design: docs/mcp-server-plan.md.
Maintaining knowledge is hard. Docs go stale the day they are written, two files disagree and nobody notices, and nobody can say where a sentence came from.
So Corpus Wiki does it for you. Every line knows its source, changes when its source changes, and goes through a human check when it matters.
Messy data Corpus Wiki What you get
docs · images · video ──▶ convert → split → extract ──▶ wiki pages · glossary
links · notes · API → reconcile → check → build stakeholders · agent memory
Every page is read, pictures included. Each fact comes out short, with its source.
A new file arrives. Only the sentences it changes are rewritten, each with its source, and every change lands in the change log with an undo.
Every term your documents use, defined in plain words, with real examples from your sources. Duplicates merge; new meanings add themselves.
Every person and organization in your files, how they connect and how much say they have (a 1 to 5 power level). Kept current.
Connect your AI tools through MCP. They read sourced, current facts and remember what you teach them, across every session.
While you work with your coding agent, every feature, endpoint and decision is documented in the background.
| 🔗 Every line has a source | Every sentence links to the file and the page it came from. |
| ✋ Risky changes wait for you | Safe updates apply on their own. Conflicts and deletions wait for a person. |
| ↩️ Undo anything | Every change is recorded with its cause and can be reversed. |
| 🧩 One answer, not ten versions | Matching facts merge into one, and every source stays attached. |
📥 Getting knowledge in
/upload): PDF, Word, Markdown, text and notes, with cancel and retryPOST /api/capture): a note or file from a script, shortcut or agent in one request/api/mcp): outside agents read and edit a Space with scoped OAuth tokens or personal keys (details)✍️ AI that writes and tidies the wiki
📖 Reading and sharing
/p/<slug>): live lines with citations; click a line for its facts, sources and history/ask, /chatbot): answers from the facts; Agent mode can also make changes/s/<space>/explore) and Embed (/embed/<space>): a public directory and a read-only iframe🔍 Reviewing and browsing
/changes): every applied ChangeSet, with a diff and undo/exceptions): decisions the AI won't make alone/graph): a map of facts and entities with cleanup and undo🎓 Learning from the wiki
/study): quiz sets made from a topic, article, entity or glossary/study/review): levels from New to Learned, with due questions from every set🎬 Making from the wiki
/video): a narrated video from the facts, with chapters and sources/docs): how-to doc sets with an outline step, a reader, Markdown export and PublishAlso: Spaces (separate wikis), per-role AI model settings, usage plans and limits, a guided tour, evals, and a cost report per role and model. The full list is in docs/features.md.
| Use case | Why it fits |
|---|---|
| 📘 Self-maintaining docs | Handbooks, policies and project pages update when a new file changes the rules; every step links to its source. |
| 🧠 Your life's wiki | Notes, chats, lectures, plans and friends, sorted into one wiki about you. |
| 🤝 Client tracking | Every client's details, deal stage and last talk, kept current from emails and calls. |
| 📚 Learning a big subject | Long books become linked, sourced pages in minutes, with repeats merged. |
| ⚖️ Rules and compliance | Dated sources, newer overrides older, same-date conflicts go to a person, every change is logged. |
| 🤖 Memory for AI agents | One sourced memory your AI tools read and write over MCP, with the same Change control as people. |
One Next.js App Router app (UI and server code) on Vercel. Supabase provides Postgres, Realtime, Storage and the login. Browsers only read (row-level security); server code writes with the secret key, and every write is a Postgres function.
One upload pipeline, one converter per format (lib/ingest):
| Format | Converter |
|---|---|
unpdf (text per page) | |
| Word (.docx) | mammoth |
| Markdown and plain text | read as text |
| Images, audio, video | slots only; not converted yet |
The file is stored in the private sources bucket, split into passages, and recorded with a Knowledge Shift Event (ingest_source). A file with the same bytes is skipped.
Reconciliation (lib/ai): Nemotron reads the passages and the current knowledge and drafts a ChangeSet of typed actions (create domain or entity, add, revise or retire a claim, merge duplicates, link, set certainty). Details in How it uses NVIDIA Nemotron.
Change control (lib/change-control, supabase/migrations/20261014010000_change_control.sql): commit_change_set checks and applies a ChangeSet in one transaction. Everything that passes is applied without asking (approval by exception). A person is asked only when:
An older file never overwrites a newer one, and a set whose units changed while it was drafted is refused as a whole. Every applied ChangeSet can be undone from the Changes screen.
Living pages, lines as rows (lib/living-page, supabase/migrations/20261015000000_lines_as_rows.sql): every line of a wiki section is a row (lines) with never-edited versions (line_revisions) that cite the exact claim revisions they state. When a claim changes, the lines citing it are flagged (stale_lines), and only those lines are rewritten, through Change control like any other change. Editing a line that states one claim also revises that claim in the same ChangeSet, so changes flow both ways. Open pages update live.
One call (app/api/capture/route.ts): POST /api/capture runs the whole path above in a single request and answers with the event's status and ChangeSet, so a script, phone shortcut or another agent can feed the wiki without the UI. Send a note as JSON (text, optional title and sourceDate), raw text, or a file as multipart (file, optional sourceDate); the date defaults to today. Authenticate with Authorization: Bearer $SECOND_BRAIN_API_KEY or a signed-in session.
curl -X POST http://localhost:3000/api/capture \
-H "Authorization: Bearer $SECOND_BRAIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"title":"Alpha standup","text":"Alpha moves its launch to 3 March."}'
Screens: Home, Upload, Changes (with undo), Exceptions, Units, Sources, Entities, Domains, and the wiki pages (/p/<slug>). Click a line to see the claims behind it, their sources and the line's history.
Tables: sources, passages, shift_events, domains, entities, units, revisions, unit_entities, unit_domains, relationships, change_sets, actions, exceptions, pages, sections, section_inputs, change_notes, lines, line_revisions; views stale_lines and section_lines.
The AI steps run on NVIDIA Nemotron models served by Nebius Token Factory, called at runtime through Token Factory's OpenAI-compatible API (https://api.tokenfactory.nebius.com/v1/). The default model is nvidia/nemotron-3-super-120b-a12b; each AI role has its own default (ROLE_DEFAULT_MODELS in lib/ai/config.ts), and any role can be switched on /settings.
Supporting models on Token Factory: Qwen/Qwen3-Embedding-8B for embeddings (stored in pgvector to find near-duplicate claims) and DeepSeek-V4.1-Flash for yes/no duplicate checks. Cerebras, Claude and OpenRouter can be added as optional extra providers, but every default runs on Token Factory.
The model never writes knowledge. Its draft goes to commit_change_set, a Postgres function that checks every action and applies the ChangeSet in one transaction (see What the prototype does); anything that needs judgement becomes an exception for a person. Each ChangeSet records the model id and prompt version that drafted it, so a bad batch can be traced and undone.
| What | Where |
|---|---|
| Provider settings (base URL, default model, per-role Nemotron defaults, prompt version) | lib/ai/config.ts |
| Vision model for images and video frames | lib/ingest/describeMedia.ts, lib/ingest/describeVideoServer.ts |
| Embeddings | lib/ai/embeddings.ts |
| Chat call with a JSON schema, and settings from env | lib/ai/chat.ts |
| Reconciliation prompt, answer schema and mapping to typed actions | lib/ai/tokenFactory/ |
Picks the real client when NEBIUS_API_KEY is set, the fake one otherwise | lib/ai/factory.ts |
| Wiki line writer | lib/living-page/writers/tokenFactory.ts |
| Fake clients used by tests and offline development | lib/ai/fake/, lib/living-page/writers/fake.ts |
| End-to-end eval cases E1–E7 | evals/ |
Set these in .env.local (local) or in Vercel's environment settings (deployed). Never commit them.
NEBIUS_API_KEY= # from Nebius Token Factory
AI_MODEL=nvidia/nemotron-3-super-120b-a12b # optional; this is the default
Token Factory runs the models; Nebius AI Cloud also does the heavy compute. Rendering a narrated video needs a browser, ffmpeg and minutes of CPU, which do not fit in a web request. So the app hands each render to a Nebius Serverless AI job:
nebius ai job create on a CPU platform (cpu-d3, preset 8vcpu-32gb).scripts/video/render/Dockerfile: Node, headless Chromium, HyperFrames, ffmpeg), renders the frames, muxes the audio and uploads the MP4 and poster.POST /api/video/[id]/rendered with a signed token. If no callback comes, /api/video/[id]/status reads the job state and log tail from Nebius and marks the video failed.In our test, 8 vCPUs rendered 5.5 seconds of video in 11 seconds. The VM is billed only while the job runs, and the script editor shows the render cost before you start (lib/video/cost.ts).
| What | Where |
|---|---|
| Nebius job client (start a job, read its state and logs) | lib/video/render.ts |
| Wiring and environment | lib/video/server.ts |
| Render image | scripts/video/render/Dockerfile |
| Callback and status routes | app/api/video/[id]/rendered/route.ts, app/api/video/[id]/status/route.ts |
NEBIUS_PROJECT_ID= # or NEBIUS_RENDER_PROJECT_ID: a region with CPU quota
NEBIUS_IAM_TOKEN= # for the nebius CLI and the image pull
VIDEO_RENDER_IMAGE= # the render image in Nebius Container Registry
response_format: {"type": "json_schema"} with the answer's JSON schema constrains the output on the server; the app still validates it with zod before anything is committed.AI_MODEL or a pick on /settings./models endpoint, so new Nemotron releases show up without a code change./v1/embeddings with Qwen3-Embedding-8B, cut to 1024 dimensions for pgvector, uses the same key and client (lib/ai/embeddings.ts).reasoning_effort is passed per role (lib/ai/chat.ts), trading speed for depth where it matters.scripts/cost/report.ts prices every logged call at Token Factory's rates (lib/ai/pricing.ts).cp .env.example .env.local # fill in the keys; never commit .env.local
npm ci
npm run dev # http://localhost:3000, redirects to /login when signed out
Sign in with your Supabase Auth user. Without NEBIUS_API_KEY the app uses fake AI clients that answer the eval fixtures, so the UI and tests run without a key.
npm run build
npm run typecheck
npm run lint
npm test # vitest; DB tests start a throwaway Postgres 16 (see below)
npm run db:types # prints how to regenerate lib/database/types.ts
npm run db:migrate # applies pending supabase/migrations to the Supabase database (see below)
supabase/migrations/ is the source of truth, applied in file-name order. Never edit an applied migration; add a new file. Don't put begin/commit in a migration; the runner wraps each file in its own transaction. lib/database/types.ts is generated from the live schema.npm run db:migrate (scripts/db/migrate.ts) sends each pending file as one script that opens a transaction, takes a lock, records the file in supabase_migrations.schema_migrations, runs it and commits, so a failed file leaves nothing behind. It reaches the database one of two ways (scripts/db/targets.ts): with SUPABASE_ACCESS_TOKEN (a personal access token) it uses Supabase's Management API over HTTPS, which is the only route that works from Claude's cloud sessions, since they pass HTTPS traffic only; otherwise it connects straight to Postgres with SUPABASE_DB_URL (dashboard > Connect > Session pooler, port 5432), verified against Supabase's root CA in supabase/certs/. -- --status lists applied and pending files; -- --baseline <version> records files up to that version as applied without running them (for a database whose schema was built another way). Schema changes go through this path, not the Supabase connector, whose confirmation prompt for DROP/DELETE can't be answered from a Claude thread.supabase/seed.sql is the Project Alpha baseline the tests and evals start from.test/db/localPostgres.ts creates a socket-only cluster in /var/tmp with the binaries in /usr/lib/postgresql/16/bin (override with PG_BIN), stubs Supabase's auth, storage, Realtime publication and API roles, applies every migration and the seed, and deletes it afterwards. The tests skip when the binaries are missing.evals/cases.ts lists E1–E7 and evals/fixtures/ holds the dated files. evals/evals.test.ts runs each case through the real pipeline with the fake model. LIVE_FILE=<path> npx vitest run evals/live.test.ts sends one real file through Nemotron.npx npm@11 install), because npm 10.9 crashes resolving vitest 5's optional peers. npm ci works with npm 10 and 11.components/ui holds jayrr.dev registry components; is jayrr.dev's standard lint (theme colors only, sizes through props), wired into .Store information to preserve evidence. Structure knowledge to support understanding. Retrieve knowledge to support decisions and actions.
Build a wiki that can explain what it knows, where that knowledge came from, when it applies, how it connects to other knowledge, and why it influenced a conclusion or decision.
Documents preserve evidence. Atomic Knowledge Units (AKUs) represent independently understandable claims, concepts, principles, procedures, hypotheses, or questions. Typed relationships connect them into a versioned knowledge graph.
New evidence should trigger incremental reconciliation. Questions should assemble task-specific context. Equivalent claims should consolidate without losing their sources or history. Conclusions, decisions, and observed outcomes should feed future learning while retaining their distinct meanings.
The canonical knowledge store sits at the center of four engines. Arrows summarize responsibilities; every canonical write passes through validation.
flowchart TB
KRE["Knowledge Reconciliation Engine · KRE<br/>Interprets Knowledge Shift Events<br/>Proposes evidence-backed ChangeSets"]
KDCE["Deduplication & Consolidation Engine · KDCE<br/>Finds candidates and checks equivalence<br/>Preserves sources, aliases, and history"]
STORE[("CANONICAL KNOWLEDGE STORE<br/>Single source of truth<br/><br/>Atomic Knowledge Units · Immutable revisions<br/>Sources · Relationships · Applicability rules<br/>Derivations · Decisions · Canonical aliases")]
KCE["Knowledge Context Engine · KCE<br/>Selects relevant, applicable knowledge<br/>Builds revision-specific Context Packages"]
RE["Reasoning Engine<br/>Uses Context Packages<br/>Produces traceable conclusions and recommendations"]
KRE -->|"Validated updates"| STORE
KDCE -->|"Validated consolidation"| STORE
STORE -.->|"Existing knowledge and evidence"| KRE
STORE -.->|"Candidates and revision history"| KDCE
STORE -->|"Knowledge and retrieval indexes"| KCE
STORE -->|"Referenced evidence and revisions"| RE
KCE -->|"Context Package"| RE
RE -.->|"New knowledge candidates"| KRE
| Engine | Responsibility | Primary output |
|---|---|---|
| Knowledge Reconciliation Engine (KRE) | Interpret incoming events, extract knowledge, identify contradictions, and analyze impact | Proposed Knowledge ChangeSet |
| Deduplication & Consolidation Engine (KDCE) | Find similar units, verify claim equivalence across context, entities, and time, and propose safe consolidation | Consolidation or relationship proposal |
| Knowledge Context Engine (KCE) | Interpret a task, retrieve candidates, evaluate applicability, expand evidence and dependencies, and identify gaps | Context Package referencing specific revisions |
| Reasoning Engine | Evaluate the package, request more context when needed, and preserve the derivation behind each conclusion | Conclusions, recommendations, and decision proposals |
The store preserves AKUs, immutable revisions, source records, typed relationships, applicability rules, derivations, decisions, and aliases. Metadata records knowledge type, status, provenance, authority, scope, timestamps, and uncertainty where justified.
Vector embeddings, keyword indexes, structured queries, and graph traversal support retrieval. Embeddings belong to specific revisions and can be regenerated; they do not replace canonical knowledge.
An event-driven processing layer handles execution state, retries, idempotency, revision checks, validation, dependency propagation, embedding refresh, and real-time notifications. Approval blocks operations that require it while permitted processing continues.
These axioms summarize the principles developed for the project.
Open point: the design documents use a list of 12 fundamental axioms; this README lists 17. Both are kept until Sam decides which list is canonical.
Open Publishing in the sidebar to choose Private, Unlisted (anyone with the link), or Public (also listed in /explore). Select up to 100 pages, preview the visitor text, and publish a reviewed edition. Later edits and newly created pages stay private until republished. Source files, private citations, images, attachments, and workspace tools are excluded from this first version.
Enable embedding to copy a read-only wiki iframe for another website. Public readers use /s/[spaceSlug]; embeds use /embed/[spaceSlug]. Both read only the published projection, without a workspace session. Unpublishing or deleting a space disables its reader, embeds, and Explore listing. Existing copies cannot be recalled. Both public and unlisted editions request no search-engine indexing.
The owner-only Publishing screen reports views, daily browser-tab sessions, engaged reads (30 visible seconds), embed views, Explore-attributed views, and popular articles for 7, 30, or 90 UTC calendar days. Repeated views are deduplicated per article, tab, surface, and 30-minute period. Known bots and signed-in owner visits are excluded; browser privacy preferences and blocked storage can reduce counts. No analytics cookies or raw IP addresses are stored. Older event rows are removed when new reads or owner metrics are processed.
Apply database migrations with npm run db:migrate before running these routes. Public access is through narrow read RPCs; workspace tables retain their existing ownership rules, and public page URLs reject write requests.
Capture and update
Source → preserved evidence → Knowledge Shift Event → KRE → KDCE checks for new or revised units → validated ChangeSet → canonical store.
Retrieve and reason
Question + situation → KCE → Context Package → Reasoning Engine → conclusion or recommendation → authorized decision when accepted.
Learn and re-evaluate
Committed revision → dependency analysis → affected contexts and derivations marked stale → context rebuilding and reconciliation as needed.
Derived claims, decision facts, and observed outcomes re-enter through the same update pipeline. An accepted decision remains in effect until an authorized change supersedes it, even if its supporting derivation needs review.
For near-real-time ingestion, validated provisional units may be available while consolidation runs asynchronously. Provisional status remains explicit.
Use exact hashes, vector similarity, entity matching, and graph relationships to find a small candidate set. Then evaluate claim equivalence, scope, applicability, time, and provenance.
This architecture was developed in the original Corpus Wiki design conversation.
lib/standard-lint.mjseslint.config.mjsapp/globals.css (grayscale plus five muted accents). Font sizes are text-panel, text-body and text-title; muted text is text-muted-foreground or text-faint.