After ORCH-10 the webhook resolves Plane state UUIDs per-project via
get_project_states(project_id). The m6/plane webhook tests hardcoded the
enduro in_progress UUID for ORCH-project payloads, so the pipeline never
started and task creation assertions failed.
Tests:
- Mock get_project_states with a deterministic per-project ET/ORCH map (no
network) and reset _STATES_CACHE via reload_project_states() per test.
- Send each request with the in_progress UUID that matches its own project.
CI hole:
- requirements.txt lacked pytest-asyncio, so the 6 @pytest.mark.asyncio tests
in test_orch10_states.py were SILENTLY SKIPPED -> CI green while async paths
never ran. Add pytest-asyncio + pytest.ini (asyncio_mode=auto, strict
markers); harden ci.yml (set -euo pipefail, --strict-markers) so any failure
or unknown marker reds the build and the whole suite runs.
src/ unchanged (per-project resolving is the ORCH-10 feature, kept as-is).
Feature 1. work_item.created no longer starts the pipeline (soft QG-0 log only);
the issue stays in the backlog until moved to In Progress. The pipeline-start body
is extracted into start_pipeline(); a new issue updated handler routes a state
change to In Progress -> handle_status_start, which is idempotent: an existing task
for the plane_id is NOT re-created or restarted (protects handle_comment, which also
flips issues to In Progress). Real Plane payload: event=issue, action=updated,
data.state.id. Existing m6/plane_webhook/dedup tests updated to drive the new
trigger; new test_status_trigger.py covers created-no-op / start / idempotent.
