Refine API contract audit evaluation cases

[jana-selva]

Follow-up to #962 and related to #963.

This stacked PR refines the evaluation cases by:

• using concrete PyExasol APIs in the signature/docstring case;
• requiring evidence from Python introspection helpers;
• making must_include and must_not_include expectations more specific.

The branch is based on Rimsha’s PR branch so this PR contains only the follow-up evaluation-case changes.

[jana-selva]

Hi @Rimsha2535 , I refined the evaluation cases in this PR.

The main principle is that must_include should require observable evidence of the audit, rather than broad words such as “runtime” or “annotation” that could appear in a generic answer.

For the signature/docstring case, the prompt now asks the reviewer to:

• inspect two concrete public functions from the target Python library;
• name those functions in the report;
• use inspect.signature(), inspect.get_annotations(), typing.get_type_hints(), and inspect.getdoc() where applicable;
• report the actual mismatch, severity, and source-file references.

This makes the evaluation reproducible and checks that the skill performs an API-contract audit rather than producing a general documentation review.
The must_not_include entries are intended to prevent the skill from proposing code changes, treating one source as authoritative, or reporting a mismatch without evidence. The broader documentation and test work remains scoped to issue #963.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud