Code review still fails to trace VeNCrypt activation path for load_cert_chain false positive

[sbauza]

Problem

When reviewing Gerrit change 955915 (VNC proxy ssl.wrap_socket → SSLContext migration), the agent consistently flags load_cert_chain(keyfile=None, certfile=None) as a blocker bug — even after multiple rounds of instruction improvements.

The false positive persists because the agent fails to trace the full activation path:

• RFBAuthSchemeVeNCrypt is only instantiated when CONF.vnc.auth_schemes includes "vencrypt" (see auths.py:28-49)
• When vencrypt is enabled, the config docs require client certs to be configured
• Therefore None only reaches load_cert_chain through operator misconfiguration, not a valid code path

The agent checks callers and config options but does not connect the two: it sees vencrypt_client_key has no default (so None is "valid") without realizing that the class is gated by a feature toggle that requires those certs when active.

How to reproduce

1. Start a Nova Review session
2. Run /code-review 955915
3. The agent will flag load_cert_chain(keyfile=None, certfile=None) as a blocker

Sessions tested

• session-b8aaf3fe-0a00-4b7c-8d8d-2f668d0a6f2a — first attempt with PR fix: add context checks to prevent false-positive code reviews #15 improvements
• session-9bb02f5a-cc5c-4507-81cc-ad7ae45c361d — with PR fix: elevate security-degradation principle to a top-level review rule #16 (loud-failure rule + context inheritance)
• session-892a8050-fa62-47b9-b6bb-8b5f502f580d — with mandatory nova-core + reachability verification
• session-03ceb4e1-d7c5-4554-a3dd-562e84cd3246 — with config interdependency connection rule

What we tried (PR #16)

1. Elevated "prefer loud failure over silent security degradation" to a top-level rule in rules.md
2. Added context inheritance to agent personas so subagents see workflow rules and knowledge files
3. Made nova-core invocation mandatory for every review
4. Added the loud-failure principle to both nova-core and nova-coresec agents
5. Added "verify reachability before flagging bugs" rule with 3 mandatory steps
6. Strengthened the rule to require connecting activation path to config dependencies

Each iteration got closer but the agent still fails to complete the full chain: feature toggle → class instantiation → config prerequisites → None is misconfiguration, not a bug.

Root cause hypothesis

The activation path for VeNCrypt is indirect enough (config option → factory class → class map → method call) that the agent either doesn't follow far enough or doesn't connect the config dependency back. The instructions tell it what to do but the reasoning chain is too long for the agent to reliably execute in practice.

Possible next steps

• Add a worked example in rules.md showing the full reasoning chain for a config-gated feature
• Investigate whether a dedicated "reachability analysis" subagent with focused tooling would be more reliable
• Consider structured output for reachability checks (force the agent to fill in: feature toggle, activation path, config prerequisites, conclusion)

Related to #14