dotpudica-wf-add-page

name	dotpudica-wf-add-page
description	End-to-end workflow: deliver a complete new UI page (settings, inventory, menu, any panel) with ViewModel, View, bindings, commands, optional item lists, and verification. The most common workflow - use whenever the user describes a page or panel they want to build.

dotpudica-wf-add-page

Purpose

Take a described page or panel and deliver it end to end: a ViewModel holding state, commands, and events, a [DotPudicaView] View with declarative bindings and the two lifecycle lines, optional item lists, and verification through build and runtime. This workflow owns the end-to-end task graph; the capability skills own the "how" of each node. It is the most common workflow — most framework work is "add this page".

Trigger Patterns

Use this workflow when the user says:

• "Build a settings page" / "inventory screen" / "menu" / "XX panel" / "a screen that shows Y".
• A page exists but has no bindings — it is built with manual Label.Text = ... plumbing instead of ViewModel bindings.
• An existing page needs a list or command added (item list, new button behavior).

Do not use it for popups or dialogs hosted as windows (route to dotpudica-wf-add-window) or for projects with no bootstrap (route to dotpudica-wf-project-setup first).

Task graph

Execute the nodes in order; close each node's acceptance point before advancing.

• N1 — Clarify the requirement (deliverable: requirement summary; invokes no skill): page purpose, data source (which service supplies it), interactions (what the user can do), and whether the page lives inside a window/popup. Acceptance: the summary names the page type, its data, and its interactions — no open questions.
• N2 — Verify the bootstrap (deliverable: readiness confirmed; invokes capabilities/dotpudica-bootstrap for the check): the csproj contains the <!-- DotPudica:Begin --> ... <!-- DotPudica:End --> block and a bootstrap class calls AppContext.Initialize once. If missing, run dotpudica-wf-project-setup first. Acceptance: Select-String "DotPudica:Begin" matches and AppContext.Current is reachable.
• N3 — Design the ViewModel (deliverable: VM class; invokes capabilities/dotpudica-view): state as [ObservableProperty] fields, commands as [RelayCommand] methods, events the page must react to. Acceptance: the class is partial; construction is DI-resolvable (exactly one public all-interface constructor, no DOTPUDICA040 needed) or a [ViewModelFactory] method is declared.
• N4 — Write the View (deliverable: View class; invokes capabilities/dotpudica-view): [DotPudicaView(typeof(TVM))], [Export] control fields carrying the binding attributes, and the two lifecycle lines _Ready() => InitializeView() / _ExitTree() => DisposeView(). Acceptance: every binding path resolves on the ViewModel and every [Export] binding field is assigned a node in the scene.
• N5 — Add lists/commands (on demand) (deliverable: list/command bindings; invokes capabilities/dotpudica-view): [ItemsSource(path, itemScene)] for collections, [BindCommand] for per-item or extra commands. Acceptance: the collection implements INotifyCollectionChanged and the ItemCommand parameter type matches the element type.
• N6 — Build verification (deliverable: build result; invokes capabilities/dotpudica-verify): dotnet build with zero DOTPUDICA diagnostics; when the project builds with -p:EmitCompilerGeneratedFiles=true, also confirm the generated artifacts. Acceptance: zero diagnostics; with EmitCompilerGeneratedFiles enabled, obj/Generated contains the Bindings.g.cs with InitializeView / DisposeView.
• N7 — Runtime check (deliverable: check conclusion; invokes capabilities/dotpudica-verify): launch the project, confirm initial values display, trigger an interaction, then leave the page. Acceptance: initial state shows, commands fire, and leaving the page produces no leaks or repeated-subscription errors.

Select-String "DotPudica:Begin" <project>.csproj
dotnet build

Acceptance criteria

The workflow is complete when all of these hold:

• dotnet build completes with zero DOTPUDICA diagnostics.
• The page displays the ViewModel's initial state on open.
• Commands trigger visible effects (button press updates state / UI).
• Leaving the page leaks nothing — returning does not duplicate subscriptions or error.

Failure branches

Node	Symptom	Fix
N3	DOTPUDICA040 / DOTPUDICA041	The ViewModel's construction shape is not all-interface — add a [ViewModelFactory] method matching the generator's expected shape.
N4	DOTPUDICA046	Add the two lifecycle lines: _Ready() => InitializeView() and _ExitTree() => DisposeView() (use RecycleView() when Pooled = true).
N4	DOTPUDICA001	A binding path does not resolve — fix the path or member name (Mvvm members must use generated names: Title, SaveCommand).
N6	Diagnostics remain after the fix round	Look each remaining ID up in references/diagnostics.md, fix the root cause, and rebuild — repeat until zero.

Any node checkpoint failure returns to capabilities/dotpudica-verify to fix; never roll back and restart the graph from N1.

Common variants

• Page with a list: N5 uses [ItemsSource] with an item scene plus an ItemCommand for item taps; each item scene is itself a small View whose binding path is the element type.
• Popup embedded in the page: after N4, additionally invoke capabilities/dotpudica-windows for the popup class and its scene path; the page shows it via the window manager.

References

• capabilities/dotpudica-view — N3 (ViewModel shape, [ObservableProperty] / [RelayCommand] generated names) and N4/N5 (View class, binding attributes, lifecycle lines, [ItemsSource] contract).
• capabilities/dotpudica-bootstrap — N2 (csproj block check, bootstrap readiness).
• capabilities/dotpudica-verify — N6/N7 (build command, diagnostic loop, runtime checklist).
• capabilities/dotpudica-windows — variant: popups embedded in the page.
• dotpudica-route — related: entry point that routes to this workflow; consult it for the next task on this project.