chore(edit-docs): move Markdown documentation outside src for now

docs/User Guide/User Guide/Advanced Usage/Attributes/Attribute Inheritance.md

@@ -0,0 +1,25 @@
+# Attribute Inheritance
+## 1\. Standard Inheritance
+
+In Trilium, attributes can be automatically inherited by child notes if they have the `isInheritable` flag set to `true`. This means the attribute (a key-value pair) is applied to the note and all its descendants.
+
+### Example Use Case
+
+The `archived` label can be set to be inheritable, allowing you to hide a whole subtree of notes from searches and other dialogs by applying this label at the top level.
+
+## 2\. Copying Inheritance
+
+Copying inheritance differs from standard inheritance by using a `child:` prefix in the attribute name. This prefix causes new child notes to automatically receive specific attributes from the parent note. These attributes are independent of the parent and will persist even if the note is moved elsewhere.
+
+### How to Use
+
+*   **Syntax:** `#child:attributeName`
+*   **Chained Inheritance:** You can chain this inheritance, such as `#child:child:attributeName`, where each child down the hierarchy receives the appropriate attribute.
+
+### Example
+
+If a parent note has the label `#child:exampleAttribute`, all newly created child notes will inherit the `#exampleAttribute` label. This can be useful for setting default properties for notes in a specific section.
+
+## 3\. Template Inheritance
+
+Attributes can also be inherited from [templates](Template.md). When a new note is created using a template, it inherits the attributes defined in that template. This is particularly useful for maintaining consistency across notes that follow a similar structure or function.

docs/User Guide/User Guide/Advanced Usage/Attributes/Promoted Attributes.md

@@ -0,0 +1,32 @@
+# Promoted Attributes
+Promoted attributes are [attributes](../Attributes.md) which are considered important and thus are "promoted" onto the main note UI. See example below:
+
+![](../../Attachments/promoted-attributes.png)
+
+You can see the note having kind of form with several fields. Each of these is just regular attribute, the only difference is that they appear on the note itself.
+
+Attributes can be pretty useful since they allow for querying and script automation etc. but they are also inconveniently hidden. This allows you to select few of the important ones and push them to the front of the user.
+
+Now, how do we make attribute to appear on the UI?
+
+## Attribute definition
+
+Attribute is always name-value pair where both name and value are strings.
+
+_Attribute definition_ specifies how should this value be interpreted - is it just string, or is it a date? Should we allow multiple values or note? And importantly, should we _promote_ the attribute or not?
+
+![](Promoted Attributes_image.png)
+
+You can notice tag attribute definition. These "definition" attributes define how the "value" attributes should behave.
+
+So there's one attribute for value and one for definition. But notice how definition attribute is [Inheritable](Attribute%20Inheritance.md), meaning that it's also applied to all descendant note. So in a way, this definition is used for the whole subtree while "value" attributes are applied only for this note.
+
+### Inverse relation
+
+Some relations always occur in pairs - my favorite example is on the family. If you have a note representing husband and note representing wife, then there might be a relation between those two of `isPartnerOf`. This is bidirectional relationship - meaning that if a relation is pointing from husband to wife then there should be always another relation pointing from wife to husband.
+
+Another example is with parent - child relationship. Again these always occur in pairs, but in this case it's not exact same relation - the one going from parent to child might be called `isParentOf` and the other one going from child to parent might be called `isChildOf`.
+
+Relation definition allows you to specify such "inverse relation" - for the relation you just define you specify which is the inverse relation. Note that in the second example we should have two relation definitions - one for `isParentOf` which defines `isChildOf` as inverse relation and then second relation definition for `isChildOf` which defines `isParentOf` as inverse relation.
+
+What this does internally is that whenever we save a relation which has defined inverse relation, we check that this inverse relation exists on the relation target note. Similarly, when we delete relation, we also delete inverse relation on the target note.

docs/User Guide/User Guide/Advanced Usage/Attributes/Template.md

@@ -0,0 +1,36 @@
+# Template
+A template in Trilium serves as a predefined structure for other notes, referred to as instance notes. Assigning a template to a note brings three main effects:
+
+1.  **Attribute Inheritance**: All attributes from the template note are [inherited](Attribute%20Inheritance.md) by the instance notes. Even attributes with `#isInheritable=false` are inherited by the instance notes, although only inheritable attributes are further inherited by the children of the instance notes.
+2.  **Content Duplication**: The content of the template note is copied to the instance note, provided the instance note is empty at the time of template assignment.
+3.  **Child Note Duplication**: All child notes of the template are deep-duplicated to the instance note.
+
+## Example
+
+A typical example would be a "Book" template note, which might include:
+
+*   **Promoted Attributes**: Such as publication year, author, etc. (see [promoted attributes](Promoted%20Attributes.md)).
+*   **Outline**: An outline for a book review, including sections like themes, conclusion, etc.
+*   **Child Notes**: Additional notes for highlights, summary, etc.
+
+![Template Example](../../Attachments/template.png)
+
+## Instance Note
+
+An instance note is a note related to a template note. This relationship means the instance note's content is initialized from the template, and all attributes from the template are inherited.
+
+To create an instance note through the UI:
+
+![show child note templates](../../Attachments/template-create-instance-n.png)
+
+For the template to appear in the menu, the template note must have the `#template` label. Do not confuse this with the `~template` relation, which links the instance note to the template note. If you use [workspaces](../../Basic%20Concepts/Navigation/Workspace.md), you can also mark templates with `#workspaceTemplate` to display them only in the workspace.
+
+Templates can also be added or changed after note creation by creating a `~template` relation pointing to the desired template note.
+
+## Additional Notes
+
+From a visual perspective, templates can define `#iconClass` and `#cssClass` attributes, allowing all instance notes (e.g., books) to display a specific icon and CSS style.
+
+Explore the concept further in the [demo notes](../Database.md), including examples like the [Relation Map](../Relation%20Map.md), [Task Manager](../Advanced%20Showcases/Task%20Manager.md), and [Day Notes](../Advanced%20Showcases/Day%20Notes.md).
+
+Additionally, see [default note title](../Default%20Note%20Title.md) for creating title templates. Note templates and title templates can be combined by creating a `#titleTemplate` for a template note.