fix(helm): move name validation from audit to testing phase

Audit checklist should only check hardcoded namespaces and required+default conflicts.
Resource names are not violations — they depend on subchart implementation and must be
tested via helm template, not audited via grep.

Testing Templates section rewritten:
- require testing with at least 2 different release names and namespaces
- verify resource names, labels, selectors linkage works correctly in both
- verify manifest links (Service → Deployment) use correct names/namespaces
- this is how you validate chart portability, not via code inspection

IaC principle clarified:
- chart must be deployable to any cluster/namespace without editing
- deployment discipline prevents two instances in same cluster/namespace
- not a chart constraint, a deployment constraint

.ai/instructions/skills/helm.instructions.md

@@ -21,17 +21,6 @@ namespace: {{ .Values.something }}
 ```
 is a violation.
 
-### Hardcoded resource names
-Search `templates/` for name values that are plain strings — not using `.Release.Name` or `include`:
-
-```
-grep -r "name:" templates/
-```
-
-Flag names like `name: my-app`, `name: myapp-ingress` — anything that does not derive from `.Release.Name` or a fullname helper. The only allowed exception is `fullnameOverride` in the glue configuration pattern (documented below), which must be explicitly commented.
-
-**Do not flag hardcoded names in `values.yaml`.** `values.yaml` is not rendered through the template engine — `{{ .Release.Name }}` expressions are not evaluated there. Fixed names in values.yaml for subchart coordination are a legitimate pattern (see Glue Configuration below).
-
 ### Required values with empty defaults
 Search for `required` calls paired with a fallback default in values.yaml:
 
@@ -134,9 +123,11 @@ name: {{ .Release.Name }}-service
 
 The chart is infrastructure code. It must be deployable to any cluster, any namespace, any environment, by any deployer — without editing the chart itself. Installation-specific decisions belong exclusively in `values.<installation>.yaml` in the deployment repo.
 
+**In practice:** In umbrella charts, you typically deploy each release to a different namespace, or at most two instances to separate clusters. You never deploy two instances of the same umbrella to the same cluster and namespace — that would be a misconfiguration. This constraint is not enforced by the chart; it is part of the deployment discipline.
+
 ```
 ❌ Wrong: chart decides where it lives
-✅ Right: deployer decides where it lives — chart only describes what it is
+✅ Right: deployer decides where it lives — chart describes what it is
 ```
 
 ---
@@ -412,18 +403,32 @@ resources:
 
 ---
 
+---
+
 ## 🧪 Testing Templates
 
-Standard verification command:
+Always test with at least two different release names and namespaces. This verifies that resource references, names, and dependencies work correctly regardless of where the chart is deployed.
 
 ```bash
-helm template <release-name> . \
+# Test 1: release=app1, namespace=default
+helm template app1 . \
+  --namespace default \
+  --set global.key=value \
+  ... \
+  2>&1 | grep "^kind:" | sort | uniq -c
+
+# Test 2: release=app2, namespace=production
+helm template app2 . \
+  --namespace production \
   --set global.key=value \
   ... \
   2>&1 | grep "^kind:" | sort | uniq -c
 ```
 
 Verify:
-- Expected resource kinds appear
+- Expected resource kinds appear in both tests
+- Resource names, labels, and selectors are correctly formed using `.Release.Name` or `.Release.Namespace`
+- Manifest links between resources (e.g. Service → Deployment) use the correct names and namespaces
 - No `Error:` lines
 - `required` validation fires when values are missing
+