[
  {
    "slug": "getting-started",
    "title": "Getting Started",
    "category": "Getting Started",
    "sortOrder": 10,
    "content": "Learnitive is a local-first development and document workspace. Normal projects live in your Browser/OPFS storage and can optionally synchronize to one ordinary Projects Folder on your computer.\n\n## Create or import a project\n\nOpen **Projects** and choose **New Project**, a template, ZIP import or Git import. Every normal path creates a Browser project first. The project receives a stable local ID and a canonical slug used for filesystem naming.\n\n## Tour the workspace\n\nThe workspace combines the file tree, multi-file editor, tabs, output surfaces and project actions. Web projects expose Preview, command-line projects expose Console/Input, LaTeX projects expose PDF workflows and Interactive Doc provides structured writing.\n\n## Keep work durable\n\nChoose **Projects → Storage → Local Folder** at any time. No account is needed. Learnitive synchronizes all projects to **<Projects Folder>/<projectSlug>/**. If Browser/site data is later cleared, select the same folder again with **Recover Projects Folder** to rebuild the Browser copies.\n\n## Accounts are for account features\n\nSigning in is only needed when a feature itself requires authenticated server resources. Local project creation, filesystem synchronization and recovery do not require login.\n\n## Where to go next\n\nRead [Creating Projects](/docs/creating-projects), [Project Storage and Recovery](/docs/project-storage), [Projects Folder](/docs/linked-local-folders), [Code Editor and IDE](/docs/code-editor) and [Terminal and Runtime](/docs/texlab)."
  },
  {
    "slug": "local-first-projects",
    "title": "Local-First Projects",
    "category": "Projects & Files",
    "sortOrder": 10,
    "content": "Learnitive keeps normal project inventory outside the SaaS account database. Browser/OPFS is the working copy and one optional Projects Folder provides durable filesystem synchronization and recovery.\n\n## Browser is the working copy\n\nEvery normal project is created locally in Browser storage. OPFS is preferred when supported. Local project creation and editing do not require login.\n\n## Optional Projects Folder\n\nChoose **Projects → Storage → Local Folder** and select one directory. No account is required. Each project synchronizes to a child directory named exactly after its stable project slug.\n\n## Recoverability\n\nThe filesystem replica contains project manifests, stable IDs, slugs and sync metadata. If browser/site data is cleared, select the previous Projects Folder again and rebuild Browser projects directly from those files.\n\n## External tools\n\nThe synchronized folders are ordinary files, so you can edit them using VS Code or other local tools. Learnitive reconciles external changes and surfaces same-file conflicts instead of silently overwriting them.\n\n## Privacy boundary\n\nNormal local project inventory, names and paths are not uploaded simply because a project exists. Authenticated online features receive only the data they require when explicitly invoked."
  },
  {
    "slug": "creating-projects",
    "title": "Creating Projects",
    "category": "Projects & Files",
    "sortOrder": 20,
    "content": "Learnitive projects always start in Browser storage. You do not choose a storage provider for each project and no account is required for project storage.\n\n## Create a project\n\nFrom **Projects**, choose **New Project**, select a language, framework or document type, give the project a name and create it. Learnitive stores the project in Browser/OPFS and assigns a stable local project ID and slug.\n\n## Project name and slug\n\nThe display name is what you see in Projects. The project slug is the stable lowercase filesystem name. A project named **My React Dashboard** can use **my-react-dashboard**. The Browser workspace and synchronized local subfolder use that same slug.\n\n## Projects Folder\n\nChoose **Projects → Storage → Local Folder** to connect one Projects Folder. No login is required. Learnitive synchronizes all existing Browser projects into matching slug-named subfolders and mirrors new projects automatically.\n\n## Import, Git, templates and AI\n\nZIP imports, Git clones, templates, AI Builder projects and Interactive Docs all create the same Browser-first project and automatically participate in Projects Folder synchronization when one is connected."
  },
  {
    "slug": "browser-projects",
    "title": "Browser Projects",
    "category": "Projects & Files",
    "sortOrder": 30,
    "content": "Every normal Learnitive project uses Browser storage as its working copy. OPFS is used when the browser supports it.\n\n## Browser storage is always enabled\n\nCreating and editing a project does not require an account or filesystem permission. A temporarily unavailable Projects Folder never prevents Browser saves.\n\n## Durable local recovery\n\nBrowser/site data can be cleared. Connect a Projects Folder for a durable filesystem replica. If Browser data is later erased, choose **Recover Projects Folder**, select the same directory again and Learnitive rebuilds Browser projects from the folder manifests. No login is required.\n\n## Automatic synchronization\n\nWhen a Projects Folder is connected, Learnitive synchronizes Browser changes to the matching local project directory and reconciles external filesystem edits back into Browser storage.\n\n## Project directory naming\n\nThe synchronized directory name exactly matches the canonical project slug. For example, **research-paper** is mirrored to **<Projects Folder>/research-paper/**."
  },
  {
    "slug": "linked-local-folders",
    "title": "Projects Folder",
    "category": "Projects & Files",
    "sortOrder": 40,
    "content": "Projects Folder is Learnitive's optional local-filesystem synchronization and recovery feature. It is global for the current browser profile, not a per-project storage choice, and it does not require an account.\n\n## Connect one folder\n\nChoose **Projects → Storage → Local Folder**. Select one directory once. Learnitive remembers the browser-granted directory handle while site data remains available.\n\n## All projects synchronize\n\nExisting Browser projects are reconciled into the selected folder immediately. New projects, templates, ZIP imports, Git clones, AI Builder projects and Interactive Docs synchronize automatically.\n\n## Folder structure\n\nEach project lives in an immediate child folder whose name exactly matches its project slug. Hidden **.learnitive** metadata stores stable local identity, sync state and local deletion tombstones. It contains no login token or account ownership marker.\n\n## External editing\n\nYou can edit synchronized files with VS Code or another local editor. Learnitive reconciles external changes when Projects/project views open, the browser regains focus or you choose **Sync now**. Same-file concurrent edits become conflicts rather than silent overwrites.\n\n## Browser cleanup recovery\n\nA complete browser cleanup also removes the saved directory handle. Return to Projects, choose **Recover Projects Folder**, and select the previous folder again. Learnitive scans project manifests and restores the Browser copies without contacting an account project registry.\n\n## Disconnect\n\nDisconnect stops synchronization only. It never deletes Browser projects or files already written to the Projects Folder."
  },
  {
    "slug": "zip-import-export",
    "title": "ZIP Import and Export",
    "category": "Projects & Files",
    "sortOrder": 50,
    "content": "ZIP is the portable file-based route into and out of Learnitive. It is useful for migrations, backups and projects that do not need a Git history transfer.\n\n## Import a ZIP as a project\n\nIn the project creator choose **Import ZIP**, select a `.zip` archive and choose the project name. Learnitive creates a browser project, extracts the archive and then inspects the imported files to detect an appropriate project profile when possible.\n\n## Import into an existing project\n\nProject ZIP actions can also import an archive into the current project. Learnitive blocks this operation while live collaboration is active so a bulk file replacement cannot race against collaborative edits.\n\n## Export the current project\n\nUse the project ZIP export action to flush pending collaborative state to project storage and stream the current project files into a downloadable archive. The ZIP contains project files, not a snapshot of the temporary Linux container.\n\n## Size and browser limits\n\nLearnitive applies archive safety limits before import. Browser storage quota can also limit very large projects. If an archive is rejected, reduce generated/vendor files and keep dependencies reproducible through manifests rather than bundling package caches.\n\n## Recommended migration workflow\n\nFor a project from another IDE, start with source files, configuration, manifests and assets. Import the ZIP, verify the detected project mode, then run or build inside Learnitive. Reinstall declared dependencies in the terminal instead of copying another machine's dependency cache.\n\n## ZIP versus Git\n\nChoose ZIP for a simple snapshot. Choose [Git Project Import](/docs/git-project-import) when commit history and remotes matter."
  },
  {
    "slug": "git-project-import",
    "title": "Git Project Import",
    "category": "Projects & Files",
    "sortOrder": 60,
    "content": "Learnitive can clone a Git repository into a browser project, preserving repository history while giving the result the same editor, runtime and preview workflows as any other project.\n\n## Clone a repository\n\nOpen the clone repository workflow, choose a workspace name and enter the repository URL. Learnitive creates a browser-backed project, clones the repository and detects a project profile from the resulting files when possible.\n\n## Authentication\n\nPrivate repositories may require a token. The Git dialog warns before sending authentication through the default public CORS proxy and requires explicit confirmation in that situation. Prefer a trusted/self-hosted proxy or another trusted Git path when credentials are involved.\n\n## After cloning\n\nInspect the detected mode and entry file, then install project dependencies from the normal manifest in the Interactive Terminal if needed. Use [Run Build and Preview](/docs/run-build-preview) to verify the project rather than assuming another platform's launch command is identical.\n\n## Repository history\n\nA clone keeps Git metadata so you can inspect changes, commit, fetch, pull and push through the Git workflow. Browser storage remains the project filesystem; the temporary runtime is a working environment, not the Git source of truth.\n\n## Migrations from other tools\n\nWhen moving from Cursor, Replit, Codespaces or another editor, bring the repository first, then translate secrets, environment variables and run configuration separately. Learnitive should be able to rebuild from the repository and declared dependencies.\n\n## Alternative\n\nIf history does not matter, [ZIP Import and Export](/docs/zip-import-export) is often simpler."
  },
  {
    "slug": "file-tree-tabs",
    "title": "File Tree and Editor Tabs",
    "category": "Projects & Files",
    "sortOrder": 70,
    "content": "Learnitive uses a project file tree for filesystem navigation and VS Code-style editor tabs for the files you are actively working on.\n\n## Open a file\n\nSelect a file in the tree. Learnitive opens it in the editor and creates or activates its tab. The active file is visually distinct from other open files; merely having a file open does not make every tree item bold.\n\n## Keep several files open\n\nTabs are stored per workspace so switching projects does not mix unrelated open-file state. The tab row can scroll horizontally when many files are open, and the active tab is brought into view.\n\n## Close a tab\n\nUse the tab close control, middle-click where supported or the normal close-tab shortcut. Closing a tab only closes the editor view; it does not delete the file from the project.\n\n## Rename move and delete\n\nFile-tree operations reconcile open tabs so a renamed or moved file continues to point at its new path where possible, while deleting a file removes stale editor state. Confirm destructive filesystem actions carefully, especially when the project also has pending Projects Folder synchronization.\n\n## File content and project mode\n\nThe project mode configures the overall runtime/output workflow, but a project can contain many file types. Open configuration, source, assets, Markdown and other text files directly from the same tree.\n\n## Related editor guide\n\nFor editor behavior, Run/Build actions and output surfaces, continue with [Code Editor and IDE](/docs/code-editor)."
  },
  {
    "slug": "project-storage",
    "title": "Project Storage and Recovery",
    "category": "Projects & Files",
    "sortOrder": 80,
    "content": "Learnitive uses a local-first two-replica project model. Browser/OPFS is the normal working copy and one optional Projects Folder is the durable, human-accessible filesystem replica.\n\n## No account project registry\n\nNormal project names, slugs, modes and inventory are not registered in the SaaS database for storage or recovery. Project identity travels with the Browser workspace and, when connected, the project's own **.learnitive/project.json** manifest.\n\n## Connect storage\n\nOpen **Projects → Storage → Local Folder**. No login is required. Learnitive opens the browser directory picker and synchronizes every normal Browser project into **<Projects Folder>/<projectSlug>/**.\n\n## Recovery after Browser data loss\n\nIf Browser/OPFS, IndexedDB and the saved directory handle are cleared, choose **Recover Projects Folder** and select the same filesystem folder again. The root index is rebuildable from child project manifests, so a missing root index does not prevent recovery.\n\n## Disconnected deletion semantics\n\nThe Projects Folder is a durable backup replica. If you delete a Browser project while the Projects Folder is disconnected, an older untouched copy may still be offered during a later recovery. Learnitive warns before that deletion. When the folder is connected, local tombstones/trash prevent normal deleted projects from being restored accidentally.\n\n## Accounts and online services\n\nLogin is independent from project storage. Features that consume authenticated server resources, such as paid compute or hosted collaboration, may ask you to sign in when you invoke them. That does not register the local project as account inventory."
  },
  {
    "slug": "editor-overview",
    "title": "Editor Overview",
    "category": "Editor & IDE",
    "sortOrder": 10,
    "content": "The Learnitive editor is a multi-file development workspace rather than a single text box. It keeps the project tree, open-file tabs, code editing, document editing, output and runtime actions around the same project.\n\n## Multi-file editing\n\nOpen files from the project tree and keep several files open as tabs. The active tab and active file are emphasized; open files are not all rendered as active. Tabs can be closed without deleting the underlying file.\n\n## File tree\n\nThe project tree is the authoritative view of project structure. Create, rename, move and delete files and folders from project controls. Open tabs reconcile with file operations so a renamed or moved file does not leave a stale editor identity behind.\n\n## Language-aware surfaces\n\nLearnitive chooses output surfaces from the project mode. CLI languages use Console and can expose Input. Web projects use Web Preview. Markdown provides document-oriented editing. LaTeX adds Source, Visual and PDF-specific tools.\n\n## Terminal beside the editor\n\nThe Interactive Terminal runs in the active project environment and is the right place for package managers, compilers, Git, shells, servers and diagnostics that do not fit a one-click Run action.\n\n## AI beside the editor\n\nInteractive AI can work with the current file or project context. AI Agent can span multiple files and shell commands. AI Web App Builder creates a normal project that immediately becomes editable in the same IDE.\n\n## Related guides\n\nContinue with [Code Editor and IDE](/docs/code-editor), [Keyboard Shortcuts](/docs/keyboard-shortcuts), [Program Input](/docs/program-input) and [Web Preview](/docs/web-preview)."
  },
  {
    "slug": "code-editor",
    "title": "Code Editor and IDE",
    "category": "Editor & IDE",
    "sortOrder": 20,
    "content": "The Learnitive code editor is the primary editing surface for programming, web, Markdown and source-oriented project files. It is designed to work with the runtime rather than pretending execution is separate from the project.\n\n## Open files and tabs\n\nSelect a file in the project tree to open it. Open files become tabs, the current tab is highlighted, and tab state is kept per workspace. You can close tabs with the visible close control, middle-click where supported, or the normal close-tab shortcut. Closing a tab does not delete the file.\n\n## Edit normal project files\n\nLearnitive edits the file format your project actually uses: Python, JavaScript, TypeScript, C, C++, Java, Go, Rust, PHP, Ruby, R, Bash, HTML, framework source, Markdown, LaTeX and supporting configuration files. Syntax and project behavior come from the selected project mode and file type.\n\n## Run and build\n\nThe workspace presents Run/Build/Compile actions appropriate to the active project. CLI output appears in Console. Standard CLI modes can accept stdin from the Input tab. Web modes use Web Preview. Build failures remain visible so you can inspect the first useful error rather than losing it behind a generic failure state.\n\n## Use the terminal for full control\n\nOpen the terminal when you need a package manager, custom command, test runner, development server, Git operation or system utility. The terminal and editor work on the same active sandbox project working tree while the environment is running.\n\n## AI workflows\n\nInteractive AI can explain code, suggest changes and help diagnose errors. AI Agent can inspect multiple files and perform shell-backed work. AI Web App Builder creates a project rather than a sealed generated artifact, so every generated file stays editable here.\n\n## File safety\n\nRenames, moves and deletes reconcile with open tabs. Durable source should remain in your browser/local project path, Git or exported archive rather than relying on a temporary runtime container.\n\n## Next steps\n\nSee [Supported Languages](/docs/supported-languages), [Run Build and Preview](/docs/run-build-preview), [Program Input](/docs/program-input), [Console Output](/docs/console-output) and [Interactive Terminal](/docs/linux-terminal-pro)."
  },
  {
    "slug": "keyboard-shortcuts",
    "title": "Keyboard Shortcuts",
    "category": "Editor & IDE",
    "sortOrder": 30,
    "content": "Learnitive follows familiar editor and browser conventions while avoiding shortcuts that the browser or operating system reserves.\n\n## Editing\n\nUse your platform shortcuts for undo, redo, copy, paste, select all and search. Editor history is scoped to the current editing surface and file state.\n\n## File tabs\n\nUse the visible tab close action for certainty. Where supported, middle-click closes a file tab and Ctrl/Cmd+W closes the active editor tab when Learnitive can safely intercept the command.\n\n## Navigation\n\nUse the project file tree, open tabs, documentation navigation and visible project actions instead of depending on hidden shortcuts. This keeps the workspace usable when a browser captures a keyboard combination first.\n\n## Terminal\n\nTerminal keyboard behavior follows the shell and terminal emulator. Common shell control sequences therefore remain available inside the terminal rather than being repurposed as editor commands.\n\n## Accessibility\n\nButtons, menus, dialogs, tabs and documentation controls remain keyboard focusable. If a browser prevents a shortcut, use the equivalent visible command."
  },
  {
    "slug": "supported-languages",
    "title": "Supported Languages and Frameworks",
    "category": "Editor & IDE",
    "sortOrder": 40,
    "content": "Learnitive supports multiple project modes. The list below is generated from the same project-mode catalog used by the application so the documentation does not need a separate hand-maintained language list.\n\n{{PROJECT_MODE_CATALOG}}\n\n## How project modes affect the workspace\n\nA project mode determines the default entry file, runtime provider, primary output and whether Console, stdin, Web Preview or PDF Preview are relevant. The mode is a workflow hint, not a restriction on every file you can keep in the project.\n\n## CLI languages\n\nConsole-oriented modes can run a program and show stdout/stderr. Modes that support stdin expose the Input workflow so you can provide data before execution.\n\n## Web projects\n\nStatic HTML and Vite-based framework modes open a browser preview rather than a stdin-oriented console workflow. Use the terminal for package scripts, dependency installation and long-running development commands.\n\n## Document projects\n\nMarkdown uses document-oriented output. LaTeX uses build/compile and PDF-oriented workflows rather than stdin.\n\n## Runtime software\n\nThe public [Software and Packages](/software-list) page describes important tools in the certified Learnitive development image. Project-specific libraries still belong in your own project manifests and setup scripts."
  },
  {
    "slug": "run-build-preview",
    "title": "Run Build and Preview",
    "category": "Run, Build & Preview",
    "sortOrder": 10,
    "content": "Learnitive chooses the main execution action from the project mode. The goal is to make the common path one click while leaving the full Linux terminal available for custom workflows.\n\n## Run\n\nConsole-oriented languages use **Run** to execute the configured entry point. stdout and stderr appear in Console. When the language accepts stdin, enter it in the Input tab before starting the run.\n\n## Build\n\nCompiled and framework projects can require a build step. Learnitive reports build output rather than hiding it. If a build fails, start with the first actionable compiler or tool error and then rerun.\n\n## Preview\n\nWeb projects use Web Preview for the running application or generated site. Static HTML can preview directly; framework projects use the configured runtime/build workflow. Preview is part of the current project environment, not a replacement for your source files.\n\n## Compile\n\nLaTeX projects use Local or Cloud Compile and open PDF output. Compilation and PDF workflows are documented separately because their engines, logs and SyncTeX behavior differ from normal code execution.\n\n## Terminal fallback\n\nWhen the standard action is not enough, open the Interactive Terminal and run the exact command you need. This is useful for test runners, package managers, custom build scripts, servers and diagnostics.\n\n## Related guides\n\nRead [Program Input](/docs/program-input), [Console Output](/docs/console-output), [Web Preview](/docs/web-preview) and [Build and Run Troubleshooting](/docs/troubleshooting-project-run)."
  },
  {
    "slug": "program-input",
    "title": "Program Input",
    "category": "Run, Build & Preview",
    "sortOrder": 20,
    "content": "Learnitive exposes program stdin as an Input tab only for project modes that support standard input.\n\n## Supported stdin modes\n\nPython, JavaScript, TypeScript, Node.js, C, C++, Java, Go, Rust, PHP, Ruby, R and Bash project modes can expose stdin according to the project-mode catalog.\n\n## Enter input\n\nPlace exactly the text that the program should read in the Input surface. New lines are significant for programs that read one value or record per line.\n\nExample input:\n\n```text\nAda\n42\n```\n\nA program can then read those values using its normal language APIs.\n\n## When Input is hidden\n\nReact, Vue, Svelte, Vite web projects, static HTML, Markdown and LaTeX do not show an irrelevant stdin workflow. Use Web Preview, document output or PDF output instead.\n\n## Interactive prompts\n\nThe one-click run input surface is best for predetermined stdin. For a program that needs live prompts, open the Interactive Terminal and run it there so the PTY can handle the interactive session."
  },
  {
    "slug": "console-output",
    "title": "Console Output",
    "category": "Run, Build & Preview",
    "sortOrder": 30,
    "content": "Learnitive uses the Console surface for stdout, stderr, exit status and one-click run/build feedback from console-oriented project modes.\n\n## stdout and stderr\n\nNormal program output and errors are kept visible so you can distinguish a successful result from a runtime or compiler failure. Do not treat an empty console as proof of success if the program is expected to produce output.\n\n## Build diagnostics\n\nFor compiled languages and tooling, read the earliest useful error first. Later errors are often consequences of the first missing file, invalid syntax or failed dependency step.\n\n## Input and Console\n\nInput is data supplied to the program; Console is what the run returns. Keeping the two separate makes it easier to rerun the same input while changing code.\n\n## When to use the terminal instead\n\nUse the terminal for interactive prompts, long-running servers, custom command flags, test runners, package managers and workflows that need a PTY rather than a one-shot execution result.\n\n## Troubleshooting\n\nSee [Build and Run Troubleshooting](/docs/troubleshooting-project-run) when a run never starts, exits unexpectedly or produces an environment-related error."
  },
  {
    "slug": "web-preview",
    "title": "Web Preview",
    "category": "Run, Build & Preview",
    "sortOrder": 40,
    "content": "Web Preview shows supported web projects inside the Learnitive development workflow while the source remains fully editable.\n\n## Supported web modes\n\nThe project catalog includes static HTML, TypeScript with Vite, React with Vite, Vue with Vite and Svelte with Vite. Framework modes may build or run a development process before the preview becomes available.\n\n## Edit and refresh\n\nChange project files in the code editor, then use the project preview workflow to inspect the result. If the framework development server reports an error, inspect the build/terminal output rather than assuming the preview frame itself is broken.\n\n## Dependencies\n\nKeep package dependencies in package.json and the normal lockfile for the project. Use the terminal when you need to install or inspect packages.\n\n## Ports and processes\n\nLong-running development servers belong to the active runtime environment. Restart the relevant process when configuration changes require it. Destroying the environment removes temporary processes and server-side state.\n\n## Security\n\nAuthenticated/private previews remain subject to Learnitive project and runtime controls. A preview URL is not a substitute for project authorization.\n\n## Troubleshooting\n\nIf a preview is blank, check the build command, terminal output, application console and expected entry file. See [Build and Run Troubleshooting](/docs/troubleshooting-project-run)."
  },
  {
    "slug": "cli",
    "title": "CLI Workflow",
    "category": "Run, Build & Preview",
    "sortOrder": 50,
    "content": "Learnitive supports command-driven development through the Interactive Terminal rather than requiring every workflow to fit a toolbar action.\n\n## Open the terminal\n\nUse the terminal from the active project when you need direct shell control. Commands run in the project sandbox working tree while the environment is alive.\n\n## Common tasks\n\nUse normal tools for package installation, compilers, Git, tests, build systems, file inspection and scripts. The public Software and Packages page describes the important tools included in the certified image.\n\n## Keep commands reproducible\n\nPut durable setup in project manifests, lockfiles, Makefiles, package scripts, shell scripts or documented setup instructions. Packages installed only into a disposable environment can disappear when that environment is destroyed or expires.\n\n## Project durability\n\nGit, browser/local project storage and exported archives remain the durable layers. The terminal is an execution surface around that project, not the sole project store."
  },
  {
    "slug": "runtime-detection",
    "title": "Project Mode and Runtime Detection",
    "category": "Run, Build & Preview",
    "sortOrder": 60,
    "content": "Learnitive uses a project mode to decide which default entry file, one-click runtime action and output surface make sense. Imported and opened projects can be inspected to detect an appropriate profile from their files.\n\n## What detection changes\n\nThe detected mode can select the primary language, entry file and whether the workspace should emphasize Console, Input, Web Preview or PDF Preview. It does not prevent the project from containing other languages or support files.\n\n## Examples\n\nA Python project normally routes Run output to Console and supports stdin. A React + Vite project uses Web Preview and package-based build/run behavior. A LaTeX project uses compile and PDF-oriented output. The exact current list is generated in [Supported Languages and Frameworks](/docs/supported-languages).\n\n## Imported projects\n\nZIP import, Git clone and opening an existing local folder all trigger project-target detection when possible. If a repository contains several possible targets, inspect the chosen mode and project files before running commands.\n\n## Entry files\n\nStarters provide a known default entry file. Existing repositories can use their own package scripts or configuration, so the terminal remains the right place for non-standard build systems.\n\n## When detection is wrong\n\nDo not rename or delete source files merely to satisfy an incorrect guess. Review the project configuration/profile, choose the intended mode where the UI exposes that control, and use the terminal to verify the real build command.\n\n## Troubleshooting\n\nIf one-click Run or Preview is not appropriate for the project, see [Build and Run Troubleshooting](/docs/troubleshooting-project-run)."
  },
  {
    "slug": "build-errors",
    "title": "Reading Build and Runtime Errors",
    "category": "Run, Build & Preview",
    "sortOrder": 70,
    "content": "Learnitive keeps build and runtime failures visible so you can diagnose the first useful error instead of treating a failed Run or Preview as an empty result.\n\n## Start with the first meaningful error\n\nLater errors are often consequences of an earlier missing file, syntax problem, dependency failure or configuration error. Read Console, build output or terminal stderr from the top of the relevant failure rather than fixing the last line first.\n\n## Separate source errors from environment errors\n\nA syntax/type/compiler error usually belongs in project source. A missing executable or package can indicate that dependencies have not been installed in the runtime. A permission/network failure is an environment or policy issue. A blank Web Preview can be a successful build followed by an application runtime error.\n\n## Reproduce with the terminal\n\nWhen a one-click action hides too much detail, run the project's documented command in the Interactive Terminal. Package managers, compilers and test tools often provide more context there.\n\n## Avoid editing generated dependencies\n\nFix manifests and source instead of patching `node_modules`, caches or compiled output. Reinstalling declared dependencies should recreate the environment on a fresh runtime.\n\n## Ask AI with evidence\n\nIf you use Interactive AI or Agent to help, include the relevant error and project context. Agent can be useful for an inspect → edit → verify loop, but review broad fixes before accepting them.\n\n## Related troubleshooting\n\nContinue with [Build and Run Troubleshooting](/docs/troubleshooting-project-run), [Terminal Troubleshooting](/docs/troubleshooting-terminal) or [LaTeX Troubleshooting](/docs/troubleshooting-latex)."
  },
  {
    "slug": "texlab",
    "title": "Terminal and Runtime",
    "category": "Terminal & Runtime",
    "sortOrder": 10,
    "content": "The Interactive Terminal is a real Ubuntu development environment for commands, builds, Git, scientific work and project tooling. The environment lifecycle is separate from any individual terminal tab or PTY.\n\n## Authenticated environments\n\nAuthenticated users receive a plan-controlled environment that can host multiple terminal sessions. Closing one terminal closes that PTY; it does not automatically destroy the environment.\n\n## Guest environments\n\nSigned-out terminal experiences are disposable and are cleaned after the browser lease/activity window ends. Do not use a guest runtime as the only copy of important files.\n\n## Project working tree\n\nWhen a project environment is active, editor synchronization, Terminal, Agent work, build/test processes and Preview operate on the active sandbox working tree under the Learnitive project workspace. Durable source remains in the project storage path.\n\n## Close versus destroy\n\nClosing a terminal ends one session. Closing active sessions ends PTYs while preserving the environment where supported. **Destroy environment** explicitly removes the temporary runtime container and its server-side workspace.\n\n## Lifetime and limits\n\nRuntime lifetime, storage, concurrency and networking are controlled by the current account policy. Reopening a terminal is not a promise that an expired environment can be resurrected with all temporary packages and processes intact.\n\n## Related guides\n\nRead [Interactive Terminal](/docs/linux-terminal-pro), [Runtime Lifecycle](/docs/runtime-lifecycle), [Terminal Files](/docs/terminal-files), [Terminal Sync](/docs/sync-terminal-projects) and [Runtime Software](/docs/runtime-software)."
  },
  {
    "slug": "linux-terminal-pro",
    "title": "Interactive Terminal",
    "category": "Terminal & Runtime",
    "sortOrder": 20,
    "content": "The standalone and project terminal experiences provide PTY-backed shell access to the Learnitive Ubuntu runtime.\n\n## Shell access\n\nUse normal shell commands, compilers, package managers, Git, scripting tools and diagnostics. The exact installed baseline is documented at [Software and Packages](/software-list).\n\n## Multiple sessions\n\nAn authenticated environment can host multiple terminal PTYs subject to the current plan policy. Closing one session does not imply that every other terminal or process has stopped.\n\n## Same project environment\n\nFor an active project, the terminal works in the same temporary project sandbox used by server execution and supported preview/Agent operations. That makes it possible to inspect files created by a build and immediately continue editing them.\n\n## Full-page terminal routes\n\nLearnitive keeps `/terminal` and `/appterminal` as standalone full-viewport terminal routes. Both use the same terminal implementation rather than separate runtime logic.\n\n## Destroy carefully\n\nDestroy environment removes the disposable server environment. Synchronize, commit or export work you want to keep first.\n\n## Related guides\n\nSee [Runtime Lifecycle](/docs/runtime-lifecycle), [Terminal Files](/docs/terminal-files) and [Terminal Troubleshooting](/docs/troubleshooting-terminal)."
  },
  {
    "slug": "runtime-lifecycle",
    "title": "Runtime Lifecycle",
    "category": "Terminal & Runtime",
    "sortOrder": 30,
    "content": "Learnitive deliberately separates a terminal session, a runtime environment and durable project storage.\n\n## Terminal session\n\nA session is one PTY connection. Close it when you are finished with that shell. Other sessions and the underlying environment can continue.\n\n## Runtime environment\n\nThe environment is the temporary Ubuntu container/workspace used for commands and server execution. It has policy-controlled lifetime and storage. Rebuilding or recreating it can remove manually installed packages and background processes.\n\n## Durable project\n\nBrowser project storage, an optional synchronized Projects Folder, Git and exported archives are the durable source paths. Treat the runtime as reconstructable infrastructure around those files.\n\n## Destroy environment\n\nDestroying is explicit and higher impact than closing a terminal. Learnitive requests removal of the environment and temporary server workspace. Make sure important runtime-created files have been synchronized back first.\n\n## Reproducible setup\n\nRecord dependencies in package manifests, requirements files, lockfiles, build scripts or project documentation so a fresh environment can be brought back to the same working state."
  },
  {
    "slug": "sync-terminal-projects",
    "title": "Terminal Sync",
    "category": "Terminal & Runtime",
    "sortOrder": 40,
    "content": "Terminal Sync reconciles the active runtime working tree with the durable Learnitive project.\n\n## Send Files\n\nWhen a project environment is activated, Learnitive materializes project files into the sandbox working tree used by Terminal, Agent, build/test and Preview processes.\n\n## Sync Back\n\nWhen server-side tools create or modify project source, sync/reconciliation moves supported changes back into the browser/local project. Newly created nested files and folders can be brought back without requiring them to exist locally first.\n\n## Conflicts and Deletions\n\nConflicting edits and destructive file changes should remain explicit. Review the result when the same source changed on both sides or when a deletion would remove durable project data.\n\n## Before environment destruction\n\nDestroying or expiring the Linux environment removes temporary runtime storage. Synchronize work that matters before you intentionally remove it.\n\n## Git is complementary\n\nSync keeps the runtime and active project aligned. Git provides durable history and remote collaboration. Use both where appropriate."
  },
  {
    "slug": "terminal-files",
    "title": "Terminal Files",
    "category": "Terminal & Runtime",
    "sortOrder": 50,
    "content": "The terminal file workflow helps you inspect artifacts created inside the active Learnitive runtime and move durable project changes back to project storage.\n\n## Project files\n\nThe active project is materialized into the sandbox working tree while the environment is running. Commands can create, rename and edit files there just as they would in a normal Linux directory.\n\n## Generated artifacts\n\nBuild outputs, datasets, reports and other temporary artifacts can be inspected or downloaded according to the terminal file tools exposed by the current workspace.\n\n## Keep source changes\n\nProject-source changes should synchronize back to the durable browser/local project. Do not assume that a file created only in a disposable container will survive environment destruction.\n\n## Large or binary files\n\nTreat large binaries and generated outputs deliberately. Keep reproducible sources and manifests in the project, and export or download artifacts you actually need to preserve.\n\n## Security\n\nTerminal file APIs remain authenticated and scoped to the active environment. A workspace path is not a public file-sharing URL."
  },
  {
    "slug": "runtime-software",
    "title": "Runtime Software",
    "category": "Terminal & Runtime",
    "sortOrder": 60,
    "content": "Learnitive uses a certified development image for the terminal and server-side execution. The public [Software and Packages](/software-list) page is the best current inventory of important installed commands, compilers and libraries.\n\n## Included baseline\n\nThe image includes common programming languages, compilers, build tools, Git utilities, TeX Live and scientific tooling. The public catalog is tied to the runtime definitions and smoke checks rather than maintained as an unrelated marketing list.\n\n## Project dependencies\n\nKeep application dependencies in the normal project mechanism: package.json and lockfiles, Python requirements or environment files, Cargo, Go modules, Maven/Gradle, native build files, TeX source and similar manifests.\n\n## Manually installed packages\n\nA package installed only inside a temporary runtime belongs to that runtime. It can disappear after destroy, reset or expiry. Reproducible project setup is safer than relying on one long-lived container.\n\n## Networking\n\nAn installed command does not imply unrestricted Internet access. Runtime networking is governed separately by account policy and security controls."
  },
  {
    "slug": "terminal-python-scientific",
    "title": "Scientific Python",
    "category": "Terminal & Runtime",
    "sortOrder": 70,
    "content": "Learnitive can run scientific Python workflows in the same project environment used for source, terminal commands and generated artifacts.\n\n## Python tools\n\nUse the certified runtime baseline for Python and the scientific packages documented by the Software and Packages inventory. Add project-specific dependencies through a reproducible requirements or environment workflow.\n\n## Scripts and notebooks\n\nKeep analysis scripts, data-processing code, figures and manuscript sources together when that improves reproducibility. The browser editor handles source files while the terminal gives access to normal Python commands and package tooling.\n\n## Generated figures and data\n\nWrite generated outputs into the project working tree when they belong with the project, then synchronize or export them before destroying the environment.\n\n## Resource awareness\n\nScientific workloads can be memory or CPU intensive. Work within current runtime limits and prefer reproducible scripts over relying on process state that exists only in one temporary container."
  },
  {
    "slug": "installing-dependencies",
    "title": "Installing Project Dependencies",
    "category": "Terminal & Runtime",
    "sortOrder": 80,
    "content": "Use the Learnitive Interactive Terminal to install project dependencies when the language or framework expects a package manager, compiler toolchain or environment setup beyond the starter files.\n\n## Prefer declared dependencies\n\nA reproducible project records dependencies in files such as `package.json`, language package manifests, requirements files or the build system's own configuration. Install from those declarations instead of relying on packages that happen to exist in one runtime container.\n\n## Work in the project directory\n\nLoad/synchronize the project into the terminal workspace, confirm the current directory and then run the package manager command documented by the project. Keep generated dependency directories out of ZIP/Git migrations when they can be recreated safely.\n\n## Runtime persistence\n\nInstalled packages live in the runtime environment or project working tree according to the tool. Free and Pro runtime persistence policies differ, so the safest workflow is always one that can reinstall dependencies from project metadata.\n\n## Public network access\n\nDependency installation that reaches public package registries is subject to the current account/network policy. A package manager error caused by blocked or unavailable networking is different from a missing manifest or incompatible dependency.\n\n## Verify after install\n\nRun the project's build, test or start command. If a dependency install succeeds but the app still fails, inspect the first build/runtime error rather than repeatedly reinstalling everything.\n\n## Security\n\nPackage installation can execute package scripts. Use trusted dependencies and review unfamiliar install instructions before running them in the shell."
  },
  {
    "slug": "processes-and-ports",
    "title": "Processes Ports and Web Preview",
    "category": "Terminal & Runtime",
    "sortOrder": 90,
    "content": "Learnitive web projects can run development processes inside the isolated Linux environment and expose supported preview traffic through the product's private Web Preview path.\n\n## Start the application\n\nUse the normal project Run/Build/Preview action when the project mode supports it, or start the documented development command in the Interactive Terminal. Framework projects commonly use a package script that launches a local HTTP server.\n\n## Keep the process alive\n\nA preview only works while the relevant runtime process is running. Closing a PTY can close the shell process attached to that terminal session, while destroying the environment removes the temporary runtime workspace according to the runtime lifecycle.\n\n## Ports\n\nUse the port expected by the project/runtime integration rather than binding arbitrary services and assuming they are public. Web Preview is an application feature, not unrestricted public port forwarding.\n\n## Preview is private\n\nThe preview route is designed around the Learnitive project/session context. Do not treat a preview URL as a durable public deployment endpoint.\n\n## Diagnose failures\n\nIf the browser preview is blank, check both the terminal process and the Web Preview error/console. A server that never started, a build failure and a client-side JavaScript exception require different fixes.\n\n## Related guides\n\nRead [Web Preview](/docs/web-preview), [Runtime Lifecycle](/docs/runtime-lifecycle) and [Build and Run Troubleshooting](/docs/troubleshooting-project-run)."
  },
  {
    "slug": "runtime-security",
    "title": "Runtime Security and Isolation",
    "category": "Terminal & Runtime",
    "sortOrder": 100,
    "content": "Learnitive runs development commands in isolated server-side environments rather than executing arbitrary shell commands inside the public web server process.\n\n## Project-scoped access\n\nAuthenticated runtime operations are tied to the current account/project authorization. Collaboration and share links do not automatically grant unrestricted shell access; permission checks remain separate from the existence of a project URL.\n\n## Environment lifecycle\n\nGuest environments are disposable. Authenticated environments follow the current plan-limited lifecycle. Destroying an environment explicitly removes the temporary container/workspace; closing a terminal session only closes that PTY. See [Runtime Lifecycle](/docs/runtime-lifecycle).\n\n## Network policy\n\nOutbound/public Internet access follows product policy and can differ by plan. Network restrictions are security boundaries, not compiler errors. Do not document a temporary network success as a permanent entitlement guarantee.\n\n## Secrets\n\nKeep API keys and repository tokens out of source files. BYOK AI credentials belong in the AI configuration path, while Git authentication should use the repository workflow. Do not paste long-lived secrets into shared terminal history or lesson content.\n\n## Untrusted commands\n\nAI Agent, package installers and copied shell commands can all change files or execute code. Review commands that are destructive, security-sensitive or broader than the requested task.\n\n## Project durability\n\nIsolation also means the runtime is not the canonical backup. Keep important work in browser/local project storage, Git or ZIP even when the runtime itself is persistent."
  },
  {
    "slug": "ai-overview",
    "title": "AI in Learnitive",
    "category": "AI",
    "sortOrder": 10,
    "content": "Learnitive provides several AI workflows around the same editable project. The important distinction is not only which model you use, but what level of project access the workflow receives.\n\n## Interactive AI\n\nUse Interactive AI for questions, explanations, focused assistance and supported editor actions. It is the conversational surface for work that does not require an autonomous multi-step project task.\n\n## AI Agent\n\nAI Agent can work across project files and supported shell-backed actions. Use it when the task spans several edits, diagnostics or build/test steps. Review important changes and keep the underlying project under your control.\n\n## AI Web App Builder\n\nAI Web App Builder starts from a description and produces a real Learnitive project. Generated files open in the normal code editor, can use shell access for build/run work, and can be continued manually or with Agent.\n\n## Ollama\n\nOllama connects the browser to an Ollama service on your own machine. Learnitive discovers models through the local service and applies local/cloud model safety checks. See [Ollama](/docs/ollama).\n\n## BYOK cloud AI\n\nBring-your-own-key providers use credentials you configure for the browser/session workflow. Privacy controls determine whether project/manuscript context may be sent to a cloud provider.\n\n## Research AI\n\nPaper Memory, AI Review and Deep Research add evidence-oriented workflows for research and LaTeX projects. Generated analysis is assistance, not automatically verified evidence.\n\n## Choose the narrowest tool\n\nPrefer a focused assistant action for a focused question. Use Agent or Builder when the task genuinely needs project-wide edits, commands or a generated starting application."
  },
  {
    "slug": "ai-builder",
    "title": "AI Web App Builder",
    "category": "AI",
    "sortOrder": 20,
    "content": "AI Web App Builder turns a description into a real, editable Learnitive project and then continues through the same IDE, shell and preview workflow as a manually created project.\n\n## Start with an application description\n\nDescribe the application, audience, main interactions and preferred technology when you have one. A specific prompt gives the builder a clearer file structure and first implementation.\n\n## Builder creates project files\n\nThe output is not only a screenshot or hosted black box. Builder creates normal project files that open in the Learnitive file tree and code editor. You can inspect every generated source file and configuration file.\n\n## Shell access\n\nBuilder can use the project development environment for supported setup, dependency, build, run and diagnostic tasks. This is the important difference between a visual mockup generator and an application-building workflow: generated code can be exercised in a real shell-backed project.\n\n## Preview the result\n\nFor supported web modes, open Web Preview and test the generated application. Use Console or terminal output to diagnose build errors. Keep framework dependencies in normal project manifests.\n\n## Continue manually\n\nEdit files directly, add new components, change styles, refactor code or replace generated sections. Builder does not lock the project into a separate document model.\n\n## Continue with AI Agent\n\nUse Agent for follow-up tasks that span multiple files or need shell-backed checks. You do not need to regenerate the entire project to make a small or medium change.\n\n## Keep ownership\n\nUse local-first project storage, ZIP and Git like any other Learnitive project. The builder is a creation workflow around your project, not the permanent owner of it.\n\n## Good starting projects\n\nTypical uses include React/Vite applications, static sites, small Node services, Python tools and Vue or Svelte front ends supported by the project-mode catalog."
  },
  {
    "slug": "ai-agent",
    "title": "AI Agent",
    "category": "AI",
    "sortOrder": 30,
    "content": "Learnitive AI Agent is the project-oriented AI workflow for tasks that are larger than a single answer or editor suggestion.\n\n## Project context\n\nAgent can reason across supported project files rather than only the visible line of code. Give it a clear objective and relevant constraints so it can avoid unnecessary broad changes.\n\n## Shell-backed work\n\nWhen allowed by the project workflow, Agent can use the development environment for diagnostics, builds, tests and other supported commands. Shell access means Agent can verify more than a text-only model, but command output still needs to be interpreted carefully.\n\n## Edit loop\n\nA good Agent task follows a loop: inspect relevant files, make the smallest useful change, run an appropriate check, read failures, fix the cause and verify again.\n\n## Human control\n\nReview security-sensitive, destructive or wide-ranging changes. Keep Git or another durable history path for important projects. Agent output does not make a temporary runtime the source of truth.\n\n## When not to use Agent\n\nUse Interactive AI for a focused question and use AI Web App Builder when the primary goal is generating a new application starting point."
  },
  {
    "slug": "byok-ai",
    "title": "BYOK AI Providers",
    "category": "AI",
    "sortOrder": 40,
    "content": "BYOK means you connect your own supported AI provider credentials to Learnitive instead of relying on a shared application key.\n\n## Configure a provider\n\nOpen AI Settings, choose a supported cloud provider and enter the credential required by that provider. Follow the provider's own account and billing controls for the key.\n\n## Credential handling\n\nLearnitive is designed to keep user provider credentials in the browser-side configuration path rather than publishing them as project files. Never commit an API key into a project repository or template.\n\n## Project context\n\nA cloud model can only help with context you intentionally allow the workflow to send. Privacy Mode is the control to use when you do not want manuscript/project context sent to a cloud provider.\n\n## Switching providers\n\nChanging the configured provider changes where future cloud AI requests are sent. Local browser AI and Ollama are separate paths.\n\n## Troubleshooting\n\nIf a cloud provider rejects a request, verify the key, provider/model selection, account quota and network availability. Provider errors are not fixed by recreating the Learnitive project."
  },
  {
    "slug": "ollama",
    "title": "Ollama",
    "category": "AI",
    "sortOrder": 50,
    "content": "Ollama lets Learnitive connect to models served by Ollama on your own computer. Learnitive treats local-model verification and cloud-backed Ollama models differently so a localhost connection is not automatically assumed to mean local inference.\n\n## Download Ollama\n\n[Download Ollama](https://ollama.com/download)\n\nInstall Ollama using the official installer for your operating system, then keep the Ollama service running while you use it with Learnitive.\n\n## Run a model\n\nDownload or start a model with normal Ollama commands. For example:\n\n```bash\nollama run llama3.2\nollama run qwen2.5-coder\n```\n\nUse `ollama list` to confirm that at least one model is available locally.\n\n## Allow the Learnitive origin\n\nLearnitive runs at https://www.learnitive.com while Ollama normally runs on localhost. Configure Ollama to allow the Learnitive browser origin and restart the service:\n\n```text\nOLLAMA_ORIGINS=https://www.learnitive.com\n```\n\nUse Ollama's current operating-system instructions for setting that environment variable.\n\n## Connect from Learnitive\n\nOpen AI Settings or the AI Assistant and choose **Use Local Ollama**. Refresh model discovery after adding or removing models. Learnitive checks the local service and validates the selected model before sending project or manuscript context through the local-service path.\n\n## Local versus cloud-backed models\n\nOllama can expose models whose inference is not actually local. Learnitive does not treat localhost alone as proof of local inference. Remote/cloud-backed models are kept out of the verified-local path.\n\n## Privacy Mode\n\nPrivacy Mode prevents cloud fallback/context use where the policy requires it. A verified local Ollama workflow can remain available without silently converting into a cloud request.\n\n## Troubleshooting\n\nIf discovery fails, confirm Ollama is running, visit the Ollama service locally, verify OLLAMA_ORIGINS, run `ollama list`, then use Refresh Ollama. See [Ollama Troubleshooting](/docs/troubleshooting-ollama)."
  },
  {
    "slug": "automatic-ai-suggestions",
    "title": "Automatic AI Suggestions",
    "category": "AI",
    "sortOrder": 60,
    "content": "Automatic AI Suggestions watch for safe editing opportunities after a short idle period. They are designed to stay outside the active typing path and to present changes for review rather than silently rewriting source.\n\n## Configure the watcher\n\nOpen AI Settings and choose the available automatic-AI mode for your current provider path. Pause the watcher temporarily when you want uninterrupted manual editing.\n\n## Idle behavior\n\nText edits create a short idle window. New typing invalidates stale work. Cursor-only movement should not force the same text to be repeatedly re-sent for review.\n\n## Safety gates\n\nLearnitive suppresses automatic suggestions in contexts where a rewrite would be ambiguous, such as protected document regions, structural LaTeX areas, active selections or overlapping unresolved review changes.\n\n## Review first\n\nA successful suggestion enters the review workflow for Accept or Reject. This keeps canonical project/manuscript source under human control."
  },
  {
    "slug": "ai-review",
    "title": "AI Review",
    "category": "AI",
    "sortOrder": 70,
    "content": "Learnitive AI Review turns an AI suggestion into a reviewable change rather than silently replacing project or manuscript content.\n\n## Review depth\n\nChoose a review mode appropriate to the task. Faster modes focus on broad issues while deeper workflows can spend more time on structure, evidence and verification.\n\n## Evidence-aware options\n\nWhere available, Paper Memory and research search can provide retrieved evidence. Keep retrieved sources distinguishable from generated prose and verify important claims before using them in a manuscript.\n\n## Reproducibility\n\nFor technical work, use review output as a prompt for concrete checks rather than as proof that code or analysis is correct. The Interactive Terminal and project files provide the environment for those checks.\n\n## Apply deliberately\n\nAI Review findings should enter a review/acceptance workflow instead of silently replacing canonical source."
  },
  {
    "slug": "paper-memory",
    "title": "Paper Memory",
    "category": "AI",
    "sortOrder": 80,
    "content": "Learnitive Paper Memory keeps research evidence close to the project so AI-assisted writing and review can retrieve from papers you explicitly add.\n\n## Add sources deliberately\n\nUse papers you are allowed to store and process. Keep bibliographic metadata and the underlying source identity clear enough that you can trace an AI-assisted claim back to evidence.\n\n## Retrieval\n\nPaper Memory retrieves project-scoped evidence rather than asking a model to invent citations from memory. The retrieved passage and page/source provenance remain more important than the generated summary.\n\n## AI providers\n\nPaper Memory can be used with supported local or cloud AI paths according to the current provider and Privacy Mode. A provider choice does not change the need to verify evidence.\n\n## Manuscript authority\n\nRetrieved evidence and generated analysis do not automatically rewrite the manuscript. Use citation and review workflows to apply changes deliberately."
  },
  {
    "slug": "templates-guide",
    "title": "Templates",
    "category": "Templates",
    "sortOrder": 10,
    "content": "Learnitive templates are validated starting projects for programming, web development, Markdown, LaTeX and other supported workflows.\n\n## Browse templates\n\nOpen [Templates](/templates) and filter by technology or use case. Template cards identify the relevant language/framework and provide a quick path into a complete project.\n\n## Ordinary project files\n\nA template creates normal files that open in the same project tree and code editor as any other Learnitive project. You are not locked into the template after creation.\n\n## Language and framework templates\n\nTemplates can target console languages, Node.js, Vite-based front ends, static web projects, Markdown and LaTeX. The project mode determines the default Run/Build/Preview behavior.\n\n## Templates versus AI Builder\n\nChoose a template when you want a known starting structure. Choose AI Web App Builder when you want the initial project generated from a natural-language description. Both end as editable Learnitive projects.\n\n## Dependencies\n\nKeep dependencies in the normal project manifests. The runtime can install project dependencies as needed, but a manually changed temporary environment is not a substitute for a reproducible project definition."
  },
  {
    "slug": "version-control",
    "title": "Version Control",
    "category": "Git & Collaboration",
    "sortOrder": 10,
    "content": "Git is the durable version-history layer for Learnitive projects. It complements local-first project storage and runtime synchronization.\n\n## Repository workflow\n\nUse normal Git commands in the Interactive Terminal for status, diff, branch, commit, fetch, pull and push. Keep credentials and remote access scoped to the account and repository you intend to use.\n\n## Commit source, not accidental runtime state\n\nTrack source files, manifests and intentional generated artifacts. Do not rely on the temporary container filesystem as history.\n\n## Before large AI or Agent changes\n\nCreate a commit or clean checkpoint before a wide refactor. This gives you a reviewable diff and an easy rollback path.\n\n## Collaboration\n\nLive Learnitive collaboration and Git solve different problems. Collaboration handles active shared editing; Git provides durable history and remote exchange."
  },
  {
    "slug": "terminal-git-github",
    "title": "Git and GitHub",
    "category": "Git & Collaboration",
    "sortOrder": 20,
    "content": "Use normal Git workflows from the Interactive Terminal while keeping Learnitive local-first project semantics.\n\n## Work in the active project\n\nGit commands operate on the active sandbox working tree while the environment is alive. Source changes reconcile with the project storage workflow; the sandbox remains disposable.\n\n## Authentication\n\nUse GitHub's current authentication mechanisms for HTTPS or SSH as appropriate to your account and repository. Do not paste long-lived credentials into project source.\n\n## Commit before destructive experiments\n\nGit is particularly useful before Agent-driven changes, dependency upgrades, migrations or large refactors.\n\n## Runtime lifetime\n\nA terminal environment can expire or be destroyed. Push important commits or synchronize them back to the durable project before relying on a temporary runtime to remember them."
  },
  {
    "slug": "collaboration",
    "title": "Collaboration",
    "category": "Git & Collaboration",
    "sortOrder": 30,
    "content": "Learnitive collaboration keeps authenticated participants around an authorized project rather than turning a project link into anonymous public editing.\n\n## Access\n\nStarting a collaboration is governed by the current plan and project permissions. Joining requires an authenticated Learnitive account and current authorization for the shared project.\n\n## Shared source\n\nSupported source files can be edited with presence and review metadata. Keep large binary additions and project-structure operations coordinated through the normal project workflow.\n\n## Review\n\nComments and Track Changes remain useful for discussing or accepting changes without immediately making every proposal canonical source.\n\n## Project durability\n\nCollaboration does not replace Git, browser/local storage or exported project archives. Keep an independent durable history for important work."
  },
  {
    "slug": "comments-and-track-changes",
    "title": "Comments and Track Changes",
    "category": "Git & Collaboration",
    "sortOrder": 40,
    "content": "Learnitive comments and Track Changes support deliberate review around editable project and manuscript content.\n\n## Comments\n\nUse comments for questions, review notes and discussion that should not become source text. Resolve comments when the discussion is complete.\n\n## Track Changes\n\nTracked insertions, deletions and replacements can be accepted or rejected explicitly. This is preferable to silently applying uncertain AI or collaborator edits.\n\n## AI proposals\n\nSupported AI suggestions enter the same review philosophy: generated changes should be inspectable before they become canonical source.\n\n## Collaboration\n\nIn live collaboration, review metadata and presence help identify who proposed or discussed a change while the underlying project remains portable outside the collaboration session."
  },
  {
    "slug": "learn",
    "title": "Learnitive Learn",
    "category": "Learn",
    "sortOrder": 10,
    "content": "Learnitive Learn combines instructional content with the same code editor, terminal and runtime capabilities used elsewhere in the product.\n\n## Courses and lessons\n\nCourses are organized into sections and items such as lessons, quizzes and assignments. A lesson can combine explanatory blocks, video, code, terminal activities, checkpoints and other interactive content.\n\n## Real project work\n\nInteractive exercises use Learnitive project modes rather than a separate toy language runner. This lets a course teach Python, C++, web development, Linux, Markdown, LaTeX and other supported workflows in the same environment learners can use for projects.\n\n## Progress\n\nSigned-in learners can track course progress according to the course structure and completion rules. Sequential courses can require earlier work before later items become available.\n\n## Free and Pro courses\n\nCourse access is determined by the course access tier and the user's current entitlement. Documentation describes the behavior but does not alter access policy.\n\n## Related guides\n\nSee [Code Exercises](/docs/learn-code-exercises), [Terminal Labs](/docs/learn-terminal-labs), [Web Labs](/docs/learn-web-labs), [Progress](/docs/learn-progress) and [Certificates](/docs/learn-certificates)."
  },
  {
    "slug": "learn-code-exercises",
    "title": "Learn Code Exercises",
    "category": "Learn",
    "sortOrder": 20,
    "content": "Code exercises embed a runnable project experience inside an Learnitive lesson.\n\n## Starter code\n\nA course can provide starter source in a supported project mode. Edit the code in the lesson workspace and run it using the same language/runtime behavior as a normal Learnitive project.\n\n## Input and output\n\nCLI exercises can use the Input and Console model when the project mode supports stdin. This is useful for deterministic examples and hidden verification without requiring a live terminal prompt.\n\n## Validation\n\nExercises can compare outputs or run protected checks defined by the course author. Hidden verification details are kept server-side so the exercise cannot reveal its own answer by inspecting lesson data.\n\n## Keep learning work separate\n\nCourse workspaces are instructional environments. Export or move code into a normal project when you want to continue it as a personal project outside the lesson."
  },
  {
    "slug": "learn-terminal-labs",
    "title": "Learn Terminal Labs",
    "category": "Learn",
    "sortOrder": 30,
    "content": "Terminal labs teach Linux and development workflows using the Learnitive terminal rather than a simulated command list.\n\n## Real shell\n\nA terminal lesson can ask you to create files, inspect directories, run commands or use development tools inside the course workspace.\n\n## Protected verification\n\nTerminal Task verification is stored separately from the public lesson block. This lets a lesson validate filesystem and command outcomes without exposing the protected verifier to the learner.\n\n## Example tasks\n\nA lesson might ask you to create a directory, write a file, inspect permissions, run a compiler or use Git. The verifier should check the required outcome rather than depending on one exact sequence of commands.\n\n## Reset\n\nUse the lesson reset/retry workflow when the course allows it. The reset should affect the learning task environment, not unrelated durable projects."
  },
  {
    "slug": "learn-web-labs",
    "title": "Learn Web Labs",
    "category": "Learn",
    "sortOrder": 40,
    "content": "Learnitive Learn web labs combine lesson instructions with real web project files and the same Web Preview used by normal projects.\n\n## Supported project modes\n\nCourses can use static HTML or framework project modes such as Vite, React, Vue or Svelte when those modes fit the lesson.\n\n## Edit and preview\n\nChange the project source, run/build as required, and inspect the result in Web Preview. Build output remains available for debugging when the page does not render.\n\n## Learn the real toolchain\n\nFramework labs can expose normal project manifests and source structure instead of hiding everything behind a one-file sandbox. Use the terminal when the lesson intentionally teaches package scripts or shell commands.\n\n## Verification\n\nA course can pair visible instructions with protected validation so learners still need to produce the required result."
  },
  {
    "slug": "learn-progress",
    "title": "Learn Progress",
    "category": "Learn",
    "sortOrder": 50,
    "content": "Learnitive Learn records signed-in learner progress so courses can show completed work and guide the next item.\n\n## Completion\n\nCompletion rules can differ by item type. A reading lesson, quiz, assignment, code exercise or terminal task can use different completion evidence.\n\n## Sequential learning\n\nCourses can require items to be completed in order. When sequential learning is enabled, later items can remain unavailable until prerequisites are satisfied.\n\n## Attempts\n\nQuizzes, assignments and protected exercises can keep attempt information according to their course settings. Retry behavior is part of the learning design, not a global project permission.\n\n## Durable learning record\n\nProgress belongs to the signed-in course experience and is separate from the temporary runtime container used to execute an exercise."
  },
  {
    "slug": "learn-certificates",
    "title": "Learn Certificates",
    "category": "Learn",
    "sortOrder": 60,
    "content": "Learnitive Learn certificates represent course completion when a published course is configured to issue one and the learner satisfies its completion rules.\n\n## Eligibility\n\nCertificate availability depends on course completion rules and any other requirements configured for that course. Finishing one lesson is not necessarily the same as completing the whole course.\n\n## Private route behavior\n\nCertificate pages are account-specific learning surfaces and are not intended to be indexed as public documentation or marketing pages.\n\n## Verification\n\nKeep the underlying course and progress record as the source of truth. A certificate view should reflect completed course state rather than creating completion by itself."
  },
  {
    "slug": "latex-scientific",
    "title": "LaTeX and Scientific Computing",
    "category": "LaTeX & Scientific",
    "sortOrder": 10,
    "content": "Learnitive keeps LaTeX and scientific computing as first-class workflows inside the broader development platform.\n\n## LaTeX projects\n\nUse ordinary .tex, bibliography and asset files. Source mode preserves exact LaTeX, Visual mode assists with supported document structures, and compile output opens in the integrated PDF workflow.\n\n## Local and cloud compile\n\nLocal Compile keeps the browser-first path. Cloud Compile and the Full TeX Live server path are available when the selected workflow requires server-side TeX tooling. Read the individual compile guides for current behavior.\n\n## Scientific code beside documents\n\nPython, R, C/C++ and other supported languages can live in the same project as research documents. Use the Interactive Terminal for reproducible data processing, generated figures and command-line scientific tooling.\n\n## Reproducibility\n\nKeep analysis scripts, dependency manifests, figure-generation code and manuscript source together when possible. Git or exported project archives make the research object easier to reproduce outside Learnitive.\n\n## Related guides\n\nSee [Compiling LaTeX](/docs/compiling-latex), [PDF and SyncTeX](/docs/pdf-viewer), [Scientific Python](/docs/terminal-python-scientific) and [Research Workflows](/docs/research-workflows)."
  },
  {
    "slug": "source-editor",
    "title": "LaTeX Source Editor",
    "category": "LaTeX & Scientific",
    "sortOrder": 20,
    "content": "Source mode is the exact-text LaTeX editing surface in Learnitive. It is the right place for custom commands, package-specific syntax, complex environments and precise source control.\n\n## Canonical source\n\nLearnitive keeps the .tex file as the canonical document source. Switching to supported Visual tools does not convert the project into a proprietary document format.\n\n## Multi-file projects\n\nUse the normal project tree and open-file tabs for chapters, bibliography files, class files and other project assets. Git and terminal tools can work on the same project structure.\n\n## AI and review\n\nAI suggestions should enter review-aware workflows instead of silently replacing manuscript text. Structural LaTeX contexts can be protected from automatic rewriting.\n\n## Compile\n\nUse Local or Cloud Compile according to project requirements and inspect the compiler log when a build fails."
  },
  {
    "slug": "visual-editor",
    "title": "LaTeX Visual Editor",
    "category": "LaTeX & Scientific",
    "sortOrder": 30,
    "content": "Learnitive provides a LaTeX Visual Editor as a specialized document editing surface alongside the general code editor.\n\n## Supported structures\n\nParagraphs, headings, lists, common formatting, equations, tables and other recognized structures can be projected into editable visual components.\n\n## Protected source\n\nUnsupported or structurally sensitive LaTeX should remain protected rather than being guessed or discarded. Use the route back to Source when you need exact control.\n\n## Figures and assets\n\nCommon project-relative figure assets can be previewed without replacing the underlying LaTeX include command.\n\n## Collaboration and authority\n\nSource remains the canonical representation. Visual tools should not create a second competing document model during collaboration or review."
  },
  {
    "slug": "compiling-latex",
    "title": "Compiling LaTeX",
    "category": "LaTeX & Scientific",
    "sortOrder": 40,
    "content": "Learnitive supports browser-first and server-side LaTeX compilation while keeping the source project portable.\n\n## Local Compile\n\nLocal Compile runs the supported browser TeX path and keeps project files on the browser/local side for that compile workflow. It is the preferred first attempt when the project is compatible with the browser compiler environment.\n\n## Cloud Compile\n\nCloud Compile temporarily sends the files required for a compile job to the isolated server compiler. Use it when you intentionally need the server-side TeX environment or when the browser path cannot satisfy a package, font or engine requirement.\n\n## Full TeX Live reliability path\n\nWhen a local compile fails specifically because of the browser TeX environment, Learnitive can use its isolated Full TeX Live server path where configured.\n\n## Logs\n\nRead the first meaningful TeX error before reacting to cascaded failures. Missing files, packages, fonts and unbalanced structure are common causes.\n\n## Bibliographies\n\nBibTeX/Biber behavior depends on the project and selected compiler path. Keep bibliography files in the project and inspect the compile log when references do not settle."
  },
  {
    "slug": "local-compile",
    "title": "Local Compile",
    "category": "LaTeX & Scientific",
    "sortOrder": 50,
    "content": "Local Compile is the browser-first LaTeX compilation path in Learnitive.\n\n## Why use it\n\nUse Local Compile when the project can be built with the browser compiler profile and you want source/assets to remain on the local/browser side of the workflow.\n\n## Engines and packages\n\nAvailable engines and packages depend on the certified browser TeX environment for the current release. A project that relies on an unavailable package, font or engine can require the server fallback or Cloud Compile.\n\n## Failure handling\n\nOpen the compile log, identify the first meaningful error and confirm that every referenced project asset exists. If the error is specifically an environment limitation, switch to the supported server-side path rather than repeatedly changing correct source.\n\n## PDF output\n\nSuccessful output opens in the integrated PDF workspace and can participate in SyncTeX when the compile path provides the required mapping data."
  },
  {
    "slug": "cloud-compile",
    "title": "Cloud Compile",
    "category": "LaTeX & Scientific",
    "sortOrder": 60,
    "content": "Cloud Compile runs a LaTeX build in the isolated Learnitive server compile environment.\n\n## When to choose it\n\nUse Cloud Compile when you intentionally need server-side TeX tooling, Full TeX Live coverage or a compile capability that the current browser path cannot provide.\n\n## Temporary upload\n\nOnly the project files required for the compile job should be sent to the compiler service. The compile environment is a processing path, not a permanent project-storage replacement.\n\n## Logs and results\n\nCompiler logs remain visible so package, engine, font and bibliography problems are diagnosable. The generated PDF returns to the normal Learnitive PDF workflow.\n\n## Privacy and project ownership\n\nChoose the local browser path when you do not want a project sent to the server compiler. Keep the original source in your durable project storage either way."
  },
  {
    "slug": "live-pdf",
    "title": "Live PDF",
    "category": "LaTeX & Scientific",
    "sortOrder": 70,
    "content": "Live PDF keeps rendered output close to the current LaTeX source without forcing a compile directly into every keystroke.\n\n## Quiet period\n\nLearnitive waits for a short editing quiet period before starting background compile work. Newer edits can supersede obsolete work.\n\n## Compile path\n\nLive PDF follows the project compile preference, including the current local/server fallback behavior where applicable.\n\n## Manual compile\n\nUse manual Compile when you want an immediate explicit build instead of waiting for the Live PDF debounce.\n\n## Status\n\nTreat the exact compiled PDF and log as authoritative. The interface should distinguish current output, compiling state and failed output."
  },
  {
    "slug": "pdf-viewer",
    "title": "PDF and SyncTeX",
    "category": "LaTeX & Scientific",
    "sortOrder": 80,
    "content": "Learnitive connects LaTeX compilation with an integrated PDF viewer and SyncTeX-oriented source navigation.\n\n## Preview\n\nOpen the generated PDF without leaving the project. Text selection and search depend on the structure of the generated PDF.\n\n## Source to PDF\n\nSource-to-PDF navigation reveals the corresponding rendered location when the selected compiler produced usable SyncTeX information.\n\n## PDF to Source\n\nReverse SyncTeX is an explicit navigation action back to the mapped source location. It should not silently rewrite manuscript text.\n\n## Exact output\n\nUse the exact compiled PDF as the final authority for layout. Live or optimistic preview behavior should eventually reconcile with the compile result."
  },
  {
    "slug": "pdf-export",
    "title": "PDF Preview and Export",
    "category": "LaTeX & Scientific",
    "sortOrder": 90,
    "content": "Learnitive separates PDF compilation/preview from export policy.\n\n## Preview\n\nSupported users can compile and inspect PDF output inside the project according to the current LaTeX feature policy.\n\n## Export policy\n\nFree and Pro export behavior is controlled by the current account entitlement. Export policy operates on the generated artifact rather than injecting hidden commands into the .tex source.\n\n## Keep source unchanged\n\nYour project source remains ordinary LaTeX regardless of how a generated PDF is exported. This keeps the project portable to other TeX environments.\n\n## Before submission\n\nCompile from the intended source revision, inspect the PDF, resolve important warnings and then export the artifact you plan to submit or share."
  },
  {
    "slug": "math-equations",
    "title": "Math and Equations",
    "category": "LaTeX & Scientific",
    "sortOrder": 100,
    "content": "Learnitive preserves mathematical expressions as LaTeX source while providing equation-aware assistance where supported.\n\n## Source math\n\nInline math, display math and equation environments remain ordinary LaTeX. Source mode is the authority for custom macros and package-specific notation.\n\n## Visual math\n\nSupported math regions can use the equation editing experience. The resulting edit maps back to the corresponding canonical source region.\n\n## Unsupported syntax\n\nWhen an expression cannot be represented safely in the visual tool, keep it source-backed rather than rewriting it into a different formula.\n\n## Compile to verify\n\nThe TeX compiler remains the final authority for whether the mathematical source is valid and how it renders."
  },
  {
    "slug": "figures-and-tables",
    "title": "Figures and Tables",
    "category": "LaTeX & Scientific",
    "sortOrder": 110,
    "content": "Learnitive LaTeX projects keep figures, tables and their source definitions inside ordinary project files.\n\n## Figures\n\nKeep images in the project and use project-relative paths. Common PNG, JPEG and PDF assets can be previewed where supported while the underlying include command remains source-backed.\n\n## Tables\n\nSupported tabular structures can be edited visually. Complex package-specific tables should remain protected until you edit them in Source.\n\n## Labels and references\n\nKeep captions, labels and references semantic so numbering can update when the document changes.\n\n## Reproducible figures\n\nWhen figures are generated from code, keep the generation script and dependencies with the project so the output can be rebuilt."
  },
  {
    "slug": "research-workflows",
    "title": "Research Workflows",
    "category": "Research",
    "sortOrder": 10,
    "content": "Learnitive combines research writing with normal project files, scientific code, evidence tools and LaTeX rather than separating manuscript and computation into unrelated systems.\n\n## Keep evidence and source together\n\nUse project folders for manuscript source, bibliography, figures, analysis scripts and supporting notes. Git or exported archives make the research object easier to reproduce.\n\n## Paper Memory\n\nPaper Memory retrieves from papers you explicitly add. Keep retrieved evidence distinguishable from AI-generated summaries and verify important claims against the source.\n\n## Scientific terminal work\n\nUse Python, R, C/C++ and other supported tools in the Interactive Terminal for analysis and figure generation. Reproducible scripts are safer than depending on one runtime session.\n\n## AI assistance\n\nAI Review and Deep Research can help structure questions and inspect evidence, but they do not make generated prose a verified citation."
  },
  {
    "slug": "citations-and-bibliography",
    "title": "Citations and Bibliography",
    "category": "Research",
    "sortOrder": 20,
    "content": "Learnitive keeps citations tied to ordinary bibliography files and LaTeX citation commands.\n\n## Bibliography files\n\nStore .bib files with the project and use the bibliography package expected by the document. Keep citation keys stable and readable.\n\n## Search and import\n\nWhen scholarly metadata is retrieved, inspect title, authors, venue, year and identifier before adding it to the bibliography. A retrieved record is not automatically correct because an AI workflow found it.\n\n## Missing keys\n\nUse project-aware analysis to detect citation keys that do not exist in known bibliography files. Do not fabricate a replacement key.\n\n## Compile\n\nBibTeX or Biber availability depends on the selected compile workflow and project configuration. Compiler logs remain the source of truth for bibliography errors."
  },
  {
    "slug": "deep-research",
    "title": "Deep Research",
    "category": "Research",
    "sortOrder": 30,
    "content": "Learnitive Deep Research is a research-oriented workflow for collecting and organizing evidence before you turn it into manuscript changes.\n\n## Plan the question\n\nStart with a bounded research question. A narrower question produces a more inspectable evidence trail and reduces irrelevant retrieval.\n\n## Retrieve evidence\n\nKeep real retrieved sources and metadata separate from generated reasoning. Missing or unavailable evidence should be reported as unavailable rather than invented.\n\n## Verify separately\n\nA verification stage should challenge unsupported, inconsistent or weakly sourced claims from the first synthesis.\n\n## Apply to the project deliberately\n\nResearch output does not automatically become manuscript source. Use citation and review workflows to decide what belongs in the project."
  },
  {
    "slug": "plans-and-features",
    "title": "Plans and Features",
    "category": "Account & Plans",
    "sortOrder": 10,
    "content": "Learnitive has Free and Pro plans. The public pricing page is the current marketing summary; runtime and feature enforcement are controlled by the application's entitlement policies.\n\n## Free\n\nFree is intended for getting started with a limited number of projects, browser IDE/terminal workflows, Git, templates and free learning content. Runtime persistence, networking and other limits follow the current Free policy.\n\n## Pro\n\nPro plans expand project limits and provide the current Pro feature set, including persistent terminal workspaces, public Internet access, Interactive AI, Ollama/BYOK workflows, scientific/LaTeX capabilities, AI Web App Builder with shell access, collaboration, Pro courses and priority support as advertised on the pricing page.\n\n## Marketing copy versus enforcement\n\nDocumentation and pricing copy do not grant a feature by themselves. The authoritative enforcement path is the current account entitlement and runtime policy in the application.\n\n## Runtime limits\n\nEnvironment lifetime, storage, concurrency and network policy can be separately controlled from the broad plan name. Reproducible projects should not depend on one temporary environment remaining alive indefinitely.\n\n## Learn access\n\nCourse access is controlled by each course's access tier together with the account entitlement.\n\n## Check the latest pricing\n\nSee [Pricing](/pricing) for the current plan presentation."
  },
  {
    "slug": "authentication-and-account",
    "title": "Authentication and Account",
    "category": "Account & Plans",
    "sortOrder": 20,
    "content": "Learnitive uses authenticated accounts for account features such as collaboration authorization, learning progress, plan entitlements and authenticated runtime services. Local project storage, Projects Folder synchronization and recovery do not require an account.\n\n## Sign in\n\nUse the currently available Google, GitHub or secure email sign-in path when an account feature asks for authentication. Authentication returns you to an allowed Learnitive route after the identity flow completes.\n\n## Local projects\n\nNormal Browser projects are not registered as account project inventory. You can create projects, connect a Projects Folder and recover from that folder without signing in.\n\n## Collaboration\n\nJoining an invited collaboration requires a signed-in Learnitive account and the authorization required by that online feature. A share link does not bypass collaboration permissions.\n\n## Terminal\n\nAuthenticated terminal environments are governed by the current plan/runtime policy. Project storage remains local even when an online runtime asks you to sign in.\n\n## AI credentials\n\nDo not store BYOK provider keys in project source. Use the AI settings workflow designed for credentials.\n\n## Sign out and shared devices\n\nSigning out does not define local project ownership. On shared devices, disconnect any Projects Folder and clear browser-stored project or provider information when appropriate to your privacy needs."
  },
  {
    "slug": "troubleshooting",
    "title": "Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 10,
    "content": "Start troubleshooting Learnitive by identifying which layer failed: project source, one-click runtime, terminal environment, preview, AI provider, Git or LaTeX compiler.\n\n## Project will not run\n\nCheck the selected project mode, entry file, Input, Console and first build/runtime error. Continue with [Build and Run Troubleshooting](/docs/troubleshooting-project-run).\n\n## Terminal will not start\n\nCheck authentication, runtime status and whether the environment is being created or recovered. Continue with [Terminal Troubleshooting](/docs/troubleshooting-terminal).\n\n## Web preview is blank\n\nRead framework/build output, confirm the expected entry file and restart the development process when configuration changed.\n\n## Ollama is not detected\n\nConfirm the local service is running, OLLAMA_ORIGINS is correct and at least one model is installed. See [Ollama Troubleshooting](/docs/troubleshooting-ollama).\n\n## LaTeX compile failed\n\nRead the first meaningful compiler error before addressing later cascades. See [LaTeX Troubleshooting](/docs/troubleshooting-latex).\n\n## Git failed\n\nCheck repository state, remote URL, credentials and branch expectations. See [Git Troubleshooting](/docs/troubleshooting-git)."
  },
  {
    "slug": "troubleshooting-project-run",
    "title": "Build and Run Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 20,
    "content": "Use this checklist when project files, Projects Folder synchronization, ZIP import or terminal changes do not look current.\n\n## Identify the working copy\n\nNormal projects always work from Browser storage. The optional Projects Folder is a synchronized filesystem replica, while the Linux terminal uses a separate runtime working tree.\n\n## Projects Folder access\n\nIf Storage shows **Access required**, use **Projects → Storage → Grant access**. Browser projects continue working while access is unavailable.\n\n## Recover after clearing browser data\n\nOpen **Projects** and choose **Recover Projects Folder** (or **Projects → Storage → Local Folder**), then select the previously used Projects Folder. No login is required. Learnitive scans project manifests and rebuilds Browser workspaces. Do not create empty replacement projects with the same names.\n\n## External edits and conflicts\n\nUse **Sync now** after substantial filesystem edits. If the same file changed in Browser and on disk, review the conflict and choose which copy to keep or preserve both.\n\n## Terminal synchronization\n\nRuntime files are separate from Browser/Projects Folder storage. Use Terminal Sync deliberately to send project files into the runtime and bring intended runtime changes back. Authentication may be required by the runtime itself, not by local project storage.\n\n## Related guides\n\nRead [Project Storage and Recovery](/docs/project-storage), [Projects Folder](/docs/linked-local-folders), [ZIP Import and Export](/docs/zip-import-export) and [Terminal Sync](/docs/sync-terminal-projects)."
  },
  {
    "slug": "troubleshooting-terminal",
    "title": "Terminal Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 30,
    "content": "Use this Learnitive checklist when the standalone or project terminal will not start, disconnects or has an unexpected workspace state.\n\n## Check account state\n\nAuthenticated terminal access depends on the current session and runtime policy. Refresh authentication if the browser session expired.\n\n## Environment creation\n\nA new or reconstructed environment can take longer than opening an additional PTY in an already healthy container. Distinguish startup from a dead connection.\n\n## Session versus environment\n\nClosing one terminal does not necessarily destroy the environment. Conversely, destroying or expiring the environment removes temporary processes and manually installed packages.\n\n## Project files\n\nIf the environment was rebuilt, confirm the project materialized into the expected working tree and synchronize durable source as needed.\n\n## Network-dependent commands\n\nA command can fail because runtime networking is restricted even when the command itself is installed."
  },
  {
    "slug": "troubleshooting-ollama",
    "title": "Ollama Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 40,
    "content": "Use this guide when Learnitive cannot discover Ollama or a selected model cannot be used through the local path.\n\n## Service running\n\nStart Ollama and confirm `ollama list` works on the same computer as the browser.\n\n## Browser origin\n\nSet the Ollama origin configuration to allow https://www.learnitive.com and restart Ollama after changing it.\n\n## Model availability\n\nDownload at least one local model. Refresh Ollama in Learnitive after adding or removing models.\n\n## Local verification\n\nA localhost model can still be cloud-backed. Learnitive can reject a model from the verified-local path when it cannot confirm genuinely local inference.\n\n## Browser restrictions\n\nBrowser local-network/loopback security controls can block access even when the service is healthy. Check browser permissions and developer-network errors.\n\n## Reinstall\n\nIf Ollama itself is missing or damaged, use the official [Download Ollama](https://ollama.com/download) page."
  },
  {
    "slug": "troubleshooting-latex",
    "title": "LaTeX Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 50,
    "content": "Use this Learnitive checklist when a LaTeX build fails or the PDF does not match the source you expected.\n\n## Missing file or package\n\nConfirm project-relative assets exist and the selected compiler environment contains the required package/font. Switch compile paths only when the source is correct and the environment is the actual limitation.\n\n## Unbalanced structure\n\nCheck recently edited braces, begin/end pairs and package-specific environments near the first error.\n\n## Bibliography\n\nConfirm the .bib file, citation key, bibliography package and expected BibTeX/Biber workflow.\n\n## Minimal reproduction\n\nTemporarily isolate the failing section or create a smaller root document when the cause is unclear. Restore content incrementally after the minimal case compiles.\n\n## Compare compile paths\n\nIf Local Compile fails because of a browser TeX limitation, try the supported server-side compile path and compare logs."
  },
  {
    "slug": "troubleshooting-git",
    "title": "Git Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 60,
    "content": "Use this Learnitive checklist when clone, fetch, pull, push or another Git operation fails.\n\n## Inspect state\n\nRun `git status`, inspect the current branch and confirm the working tree you are changing is the intended project.\n\n## Remote\n\nUse `git remote -v` to verify the repository target before pushing credentials or commits to the wrong remote.\n\n## Authentication\n\nUse the current GitHub/Git provider authentication method for your account. Do not commit tokens, private keys or passwords into project files.\n\n## Diverged history\n\nInspect incoming and local commits before forcing history changes. Pull/rebase/merge decisions should be intentional.\n\n## Runtime durability\n\nPush important commits or synchronize them back before destroying an environment. The temporary sandbox is not durable Git hosting."
  },
  {
    "slug": "troubleshooting-web-preview",
    "title": "Web Preview Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 70,
    "content": "Use this Learnitive checklist when Web Preview is blank, stale or reports that the build/runtime is unavailable.\n\n## Check the project mode\n\nConfirm the project is a web-capable mode. Console-oriented CLI languages use Console/Input instead of Web Preview, while LaTeX uses PDF Preview.\n\n## Read the build result\n\nIf Learnitive says Web Preview is unavailable until the build succeeds, inspect the build error first. Fix syntax, missing dependencies or configuration before debugging the browser page.\n\n## Confirm the development process\n\nFor projects that require a running dev server, verify the process is still alive in the terminal/runtime. A closed terminal PTY or destroyed environment can stop the server.\n\n## Check client-side errors\n\nA successful HTTP response can still render a blank application because of a JavaScript exception. Read the preview/runtime error surface and application console output.\n\n## Refresh after configuration changes\n\nAfter changing framework config, dependencies or entry points, rebuild/restart the development process rather than relying on stale hot-reload state.\n\n## Keep deployment separate\n\nLearnitive Web Preview is for development verification. A preview problem is not the same as a public hosting/deployment problem.\n\n## Related guides\n\nSee [Web Preview](/docs/web-preview), [Processes Ports and Web Preview](/docs/processes-and-ports) and [Reading Build and Runtime Errors](/docs/build-errors)."
  },
  {
    "slug": "troubleshooting-files",
    "title": "Project File and Sync Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 80,
    "content": "Use this guide when the file tree, Projects Folder or runtime copy does not look current.\n\n## Identify the working copy\n\nEvery normal project works from Browser storage. An optional global Projects Folder mirrors all projects. The Linux runtime is a separate temporary server working tree used only when an authenticated compute feature is invoked.\n\n## Browser project missing after site-data cleanup\n\nChoose **Recover Projects Folder** or **Projects → Storage → Local Folder**, then select the previously used directory. No login is required. Learnitive scans child **.learnitive/project.json** manifests and rebuilds Browser workspaces.\n\n## Projects Folder needs permission\n\nIf Storage shows **Access required**, choose **Grant access**. Learnitive never requests filesystem permission in the background. Browser saves remain available while synchronization is paused.\n\n## External edits\n\nIf you changed a synchronized file in another editor, return to Learnitive or choose **Sync now**. Local-only changes are reconciled into Browser storage. Same-file changes on both sides are surfaced as conflicts.\n\n## Deleted while disconnected\n\nIf you delete a Browser project while the Projects Folder is disconnected, an older local backup can still exist. A later recovery may offer that project again because there is intentionally no cloud deletion journal. Reconnect before deletion when you want the folder copy tombstoned too.\n\n## Related guides\n\nRead [Project Storage and Recovery](/docs/project-storage), [Projects Folder](/docs/linked-local-folders), [ZIP Import and Export](/docs/zip-import-export) and [Terminal Sync](/docs/sync-terminal-projects)."
  },
  {
    "slug": "troubleshooting-ai",
    "title": "AI and Agent Troubleshooting",
    "category": "Troubleshooting",
    "sortOrder": 90,
    "content": "Use this Learnitive checklist when AI Assistant, AI Agent, AI Web App Builder, BYOK or local-model workflows are unavailable or return an error.\n\n## Identify the provider path\n\nOpen AI Settings and confirm whether the workflow is using browser Local AI, Ollama or a BYOK cloud provider. The troubleshooting steps differ: a local model may need downloaded assets, Ollama needs its localhost service, and BYOK needs a valid provider credential/network path.\n\n## Check privacy mode\n\nPrivacy Mode can intentionally block cloud-backed context. If a workflow requires cloud context and Privacy Mode is enabled, switch to an allowed local path or explicitly change the privacy/provider configuration rather than treating the block as a model failure.\n\n## Agent readiness\n\nAI Web App Builder and project Agent workflows require an Agent-capable setup. If Build with AI opens settings or says setup is incomplete, finish the supported provider/model configuration first.\n\n## Use project evidence\n\nFor coding failures, give the AI the relevant file/error rather than repeatedly asking the same generic question. Agent works best with a bounded objective and a verification command.\n\n## Protect secrets\n\nNever solve an authentication error by committing an API key into project source. Keep BYOK credentials in the AI settings path and repository credentials in the Git workflow.\n\n## Ollama-specific issues\n\nFor local Ollama detection, continue with [Ollama Troubleshooting](/docs/troubleshooting-ollama). For provider concepts, see [AI in Learnitive](/docs/ai-overview) and [BYOK AI Providers](/docs/byok-ai)."
  }
]