LocalEndpoint Agent Package and Memory Management: Architectural and UX Design Specifications

Full report

On this page

The transition toward decentralized, locally executed artificial intelligence necessitates a fundamental reimagining of how users interact with agentic software. Unlike cloud-based systems that obfuscate data storage and state management behind proprietary APIs, local execution environments like LocalEndpoint Connect empower users with direct control over their agents' cognitive and historical assets. This paradigm shift requires a user experience that bridges the gap between complex file system architectures and intuitive consumer software. LocalEndpoint Connect operates as the primary execution environment for portable AI agents, loading standardized .uaix packages and managing their underlying persistence layers. As the desktop application scales to support concurrent instances, cross-platform portability, and interchangeable agent packages, the user experience must elegantly handle package administration, strict dependency declarations, and durable memory structures. This comprehensive report provides an exhaustive architectural and user experience specification for LocalEndpoint's package and memory management ecosystem. It establishes definitive plain-language taxonomies for core components, outlines the critical graphical interfaces required for package and memory orchestration, and defines the syntactical frameworks necessary for dependency communication. Furthermore, this analysis addresses the systemic risks inherent in multi-instance desktop applications, proposing sophisticated data resilience mechanisms—including atomic file operations, concurrent lock management, and visual conflict resolution—to ensure that hardware failures or asynchronous cloud syncing processes do not result in the catastrophic loss of agent configurations or accumulated knowledge.

Foundational Taxonomies and Plain-Language Definitions

To design an effective and frictionless user interface, the underlying technical components of the LocalEndpoint architecture must be translated into conceptual models that end-users can readily comprehend. Whether the user is a casual consumer experimenting with local AI or an enterprise developer deploying custom workflows, the cognitive load required to understand file types and memory structures must be minimized. The following plain-language definitions serve as the semantic foundation for all in-app typography, instructional tooltips, and official documentation.

The .uaix Package Paradigm

A .uaix package serves as the standardized, portable container for a local AI agent, functioning much like a software installer or a self-contained execution cartridge. In plain language, the .uaix package can be conceptualized as the physical brain structure and immutable rulebook of the AI assistant. Just as a .zip archive holds a directory of compressed files or a container image bundles an application and its dependencies, a .uaix package encapsulates everything an agent requires to operate securely and predictably within the LocalEndpoint ecosystem1. The .uaix architecture relies on a declarative-first approach, meaning the agent's capabilities are described in machine-readable manifests rather than opaque code1. This package contains the agent's core operational instructions, its predefined behavioral constraints, and its required configuration files, which are designated by the .uai file extension as defined by UAIX.org3. Because the package is entirely self-contained, a user can download a .uaix file from an internal repository or external marketplace, load it into the LocalEndpoint desktop application, and immediately initialize the agent without executing manual environment setups or resolving external dependencies. The package dictates what the agent is capable of doing, but it does not inherently contain the user's personal data or historical interactions.

The .uai File Memory Architecture

While the .uaix package provides the overarching structure, .uai file memory represents the specialized, localized configuration and transient state files contained within or actively utilized by the loaded package. In plain language, if the .uaix package constitutes the agent's physical brain structure, the .uai files function as its specific short-term working memory, situational personality traits, and immediate task parameters5. These files govern how the agent operates in the present moment, holding critical operational context, parameters for project handoffs between different agents, and specific behavioral preferences tailored to the current user or session5. They are the structural components that inform the agent of its current identity and its immediate operational objectives. .uai files are distinct from the broader repository of historical facts; they are highly structured, often JSON- or YAML-formatted documents that act as the connective tissue between the static .uaix package and the dynamic execution environment of the LocalEndpoint desktop application. The manipulation or absence of specific .uai files directly alters the agent's immediate capabilities and interaction style.

The Wiki Memory Framework

Wiki memory constitutes the agent's long-term, durable knowledge vault, structured similarly to a human-readable digital encyclopedia rather than a chronological chat log7. In plain language, while .uai files act as the agent's short-term working memory and configuration, wiki memory acts as its permanent, highly organized filing cabinet. Traditional conversational agents suffer from context degradation because they rely on linear chat histories. In contrast, wiki memory organizes synthesized information into distinct directories and interconnected Markdown pages7. A standard wiki memory vault might contain directories such as entities/ for tracking facts about people and places, concepts/ for storing abstract ideas and architectural patterns, and reports/ for maintaining compiled dashboards of ongoing projects7. This structured approach allows the agent to recall specific facts efficiently, maintain strict provenance regarding where and when it learned a piece of information, and safely accumulate knowledge over extended periods without degrading performance or exceeding context windows8. Crucially, wiki memory resides in standard directories on the user's local file system—defaulting to standard Documents folders—allowing users to read, edit, and back up the agent's knowledge using standard operating system utilities and text editors.

