Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] gem4gov-cli: the compliance regime has no effect on the engine's feature posture — FedRAMP High, IL4 and IL5 print the same list and apply the same engine_features.yaml

Closed
  • Is something wrong?
#190 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
cli, security

Research direction

Start with gem4gov app update-compliance and the onboarding flow, then inspect configure_gemini_enterprise_for_fedramp_high, configure_gemini_enterprise_for_il4, configure_gemini_enterprise_for_il5, and engine_features.yaml. Reproduce the FEDRAMP_HIGH and IL5 commands and compare the returned features maps. Done means the applied feature posture and the regime-specific message agree, whether the regimes receive distinct sets or one shared set is explicitly described.

Written by the indexing model from the issue text.

Description

Bug Gemini - Government Level of Effort - Medium Priority - High

Bug Description

gem4gov app update-compliance and the onboarding flow both branch on the compliance regime, announce a regime-specific set of features that "are not yet authorized for <regime> and must be disabled", and then configure the engine identically.

Two things are the same across all three branches:

  • The message. The 13 printed bullets are byte-identical for FEDRAMP_HIGH, IL4 and IL5; only the regime name in the lead sentence changes.
  • What is applied. configure_gemini_enterprise_for_fedramp_high (:1526), configure_gemini_enterprise_for_il4 (:1642) and configure_gemini_enterprise_for_il5 (:1754) each load the same file and send its map unchanged:
yaml_path = os.path.join(script_dir, 'engine_features.yaml')
with open(yaml_path, 'r') as f:
    engine_features = yaml.safe_load(f)
...
engine_patch_body = { "features": engine_features.get('features'), ... }

There is one engine_features.yaml in the package, and it carries no regime dimension. So the engine's feature posture — including the four disable-* keys — is identical whichever regime the operator picks.

The assistant PATCH in the same functions does diverge by regime (FedRAMP High's updateMask includes customerPolicy; IL5's does not), which shows per-regime behavior is intended somewhere. That is what makes the identical engine feature set look unintended rather than deliberate.

Environment and Deployment Context

  • Stellar Engine Version/Commit: v3.0.0 (f64ce6cd).
  • Deployment Type:
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Medium
    • FedRAMP High
    • FedRAMP Moderate
    • DoD IL4
    • DoD IL5
    • Stand-alone / Custom
  • **FAST Stage (if applicable):
    • Stage 0 (Bootstrap)
    • Stage 1 (Resource Management)
    • Stage 2 (Networking)
    • Stage 3 (Security)

Steps to Reproduce

  1. Run gem4gov app update-compliance --project-id <project> --engine-id <engine-a> --compliance-regime FEDRAMP_HIGH.
  2. Run the same command against a second engine with --compliance-regime IL5.
  3. GET both engines and diff their features maps.

Expected Behavior

Either each regime applies the feature set its own on-screen list describes, or — if the three regimes genuinely share one engine feature set — the tool says so once instead of naming a regime it did not act on.

Actual Behavior

The features maps are identical. Three regime choices produce one posture, announced three different ways.

Relevant Logs and Errors

None. Both runs report success.

Additional Context

The practical impact is that an operator deploying at IL5 is told a specific set of features is being disabled for IL5, and has no way to tell from the tool that the set applied is the FedRAMP High one.

If the sets should differ, this is a missing per-regime capability. If they should not, the messaging asserts a determination the code never makes. Either way the tool's output and its behavior disagree, and an auditor reading the transcript would conclude something the deployment cannot evidence.

Dominant language
HCL
Stars
51
Forks
21
Avg merge
1d 16h
Merged PRs (30d)
30

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/stellar-engine

All issues in google/stellar-engine

Similar issues

More CLI issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.