adding cross-platform summaries and faqs

Author: anupras-mohapatra-arm

content/learning-paths/cross-platform/adler32/_index.md

@@ -12,11 +12,59 @@ learning_objectives:
 
 prerequisites:
     - An Arm computer running Linux with the GNU compiler (gcc) installed.
-    - Visual Studio Code with the GitHub Copilot extension installed. 
+    - Visual Studio Code with the GitHub Copilot extension installed.
+
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-07-02T17:11:56Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: 37b19106fba70423ba8c58f82097d9251f0ae208e882c852f9c4531afcebb46c
+  summary_generated_at: '2026-07-02T17:11:56Z'
+  summary_source_hash: 37b19106fba70423ba8c58f82097d9251f0ae208e882c852f9c4531afcebb46c
+  faq_generated_at: '2026-07-02T17:11:56Z'
+  faq_source_hash: 37b19106fba70423ba8c58f82097d9251f0ae208e882c852f9c4531afcebb46c
+  summary: >-
+    You'll use GitHub Copilot in Visual Studio Code to set up an Adler32
+    checksum project on an Arm Linux system, establish a C baseline, and measure results. First, you'll
+    generate the C implementation, create a test program that validates correctness and records
+    timing for multiple input sizes, and ask Copilot to produce a GCC-based Makefile tuned for
+    a Neoverse N1 target. Then, you'll to build and run the project, verify outputs, and
+    collect timing data. With a working harness and repeatable measurements, you're positioned
+    to introduce Arm Neon intrinsics for the Adler32 hot path and compare behavior against the
+    baseline C version.
+  faqs:
+  - question: What files should exist before building?
+    answer: >-
+      You should have the C implementation (`adler32-simple.c`), a test program (`adler32-test.c`),
+      and a Makefile generated by GitHub Copilot. If a file is missing or named differently, regenerate
+      it using the provided prompts.
+  - question: Which GitHub Copilot mode should I use to generate the code and Makefile?
+    answer: >-
+      Use the Copilot Agent session in VS Code and paste the prompts from the steps. Results vary
+      by model, so minor differences in code or target names are expected.
+  - question: How do I run the tests and verify correctness?
+    answer: >-
+      Use the Copilot-generated Makefile to build and execute the test program. The run should
+      confirm correct checksum results for all listed data sizes before you proceed.
+  - question: What should I check if the GCC build fails on my Arm system?
+    answer: >-
+      Confirm that GCC is installed and that the Makefile’s architecture-specific flags are supported.
+      If a flag is not recognized for your CPU, adjust or remove it and rebuild.
+  - question: What output should I expect when measuring performance?
+    answer: >-
+      The test program measures timing around Adler32 calls on random inputs of 1 kb, 10 kb, 100
+      kb, 1 mb, and 10 mb. You should see per-size timings that you can reuse when evaluating
+      a Neon-based implementation.
+# END generated_summary_faq
 
 author: Jason Andrews
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 

content/learning-paths/cross-platform/automate-mcp-with-testcontainers/_index.md