Package and Memory Management User Experience

The LocalEndpoint desktop application must orchestrate a complex ecosystem where users can seamlessly switch between various .uaix packages and run multiple agent instances concurrently. To facilitate this orchestration without inducing user fatigue or confusion, the package management experience requires a unified interface divided into highly focused operational views. The user experience must visually separate the management of the agent's execution logic (the package) from the management of its historical knowledge (the memory).

The LocalEndpoint Hub

The Hub serves as the primary dashboard and operational launchpad for the desktop application. It provides a comprehensive visual roster of all installed .uaix packages and currently running agent instances. The interface is organized into an active instances grid and a package library. The active instances grid displays running agents as interactive cards, detailing the agent's assigned name, its current operational status, and a clear visual indicator of the specific wiki memory vault it is currently accessing. The primary action architecture within the Hub allows users to click a prominent deployment button to load a new .uaix package via a native operating system file picker, or to initialize a new instance from a previously imported package residing in the library. To provide immediate systemic feedback, the Hub incorporates real-time status badges on each active instance card, indicating whether the agent is idle, processing a request, or actively writing to its wiki memory vault. This transparency is critical in multi-agent environments, allowing users to monitor concurrent processes effortlessly12.

The Package Inspector

When a user selects a specific .uaix package from the library, the interface transitions to the Package Inspector. This screen parses the package contents and presents a detailed, human-readable manifest of the agent's capabilities and constraints. The inspector is vital for establishing user trust before an agent is executed1. The upper section of the inspector details the package's identity, origin, versioning, and cryptographic integrity status. It visually confirms whether the package signature is valid and displays any behavioral trust scores associated with the manifest1. The central component of the inspector is the dependency tree, which parses all .uai files embedded within the package and explicitly displays their requirements using the strict nomenclatures defined in subsequent sections of this report. Finally, the inspector features a rigid capabilities boundary—a read-only declaration that explicitly states what the package can and cannot execute, reinforcing the safety policies that the local environment enforces upon the agent1.

The Memory Vault Manager

The Memory Vault Manager is dedicated to decoupling the agent's execution logic from its accumulated data. Because wiki memory is durable and persistent, users must be able to manage these knowledge bases independently of the agents that utilize them. The interface utilizes a split-pane layout, where the primary navigation pane lists all detected wiki memory directories, defaulting to those located within the system's Documents folder hierarchy. Selecting a specific vault populates the details pane with comprehensive statistics, including the total storage footprint, the number of indexed concepts and entities, the date of the last structural modification, and the current health status of the vault's internal linkages7. The most critical feature of this screen is the assignment matrix, which allows users to dynamically bind or unbind running agent instances to specific memory vaults. This interface empowers users to rapidly reassign agents to different knowledge bases, facilitating workflows where different specialized agents can sequentially process the same dataset.

Dependency Declarations and Requirement Mapping

A fundamental constraint of the LocalEndpoint user experience is the strict prohibition of the term "optional" when describing .uai file dependencies. In software design, designating a component as optional frequently leads to user ambivalence and configuration errors, as users struggle to determine whether the absence of the file will degrade their experience. To maintain absolute clarity regarding the utility and operational purpose of every file within the .uaix ecosystem, the user interface must frame every .uai component as a definitive prerequisite for a specific, tangible capability. This establishes a clear and actionable mental model: files are not superfluous additions; they are the strict enablers of discrete functionalities.

Enforcing the persona.uai Requirement

The persona.uai file is the architectural keystone of the .uaix package. It contains the foundational identity, tonal guidelines, and overarching operational constraints that govern the agent's behavior6. It is the most critical file in the entire framework, as it prevents the agent from experiencing severe hallucination or context collapse upon initialization. Within the Package Inspector interface, the persona.uai dependency must be pinned to the apex of the file manifest. It must be explicitly labeled with a prominent, non-dismissible visual badge utilizing the exact required phrasing: "Required For All LocalEndpoint Desktop Packages." The user interface must treat the absence or corruption of this file as a fatal execution error. If a user attempts to launch a .uaix package that is missing a valid persona.uai file, the application must immediately halt the initialization sequence and present a blocking modal stating that the file is Required For All LocalEndpoint Desktop Packages, prompting the user to either repair the package or abort the deployment.

