fix:readme issue --++

README.md

@@ -0,0 +1,158 @@
+---
+title: FirewatchEnv
+emoji: 🔥
+colorFrom: red
+colorTo: yellow
+sdk: docker
+app_port: 7860
+pinned: false
+tags:
+  - openenv
+  - reinforcement-learning
+  - sre
+  - agentic
+base_path: /web
+---
+# FirewatchEnv 🔥
+
+> **AIOps 2.0 incident response RL environment** — fills a real gap in the open-source AI SRE tooling landscape.
+
+[![openenv](https://img.shields.io/badge/OpenEnv-compatible-blue)](https://github.com/meta-pytorch/OpenEnv)
+[![HF Space](https://img.shields.io/badge/HuggingFace-Space-orange)](https://huggingface.co/spaces/10doshi12/firewatch-env)
+
+
+## 1. Environment Description & Motivation
+
+FirewatchEnv is a **genuine RL training environment** for autonomous SRE incident response. An AI agent acts as an on-call Site Reliability Engineer, receiving simulated microservice production telemetry (OTel-compatible metrics, Prometheus alerts, log excerpts) and must diagnose and remediate the root cause before the SLO error budget runs out.
+
+### Why this environment fills a real gap
+
+The 2026 AI SRE landscape has many commercial agents (Azure SRE Agent, Datadog Bits AI, Komodor Klaudia AI) but **no portable RL training environment**. Existing academic benchmarks — AIOpsLab (Microsoft Research, MLSys 2025), ITBench (IBM), SRE-bench — all require a full Kubernetes cluster and multi-GB Docker images. They are not portable, not deployable to HuggingFace Spaces, and not OpenEnv-spec compliant.
+
+FirewatchEnv is the first OpenEnv-spec compliant SRE training environment:
+- Runs in a single Docker container, no Kubernetes, no external cloud credentials
+- 2 vCPUs and 8GB RAM sufficient
+- Deployable to HuggingFace Spaces in one command
+
+### Novel mechanics
+
+1. **Adversarial telemetry (Task 3):** One red herring service emits a log line containing an embedded prompt injection attempt. A naive agent follows the injected instruction and acts on a healthy service. A robust agent verifies metrics and ignores it. This mirrors the 2026 SRE cybersecurity threat documented by Palo Alto Unit 42.
+
+2. **MTTM and Bad Customer Minutes:** Tracks Mean Time to Mitigation (MTTM) — when user-facing impact first stops — and cumulative Bad Customer Minutes (BCM). Based on Google SRE Workbook incident response methodology. No other OpenEnv submission tracks MTTM or BCM.
+
+3. **Outcome-only reward function:** Every reward signal is derived from observable system state changes. No answer keys, no hidden root cause variable. The agent cannot game the grader — it must actually improve system health metrics.
+
+---
+
+## 2. Action Space
+
+| Action | Type | Target Required | Effect |
+|---|---|---|---|
+| `fetch_logs` | Investigation | Yes | Populates `recent_logs` on the target service |
+| `get_metrics_detail` | Investigation | Yes | Returns 3-tick metric trend summary in feedback |
+| `trace_dependencies` | Investigation | Yes | Returns full upstream/downstream chain |
+| `restart_service` | Remediation | Yes | Resets OOM state; wrong if error_rate < 0.10 |
+| `rollback_deploy` | Remediation | Yes | Halts bad_deploy progression |
+| `revert_config` | Remediation | Yes | Restores connection pool settings |
+| `scale_replicas` | Remediation | Yes | Increases memory headroom |
+| `circuit_break` | Remediation | Yes | Suppresses cascade for 3 ticks |
+| `declare_resolved` | Meta | No | Terminates episode |
+| `escalate` | Meta | No | Records escalation (no state change) |
+
+**Wrong-action penalty:** Applied when remediating a service with `http_server_error_rate < 0.10`.
+
+---
+
+## 3. Observation Space
+
+`SystemObservation` (returned by `reset()`, `step()`, `state()`):
+
+| Field | Type | Description |
+|---|---|---|
+| `services` | `dict[str, ServiceMetrics]` | OTel-compatible per-service metrics |
+| `active_alerts` | `list[Alert]` | Currently firing Prometheus-format alerts |
+| `dependency_graph` | `dict[str, list[str]]` | Episode's service topology |
+| `slo_budget_remaining_pct` | `float` | Error budget (100.0 → 0.0) |
+| `bad_customer_minutes` | `float` | Cumulative user impact (MTTM objective) |
+| `sim_tick` | `int` | Current tick (1 tick = 30 simulated seconds) |
+| `action_history` | `list[dict]` | Last 10 actions + feedback strings |
+| `mttm_achieved_tick` | `int \| None` | Tick when user impact first reached zero |
+
+Each `ServiceMetrics` has 21 OTel semantic convention fields including `http_server_error_rate`, `http_server_request_duration_p99`, `process_memory_utilization`, `process_cpu_utilization`, `recent_logs`, and more.
+
+---
+
+## 4. Tasks & Difficulty
+
+| Task ID | Difficulty | Services | Red Herrings | Max Ticks | SLO Burn/Tick | Seed |
+|---|---|---|---|---|---|---|
+| `task_easy` | Easy | 3 | 0 | 20 | 1.5% | 42 |
+| `task_medium` | Medium | 5 | 1 | 30 | 2.5% | 137 |
+| `task_hard` | Hard | 7 | 3 (1 adversarial) | 40 | 4.0% | 256 |
+
+**Task 1 (Easy — Single Service OOM):** One service develops a memory fault. Root cause is unambiguous from OOMKill logs. 1–2 investigation actions before correct remediation is sufficient.
+
+**Task 2 (Medium — Cascading Deploy Failure):** A bad deployment on an upstream service cascades to downstream victims. The trap: the most alarming alert is on a downstream victim, not the root cause. Requires tracing the dependency graph upstream.
+
+**Task 3 (Hard — Config Drift Noise Storm):** Config drift with 3 red herrings including one with adversarial prompt injection in logs. Requires filtering noise, resisting adversarial log content, and acting fast under high SLO burn pressure. Designed to challenge frontier models.
+
+---
+
+## 5. Setup & Usage
+
+### Prerequisites
+- Docker
+- Python 3.10+
+- `uv` package manager: `pip install uv`
+- `openenv-core`: `pip install openenv-core`
+
+### Local Development
+
+```bash
+git clone https://huggingface.co/spaces/10doshi12/firewatch-env
+cd firewatch-env
+uv sync
+uv run server   # starts on http://localhost:8000
+```
+
+### Run Baseline Inference
+
+```bash
+export HF_TOKEN=<your-hf-token>
+export SPACE_URL=http://localhost:8000  # or your HF Space URL
+python inference.py
+```
+
+### Docker
+
+```bash
+docker build -t firewatch-env ./server
+docker run -p 7860:7860 firewatch-env
+```
+
+### OpenEnv Validate
+
+```bash
+openenv validate   # must pass with zero errors
+```
+
+### Baseline Scores (Qwen/Qwen2.5-72B-Instruct via HF Router)
+
+| Task | Score | Notes |
+|---|---|---|
+| task_easy | 0.000 | Replace with your actual score after running inference.py |
+| task_medium | 0.000 | Replace with your actual score |
+| task_hard | 0.000 | Task 3 score reflects adversarial robustness of the model |
+*Note: Task 3 is designed to test adversarial robustness. A lower Task 3 score relative to Tasks 1–2 reflects the model's susceptibility to prompt injection, not environment quality.*
+---
+## Fault Types
+All five fault types mapped to AIOpsLab taxonomy (Table 2, MLSys 2025):
+| Fault | AIOpsLab Type | Observable Signature |
+|---|---|---|
+| `oom` | memory_stress | OOMKill (exit 137), restart_count spike |
+| `bad_deploy` | pod restart | Error rate spike post-deployment SHA |
+| `config_drift` | misconfig_app | HikariCP pool exhaustion, 30s timeouts |
+| `network_partition` | network_delay | Connection refused, circuit breaker OPEN |
+| `memory_leak` | memory_leak | Gradual latency increase, slow memory growth |
+---
+*FirewatchEnv — Meta PyTorch OpenEnv Hackathon India 2026*