# 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.)*