DSH-P2M

Once a DSH installation accumulates a dozen or so plugins, the real friction rarely comes from any single add-on. It comes from collisions between them: duplicate service registrations overwriting each other, peer version declarations drifting from what actually resolves, and multiple patch layers handing contradictory configs to the same loader entry. The usual response is reactive - wait for a crash, dig through logs, and hope nothing got silently corrupted.

P2M turns that loop into an automated pipeline. On every boot it runs a full health check - boot-crash attribution, runtime auto-disable detection, and a static scan across all patch layers - then adjudicates priority under one fixed rule: DSH core always first, P2M second, every other plugin ranked by its cumulative usage time. Offenders are isolated into a single guard file that survives restarts, every decision is appended to an audit log, and rollback is one step away. Before any new plugin is activated, a subprocess trial gate catches import-level crashes and asks the user to cancel or proceed, so one bad add-on cannot take down the whole host.

It is built for power-users who are steadily growing their DSH plugin set and want a safety net that works without them untangling every conflict by hand. Zero runtime dependencies means P2M never introduces its own source of conflict, and any decision involving DSH core or P2M itself is report-only - never auto-disable.