docs: pre-release audit — fix documentation drift for v0.1.0 (#7)

- README, overview, architecture: reflect dual-RTOS (Zephyr + FreeRTOS)
  instead of Zephyr-only descriptions
- architecture.rst: add note about platform abstraction layer enabling
  FreeRTOS backend; remove broken :doc: cross-reference to deleted file
- Remove freertos_porting_plan.rst (superseded by the implementation)
  and clean up all references to it in index.rst and architecture.rst
- changelog.rst: add FreeRTOS simulator, platform abstraction layer,
  network_config split, CI pipeline, and devcontainer image rename

Author: oguzkaganozt

README.md

@@ -8,10 +8,11 @@
 
 [![Documentation](https://img.shields.io/badge/docs-latest-brightgreen)](https://autowarefoundation.github.io/autoware-safety-island/)
 
-A standalone Zephyr RTOS application that runs Autoware's trajectory
-follower (MPC lateral, PID longitudinal) on an Arm safety-class processor
-and exchanges control commands with Autoware over DDS. No changes to the
-Autoware codebase are required.
+A standalone application that runs Autoware's trajectory follower (MPC
+lateral, PID longitudinal) on an Arm safety-class processor and exchanges
+control commands with Autoware over DDS. The application runs on **Zephyr
+RTOS** (production target) or a **FreeRTOS POSIX simulator** (development
+and testing). No changes to the Autoware codebase are required.
 
 ### Workflow
 

documentation/changelog.rst

@@ -34,6 +34,15 @@ New features
 - AVH deployment flow via ``avh.py``, using the
   ``aem8r64-lan9c111`` instance flavor.
 - Simplified top-level ``build.sh`` replaces the previous multi-step build.
+- Platform abstraction layer (``actuation_module/include/platform/``) with
+  Zephyr and FreeRTOS backends, keeping controller logic fully shared.
+- FreeRTOS POSIX simulator build (``actuation_module/freertos/``) using
+  FreeRTOS-Kernel V11.1.0, buildable on any Linux host.
+- CI pipeline (``build-ci.yml``) verifying both Zephyr (FVP) and FreeRTOS
+  simulator builds on every pull request and daily.
+- Release workflow (``release.yml``) publishing ``zephyr-fvp.elf``,
+  ``zephyr-s32z.elf``, ``actuation_freertos``, and ``sha256sums.txt`` on
+  every ``v*.*.*`` tag.
 
 Changed
 =======
@@ -43,8 +52,12 @@ Changed
   application.
 - Replaced the ROS 2-based *Message Converter* and *Actuation Player* with
   direct DDS communication and integrated control logic.
-- The project is now a standalone Zephyr application with Autoware libraries
-  linked in.
+- ``network_config`` refactored from a header-only implementation to a
+  proper declaration (``include/common/dds/network_config.hpp``) and
+  Zephyr-only source file (``src/common/dds/network_config.cpp``), guarded
+  by a compile-time error if included in non-Zephyr builds.
+- Devcontainer image moved to
+  ``ghcr.io/autowarefoundation/autoware-safety-island:devcontainer``.
 
 Third-party repositories
 ========================

documentation/design/architecture.rst

@@ -7,9 +7,12 @@
 Architecture
 ##############
 
-The safety island runs a single Zephyr application that hosts the Autoware
-trajectory follower and talks to the main compute over DDS. This page
-describes how the pieces fit together at runtime.
+The safety island hosts the Autoware trajectory follower and talks to the
+main compute over DDS. This page describes how the pieces fit together at
+runtime on the Zephyr backend. The controller logic is shared across
+backends via a platform abstraction layer
+(``actuation_module/include/platform/``); a FreeRTOS POSIX simulator uses
+the same core with a different backend under ``include/platform/freertos/``.
 
 ************************
 Two-domain DDS topology
@@ -95,9 +98,9 @@ hides Zephyr specifics behind small interfaces:
 - ``clock/clock.hpp`` — monotonic clock, optional SNTP-backed wall clock.
 - ``logger/logger.hpp`` — throttled logging.
 
-This layering is what makes the forward-looking
-:doc:`freertos_porting_plan` feasible: replacing the RTOS backend is a
-question of swapping these four headers, not rewriting the controller.
+This layering means replacing the RTOS backend is a question of swapping
+these four headers, not rewriting the controller. The FreeRTOS backend
+under ``include/platform/freertos/`` demonstrates this in practice.
 
 ****************
 Build pipeline

documentation/design/freertos_porting_plan.rst

@@ -16,4 +16,3 @@ Runtime design, DDS topic contracts, and forward-looking design work.
 
    architecture
    topics
-   freertos_porting_plan

documentation/design/index.rst

@@ -7,12 +7,18 @@
 Overview
 ##########
 
-The Autoware Safety Island is a Zephyr RTOS application that runs Autoware's
+The Autoware Safety Island is an actuation module that runs Autoware's
 trajectory follower on an Arm safety-class processor. It consumes planning,
 localization, and vehicle-state topics from the Autoware main compute, runs
 MPC lateral and PID longitudinal control, and publishes control commands back
 out over DDS. No changes to the upstream Autoware codebase are required.
 
+The module runs on **Zephyr RTOS** for production hardware targets (FVP,
+NXP S32Z). A **FreeRTOS POSIX simulator** build is also available for
+development and integration testing on Linux. A platform abstraction layer
+(``actuation_module/include/platform/``) keeps the controller logic shared
+between both backends.
+
 The main compute and the safety island run on separate DDS domains. A
 domain bridge on the main compute forwards the relevant topics between them,
 which isolates the real-time controller from the rest of the Autoware graph.