[lestarch-autobot]

Describe the contribution
Bumps all submodule pointers to the latest upstream HEADs:

• libs/fprime: fb21595 -> d739002 (nasa/fprime devel; includes #5488 restoring the ActiveRateGroup::ContextArray API and the FPP v3.3.0a13 bump #5532). This fixes the current devel CI compile failure (ContextArray missing from the previously pinned fprime).
• libs/fprime_cfs: ea0a8f8 -> 78654ee (CfsBridge cleanup, CfsBridge cleanup: remove debug logging, member naming, named packet-length offset fprime_cfs#12)
• apps/fprime_app: 4032403 -> c27da5e (SCH tick rate groups Bump fprime_cfs to latest devel (SDDs, unit tests, CI workflow) #6 + cleanup Cleanup: remove debug printfs, check subscribe statuses, accurate deployment README fprime_app#7)
• apps/fprime_gds: 1d9f7c9 -> 31ea2b7 (cleanup Cleanup: remove debug printfs, table-driven subscriptions with status checking, accurate README fprime_gds#4)

Testing performed

1. pip install -r libs/fprime/requirements.txt (FPP v3.3.0a13), then make SIMULATION=native prep && make && make install — clean build with these pins.
2. Ran core-cpu1 with the F Prime GDS attached and pytest test/int: 5/5 pass when the SCH app (Add real cFS SCH app driving the F Prime rate groups at 1 Hz #9) is merged in locally. Without Add real cFS SCH app driving the F Prime rate groups at 1 Hz #9 the integration tests cannot pass, since fprime_app now derives rate group ticks from SCH messages — this PR should land together with (or after) Add real cFS SCH app driving the F Prime rate groups at 1 Hz #9.

Expected behavior changes

• Behavior Change: fprime_app rate groups are driven by cFS SCH ticks (from the fprime_app Bump fprime_cfs to latest devel (SDDs, unit tests, CI workflow) #6 pin); subscribe failures in both apps are now reported via EVS error events.

System(s) tested on

• Hardware: PC (x86_64)
• OS: Ubuntu 22.04 (SIMULATION=native)
• Versions: cFE/OSAL/PSP pins unchanged; fprime d739002; fprime_cfs 78654ee; fprime_app c27da5e; fprime_gds 31ea2b7

Additional context
Depends on #9 (SCH app) for green integration-test CI.

Contributor Info
Michael Starch, NASA JPL (via Devin AI session)

[lestarch-autobot]

[Documentation] must fix README.md "Running the Reference" / "Running the F Prime GDS" are now stale: this pin makes fprime_app rate groups depend on cFS SCH tick messages, but no SCH app exists in this repo (cpu1_cfe_es_startup.scr starts only fprime_gds/fprime_app) and README never mentions the SCH prerequisite.

(Anchored on the submodule bump; README.md is not in the PR diff.) Following the README as written now yields a system with no rate-group execution or periodic telemetry — an instruction set that no longer works. README (and its mermaid diagram) should document the SCH app dependency, or note it is pending PR #9.

cc @LeStarch @thomas-bc — low-confidence finding, please confirm.

[lestarch-autobot]

[Security] could fix Ground-injectable SCH ticks can drive the rate groups (finding-class: ground-overflow-or-ddos).

The fprime_app pin (c27da5e) wires ComCcsds.fprimeRouter.cfsCommandOut -> schAppDriver.cfsCommandIn and routes APID CFS_SCH_TICK (0x0090) via the cFS-command route. Any SB publisher — including a ground-uplinked space packet with APID 0x0090 forwarded to the software bus by CfsBridge::dataIn_handler — produces a rate-group cycle; SchAppDriver validates only the function code, with no rate limiting or source check. Impact is bounded (ActiveRateGroup CycleIn is a drop overflow port, so a flood causes throttled cycle-slip warnings rather than an assert), hence non-blocking. Consider rejecting SCH ticks that arrive via the uplink path, or rate-limiting SchAppDriver::cfsCommandIn.

cc @LeStarch @thomas-bc @bitWarrior — low-confidence finding, please confirm.

[lestarch-autobot]

[Security] future work CfsBridge::poll() forwards a pointer into the cFS SB buffer with flow control off by default (finding-class: general-vulnerability/use-after-free).

poll() wraps the CFE_SB_ReceiveBuffer result in an Fw::Buffer and emits it on dataOut; when configure(..., paused=false) (the default, used by fprime_app) flow control is disabled, so a subsequent CFE_SB_ReceiveBuffer may recycle the SB buffer while a downstream consumer still references it. Safe today only because the downstream chain consumes/copies synchronously. Preexisting behavior — this PR's pin (78654ee) does not change the poll() flow — so recorded as future work.

cc @LeStarch @thomas-bc @bitWarrior — low-confidence finding, please confirm.

[lestarch-autobot]

[Design] must fix Merged ahead of its stated dependency #9, leaving devel in a known-broken state.

The PR description says this pin makes fprime_app derive rate-group ticks from cFS SCH messages and "should land together with (or after) #9", and that integration tests cannot pass without it. #9 is still open, and the merge commit's Build and Integration Tests check on devel is failing (4cd852a). Until #9 lands, the reference deployment's rate groups never fire on devel. Please merge #9 (or revert this pin) to restore a working devel.

[lestarch-autobot]

[Architecture] must fix Rate groups have no tick source at this head: the fprime_app pin drives all rate-group cycles from cFS SCH tick messages, but nothing in this repo publishes them.

The pinned fprime_app (c27da5e) replaces Svc.PollingTimer with FPrimeCfs.SchAppDriver, so rateGroup1 (cmdDisp.run, tlmSend, health, comQueue, aggregator timeout, buffer manager) cycles only when a ComCfg::Apid::CFS_SCH_TICK (0x0090) message arrives via the CfsBridge. fprime_cfs_reference_defs/targets.cmake builds no SCH app (MISSION_GLOBAL_APPLIST fprime fprime_cfs fprime_app fprime_gds), and no SCH app exists under apps/ at this head or on current devel — the rate groups silently never run (arch-rate-group-violation). The PR body documents the dependency on #9, but this merged without it; the SCH app (or another CFS_SCH_TICK publisher) should land as an immediate follow-up.

cc @LeStarch @thomas-bc — low-confidence finding, please confirm.

[lestarch-autobot]

Automated review summary (run 1)

Intended review event: REQUEST_CHANGES (posted as COMMENT — GitHub rejects REQUEST_CHANGES on the PR author's own PR).

Per-agent results

Agent	must fix	suggestion	could fix	future work	outstanding	Verdict
Security Vulnerabilities	0	0	1	1	2	Go
Supply Chain / Runner Safety	0	0	0	0	0	Go
F Prime C/C++ Design	0	0	0	0	0	Go
Documentation Currency	1	0	0	0	1	No-Go
Design	1	0	0	0	1	No-Go
Architecture	1	0	0	0	1	No-Go
Test Quality	0	0	0	0	0	Go
CI safety	—	—	—	—	—	Go
Totals	3	0	1	1	5	No-Go

Supply-chain surfaces

Surface	Outstanding
Dependencies	clean
Vendored / submodule	clean
Build / test infrastructure	clean
Workflows / actions / scripts	clean
Generator output	clean
Prompt-injection	clean
Review-system integrity	clean

Outstanding must-fix items (3)

Documentation Currency

• README "Running the Reference" / "Running the F Prime GDS" now stale: rate groups depend on cFS SCH ticks but no SCH app or README mention exists — #11 (comment)

Design

• Merged ahead of stated dependency #9, leaving devel in a known-broken state (integration tests failing until #9 lands or the pin is reverted) — #11 (comment)

Architecture

• Rate groups have no tick source at this head: fprime_app pin drives cycles from CFS_SCH_TICK messages, but nothing in this repo publishes them — #11 (comment)

Merge readiness

Merge readiness: No-Go — 3 outstanding must-fix items (Documentation Currency, Design, Architecture); the pinned fprime_app depends on the still-open SCH app (#9).

---

All decks report in — one dependency short of a go for launch; land #9 and we fly.