Contributing

fragcap is developed in the open. This page is the short version; the CONTRIBUTING.md in the repository is the practical how, and the constitution under .specify/ is the governing rule.

What fragcap will not accept

Capture is passive process-attributed packet capture. Deep Capture is explicit, target-scoped, reversible local proxy inspection for authorized sessions. Neither mode permits covert target instrumentation. A pull request using any of the following is declined regardless of how well it works:

• Packet interception or filtering drivers
• Code injection into any target process
• Function hooking
• Process handles carrying memory-read rights against a target
• Layered service providers or Winsock catalog modification
• Executable image modification
• Target TLS key extraction

If a capability seems to require one of these, open an issue rather than an implementation so the requirement can be checked against the architecture. Deep Capture may use a session-owned local proxy, target-scoped launch configuration, explicitly confirmed local CA trust, and proxy-owned TLS key-log material. It may not use silent system-wide proxying, silent trust, certificate-pinning bypass, or unreported cleanup residue. Copyleft-licensed dependencies are also declined.

Building

fragcap is a Rust workspace. Build and test it with Cargo:

cargo build --workspace
cargo test --workspace

Capture backends are behind feature flags, so the workspace builds and its logic is tested on any platform without a capture driver. The live capture path needs Npcap and runs only where it is installed. Npcap is never bundled or redistributed. After explicit interactive confirmation, the shipped fragcap doctor --fix opens the official download page. A source build with the optional net feature may instead fetch and launch the vendor's signed installer.

The check set

One command runs the same checks continuous integration runs:

cargo xtask ci

It runs formatting, Clippy with warnings denied, the test suite, and the repository's own conventions, dependency-direction, and license checks. Run it before opening a pull request; it is the same set the automated checks run, so the two cannot drift.

The workflow

• Changes reach main only through a pull request that a human reviews and approves. No one pushes to main directly.
• A feature goes through the spec-kit sequence first and lands as a numbered specs/NNN-slug/ slice. Bug fixes and documentation corrections do not need a slice.
• A new term gets a glossary entry in the same change that introduces it.
• Output stays readable by unmodified analyzers: compatibility outranks richness.

Published baseline: v0.10.3.

v0.10.3 is the current release, published 2026-09-29. CHANGELOG.md records the release history, specs/ records completed slices, and the open GitHub milestones show current workstreams. v0.10.2 included S154 through S158 documentation, review-intake, deterministic certification and Windows observation corrections; v0.10.3 adds bounded QUIC observation headroom and corrected interactive CLI input.

Documentation

This site is built from the repository. The glossary has a single source under docs/glossary/, and a linter checks that every entry is complete, that internal cross-links resolve, and that the alphabetical index is reproducible. The prose you are reading is authored under site/content/docs/.