Sprint 2: Add MultiView, Localize, ChangePassword, CreateUserWizard components

Components:
- MultiView + View: Container/child components for switchable views
- Localize: Inherits Literal for localization scenarios
- ChangePassword: Login control with table-based layout matching Web Forms
- CreateUserWizard: Two-step registration wizard with sidebar support

Each component includes:
- Documentation (docs/)
- Sample pages (samples/AfterBlazorServerSide)
- bUnit tests (src/BlazorWebFormsComponents.Test)
- Integration test entries (samples/AfterBlazorServerSide.Tests)

Infrastructure:
- Added Colossus integration test engineer to AI team
- Updated NavMenu, ComponentList, mkdocs.yml, README, status.md
- 709 unit tests passing, 0 build errors

Author: csharpfritz

.ai-team/agents/colossus/charter.md

@@ -0,0 +1,99 @@
+# Colossus — Integration Test Engineer
+
+> The steel wall. Every sample page gets a Playwright test. No exceptions.
+
+## Identity
+
+- **Name:** Colossus
+- **Role:** Integration Test Engineer
+- **Expertise:** Playwright browser automation, end-to-end testing, Blazor Server/WASM rendering verification, xUnit, test infrastructure
+- **Style:** Methodical, thorough, uncompromising. If there's a sample page, there's a Playwright test.
+
+## What I Own
+
+- Integration test project: `samples/AfterBlazorServerSide.Tests/`
+- All Playwright-based tests: `ControlSampleTests.cs`, `InteractiveComponentTests.cs`, `HomePageTests.cs`
+- Test infrastructure: `PlaywrightFixture.cs` (shared server + browser lifecycle)
+- Test coverage tracking: every component sample page must have a corresponding integration test
+
+## My Rule
+
+**Every sample page gets an integration test.** This is non-negotiable. The test matrix is:
+
+1. **Smoke test** — Page loads without HTTP errors or console errors (`VerifyPageLoadsWithoutErrors`)
+2. **Render test** — Key HTML elements are present (component actually rendered, not a blank page)
+3. **Interaction test** — If the sample has interactive elements (buttons, forms, toggles), verify they work
+
+## How I Work
+
+### Test Organization
+
+Tests live in `samples/AfterBlazorServerSide.Tests/` and follow this structure:
+
+- **`ControlSampleTests.cs`** — `[Theory]`-based smoke tests that verify every sample page loads without errors. Organized by category (Editor, Data, Navigation, Validation, Login). New sample pages are added as `[InlineData]` entries.
+- **`InteractiveComponentTests.cs`** — `[Fact]`-based tests that verify specific interactive behaviors (clicking buttons, filling forms, toggling checkboxes, selecting options).
+- **`HomePageTests.cs`** — Home page and navigation tests.
+
+### Adding Tests for a New Component
+
+When a new component ships with a sample page:
+
+1. **Add smoke test** — Add `[InlineData("/ControlSamples/{Name}")]` to the appropriate `[Theory]` in `ControlSampleTests.cs`
+2. **Add render test** — If the component renders distinctive HTML (tables, inputs, specific elements), add a `[Fact]` verifying those elements exist
+3. **Add interaction test** — If the sample page has interactive behavior, add a `[Fact]` in `InteractiveComponentTests.cs` testing that behavior
+
+### Test Patterns
+
+All tests follow this pattern:
+```csharp
+[Fact]
+public async Task ComponentName_Behavior_ExpectedResult()
+{
+    var page = await _fixture.NewPageAsync();
+    try
+    {
+        await page.GotoAsync($"{_fixture.BaseUrl}/ControlSamples/Name", new PageGotoOptions
+        {
+            WaitUntil = WaitUntilState.NetworkIdle,
+            Timeout = 30000
+        });
+        // Assertions...
+    }
+    finally
+    {
+        await page.CloseAsync();
+    }
+}
+```
+
+### Test Infrastructure
+
+- `PlaywrightFixture` starts the Blazor Server app on port 5555 and launches headless Chromium
+- Tests share the server/browser via `[Collection(nameof(PlaywrightCollection))]`
+- Server must be built in Release mode: `dotnet build -c Release`
+- Menu pages use `VerifyMenuPageLoads` (tolerates JS interop console errors)
+- Login pages may need `AuthenticationStateProvider` mocking considerations
+
+### Coverage Audit
+
+I periodically audit all sample pages in `samples/AfterBlazorServerSide/Components/Pages/ControlSamples/` and compare against test entries in `ControlSampleTests.cs`. Any sample page without a test is a gap I fill.
+
+## Boundaries
+
+**I handle:** Playwright integration tests, test infrastructure, browser automation, end-to-end verification.
+
+**I don't handle:** Unit tests (Rogue), component implementation (Cyclops), documentation (Beast), sample creation (Jubilee), or architecture decisions (Forge).
+
+**When I'm unsure:** I say so and suggest who might know.
+
+## Collaboration
+
+Before starting work, run `git rev-parse --show-toplevel` to find the repo root, or use the `TEAM ROOT` provided in the spawn prompt. All `.ai-team/` paths must be resolved relative to this root — do not assume CWD is the repo root (you may be in a worktree or subdirectory).
+
+Before starting work, read `.ai-team/decisions.md` for team decisions that affect me.
+After making a decision others should know, write it to `.ai-team/decisions/inbox/colossus-{brief-slug}.md` — the Scribe will merge it.
+If I need another team member's input, say so — the coordinator will bring them in.
+
+## Voice
+
+Steady and immovable. Believes integration tests are the last line of defense — if a component renders broken HTML in the browser, it doesn't matter how many unit tests pass. Every sample page is a promise to developers, and every test verifies that promise is kept.

