diff --git a/tests/mattermost-lts/PARITY.md b/tests/mattermost-lts/PARITY.md
new file mode 100644
index 0000000..02fc1b5
--- /dev/null
+++ b/tests/mattermost-lts/PARITY.md
@@ -0,0 +1,27 @@
+# mattermost-lts — parity & coverage map (Phase 2)
+
+## P2 — Parity port
+**No recipe-maintainer corpus exists for mattermost-lts** (`/srv/recipe-maintainer/recipe-info/` has
+no `mattermost-lts/` entry). P2 (parity) is therefore **vacuously satisfied** — there are no
+`recipe-info/mattermost-lts/tests/*.py` scripts to port. Coverage is delivered entirely via the
+generic lifecycle tiers (install/upgrade/backup/restore) + the recipe-specific functional tests below.
+
+## Lifecycle (generic tiers — Phase 1d/1e)
+mattermost-lts ships no `test_<op>.py` overlays, so the **generic** install/upgrade/backup/restore
+tiers run by default (the Phase-1e invariant: no overlay ⇒ generic runs). The stack bundles its own
+postgres in-compose (no external dep), so no dependency resolution is needed.
+
+## P3 — Recipe-specific functional tests
+- `functional/test_health_check.py`
+  - `test_root_serves` — web app served at `/` (200/302).
+  - `test_system_ping_ok` — GET `/api/v4/system/ping` → `{"status":"OK"}` (proves the mattermost
+    server + API router are live, not a Traefik fallback).
+- `functional/test_create_message.py` — **§4.3 prescribed create-an-object + read-it-back** (planned,
+  authored against the live instance): create the first user (system admin) → login → create team →
+  create channel → POST a message → GET it back → assert the message text round-trips. *(In progress —
+  requires response-header access for the mattermost login `Token`; harness.http extension pending.)*
+
+## P4 — Backup data-integrity
+Planned `ops.py`: pre_backup seeds an identifiable message via the API; pre_restore mutates/wipes;
+the restore assertion re-reads the message and asserts it survived (recipe-aware, not health-only).
+*(Follows once the create-message API flow is proven green.)*
diff --git a/tests/mattermost-lts/functional/test_health_check.py b/tests/mattermost-lts/functional/test_health_check.py
new file mode 100644
index 0000000..abdfcbe
--- /dev/null
+++ b/tests/mattermost-lts/functional/test_health_check.py
@@ -0,0 +1,37 @@
+"""mattermost-lts — Phase-2 health_check (recipe-maintainer corpus has no parity test for this recipe).
+
+Two real assertions on app state, not a bare root 200:
+  1. The web app is served at `/` (200/302 — SPA shell or redirect toward login).
+  2. The dedicated API liveness endpoint GET /api/v4/system/ping returns {"status":"OK"} — this
+     proves the mattermost server process (not just Traefik) is up and its API router is live.
+"""
+
+from __future__ import annotations
+
+import os
+import sys
+
+sys.path.insert(0, os.path.join(os.path.dirname(__file__), "..", "..", "..", "runner"))
+from harness import http as harness_http  # noqa: E402
+
+
+def test_root_serves(live_app):
+    """GET / → 200 or 302 (mattermost web app shell / login redirect)."""
+    url = f"https://{live_app}/"
+    status, _ = harness_http.retry_http_get(
+        url, expect_status=(200, 302), max_wait=60, interval=3
+    )
+    assert status in (200, 302), f"GET {url} HTTP {status} (expected 200/302)"
+
+
+def test_system_ping_ok(live_app):
+    """GET /api/v4/system/ping → 200 with JSON {"status":"OK"} — the mattermost server's own
+    liveness endpoint (distinguishes a live mattermost API from a Traefik fallback / dead backend)."""
+    url = f"https://{live_app}/api/v4/system/ping"
+    status, body = harness_http.retry_http_get(
+        url, expect_status=200, max_wait=120, interval=3
+    )
+    assert status == 200, f"GET {url} HTTP {status} (expected 200)"
+    assert isinstance(body, dict) and body.get("status") == "OK", (
+        f"/api/v4/system/ping did not report status=OK; got {body!r}"
+    )
diff --git a/tests/mattermost-lts/recipe_meta.py b/tests/mattermost-lts/recipe_meta.py
new file mode 100644
index 0000000..50f49df
--- /dev/null
+++ b/tests/mattermost-lts/recipe_meta.py
@@ -0,0 +1,20 @@
+# Per-recipe harness config for mattermost-lts (Phase 2 Q4.5 — team chat / collaboration platform).
+#
+# Stack (compose.yml): app (mattermost/mattermost-team-edition) + postgres (postgres:15-alpine,
+# bundled IN-STACK — NOT an external dep). HTTP-native: the app serves the web UI + REST API
+# (/api/v4/...) at `/` through Traefik. No reference corpus under recipe-info/ → P2 (parity) is
+# vacuously satisfied; coverage is ≥2 recipe-specific functional tests (P3) on the proven HTTP harness.
+#
+# Health: mattermost serves its web app at `/`. A fresh server with no users redirects `/` toward the
+# setup/login flow (302) or serves the SPA shell (200); accept both. The dedicated liveness endpoint
+# is GET /api/v4/system/ping -> {"status":"OK"} (exercised as a functional test, not the install gate).
+HEALTH_PATH = "/"
+HEALTH_OK = (200, 302)
+
+# mattermost first-boot runs DB migrations against a fresh postgres volume; the default abra
+# convergence TIMEOUT (300s) is tight on cc-ci's single node (postgres init + app migrate + plugin
+# unpack). Bump, kept under DEPLOY_TIMEOUT so abra finishes its convergence wait before the Python
+# subprocess timeout.
+DEPLOY_TIMEOUT = 900
+HTTP_TIMEOUT = 600
+EXTRA_ENV = {"TIMEOUT": "600"}