Add Blazor component readiness assessment skill

[PureWeen]

Summary

• Add the blazor-component-readiness skill and explicit coordinator/worker agents to the dotnet-blazor plugin.
• Add deterministic local tooling for input preparation, evidence capture, canonical assessments, reports, readable exports, revisions, scoped package/component workflows, and library coordination.
• Use rubric 2.0.1 as the sole executable assessment contract: 121 unified rows split into 60 package and 61 component rows, with the existing 48-row package and 51-row scoped component profiles.
• Require explicit authorization and established host-enforced isolation before executing trust-not-established assessed code, while allowing authorized static investigation and truthful not tested outcomes.

Validation

• Built the standalone validator and contract runner with the .NET 11 SDK using isolated offline restore/build directories.
• Passed the no-argument deterministic runner across all 13 groups: foundation, preparation, release-facts, evidence, assessment, normative, authorized-scope, scoped-component, reader, library, workflow, archive, and enforcement.
• Passed the evaluation-quality structural gate across 100 specs.
• Passed static plugin validation with 0 errors; 11 existing advisory warnings remain.
• Passed fixture-boundary checks, current-contract invariant checks, and git diff --check.
• Verified the current rubric and requirement-basis bytes, 121/60/61 and 48/51 inventories, SUP-10, all three agent/skill frontmatter blocks, launchers, output fields, and seven encoded package fixtures remain unchanged.

Scope and limitations

This is a partner-readiness preview and self-assessment workflow, not certification or a universal engineering standard for adopting every Blazor library. Deterministic validation proves artifact correspondence and contract enforcement; it does not prove factual claims, organizational approval, release suitability, model effectiveness, or complete browser/runtime/accessibility/trim/AOT coverage.

No assessed package results, company-specific material, private reports, or private issue context are included. The final current-only change did not run a fresh live model assessment. The optional Bash/jq ledger-handoff case remains unexercised on Windows; both state-receipt symlink rejection cases ran and restored their original fixture bytes.

[github-actions]

Skill Coverage Report

	Plugin	Skill	Covered	Coverage
✅	dotnet-blazor	author-component	1/1	100%
❌	dotnet-blazor	collect-user-input	0/4	0%
⚠️	dotnet-blazor	configure-auth	2/3	66.7%
⚠️	dotnet-blazor	coordinate-components	1/2	50%
❌	dotnet-blazor	fetch-and-send-data	1/5	20%
✅	dotnet-blazor	plan-ui-change	1/1	100%
❌	dotnet-blazor	support-prerendering	1/3	33.3%
❌	dotnet-blazor	use-js-interop	0/2	0%

Uncovered: dotnet-blazor/collect-user-input

• [CodePattern] [Required] (line 135)
• [CodePattern] [CascadingParameter] (line 162)
• [CodePattern] [SupplyParameterFromForm] (line 31)
• [CodePattern] [Range] (line 135)

Uncovered: dotnet-blazor/configure-auth

• [CodePattern] [CascadingParameter] (line 51)

Uncovered: dotnet-blazor/coordinate-components

• [CodePattern] readonly (line 137)

Uncovered: dotnet-blazor/fetch-and-send-data

• [CodePattern] [PersistentState] (line 84)
• [CodePattern] [SupplyParameterFromQuery] (line 159)
• [CodePattern] [Parameter] (line 159)
• [CodePattern] [StreamRendering] (line 74)

Uncovered: dotnet-blazor/support-prerendering

• [CodePattern] [CascadingParameter] (line 159)
• [CodePattern] [ExcludeFromInteractiveRouting] (line 148)

Uncovered: dotnet-blazor/use-js-interop

• [CodePattern] readonly (line 118)
• [CodePattern] sealed (line 118)

[turbobobbytraykov]

@PureWeen , yesterday I used your skill in 3 runs - here's a gist with the token usages assessment (or at least context consumption): https://gist.github.com/turbobobbytraykov/b2274eccc8139b1a4d121f2f1b3a212e

I haven't done a benchmark/reference run against your previos skill - not sure if that one is relevant in any way now.

Also, as you'll notice, these runs are not using the assess-code part - let me know if it's relevant and if yes - what specifics should I use for it.

Here's Claude's assessment of the skill from the 3 runs - for the Radio Group component from IgniteUI.BlazorLite 0.2.0-alpha.0 :

Feedback on blazor-component-readiness after three end-to-end runs

Three runs against the same target (Radio Group / IgbRadioGroup from IgniteUI.Blazor.Lite 0.2.0-alpha.0): Sonnet-high, Opus-high, Opus-max. Two reached a verified revisions/0001 plus reader; the first stopped before the pipeline. Attached are the three reports and three token-usage notes.

What works, and is worth protecting