Mapping Secondary .uai File Types

All other .uai files must adhere to the "Required For {x}" nomenclature. This phrasing maps the file directly to a user-centric feature or systemic capability, educating the user on the file's exact purpose while simultaneously enforcing the strict architectural vocabulary of the LocalEndpoint ecosystem. By structuring the user interface around this nomenclature, users are never left wondering if a file is safe to delete or ignore. If a user determines they do not require external API integrations, they inherently understand that the absence of the file required for that capability is an acceptable and safe state for their specific use case.

Wiki Memory Architecture and Topological Configuration

The architectural design of the wiki memory experience must carefully balance the need for data isolation—preventing specialized agents from corrupting each other's knowledge bases—with the need for interoperability—allowing multiple agents to collaborate seamlessly on a shared repository of facts. The user interface must guide users through the implications of their memory topology choices without requiring advanced database administration knowledge.

Navigating Shared Versus Separate Wiki Memory

When a user initiates the launch sequence for a .uaix package via the LocalEndpoint Hub, the application presents a mandatory memory assignment dialogue. This interface forces a conscious, explicit choice between connecting the agent to a shared global repository or isolating it within a separate knowledge silo. Selecting a shared wiki memory root connects the agent to the default global knowledge vault. The user interface explicitly informs the user that choosing this option allows the newly launched agent to read from and write to the same central repository utilized by their other global agents. This topology is optimal for building a unified, compounding personal knowledge base where an agent specialized in research can write a report to the wiki, and an agent specialized in formatting can subsequently read and refine that same report12. Mechanically, the application points the agent instance to the default root directory established by the system. Conversely, selecting a separate wiki memory root creates an isolated data environment. The user interface describes this option as restricting the agent to a private memory silo, ensuring that it cannot access the user's global facts, and preventing global agents from accessing its specialized data. This configuration is critical for enterprise use cases involving sensitive client data or compartmentalized projects where cross-contamination of knowledge is unacceptable. Mechanically, the application invokes a standard directory picker, defaulting to the creation of a new, distinctly named folder isolated from the global root.

Operating System Integration and the Documents Directory

A paramount architectural directive for the LocalEndpoint application is that wiki memory must default to the user's standard OS-level document directories. For example, the default path should map to standard user profiles on Windows or macOS, placing the Markdown-based wiki files directly within the standard file system hierarchy. This is a critical design decision centered entirely around passive user protection and data sovereignty. By default, the vast majority of operating system-level backup utilities, such as Apple Time Machine or Windows File History, alongside ubiquitous cloud synchronization clients like OneDrive, iCloud Drive, and Dropbox, are pre-configured to monitor and protect the standard documents directory. By locating the agent's wiki memory within these default paths, LocalEndpoint ensures that the user's existing, normalized backup tools seamlessly protect the agent's accumulating knowledge7. The user is not required to learn a proprietary backup system, export database dumps, or configure complex storage volumes. The agent's knowledge simply becomes a transparent, highly legible part of the user's standard document ecosystem, entirely readable through basic text editors even if the LocalEndpoint application is uninstalled7.

Portability, Migration, and Backup Workflows

Because artificial intelligence agents represent a significant investment of user time and interaction, their underlying memories compound in value the longer they are utilized8. The destruction or loss of an agent's memory is akin to losing a highly trained employee. Therefore, the user experience must ensure that migrating and backing up agents is entirely frictionless, leveraging standard file formats rather than proprietary archiving mechanisms.

Migrating .uaix Packages and Wiki Memory Across Hardware

