sysdiagnose-public adoption: third validation of dazzlecmd-lib across a different domain

[djdarcy]

Summary

Adopt dazzlecmd-lib as the engine powering a unified sysdiag CLI for the sysdiagnose-public project. Serves as a third-party validation of the library (after dazzlecmd itself and wtf-windows in Phase 4d Phase 2), with domain vocabulary substantially different from wtf's diagnostic-tool model.

Context

sysdiagnose-public (at the user's local C:/code/sysdiagnose-public) currently holds:

• monitoring/ — ongoing system monitoring utilities (process watchers, pool-tag observers)
• poc/ — vendor bug-report proof-of-concept scripts (notably the amdkmdag.sys kernel zombie-leak POC submitted to AMD and Microsoft)
• guard/ — active protection / blocking
• docs/ / logs/ / private/

Each of these is a candidate "tool" in dazzlecmd-lib terms. The aggregator would be sysdiag, and its tools would be dispatchable as sysdiag monitor pool-watch, sysdiag poc amd-zombie-leak, sysdiag guard block-<signature>, etc.

Why this matters for dazzlecmd-lib

1. Third adopter = library validation. Phase 4d Phase 2 will close with wtf-windows as the second adopter. sysdiagnose-public as a third proves "aggregator-agnostic" across wildly different domains:

   • wtf-windows → user-invoked diagnostics ("why did my PC restart?")
   • sysdiagnose-public → security research, vendor bug reports, long-running monitoring
   • dazzlecmd → dev utilities

2. Domain-vocabulary stress test. sysdiagnose commands will include monitor, capture, submit, probe, check, block. These collide with nothing the library reserves today — good. But sysdiag list / sysdiag info are very weak names for a diagnostic CLI compared to sysdiag monitors, sysdiag pocs, sysdiag guards. This will be the first real demand for the root-command-namespace flexibility feature (see related issue).

3. Long-running tool dispatch (new runtime pattern for this project). Some sysdiagnose tools run for hours (kernel pool monitoring). Tests the library's dispatch semantics under a different lifecycle than wtf's "invoke-and-return."

4. Production bug-report workflow. The AMD POC (zombie-leak) is a real submitted bug report. Encoding that as sysdiag poc amd-zombie-leak --capture --submit exercises:

   • dispatch + setup + artifact collection
   • multi-step command chains
   • potentially docker/VM-runtime (isolated reproduction environments)

Acceptance criteria

• sysdiagnose-public/pyproject.toml declares dazzlecmd-lib>=X.Y.Z as dependency
• sysdiagnose-public/src/sysdiag_cli/cli.py (or similar) constructs AggregatorEngine(name="sysdiagnose", command="sysdiag", ...) and delegates to engine.run()
• sysdiagnose-public declares kits/ and tools/ per dazzlecmd-lib conventions, OR continues using its own layout via engine kwargs (document which)
• Existing monitoring / POC / guard scripts become tools dispatchable via sysdiag <tool>
• AMD POC runs end-to-end: sysdiag poc amd-zombie-leak reproduces + captures the expected artifacts
• At least one tool uses a runtime type that wtf-windows doesn't stress-test (candidates: docker-isolated repro, long-running monitor with signal handling, PowerShell-heavy privilege-escalation scripts)
• Human test checklist produced + tester-agent sweep passes
• Documentation (README): "why sysdiagnose uses dazzlecmd-lib" and "how to add a new monitor / POC / guard as a tool"

Dependencies / blocks / related

• Depends on: dazzlecmd-lib: extract AggregatorEngine as an importable library package #27 (dazzlecmd-lib extraction) — done
• Depends on: EPIC: Phase 4 -- library extraction, polyglot dispatch, scaffolding redesign, ecosystem validation #30 (Phase 4 epic) Phase 2 completion (wtf-windows adoption)
• Likely drives: root-command-namespace flexibility feature (nest under subcommand, rename defaults, selective exposure at root)
• Related: Recursive kit PoC: wtf-windows as a DazzleCMD-pattern aggregator #13 (recursive kit PoC), wtf-windows full integration experiment: sandboxed adoption + 3-tier nesting validation #28 (wtf-windows integration)

Status

Not started. Gated on Phase 4d Phase 2 (wtf-windows) completing in dazzlecmd repo + its upstream wtf-windows commit. Likely scheduled for v0.8.x timeline after PyPI publish.

Notes for maintainers

• Design note: notes/cli/2026-04-18__20-41-16__both_sysdiagnose-adoption-and-root-command-namespace-flexibility.md (project-private)
• sysdiagnose-public is a security-research repo; adoption PR should preserve its existing bug-report-workflow integrity during refactor
• The AMD POC README (in sysdiagnose-public) has detailed reproduction steps; expect the sysdiag CLI to wrap those steps, not replace them