Skip to content
cccskills
FreePublished on GitHub

wfa-extract-domain

Phase B of a WinForms-to-Avalonia migration: extract UI-independent application behavior, state rules, use cases, and boundary contracts with TDD and no WinForms/Avalonia references. Use only when an explicit migration still has business behavior in Forms or UI helpers, or when the orchestrator routes here. Do not build Avalonia XAML in this phase.

The English summary is being prepared. Showing the original description.

See how to install

Files included (4)

  • SKILL.md3.4 KB
  • references/boundary-adapter-patterns.md1.5 KB
  • references/core-layer.md1.4 KB
  • references/tdd-baseline.md1.1 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Phase B — Extract application core

Implement Phase A contracts as a UI-independent application core. The UI may call the core; the core never calls UI controls or framework services.

Read core layer for dependency boundaries, boundary adapter patterns when the application has external inputs or effects, and TDD baseline for test sequencing.

Workflow

1. Scaffold (if needed)

  • src/<Product>.Core — modern TFM, no UI packages
  • tests/<Product>.Core.Tests — representative behavior fixtures and helpers

2. Models and invariants

  • Preserve field meanings and documented invariants
  • Drop UI-only storage (control tags, display-only caches unless computed by services)
  • Prefer explicit edit APIs over free-form mutation from Views

Document intentional semantic changes.

3. Application rules and use cases

Extract calculations, validation, state transitions, and multi-step use cases discovered in Phase A. Replace control indexes and tags with semantic types.

4. Boundary contracts

  1. Keep deterministic translation or validation logic in the core when it has no environment dependency.
  2. Represent filesystem, process, network, device, clock, and OS dependencies as narrow ports when present.
  3. Implement environment-dependent adapters in Phase C, not as hidden calls from the core.

Return structured outcomes and diagnostics. Never prompt the user from the application core.

5. Untrusted-input baseline

  • Validate size, depth, counts, recursion, and identifier ranges before allocation or traversal.
  • Disable external resource access unless the product explicitly requires and constrains it.
  • Bound dynamic execution by capability, time, memory, and cancellation when it exists.
  • Add negative fixtures before the first releasable Avalonia build.

6. TDD

Port legacy tests; goldens for representative fixtures; edge cases from contracts; document intentional non-support with tests.

7. Coupling kill list

Check the core for zero WinForms/Avalonia types, UI prompts, environment-specific APIs, and unmediated external effects.

Corrections seen in practice

  • One application rule must drive every relevant entry point and consumer.
  • Validate extreme values and illegal transitions; add regression tests for rejected states.
  • Prefer typed diagnostic codes over free-form strings.
  • Public core types are a stable API: use role-based names, explicit invariants, and accurate documentation.
  • Preserve authoritative external contracts at boundary adapters; do not simplify away required semantics.

Deliverables

  • Core builds
  • Models, invariants, and use cases extracted
  • Boundary ports match discovered dependencies
  • Untrusted-input bounds covered before first release
  • Core tests green

Handoff

  • Platform and infrastructure adapters -> wfa-platform-services
  • UI → wfa-avalonia-ui
  • Product evolution after ship -> wfa-post-port-evolve

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

The English summary is being prepared. Showing the original description.

tautcony/ChapterTool113Updated Oct 14, 2026

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

The English summary is being prepared. Showing the original description.

tautcony/ChapterTool113Updated Oct 14, 2026

Archive multiple completed changes at once. Use when archiving several parallel changes.

The English summary is being prepared. Showing the original description.

tautcony/ChapterTool113Updated Oct 14, 2026

Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.

The English summary is being prepared. Showing the original description.

tautcony/ChapterTool113Updated Oct 14, 2026

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.

The English summary is being prepared. Showing the original description.

tautcony/ChapterTool113Updated Oct 14, 2026

Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.

The English summary is being prepared. Showing the original description.

tautcony/ChapterTool113Updated Oct 14, 2026

See all skills by tautcony

Report a problem with this skill