To effectively move an agent to a new hardware environment, the user must transport both the execution logic contained within the package and the historical state contained within the memory vault. The user interface facilitates this via a dedicated migration wizard located within the Dashboard. When a user initiates a migration, the interface presents a clear, binary checklist asking the user to confirm the inclusion of both the .uaix agent package, which is required for agent portability, and the associated wiki memory directory, which is required for retaining historical knowledge. Upon confirmation, the application does not generate an encrypted or proprietary backup file. Instead, it aggregates the .uaix file and a direct copy of the associated wiki memory directory into a standard, universally accessible .zip archive. The rehydration process on the target hardware is designed for absolute simplicity. The user drags the exported archive into the LocalEndpoint Hub on the new machine. The application automatically unpacks the .uaix package into the local library, extracts the wiki memory directory into the local documents folder, and seamlessly restablishes the binding between the package and the memory vault, allowing the agent to resume operations exactly where it left off.

Active and Passive Backup Methodologies

Because the .uaix packages are inherently static—remaining unchanged unless explicitly updated by the developer or user—and the wiki memory is dynamically backed to the standard documents folder, the backup strategy relies primarily on passive system processes. The user experience includes a continuous backup status indicator within the Memory Vault Manager. This indicator relies on basic operating system hooks to determine if the wiki memory folder is currently located within a known synchronization path, such as detecting the presence of Dropbox or OneDrive daemon processes monitoring the directory. If passive protection is detected, the interface displays a reassuring visual confirmation that the memory is safely integrated into the system's sync routine. For users operating in air-gapped environments or without active cloud synchronization, the user interface provides a manual snapshot mechanism. Activating this feature triggers a localized, chronological backup routine that creates a compressed archive of the current state of the wiki folder. These snapshots are appended with precise timestamps and stored in a dedicated local subfolder, providing a reliable rollback mechanism in the event of catastrophic data corruption or unintended agent hallucination resulting in mass deletion of wiki pages.

Systemic Resilience and Conflict Resolution

The most severe architectural risk in a local, multi-instance desktop application managing flat files is the potential for catastrophic data corruption. If two concurrent instances of the LocalEndpoint application attempt to write to the same Markdown file simultaneously, or if the host computer experiences a sudden power loss mid-write, the file can become irrecoverably corrupted or truncated to zero bytes15. Furthermore, if users rely on asynchronous cloud synchronization tools to back up their wiki memory across multiple devices, latency will inevitably create conflicted copies of files18. The user experience must actively mitigate these edge cases through invisible system architecture and highly visible conflict resolution interfaces.

Implementing the Atomic File Swap Pattern

Standard operating systems do not natively guarantee atomic writes for basic file input/output operations20. If an application crashes while updating a memory file, the data is frequently destroyed. To prevent this, LocalEndpoint must implement the atomic file swap pattern at the deepest level of its storage architecture15. When an agent initiates an update to a wiki page, the system must never permit a direct write to the target file. Instead, the application must create a temporary file within the same directory. The entire new state of the memory page is written exclusively to this temporary file. Following the write operation, the application must flush its internal buffers and issue a strict operating system-level synchronization command—such as fsync on POSIX systems—to absolutely guarantee that the data has been physically committed to the storage drive15. Only after this confirmation does the application perform an atomic rename operation—utilizing rename() on POSIX or MoveFileEx on Windows—to instantaneously swap the temporary file over the original file16. While this mechanical process is invisible to the user, it represents a foundational requirement for data safety. The user interface must gracefully handle the inevitable edge cases where an atomic swap fails, such as when an aggressive antivirus scanner temporarily locks the target file. In such instances, rather than failing silently or crashing, the user interface must surface a non-intrusive notification indicating that a memory update has been temporarily delayed due to file locking, and the system is automatically retrying the operation in the background.

Managing Multi-Instance Concurrency and Lockfiles

When multiple running agent instances are configured to share the same global wiki memory root, the system requires a robust mechanism to prevent race conditions and concurrent write collisions22. If an agent tasked with researching a topic and an agent tasked with summarizing that topic attempt to modify the same concept file simultaneously, the resulting data will be unpredictable9. LocalEndpoint must utilize a strict lockfile pattern, or leverage SQLite reader/writer locks if a localized indexing database is utilized alongside the raw Markdown files23. Before an instance is permitted to write to a wiki page, it must successfully check for the absence of a .lock file or acquire a shared system mutex. If a secondary instance attempts to execute a write operation on a file that is currently locked, the user experience must manage the delay gracefully. The application must queue the write operation in the background and display a subtle synchronization spinner on the corresponding agent's card within the Hub. If the lock persists beyond a reasonable timeout threshold, the user interface must display an intervention prompt, clearly communicating which specific agent instance is currently holding the memory resources and preventing the operation from completing.

