بنقرة واحدة
sharex-architecture-and-porting
Platform abstraction rules, porting guidelines, and architecture standards for XerahS
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Platform abstraction rules, porting guidelines, and architecture standards for XerahS
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use the local ShareX checkout as the source of truth for ShareX.ImageEditor, find the latest upstream commit that touches it, and port or sync the matching changes into the XerahS ShareX.ImageEditor submodule with path-aware diffing and build gates.
Orchestrate XerahS release flow in strict order: run maintenance prep first, update-changelog second (optional only if docs/CHANGELOG.md is intentionally absent), verify build, bump/commit/push/tag while syncing Chocolatey version metadata, monitor GitHub Actions every 2 minutes, ensure standard release notes content, then set pre-release by default (use explicit opt-out for stable). On failures, inspect logs, fix root cause, and retry with the next patch release.
Rules and workflows for updating docs/CHANGELOG.md, including version grouping, aggressive consolidation, and GitHub tag-linked release headings.
Repository maintenance preparation for XerahS. Use before release or changelog work to sync repositories, inspect submodule state, identify version/changelog needs, and hand off commit/push/version rules to git-workflow.
Bring src/mobile-experimental Avalonia/MAUI mobile apps to feature and behavior parity with src/mobile/ios while preserving native platform feel. Use when comparing the Swift iOS app against XerahS.Mobile.Ava, XerahS.Mobile.Maui, or the experimental iOS share extension, implementing parity gaps, or validating Android/iOS experimental mobile flows.
Bring src/mobile/android to feature and behavior parity with src/mobile/ios while keeping each app native. Use when comparing iOS Swift/SwiftUI/UIKit mobile behavior against Android Kotlin/Jetpack Compose behavior, implementing missing Android features, or validating parity with the Test Android Apps emulator QA workflow.
| name | ShareX Architecture and Porting |
| description | Platform abstraction rules, porting guidelines, and architecture standards for XerahS |
All platform specific functionality must be isolated behind platform abstraction interfaces.
No code outside XerahS.Platform.* projects may reference:
Direct calls to Windows APIs are forbidden in Common, Core, Uploaders, Media, or other backend projects.
Define platform neutral interfaces in XerahS.Platform.Abstractions.
Implement Windows functionality in XerahS.Platform.Windows.
Create stub implementations for future platforms:
If a capability is Windows only:
UI and workflows must detect capability availability and disable or hide unsupported features.
A file may only be ported directly if it contains zero references to:
If a file mixes logic and native calls:
Native method names and signatures should remain Windows specific and must not leak into shared layers.
When porting ShareX.HelpersLib, files that reference:
must be treated as platform code and cannot be copied wholesale.
C:\Users\liveu\source\repos\ShareX Team\ShareX to understand existing non-UI logic and reuse it by copying into this repo after the Avalonia solution and projects are drafted.XerahS.Common: shared helpers, serialization, utilities.XerahS.Core: task settings, workflows, application-level services.XerahS.Uploaders: uploaders, config, OAuth, HTTP helpers.XerahS.History: history models and persistence.XerahS.Indexer: file indexing and search.XerahS.ImageEffects: filters/effects pipeline.XerahS.Media: encoding, thumbnails, FFmpeg integration.XerahS.ScreenCapture: capture engines and platform abstractions.XerahS.Platform.*: OS-specific implementations (Windows first, others later).XerahS.App and XerahS.UI: Avalonia UI and view models (defer until backend is ready).When asked to ensure feature parity with a specific historical commit or "make it identical to commit X":
ref directory: Create a temporary folder (e.g., src/XerahS/ref).git show <commit_hash>:<file_path> > src/XerahS/ref/<commit_short>_<filename> to verify the state of relevant files at that commit.ref directory once the task is complete and verified, unless instructed otherwise.This reduces git command overhead and provides a stable reference point for parity checks.