roadmap: dotnet plugin family (dotnet-msbuild, dotnet-test, …) — first-class .NET toolchain support

[kyle-sexton]

Category: improvement (roadmap umbrella) · Source: maintainer stack disclosure while dispositioning #405/#412/#422 (forward references, not stale).

Motivation

.NET is the maintainer's primary application stack — day-job environment: .NET 10, Azure Cloud, Pulumi, Duende IdentityServer, SQL Server, Azure Service Bus, Blazor for all UIs. Existing dotnet-msbuild:/dotnet- references in toolchain/verification/implementation anticipate plugins that don't exist yet. First-class .NET plugins are the highest-leverage stack-specific investment for day-job work-readiness.

Scope sketch (decompose at triage/planning)

• dotnet-msbuild: build/restore/solution ops the toolchain plugin's dotnet.md already gestures at.
• dotnet-test: test running/enrichment the testing plugin's .NET examples anticipate.
• Candidates from the stack: Blazor E2E patterns (playwright integration), Azure Service Bus + Pulumi verification patterns — evaluate, don't assume.
• All plugins follow the marketplace's agnosticism contract: company/machine-agnostic, setup-driven discovery, presence-gated cross-references.

Sequencing

References get presence-gated NOW via #405/#412/#422. Plugin construction is post-work-readiness-week roadmap unless capacity frees earlier.

Related

#405 · #412 · #422 (reference gating) · toolchain dotnet.md · testing .NET defaults (#429)

[kyle-sexton]

This was generated by AI during triage. · Category: improvement (roadmap umbrella) · Priority: priority: high (maintainer's primary day-job stack — north-star day-job work-readiness; note: explicitly sequenced post-work-readiness-week, so high-value but not this week's execution). Routed needs-human + wayfind: research.

Why needs-human (+ research)

This is a plugin-family roadmap umbrella, not a single actionable change — it needs a scope/decompose pass, and its own body flags "evaluate, don't assume" for several candidates. Two things a human must own before it becomes buildable work:

1. Scope + prioritization — which plugins make the cut and in what order. dotnet-msbuild and dotnet-test are anchored by existing forward references (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/verification: bare unguarded cross-plugin references to dotnet-*/cloudflare plugins in measure contexts #422 already gesture at them). The stack candidates — Blazor E2E patterns (playwright integration), Azure Service Bus + Pulumi verification patterns — are explicitly "evaluate, don't assume": a research pass, not an assumed build list. Hence wayfind: research.
2. Sequencing vs the week — the body sequences plugin construction as post-work-readiness-week roadmap "unless capacity frees earlier." That prioritization call is the maintainer's.

Decoupled from the interim fixes (not a blocker)

Per this issue's own sequencing, the dangling-reference cleanup happens now and independently: #405 (implementation), #412 (toolchain), #422 (verification) are each routed status: ready this cycle with a presence-gate + stack-neutral-fallback fix, each annotated as a forward reference to this family. They do not wait on this roadmap decision; when the family ships, its plugins satisfy the gates the interim fixes install.

Recommended human path

/work-items:decompose (or /planning:research on the "evaluate, don't assume" candidates first) to turn this umbrella into per-plugin buildable issues, following the marketplace agnosticism contract (company/machine-agnostic, setup-driven discovery, presence-gated cross-references). Anchor plugins: dotnet-msbuild, dotnet-test. Related: testing .NET defaults (#429).

[kyle-sexton]

This was generated by AI (needs-human decision-brief pass).

Decision brief (2-minute read)

Roadmap-altitude decision (scope / sequencing / priority) — builds on the triage note above rather than restating "run decompose." The value added here is the verified "today" state and reversibility-weighted options.

Problem. .NET is the maintainer's primary day-job stack, and several plugins already carry forward references to dotnet-msbuild:* / dotnet-test:* verbs that don't exist. The umbrella needs a maintainer call on which plugins make the cut, in what order, and when relative to work-readiness-week.

Today (verified):

• No dotnet-* plugin exists — none in plugins/ (confirmed against the full plugin list).
• .NET is already supported at the toolchain layer, not absent: plugins/toolchain/reference/ecosystems/dotnet.yaml ships portable build/test/format/fix commands (dotnet build|test|format), and plugins/toolchain/skills/check/context/dotnet.md carries .NET check guidance.
• The dotnet-msbuild:* / dotnet-test:* mentions are forward references to not-yet-built plugins, already spread across four plugins:
  • dotnet-msbuild:* — binlog-failure-analysis, msbuild-antipatterns, resolve-project-references, build-perf-diagnostics/build-perf-baseline, binlog-generation, check-bin-obj-clash (in implementation/skills/implement/context/{bugfix,refactor}.md, toolchain/skills/check/context/dotnet.md:74-76, testing/skills/diagnose/context/investigate.md:58, verification/skills/measure/context/performance.md:65).
  • dotnet-test:* — mtp-hot-reload, code-testing-agent, crap-score, test-anti-patterns, assertion-quality (in testing/skills/{plan/SKILL.md:107, diagnose/context/loop.md:112, write/context/{organize,write}.md}, verification/skills/measure/context/metrics.md:70-71).

So the two anchor plugins are already load-bearing (real dangling verbs), while the stack candidates (Blazor E2E, Azure Service Bus + Pulumi verification) have no references yet — matching the body's "evaluate, don't assume."

Options (roadmap ordering — no code committed by any of these; all reversible):

• Option A — build the two reference-anchored plugins first (dotnet-msbuild, dotnet-test); treat Blazor E2E and Service Bus/Pulumi verification as a separate research spike, not committed scope; keep construction sequenced post-work-readiness-week "unless capacity frees earlier." RECOMMENDED. Anchors are justified by existing forward-reference surface (the refs already exist and dangle); the stack candidates are gated behind the wayfind: research pass the body itself asks for, so nothing speculative gets built. Next step: /work-items:decompose into per-plugin issues under the marketplace agnosticism contract (company/machine-agnostic, setup-driven discovery, presence-gated cross-refs). Fully reversible (ordering only).
• Option B — commit the whole family now (msbuild, test, Blazor E2E, Service Bus/Pulumi) as one push. Highest day-job leverage if readiness is urgent, but commits the "evaluate, don't assume" candidates before the research they were flagged for, and collides with the explicit post-work-readiness-week sequencing.
• Option C — defer the entire family until a concrete day-job task pulls it; keep only the interim presence-gates. Lowest effort, but strands the already-written forward references indefinitely and shelves what the maintainer called the highest-leverage stack-specific investment.

Cross-links.

• 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 / verification: bare unguarded cross-plugin references to dotnet-*/cloudflare plugins in measure contexts #422 — the interim presence-gate + neutral-fallback fixes for the dangling references; they ship now and independently, and the family (when built) satisfies the gates they install. toolchain: dotnet.md references dotnet-msbuild:* plugin skills that do not exist in this marketplace #412 (toolchain forward-reference gating) is the carrier that ties the reference cleanup to this umbrella.
• testing: C#/.NET idioms are the fallback defaults and only worked examples in ecosystem-agnostic skills #429 — testing .NET defaults, related scope for dotnet-test.
• Not constrained by source-control: no read/consume-only posture — "safe" babysit tier and pull-request monitor write to GitHub autonomously #440 (outward-write mode) or feat(source-control): babysit autopilot merge tier — bot-account review + criteria-gated merge #476 (autopilot merge tier).

[kyle-sexton]

Operator decision (2026-07-19, decision-session batch 2; relayed).

ACCEPTED — the decision brief's RECOMMENDED option verbatim.

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

[kyle-sexton]

Supplement to the batch-2 acceptance: the operator's routing question (toolchain vs dotnet-* boundary) was answered and confirmed in-session — toolchain stays the generic verb layer (build/test/lint via ecosystem config); dotnet-msbuild/dotnet-test are specialist escalation skills, the hand-off already encoded at plugins/toolchain/skills/check/context/dotnet.md:74-76 (today's dangling refs, #412). The plugin family must preserve that boundary: no duplication of toolchain's generic verbs.