gurix/yoloyolo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: archive v1.0 MVP milestone

Browse Source 
Archive roadmap and requirements to milestones/, reorganize ROADMAP.md,
evolve PROJECT.md with shipped state, create retrospective.

4 phases, 11 plans, 16/16 requirements — all complete.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
gurix
2026-03-26 15:23:04 +01:00
co-authored by Claude Opus 4.6
parent c8659d0579
commit 2c9a049728
7 changed files with 245 additions and 204 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/MILESTONES.md
+16
View File
@@ -0,0 +1,16 @@
# Milestones
## v1.0 MVP (Shipped: 2026-03-26)
**Phases completed:** 4 phases, 11 plans, 9 tasks
**Key accomplishments:**
- Config-driven packet classifier with 12 protocol rules (ICMP, DNS, HTTPS, SSH, etc.) and 4 hash-bucketed unknown classes
- Live packet capture via go-pcap with privilege detection, non-blocking channel pipeline, and atomic drop counter
- Additive synthesis engine: per-class sine oscillators, EMA amplitude smoothing, constant-power stereo panning
- MP3 encoding via embedded LAME (go-lame v0.0.9), zero-packet guard, `-o` flag with timestamp default
- End-to-end pipeline: capture -> classify -> aggregate -> synthesize -> MP3 with clean Ctrl+C shutdown
- BPF filter support (`--filter`) and offline pcap file sonification (`--read`) with timestamp-based windowing
---
.planning/PROJECT.md
+39 -49
View File
@@ -2,40 +2,39 @@
## What This Is
A Go CLI tool that captures live network traffic on an interface, clusters and classifies the packets by protocol/pattern, and synthesizes an ambient MP3 soundscape where each traffic type produces a distinct harmonic drone or tone. Run it, let it listen, hit Ctrl+C, and get an audio fingerprint of your network.
A Go CLI tool that captures live network traffic on an interface, classifies packets by protocol, and synthesizes an ambient MP3 soundscape where each traffic type produces a distinct harmonic drone or tone. Supports live capture with BPF filtering and offline pcap file sonification.
## Core Value
Network traffic patterns are instantly recognizable as distinct sounds — a ping sounds different from HTTPS noise, which sounds different from a port scan.
## Current State
**v1.0 MVP shipped 2026-03-26.** 3,254 lines of Go across 6 packages.
Tech stack: gopacket/gopacket v1.5.0, packetcap/go-pcap (pure Go capture), sjzar/go-lame v0.0.9 (embedded LAME), spf13/cobra v1.10.2.
All 16 v1 requirements validated. Full pipeline working: capture -> classify -> aggregate -> synthesize -> MP3.
## Requirements
### Validated
### Validated (v1.0)
- [x] Capture live packets from a specified network interface until interrupted (Ctrl+C) — Validated in Phase 1
- [x] Classify packets by known protocols (ICMP, TCP/HTTPS, DNS, SSH, etc.) using predefined rules — Validated in Phase 1
- [x] Aggregate traffic into time windows to drive amplitude and tonal evolution — Validated in Phase 1
- [x] CLI interface with flags for interface selection and output file path — Validated in Phase 1 (interface flags; output flag in Phase 2)
### Validated in Phase 4
- [x] BPF capture filter — users can scope live capture with tcpdump-syntax expressions — Validated in Phase 4
- [x] Offline pcap file input — users can sonify historical pcap files without live capture — Validated in Phase 4
- Capture live packets from a specified network interface until Ctrl+C
- Classify packets by known protocols (ICMP, DNS, HTTPS, SSH, etc.) with 12 predefined rules
- Auto-cluster unrecognized traffic into 4 hash-bucketed unknown classes with distinct tones
- Aggregate traffic into 500ms time windows driving amplitude evolution
- End-to-end pipeline: capture -> classify -> synthesize -> MP3 output
- Map each traffic class to a distinct ambient/drone layer (sine oscillators + EMA smoothing)
- Stereo mixing with constant-power panning, no distortion
- MP3 encoding via embedded LAME, zero-packet guard
- CLI with `-i`, `-o`, `--list-interfaces`, `--verbose`, `--filter`, `--read` flags
- BPF capture filter for scoping live traffic
- Offline pcap file sonification with timestamp-based windowing
### Active
(None — all requirements validated through Phase 4)
### Validated in Phase 3
- [x] Auto-cluster unrecognized traffic patterns and assign them unique tones — Validated in Phase 3 (hash-bucketed into 4 unknown classes with distinct dissonant tones)
- [x] End-to-end pipeline: capture → classify → synthesize → MP3 output — Validated in Phase 3
### Validated in Phase 2
- [x] Map each traffic class to a distinct harmonic/drone sound layer — Validated in Phase 2
- [x] Synthesize ambient/drone audio from the layered sound mappings — Validated in Phase 2
- [x] Encode and save output as MP3 file — Validated in Phase 2
(None — next milestone requirements TBD)
### Out of Scope
@@ -46,46 +45,37 @@ Network traffic patterns are instantly recognizable as distinct sounds — a pin
## Context
- Built in Go for single-binary distribution and performance
- Needs packet capture (likely pcap/gopacket) — may require elevated privileges
- Audio synthesis in Go is less common than Python; will need to evaluate libraries
- MP3 encoding requires an encoder library or CGo bindings (e.g., LAME)
- The "ambient/drone" style means layered sine/harmonic waves that evolve slowly based on traffic volume and mix, not discrete note triggers
- Built in Go (CGO_ENABLED=1 for LAME), single binary output
- Packet capture requires root/CAP_NET_RAW on Linux
- Pure Go capture layer (no libpcap dependency)
- MP3 encoding embeds LAME C source (no system library needed)
- 14 traffic classes: 10 known protocols + 4 hash-bucketed unknowns
## Constraints
- **Language**: Go — user preference, single binary output
- **Privileges**: Packet capture requires root/CAP_NET_RAW on Linux
- **Audio format**: MP3 output (not WAV or raw PCM)
- **Interaction model**: Non-interactive capture (run → Ctrl+C → file saved)
- **Interaction model**: Non-interactive capture (run -> Ctrl+C -> file saved)
## Key Decisions
| Decision | Rationale | Outcome |
|----------|-----------|---------|
| Go over Python/Rust | User preference, single binary, good perf | — Pending |
| Ambient/drone style | Layered tones better represent continuous traffic patterns | — Pending |
| Predefined + auto-cluster | Known protocols get recognizable sounds; unknown traffic still represented | — Pending |
| File output only | Simpler v1, avoids real-time audio complexity | — Pending |
| Go over Python/Rust | User preference, single binary, good perf | Good |
| Ambient/drone style | Layered tones better represent continuous traffic patterns | Good |
| Predefined + auto-cluster | Known protocols get recognizable sounds; unknown traffic still represented | Good |
| File output only | Simpler v1, avoids real-time audio complexity | Good |
| go-pcap over libpcap | Pure Go, no CGo for capture, cross-compilation friendly | Good |
| go-lame (embedded C) over shine-mp3 | Better quality, smaller files, acceptable CGo tradeoff | Good |
| Hand-rolled synthesis over audio libraries | 20 lines of oscillator code, no unnecessary dependencies | Good |
| Hash-bucketed unknowns over k-means | Deterministic, zero-config, sufficient for v1 audio distinction | Good |
| Ordered []Rule classifier over switch | Configurable, extensible, first-match-wins semantics | Good |
| 500ms window duration | Balances temporal resolution against snapshot frequency for synthesis | Good |
## Evolution
This document evolves at phase transitions and milestone boundaries.
Last updated: 2026-03-26 — Phase 4 (Power User Features) complete. All v1.0 milestone phases delivered.
**After each phase transition** (via `/gsd:transition`):
1. Requirements invalidated? → Move to Out of Scope with reason
2. Requirements validated? → Move to Validated with phase reference
3. New requirements emerged? → Add to Active
4. Decisions to log? → Add to Key Decisions
5. "What This Is" still accurate? → Update if drifted
**After each milestone** (via `/gsd:complete-milestone`):
1. Full review of all sections
2. Core Value check — still the right priority?
3. Audit Out of Scope — reasons still valid?
4. Update Context with current state
---
*Last updated: 2026-03-26 after Phase 4 completion*
*Last updated: 2026-03-26 after v1.0 milestone*
.planning/RETROSPECTIVE.md
+48
View File
@@ -0,0 +1,48 @@
# Retrospective
## Milestone: v1.0 — MVP
**Shipped:** 2026-03-26
**Phases:** 4 | **Plans:** 11 | **Timeline:** 3 days (2026-03-24 -> 2026-03-26)
**LOC:** 3,254 Go | **Files:** 84 modified
### What Was Built
- Config-driven packet classifier with 12 protocol rules and 4 hash-bucketed unknown classes
- Live packet capture via pure Go go-pcap with privilege detection and non-blocking channel pipeline
- Additive synthesis engine: per-class oscillators, EMA amplitude smoothing, constant-power stereo mixing
- MP3 encoding via embedded LAME, zero-packet guard
- End-to-end pipeline with clean Ctrl+C shutdown
- BPF filter and offline pcap file sonification with timestamp-based windowing
### What Worked
- Risk-ordered phases: hardest foundation first (capture), then synthesis in isolation, then integration — no phase blocked on another's bugs
- TDD approach in executor agents caught signature mismatches early
- Pure Go capture layer (go-pcap) avoided libpcap dependency headaches
- Hand-rolled synthesis kept dependencies minimal and code understandable
- Wave-based parallel execution for independent plans
### What Was Inefficient
- Some SUMMARY.md files had empty one-liner fields, causing noisy milestone extraction
- Phase 4 research could have been lighter — BPF/pcap APIs were straightforward
### Patterns Established
- Ordered []Rule slice for classifier (first-match-wins, extensible)
- io.Writer injection for testable stderr output
- Buffered channels between pipeline stages (512-1024) to absorb bursts
- Package-level globals for Cobra flag binding
- Timestamp-based windowing for non-live sources
### Key Lessons
- Embedding C source (go-lame) is a good tradeoff: CGo at build time only, no runtime dependency
- go-audio/wav was unnecessary — writing PCM bytes directly to LameWriter is simpler
- Hash-bucketed unknowns (4 classes) are sufficient for audio distinction without k-means complexity
## Cross-Milestone Trends
| Metric | v1.0 |
|--------|------|
| Phases | 4 |
| Plans | 11 |
| Days | 3 |
| LOC | 3,254 |
| Avg plan duration | ~8 min |
.planning/ROADMAP.md
+16 -83
View File
@@ -1,95 +1,28 @@
# Roadmap: NetSynth
## Overview
## Milestones
NetSynth is built in four phases ordered by technical risk. Phase 1 validates the hardest foundation: live packet capture and protocol classification without any audio code. Phase 2 builds the synthesis and encoding engine in isolation against synthetic inputs, resolving audio-specific pitfalls before integration. Phase 3 wires the two pipelines together with coordinated Ctrl+C shutdown and auto-clustering, delivering the complete v1 MVP. Phase 4 adds power-user features (BPF filter, offline pcap input) that extend the core without blocking it.
- **v1.0 MVP** — Phases 1-4 (shipped 2026-03-26)
## Phases
**Phase Numbering:**
- Integer phases (1, 2, 3): Planned milestone work
- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)
<details>
<summary>v1.0 MVP (Phases 1-4) — SHIPPED 2026-03-26</summary>
Decimal phases appear between their surrounding integers in numeric order.
- [x] Phase 1: Capture and Classification (4/4 plans) — completed 2026-03-25
- [x] Phase 2: Audio Synthesis Engine (3/3 plans) — completed 2026-03-26
- [x] Phase 3: Pipeline Integration and MVP (2/2 plans) — completed 2026-03-26
- [x] Phase 4: Power User Features (2/2 plans) — completed 2026-03-26
- [x] **Phase 1: Capture and Classification** - Live packet capture, protocol identification, and CLI scaffolding — no audio yet (completed 2026-03-25)
- [x] **Phase 2: Audio Synthesis Engine** - Oscillators, EMA amplitude smoothing, mixing, and MP3 encoding against synthetic inputs (completed 2026-03-26)
- [x] **Phase 3: Pipeline Integration and MVP** - Wire capture into synthesis, Ctrl+C with valid MP3 output, auto-clustering of unknown traffic (completed 2026-03-26)
- [x] **Phase 4: Power User Features** - BPF capture filter, offline pcap file input (completed 2026-03-26)
Full details: `.planning/milestones/v1.0-ROADMAP.md`
## Phase Details
### Phase 1: Capture and Classification
**Goal**: Users can run the CLI against a live interface and see a live protocol classification summary — the full capture-to-classify pipeline validated without audio
**Depends on**: Nothing (first phase)
**Requirements**: CAPT-01, CAPT-02, CAPT-04, CLAS-01, CLAS-03, CLAS-04
**Success Criteria** (what must be TRUE):
1. User can run `netsynth -i eth0` and see packets being classified live to stderr
2. User can run `netsynth --list-interfaces` and see all available network interfaces listed
3. User running without root/CAP_NET_RAW sees a clear error message with a `sudo` hint — not a panic or silent failure
4. On exit, user sees a per-protocol packet count summary printed to stderr
5. User can pass `--verbose` and see per-window protocol activity lines on stderr
**Plans:** 4/4 plans complete
Plans:
- [x] 01-01-PLAN.md — Go 1.24 setup, module init, shared types, config-driven classifier with tests
- [x] 01-02-PLAN.md — Capture package: OpenCapture, ListInterfaces, privilege error handling
- [x] 01-03-PLAN.md — Aggregation: time-windowed accumulator, exit summary, verbose output
- [x] 01-04-PLAN.md — CLI wiring: Cobra commands, signal handling, pipeline assembly, smoke test
### Phase 2: Audio Synthesis Engine
**Goal**: The synthesis and encoding stack produces a valid MP3 from synthetic WindowSnapshot inputs — audio pipeline fully validated before any real traffic flows through it
**Depends on**: Phase 1
**Requirements**: SYNTH-01, SYNTH-02, SYNTH-03, OUT-01, OUT-02, OUT-03
**Success Criteria** (what must be TRUE):
1. Given synthetic traffic snapshots, the tool produces an MP3 file that passes `ffprobe` validation
2. Each traffic class (ICMP, DNS, TCP/443, TCP/other, UDP, SSH) produces a perceptually distinct drone tone
3. Drone layer amplitude rises and falls with traffic volume over time — sustained traffic sounds louder, quiet periods fade
4. User can specify output path via `-o` flag; it defaults to `netsynth-<timestamp>.mp3` when omitted
5. An empty (zero-packet) input produces a clear error message instead of a corrupt or zero-byte MP3
**Plans:** 3/3 plans complete
Plans:
- [x] 02-01-PLAN.md — Environment setup (gcc, ffprobe, go-lame), synth config table, oscillator, EMA layer with tests
- [x] 02-02-PLAN.md — Stereo mixer (constant-power panning), OscillatorBank multi-layer rendering with tests
- [x] 02-03-PLAN.md — MP3 encoder package, zero-packet guard, -o CLI flag, ffprobe integration test
### Phase 3: Pipeline Integration and MVP
**Goal**: Live capture flows end-to-end into audio synthesis — the complete v1 MVP: run, capture, Ctrl+C, get an MP3
**Depends on**: Phase 2
**Requirements**: CAPT-03, CLAS-02
**Success Criteria** (what must be TRUE):
1. User runs `netsynth -i eth0 -o out.mp3`, generates traffic, presses Ctrl+C, and receives a valid playable MP3 at `out.mp3`
2. Unrecognized traffic patterns are automatically assigned distinct drone tones — unknown traffic is not silent or merged into a single undifferentiated layer
3. The MP3 audio reflects the actual traffic mix — a session with mostly DNS sounds different from one with mostly HTTPS
**Plans:** 2/2 plans complete
Plans:
- [x] 03-01-PLAN.md — Extend TrafficClass to 14 classes (hash-bucketed unknown-1 through unknown-4), update synth config with dissonant tones
- [x] 03-02-PLAN.md — Wire capture pipeline into RunSynthesis, encoding feedback messages, end-to-end MVP verification
### Phase 4: Power User Features
**Goal**: Users can scope capture with BPF expressions and sonify historical pcap files
**Depends on**: Phase 3
**Requirements**: CAPT-05, CAPT-06
**Success Criteria** (what must be TRUE):
1. User can run `netsynth -i eth0 --filter "port 53"` and only DNS traffic is captured and sonified
2. User can run `netsynth --read capture.pcap -o out.mp3` against an existing pcap file and receive a valid MP3
3. An invalid BPF filter expression produces a clear error message before any capture begins
**Plans:** 2/2 plans complete
Plans:
- [x] 04-01-PLAN.md — BPF validation, pcap file reading, timestamp-based aggregation (core library functions)
- [x] 04-02-PLAN.md — Wire --filter and --read flags into CLI with branching run logic
</details>
## Progress
**Execution Order:**
Phases execute in numeric order: 1 -> 2 -> 3 -> 4
| Phase | Plans Complete | Status | Completed |
|-------|----------------|--------|-----------|
| 1. Capture and Classification | 4/4 | Complete | 2026-03-25 |
| 2. Audio Synthesis Engine | 3/3 | Complete | 2026-03-26 |
| 3. Pipeline Integration and MVP | 2/2 | Complete | 2026-03-26 |
| 4. Power User Features | 2/2 | Complete | 2026-03-26 |
| Phase | Milestone | Plans Complete | Status | Completed |
|-------|-----------|----------------|--------|-----------|
| 1. Capture and Classification | v1.0 | 4/4 | Complete | 2026-03-25 |
| 2. Audio Synthesis Engine | v1.0 | 3/3 | Complete | 2026-03-26 |
| 3. Pipeline Integration and MVP | v1.0 | 2/2 | Complete | 2026-03-26 |
| 4. Power User Features | v1.0 | 2/2 | Complete | 2026-03-26 |
.planning/STATE.md
+22 -72
View File
@@ -1,10 +1,10 @@
---
gsd_state_version: 1.0
milestone: v1.0
milestone_name: milestone
status: Milestone complete
stopped_at: Completed 04-power-user-features 04-02-PLAN.md
last_updated: "2026-03-26T13:45:31.552Z"
milestone_name: MVP
status: v1.0 milestone complete
stopped_at: Milestone v1.0 archived
last_updated: "2026-03-26T14:50:00.000Z"
progress:
total_phases: 4
completed_phases: 4
@@ -16,98 +16,48 @@ progress:
## Project Reference
See: .planning/PROJECT.md (updated 2026-03-24)
See: .planning/PROJECT.md (updated 2026-03-26)
**Core value:** Network traffic patterns are instantly recognizable as distinct sounds — a ping sounds different from HTTPS noise, which sounds different from a port scan.
**Current focus:** Phase 04 — power-user-features
**Current focus:** Planning next milestone
## Current Position
Phase: 04
Plan: Not started
Phase: All v1.0 phases complete
Plan: N/A
## Performance Metrics
**Velocity:**
- Total plans completed: 0
- Average duration: —
- Total execution time: —
**By Phase:**
| Phase | Plans | Total | Avg/Plan |
|-------|-------|-------|----------|
| - | - | - | - |
**Recent Trend:**
- Last 5 plans: —
- Trend: —
*Updated after each plan completion*
| Phase 01 P01 | 4 | 2 tasks | 6 files |
| Phase 01 P03 | 8 | 2 tasks | 4 files |
| Phase 01-capture-and-classification P02 | 3min | 1 tasks | 4 files |
| Phase 01-capture-and-classification P04 | 15min | 2 tasks | 2 files |
| Phase | Duration | Tasks | Files |
|-------|----------|-------|-------|
| Phase 01 P01 | 4min | 2 tasks | 6 files |
| Phase 01 P02 | 3min | 1 tasks | 4 files |
| Phase 01 P03 | 8min | 2 tasks | 4 files |
| Phase 01 P04 | 15min | 2 tasks | 2 files |
| Phase 02 P01 | 15min | 2 tasks | 8 files |
| Phase 02 P02 | 10min | 2 tasks | 4 files |
| Phase 02 P03 | 3min | 2 tasks | 3 files |
| Phase 03-pipeline-integration-and-mvp P01 | 15min | 2 tasks | 6 files |
| Phase 03 P01 | 15min | 2 tasks | 6 files |
| Phase 03 P02 | 5min | 1 tasks | 1 files |
| Phase 04-power-user-features P01 | 3min | 2 tasks | 9 files |
| Phase 04-power-user-features P02 | 4min | 1 tasks | 2 files |
| Phase 04 P01 | 3min | 2 tasks | 9 files |
| Phase 04 P02 | 4min | 1 tasks | 2 files |
## Accumulated Context
### Decisions
Decisions are logged in PROJECT.md Key Decisions table.
Recent decisions affecting current work:
- Use `github.com/gopacket/gopacket` v1.5.0 (community fork) — NOT `google/gopacket` which is unmaintained
- Use `github.com/packetcap/go-pcap` for live capture (pure Go, no CGo for capture layer)
- Use `github.com/sjzar/go-lame` v0.0.9 for MP3 encoding (embeds LAME C source, CGo required at build time only)
- Audio synthesis: hand-rolled additive sine oscillators + EMA amplitude smoothing (no external audio library)
- Frequency table: register-separated harmonics (low drones = bulk traffic, mid = control, high = interactive)
- [Phase 01]: Go installed to /home/dev/tools/go-install/go (no sudo); PATH export required each session
- [Phase 01]: Classifier uses ordered []Rule slice with first-match-wins; no switch statement (D-02)
- [Phase 01]: ICMP checked before TCP/UDP in Classify to handle packets with no port info
- [Phase 01]: DefaultWindowMs=500: 500ms windows balance temporal resolution against snapshot frequency for audio synthesis
- [Phase 01]: io.Writer injection in PrintSummary/PrintWindowLine enables test capture via bytes.Buffer and production use via os.Stderr
- [Phase 01-capture-and-classification]: Use net.Interfaces() for listing (go-pcap has no FindAllDevs equivalent); privileges not required for enumeration
- [Phase 01-capture-and-classification]: StartCapture uses 512-buffered channel with atomic drop counter to prevent backpressure blocking capture goroutine
- [Phase 01-capture-and-classification]: Dynamic link type detection via handle.LinkType() not hardcoded LinkTypeEthernet
- [Phase 01-04]: Cobra RunE + signal.NotifyContext for clean shutdown: context cancellation is the single stop signal propagating through all three pipeline stages
- [Phase 01-04]: Three-stage pipeline: capture -> classify goroutine -> aggregate via buffered channels; 1024-buffered classified channel absorbs burst processing
- [Phase 02]: go-lame v0.0.9 used for MP3 encoding (embedded LAME C source, no system library needed)
- [Phase 02]: go-audio/wav excluded — writing PCM bytes directly to LameWriter is simpler (per Claude's Discretion grant in CONTEXT.md)
- [Phase 02]: GainPerLayer applied in bank.go during mixing to ensure 11 max layers sum to 1.0 (D-10)
- [Phase 02]: int16 conversion uses float * 32767 to avoid positive overflow at exactly +1.0
- [Phase 02]: RunSynthesis takes snapshot slice (not channel) enabling zero-packet guard before file creation
- [Phase 02]: EncodeMP3 and RunSynthesis are separate functions for independent testability
- [Phase 03-01]: hashBucket uses (dstPort*31 + protoNum*7) % 4 for deterministic 4-bucket unknown class assignment
- [Phase 03-01]: TestHashBucketDistribution uses minimal custom rules (not DefaultRules) because DefaultRules catch-all OtherTCP/OtherUDP prevent hashBucket from being reached
- [Phase 03-02]: PrintSummary called before RunSynthesis per D-08 — user sees traffic stats before waiting for encoding to complete
- [Phase 03-02]: Audio duration computed from snapshot count * DefaultWindowMs (not wall-clock) to avoid truncation for short captures
- [Phase 04-power-user-features]: OpenCapture/StartCapture accept filter string; empty = no filter (backward compatible with live mode)
- [Phase 04-power-user-features]: AggregatePcap: synchronous drain of events channel then assign to windows by Timestamp offset; gap windows pre-initialized with empty maps
- [Phase 04-02]: bpfFilter and readPath are package-level globals for Cobra flag binding (same pattern as other flags)
- [Phase 04-02]: runPcapMode checks for empty snapshots after PrintSummary so user sees zero-count table before error
- [Phase 04-02]: deriveOutputPath uses filepath.Ext (last extension only) matching tcpdump convention
All decisions archived in PROJECT.md Key Decisions table and `.planning/milestones/v1.0-ROADMAP.md`.
### Pending Todos
None yet.
None.
### Blockers/Concerns
- Phase 2: Frequency mapping requires subjective listening validation — specific Hz values not determined by research; must test during Phase 2
- Phase 3: Auto-clustering algorithm choice (hash-bucketing vs k-means) deferred until synthesis engine exists to evaluate perceptual results
- macOS privilege model (BPF device vs CAP_NET_RAW) not verified by research — flag if macOS is a target during Phase 1
None — all v1.0 blockers resolved.
## Session Continuity
Last session: 2026-03-26T13:42:19.476Z
Stopped at: Completed 04-power-user-features 04-02-PLAN.md
Last session: 2026-03-26T14:50:00.000Z
Stopped at: Milestone v1.0 archived
Resume file: None
.planning/REQUIREMENTS.md → .planning/milestones/v1.0-REQUIREMENTS.md
+9
View File
@@ -1,3 +1,12 @@
# Requirements Archive: v1.0 MVP
**Archived:** 2026-03-26
**Status:** SHIPPED
For current requirements, see `.planning/REQUIREMENTS.md`.
---
# Requirements: NetSynth
**Defined:** 2026-03-24
.planning/milestones/v1.0-ROADMAP.md
+95
View File
@@ -0,0 +1,95 @@
# Roadmap: NetSynth
## Overview
NetSynth is built in four phases ordered by technical risk. Phase 1 validates the hardest foundation: live packet capture and protocol classification without any audio code. Phase 2 builds the synthesis and encoding engine in isolation against synthetic inputs, resolving audio-specific pitfalls before integration. Phase 3 wires the two pipelines together with coordinated Ctrl+C shutdown and auto-clustering, delivering the complete v1 MVP. Phase 4 adds power-user features (BPF filter, offline pcap input) that extend the core without blocking it.
## Phases
**Phase Numbering:**
- Integer phases (1, 2, 3): Planned milestone work
- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)
Decimal phases appear between their surrounding integers in numeric order.
- [x] **Phase 1: Capture and Classification** - Live packet capture, protocol identification, and CLI scaffolding — no audio yet (completed 2026-03-25)
- [x] **Phase 2: Audio Synthesis Engine** - Oscillators, EMA amplitude smoothing, mixing, and MP3 encoding against synthetic inputs (completed 2026-03-26)
- [x] **Phase 3: Pipeline Integration and MVP** - Wire capture into synthesis, Ctrl+C with valid MP3 output, auto-clustering of unknown traffic (completed 2026-03-26)
- [x] **Phase 4: Power User Features** - BPF capture filter, offline pcap file input (completed 2026-03-26)
## Phase Details
### Phase 1: Capture and Classification
**Goal**: Users can run the CLI against a live interface and see a live protocol classification summary — the full capture-to-classify pipeline validated without audio
**Depends on**: Nothing (first phase)
**Requirements**: CAPT-01, CAPT-02, CAPT-04, CLAS-01, CLAS-03, CLAS-04
**Success Criteria** (what must be TRUE):
1. User can run `netsynth -i eth0` and see packets being classified live to stderr
2. User can run `netsynth --list-interfaces` and see all available network interfaces listed
3. User running without root/CAP_NET_RAW sees a clear error message with a `sudo` hint — not a panic or silent failure
4. On exit, user sees a per-protocol packet count summary printed to stderr
5. User can pass `--verbose` and see per-window protocol activity lines on stderr
**Plans:** 4/4 plans complete
Plans:
- [x] 01-01-PLAN.md — Go 1.24 setup, module init, shared types, config-driven classifier with tests
- [x] 01-02-PLAN.md — Capture package: OpenCapture, ListInterfaces, privilege error handling
- [x] 01-03-PLAN.md — Aggregation: time-windowed accumulator, exit summary, verbose output
- [x] 01-04-PLAN.md — CLI wiring: Cobra commands, signal handling, pipeline assembly, smoke test
### Phase 2: Audio Synthesis Engine
**Goal**: The synthesis and encoding stack produces a valid MP3 from synthetic WindowSnapshot inputs — audio pipeline fully validated before any real traffic flows through it
**Depends on**: Phase 1
**Requirements**: SYNTH-01, SYNTH-02, SYNTH-03, OUT-01, OUT-02, OUT-03
**Success Criteria** (what must be TRUE):
1. Given synthetic traffic snapshots, the tool produces an MP3 file that passes `ffprobe` validation
2. Each traffic class (ICMP, DNS, TCP/443, TCP/other, UDP, SSH) produces a perceptually distinct drone tone
3. Drone layer amplitude rises and falls with traffic volume over time — sustained traffic sounds louder, quiet periods fade
4. User can specify output path via `-o` flag; it defaults to `netsynth-<timestamp>.mp3` when omitted
5. An empty (zero-packet) input produces a clear error message instead of a corrupt or zero-byte MP3
**Plans:** 3/3 plans complete
Plans:
- [x] 02-01-PLAN.md — Environment setup (gcc, ffprobe, go-lame), synth config table, oscillator, EMA layer with tests
- [x] 02-02-PLAN.md — Stereo mixer (constant-power panning), OscillatorBank multi-layer rendering with tests
- [x] 02-03-PLAN.md — MP3 encoder package, zero-packet guard, -o CLI flag, ffprobe integration test
### Phase 3: Pipeline Integration and MVP
**Goal**: Live capture flows end-to-end into audio synthesis — the complete v1 MVP: run, capture, Ctrl+C, get an MP3
**Depends on**: Phase 2
**Requirements**: CAPT-03, CLAS-02
**Success Criteria** (what must be TRUE):
1. User runs `netsynth -i eth0 -o out.mp3`, generates traffic, presses Ctrl+C, and receives a valid playable MP3 at `out.mp3`
2. Unrecognized traffic patterns are automatically assigned distinct drone tones — unknown traffic is not silent or merged into a single undifferentiated layer
3. The MP3 audio reflects the actual traffic mix — a session with mostly DNS sounds different from one with mostly HTTPS
**Plans:** 2/2 plans complete
Plans:
- [x] 03-01-PLAN.md — Extend TrafficClass to 14 classes (hash-bucketed unknown-1 through unknown-4), update synth config with dissonant tones
- [x] 03-02-PLAN.md — Wire capture pipeline into RunSynthesis, encoding feedback messages, end-to-end MVP verification
### Phase 4: Power User Features
**Goal**: Users can scope capture with BPF expressions and sonify historical pcap files
**Depends on**: Phase 3
**Requirements**: CAPT-05, CAPT-06
**Success Criteria** (what must be TRUE):
1. User can run `netsynth -i eth0 --filter "port 53"` and only DNS traffic is captured and sonified
2. User can run `netsynth --read capture.pcap -o out.mp3` against an existing pcap file and receive a valid MP3
3. An invalid BPF filter expression produces a clear error message before any capture begins
**Plans:** 2/2 plans complete
Plans:
- [x] 04-01-PLAN.md — BPF validation, pcap file reading, timestamp-based aggregation (core library functions)
- [x] 04-02-PLAN.md — Wire --filter and --read flags into CLI with branching run logic
## Progress
**Execution Order:**
Phases execute in numeric order: 1 -> 2 -> 3 -> 4
| Phase | Plans Complete | Status | Completed |
|-------|----------------|--------|-----------|
| 1. Capture and Classification | 4/4 | Complete | 2026-03-25 |
| 2. Audio Synthesis Engine | 3/3 | Complete | 2026-03-26 |
| 3. Pipeline Integration and MVP | 2/2 | Complete | 2026-03-26 |
| 4. Power User Features | 2/2 | Complete | 2026-03-26 |