RAG packs & exports

RAG packs & exports

RAG — knowledge packs

Her knowledge comes in packs, chip-style like her chips, managed in the RAG tab. A pack is a GitHub repo tagged navi-rag whose documents are its .md/.txt files and the extracted text of its .pdf files (a PDF gives up its words at the door; only the text is stored).

Installing one downloads the documents into rag-packs/ and builds the pack's index there, at install time — feature-hashed term vectors, small local embeddings computed with the standard library alone, no model to download. At question time only your question is embedded, so retrieval stays fluid on CPU.

Each pack carries an active toggle: only active packs feed her answers, and when a pack informs an answer, the pack and the document it came from appear as a source pill under her message — display only, never part of her reply text, so her voice never reads citations aloud, and a message that drew on no pack carries none. A bare /rag in chat lists the packs on this machine and which are active.

RAG Studio (the RAG tab's second tab) forges packs from documents on your disk — picked files, or a folder on this machine — into the same folder, documents, index, and metadata, ready to use immediately. Publishing a pack mirrors chips: a public repo, the navi-rag topic, and the choice is yours — a public repo for everyone, a private one for you.

The Packs list's Export for GitHub button packages a pack into exactly that repo shape:

• a generated README page (installs skip a root README, so it is never indexed),
• a navi-rag.json manifest,
• the documents under documents/,
• a .gitignore, and
• the pack's built index.json, shipped as a reference copy — installing Navi rebuilds the index locally.

A pack can ride a picture, too. Export as PNG on a pack's card draws its knowledge cartridge: one picture carrying the pack's manifest and every document's full text, compressed inside the image in a PNG text block (keyword navi-rag). Its face is card grade, like a chip's face: the pack name and description, and a split footer — the kind and document count at the bottom left, the version at the bottom right, omitted when the picture's data does not know one. Its face wears the RAG family green, (52, 211, 153) — bands, header, and every derived tone following the family accent — and its center is the spray, the name-seeded tile field grown to fill the whole window, denser and brighter toward the middle. A pack can declare its own art — an icon in navi-rag.json, in the same twenty-by-twenty format as a chip's — and declared art outranks the spray. The art rides inside the picture; malformed art is refused in plain words at export, and damaged art in a picture falls back to the spray. RAG Studio edits the icon as text rows. Hand someone the picture and they install the pack from the picture alone — Install from a picture on this tab, or a drop onto ChipDeck — and the index is built on their machine at install time from the texts inside: a cartridge never carries an index, and nothing reads the picture when her answers draw on the pack. Installed from a picture, a pack is a pack in every way — same folder, same index, same active toggle. There is a ceiling: a cartridge may run to 8 MB of picture; past it the export refuses in plain words and the ZIP stays the way to carry that pack — nothing is ever truncated to squeeze into a picture. Pictures carry their data in an invisible text block, and some places strip it — send the original file inside a .zip.

Installed packs and their indexes are on the persistence keep-list with her chips and voice models: updates, reinstalls, and even a --fresh install stash and put them back, so she still has them when she wakes. A pack's data is never re-fetched from GitHub unless you ask — updating does not read its repo, so if the pack's repo changes, the installed copy simply does not know. Reinstalling it fetches the latest.

The Packs list — cards, like the chips

The catalog half of the Packs list wears the same flip cards as the chips catalog: the front carries the pack's name, description, stars and forks, latest release, and whether it is installed, and README — flips the card over to read the repo's README inside it, with links to its Issues and — when the repo has a wiki — its Documentation. A pack that is already on this machine, installed from its repo or forged in RAG Studio under the same name, reads INSTALLED on its catalog card and its Install button sits grayed out — there is no second install over the copy you have. The pack's own card under On this machine is where it is managed: the Active toggle, Edit in RAG Studio, Delete, the Version field, Export for GitHub, Publish to GitHub, and Edit README all live there.

Publishing a pack, step by step

1. Forge the pack in RAG Studio. On its card in the Packs list, press Edit README if you want your own words on its GitHub page — your edited README is kept with the pack and shipped in the export and the upload alike (Restore generated README undoes it).
2. Signed in to GitHub: type a version like 0.1.0 and press Publish to GitHub. Check the repo name — pre-filled from the pack's name, yours to edit — and confirm. Navi creates the public repo if it is new, sets the navi-rag topic on its own, and uploads the files; an existing repo is updated, and she says so.
3. Not signed in: press Export for GitHub and download the ZIP instead. Make a new public repository on GitHub, unzip the export at its top, and add the topic navi-rag (repo page → About gear → Topics).
4. With the ZIP route, the last step is yours: on GitHub, publish the release — the version tag is created with that publish, so use the pack version from the manifest. With Publish to GitHub the release is published for you, knowledge cartridge attached (a pack too big for a picture releases without one, and says so).

Inside the export:

• a README.md page (installs skip a root README — it describes the pack, it is never a document),
• the navi-rag.json card,
• the documents under documents/, and
• index.json — the built index, shipped as the pack's reference copy.

Install downloads the documents (Markdown, text, and PDF files anywhere in the repo) and builds the index fresh on that machine. A release with a bigger tag offers everyone an update.