Good First Issues in Mustache

What is wrong The spec "'hostport_not_used' should fail when a host port is being used" (spec/workload/configuration_spec.cr) installs sample-cnfs/sample_hostport: a full Helm chart of a UniFi controller (jacobalberty/unifi:5.12.35, a Java application with an embedded database, 17 files). The test only reads the hostPort of the Deployment in the manifest, so none of that application is needed. #2676 made the spec stop waiting for the application to become ready, after it once did not start at all (#2669). The heavy image is still pulled on every run, and this is the only spec that uses the fixture. Proposal Replace the fixture with a minimal one, next to the existing bare-Pod fixture sample-cnfs/sample-hostport-pod: A manifests deployment with one Deployment (so the test's path through spec.template stays covered) whose container declares a hostPort, using a small image such as busybox running sleep, as sample-hostport-pod does. Its own namespace labelled pod-security.kubernetes.io/en

What is missing The specs test a failing cnf_install with a broken config file (spec/fixtures/sample-bad-config.yml) and with a config path that does not exist. No spec covers a config that is valid and names a chart the repository does not have. That path has code of its own: helm_deployment_manager.cr pulls the chart with Helm.pull, which retries (NetRetry.with_retries), and reports "Helm pull failed for deployment ..." when it gives up. Nothing exercises it. Background The fixture sample-cnfs/sample-coredns-cnf-bad-chart was made for this case (chart name corsdsdsdedns), but no spec used it. It is removed with the other unused fixtures in #2673. Proposal A spec in spec/setup_spec.cr that installs a config with a chart name that does not exist, with expect_failure: true, and asserts: the exit code of a failed command; the message names the deployment and the chart; nothing is left behind that makes the next cnf_install refuse to run (related: #2332). How long the retries take befor

The anonymized buyer email ([email protected]) was previously returned by default in the Orders API v0 getOrders and getOrder responses without requiring a Restricted Data Token (RDT) or any restricted roles. This field has been silently removed from the response with no deprecation notice or entry in the SP-API Release Notes. What changed Before: BuyerEmail (e.g. [email protected]) was returned in every order response — both FBA and FBM — without RDT and without any restricted roles. Now: The field is no longer returned in either the v0 or v2026-01-01 API, regardless of whether includedData=BUYER is specified. Why this is a problem No deprecation notice. The SP-API Release Notes contain no mention of this change. The field was removed without any advance warning. Not actual PII. The buyerEmail field is Amazon's own anonymized relay address (@marketplace.amazon.com), not the customer's real email. It cannot be used to identify the buyer. Gating