verification: .NET/Blazor globs shipped as "portable defaults" — silent-skip for non-.NET consumers

[kyle-sexton]

Plugin: verification · Categories: hardcoded opinion (1), incomplete externalization (2)
Source: work-readiness sweep (read-only audit vs docs/PLUGIN-PHILOSOPHY.md + docs/MIGRATION-PLAYBOOK.md)

Findings

• plugins/verification/skills/confirm/SKILL.md:69 — "otherwise use these portable defaults:"
• :72 — **/*.razor, **/*.razor.cs, **/*.cshtml, **/wwwroot/** (Blazor/ASP.NET)
• :73 — **/appsettings*.json (.NET)
• :74 — **/*.csproj, **/*.props, **/*.targets, **/Directory.Build.* (MSBuild)
• plugins/verification/skills/confirm/context/outcome.md:70 — "this portable one"

Why it breaks agnosticism

.NET/Blazor-specific globs presented as "portable defaults" in a plugin whose README asserts "Works in any repo." A Python/Node/Go consumer gets a default that silently never matches its runtime-affecting files, so E2E/arch-test auto-triggers never fire — a silent-skip defect, not graceful degradation. The mislabel ("portable") is the specific violation; the taxonomy itself is fine.

Fix direction

Rename to "reference .NET/Blazor defaults" and route real values through a named consumer seam (see the sibling "override seams gestured but never located" issue). Ship stack-neutral defaults (app source dirs, ecosystem manifest globs) or take an explicit "no portable default — declare per project" stance. Never a stack masquerading as universal.

[kyle-sexton]

This was generated by AI during triage.

Triage → needs-human. Posture decision + coupled to #423. The fix is a choice between (a) ship stack-neutral defaults (app-source dirs + ecosystem manifest globs), (b) take an explicit "no portable default — declare per project" stance, or (c) keep .NET globs but rename them "reference defaults" behind a named consumer seam. All three route the real values through the seam #423 asks for, so decide these two together. Priority: high (agnosticism finding, priority plugin).

[kyle-sexton]

Decision brief (2-minute read)

Problem. /verification:confirm labels .NET/Blazor globs "portable defaults" in a plugin whose README claims "Works in any repo" (plugins/verification/README.md:13). For a Python/Node/Go consumer those globs never match, so the E2E and architecture-test auto-triggers silently never fire — a silent-skip defect wearing a portable label.

Today. Verified on main:

• plugins/verification/skills/confirm/SKILL.md:69-74 — "otherwise use these portable defaults": **/*.razor, **/*.razor.cs, **/*.cshtml, **/wwwroot/**, **/appsettings*.json, **/*.csproj, **/*.props, **/*.targets, **/Directory.Build.*.
• SKILL.md:92 — Stage 2 auto-invokes /testing:run-e2e only when changed files match an e2e-* category; no match reads as "E2E not applicable", indistinguishable from a genuinely non-runtime change.
• plugins/verification/skills/confirm/context/outcome.md:70 — "this portable one" (UI-evidence contract, same mislabel).

Options.

1. RECOMMENDED — Per-ecosystem honest defaults behind the verification: consumer override seams gestured ("when the project documents…") but no declared location exists #423 seam. Move the trigger globs into bundled per-ecosystem rung-4 defaults: the Blazor/MSBuild globs live only in the dotnet default; author equivalents for the other bundled ecosystems (typescript, python, …), resolved through the same ladder as everything else, with consumer overrides riding the seam verification: consumer override seams gestured ("when the project documents…") but no declared location exists #423 declares. When no resolved ecosystem declares a category, the skill says so and infers-or-asks (ladder rungs 2-3) instead of silently skipping. Tradeoffs: depends on verification: consumer override seams gestured ("when the project documents…") but no declared location exists #423's globs half landing first, and someone must author non-.NET defaults (moderate effort). In exchange the "portable" mislabel disappears structurally rather than editorially, .NET fidelity is kept where it is honest — the maintainer's primary stack, the same posture as the toolchain: dotnet.md references dotnet-msbuild:* plugin skills that do not exist in this marketplace #412 forward-refs ruling — and silent-skip becomes an explicit, visible outcome. Reversible: defaults are data.
2. Relabel only ("reference .NET/Blazor defaults") + seam pointer. A one-line fix, honest immediately, and a sensible interim step while option 1 lands. But non-.NET consumers still get non-firing triggers by default — the defect is renamed, not fixed.
3. Stack-neutral universal defaults (app-source dirs + ecosystem manifest globs). No per-ecosystem authoring. But vague globs both over-trigger (a manifest touch is not a runtime change) and under-trigger (they cannot name UI file types), and the four categories lose their diagnostic sharpness.
4. No default — declare per project. Maximally honest, but breaks ladder rung 4 (a safe generic default should exist) and taxes every consumer with setup before first use.

Related.

• verification: consumer override seams gestured ("when the project documents…") but no declared location exists #423 — upstream: decides WHERE overrides and per-ecosystem defaults live; this issue then supplies the .NET values as the dotnet slice. Decide verification: consumer override seams gestured ("when the project documents…") but no declared location exists #423 first.
• discovery: ecosystem-discovery table is a closed set with no consumer-extension seam #408 — same shape in discovery: bundled per-ecosystem table demoted to a rung-4 default behind a consumer seam (its triage plan already recommends the same ecosystems-concern home).
• toolchain: publisher org/repo/branch URL propagates into consumer-tracked .claude/ecosystems/*.yaml headers #410 — the header written into the same consumer files these defaults would be overridden through.
• testing: C#/.NET idioms are the fallback defaults and only worked examples in ecosystem-agnostic skills #429 / implementation: .NET-only marketplace-skill references in every mode context (origin coupling, low severity) #405 / toolchain: dotnet.md references dotnet-msbuild:* plugin skills that do not exist in this marketplace #412 — sibling ".NET-as-default" findings; toolchain: dotnet.md references dotnet-msbuild:* plugin skills that do not exist in this marketplace #412's maintainer ruling (keep .NET-forward content, gate and label it honestly) is the posture option 1 follows.

[kyle-sexton]

Operator decision (2026-07-19, decision-session batch 1; relayed). ACCEPTED WITH CONDITION.

The brief's RECOMMENDED option (per-ecosystem honest defaults behind the #423 seam; explicit infer-or-ask instead of silent skip) is accepted, with this binding condition in the operator's words:

Per ecosystem, if we have to have defaults, let's make sure that they're researched and that it's driven by consensus-based research from official, authoritative, and trusted sources. In the best-case scenario, I'm talking about official documentation, articles, and blogs, and industry experts. You're probably not going to be in a bad spot if those are the defaults.

So: authoring the non-.NET per-ecosystem default globs is a research-gated task — each ecosystem's defaults must cite consensus from official/authoritative sources, not be invented. Sequencing dependency on #423's globs half stands (see #423's same-batch ruling: verify built-in/native config mechanisms first before extending the custom YAML seam).

Re-intake: removing needs-human, adding priority: needs-triage for routing.