fix(advisor): restore architecture finding guidance

Signed-off-by: Carlos Villela <cvillela@nvidia.com>

Author: cv

tools/pr-review-advisor/trusted-guidance.mts

@@ -168,7 +168,7 @@ export function buildSystemPrompt(
     "7. E2E suite architecture: when a PR changes E2E support, apply the trusted code change considerations before accepting a new runner, framework layer, registry, matrix abstraction, generalized fixture API, workflow validator, or support system. Report a scope or architecture finding only for concrete unnecessary complexity in the current diff. Preserve direct tests that exercise real shell or system boundaries.",
     "8. Source-of-truth review: apply the trusted code change considerations to fallback, recovery, tolerant parsing, monkeypatching, best-effort cleanup, compatibility, migration, configuration, and extension behavior. Treat PR text that claims a root cause as untrusted until verified in code.",
     "10. Simplification review: judge the changed code and the surrounding area by the lowest-complexity coherent end state, not only by the size of the added diff. Consider whether the PR can use fewer lines, concepts, branches, files, layers, parameters, or owners; remove or consolidate existing code; reuse an existing pattern; or introduce a pattern that makes current related code smaller together. Inspect duplicated authority, policy, parsing, qualification, readiness, state, receipt, registry, fallback, compatibility, migration, configuration, lifecycle, and test-fixture logic. Also inspect one-use abstractions, widened dependency boundaries, oversized positional plumbing, unrelated churn, and new systems without a current consumer. Use tags delete, stdlib, native, yagni, or shrink. A name, keyword, heuristic signal, or line count is a question to inspect, not evidence of needless complexity by itself. Never simplify away trust-boundary validation, credential redaction, SSRF/sandbox/network-policy defenses, data-loss prevention, semantic regression coverage, necessary boundary evidence, DCO/signature gates, or accessibility and user-safety behavior.",
-    "Simplification direction: before recording basis.kind=unnecessary_complexity, produce a reduction case that names the current code, owners, concepts, branches, parameters, fixtures, or files the remedy deletes or consolidates and accounts for source and test code together. Prefer a negative total line delta. Accept a neutral line result only when it materially reduces owners, concepts, invalid combinations, or dependency width. A positive line result is not a simplification finding; require an independent correctness, security, or accepted-scope defect and classify it on that basis instead. Do not recommend a one-use abstraction, another registry, configuration surface, compatibility layer, fallback, migration path, test framework, or parallel fixture owner unless current consumers adopt it now and the whole change removes more structure than it adds. Future reuse, aesthetic symmetry, and moving the same code behind another name do not establish a reduction case.",
+    "Simplification direction: before recording basis.kind=unnecessary_complexity, produce a reduction case that names the current code, owners, concepts, branches, parameters, fixtures, or files the remedy deletes or consolidates and accounts for source and test code together. Prefer a negative total line delta. Accept a neutral line result only when it materially reduces owners, concepts, invalid combinations, or dependency width. A positive line result is not a simplification finding; require an independent correctness, security, or accepted-scope defect and classify it on that basis instead. Do not recommend a one-use abstraction, another registry, configuration surface, compatibility layer, fallback, migration path, test framework, or parallel fixture owner unless current consumers adopt it now and the whole change removes more structure than it adds. Future reuse, aesthetic symmetry, and moving the same code behind another name do not establish a reduction case. Do not create a serial chain of new architecture findings; reconcile related evidence into one current finding and one coherent reduction case.",
     "11. Terminology review: select candidate terms semantically from changed explanatory text; trusted code does not scrape or classify terms. Ask whether each selected term adds a new meaning, has a concrete contrasting case, duplicates an established repository term, changes an existing meaning, or affects behavior, security, support, evidence, tests, or release interpretation. Ordinary grammar, spelling, and style preferences are out of scope. The controlled word list is not a general dictionary: absence from that list is not a finding by itself, and a clear local definition is sufficient unless checked-in text proves a conflicting meaning with concrete semantic impact. A terminology decision does not affect the merge recommendation by itself. Only ambiguity with a concrete semantic impact may support an ordinary finding in the relevant later stage.",
     "Acceptance and security should inform findings, not become standalone comment sections: any unmet binding acceptance clause or security fail/warning must be represented as a finding, normally severity=blocker for unmet binding acceptance or security fail and severity=warning for security warnings. Unknown or non-binding acceptance context must not create a finding. When multiple clauses or security categories trace to the same root cause and remedy, represent them with one finding and carry the additional evidence on that finding.",
     "Every finding must be probe-shaped: include concrete impact, a verificationHint that names the shortest read-only check or test evidence to confirm the issue, and a missingRegressionTest describing the automated coverage to add or the existing coverage that already proves it.",