@@ -17,9 +17,56 @@ prerequisites:
     - Basic familiarity with Python, PyTest, and container concepts
     - Familiarity with the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) specification
 
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-07-02T17:12:52Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: 597877722e5f277e5558e29ecd33878ac2262b70a84a9769325b3c3b0ce06e58
+  summary_generated_at: '2026-07-02T17:12:52Z'
+  summary_source_hash: 597877722e5f277e5558e29ecd33878ac2262b70a84a9769325b3c3b0ce06e58
+  faq_generated_at: '2026-07-02T17:12:52Z'
+  faq_source_hash: 597877722e5f277e5558e29ecd33878ac2262b70a84a9769325b3c3b0ce06e58
+  summary: >-
+    You'll automate integration testing of Model Context Protocol (MCP)
+    servers using PyTest and Testcontainers. First, you'll prepare a Python and Docker environment,
+    verify Docker availability, and run a short Testcontainers example to start a disposable container
+    and execute commands inside it. Then, you'll build a minimal integration test suite for
+    the Arm MCP server, focusing on JSON-RPC 2.0 communication over standard input and output.
+    Finally, you'll add a GitHub Actions workflow to run the tests on every push and pull request
+    using native Arm64 runners with Docker. By the end, you'll have containerized tests that validate
+    MCP server behavior locally and in continuous integration.
+  faqs:
+  - question: How do I know Docker is ready before running the examples?
+    answer: >-
+      Run docker info and confirm it returns configuration details without errors. If it fails,
+      start the Docker daemon and retry.
+  - question: What should I expect when I run the basic Testcontainers example?
+    answer: >-
+      It starts a long-running container, executes a command inside it, and then cleans up when
+      the script ends. Seeing the command output and a clean exit indicates the example worked.
+  - question: How do the integration tests communicate with an MCP server?
+    answer: >-
+      MCP uses JSON-RPC 2.0 over standard input/output, so tests exchange JSON-RPC messages with
+      the server process. When containerized, Testcontainers manages the server lifecycle during
+      each test run.
+  - question: Where can I find a complete reference implementation of the tests?
+    answer: >-
+      A full test implementation is available in the Arm MCP repository under mcp-local/tests/.
+      You can consult those files while building your own suite.
+  - question: Which events should trigger the GitHub Actions workflow, and where is it defined?
+    answer: >-
+      The workflow runs on push and pull_request and is defined at `.github/workflows/integration-tests.yml`.
+      GitHub’s native Arm64 runners include Docker.
+# END generated_summary_faq
+
 author: Neethu Elizabeth Simon
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 

content/learning-paths/cross-platform/avh_cicd/_index.md

@@ -14,9 +14,55 @@ learning_objectives:
 prerequisites:
     - Some familiarity with CI/CD concepts is assumed
 
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-07-02T17:13:33Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: b6a7439a701f6ae09ce8c61f02150a61fa6ecc1151050e903492e16794999676
+  summary_generated_at: '2026-07-02T17:13:33Z'
+  summary_source_hash: b6a7439a701f6ae09ce8c61f02150a61fa6ecc1151050e903492e16794999676
+  faq_generated_at: '2026-07-02T17:13:33Z'
+  faq_source_hash: b6a7439a701f6ae09ce8c61f02150a61fa6ecc1151050e903492e16794999676
+  summary: >-
+    You'll connect Arm Virtual Hardware (AVH) to a GitHub Actions CI/CD
+    workflow for embedded software. First, you'll prepare a GitHub repository by forking an example
+    project, generate a Personal Access Token with permission to update workflow files, and set
+    up an AVH instance using the Arm Virtual Hardware install guide. Then, you'll enable GitHub
+    Actions on the fork and add a self-hosted runner on an AWS host, selecting a Linux image
+    and x64 architecture to match the instance. By the end, the repository is configured to use
+    an AVH-backed self-hosted runner so workflows can drive automated testing and validation for
+    bare‑metal targets.
+  faqs:
+  - question: Which permission should I enable on the GitHub Personal Access Token?
+    answer: >-
+      Enable the token to update GitHub Action workflows. Generate it under **Settings > Developer
+      settings > Personal access tokens** and save it locally.
+  - question: Where do I run the self-hosted runner setup commands?
+    answer: >-
+      Run the commands shown after selecting **New self-hosted runner** on the machine that will host
+      the runner. Use the AWS instance where Arm Virtual Hardware is set up.
+  - question: Which runner image and architecture should I choose?
+    answer: >-
+      Set **Runner image** to **Linux** and **Architecture** to **x64**. This matches the AWS instance as specified
+      in the steps.
+  - question: How do I enable GitHub Actions on my fork?
+    answer: >-
+      Open the Actions tab in your fork. If workflows are disabled, click **I understand my workflows,
+      go ahead and enable them**.
+  - question: How do I verify that the self-hosted runner is available to the repository?
+    answer: >-
+      Open **Settings > Actions > Runners** in the repository and confirm the runner appears in the
+      list. If it doesn't, re-check the setup commands on the instance.
+# END generated_summary_faq
+
 author: Pareena Verma
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 

content/learning-paths/cross-platform/avh_cicd2/_index.md

@@ -15,9 +15,56 @@ prerequisites:
     - This learning path builds on [Integrate Arm Virtual Hardware into CI/CD workflow 1](/learning-paths/cross-platform/avh_cicd/).
     - Valid AWS and GitHub accounts are required
 
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-07-02T17:14:08Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: 251b6edf6a016f9fc73eb35216f56b2001465fbca8253bd7b6e6f9f4afcd25e6
+  summary_generated_at: '2026-07-02T17:14:08Z'
+  summary_source_hash: 251b6edf6a016f9fc73eb35216f56b2001465fbca8253bd7b6e6f9f4afcd25e6
+  faq_generated_at: '2026-07-02T17:14:08Z'
+  faq_source_hash: 251b6edf6a016f9fc73eb35216f56b2001465fbca8253bd7b6e6f9f4afcd25e6
+  summary: >-
+    You'll extend Arm Virtual Hardware (AVH) integration by preparing an AWS account with a CloudFormation
+    stack and connecting it to a forked GitHub repository that runs automated build and validation
+    on AVH. First, you'll fork the `ARM-software/AVH-GetStarted` project, deploy the
+    included CloudFormation template, and configure GitHub Actions with repository secrets. The
+    settings include the AWS region used by the stack and a valid VPC subnet ID obtained from
+    the AWS console. After configuration, you'll run the workflow in GitHub Actions to drive
+    tests on AVH, providing a clear sequence from account setup to automated
+    validation.
+  faqs:
+  - question: How do I get the example project used in this workflow?
+    answer: >-
+      Fork the [repository](https://github.com/ARM-software/AVH-GetStarted/fork) and clone your
+      fork. The example includes a template to help set up your AWS account and documentation
+      for the CI workflow.
+  - question: What do I need to complete in AWS before adding GitHub secrets?
+    answer: >-
+      Deploy the CloudFormation stack using the template provided in the example project. After
+      creating the stack, proceed to define the repository secrets in GitHub.
+  - question: Which value should I use for `AWS_DEFAULT_REGION`?
+    answer: >-
+      Use the same AWS Region where you created the CloudFormation stack. The region must match
+      for the workflow to reference the correct resources.
+  - question: How do I find the `AWS_SUBNET_ID` required by the workflow?
+    answer: >-
+      In the AWS console, go to **VPC > Subnets** and select any valid Subnet ID. Copy that ID into
+      the `AWS_SUBNET_ID` repository secret.
+  - question: Where do I add the required secrets in GitHub, and do names matter?
+    answer: >-
+      In your forked repository, go to **Settings > Secrets > Actions**, then choose **New repository
+      secret**. The secret names must match exactly as specified in the Learning Path.
+# END generated_summary_faq
+
 author: Pareena Verma
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 

content/learning-paths/cross-platform/aws-greengrass-pacbti-test/_index.md

@@ -19,11 +19,58 @@ prerequisites:
     - An NVIDIA Jetson Thor device running JetPack 7.1 or later
     - Familiarity with AWS IoT Core and basic cloud concepts
 
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-07-02T17:15:02Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
+  summary_generated_at: '2026-07-02T17:15:02Z'
+  summary_source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
+  faq_generated_at: '2026-07-02T17:15:02Z'
+  faq_source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
+  summary: >-
+    This Learning Path guides you through registering a Raspberry Pi 5 and an NVIDIA Jetson Thor
+    as AWS IoT Greengrass core devices, building a custom component that checks for Arm Pointer
+    Authentication (PAC) and Branch Target Identification (BTI), and deploying it to both devices
+    using a Greengrass thing group. The Raspberry Pi 5 (Armv8.2-A) acts as the negative comparison
+    platform, while the Jetson Thor (Armv9-A) provides the positive case. After uploading the
+    component artifact to Amazon S3 and completing the deployment, you use MQTT to trigger the
+    checks and compare results, confirming the expected difference in PAC/BTI support.
+  faqs:
+  - question: How do I know both devices are ready before I create the deployment?
+    answer: >-
+      Check that each device is set up as an AWS IoT Greengrass core device and added to the thing
+      group you plan to target (for example, My_PAC_BTI_Test_Devices). If both appear when selecting
+      the group during deployment creation, you are ready to proceed.
+  - question: Which device should report PAC/BTI support after the test runs?
+    answer: >-
+      Jetson Thor (Armv9-A) should report support for both PAC and BTI. Raspberry Pi 5 (Armv8.2-A)
+      should report that neither feature is supported.
+  - question: What should I check after uploading the component artifact to Amazon S3?
+    answer: >-
+      Confirm the bucket exists and that the artifact file appears in the bucket. Ensure you reference
+      the correct bucket and object when creating the custom component.
+  - question: How do I trigger the PAC/BTI check once the deployment is complete?
+    answer: >-
+      Use MQTT as described in the steps to publish the trigger for the component and then review
+      the returned messages. The results indicate PAC/BTI support for each device.
+  - question: What should I check if one device does not produce results after I publish the MQTT
+      message?
+    answer: >-
+      Verify the device is in the selected thing group and that the deployment targeted that group.
+      If the device is not set up as a Greengrass core device, complete that setup and redeploy.
+# END generated_summary_faq
+
 author:
     - Varun Chari
     - Doug Anson
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 
@@ -72,3 +119,4 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
+

content/learning-paths/cross-platform/build-a-reachy-robot-app-on-pi/_index.md

@@ -22,9 +22,57 @@ prerequisites:
     - Basic Python and Bash terminal experience.
     - (Optional) [Reachy Mini](https://huggingface.co/reachy-mini)
 
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-07-02T17:15:58Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
+  summary_generated_at: '2026-07-02T17:15:58Z'
+  summary_source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
+  faq_generated_at: '2026-07-02T17:15:58Z'
+  faq_source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
+  summary: >-
+    This Learning Path guides you to build a distributed edge AI application where a Raspberry
+    Pi 5 performs on-device gesture recognition with MediaPipe and TensorFlow Lite and sends commands
+    to a Reachy Mini robot running in a MuJoCo simulation on a development machine. You set up
+    the Pi, enable Git LFS to retrieve the gesture model, run the app, and open a browser dashboard
+    on port 8042 to deliver thumbs-up or thumbs-down verdicts that trigger Reachy’s reactions.
+    The steps explain how the Pi connects to the robot daemon over the network and how to operate
+    the dashboard, then walk through the code structure that separates perception, logic, robot
+    motion, and static assets so you can extend or adapt the project.
+  faqs:
+  - question: I cloned the project but the gesture model file is tiny—did Git LFS work?
+    answer: >-
+      Verify that you installed and enabled Git LFS before cloning. Re-clone with LFS enabled
+      and check that assets/gesture_recognizer.task is a large binary file, not a small text pointer.
+  - question: The dashboard doesn’t open at http://localhost:8042—what should I try?
+    answer: >-
+      If you use VS Code Remote SSH, confirm that port forwarding is active. Otherwise, open http://<pi-ip-address>:8042
+      from a browser on the same network and make sure the app is running on the Raspberry Pi.
+  - question: How do I know the Raspberry Pi is connected to the MuJoCo simulation?
+    answer: >-
+      When you show a thumbs-up or thumbs-down, the simulated Reachy Mini should perform the corresponding
+      victory or defeat reaction. If nothing happens, check that both machines are on the same
+      network and that the connection settings in main.py point to the correct host.
+  - question: Can I run the Raspberry Pi headless for this app?
+    answer: >-
+      Yes. Open the dashboard from another machine using the Raspberry Pi’s IP address and port
+      8042; the Pi does not need a local display.
+  - question: Where do I change gesture handling or robot moves in the code?
+    answer: >-
+      Edit gesture.py to adjust recognition or mapping and moves.py to change motion routines.
+      Use main.py to wire the app and update the settings used for the distributed simulation
+      route.
+# END generated_summary_faq
+
 author: Matt Cossins
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 
@@ -75,3 +123,4 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
+