Website update: How-To Organization, Automated Landing Pages

.github/workflows/build-test-rhel8.yml

@@ -6,10 +6,10 @@ name: CI [RHEL8]
 # events but only for the master branch
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/cmake-test.yml

@@ -4,10 +4,10 @@ name: CMake Test
 # events but only for the master branch
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/codeql-jpl-standard.yml

@@ -5,10 +5,10 @@ name: "Code Scan: JPL Coding Standard"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/codeql-security-scan.yml

@@ -5,10 +5,10 @@ name: "Code Scan: CodeQL Security"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/config-test.yml

@@ -6,9 +6,9 @@ name: "Config Test"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/coverage-check.yml

@@ -22,7 +22,7 @@ name: "Coverage Check"
 
 on:
   pull_request:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/coverage-update.yml

@@ -18,7 +18,7 @@ name: "Coverage Update"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     tags:     [ 'v*' ]
   workflow_dispatch:
 

.github/workflows/cppcheck-scan.yml

@@ -3,10 +3,10 @@ name: "Code Scan: CppCheck"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-aarch64-linux-led-blinker.yml

@@ -5,10 +5,10 @@ name: "External Repo: AArch64 Linux LedBlinker"
 
 on:
   push:
-    branches: [devel, release/**]
+    branches: [zensical-integ, release/**]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [devel, release/**]
+    branches: [zensical-integ, release/**]
     paths-ignore:
       - "docs/**"
       - "**.md"

.github/workflows/ext-build-examples-repo.yml

@@ -4,10 +4,10 @@ name: "External Repo: fprime-examples"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-build-hello-world.yml

@@ -4,10 +4,10 @@ name: "External Repo: Tutorial: HelloWorld"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-build-led-blinker.yml

@@ -4,10 +4,10 @@ name: "External Repo: Tutorial: LedBlinker"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-build-math-comp.yml

@@ -4,10 +4,10 @@ name: "External Repo: Tutorial: MathComponent"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-cookiecutters-test.yml

@@ -2,10 +2,10 @@ name: "External Repo: Cookiecutters Tests"
 
 on:
  push:
-   branches: [ devel, release/** ]
+   branches: [ zensical-integ, release/** ]
  pull_request:
    # The branches below must be a subset of the branches above
-   branches: [ devel, release/** ]
+   branches: [ zensical-integ, release/** ]
    paths-ignore:
      - 'docs/**'
      - '**.md'

.github/workflows/ext-fprime-cfs-reference.yml

@@ -5,10 +5,10 @@ name: "External Repo: cFS Reference"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-fprime-zephyr-reference-pico2.yml

@@ -4,10 +4,10 @@ name: "External Repo: Zephyr Reference (Pico 2)"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-fprime-zephyr-reference-teensy41.yml

@@ -4,10 +4,10 @@ name: "External Repo: Zephyr Reference (Teensy 4.1)"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/ext-raspberry-led-blinker.yml

@@ -5,10 +5,10 @@ name: "External Repo: RPI LedBlinker"
 
 on:
   push:
-    branches: [devel, release/**]
+    branches: [zensical-integ, release/**]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [devel, release/**]
+    branches: [zensical-integ, release/**]
     paths-ignore:
       - "docs/**"
       - "**.md"

.github/workflows/format-check.yml

@@ -2,10 +2,10 @@ name: "Code Format Check"
 
 on:
   push:
-    branches: [ devel, release/**, ci/** ]
+    branches: [ zensical-integ, release/**, ci/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/fpp-tests.yml

@@ -2,10 +2,10 @@ name: "FppTest"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/fpp-to-json.yml

@@ -2,10 +2,10 @@ name: "fpp-to-json Test"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/framework.yml

@@ -4,9 +4,9 @@ name: "Framework"
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
     paths-ignore:
       - 'docs/**'
       - '**.md'

.github/workflows/markdown-link-check.yml

@@ -2,9 +2,9 @@ name: Check Markdown links
 
 on: 
   push:
-    branches: [devel, docs/new-website]
+    branches: [zensical-integ, docs/new-website]
   pull_request:
-    branches: [devel]
+    branches: [zensical-integ]
 # Cancel in-progress runs if a newer run is started on a given PR
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}

.github/workflows/python-format.yml

@@ -2,10 +2,10 @@ name: Format Python
 
 on:
   push:
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ devel, release/** ]
+    branches: [ zensical-integ, release/** ]
 # Cancel in-progress runs if a newer run is started on a given PR
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}

.github/workflows/ref.yml

@@ -4,9 +4,9 @@ name: "Ref"
 
 on:
   push:
-    branches: [devel, release/**]
+    branches: [zensical-integ, release/**]
   pull_request:
-    branches: [devel, release/**]
+    branches: [zensical-integ, release/**]
     paths-ignore:
       - "docs/**"
       - "**.md"

docs/how-to/data-products.md → docs/how-to/develop/data-products.md

@@ -1,4 +1,4 @@
-# How-To: Generate Data Products
+# Generate Data Products
 
 This How-To describes **when to use data products**, **how to generate them in flight software**, **how to test them**, and provides guidance for **topology integration** and **ground decoding**. It is intended for engineers who are comfortable with F Prime components and want to add structured, store-and-forward mission data to their system.
 

docs/how-to/define-state-machines.md → docs/how-to/develop/define-state-machines.md

@@ -1,4 +1,4 @@
-# How-To: Define State Machines in F Prime
+# Define State Machines in F Prime
 
 This guide shows how to define and use state machines in F Prime using the F Prime Modeling Language (FPP). State machines help capture component behavior by modeling modes (states) and transitions explicitly, making complex logic easier to implement, test, and maintain. FPP provides autocoding capabilities to allow users to quickly implement state-defined behavior.
 

docs/how-to/develop-device-driver.md → docs/how-to/develop/develop-device-driver.md

@@ -19,7 +19,7 @@ Before starting, you should have:
 
 A "device driver" traditionally refers to the entire stack of software that manages a hardware device. In F´, the driver-manager pattern splits this in two components: the device manager component and the bus driver component. The bus driver handles the platform-specific implementation of communications on a specific bus (e.g., LinuxI2cDriver, LinuxUartDriver). The device manager handles the operations and logic for a specific device. This enhances modularity and reusability: for example the same device manager can be ported to different platforms by switching the bus driver component.
 
-Please refer to the [Application Manager Driver pattern documentation](../user-manual/design-patterns/app-man-drv.md) for more details on the design pattern used in F Prime for device drivers.
+Please refer to the [Application Manager Driver pattern documentation](../../user-manual/design-patterns/app-man-drv.md) for more details on the design pattern used in F Prime for device drivers.
 
 ### Example and reference
 
@@ -65,7 +65,7 @@ Use `fprime-util new --component` to create a new component for your device mana
 
 This component will translate device-specific operations into bus transactions. Identify the bus type (I2C, SPI, UART, etc.) and the operations needed (read, write, configure, etc.). These should be reflected in the component's ports by mirroring the bus driver's interface.
 
-For our `ImuManager` component, we are using an I2C bus, therefore we need to define ports that mirror the `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../Drv/Interfaces/I2c.fpp)).  
+For our `ImuManager` component, we are using an I2C bus, therefore we need to define ports that mirror the `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../../Drv/Interfaces/I2c.fpp)).  
 For example, a `Drv.I2c` component provides an ***input*** port of type `Drv.I2cWriteRead`, so we need to define an ***output*** port of that type in our component in order to connect to a bus driver component. We mirror each Bus Driver port that we need to use in our Device Manager.
 
 ```python
@@ -280,7 +280,7 @@ We learn the following:
 
 ### Step 2 - Define the Bus Driver Component
 
-Use `fprime-util new --component` to create a new component for your bus driver. The set of ports that a bus driver needs to expose depends on the bus communication protocol (I2C, SPI, UART, etc.). F Prime provides standard interfaces for common bus types in the `Drv/Interfaces/` directory. For I2C, we can use the existing `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../Drv/Interfaces/I2c.fpp)).
+Use `fprime-util new --component` to create a new component for your bus driver. The set of ports that a bus driver needs to expose depends on the bus communication protocol (I2C, SPI, UART, etc.). F Prime provides standard interfaces for common bus types in the `Drv/Interfaces/` directory. For I2C, we can use the existing `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../../Drv/Interfaces/I2c.fpp)).
 
 ```python
 # In: ZephyrI2cDriver.fpp
@@ -292,7 +292,7 @@ passive component ZephyrI2cDriver {
 ```
 
 > [!TIP]
-> Our I2C bus driver will only be responding to read/write requests from a device manager, therefore we define it as a `passive component` and the `Drv.I2c` ports are sufficient. If your bus driver needs to perform scheduled tasks (e.g., polling, timeouts, etc.), you may consider adding a scheduling port (`Svc.Sched`) to hook to a [Svc.RateGroup](../../Svc/ActiveRateGroup/docs/sdd.md), and potentially switching to an `active` component. `queued` components can also be used but need careful design to ensure messages are dispatched.
+> Our I2C bus driver will only be responding to read/write requests from a device manager, therefore we define it as a `passive component` and the `Drv.I2c` ports are sufficient. If your bus driver needs to perform scheduled tasks (e.g., polling, timeouts, etc.), you may consider adding a scheduling port (`Svc.Sched`) to hook to a [Svc.RateGroup](../../../Svc/ActiveRateGroup/docs/sdd.md), and potentially switching to an `active` component. `queued` components can also be used but need careful design to ensure messages are dispatched.
 
 Run `fprime-util impl` to generate the component C++, including the port handler to fill out. In our case, we will need to implement the `write`, `read`, and `writeRead` port handlers.
 
@@ -405,9 +405,9 @@ void configureTopology() {
 
 ## Additional Resources
 
-- [Application Manager Driver Pattern](../user-manual/design-patterns/app-man-drv.md)
+- [Application Manager Driver Pattern](../../user-manual/design-patterns/app-man-drv.md)
 - [fprime-sensors Repository](https://github.com/fprime-community/fprime-sensors) - A collection of ready-to-use device managers for specific devices
 - [fprime-sensors-reference Repository](https://github.com/fprime-community/fprime-sensors-reference) - Reference project that uses sensors defined in fprime-sensors
-- [F´ core Linux Bus Drivers](../../Drv/)
+- [F´ core Linux Bus Drivers](../../../Drv)
 - [fprime-zephyr package](https://github.com/fprime-community/fprime-zephyr) - F Prime support for Zephyr RTOS, including common bus drivers for Zephyr
 

docs/how-to/develop-fprime-libraries.md → docs/how-to/develop/develop-fprime-libraries.md

@@ -59,7 +59,7 @@ add_fprime_subdirectory("${CURRENT_CMAKE_LIST_DIR}/MyLibrary/MyTopology")
 
 F´ libraries share F´ code through modules. These module directories are created by `fprime-util new --component` or by hand and may include any F´ code (Components, Ports, Topologies, Data Types, etc.).  These types are made available to users of the library by ensuring that they are added to the `library.cmake` file.  The only restriction is that these component should be placed under a namespacing directory for the library (e.g. `MyLibrary`) to avoid collisions with other libraries and F´ code.
 
-Developing component, ports, topologies, etc. are the subject of our [tutorials](../tutorials/index.md).
+Developing component, ports, topologies, etc. are the subject of our [tutorials](../../tutorials/index.md).
 
 
 ## Optional: Toolchain Folder and Toolchain Files

docs/how-to/develop-subtopologies.md → docs/how-to/develop/develop-subtopologies.md

@@ -1,13 +1,13 @@
 # Develop a Subtopology
 
-Subtopologies are topologies for smaller chunks of behavior in F Prime. It allows for grouping bits of topology architecture that fit together, to then be imported into a base deployment's topology. The use case for this is seen when working with shareable components, specifically in the form of [libraries](./develop-fprime-libraries.md).
+Subtopologies are topologies for smaller chunks of behavior in F Prime. It allows for grouping bits of topology architecture that fit together, to then be imported into a base deployment's topology. The use case for this is seen when working with shareable components, specifically in the form of [libraries](develop-fprime-libraries.md).
 
 *Contents*
 1. [Subtopology Structure](#subtopology-structure)
 2. [Individual File Contents](#individual-file-contents)
     1. [Example Scenario](#example-scenario)
 3. [Integration into a "Main" Deployment](#integration-into-a-main-deployment)
-4. [Subtopology Autocoder](#the-subtopology-autocoder)
+4. [Adding Subtopology Configuration](#adding-subtopology-configuration)
 5. [Conclusion](#conclusion)
 
 ## Subtopology Structure