跳到正文
cccskills
免费在 GitHub 公开

wfa-platform-services

Phase C of a WinForms-to-Avalonia migration: implement platform and infrastructure adapters for dependencies discovered in Phase A/B, such as persistence, process execution, dialogs, notifications, or environment capabilities. Use only in an explicit migration when such dependencies leak into Forms/core or when the orchestrator routes here. Do not invent adapters for capabilities the product does not have, and do not implement main-window XAML.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(4)

  • SKILL.md4.0 KB
  • references/external-processes.md1.1 KB
  • references/platform-abstraction.md1.2 KB
  • references/settings-migration.md1.2 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Phase C — Platform / Infrastructure services

Replace legacy static helpers and environment coupling with injectable, testable adapters.

Read platform abstraction to define ports, external processes only when the product launches child processes, and settings migration only when settings exist.

Workflow

1. Catalog touchpoints

Legacy patternService direction
UI prompts hidden in helpershost-owned interaction port
Static notifications or loggingstructured diagnostic/logging port
Persisted application preferencestyped, versioned store
Filesystem or process callsnarrow adapter with cancellation and failure semantics
Environment capability checkscapability query plus supported/unsupported result
Legacy deployment integrationreplace, isolate, or explicitly retire

2. Interfaces vs implementations

  • Abstractions consumable without Avalonia types where possible
  • Implementations in Infrastructure, or in the UI host when they require a UI lifetime

3. Persisted state, when present

Evolve toward a versioned single document when multiple stores appear:

  • schemaVersion + sections
  • Ordered migrators
  • Reject future versions (do not overwrite with defaults)
  • Preserve predecessor data while migration is being validated
  • Validate the complete document before commit
  • Write to a temporary sibling, flush as required, then atomically replace
  • Preserve the last known-good state when parsing or migration fails
  • Define in-process and cross-process coordination from the actual deployment model

4. External processes, when present

  • Argument arrays, never shell string concatenation with user-controlled values
  • Timeout + cancellation
  • Distinguish not-found vs started-but-failed
  • Document selection and fallback policy

Unavailable dependencies return a structured unavailable result without changing product state.

5. Dependency-backed adapters

Implement the ports defined in Phase B and test success, failure, cancellation, timeout, and partial-result cleanup with fakes or controlled integration fixtures.

6. Secondary-surface API only

Use a narrow host interaction/window service for secondary surfaces; XAML belongs in Phase D.

7. Logging

Structured logging; bounded UI buffer with events after append; localize at display time.

Corrections seen in practice

  • Resolve optional dependencies according to documented product policy, not a universal search order.
  • Account for platform differences in process I/O, paths, permissions, and lifecycle when relevant.
  • Prefer portable implementations when cross-platform support is an explicit requirement.
  • Use one transaction boundary for one logical settings update.
  • Treat migration as validated best effort, not a promise of lossless conversion.
  • Do not silently change product defaults without an explicit decision.

Deliverables

  • Service interfaces + registration
  • Persisted-state store and migration story when persistence exists
  • Required platform adapters implemented; absent capabilities were not invented
  • Environment-dependent adapters covered with fakes or integration tests
  • Unsupported platform behavior is explicit and recoverable
  • Persisted writes are versioned, validated, and durable when persistence exists
  • No UI prompts or direct environment calls leak into the application core

Handoff

  • UI → wfa-avalonia-ui
  • Post-port product evolution -> wfa-post-port-evolve

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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

中文简介正在准备中。当前显示原文说明。

tautcony/ChapterTool1132026年10月14日 更新

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

中文简介正在准备中。当前显示原文说明。

tautcony/ChapterTool1132026年10月14日 更新

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

中文简介正在准备中。当前显示原文说明。

tautcony/ChapterTool1132026年10月14日 更新

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.

中文简介正在准备中。当前显示原文说明。

tautcony/ChapterTool1132026年10月14日 更新

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.

中文简介正在准备中。当前显示原文说明。

tautcony/ChapterTool1132026年10月14日 更新

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.

中文简介正在准备中。当前显示原文说明。

tautcony/ChapterTool1132026年10月14日 更新

查看 tautcony 的全部技能

报告此技能的问题