Skip to content

fix: recognize FPApp tooling in scope checks - #665

Merged
ArthurGibert merged 3 commits into
ATOVproject:mainfrom
thorinside:fix/fpapp-scope-classifier
Sep 4, 2026
Merged

ArthurGibert merged 3 commits into
ATOVproject:mainfrom
thorinside:fix/fpapp-scope-classifier

Conversation

@thorinside

Copy link
Copy Markdown
Contributor

Category

  • New app
  • App fix
  • Firmware core
  • Configurator
  • Protocol (libfp)
  • Docs
  • CI / tooling
  • Other (explain below)

Type

  • Fix
  • Feature
  • Refactor
  • Docs
  • Chore

Description

The PR scope check currently treats two planned first-party directories as if
they were unrelated projects:

  • fpapp/, the command-line package builder;
  • fpapp-sdk/, the small ABI facade used by native community apps.

That makes the scope report misleading before it has even looked at the code.
This focused prerequisite teaches the classifier what those directories mean.
The builder is classified as project tooling, while the SDK is classified with
the shared protocol surface because changing it affects both firmware and apps.

This PR does not add the FPApp runtime or change the firmware. It only makes
the existing review gate understand the new first-party areas. Keeping this
separate means the classifier change can be reviewed and merged on its own,
before the larger feature PR.

The contributor table now says the same thing as the script, and a synthetic
fixture protects both paths from regressing back to “unrecognized.”

Scope acknowledgement

  • I've read CONTRIBUTING.md's PR Scope Categories table. This is a deliberately small CI/tooling correction with matching contributor documentation.

Verification

  • Ran .github/scripts/pr-scope-check.test.sh in Ubuntu 24.04 with GNU Bash, GNU sed, and jq: 17 passed, 0 failed.
  • The new two-directory fixture reports 0 hard failures.
  • Existing accepted and rejected PR fixtures keep their original results.

Teach the pull-request classifier that fpapp is first-party build tooling and fpapp-sdk is part of the shared protocol surface. This keeps future native-app work from being mistaken for an unrelated standalone project.\n\nDocument both directories in the contributor categories and add a Linux-tested regression fixture covering them together.
ArthurGibert and others added 2 commits September 4, 2026 14:28
The soft-flag only fired for App-category PRs, so a PR touching only
libfp/src/** or fpapp-sdk/** got zero soft-flags despite CONTRIBUTING.md's
"always flagged for a manual look" claim. Extend the test harness to assert
on soft-flag content, not just hard-fail count, so this can't regress
silently again.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@ArthurGibert
ArthurGibert merged commit e1b3df8 into ATOVproject:main Sep 4, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants