hybridops-tech/hybridops-core

Area Module or blueprint Relevant reference networking/edge-control-plane@v1 Expected behaviour Blueprint validation should reject settings that are not part of the step contract. The error should name the step and the unexpected keys. Observed behaviour The shared_control_host step has firewall_name, ssh_source_cidrs, and firewall_extra_tcp_ports beside inputs rather than inside it. Validation reports status=ok, but those values are dropped from the validated step. Steps to reproduce Run hyops blueprint validate --ref networking/edge-control-plane@v1 --blueprints-root blueprints. Inspect the shared_control_host step in its blueprint.yml. Notice that the three misplaced settings are accepted but never become module inputs. Scope Move the three settings under inputs, reject unknown step-level keys, and add a regression test covering a misplaced input.

Area Module or blueprint Problem tools/ci/check-module-catalog.py checks that each module has a README and examples, but it does not inspect the spec.yml contract itself. A malformed spec, a module_ref that does not match its directory, or an incomplete execution block can pass the catalog check and fail later when the module is resolved. Proposed change Extend the module catalog check so every modules/**/spec.yml file is loaded and checked for: a YAML mapping with kind: ModuleSpec a module_ref matching its path under modules/ the required execution fields: driver, profile, and pack_ref.id a clear error containing the source path and failed field Add focused tests for a valid module, a path/reference mismatch, malformed YAML, and a missing execution field. Keep the check in the existing Python quality path. Acceptance criteria all shipped module specs are checked offline failures identify the module path and field no credentials or live infrastructure are required bash tools/ci/chec

Area Module or blueprint Problem core/onprem/network-sdn currently applies the same SDN ID rule to the zone name, VNet keys, and subnet map keys. After hybridops-tech/terraform-proxmox-sdn#32, the module requires zone and VNet IDs to be 2-8 characters, start with a letter, and contain only letters and digits. Subnet map keys are local keys, not Proxmox SDN object IDs. Core still accepts a one-character zone or VNet ID, and rejects local subnet keys such as subnet_name. Core validation can therefore disagree with the module plan. Proposed change Update the Core validator so zone and VNet IDs use the same 2-8 character boundary as the module. Keep Core's existing lowercase naming policy. Treat subnet map keys as non-empty local keys instead of applying the Proxmox SDN ID rule. Add focused tests for both boundaries. Acceptance criteria one-character zone and VNet IDs fail Core validation existing IDs such as hybzone and vnetmgmt pass a subnet key such as subnet_name passes validation err

Area Preflight, probe, or run record Problem hyops/runtime/redact.py protects text that can end up in logs and run-record evidence. It already handles several common token and secret shapes, but there is no small regression test that proves those cases stay covered. Proposed change Add lightweight regression coverage for the redaction helper. Keep it narrow and easy to run from the existing project tooling. Cover at least these cases: Authorization: Bearer ... token=... and access_token=... JSON-style client_secret password=... environment-style cloud or GitHub tokens already listed in the helper Acceptance criteria A contributor can run the redaction test locally. The test fails if a supported secret shape is no longer redacted. The test does not require real credentials or external services. CI or contributor docs mention the command used to run it.

The release bundle verification path is in place, but the failure output should be easier to act on. If the manifest check fails, the output should point at the actual mismatch instead of forcing the next maintainer to inspect the bundle by hand. The common cases are missing files, unexpected files, and manifest entries that no longer match the generated bundle. Relevant files: pkg/build_release.sh pkg/verify_release.sh pkg/manifest.yml A small test or fixture for one missing file and one unexpected file would be enough to start. Please also include a short note on updating the manifest when a packaging change is intentional. Close this when bundle verification still passes in CI and a manifest mismatch points clearly at the file or entry that needs attention.