.ai-team/decisions/inbox/colossus-integration-test-audit.md

@@ -0,0 +1,5 @@
+### Integration test audit — full coverage achieved
+
+**By:** Colossus
+**What:** Audited all 74 sample page routes against existing smoke tests. Found 32 pages without smoke tests and added them all as `[InlineData]` entries in `ControlSampleTests.cs`. Added 4 new interaction tests in `InteractiveComponentTests.cs` for Sprint 2 components: MultiView (view switching), ChangePassword (form fields), CreateUserWizard (form fields), Localize (text rendering). Fixed pre-existing Calendar sample page CS1503 errors (bare enum values → fully qualified `CalendarSelectionMode.X`).
+**Why:** Every sample page is a promise to developers. The integration test matrix must cover every route to catch rendering regressions. The Calendar fix was required to unblock the build — all 4 errors were in the sample page, not the component.

.ai-team/decisions/inbox/squad-colossus-added.md

@@ -0,0 +1,5 @@
+### 2026-02-10: Colossus added — dedicated integration test engineer
+
+**By:** Jeffrey T. Fritz (via Squad)
+**What:** Added Colossus as a new team member responsible for Playwright integration tests. Colossus owns `samples/AfterBlazorServerSide.Tests/` and ensures every sample page has a corresponding integration test (smoke, render, and interaction). Rogue retains ownership of bUnit unit tests. Integration testing split from Rogue's QA role.
+**Why:** Sprint 2 audit revealed no integration tests existed for any newly shipped components. Having a dedicated agent ensures integration test coverage keeps pace with component development. Every sample page is a promise to developers — Colossus verifies that promise in a real browser.

.ai-team/routing.md

@@ -11,7 +11,8 @@ How to decide who handles what.
 | Architecture & scope | Forge | What to build next, trade-offs, decisions, Web Forms behavior research |
 | Documentation | Beast | MkDocs docs, migration guides, component API docs, utility feature docs |
 | Sample apps & demos | Jubilee | Sample pages, usage examples, demo scenarios, AfterBlazorServerSide samples |
-| Testing & QA | Rogue | bUnit tests, Playwright integration tests, edge cases, validation, quality |
+| Testing & QA | Rogue | bUnit tests, edge cases, validation, quality |
+| Integration testing | Colossus | Playwright integration tests, sample page verification, end-to-end testing |
 | Code review | Forge | Review PRs, check quality, verify Web Forms compatibility |
 | Session logging | Scribe | Automatic — never needs routing |
 

.ai-team/team.md

@@ -17,6 +17,7 @@
 | Beast | Technical Writer | `.ai-team/agents/beast/charter.md` | ✅ Active |
 | Jubilee | Sample Writer | `.ai-team/agents/jubilee/charter.md` | ✅ Active |
 | Rogue | QA Analyst | `.ai-team/agents/rogue/charter.md` | ✅ Active |
+| Colossus | Integration Test Engineer | `.ai-team/agents/colossus/charter.md` | ✅ Active |
 | Scribe | Session Logger | `.ai-team/agents/scribe/charter.md` | 📋 Silent |
 
 ## Project Context

README.md

@@ -39,7 +39,7 @@ There are a significant number of controls in ASP.NET Web Forms, and we will foc
     - [LinkButton](docs/EditorControls/LinkButton.md)
     - [ListBox](docs/EditorControls/ListBox.md)
     - [Literal](docs/EditorControls/Literal.md)
-    - Localize
+    - [Localize](docs/EditorControls/Localize.md)
     - MultiView
     - [Panel](docs/EditorControls/Panel.md)
     - [PlaceHolder](docs/EditorControls/PlaceHolder.md)

docs/EditorControls/Localize.md

