Fix fusion redirect classifier mishandling negation; name the plugin not the repo

[mraible]

detect_fusion_redirect.py decides whether a request belongs to the Falcon Fusion plugin instead of this one. It got that decision backwards on exactly the requests where it mattered most, and it turned out the script was never running in the first place.

The classifier ignored negation

Capability keywords were matched with no regard for the words around them. A prompt saying "no Foundry app, no UI, no functions" registered UI and Foundry app as requests for those capabilities, so redirect came back false.

# before
{"redirect": false, "app_signals": ["\\bUI\\b", "\\bFoundry app\\b"]}

# after
{"redirect": true, "app_signals": [],
 "negated_app_signals": ["\\bUI\\b", "\\bFoundry app\\b"]}

The effect was precisely inverted: a request that explicitly rules out app capabilities is the clearest possible signal it belongs to the Fusion plugin, and those were the ones most likely to be kept here.

Negated spans are now blanked out before app signals are matched, using cues like no / not / without / don't need across a comma-or-or series. Matching stops at sentence-ending punctuation, so a later clause that genuinely asks for an app still counts. The verdict reports negated_app_signals so the reasoning stays inspectable rather than silently dropping matches.

The script was never wired up

Fixing the logic changed nothing at runtime, because detect_fusion_redirect.py shipped as a standalone script that no hook invoked. The eval still passed only 1 of 5 trials against the corrected classifier.

The skill router now runs it on Foundry-matched prompts and injects a redirect advisory. The wording adapts to whether the sibling plugin is already installed, since telling someone to install what they already have is noise.

The advisory was too easy to satisfy

A table row saying "advise the plugin" let the agent congratulate itself for not scaffolding an app while quietly authoring the workflow anyway. That's the worst available outcome: it hands over YAML with placeholder action IDs instead of pointing at the plugin that can discover real ones, validate against the schema, and import to the CID. Naming the plugin is now stated as required output, with the three things a redirect response must contain.

Name the plugin, not the repo

The advisory pointed at the fusion-skills GitHub repo. It now names the plugin — /plugin install crowdstrike-falcon-fusion, plus https://claude.com/plugins/crowdstrike-falcon-fusion. A repo link is a detour for anyone installing from the marketplace, and the repo name isn't the product name. classify() returns crowdstrike-falcon-fusion / crowdstrike-falcon-foundry as target.

Test harness reported success against nothing

Also here, since it's what surfaced the query-parameter bug. Pointed at a directory whose run-*/ dirs contain no manifest.yml, verify-apps.sh discovered zero apps and still wrote phase1_completed: true / phase2_completed: true, printing Overall: 0/0 fully verified — which reads as a pass. It then drove the browser phase with nothing in scope. Discovery now exits 1, naming the directory it searched and pointing at --green / --dir.

The advice loops iterated seq 0 $((APP_COUNT - 1)). With APP_COUNT=0 that expands to seq 0 -1, which emits 0 and -1 rather than nothing, so each body ran twice against nonexistent indices. jq returned null, null != "true", and the output was 2/0 apps failed to release plus App null: null scorecard rows — advice fabricated from absent data, recommending a release step that had never been measured. All six loops now use the C-style form, which doesn't execute when the count is zero. run-ab-test.sh also now fails loudly when --ref names a nonexistent baseline.

These files (verify-apps.sh, test-scorecard-parser.sh, run-ab-test.sh) don't ship with the plugin, so there's no CHANGELOG entry for them.

Query parameter types in generated UI code

Found by the end-to-end verification below. One of five A/B runs generated limit: '25' in its extension's API call while the other four generated limit: 25. All five OpenAPI specs declare limit as type: integer, so the quoted value failed server-side schema validation with got string want integer and that extension never fetched data.

apiIntegration().execute() types params as Record<string, unknown>, so a quoted number type-checks and builds cleanly — the mismatch only surfaces at runtime, and because the extension still renders, it reads as an API or credential error rather than a code bug. The UI skill now documents the constraint with a correct/incorrect pair, plus a Common Pitfalls entry.

A/B against v1.3.0

5 runs per arm, same model throughout. Deploy rate 5/5 both arms, spec quality unchanged, zero anti-patterns, no reference-file reads. Tokens came in +4.7% (5.64M → 5.91M per run), which is inside the noise at this sample size — Welch t = 0.49, 95% CI spanning -970k to +1.5M. No measurable regression; no claim of improvement either.

End-to-end verification ran all five apps through install → UI render → workflow execution → uninstall against a live CID: 5/5 on every stage. Worth reading precisely — all five extensions rendered but none completed a successful data fetch. Four returned 401 from the upstream API (expected with test credentials) and the fifth hit the schema error described above. So what's confirmed is that manifest sockets, CSP, entrypoint paths, and build output are all correct; a successful end-to-end data fetch is not part of this evidence.

Tests

Negation, naming, and router tests were each confirmed to fail against the unfixed code before being kept — a passing test proves nothing until you've watched it fail. Guard tests cover over-reach in both directions: an affirmative UI request and an app request following a negated clause both still stay here, and a bare "Fusion workflow" request produces no output, correctly, since the Fusion plugin's own router matches that phrasing. The two routers partition the space; this redirect covers the ambiguous middle where someone says "Foundry" but describes work needing no app.

./test-hooks.sh 192/192, pytest 89 passed, ./test-scorecard-parser.sh 25 passed, shellcheck clean.

Known limitation

The eval covering this can't validate the hook path. The Agent SDK doesn't load hooks for a local plugin, confirmed by neither advisory appearing anywhere in the eval transcript. So what's verified is that the advisory is correctly emitted; agent compliance with it is not. The eval is marked non-blocking in the evals repo with the same rationale, to be reverted once the harness loads hooks.