Turn “my Harness profile breaks with many plugins installed” into “these one or two plugins are sufficient to reproduce it,” without trial-and-error edits to the real profile.
Primary users are Harness plugin users, plugin authors, and maintainers handling bug reports. Their job is not merely to make Harness boot again; it is to reduce a reproducible failure until ownership and next action become obvious.
The painful case is interaction failure. Sequentially disabling one plugin at a time can conclude that every plugin is healthy even though a pair or trio is incompatible.
The first release is an external CLI, not an in-process Harness plugin. A diagnostic component that depends on the failing plugin tree may disappear at the moment it is needed most. External execution also allows every trial to use a fresh Harness process and a disposable home.
The unit of reduction is an out-of-tree profile bundle: a name present in both the profile's ordered bundle list and its dependency map. Built-in bundles stay fixed because they belong to the Harness installation, not the user's plugin selection.
- Prove the full candidate set fails.
- Prove the empty candidate baseline passes.
- Test complements and subsets with delta debugging, using a fresh shadow home for every probe attempt.
- Treat inconsistent repeated probes as unresolved.
- Verify that removing any one final item stops the failure.
- Emit a reviewable report and verify the source-profile fingerprint.
- Repairing or quarantining plugins.
- Replacing startup guards, plugin managers, doctors, or repro exporters.
- Reducing built-in Harness components or arbitrary individual Cordis rows.
- Claiming a globally minimum set.
- Sandboxing untrusted plugin code.
- Automatically uploading diagnostics.
For the first public milestone:
- Detect the known A+B interaction fixture on all three desktop operating systems.
- Never mutate source profile configuration in reducer-owned code paths.
- Produce a report with no known absolute local paths or common token forms.
- Receive at least three real-world reports that either isolate a plugin or correctly prove the failure is outside the out-of-tree candidate set.
- Convert one maintainer conversation into an agreed machine-readable profile inspection/reporting seam, whether or not the whole CLI moves upstream.
- 0.1: config/Web/custom probes, 1-minimal sets, scrubbed reports.
- 0.2: a zero-probe candidate preview, added after hands-on use showed that users need to verify scope before starting a reduction.
- 0.3: ordered-prefix reduction for order-sensitive layer bugs and a report viewer, only after real reports show demand.
- 0.4: optional session-level oracle adapter and CI reproduction action.
- Upstream: standardize profile inspection and diagnostic report metadata;
consider an official
dsh plugin reducecommand after cross-platform usage.
The roadmap intentionally avoids building a marketplace, manager, or generic doctor: those areas already have active projects.