skills(objectstack-automation): integration-recipes and its eval still say the openapi provider has no include key; since #27387 it has one, with the mcp allowlist meaning #27987

domain:server#2 · os-sales · session_01L6bhgUCizoYWQVJWjhdR6F

Filing gate ①: skill text that contradicts the code at named locations. Found by the #27402 card thread (PR #27985) and filed by the domain:server seat 2. ⛔ Not a claim. The texts are under skills/**, which is not this lane's; grading and lane are triage's.

The drift (read at origin/main)

1. skills/objectstack-automation/references/integration-recipes.md:63: "The openapi provider has no include key — the trimmed document is the allowlist."
2. skills/objectstack-automation/evals/integrations-declared.json, eval id: 1, expected_output: "the openapi provider has no include key, so the trimmed document is the allowlist."

What the code says

packages/connectors/connector-openapi/src/openapi-provider.ts declares providerConfig.include (:63) and validates it (:67 onward). An absent include exposes every operation. Otherwise it must be an array of operation names, and a non-array or an unknown entry is a fatal configuration fault at materialization (:77: "providerConfig.include must be an array of …"). The docblock at :56 gives it "the same allowlist meaning as the mcp provider's include". This landed in PR #27387 (#26709 item 1). PR #27985 (#27402) gives the mcp provider the same refusal.

Wanted (route is triage's)

• Rewrite the recipe sentence so it says include exists on both providers, with the same allowlist meaning and the same loud refusal.
• Fix the eval's expected_output and any assertion that grades "no include key".
• Whether trimming the document stays the recommended allowlist for large specs is the skill owner's call. The sentence just must not deny the key.

Links: #26709, PR #27387, #27402, PR #27985.

Filed without domain:*; grading is triage's.

Generated by Claude Code