If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/nasa/fprime shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2d ago
• 27+ active contributors
• Distributed ownership (top contributor 28% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live nasa/fprime repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nasa/fprime.

What it runs against: a local clone of nasa/fprime — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in nasa/fprime | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch devel exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of nasa/fprime. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/nasa/fprime.git
#   cd fprime
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of nasa/fprime and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "nasa/fprime(\\.git)?\\b" \\
  && ok "origin remote is nasa/fprime" \\
  || miss "origin remote is not nasa/fprime (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify devel >/dev/null 2>&1 \\
  && ok "default branch devel exists" \\
  || miss "default branch devel no longer exists"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f ".github/workflows/build-test.yml" \\
  && ok ".github/workflows/build-test.yml" \\
  || miss "missing critical file: .github/workflows/build-test.yml"
test -f "Drv/AsyncByteStreamBufferAdapter/AsyncByteStreamBufferAdapter.fpp" \\
  && ok "Drv/AsyncByteStreamBufferAdapter/AsyncByteStreamBufferAdapter.fpp" \\
  || miss "missing critical file: Drv/AsyncByteStreamBufferAdapter/AsyncByteStreamBufferAdapter.fpp"
test -f "CFDP/Checksum/Checksum.hpp" \\
  && ok "CFDP/Checksum/Checksum.hpp" \\
  || miss "missing critical file: CFDP/Checksum/Checksum.hpp"
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/nasa/fprime"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

F´ (F Prime) is a component-driven flight software framework originally developed at NASA's JPL that enables rapid development of spaceflight and embedded systems applications through discrete components with well-defined interfaces, automatic code generation from FSM/component models, and built-in testing/telemetry tools. It has been flight-proven on multiple NASA space missions and is tailored for resource-constrained platforms like CubeSats and SmallSats. Monorepo structure: Fw/ contains core framework libraries (message queues, threading, serialization), Utils/ provides utility functions, Drv/ contains driver abstractions, ROS/, Zephyr/, and platform-specific dirs enable cross-platform deployment. Code generation happens via Python tools (inferred from .github/actions/cookiecutter-check) that consume FSM/XML component definitions and emit C++ stubs. Examples and reference implementations live in project subdirectories (referenced in ext-build-*.yml workflows).

Flight software engineers and embedded systems developers at aerospace organizations and research institutions who need to build reliable, testable spacecraft and instrument software with rapid iteration cycles and automatic code generation from architecture models rather than manual integration.

Production-ready and actively maintained: this is a NASA/JPL-backed open-source project with 6+ years of active development (since ~2018), successfully deployed on multiple space missions, comprehensive CI/CD pipelines (CodeQL, cppcheck, cpplint workflows), extensive test coverage via CMake/Python testing, and recent commits visible in workflow configurations. The codebase is large (6.2M+ lines of C++) with structured governance and contributor guidelines.

Low risk for aerospace use but moderate risk for new adopters: the framework is stable and flight-proven but has a steep learning curve with many domain-specific abstractions (component models, FSM generation). Dependency risk is mitigated by being primarily self-contained C++ with Python tooling; however, the build system complexity (CMake-heavy) and multi-language stack (C++/Python/Fortran/CMake) means infrastructure expertise is required. Single point of failure: JPL is the primary maintainer.

Active ongoing work visible in workflows: Zephyr RTOS integration for Pico2 and Teensy41 (ext-fprime-zephyr-reference-*.yml), CI modernization and security scanning (codeql-jpl-standard.yml, security-pack), cookiecutter template maintenance for project generation, and external example/reference implementation building (ext-build-hello-world.yml, ext-build-math-comp.yml). Recent focus on embedded ARM platforms and expanded platform support.

pip install fprime-bootstrap
fprime-bootstrap project
cd <your-project>
cd build
cmake ..
make

Then follow the HelloWorld Tutorial at https://fprime.jpl.nasa.gov/latest/tutorials-hello-world/docs/hello-world/

Daily commands: Development workflow: cd build && cmake .. && make for native builds, or use platform-specific CMake configurations in .github/workflows/build-test*.yml. For projects: fprime-util build (Python wrapper around CMake). Testing: make test or ctest in build directory.

• CMakeLists.txt — Root build configuration; all contributors must understand the F´ build system and component dependencies.
• .github/workflows/build-test.yml — Primary CI/CD pipeline that validates builds across platforms; essential for understanding the test and release process.
• Drv/AsyncByteStreamBufferAdapter/AsyncByteStreamBufferAdapter.fpp — Exemplifies F´'s FPP modeling language for component interfaces; critical for understanding architecture and code generation.
• CFDP/Checksum/Checksum.hpp — Core flight software utility component; demonstrates F´'s C++ component design patterns and interface conventions.
• .github/copilot-instructions.md — Documents F´ coding standards and conventions; ensures all contributions follow framework idioms.
• CONTRIBUTING.md — Outlines contribution workflow, testing requirements, and code review expectations for the project.
• CODE_OF_CONDUCT.md — Establishes community standards and behavioral expectations for all contributors.

Add a New Component

1. Create a new directory under Drv/ (or other appropriate subsystem) with your component name. (Drv/MyNewComponent/)
2. Define the component interface in FPP: specify ports, commands, telemetry, and events. (Drv/MyNewComponent/MyNewComponent.fpp)
3. Implement the C++ class in the corresponding .hpp and .cpp files, inheriting from Fw::ActiveComponent or Fw::PassiveComponent. (Drv/MyNewComponent/MyNewComponent.hpp)
4. Create a CMakeLists.txt to define compilation rules and FPP code generation targets. (Drv/MyNewComponent/CMakeLists.txt)
5. Write unit tests in test/ut/ using F´'s testing harness pattern (e.g., MyNewComponentTester.hpp). (Drv/MyNewComponent/test/ut/MyNewComponentTester.hpp)
6. Register the new component in the root CMakeLists.txt via add_subdirectory() so it builds in the full system. (CMakeLists.txt)

Add a New Utility or Library

1. Create a new subdirectory (e.g., CFDP/MyUtility/) containing your reusable code. (CFDP/MyUtility/)
2. Implement the utility with .hpp (interface) and .cpp (implementation) files following F´ naming conventions. (CFDP/MyUtility/MyUtility.hpp)
3. Create a CMakeLists.txt defining the library target and any dependencies (e.g., linking to framework core). (CFDP/MyUtility/CMakeLists.txt)
4. Add unit tests in a GTest/ subdirectory (e.g., GTest/MyUtilityTest.cpp) and register in the CMakeLists.txt. (CFDP/MyUtility/GTest/MyUtilityTest.cpp)

Integrate a New Test Workflow

1. Create a new .yml file in .github/workflows/ defining the trigger (e.g., on push, pull_request, schedule). (.github/workflows/my-custom-test.yml)
2. Use the reusable project builder or CI workflows as templates (e.g., reusable-project-ci.yml) to avoid duplication. (.github/workflows/reusable-project-ci.yml)
3. Define build steps that invoke CMake with appropriate presets (from CMakePresets.json) and run test executables. (CMakePresets.json)
4. Add the workflow to the repository settings to ensure it runs and publishes results (e.g., to GitHub Checks). (.github/workflows/my-custom-test.yml)

• C++ (C++11/14/17) — Provides low-overhead abstractions and deterministic performance required for spaceflight software with strict resource constraints.
• CMake — Multi-platform build orchestration essential for deploying to diverse hardware (CubeSats, SmallSats, embedded boards, desktop simulation).
• FPP (F´ Property Platform) Modeling Language — Domain-specific language enables declarative component interfaces and automatic code generation, reducing boilerplate and human error in flight software.
• Google Test (GTest) — Industry-standard unit test framework integrated into the component test harness for validating behavior before flight deployment.
• GitHub Actions — Continuous integration on every push validates code quality, security, and cross-platform compatibility without external CI infrastructure.

• Component-based architecture with FPP code generation

  • Why: Reduces integration bugs and human error by enforcing interface contracts upfront, critical for flight-critical software.
  • Consequence: Requires learning FPP syntax and understanding generated code patterns; initial onboarding steeper than monolithic frameworks.

• Multi-platform C++ with active/passive component threading models

  • Why: Enables real-time concurrency on small satellites and deterministic scheduling for safety-critical tasks.
  • Consequence: Developers must manage threads, message queues, and race conditions; not suitable for rapid prototyping without domain knowledge.

• CMake-based build with code generation step

  • Why: Enables platform-specific optimizations and integrates FPP→C++ compilation seamlessly.
  • Consequence: Build configuration more complex than simple makefile; requires CMake expertise to extend.

• Monolithic open-source repository with all components and utilities

  • Why: Simplifies version management and ensures compatibility across all components shipped together.
  • Consequence: Large repo (600 files) can be slow to clone; developers only needing a subset must download everything.

• Real-time operating system (RTOS) provision: F´ layers on top of POSIX/FreeRTOS; does not provide kernel-level scheduling.
• Application-level security (encryption/signing): CFDP checksum is data integrity only; cryptography integration is left to mission-specific layers.
• Web or cloud deployment: Framework targets embedded systems; no HTTP server, cloud API client, or distributed consensus built-in.
• Dynamic component loading: Components and connections are compile-time defined; no plugin or hot-reload mechanism.
• Non-C++ language support: Framework is C++ native;

1. Component port connections are type-checked at compile-time: mismatched port signatures cause hard CMake errors, not runtime issues. 2. FSM/component model code generation is opaque: generated C++ is not meant for human editing; modify the XML/FSM definitions instead. 3. Multi-threaded message queue semantics: ActiveComponentBase uses queue-based scheduling; blocking operations on one component can starve the dispatcher. 4. Cross-compilation requires platform-specific CMake toolchain files: see .github/workflows/ext-aarch64-linux-led-blinker.yml for Arm setup; defaults to native compilation. 5. Telemetry/command IDs must be globally unique across entire mission in the generated code; namespace collisions cause silent data corruption. 6. Python version lock: requires 3.10+ per README; earlier versions have incompatible syntax in code generation tools.

• Active Component Pattern — F´'s core abstraction for concurrent software: each component runs in its own thread with a message queue, enabling you to reason about component behavior independently without explicit locks. Understanding this is mandatory for architecting any F´ system.
• Typed Port-Based Communication — F´ enforces type-safe component interfaces via typed input/output ports (similar to strongly-typed event systems); prevents silent data corruption from mismatched component connections at compile time rather than runtime.
• Finite State Machine Code Generation — F´ tools auto-generate boilerplate C++ command handlers and state transitions from XML/FSM definitions; this eliminates a major source of bugs in spacecraft software (manual state handling) and speeds up development dramatically.
• Serialization/Deserialization Ports — F´ abstracts binary telemetry and command encoding via Fw/Svc ports, allowing you to swap serialization formats (protobuf, CCSDS, custom binary) without changing component logic — critical for ground compatibility.
• Time-Tagged Event Logging — Every component event is automatically timestamped and logged; essential for post-mission analysis of spacecraft anomalies. F´'s Fw/Log ports integrate this without cluttering component code.
• Command/Telemetry Dichotomy — F´ strictly separates uplink (commands to spacecraft) from downlink (telemetry from spacecraft) via different port types and middleware; this mirrors real mission operations architectures and enables ground-independent component testing.
• Cross-Platform Build Abstraction via CMake — F´ projects compile identically on Linux, macOS, and cross-compile to ARM/Zephyr/RTOS via CMake platform configurations; this is non-trivial for embedded systems and F´'s CMake layers (seen in .github/workflows/) handle it transparently.

• nasa/cFE — Core Flight Executive is an alternative NASA flight software framework focused on modular app architecture; F´ diverged to add component-based design and code generation for smaller spacecraft
• PX4/PX4-Autopilot — Open-source autopilot framework for drones/UAVs that uses similar component/module architecture patterns but without the code generation and FSM modeling tools that F´ provides
• ArduPilot/ardupilot — Alternative embedded flight control software with less rigid architecture; F´'s framework enforces stricter component isolation and testing discipline that ArduPilot does not require
• nasa/fprime-tutorials — Official companion repo containing example projects and step-by-step guides; essential for learning F´'s workflow beyond the README
• nasa/fprime-gds — Ground Data System companion tool for F´ that provides GUI, telemetry visualization, and command transmission; required for full mission operations workflows

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add CMake-based build testing for CFDP module

The CFDP directory has a CMakeLists.txt but there's no dedicated GitHub Actions workflow testing the CFDP subsystem in isolation. Given that F´ has flight-critical CFDP (Consultative Committee for Space Data Systems) Protocol implementation, a dedicated CI workflow would catch regressions early. This is especially important since CFDP is used in space applications.

• [ ] Review CFDP/CMakeLists.txt and CFDP/Checksum/CMakeLists.txt to understand build requirements
• [ ] Create .github/workflows/cfdp-build-test.yml that builds CFDP components independently
• [ ] Add unit test execution for any CFDP test files (check CFDP directory for test/ subdirectories)
• [ ] Ensure workflow runs on pushes to CFDP/* paths to catch changes early

Implement spell-check validation for API documentation in Markdown files

The repo has sophisticated spelling checks (.github/actions/spelling/) but the allow.txt, reject.txt, and patterns.txt files appear to lack domain-specific technical terms common in aerospace/F´ (e.g., telemetry, commanding, component, port, topology patterns). Add flight-software-specific terminology to improve spell-check accuracy and reduce false positives for contributors.

• [ ] Audit .github/actions/spelling/allow.txt for missing F´-specific terms (components, ports, telemetry, commands, topology, etc.)
• [ ] Add aerospace/embedded systems terminology to the allow list
• [ ] Update .github/actions/spelling/patterns.txt to handle camelCase component names and FPP language keywords
• [ ] Run spelling.yml workflow locally to validate no regressions in existing documentation

Add integration test workflow for cross-platform example builds (Linux-ARM, macOS, RHEL8)

The repo has individual build workflows for macOS (.github/workflows/build-test-macos.yml) and RHEL8 (.github/workflows/build-test-rhel8.yml), but no unified workflow testing example projects across all platforms. The ext-* workflows test external projects but not F´'s own example deployments. Create a reusable workflow that validates example projects build on all three major platforms using the existing reusable-project-builder.yml.

• [ ] Review .github/workflows/reusable-project-builder.yml to understand the build matrix pattern
• [ ] Create .github/workflows/examples-cross-platform-test.yml that runs against examples/ directory (if it exists) or identified example projects
• [ ] Define matrix for: Ubuntu (x86_64), macOS (x86_64/ARM64), RHEL8 to catch platform-specific build issues
• [ ] Ensure workflow uses the setup action from .github/actions/setup/action.yml for consistency

• Add CMake configuration examples for Cortex-M4 targets (STM32): the repo has Zephyr examples for Pico2/Teensy41 but lacks mainstream microcontroller doc; create a reference build directory with working CMakeLists.txt for STM32CubeMX integration.
• Extend the HelloWorld tutorial with a 'Adding a Custom Telemetry Channel' section: the tutorial (referenced in README) covers basic project creation but skips the common task of defining and transmitting custom telemetry; add step-by-step example to docs/tutorials/.
• Add static assertion tests for component port type safety: currently port mismatch errors are caught at CMake configure time (verbose); create a C++ test in Fw/Port/test/ that demonstrates proper error messages to help developers diagnose connection failures faster.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.