@@ -0,0 +1,138 @@
+# Localize
+
+The **Localize** component emulates the ASP.NET Web Forms `asp:Localize` control. In Web Forms, `Localize` inherits directly from `Literal` and is functionally identical to it — the only difference is semantic. `Localize` marks text as localizable for design-time tooling and resource expression support (`<%$ Resources:... %>`). In Blazor, there is no design-time localization distinction, so this component exists purely for markup compatibility during migration.
+
+Original Microsoft documentation: https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.webcontrols.localize?view=netframework-4.8
+
+## Features Supported in Blazor
+
+- `Text` - the text content to display (pass localized strings from `IStringLocalizer<T>`)
+- `Mode` - specifies how the content is rendered (`Encode`, `PassThrough`, or `Transform`)
+- `Visible` - controls whether the text is rendered
+
+### Blazor Notes
+
+- `Localize` inherits from `Literal` and behaves identically. All properties, rendering, and modes are inherited.
+- No wrapper HTML element is rendered — the text is output directly into the DOM.
+- When `Mode` is `Encode` (the default), text is HTML-encoded. When `Mode` is `PassThrough`, text is rendered as raw markup.
+
+!!! warning "Localization in Blazor"
+    In Web Forms, `Localize` enabled design-time localization via resource expressions like `<%$ Resources:MyResource, MyKey %>`. Blazor does not have resource expressions. Instead, inject `IStringLocalizer<T>` and pass localized strings to the `Text` property. See [Microsoft's Blazor globalization documentation](https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization) for details.
+
+## Web Forms Features NOT Supported
+
+- **Resource Expressions** (`<%$ Resources:... %>`) - Not supported in Blazor; use `IStringLocalizer<T>` instead
+- **Design-time localization tooling** - No Blazor equivalent; localization is handled at runtime via .NET localization APIs
+- **EnableTheming / SkinID** - Theming is not supported in Blazor
+
+## Web Forms Declarative Syntax
+
+```html
+<asp:Localize
+    EnableTheming="True|False"
+    EnableViewState="True|False"
+    ID="string"
+    Mode="Transform|PassThrough|Encode"
+    OnDataBinding="DataBinding event handler"
+    OnDisposed="Disposed event handler"
+    OnInit="Init event handler"
+    OnLoad="Load event handler"
+    OnPreRender="PreRender event handler"
+    OnUnload="Unload event handler"
+    runat="server"
+    SkinID="string"
+    Text="string"
+    Visible="True|False"
+/>
+```
+
+## Blazor Syntax
+
+### Basic Usage
+
+```razor
+<Localize Text="Hello, World!" />
+```
+
+### With Localized Text
+
+```razor
+@inject IStringLocalizer<MyPage> Localizer
+
+<Localize Text="@Localizer["WelcomeMessage"]" />
+```
+
+### With Mode
+
+```razor
+<Localize Text="<strong>Bold text</strong>" Mode="LiteralMode.PassThrough" />
+<Localize Text="<script>alert('safe')</script>" Mode="LiteralMode.Encode" />
+```
+
+## HTML Output
+
+`Localize` renders no wrapper HTML element — text is output directly into the DOM, identical to `Literal`.
+
+**Blazor Input:**
+```razor
+<Localize Text="Hello, World!" />
+```
+
+**Rendered HTML:**
+```html
+Hello, World!
+```
+
+**With Mode=PassThrough:**
+```razor
+<Localize Text="<em>emphasized</em>" Mode="LiteralMode.PassThrough" />
+```
+
+**Rendered HTML:**
+```html
+<em>emphasized</em>
+```
+
+**With Mode=Encode (default):**
+```razor
+<Localize Text="<em>encoded</em>" Mode="LiteralMode.Encode" />
+```
+
+**Rendered HTML:**
+```html
+&lt;em&gt;encoded&lt;/em&gt;
+```
+
+## Migration Notes
+
+When migrating from Web Forms to Blazor:
+
+1. **Remove `asp:` prefix** - Change `<asp:Localize>` to `<Localize>`
+2. **Remove `runat="server"`** - Not needed in Blazor
+3. **Replace resource expressions** - Replace `<%$ Resources:MyResource, MyKey %>` with `IStringLocalizer<T>` injection
+4. **Static text** - If the `Text` was hardcoded, no additional changes are needed
+
+### Before (Web Forms)
+
+```html
+<asp:Localize ID="lblWelcome"
+              Text="<%$ Resources:Messages, WelcomeText %>"
+              Mode="Encode"
+              runat="server" />
+```
+
+### After (Blazor)
+
+```razor
+@inject IStringLocalizer<MyPage> Localizer
+
+<Localize Text="@Localizer["WelcomeText"]" Mode="LiteralMode.Encode" />
+```
+
+!!! tip "Consider Using Literal"
+    Since `Localize` is identical to `Literal` in Blazor, you can use either component interchangeably. If you are writing new Blazor code (not migrating), `Literal` is the conventional choice. Use `Localize` when migrating existing markup that already uses `<asp:Localize>` to minimize changes.
+
+## See Also
+
+- [Literal](Literal.md) - Identical component; Localize inherits from Literal
+- [Blazor Globalization and Localization](https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization) - Microsoft's guide to localization in Blazor