Traffic-Proccessor: Instructions file for Codex

AGENTS.md – Traffic Processor (TP)

This file is the maintained public guide for coding agents working in the Traffic Processor repository. It focuses on actionable setup, workflow, and safety instructions. For human‑oriented onboarding, see README.md. For detailed team processes, see docs/development-process.md.

---

1. Setup, Build, Test, and Verification Commands

All development is containerised with Docker and Docker Compose. No system‑wide dependencies beyond Docker are required.

1.1 Quick Start

# Clone the repository
git clone https://github.com/SWP-Team-46/Traffic-Proccessor.git
cd Traffic-Proccessor/src

# Build and start all services (TP, CNSS, PostgreSQL, etc.)
docker compose up --build

1.2 Run Linters and Tests (CI‑aligned)

The CI pipeline uses flake8 for syntax checking and pytest for unit tests. Run them locally to catch issues before opening a PR:

# Install Python dependencies (if not using Docker)
pip install netifaces scapy pytest pytest-cov requests flake8

# Lint (syntax‑only checks)
flake8 src/ --count --select=E9,F63,F7,F82 --show-source --statistics

# Run tests with coverage
pytest src/ --cov=src/ --cov-report=xml --cov-report=html --maxfail=1 --disable-warnings -v

1.3 Build and Smoke‑Test the Docker Images

cd src
docker compose build
docker compose up -d
# Wait a few seconds for services to initialise, then check that all expected containers are running
docker ps --filter "status=running" --format "table {{.Names}}" | grep -E "tproc|cnss|cn|postgres"
docker compose down

2. Repository Workflow and Review Expectations

We follow a modified GitHub Flow with a long‑lived main branch. All changes are submitted via Pull Requests (PRs). The canonical workflow is documented in docs/development-process.md; the key points for agents are:

• Branch naming: feature/<issue-id>-short-description, bugfix/..., hotfix/..., chore/..., or docs/....
• Pull Requests:
  • Must link to at least one GitHub Issue.
  • Must use the PR template (automatically provided).
  • Require at least one approval from a team member other than the author.
  • Must pass all CI checks (linting, tests, Docker build, smoke test).
• Merging: Use “Squash and merge” to keep history clean, unless the PR is a release or hotfix where preserving individual commits is justified.
• Definition of Done: An issue is done when all acceptance criteria are met, the PR is approved, CI is green, the PR is merged, and the issue is closed (see docs/definition-of-done.md).