Merge API docs and reorganize files into folders that match the sidebar navigation

docs/archive/bootcamp.md

@@ -2,7 +2,7 @@
 id: bootcamp
 title: Suffolk LIT Lab's Document Assembly Line Bootcamp
 sidebar_label: Bootcamp
-slug: /archive/bootcamp
+slug: bootcamp
 ---
 
 :::info
@@ -46,9 +46,9 @@ After signing up, you should have received invites to our docassemble server (ht
 
 Resources from the session:
 
-* [Running templates through the Weaver](weaver_overview.md)
-* [Labeling PDF variables](pdf_templates.md)
-* [Naming Variables Quick Reference](doc_vars_reference.md)
+* [Running templates through the Weaver](../authoring/weaver_overview.md)
+* [Labeling PDF variables](../authoring/pdf_templates.md)
+* [Naming Variables Quick Reference](../authoring/doc_vars_reference.md)
 * [The LIST taxonomy](https://taxonomy.legal/)
 
 Homework:
@@ -78,7 +78,7 @@ additional questions.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/VAzXYEacN78" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-* [Using Github in Docassemble](github.md)
+* [Using Github in Docassemble](../authoring/github.md)
 * Customizing basic branding with the [ALThemeTemplate](https://github.com/SuffolkLITLab/docassemble-ALThemeTemplate) package.
     * Logo
     * Intro screen

docs/customizing_interview.md → docs/authoring/customizing_interview.md

@@ -2,7 +2,7 @@
 id: customizing_interview
 title: Editing your interview
 sidebar_label: Editing your interview
-slug: /customizing_interview
+slug: customizing_interview
 ---
 
 ## Edit your completed draft interview in the Docassemble playground
@@ -34,7 +34,7 @@ quite right, perhaps something as simple as a typo.
 ## Work towards a readable, usable interview
 
 You should also take this chance to review our guidance about
-[writing good questions](/docs/question_style_overview.md). While you edit
+[writing good questions](../style_guide/question_style_overview.md). While you edit
 your interview, work steadily to make it better.
 
 ## Getting the draft into your playground
@@ -56,11 +56,11 @@ Before downloading the package, turn off that behavior:
 First, create a new "Project" in your playground. Using projects will
 help you keep your Docassemble code organized.
 
-![playground | projects ](./assets/playground_projects.png)
+![playground | projects ](../assets/playground_projects.png)
 
 Next, upload this file to the Docassemble playground's `Packages` folder.
 
-![Folders | Packages ](./assets/playground_packages_menu.png)
+![Folders | Packages ](../assets/playground_packages_menu.png)
 
 ## How to edit your interview
 
@@ -76,15 +76,15 @@ Scroll through and take a look at the code. You will see:
   that are asked on each screen
 
 You do not need to understand all of the code. Absorb what you can, and feel free
-to experiment. Save your code often, preferably to a [GitHub](/docs/github) repository.
+to experiment. Save your code often, preferably to a [GitHub](../authoring/github.md) repository.
 
 You will likely start by clicking the "Save and Run" button to try running your
 interview through to the end. Note any awkward wording or changes you want to make.
 
 Use the `id` that is on the top of each screen to find the screen that you want to change.
 Then, change the text that you want to change, or change the order of fields.
 
-![id: request a guardianship](./assets/playground_id.png)
+![id: request a guardianship](../assets/playground_id.png)
 
 Below we describe some of the most common starting customizations you will make,
 especially changes that interact with an Assembly Line convention.
@@ -436,7 +436,7 @@ content: |
 We usually don't recommend using the other options,
 which include help for the whole page (it comes too late) or `terms` (they get very cluttered very quickly).
 
-A more complete guide to [helping your user](/docs/coding_style/yaml_interface.md#adding-help-in-context).
+A more complete guide to [helping your user](../coding_style/yaml_interface.md#adding-help-in-context).
 
 ## Why is this question getting asked?!!!
 
@@ -754,4 +754,4 @@ with the blinking cursor.
 If you want to discard your changes and start over, upload the package .ZIP file
 to your playground again. This will wipe out all of your changes.
 
-Use [GitHub](/docs/github) regularly to let you restore your work from a point in time.
+Use [GitHub](../authoring/github.md) regularly to let you restore your work from a point in time.

docs/doc_vars_reference.md → docs/authoring/doc_vars_reference.md

@@ -2,7 +2,7 @@
 id: document_variables_reference
 title: Field labels to use in template files
 sidebar_label: Field labels to use in template files
-slug: /label_variables
+slug: label_variables
 ---
 
 The Document Assembly Line framework can help you automate templates that use any
@@ -11,8 +11,8 @@ that we list below for full compatibility.
 
 ## Example documents
 
-- [A fully labeled PDF](./assets/generic_motion_family_law.pdf)
-- [The DOCX version of the same motion](./assets/generic_motion_family_law.docx)
+- [A fully labeled PDF](../assets/generic_motion_family_law.pdf)
+- [The DOCX version of the same motion](../assets/generic_motion_family_law.docx)
 
 :::info Use a custom AI assistant for labeling instead
 
@@ -48,12 +48,12 @@ rules below to add as many custom labels as you need.
 #### Labels should be valid Python variable names that start with a letter
 
 PDF and DOCX `labels` should also work as valid [Python variable
-names](/docs/coding_style_guide/python). The basic rule is that Python variable names
+names](../coding_style/python.md). The basic rule is that Python variable names
 need to start with a letter and can only contain letters, digits, and the `_`
 underscore character. Some variable names are
-[reserved](framework/reserved_keywords.md) and have a special meaning inside
+[reserved](../components/AssemblyLine/reserved_keywords.md) and have a special meaning inside
 AssemblyLine interviews. You should not use a variable name on the
-[reserved](framework/reserved_keywords.md) list. Doing so can lead to 
+[reserved](../components/AssemblyLine/reserved_keywords.md) list. Doing so can lead to 
 hard to track bugs.
 
 #### Variable names are case sensitive - make them all lowercase
@@ -395,4 +395,4 @@ your edited template directly to the Docassemble playground's templates folder.
 
 ## See also
 
-- [List of reserved variable names](framework/reserved_keywords.md)
+- [List of reserved variable names](../components/AssemblyLine/reserved_keywords.md)

docs/docx_templates.md → docs/authoring/docx_templates.md

@@ -2,7 +2,7 @@
 id: docx_templates
 title: Working with DOCX files
 sidebar_label: Working with DOCX files
-slug: /docx
+slug: docx
 ---
 
 :::tip
@@ -193,7 +193,7 @@ each condition.
 ### Use `output_checkbox()` for conditional checkbox fields that look like paper forms
 
 In some cases, you need to make your Word Document look like a document that was
-filled in by hand. [`output_checkbox()`](https://assemblyline.suffolklitlab.org/docs/framework/altoolbox#shorthand-function-to-display-a-checkbox-in-replace-of-a-truefalse-boolean-value-in-a-docx-template) can be used to add a checkbox in-line in your document.
+filled in by hand. [`output_checkbox()`](../components/ALToolbox/altoolbox_overview.md#shorthand-function-to-display-a-checkbox-in-replace-of-a-truefalse-boolean-value-in-a-docx-template) can be used to add a checkbox in-line in your document.
 
 These two expressions are equivalent, but the second version takes substantially less
 space in your template:

docs/authoring/dynamic_phrasing_based_on_values.md

@@ -2,7 +2,7 @@
 id: dynamic_phrasing_based_on_values
 title: Dynamic phrasing based on values (gender, list length, and more)
 sidebar_label: Dynamic phrasing based on values
-slug: /authoring/dynamic_phrasing_based_on_values
+slug: dynamic_phrasing_based_on_values
 ---
 
 Docassemble has several clever features that you can use in templates

docs/github.md → docs/authoring/github.md

@@ -2,7 +2,7 @@
 id: github
 title: Using GitHub with Docassemble
 sidebar_label: "Using GitHub"
-slug: /github
+slug: github
 ---
 
 

docs/name_formats.md → docs/authoring/name_formats.md

@@ -2,7 +2,7 @@
 id: name_formats
 title: Name formats
 sidebar_label: Name formats
-slug: /naming
+slug: naming
 ---
 
 In programming languages (and sometimes in computer files and names in general),

docs/pdf_templates.md → docs/authoring/pdf_templates.md

@@ -2,7 +2,7 @@
 id: pdf_templates
 title: Working with PDF files
 sidebar_label: Working with PDF files
-slug: /pdfs
+slug: pdfs
 ---
 
 :::tip

docs/weaver_code_anatomy.md → docs/authoring/weaver_code_anatomy.md

@@ -4,7 +4,7 @@ title: |
   Appendix: Understanding the YAML code
 sidebar_label: |
   Appendix: Understanding the YAML code
-slug: /generated_yaml
+slug: generated_yaml
 ---
 
 :::warning
@@ -85,7 +85,7 @@ code: |
 1. `original_form` is a link to the original, fillable PDF form that this interview is automating, if it exists.
 1. 🚧 `allowed courts` allows your code to decide which courts to let the user pick from when they need to pick their court, usually used in conjunction with [ALThemeTemplate](https://github.com/SuffolkLITLab/docassemble-ALThemeTemplate).
 1. `categories` is the [LIST taxonomy](https://taxonomy.legal/) code for this interview, which can be used by your organization to organize your interviews.
-1. `attachment block variable` used to be used in the code that sends documents to courts, but now the [ALDocument object block](reference/AssemblyLine/al_document#aldocument-objects) is used instead.
+1. `attachment block variable` used to be used in the code that sends documents to courts, but now the [ALDocument object block](../components/AssemblyLine/al_document#aldocument-objects) is used instead.
 1. `logic block variable` should also no longer be used.
 1. `typical role`: controls which questions the user gets asked about themselves and other parties.
 

docs/weaver_overview.md → docs/authoring/weaver_overview.md

@@ -4,7 +4,7 @@ title: |
    "Weaving" your form into a draft interview
 sidebar_label: |
    "Weaving" your form into a draft interview
-slug: /generating_code
+slug: generating_code
 ---
 
 <!-- Boilerplate, Baseline, kit, ready to build, some assembly required, something to build on, starting point, blank slate, foundation, groundwork, starter dough, groundwork, spark -->
@@ -92,7 +92,7 @@ When you have finished using the Weaver, download your package. This will put a
 
 Next, upload this file to the Docassemble playground's `Packages` folder.
 
-![Folders | Packages ](./assets/playground_packages_menu.png)
+![Folders | Packages ](../assets/playground_packages_menu.png)
 
 :::warning If you are using Safari on a Mac OS computer
 Safari, by default, will turn your downloaded package into
@@ -108,6 +108,6 @@ Before downloading the package, turn off that behavior:
 ## Example of a page in a Docassemble interview
 A page might look like this:
 
-![One page of an interview made up of a heading, explanatory text, and the fields](./assets/interview_screen_or_page.png)
+![One page of an interview made up of a heading, explanatory text, and the fields](../assets/interview_screen_or_page.png)
 
 You can see [the ALWeaver docassemble package on GitHub](https://github.com/suffolkLITLab/docassemble-ALWeaver)

docs/writing_review_screen.md → docs/authoring/writing_review_screen.md

@@ -4,7 +4,7 @@ title: |
   Writing a Review Screen
 sidebar_label: |
   Review Screen
-slug: /review_screen
+slug: review_screen
 ---
 
 ## Overview
@@ -57,7 +57,7 @@ Download the primary YAML files of your interview. You can download the YAML fil
 * from GitHub. For example, for the [Motion to Stay Eviction](https://github.com/SuffolkLITLab/docassemble-MotionToStayEviction/), you can navigate
   to [the primary YAML file, SP6A.yml](https://github.com/SuffolkLITLab/docassemble-MotionToStayEviction/blob/main/docassemble/MotionToStayEviction/data/questions/SP6A.yml), and click the "download raw file" button.
 
-  ![A github page screenshot, the "download raw file" button in the top bar of the github file is circled](../docs/assets/review_download_yaml_from_github.png)
+  ![A github page screenshot, the "download raw file" button in the top bar of the github file is circled](../assets/review_download_yaml_from_github.png)
 
 You should download all of the YAML files that define variables used in your interview. The more YAML files you download, the more content you might have to
 cut from the generated review screen.
@@ -178,7 +178,7 @@ There are a few sections of the generated review screen YAML:
 
     But your interview might include [objects](https://docassemble.org/docs/objects.html#Individual) and lists of objects, like a list of plaintiffs and another list of defendants. Instead of re-asking every question that someone answered to fill the list, docassemble brings to the user to a `revisit` screen that shows each item in the list to the user, and lets them choose which to edit individually.
 
-    If you used the [Weaver](https://assemblyline.suffolklitlab.org/docs/label_variables#standard-roles) to make your interview, your interview might have a few different lists for people,
+    If you used the [Weaver](doc_vars_reference.md#standard-roles) to make your interview, your interview might have a few different lists for people,
     like `users`, `other_parties`, `children`, `debt_collectors`, and `guardians`.
 
 4. The `revisit` screens each show the `table` attribute of the `DAList`. If needed, blocks defining the table for the lists will appear at the end of the generated review file.

docs/coding_style/accessibility.md

@@ -2,7 +2,7 @@
 id: accessibility
 title: Making your interview accessible
 sidebar_label: Interview accessibility
-slug: /coding_style_guide/accessibility
+slug: accessibility
 ---
 
 **Web Accessibility** is the practice of making your website usable by many different users, such as those who use keyboard controls or screen readers.
@@ -11,7 +11,7 @@ Making your guided interviews accessible is first and foremost about making them
 
 Other parts of web accessibility involve writing the interview in a way that the user's browser and other accessibility tools (like screen readers) can understand. Docassemble [handles many of these things](https://docassemble.org/docs/accessibility.html) for you, but there are some parts that you'll have to address when writing your interview.
 
-To help you find accessibility problems in your interview you can use the [WAVE browser extension](https://wave.webaim.org/extension/), or if you want to check accessibility of your interview automatically, you can use the [ALKiln testing framework](../alkiln/automated_testing.mdx#accessibility).
+To help you find accessibility problems in your interview you can use the [WAVE browser extension](https://wave.webaim.org/extension/), or if you want to check accessibility of your interview automatically, you can use the [ALKiln testing framework](../components/ALKiln/automated_testing.mdx#accessibility).
 
 ## Use colors that contrast strongly with their backgrounds
 

docs/coding_style/coding_style_overview.md

@@ -2,7 +2,7 @@
 id: coding_style_overview
 title: Docassemble Coding Style Guide
 sidebar_label: Coding Style
-slug: /coding_style_guide
+slug: overview
 ---
 
 <!-- original: https://docs.google.com/document/d/1B-_6A5OKZ0b3s8z2S14KdRQsK7ga4nmjjthJiaZMiB8/edit#heading=h.cvtj6d8ezh8x -->

docs/coding_style/defense.md

@@ -4,7 +4,7 @@ title: |
    "Safe" coding
 sidebar_label: |
    "Safe" coding
-slug: /coding_style_guide/defense
+slug: defense
 ---
 
 ## Use Docassemble lists, dictionaries, and sets, or subclasses

docs/coding_style/python.md

@@ -2,7 +2,7 @@
 id: python
 title: Python
 sidebar_label: Python
-slug: /coding_style_guide/python
+slug: python
 ---
 
 ## Use Python conventions for Python code

docs/coding_style/yaml.md

@@ -2,7 +2,7 @@
 id: yaml
 title: Interview files
 sidebar_label: Interview files
-slug: /coding_style_guide/yaml
+slug: yaml
 ---
 
 Docassemble interviews are written in
@@ -75,7 +75,7 @@ trust with your end user.
 Avoid using numbers, underscores, and other markers to indicate that you have a
 "final", "draft", etc. interview even during the editing process, as these have
 a chance of getting leaked to the public. Instead, use [version
-control](/docs/github) to track the history of your files as your project develops.
+control](../authoring/github.md) to track the history of your files as your project develops.
 
 ### Use a small number of YAML files for each project
 

docs/coding_style/yaml_dynamic.md

@@ -2,7 +2,7 @@
 id: yaml_dynamic
 title: Making your interview dynamic
 sidebar_label: Making your interview dynamic
-slug: /coding_style_guide/yaml_dynamic
+slug: yaml_dynamic
 ---
 
 ### Use the `depends on` modifier when setting values with code

docs/coding_style/yaml_interface.md

@@ -2,7 +2,7 @@
 id: yaml_interface
 title: Choosing interface options
 sidebar_label: Choosing interface options
-slug: /coding_style_guide/yaml_interface
+slug: yaml_interface
 ---
 
 ## Use radio buttons for short lists of options