The Conflict Resolution Center

When users leverage cloud synchronization drives to back up their standard document folders, modifying a memory file while offline or running agents on two different computers simultaneously will inevitably result in synchronization collisions. Cloud clients typically resolve this by duplicating the file and appending a conflicted copy warning to the filename18. Left unaddressed by the application, these duplicated files will rapidly bloat the memory vault, and the agent's semantic search algorithms will begin pulling fragmented, contradictory data from the unresolved duplicates. To solve this, LocalEndpoint must feature a dedicated Conflict Resolution Center within its advanced settings interface18. The application must passively scan the wiki memory directories for standard conflict nomenclature patterns utilized by major cloud providers. When a conflict is detected, a prominent alert badge must appear on the Memory Vault Manager interface. Activating the alert opens a sophisticated three-way visual diff interface specifically tailored for Markdown content27. This interface displays the base version of the file prior to the divergence, alongside the local version and the remote conflicted version27. Users are presented with intuitive controls to resolve each conflicting section of the document, choosing to keep their local changes, accept the remote changes, or manually merge the text28. Without this dedicated user experience, users would be forced to manually sift through raw text files in their operating system's file explorer, entirely defeating the purpose of a cohesive, managed agent ecosystem.

Safety Boundaries and Systemic Constraint Validation

LocalEndpoint operates on the foundational premise that agents are confined execution environments. The memory layer—encompassing both .uai configuration files and the expansive wiki memory vault—must never serve as a vector for privilege escalation or sandbox escape. It is a strict systemic rule that .uaix packages or .uai memory cannot, by themselves, grant an agent access to provider APIs, local network traversal, arbitrary command execution, application telemetry, or the ability to override predefined safety policies. To communicate this absolute constraint to the user and enforce it at the application level, the user experience relies on explicit, non-bypassable validation checklists presented during critical operations.

Enforcing Portability Integrity

When a user attempts to export, package, or migrate an agent for sharing or deployment, the system must aggressively validate the structural integrity of the components to ensure that a broken or malicious package is not propagated. The user interface presents the following rigorous validation table before generating any export archive.

If any single validation requirement fails, the user interface completely prevents the export process. It highlights the specific missing or non-compliant component and provides actionable, automated repair options wherever technically feasible.

Enforcing the Memory Safety Boundary

To ensure that malicious manipulation of memory files—such as an adversarial prompt injection silently written to a wiki page—cannot grant an agent unauthorized access to the host system, the application must enforce strict parsing algorithms. Within the Package Inspector, users can review the absolute boundaries enforced by the application, providing peace of mind that text-based memory cannot be weaponized.

This rigid enforcement matrix assures enterprise and privacy-conscious users that the expansive capabilities of local artificial intelligence remain entirely subservient to the architectural constraints of the LocalEndpoint desktop application. The successful implementation of this package and memory management architecture requires a delicate equilibrium between exposing powerful systemic controls and abstracting away the inherent complexities of local file systems. By strictly defining components using the definitive "Required For {x}" nomenclature, the user experience eliminates ambiguity and ensures total comprehension of the agent's composition. Furthermore, by anchoring wiki memory to standard operating system directories, LocalEndpoint elegantly resolves the data backup dilemma by leveraging existing system utilities. However, this reliance on external file systems necessitates robust, application-level safety nets. The integration of atomic file swaps, lockfile concurrency management, and a dedicated conflict resolution interface are absolute prerequisites. Without these critical user experience components, the promised durability and autonomy of local AI agents will inevitably succumb to the realities of data corruption and synchronization conflicts, rendering the system unreliable. Adherence to these exhaustive specifications will yield a desktop experience that is highly resilient, completely transparent, and effortlessly portable.

Works cited

