update readme

Author: MDA2AV

site/content/docs/add-framework/_index.md

@@ -10,4 +10,5 @@ Adding a framework to HttpArena takes a few steps: create a Dockerfile, add meta
   {{< card link="test-profiles" title="Test Profiles" subtitle="All HTTP endpoints your framework must implement, organized by test profile." icon="code" >}}
   {{< card link="meta-json" title="meta.json" subtitle="Framework metadata — display name, language, type, and which tests to participate in." icon="document-text" >}}
   {{< card link="testing" title="Testing & Submitting" subtitle="How to validate your implementation locally and submit a pull request." icon="check-circle" >}}
+  {{< card link="ci" title="CI & Runner" subtitle="GitHub Actions workflows and the self-hosted benchmark runner." icon="cog" >}}
 {{< /cards >}}

site/content/docs/add-framework/ci.md

@@ -0,0 +1,41 @@
+---
+title: CI & Runner
+---
+
+## GitHub Actions
+
+HttpArena uses four GitHub Actions workflows to automate validation, benchmarking, and deployment.
+
+### Validate Framework
+
+**Trigger:** Automatically on every PR that modifies files under `frameworks/` or `scripts/validate.sh`.
+
+Detects which frameworks were changed in the PR and runs `./scripts/validate.sh` against each one. If validation fails, the PR check fails — you must fix the issues before merging.
+
+### Benchmark
+
+**Trigger:** Automatically when a push to `main` modifies files under `frameworks/`, or manually via workflow dispatch.
+
+When triggered automatically, it detects which frameworks changed in the latest commit and benchmarks only those. When triggered manually, you can specify:
+- **Framework** — a specific framework name, or leave empty to benchmark all changed frameworks
+- **Profile** — a specific test profile (e.g. `baseline`, `baseline-h2`), or leave empty to run all profiles
+
+Results are committed and pushed to `main` automatically by the HttpArena Bot.
+
+### Benchmark PR
+
+**Trigger:** Manual only (workflow dispatch). Requires a PR number and framework name.
+
+Checks out the PR branch, runs the benchmark, and posts the results as a comment on the PR. This lets maintainers benchmark a new framework submission before merging, so contributors can see how their implementation performs on the hosted runner. An optional profile parameter lets you run a specific test instead of the full suite.
+
+### Deploy Site
+
+**Trigger:** Automatically when a push to `main` modifies files under `site/`, or manually via workflow dispatch.
+
+Builds the Hugo site and deploys it to GitHub Pages. This runs on GitHub-hosted Ubuntu runners (not the self-hosted runner).
+
+## Hosted runner
+
+The Validate, Benchmark, and Benchmark PR workflows run on a **self-hosted runner** — a dedicated bare-metal machine configured for reproducible, low-noise benchmarking. This ensures all frameworks are tested on identical hardware under controlled conditions, with CPU governors locked, background services minimized, and no resource contention from other CI jobs.
+
+Only the Deploy Site workflow uses GitHub-hosted runners, since it only builds static HTML and doesn't need controlled hardware.

site/content/docs/add-framework/testing.md

@@ -44,41 +44,3 @@ The PR should include:
 - `Dockerfile`
 - `meta.json`
 - Source files for your server implementation
-
-## GitHub Actions
-
-HttpArena uses four GitHub Actions workflows to automate validation, benchmarking, and deployment.
-
-### Validate Framework
-
-**Trigger:** Automatically on every PR that modifies files under `frameworks/` or `scripts/validate.sh`.
-
-Detects which frameworks were changed in the PR and runs `./scripts/validate.sh` against each one. If validation fails, the PR check fails — you must fix the issues before merging.
-
-### Benchmark
-
-**Trigger:** Automatically when a push to `main` modifies files under `frameworks/`, or manually via workflow dispatch.
-
-When triggered automatically, it detects which frameworks changed in the latest commit and benchmarks only those. When triggered manually, you can specify:
-- **Framework** — a specific framework name, or leave empty to benchmark all changed frameworks
-- **Profile** — a specific test profile (e.g. `baseline`, `baseline-h2`), or leave empty to run all profiles
-
-Results are committed and pushed to `main` automatically by the HttpArena Bot.
-
-### Benchmark PR
-
-**Trigger:** Manual only (workflow dispatch). Requires a PR number and framework name.
-
-Checks out the PR branch, runs the benchmark, and posts the results as a comment on the PR. This lets maintainers benchmark a new framework submission before merging, so contributors can see how their implementation performs on the hosted runner. An optional profile parameter lets you run a specific test instead of the full suite.
-
-### Deploy Site
-
-**Trigger:** Automatically when a push to `main` modifies files under `site/`, or manually via workflow dispatch.
-
-Builds the Hugo site and deploys it to GitHub Pages. This runs on GitHub-hosted Ubuntu runners (not the self-hosted runner).
-
-## Hosted runner
-
-The Validate, Benchmark, and Benchmark PR workflows run on a **self-hosted runner** — a dedicated bare-metal machine configured for reproducible, low-noise benchmarking. This ensures all frameworks are tested on identical hardware under controlled conditions, with CPU governors locked, background services minimized, and no resource contention from other CI jobs.
-
-Only the Deploy Site workflow uses GitHub-hosted runners, since it only builds static HTML and doesn't need controlled hardware.

site/content/docs/scoring/composite-score.md

@@ -115,7 +115,12 @@ Framework A still leads because its raw throughput advantage outweighs B's CPU e
 
 ## Engine-level implementations
 
-Frameworks with type `engine` are excluded from the composite ranking and from the normalization pool. They can still be compared in individual test profiles. Only `framework` entries — those using standard, production-grade HTTP libraries — are scored here.
+Engines and frameworks are scored **separately** — each type has its own composite ranking and normalization pool. The scored profiles differ by type:
+
+- **Frameworks** are scored on all H1 profiles (Baseline, Pipelined, Short-lived, JSON, Upload, Compression, Noisy, Mixed) plus all H2/H3 profiles.
+- **Engines** are scored on a reduced H1 set (Baseline, Pipelined, Short-lived only) plus all H2/H3 profiles, since most engines don't implement the heavier endpoints (JSON, DB, upload, compression).
+
+The Type filter on the composite leaderboard switches between the two rankings.
 
 ## Why this approach