diff --git a/README.md b/README.md
index 01caf76..e9eca54 100644
--- a/README.md
+++ b/README.md
@@ -79,6 +79,9 @@ This framework can be used to:
 
 ## 🔧 Technical Documentation
 
+- [Architecture](docs/architecture.md)
+- [Design notes](docs/design.md)
+- [Roadmap](docs/roadmap.md)
 - [Development workflow and CI](docs/development-workflow.md)
 
 ---
diff --git a/docs/architecture.md b/docs/architecture.md
index e69de29..b964ca1 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -0,0 +1,236 @@
+# MicroC2 Architecture
+
+MicroC2 is an academic C2 research testbed for controlled, authorized lab
+environments. The current implementation is a Go management server, a Rust
+agent, and a static browser UI. It is useful as a prototype and research base,
+but several security, persistence, tasking, and transport boundaries are still
+being stabilized.
+
+This document describes the repository as it exists today. It deliberately marks
+partially wired features and prototype assumptions so future work can start from
+the real implementation rather than the original thesis target alone.
+
+## Runtime Topology
+
+```text
+Operator browser
+  |  HTTPS + WebSocket
+  v
+Go server / operator API
+  |  creates listeners, queues commands, stores files and payload builds
+  v
+HTTP(S) listener instances
+  |  polling endpoints
+  v
+Rust agents
+  |  heartbeat, command poll, result submission
+  v
+In-memory task/result state on the server
+```
+
+The server hosts both operator-facing routes and agent-facing routes in one
+process. Listener instances can bind additional ports for agent polling, but
+operator UI/API routes, WebSockets, and listener management are still registered
+on the same default `net/http` mux. Splitting operator and agent surfaces is
+tracked by #75.
+
+## Repository Layout
+
+| Path | Role |
+| --- | --- |
+| `server/cmd/server.go` | Server entry point, config loading, route registration, TLS startup. |
+| `server/config/` | YAML config types and defaults for the Go server. |
+| `server/internal/listeners/` | Listener lifecycle, configuration persistence, start/stop/delete logic. |
+| `server/internal/behaviour/` | HTTP polling protocol used by active agents. |
+| `server/internal/handlers/api/` | Operator APIs for agents, listeners, payloads, file drop, and SOCKS5 management. |
+| `server/internal/handlers/web/` | Static UI serving. |
+| `server/internal/handlers/ws/` and `server/internal/websocket/` | Log streaming and server terminal WebSockets. |
+| `server/internal/filestore/` | Operator file-drop storage helper. |
+| `server/internal/protocols/` | SOCKS5 server/protocol experiments. |
+| `server/web/` | Static HTML, CSS, and JavaScript operator UI. |
+| `agent/src/main.rs` | Agent bootstrap, OPSEC-gated main loop, SOCKS5/pivot task setup. |
+| `agent/src/config.rs` and `agent/build.rs` | Build-time embedded config, fallback config loading, HTTP client setup. |
+| `agent/src/commands/` | HTTP polling, shell command execution, result submission, command obfuscation helpers. |
+| `agent/src/opsec.rs` | Adaptive OPSEC scoring and mode transitions. |
+| `agent/src/dormant.rs` and `agent/src/state.rs` | In-memory state protection helpers. |
+| `agent/src/file_handling/` | Upload/download helpers, not fully wired into active dispatch yet. |
+| `agent/src/networking/` | Egress helper, SOCKS5 client, and pivot frame/server code. |
+
+## Server
+
+The server starts from `server/cmd/server.go`. Startup loads
+`server/config/settings.yaml`, opens `server.log`, initializes the file store,
+creates a communication manager, registers HTTP routes, and starts an HTTPS
+server using the configured certificate and key. When redirect support is
+enabled, a separate HTTP listener redirects to the configured HTTPS port.
+Current implementation note: `server.tls.enabled` exists in configuration, but
+the entry point always starts the main server with `ListenAndServeTLS`.
+
+The current server uses Go's default HTTP mux for most routes. That keeps the
+prototype simple, but it also means route ownership and trust boundaries are not
+strongly expressed in code yet. Unknown `/api/*` paths currently fall through to
+a generic `{"status":"ok"}` response, which can hide unsupported UI calls.
+
+### Operator Routes
+
+| Route | Current owner | Purpose |
+| --- | --- | --- |
+| `/home/` | `internal/handlers/web` | Static UI pages and assets. |
+| `/static/` | `internal/handlers/web` | Static files and generated artifacts. |
+| `/api/listeners/create` | `internal/handlers/api` | Create and start a listener. |
+| `/api/listeners/list` | `internal/handlers/api` | List listeners. |
+| `/api/listeners/{id}` | `internal/handlers/api` | Get or delete a listener. |
+| `/api/listeners/{id}/start` | `internal/handlers/api` | Start a stopped listener. |
+| `/api/listeners/{id}/stop` | `internal/handlers/api` | Stop a running listener. |
+| `/api/agents/list` | `internal/handlers/api` | Aggregate agents across listeners. |
+| `/api/agents/{id}/command` | `internal/handlers/api` | Queue a raw command string for an agent. |
+| `/api/agents/{id}/results` | `internal/handlers/api` | Fetch stored command results. |
+| `/api/file_drop/upload` | `internal/handlers/api` | Upload operator files into the server file store. |
+| `/api/file_drop/list` | `internal/handlers/api` | List operator file-drop contents. |
+| `/api/file_drop/download/{name}` | `internal/handlers/api` | Download a file-drop item. |
+| `/api/file_drop/delete/{name}` | `internal/handlers/api` | Delete a file-drop item. |
+| `/api/payload/generate` | `internal/handlers/api/payload` | Build an agent payload from a listener and payload config. |
+| `/api/payload/download/{id}` | `internal/handlers/api/payload` | Download a generated payload tracked in memory. |
+| `/ws/logs` | `internal/handlers/ws` | Stream recent and live server logs. |
+| `/ws/terminal` | `internal/handlers/ws` | Browser-accessible shell on the server host. |
+
+The operator APIs and WebSockets currently lack a complete authentication,
+authorization, origin, and CSRF boundary. The server terminal can execute shell
+commands on the host running MicroC2 and should be treated as a local lab-only
+tool until #75 and #78 are complete.
+
+### Agent Listener Routes
+
+HTTP(S) listener instances use `server/internal/behaviour/http_polling.go`.
+Each listener exposes routes under `/api/agent/{agent_id}/...` on the listener's
+bound host and port.
+
+| Route | Method | Purpose |
+| --- | --- | --- |
+| `/api/agent/{agent_id}/heartbeat` | `POST` | Agent reports ID, OS, host, IPs, and last-seen data. |
+| `/api/agent/{agent_id}/command` | `GET` | Agent polls for the next queued raw command string. |
+| `/api/agent/{agent_id}/result` | `POST` | Agent submits one command result. |
+| `/api/agent/{agent_id}/tasks` | `GET` | Placeholder currently returning an empty task list. |
+| `/api/agent/{agent_id}/results` | `POST` | Alias path handled as result submission in the current dispatcher. |
+
+The active protocol stores agents, command queues, and result history in memory.
+Server restart loses this state. Durable storage is a Phase 1 roadmap item.
+
+### Listener Lifecycle
+
+`ListenerManager` owns listener creation, listing, start, stop, delete, and
+port-conflict checks. Listener configs are written as JSON under
+`static/listeners/{listener_name}/config.json` and loaded at startup without
+auto-starting the listeners.
+
+HTTP and HTTPS listener protocols are implemented. DNS and DNS-over-HTTPS are
+explicitly rejected as not implemented. SOCKS5 code exists under
+`server/internal/protocols`, but the primary listener creation path supports
+HTTP(S) today.
+
+### Payload Builder
+
+The payload generator is a server-side wrapper around the Rust agent build
+script. It requires a selected listener, derives the connection URL from that
+listener, writes an agent `config.json`, invokes `agent/build.sh`, and tracks the
+generated payload in memory for download.
+
+Current limitation: the payload ID is the listener ID. That couples listener,
+payload build, and runtime agent identity. Issue #64 tracks separating listener
+ID, payload/build ID, and runtime agent ID.
+
+### Storage
+
+Current storage is intentionally simple:
+
+- Listener configs: JSON files under `static/listeners/`.
+- Operator uploads: configured server upload directory, default `uploads`.
+- Payload artifacts: `static/payloads/{debug,release}/{payload_id}`.
+- Server logs: `server.log`, streamed to `/ws/logs`.
+- Agent registry, command queues, results, and generated payload registry:
+  in-memory Go maps.
+
+There is no database or migration layer yet.
+
+## Agent
+
+The Rust agent loads an embedded build-time config generated by `agent/build.rs`.
+If no valid embedded config exists, it falls back to `.config/config.json` beside
+the executable. Config includes the server URL, payload ID, protocol, sleep and
+jitter settings, SOCKS5 settings, TLS verification behavior, user-agent, and
+OPSEC threshold parameters.
+
+At runtime the agent:
+
+1. Runs a Windows-only dormant startup gate before initialization.
+2. Loads config and creates the HTTP client.
+3. Starts SOCKS5/pivot background tasks when configured.
+4. Enters an OPSEC assessment loop.
+5. Sends heartbeat data when allowed.
+6. Polls for one command at a time.
+7. Executes shell commands with a timeout.
+8. Obfuscates command output with the agent ID as key material.
+9. Submits results back to the HTTP polling listener.
+
+The agent uses raw command strings as the active task format. A typed task/result
+model is planned but not implemented yet.
+
+### OPSEC Engine
+
+`agent/src/opsec.rs` is the strongest current research component. It keeps an
+encrypted in-memory OPSEC state and uses a score-driven mode system:
+
+| Mode | Current behavior |
+| --- | --- |
+| `BackgroundOpsec` | Normal communication and command processing. |
+| `ReducedActivity` | Heartbeat-only behavior with longer sleeps; command work is deferred. |
+| `FullOpsec` | No C2 communication; only periodic reassessment. |
+
+Signals include business hours, user activity, process/window analysis signals,
+C2 instability, recent noisy commands, correlation bonuses, hysteresis, and
+configurable minimum mode durations. Windows has WinAPI-backed idle/window
+checks. Non-Windows platforms use simpler user/process heuristics and do not
+currently implement window title checks.
+
+### File Transfer And Pivot Modules
+
+File upload/download helpers exist under `agent/src/file_handling/`, and
+SOCKS5/pivot types exist under `agent/src/networking/`. The active command loop
+does not yet expose a complete operator command grammar for file transfer or
+pivot start/stop. `pivot_start` and `pivot_stop` helper functions exist but are
+not wired into the active dispatch path. Issue #88 tracks completing that
+integration, and #71 tracks SOCKS5/pivot maturity.
+
+## Static UI
+
+The UI is static HTML/CSS/JavaScript served by the Go server. Current pages
+cover:
+
+- Dashboard and agent command submission.
+- Listener creation and lifecycle actions.
+- Payload generation and download.
+- File drop upload, list, download, and delete.
+- Server terminal.
+
+The UI talks directly to the REST and WebSocket routes listed above. It does not
+currently have a separate frontend build system. A few UI paths are ahead of the
+backend:
+
+- dashboard command submission still contains a hard-coded `8080` API base in
+  one path, while the default HTTPS UI/API port is `8443`;
+- agent removal calls `DELETE /api/agents/{id}`, which has no real handler yet;
+- listener and file-drop JavaScript reference EventSource streams that are not
+  registered by the server.
+
+## Current Prototype Gaps
+
+The main gaps are tracked as issues:
+
+- #75: separate operator UI/API/WebSocket routes from agent-facing endpoints.
+- #78: add lab-safety hardening for auth, origins, TLS defaults, and file paths.
+- #64: separate listener, payload/build, and runtime agent identities.
+- #88: wire file transfer and pivot controls into active command dispatch.
+- #65: finish the agent configuration system and optional OPSEC feature gating.
+
+Until those are complete, MicroC2 should be treated as a controlled lab research
+prototype rather than a hardened multi-user operations platform.
diff --git a/docs/design.md b/docs/design.md
index e69de29..0f96364 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -0,0 +1,236 @@
+# MicroC2 Design Notes
+
+MicroC2 was created as a bachelor's thesis prototype for studying lightweight,
+context-aware command and control behavior in controlled lab environments. The
+long-term project goal is broader: make it a polished, reproducible research
+testbed for C2, payload, agent, and detection engineering without hiding the
+prototype-grade parts that still need work.
+
+This document captures the design intent and the current implementation status.
+For component and route details, see [architecture.md](architecture.md). For
+sequencing, see [roadmap.md](roadmap.md).
+
+## Design Goals
+
+- Keep the core small enough to understand, test, and extend.
+- Prefer stable lifecycle behavior over adding more protocols too early.
+- Make risky operator actions explicit, scoped, and eventually audited.
+- Use asynchronous polling and structured server-side queues as the baseline
+  communication model.
+- Treat OPSEC as contextual behavior instead of relying only on binary
+  obfuscation.
+- Keep research features behind documented configuration and tests.
+- Preserve a clear lab-safety boundary: authorized, isolated environments only.
+
+## Core Model
+
+MicroC2 has three primary roles:
+
+| Role | Responsibility |
+| --- | --- |
+| Operator UI | Browser interface for listeners, agents, payload generation, files, logs, and terminal access. |
+| Server | Coordination point for operator APIs, listeners, payload builds, file storage, command queues, and results. |
+| Agent | Rust runtime that reports status, polls for commands, executes allowed work, and submits results under OPSEC control. |
+
+The current command path is intentionally simple:
+
+1. The operator selects an agent in the UI and submits a raw command string.
+2. The server finds the listener that knows that agent ID.
+3. The command is appended to an in-memory queue for that agent.
+4. The agent polls `/api/agent/{agent_id}/command`.
+5. The agent executes or queues the command depending on OPSEC mode.
+6. The agent posts the result to `/api/agent/{agent_id}/result`.
+7. The UI reads result history through `/api/agents/{agent_id}/results`.
+
+This proves the end-to-end thesis workflow, but it is not the final tasking
+model. The next design step is typed tasks and typed results, so shell, file
+transfer, pivot control, heartbeat, and future module tasks can share schemas,
+status transitions, timeouts, and audit metadata.
+
+## Server Design
+
+The Go server was chosen for its standard-library networking, simple deployment,
+and straightforward concurrency model. The server uses mutex-protected maps for
+prototype state and goroutines for listeners, redirects, and WebSocket
+connections.
+
+Current strengths:
+
+- Listener lifecycle is centralized in `ListenerManager`.
+- HTTP(S) listeners have explicit start, stop, delete, port conflict, and config
+  persistence behavior.
+- Operator APIs and static UI are small and easy to inspect.
+- The payload builder can generate agent builds from selected listener config.
+- CI now runs context-aware Go, Rust, static/script, format, and Foxguard checks.
+
+Current constraints:
+
+- Operator and agent routes still share one server process and route namespace.
+- Agent registry, command queues, result history, and generated payload registry
+  are in memory.
+- Operator APIs and WebSockets do not yet have complete auth/origin safety.
+- File handling still needs stricter basename and path validation.
+- The server terminal is powerful and should remain local-lab only until safety
+  controls exist.
+
+The intended direction is to split surfaces first, then harden them:
+
+```text
+Operator UI/API/WebSockets -> auth, origin checks, audit, local-lab defaults
+Agent listener endpoints   -> minimal polling API, stable task/result schemas
+Payload builder            -> reproducible profiles and build provenance
+Storage                    -> durable agents, tasks, results, files, events
+```
+
+## Agent Design
+
+The Rust agent was chosen for memory safety, static builds, and cross-platform
+potential. It is structured around a build-time config, an OPSEC state machine,
+HTTP polling, command execution, and optional networking helpers.
+
+The active implementation supports:
+
+- Embedded XOR-obfuscated JSON config generated by `build.rs`.
+- Fallback config loading from `.config/config.json`.
+- Direct or SOCKS5-proxied HTTP client creation.
+- Heartbeats with host, OS, local IP, and egress metadata.
+- Raw shell command polling and result submission.
+- Basic command timeout handling.
+- Result obfuscation before submission.
+- Adaptive OPSEC scoring and mode transitions.
+- In-memory encryption helper for OPSEC state.
+
+Partially wired or prototype areas:
+
+- File upload/download helpers exist but are not reachable through a stable
+  operator command grammar yet.
+- Pivot frame/server code exists, but command dispatch does not fully expose
+  pivot start/stop.
+- Payload, listener, and runtime agent identity are currently coupled.
+- OPSEC is runtime-configurable in several places, but not fully feature-gated.
+- Cross-platform behavior is uneven: Windows has richer user/window checks,
+  while non-Windows checks are simpler.
+
+## OPSEC Design
+
+The thesis design emphasized behavioral adaptation: the agent should reduce
+activity when the environment looks risky instead of constantly trying to
+out-obfuscate analysis. The current OPSEC engine implements that idea with a
+score, dynamic thresholds, and three modes.
+
+Signals include:
+
+- Business hours.
+- User activity.
+- Analysis or security process indicators.
+- Suspicious foreground window titles where supported.
+- C2 communication instability.
+- Recent noisy command execution.
+- Correlation bonuses when several signals are active together.
+
+The OPSEC system uses hysteresis and minimum residence times to avoid rapid mode
+flapping. `BackgroundOpsec` is the only mode that performs normal command
+processing. `ReducedActivity` keeps only limited heartbeat behavior. `FullOpsec`
+stops C2 communication and periodically reassesses.
+
+This is a good research foundation, but it should be made more testable before
+more advanced behavior is added. The next useful design improvements are
+injectable signal providers, deterministic scoring tests, and clearer policy
+metadata on task types.
+
+## Payload Design
+
+Payload generation is listener-driven today. The operator selects a listener,
+the server derives the agent connection settings, writes a config file, invokes
+the Rust build script, and stores the artifact for download.
+
+The current design is convenient for a prototype but has one important flaw:
+the listener ID is reused as the payload ID and agent ID. That makes it hard to
+reason about one listener serving many payload builds or many runtime agents.
+Several payload UI options are also aspirational today: indirect syscalls, custom
+sleep techniques, DLL sideloading metadata, shellcode output, and an OPSEC
+checkbox are passed through parts of the UI/config/build path but are not a
+complete implemented payload feature set.
+
+The intended identity split is:
+
+| Identity | Meaning |
+| --- | --- |
+| Listener ID | Server-side network endpoint and protocol instance. |
+| Payload/build ID | Reproducible build artifact and embedded config. |
+| Agent runtime ID | One live or historical runtime agent instance. |
+
+Issue #64 should establish that split before larger workflow features depend on
+agent identity.
+
+## Transport Design
+
+HTTP(S) polling is the reference transport. It is the only transport that should
+be considered active and end-to-end today. The design keeps polling simple:
+agents initiate outbound requests, receive at most one command per poll, and
+submit results separately.
+
+SOCKS5 and pivot code exists on both server and agent sides, but this area is
+not yet a coherent product workflow. In server `socks5` mode, the server starts
+a direct SOCKS5 CONNECT proxy with management routes for tunnel listing,
+inspection, closing, and runtime config updates. That config update is currently
+in-memory only and does not rebind the listener. On the agent side, SOCKS5 config
+means the HTTP C2 client uses a SOCKS5 proxy through reqwest. The pivot frame
+modules are local/in-memory plumbing today, not a complete multi-hop transport.
+This area needs a typed command surface, integration tests, UI state, and clear
+ownership of tunnel lifecycle.
+
+New transports should not be added until the transport boundary is explicit.
+The desired boundary is:
+
+- Validated profile/config.
+- Start/stop lifecycle.
+- Agent enrollment and heartbeat behavior.
+- Task/result transport semantics.
+- Health/error telemetry.
+- Tests or a documented manual lab run.
+
+## Safety Design
+
+The current project must be operated as a lab-only prototype. Safe defaults are
+not complete yet. Near-term safety work should focus on the operator surface,
+because it contains listener management, payload generation, file operations,
+log access, and a server terminal.
+
+Design direction:
+
+- Bind operator UI/API to localhost by default where practical.
+- Add authentication before remote operator access.
+- Restrict WebSocket origins.
+- Make CORS origins explicit instead of wildcarded.
+- Keep insecure TLS behavior opt-in and visible.
+- Validate file names as basenames and avoid path traversal through joins.
+- Add audit events for listener, payload, file, terminal, and agent tasking.
+- Add clear docs for isolated lab deployment.
+
+This safety work is tracked primarily by #75 and #78.
+
+## Documentation And Testing Expectations
+
+Every major feature should have at least one of:
+
+- A unit test for pure logic.
+- An integration or smoke test for server/agent lifecycle.
+- A documented manual verification path when automation is too heavy.
+
+CI currently gives the project a baseline safety net. Future design work should
+keep new behavior within those checks instead of adding unchecked prototype
+paths.
+
+## Near-Term Design Priorities
+
+1. Finish this documentation pass (#87).
+2. Split operator and agent-facing route surfaces (#75).
+3. Add lab-safety hardening for auth, origins, file paths, and safe defaults
+   (#78).
+4. Fix listener/payload/runtime identity separation (#64).
+5. Define typed tasks and wire file transfer/pivot commands through that model
+   (#88).
+
+Those steps create the foundation for richer transports, durable evidence,
+automation APIs, and reporting without compounding prototype debt.
diff --git a/docs/roadmap.md b/docs/roadmap.md
index e69de29..00276f7 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -0,0 +1,298 @@
+# MicroC2 Roadmap
+
+MicroC2 should grow into a serious research testbed for controlled C2, agent,
+payload, and detection engineering. The quality target is not to clone any
+commercial framework feature-for-feature, but to reach the same level of
+coherence: reliable lifecycle behavior, strong operator workflows, documented
+architecture, reproducible builds, durable evidence, and clear safety controls.
+
+This roadmap treats MicroC2 as an academic and defensive research platform for
+authorized lab environments.
+
+## Product Principles
+
+- Build stable foundations before adding advanced capabilities.
+- Prefer typed tasks, structured results, and durable evidence over raw command
+  strings and ad hoc logs.
+- Keep risky actions explicit, scoped, audited, and disabled by default where
+  possible.
+- Treat the web UI, API, server, and agent as one product surface.
+- Keep extension points narrow and documented before adding more protocols.
+- Preserve reproducibility: every important workflow should have a local test,
+  scripted check, or documented manual verification path.
+
+## Quality Bar
+
+A mature MicroC2 release should provide:
+
+- Reliable listener, agent, file, task, and pivot lifecycle management.
+- Clear operator workflows for setup, tasking, results, payload generation, and
+  session review.
+- A typed command/task model with stable JSON schemas.
+- Transport abstractions that support multiple channels without duplicating
+  lifecycle logic.
+- Durable storage for agents, tasks, results, files, events, and audit records.
+- A test suite and CI baseline that blocks regressions in server and agent code.
+- Documentation good enough for a new researcher to build, run, test, and
+  safely extend the framework.
+
+## Long-Term North Star
+
+The long-term ambition is for MicroC2 to feel as feature-rich and polished as a
+high-end commercial C2 framework, while remaining a transparent academic
+research platform. In practice, that means MicroC2 should eventually provide the
+same kind of end-to-end completeness:
+
+- A polished multi-user operator console.
+- Clear separation between management, C2, redirector, and agent surfaces.
+- Rich payload generation with reproducible build profiles.
+- Multiple configurable communication channels.
+- Peer-to-peer and pivot workflows that are visible as a network graph.
+- A typed task/module system instead of raw command strings.
+- Automation APIs and event hooks for research workflows.
+- Durable audit logs, evidence bundles, and reporting.
+- ATT&CK mapping and detection engineering views.
+- Strong release hygiene, docs, tests, and upgrade paths.
+
+This is a multi-year target. The first releases should not try to match every
+advanced feature. They should build the foundations that make those features
+possible without turning the project into another prototype.
+
+Long-term maturity tracks:
+
+- **Operator Console**: dashboards, agent graph, listener health, task queues,
+  artifacts, timelines, reporting, dark/light themes, and keyboard-friendly
+  workflows.
+- **Agent And Tasking**: typed tasks, typed results, cancellation, timeouts,
+  retries, permissions, module metadata, and cross-platform test coverage.
+- **Payload Lab**: reproducible builds, profile presets, artifact formats,
+  signing metadata where applicable, config validation, and build provenance.
+- **Transport Lab**: configurable HTTP(S), SOCKS/pivoting, peer-to-peer links,
+  profile validation, redirector-aware deployment notes, and transport
+  observability.
+- **Automation Platform**: stable API, WebSocket events, scripting hooks,
+  import/export, and integration points for defensive tooling.
+- **Evidence And Detection**: structured session bundles, ATT&CK mapping,
+  indicators, telemetry export, and repeatable lab scenario comparison.
+- **Safety And Governance**: auth, roles, target scoping, risk metadata,
+  explicit confirmations, audit trails, and safe defaults for lab use.
+- **Release Engineering**: CI, regression tests, signed releases where
+  practical, changelogs, migration notes, and reproducible development setup.
+
+## Phase 0: Stabilize The Prototype
+
+Goal: make the current codebase predictable enough to build on.
+
+Focus areas:
+
+- Fix listener lifecycle, stop/start/delete behavior, and placeholder protocol
+  code.
+- Add baseline CI for Go server tests/builds and Rust agent checks/builds.
+- Separate operator UI/API surfaces from agent-facing endpoints.
+- Replace silent failures and fatal process exits with structured errors.
+- Add basic auth and local-lab safety defaults before exposing richer operator
+  features.
+- Populate architecture, design, and roadmap documentation from the thesis and
+  current implementation.
+
+Exit criteria:
+
+- `go test ./...` passes in `server/`.
+- Rust agent builds reproducibly in the documented local environment.
+- Listener create/start/stop/delete is covered by tests.
+- The README points to usable architecture, development, and safety docs.
+
+Candidate issues:
+
+- #86 `[Server] Fix listener lifecycle and remove placeholder protocol code` (complete)
+- #85 `[CI] Add baseline Go/Rust build and test checks` (complete)
+- #89 `[CI] Make format and Foxguard baseline checks blocking` (complete)
+- #87 `[Docs] Populate architecture, design, and roadmap docs from thesis/current code`
+- #75 `[Server] Separate UI and agent API endpoints`
+- #78 `[Security] Fix lab-safety and hardening bugs`
+
+## Phase 1: Make Operations Coherent
+
+Goal: make everyday operator workflows feel like one integrated product.
+
+Focus areas:
+
+- Define a typed task model for shell, file transfer, pivot control, heartbeat,
+  and future module tasks.
+- Replace raw string-only tasking as the primary API.
+- Store agents, tasks, results, files, listener events, and audit records
+  durably.
+- Build a consistent UI flow for agents, tasking, results, files, listeners,
+  payloads, and logs.
+- Add task status transitions: queued, dispatched, running, completed, failed,
+  cancelled, expired.
+- Add result schemas and evidence bundles that can be exported for research
+  reporting.
+
+Exit criteria:
+
+- An operator can create a listener, build an agent, receive a heartbeat, run a
+  typed task, inspect results, and export session evidence from the UI.
+- File transfer and pivot controls are integrated into task dispatch instead of
+  living as disconnected code paths.
+- Server restart does not erase critical session history.
+
+Candidate issues:
+
+- #88 `[Agent] Wire file transfer and pivot controls into command dispatch`
+- #65 `[Agent] Configuration System extension`
+- #64 `[ID Parsing and Agent Generation]`
+
+## Phase 2: Transport And Pivot Maturity
+
+Goal: make communication channels and pivots modular, testable, and observable.
+
+Focus areas:
+
+- Define a shared transport interface for agent C2 channels.
+- Make HTTP(S) polling the reference implementation with complete lifecycle
+  tests.
+- Harden SOCKS5 and reverse tunnel behavior with clear ownership between agent
+  and server.
+- Add transport profiles for jitter, working hours, host rotation, kill date,
+  retry policy, and proxy awareness.
+- Add network and listener telemetry suitable for detection engineering.
+- Keep new transport work scoped behind explicit configuration and tests.
+
+Exit criteria:
+
+- HTTP(S) polling and SOCKS/pivot flows are covered by integration tests.
+- Transport profiles are represented as validated config, not scattered fields.
+- The UI can show listener health, connected agents, task latency, and recent
+  transport errors.
+
+Candidate issues:
+
+- #71 `[Agent] - SOCKSv5 capability implementation completion`
+- #74 `[Agent] - Host Rotation`
+
+## Phase 3: Payload Build And Agent Quality
+
+Goal: make payload generation reliable, reproducible, and research-friendly.
+
+Focus areas:
+
+- Make payload build configuration explicit and versioned.
+- Support repeatable local builds for Linux, Windows, and macOS targets where
+  practical.
+- Add build metadata and provenance to generated payloads.
+- Reduce unnecessary dependencies and feature-gate optional capabilities.
+- Add agent self-checks for config parsing, task dispatch, and networking.
+- Keep advanced OPSEC research behind documented, opt-in lab flags.
+
+Exit criteria:
+
+- Payload builds are reproducible from documented commands.
+- Optional agent features can be enabled without bloating the default agent.
+- Agent command dispatch is testable without live C2 infrastructure.
+
+Candidate issues:
+
+- #79 `[Agent] Reduce dependencies as much as possible`
+- #67 `[Agent] - Source-Level Mutation Engine (Phase 1)`
+- #66 `[Agent] - Selective Encryption routine`
+
+## Phase 4: Extensibility And Research Modules
+
+Goal: let MicroC2 grow without turning the core into a pile of special cases.
+
+Focus areas:
+
+- Define a plugin/module boundary for server-side tools and agent-side tasks.
+- Add stable schemas for module inputs, outputs, permissions, and evidence.
+- Build a small module SDK or examples before adding many modules.
+- Consider read-only integrations with sibling research tools, such as BACillus,
+  through structured evidence rather than repo mergers.
+- Add ATT&CK mapping and tags at the task/module level for reporting and
+  detection work.
+
+Exit criteria:
+
+- A new module can be added without changing the core task/result pipeline.
+- Module results are visible in the UI and exportable in reports.
+- Risky module classes require explicit safety metadata and operator
+  confirmation.
+
+Candidate issues:
+
+- #73 `[Agent] - Beacon Object File (BOF) support`
+
+## Phase 5: Research-Grade Reporting And Detection
+
+Goal: make MicroC2 useful not only for running experiments, but for analyzing
+and explaining them.
+
+Focus areas:
+
+- Export session reports with agents, tasks, timelines, files, listener events,
+  and evidence.
+- Add ATT&CK technique mapping and custom research tags.
+- Add detection-oriented telemetry views: network profile, task timing, file
+  operations, and operator actions.
+- Add reproducible lab scenarios and baseline runs.
+- Document known indicators and defensive observations for each transport and
+  task family.
+
+Exit criteria:
+
+- A completed lab run can produce a report suitable for thesis, blue-team, or
+  detection engineering review.
+- Important actions have timestamps, actor identity, target scope, and evidence.
+- The project can compare behavior across releases.
+
+## Backlog: Advanced Research
+
+These items are valuable, but should wait until the core is stable and audited:
+
+- Additional transport channels.
+- Advanced payload packaging formats.
+- BOF-style extensibility.
+- OPSEC mutation research.
+- Cross-platform in-memory execution research.
+- Automated scenario orchestration.
+- Optional OT/BACnet assessment bridge through BACillus evidence bundles.
+
+## Phase 6: Full-Featured Research Platform
+
+Goal: converge the maturity tracks into a framework that is broad, polished,
+and pleasant to operate in real research exercises.
+
+Focus areas:
+
+- Multi-user operations with roles, workspaces, and audit history.
+- First-class automation API and event stream.
+- A module catalog with stable compatibility metadata.
+- Payload profile library with repeatable builds and test fixtures.
+- Transport profile library with validation and detection notes.
+- Rich reporting and timeline reconstruction.
+- Scenario templates for reproducible lab exercises.
+- Long-running stability tests for agents, listeners, pivots, and UI sessions.
+
+Exit criteria:
+
+- MicroC2 can support a complete authorized research exercise from setup to
+  report without manual database edits, ad hoc scripts, or undocumented steps.
+- A new operator can understand the workflow from docs and the UI alone.
+- A developer can add a module, transport, or payload profile through documented
+  extension points.
+- Releases can be compared by test results, scenario outputs, and documented
+  behavior changes.
+
+## Near-Term Order
+
+Recommended next sequence:
+
+1. Finish #87 docs so the current architecture and constraints are explicit.
+2. Start #75 to split operator and agent-facing route surfaces.
+3. Tackle #78 lab-safety hardening on top of the clearer route boundary.
+4. Fix #64 so listener, payload/build, and runtime agent identities are
+   separate.
+5. Tackle #88 to make agent tasking, files, and pivots coherent.
+
+This order keeps momentum while preventing the framework from accumulating more
+prototype debt.