Documentation

Everything you need to work with Git Lora — local-first, by design.

What is Git Lora

Git Lora is a local-first workspace for projects that need persistent AI memory. A project lives in an ordinary folder on your disk — Markdown, code, notes. On top of that folder Git Lora builds a canonical model of the project: entities, relationships, facts and events, available to you and to the language model alike.

The difference from an ordinary chat is that context is not reassembled from scratch each time. It is stored, versioned and kept consistent across sessions, so the model answers from what you have already written rather than from whatever fitted into the last message.

  • Software development
  • Books and long prose
  • Screenplays
  • Worldbuilding
  • Research
  • Documentation
  • Structured knowledge
  • Long-running AI workflows

Installing and first run

Download the installer from the Download page and check the SHA-256 shown next to the button. If it does not match, do not run the file — tell support instead.

On first run Git Lora shows the agreement: terms, privacy policy and licence. You have to accept them to continue. Acceptance is recorded on your computer, so a first run works entirely offline; registering the installation finishes on its own once there is a network.

  1. 1

    Verify the installer

    Compare the SHA-256 against the Download page.

  2. 2

    Accept the agreement

    Three items: terms, privacy, licence.

  3. 3

    Configure an AI provider

    Settings → provider, model and API key. The key stays local.

  4. 4

    Create a project

    A project is a folder. Nothing is uploaded.

Your API key stays on your computer. Git Lora does not proxy model requests through its own servers.

Your first project

Create a project from the sidebar. It has a kind — Universal, Author or Coder — which only chooses the starting taxonomy (which entity types are suggested) and can be changed later without losing anything.

Inside a project, files sit in ordinary folders. Create them, move them by dragging, delete them: these are plain filesystem operations, visible in your file manager and friendly to Git.

  • A project is a folder on disk
  • Files are edited by hand or by AI
  • Drag and drop moves a file
  • Right-click to rename, copy path or delete
  • Ctrl+S saves, Ctrl+K opens the command palette

What a project is made of

Git Lora distinguishes files from entities. A file is the text you write. An entity is what the text is about: a character, a location, a module, a service, a decision, a rule, an event.

Entities do not replace files and do not live apart from them. They are derived from your own files and indexed locally, so the source of truth stays the thing you wrote rather than a separate database that can drift away from it.

  • Markdown files
  • Code
  • Characters
  • Locations
  • Companies
  • Kingdoms
  • Objects
  • Events
  • Relationships
  • Memories
  • Branches
  • AI proposals

Canonical memory

Memory is the set of facts the project treats as true. Each fact has a tier: canon, working or sandbox. Canon is what the model relies on; sandbox is what you are still trying out.

When two canonical facts contradict each other, Git Lora surfaces the contradiction instead of averaging it. That matters: a silently chosen middle version is a way to spoil a project without noticing, while a surfaced contradiction is an ordinary editorial decision.

  • Three tiers: canon, working, sandbox
  • Contradictions are shown, not resolved silently
  • Memory is indexed locally
  • Companions keep private memory that never becomes canon

The graph

The graph is the same set of entities shown as connections rather than a list. It earns its place when the question is "what breaks if I change this": you can see what is attached to what, and through which relationship.

It is built from the index and updates with it. There is no separate graph to maintain.

Branches and versions

A branch is an alternative development: a different turn in the plot, a different approach to an implementation. Branches live inside the project and require no knowledge of Git.

Because a project is an ordinary folder, you can also run real Git over it. Git Lora does not get in the way and does not hide your files in a private format.

The companion

The companion is a conversation with access to the project's canonical memory. It answers from what you have already written, so it does not invent a parallel version of your world.

Each companion can keep private memory: what it remembers about your arrangements with it, which never becomes project canon. That separation exists so talking to an assistant does not rewrite the project itself.

AI never overwrites silently

Every AI edit becomes a proposal first. It is stored, shown as a diff, and checked by a quality gate that can refuse it. The file changes only after you agree.

This is not a setting and cannot be turned off. A tool that grants itself permission to rewrite your work is not suitable for something you have been building for months.

  1. 1

    Request

    You describe what should change.

  2. 2

    Proposal

    The answer is stored as a proposal, not written to the file.

  3. 3

    Diff

    You see exactly which lines would change.

  4. 4

    Quality gate

    A QC agent checks the edit and can refuse it.

  5. 5

    Apply

    The file changes only once you agree.

Agent OS

Agent OS is a persistent runtime that works through a queue of goals in the background. You state a task in words; it is carried out step by step, with a record of what happened.

Each run has its own memory scope, so one agent cannot spoil another's context. Runs are visible in the panel: status, goal, tokens used.

Autonomous Engine

Autonomous mode is for work that does not fit in a single answer. The engine plans steps, executes them through tools, checkpoints progress into memory, recovers from failure, passes quality control and continues.

The computer has to stay awake: processing runs locally, on your machine, not on our servers.

  1. 1

    Plan

    Decomposes the goal into steps.

  2. 2

    Execute

    Runs the steps through tools.

  3. 3

    Checkpoint

    Saves progress into memory.

  4. 4

    Recover

    On failure, retries or takes another route.

  5. 5

    QC

    Checks the result against the goal.

  6. 6

    Continue

    Moves on to the next step.

Finalizer

The Finalizer assembles a long artifact end to end: a manuscript, a document, a codebase. First it previews several possible developments; you approve one, and assembly then proceeds stage by stage under the constraints you set.

Those constraints — style, what must happen, what must never happen, tone, length — are set once and respected at every stage, not only at the start.

MCP and external clients

The project's canonical memory is available to any MCP-capable client. That means an external AI client can ask questions about your project without receiving a copy of every file.

The MCP server runs locally alongside the engine and is reachable only from this computer.

Sync

Sync is optional. By default a project exists only on your disk.

If you turn it on, you choose where to: your own server or storage you control. gitlora.uz is not a place project content is stored under any configuration.

Privacy and data

gitlora.uz never receives project content: no Markdown, no code, no memory, no prompts. The app sends only what registering an installation requires: a random identifier generated on your machine, the version, the OS family, the architecture and the update channel.

There is no hardware fingerprinting — no MAC address, no machine name, no serial numbers. Your IP address is not stored; only a two-letter country code derived from it. Diagnostics attached to a support ticket are sent only if you tick the box, and the server discards them if you did not.

  • Projects never leave your disk
  • The installation identifier is random
  • No hardware fingerprinting
  • No IP address is stored
  • Diagnostics only with explicit consent
  • The app works when the website does not

Support and updates

You can send a ticket from the website or from inside the app — both arrive in the same place through the same endpoint, so behaviour does not depend on where you report from.

Updates are checked over HTTPS. Before installing, Git Lora verifies the publisher, the signature and the SHA-256 checksum. A build without a checksum is not offered at all: an unverifiable installer is worse than no update.