1. Introducing .agent \- The Open Packaging Standard for AI Agents \- Chris Hood, https://chrishood.com/introducing-agent-the-open-packaging-standard-for-ai-agents/
2. .fylle Protocol — The Portable AI Agent Format, https://fylle.ai/protocol/
3. AS-ITS-UAIX \- bgp.he.net, https://bgp.he.net/irr/as-set/AS-ITS-UAIX
4. UAIX.Talisman.EcosystemManager 0.1.1 on NuGet \- Libraries.io, https://libraries.io/nuget/UAIX.Talisman.EcosystemManager
5. UAIX.UAI.Memory 1.0.4 on NuGet \- Libraries.io \- security, https://libraries.io/nuget/UAIX.UAI.Memory
6. Michael.Kappel \- NuGet Gallery, https://www.nuget.org/profiles/Michael.Kappel
7. Memory wiki \- OpenClaw Docs, https://docs.openclaw.ai/plugins/memory-wiki
8. OpenClaw Memory Wiki Guide: Setup, Config, and Best Uses (2026) \- BetterClaw, https://www.betterclaw.io/blog/openclaw-memory-wiki-guide
9. Why I think markdown files are better than databases for AI memory : r/AIMemory \- Reddit, https://www.reddit.com/r/AIMemory/comments/1r2pd8k/why\_i\_think\_markdown\_files\_are\_better\_than/
10. Building stateful AI: Integrating Aura Agent lifecycle with MCP and persistent memory, https://neo4j.com/blog/genai/building-stateful-ai-integrating-aura-agent-lifecycle-with-mcp-and-persistent-memory/
11. My implementation of Karpathy's wiki idea, for coding agents : r/mcp \- Reddit, https://www.reddit.com/r/mcp/comments/1ssodwi/my\_implementation\_of\_karpathys\_wiki\_idea\_for/
12. Claude Code Parallel Sessions: How to Work on Multiple Projects Simultaneously, https://www.mindstudio.ai/blog/claude-code-parallel-sessions
13. draft-hood-independent-agtp-07, https://datatracker.ietf.org/doc/html/draft-hood-independent-agtp-07
14. sql++ \- how to join documents of 2 different types on the basis of, https://stackoverflow.com/questions/76923251/how-to-join-documents-of-2-different-types-on-the-basis-of-document-id-in-couchb
15. Writing data to disk: transforming brittle code to robust code with atomic writes, https://dev.to/memattchung/writing-data-to-disk-transforming-brittle-code-to-robust-code-with-atomic-writes-5e3e
16. A way to do atomic writes \- LWN.net, https://lwn.net/Articles/789600/
17. Better File Writing in Python: Embrace Atomic Updates | by Manish Sah \- Medium, https://sahmanish20.medium.com/better-file-writing-in-python-embrace-atomic-updates-593843bfab4f
18. Solving Obsidian \+ Readwise Merge Conflicts with a Custom Git Driver | Charles Desneuf, https://blog.charlesdesneuf.com/articles/solving-obsidian-readwise-merge-conflicts-with-a-custom-git-driver/
19. Option to let user manually resolve sync conflicts \- Feature archive \- Obsidian Forum, https://forum.obsidian.md/t/option-to-let-user-manually-resolve-sync-conflicts/94468
20. Atomic file write operations (cross platform) \- java \- Stack Overflow, https://stackoverflow.com/questions/2049247/atomic-file-write-operations-cross-platform
21. python-atomicwrites — atomicwrites 1.4.0 documentation, https://python-atomicwrites.readthedocs.io/en/latest/
22. Best way to prevent race conditions in a multi instance web environment? \- Stack Overflow, https://stackoverflow.com/questions/25865902/best-way-to-prevent-race-conditions-in-a-multi-instance-web-environment
23. SQLite problem \- LiveCode Forums., https://forums.livecode.com/viewtopic.php?t=25304
24. How do I unlock an SQLite database? \- Stack Overflow, https://stackoverflow.com/questions/151026/how-do-i-unlock-an-sqlite-database
25. How to lock file access in async ? : r/rust \- Reddit, https://www.reddit.com/r/rust/comments/kjn8dp/how\_to\_lock\_file\_access\_in\_async/
26. Robust Sync Conflict Resolution \- Help \- Obsidian Forum, https://forum.obsidian.md/t/robust-sync-conflict-resolution/93544
27. GSoC 2026 Proposal Draft \- Idea 10: Automatic Conflict Resolution – Sriram Varun Kumar, https://discourse.joplinapp.org/t/gsoc-2026-proposal-draft-idea-10-automatic-conflict-resolution-sriram-varun-kumar/49197
28. Combining Changes and Resolving Conflicts | Mendix Documentation, https://docs.mendix.com/refguide/resolving-conflicts/
29. \[Feature Request\] Conflict Handling to Help with Multi-Device Usage · Issue \#803 · Vinzent03/obsidian-git \- GitHub, https://github.com/Vinzent03/obsidian-git/issues/803