**Milestone Goal:** Users can customize how traffic sounds via a TOML config file — setting custom frequencies, waveform types, and their own classification rules with named sounds.
- [x]**Phase 5: Waveform Types and Bank Decoupling** - Internal refactors establishing waveform enum and injectable bank signature (completed 2026-03-26)
- [ ]**Phase 6: Config Package and Sound Overrides** - TOML loading, auto-discovery, partial merge, and frequency/waveform overrides wired end-to-end
- [ ]**Phase 7: Custom Rules and Print-Config** - User-defined classification rules and --print-config UX
## Phase Details
### Phase 5: Waveform Types and Bank Decoupling
**Goal**: Four waveform types are available per traffic class, and the synthesis bank accepts an injected config map instead of reading global state
**Depends on**: Phase 4
**Requirements**: WAVE-01, WAVE-02
**Success Criteria** (what must be TRUE):
1. User can set a traffic class to square, sawtooth, or triangle waveform and hear a tonally distinct sound with no audible aliasing or buzzing artifacts
2. Sine waveform continues to produce the same output as v1.0 — no regression
3. The synthesis bank builds layers from a passed-in config map rather than a hardcoded class list
**Goal**: Users can create a TOML config file to override frequency and waveform per traffic class, with auto-discovery, partial override semantics, and clear validation errors
1. User creates a `netsynth.toml` in the working directory with a custom Hz value and the tool uses that frequency for the specified class without touching other classes
2. User runs the tool with no flags in a directory without a config file — it starts silently (no warning about missing config)
3. User passes `--config /path/to/custom.toml` and the tool uses that file; if the file does not exist, the tool exits with a clear error before capture begins
4. User types `frequncy = 440` in their config file and the tool exits at startup with an error naming `frequncy` as an unrecognized key
5. User sets waveform for one class in TOML and leaves all other classes at their defaults — the unspecified classes are unchanged
**Goal**: Users can define their own traffic classification rules in TOML, assign custom sounds to them, and inspect the full effective config before capture begins
1. User adds a `[[rules]]` block in TOML matching a custom port/protocol combination and hears a distinct tone for that traffic in the output MP3
2. User-defined rules fire before built-in protocol rules — a custom rule for port 443 overrides the default HTTPS classification for packets on that port
3. A user-defined class name gets its own synthesis layer automatically — no silence or missing audio for traffic matched by a custom rule
4. User runs `netsynth --print-config` and sees the full effective config (defaults merged with their overrides) as commented TOML, without starting a capture