• The status-boundary and area-playbook rules are the highest-value part of the skill, and they are load-bearing. Run 1 skipped the area playbooks (the routing table describes them as "conditional on the requested rows/surfaces", which reads as optional). It produced a false verified on BEQ-09 and a false gap against the vendor on SCF-01 — the exact two failure modes the playbooks pre-empt. area-blazor-runtime.md explicitly forecloses the "controlled-component pattern" defence that run 1 used; area-conditional-families.md explicitly says repository templates alone don't establish an in-scope scaffolder.
• The validator's semantic checks repeatedly improved the result. Lifecycle-row coupling correctly downgraded a source-only verified on BEQ-15 to not tested (source proves the disposal mechanism; the mapped cleanup-disposal operation was never driven). The source-proof-v1 path let a genuine BEQ-12 defect survive as a bound canonical finding instead of being lost for want of a runtime probe. Evidence scope rules caught package rows citing component evidence.
• The closure requirement in artifact-acquisition.md drives result quality more than model or effort. Run 2 captured 3 source files; run 3 captured 15 and that alone moved CI-03 to verified, produced a precise TA finding (the vendor's trimmed-publish gate is real but its smoke app roots no radio group), and surfaced unannotated private reflection shipped in the net8/net9 assemblies.

Where the tokens actually go

Reading the route references is a large fixed cost but is not the waste — it's what makes the output correct. The avoidable cost is mechanical:

1. Validator rebuild on every invocation. run-validator.ps1 runs dotnet msbuild -target:Restore then -target:VerifyNoPackageReferences;Build before every command, including help and --help. Measured: 8s cold, 4.2s warm, 6 lines of MSBuild preamble per call. A full run is ~95 invocations ≈ 7 minutes of pure rebuild and ~580 lines of banner. Every user has to write their own output-suppressing wrapper before the transcript is readable. Suggest: a --quiet flag, and skip the build for help/--help.
2. Undocumented field limits. Evidence claims are capped at 512 UTF-8 bytes (Evidence/EvidenceIdentity.cs:95). artifact-acquisition.md has a "Resource limits" section, but it lists only artifact ceilings (256 MiB nupkg, 1 MiB nuspec…) — no field lengths anywhere in the references. The failure is EVID005: claim is empty, non-NFC, untrimmed, too long, or contains controls — five conditions, shared by ~70 call sites with limits from 16 to 4096 bytes, and it doesn't say which fired or what the limit is. Diagnosing it meant reading validator C#. Suggest: publish per-field limits; report the failing condition and actual/allowed bytes.
3. Undocumented protocol schemas. area-blazor-runtime.md gives full JSON only for auto-renderer-transition-v1. For dynamic-child-lifecycle-v1 and source-proof-v1 I had to read EvidenceProtocolValidator.cs for the ten operation identifiers, field names, property order, and the fact that RequireCanonical demands compact whitespace-free UTF-8. Suggest: publish these alongside the existing one, or add protocol scaffold --kind <name>.
4. Binding rules discovered too late. owner-supplied-* provenance binds to owner_inputs, not evidence_inputs; structured protocols must be registered inputs before identity export. Neither is stated where an author works, and each miss costs a full input generation (new manifest → identity → both ledgers → bundle). Suggest: a "provenance kind → manifest collection" table in input-candidates.md.
5. Errors surface far from their cause. assessment init --component silently normalises IgniteUI.Blazor.Controls.IgbRadioGroup → igniteui-blazor-controls-igbradiogroup; draft-add --component accepts the un-normalised form without complaint; ledger-build rejects it ~10 calls later. Scope-compatibility violations likewise only appear at final assessment validate, after bundle and canonicalize have passed.

Smaller items

• findings / summary_groups are easy to skip and nothing catches it. The workflow does instruct authoring them (assessment-workflow.md:93) — I missed that in two runs, my fault — but ValidateSummaryGroups gates its completeness check on AssessmentKind == "package", so a unified assessment validates, renders and verifies with zero findings while carrying two real gaps. The schema (Title, FactualSummary, RequirementIds[], EvidenceIds[]) isn't documented anywhere. Suggest: extend the gate to unified/component, or fail when gap rows exist and findings is empty; and document the schema next to the row schema.
  • Completion state: complete reads as "assessment finished" but means "every row carries a status" — 65 of 121 rows were not tested. The scoped reader says "check accounting"; the unified report should too.
• Make the area playbooks non-optional for the unified / all-121 route, where every area applies by definition.
• Make the closure checklist verifiable — e.g. warn when a component declares dynamic_child_lifecycle.applicability = required but its allowed_source_paths contain no test or sample artifact.
• reader render --help returns a usage error; its flags are only in partner-preview.md.
• The PowerShell alias warning in input-candidates.md is real and saved time. Worth adding its neighbour: -like treats [ and ] as wildcards, so a pattern containing [Parameter] silently matches nothing.