ShareX/ShareX

Can another program use it through a documented, machine-readable surface?

• next: L1 Launchable by other programs with input: command-line arguments, a URL scheme or file associations. (no arguments, URL scheme or file associations)

desktop ladder · level 0

• ✗ L1 Launchable by other programs with input: command-line arguments, a URL scheme or file associations. no arguments, URL scheme or file associations
• ✓ L2 An automation interface: AppleScript, App Intents/Shortcuts, D-Bus, COM, IPC commands, or a local API. ShareX.Tools/Controls/Media/WindowsVideoOnlySource.cs 6 matchesShareX.HelpersLib/Native/WshShell.cs 2 matches
• ✗ L3 Its functions run without the GUI (a headless/batch mode or a companion CLI). nothing runs without the GUI
• ✗ L4 The automation interface is specified machine-readably (an AppleScript sdef, D-Bus introspection XML, App Intents, an OpenAPI spec, MCP). no machine-readable automation contract

Can integrators rely on it not changing under them?

• next: L2 A changelog exists and marks breaking changes. (no changelog)

all ladder · level 1

• ✓ L1 Releases are versioned (semver tags or versioned changelog sections). 94 semver tags, latest v21.0.0
• ✗ L2 A changelog exists and marks breaking changes. no changelog
• ✓ L3 A deprecation mechanism is used in code (warnings, @deprecated, Deprecation/Sunset headers) or the API is versioned. ShareX.HelpersLib/Native/NativeEnums.cs 2 matches
• ✓ L4 Across tagged releases, no OpenAPI operation, CLI option or __all__ symbol was removed without first being deprecated. 20 tagged releases compared

Can others react to state changes without polling?

Can a machine act with its own revocable, least-privilege identity?

Can its data get in and out, in bulk, in open formats, with an explicit schema?

Can an automated caller use it without guessing, and recover from failure?

• next: L1 In headless mode, failures end with a non-zero exit status instead of a dialog. (no headless mode for automated callers)

desktop ladder · level 0

• ✗ L1 In headless mode, failures end with a non-zero exit status instead of a dialog. no headless mode for automated callers
• ✗ L2 In headless mode, data goes to stdout and diagnostics to stderr. no headless mode for automated callers
• ✗ L3 Documented exit statuses distinguish error classes, and headless output is machine-readable (JSON). no headless mode for automated callers
• ✗ L4 Dry-run for side-effecting operations, and agent docs. no headless mode for automated callers

Can another system run and compose it without a human?

• next: L1 Buildable from source with documented steps (a README with commands). (no documented build steps)

desktop ladder · level 0

• ✗ L1 Buildable from source with documented steps (a README with commands). no documented build steps
• ✓ L2 Packaged as an installer (dmg/pkg, MSI/MSIX, AppImage/Flatpak/Snap, electron-builder, Tauri bundle, PyInstaller). ShareX.Setup/InnoSetup/ShareX-setup.iss
• ✓ L3 Distributed for unattended installation: a package manager (Homebrew cask, winget, Chocolatey, Flathub, Snap) or release artifacts built in CI. .github/workflows/build.yml 2 matches
• ✗ L4 Settings can be managed without the GUI: documented environment variables or config file, macOS defaults/MDM profiles, or Windows policies. settings only change through the GUI

Can behaviour be added without modifying the code?

• next: L2 The docs show how to add behaviour through those seams (even in-tree). (no registration functions to document)

all ladder · level 1

• ✓ L1 Internal seams: a registry, registration function or plugin manager. ShareX.ImageEditor/Presentation/Effects/DiscoveredEffectRegistry.cs 1 matchShareX.ImageEditor/Presentation/Views/Dialogs/EffectDialogRegistry.cs 1 match
• ✗ L2 The docs show how to add behaviour through those seams (even in-tree). no registration functions to document
• ✗ L3 Out-of-tree extensions are discovered (entry points, a plugin directory, configuration) without editing the package. extensions must be added inside the package
• ✗ L4 The extension API is versioned, has lifecycle hooks, and has example extensions. no lifecycle hooks

Can an operator, or an orchestrating agent, tell whether it works and why not?

• next: L1 Writes logs through a standard logger (os_log/Logger, electron-log, logging, Qt categories). (no standard logging)

desktop ladder · level 0

• ✗ L1 Writes logs through a standard logger (os_log/Logger, electron-log, logging, Qt categories). no standard logging
• ✓ L2 Log verbosity can be raised for diagnosis (--verbose/--debug, a log-level setting). ShareX.ImageEditor/Integration/LinuxDesktopWallpaperService.cs 1 match
• ✗ L3 Crashes are reported (Sentry, Crashpad/Breakpad, Crashlytics, MetricKit). no crash reporting
• ✗ L4 Tracing or metrics (OpenTelemetry). no tracing

Can an agent change it safely with limited context?

• next: L1 A README and some tests. (no tests)

all ladder · level 0

• ✗ L1 A README and some tests. no tests
• ✗ L2 CI runs the tests; applications pin dependencies (libraries and zero-dependency projects are exempt). no lockfile (applications should pin dependencies)
• ✗ L3 At least 90% of modules fit 32k tokens and no file exceeds 12k; test/source token ratio at least 0.3; at least 70% of the code is typed. 92% of modules fit 32k tokens; 14 files over 12k; test/source token ratio 0.00 < 0.3
• ✗ L4 No import cycles, and agent docs (AGENTS.md, CLAUDE.md, llms.txt). no agent docs (AGENTS.md, CLAUDE.md, llms.txt)