**Milestone Goal:** Expand traffic classification with grouped protocol families that share recognizable sound signatures — from 14 classes to ~35, organized into frequency bands by family.
- [x]**Phase 8: Test and Constant Cleanup** - 1 plan — Remove stale constants and update test bounds that would block all subsequent v1.2 work (completed 2026-03-27)
- [ ]**Phase 9: Frequency Design and Group Architecture** - 2 plans — Design complete Hz allocation for all ~35 classes in family bands and add Group field to FreqConfig
- [ ]**Phase 10: Classification Layer** - Add ~21 new TrafficClass constants and port rules covering all new protocol families
- [ ]**Phase 11: Synthesis and Config Layer** - Add ClassFreqConfigs entries for all new classes, update auto-assign range, and add group-header output to --print-config
## Phase Details
### Phase 8: Test and Constant Cleanup
**Goal**: Pre-existing test assertions and a stale exported constant that would block or mislead all subsequent v1.2 work are removed
**Depends on**: Phase 7
**Requirements**: CLEAN-01
**Success Criteria** (what must be TRUE):
1.`go test ./...` passes on main with no modifications to the new v1.2 code path
2. The stale `NumLayers`/`GainPerLayer` exported constant no longer exists in the synth package — callers cannot accidentally use it
3.`TestFrequenciesInRange` accepts the new extended Hz range without manual test surgery when new classes are added in Phase 10
### Phase 9: Frequency Design and Group Architecture
**Goal**: A complete, documented frequency allocation table for all ~35 traffic classes exists and the FreqConfig struct carries a Group field — design decisions are locked in before any protocol code is written
1. A written frequency allocation table (in a planning doc or code comment) lists every built-in class, its Hz value, waveform, and group — no class is TBD
2. Every within-family pair of frequencies satisfies at least a major second interval (ratio 1.122), verifiable by inspection of the table
3. The `autoAssignFreq` base for user-defined custom classes is set above all built-in frequencies, with no collision possible
4.`FreqConfig` has a `Group` string field and all existing `ClassFreqConfigs` entries compile with the new struct shape
**Goal**: All new protocol families are classified — ~21 new TrafficClass constants exist, AllClasses() covers them, and DefaultRules maps all new ports to their classes
1. A packet arriving on any new protocol port (e.g., TCP 143, TCP 3389, TCP 3306, UDP 5353, TCP 5060) is classified into the correct named TrafficClass, not into other-TCP or other-UDP
2. All existing 10 protocol classifications continue to match as before — no regression in rule order or port assignments
3. Multiple ports mapping to the same family class (e.g., IMAP port 143 and IMAPS port 993 both classify as the same Mail-IMAP class) behave identically in the classifier output
4.`go test ./classify/...` passes with no new test failures
**Plans**: TBD
### Phase 11: Synthesis and Config Layer
**Goal**: Every new traffic class produces a distinct, family-coherent sound and --print-config shows all classes organized by group with section headers
**Depends on**: Phase 9, Phase 10
**Requirements**: GRP-02, GRP-03
**Success Criteria** (what must be TRUE):
1. Running `netsynth --print-config` shows all ~35 classes grouped by family with section header comments (e.g., `# Mail`, `# Database`) — no class is listed without a group
2. A pcap or live capture that triggers Mail traffic produces tones that are audibly in the same timbral family — same waveform type, similar frequency register — while still being distinguishable from each other
3. Users can define `[groups]` in their TOML config to reassign a protocol to a different sound family, and --print-config reflects the reassignment
4.`go test ./...` passes and a listening test on a representative pcap confirms family identity is perceptually clear
