heymaikol/network-doctor

Why this matters Network Doctor ships six hand-maintained shell completion files: packaging/completions/netdoc.bash packaging/completions/netdoc.zsh packaging/completions/netdoc.fish packaging/completions/netdoc-sim.bash packaging/completions/netdoc-sim.zsh packaging/completions/netdoc-sim.fish The repository already has strong Go tests that compare their declared commands, flags, profiles, and other values with the real CLI. Those structural tests do not replace asking the actual shells whether the scripts are syntactically valid. A malformed quote, continuation, condition, or shell-specific expression could therefore survive the Go synchronization tests. What to do Add a fast CI check that syntax-parses all shipped completion scripts with their respective shells. For example: bash -n packaging/completions/netdoc.bash bash -n packaging/completions/netdoc-sim.bash zsh -n packaging/completions/netdoc.zsh zsh -n packaging/completions/netdoc-sim.zsh fish -n packaging/completions/netdoc

Why this matters Network Doctor already ships Bash, Zsh, and Fish completion scripts. Bash and Fish can offer local filenames for snapshot-oriented commands such as --compare and offline --two-sided. The Zsh completion currently leaves the positional argument generic because ordinary Network Doctor targets are hostnames, URLs, or IP literals. As a result, Zsh users do not get useful file completion when the positional arguments are known to be .ndoc snapshots. What to do Make the Zsh completion context-sensitive enough that: netdoc --compare <TAB> offers local snapshot files, and: netdoc --two-sided <TAB> does the same for offline two-sided comparison. When --two-sided is combined with --via, its positional argument is a live target rather than a local snapshot. Arbitrary local file completion should remain disabled there. Ordinary commands such as: netdoc example.com must continue to avoid irrelevant filename completion. Suggested starting points packaging/completions/netdoc.zsh p

Why this matters GoReleaser produces an Alpine APK for Network Doctor, but CI does not currently prove that the generated APK can be installed into a clean Alpine system and used normally. The installed package should provide both: netdoc netdoc-sim What to do Add an automated smoke test using a clean Alpine environment. The test should: Use the APK produced by the normal GoReleaser snapshot build. Install that local package using apk. Verify the package database records it. Run both installed executables. For example: apk add --allow-untrusted ./network-doctor_*.apk apk info -e network-doctor netdoc --version netdoc-sim version Use the local-package invocation appropriate for the generated artifact and Alpine version used by CI. Suggested starting points .goreleaser.yaml .github/workflows/ci.yml packaging_test.go README Linux installation documentation #40 Done when A freshly generated APK is installed in a clean Alpine environment. Installation uses apk, not manual archive ext

Why this matters Network Doctor's CI already builds the release RPM and inspects its file list, but it does not install the RPM through a real RPM package-management environment. That leaves a gap between the archive containing the expected files and a user actually being able to install the package. The release package should install both: netdoc netdoc-sim What to do Add an isolated automated smoke test for the RPM produced by the normal GoReleaser snapshot build. A clean Fedora container or equivalent RPM-based environment is a reasonable approach. The test should: Take the freshly generated *_linux_amd64.rpm. Install it through the normal RPM package-management path, preferably dnf. Run the installed netdoc. Run the installed netdoc-sim. Verify the package manager considers network-doctor installed. For example: dnf install -y ./network-doctor_*.rpm netdoc --version netdoc-sim version rpm -q network-doctor Suggested starting points .github/workflows/ci.yml .goreleaser.yaml pac

Why this matters Network Doctor has a deliberately thorough validation gate, including platform-specific, integration, race, fuzz, packaging, and other checks. That is useful for releases and CI, but a new contributor making a small focused change should also have one obvious command that answers: Did I run the normal fast checks expected before opening a pull request? The goal is to improve contributor ergonomics without weakening the full validation gate. What to do Add one documented fast local validation command. For example: ./scripts/check The exact mechanism is open to implementation: a shell script, Make target, Go helper, or another small portable solution that fits the repository. It should run the fast, portable checks appropriate for an ordinary contributor workstation while leaving platform-specific and expensive validation to CI or the full gate. Potential checks include, where appropriate: formatting ordinary unit tests architecture invariants lightweight static check