wechat-on-airflow: Skill for Codex

Operate Tennis Alerts

Treat the repository and read-only production evidence as operational memory. Carry work from diagnosis through verified production state when the request includes repair, maintenance, release, or deployment.

Rebuild Context

Work from the repository root. Confirm it by locating config/active-components.yaml.

Read these sources before changing runtime behavior:

1. AGENTS.md
2. config/active-components.yaml
3. config/config-contracts.yaml
4. config/runtime-target.yaml
5. ARCHITECTURE.md
6. docs/production-baseline.md
7. The runbook and ADR relevant to the affected component

Inspect the worktree, local HEAD, upstream state, existing test evidence, and the current production baseline. Do not infer production state from chat history. Never print Variable values, credentials, recipient addresses, tokens, device login details, database passwords, or Fernet material.

Classify The Work

Choose the narrowest applicable class:

• Read-only diagnosis: inspect code, contracts, logs, health, recent runs, service status, and incident outbox metadata without changing production.
• Reversible repair: change code, tests, documentation, or non-secret contracts; deploy an exact pushed commit with a documented rollback.
• Configuration maintenance: compare names, types, counts, and protected hashes; migrate required configuration without exposing values.
• Release: verify, commit, push, wait for CI, deploy every affected runtime, observe natural cycles, and record evidence.
• High-risk operation: stop before apply and obtain explicit approval.

High-risk operations include production database migration or replacement, metadata deletion, backup restore, secret rotation, Git history rewriting, real email or WeChat tests, and deleting a component whose ownership is not proven.

Execute The Lifecycle

1. Inspect: establish the exact code, configuration contract, service, DAG, and external dependency involved.
2. Baseline: run the applicable read-only checks before editing. Preserve timestamps, counts, commit IDs, failing states, and rollback inputs without recording secrets.
3. Diagnose: identify the failing ownership boundary and root cause. Read diagnosis.md for symptom-specific checks.
4. Specify acceptance: add a failing regression test or a deterministic machine-verifiable check. Tests and smoke checks must not deliver real notifications.
5. Repair: make the smallest complete change within the repository ownership boundaries. Update contracts, runbooks, ADRs, and baseline facts when behavior or operations change.
6. Verify locally: run focused credential-free checks while iterating, then run make verify. Local checks are development evidence, not production authority.
7. Publish code: confirm the diff contains no secrets or generated noise, commit intentionally, push the exact commit, and require GitHub CI / verify to pass.
8. Deploy: select the component path in release-paths.md. Dispatch the protected GitHub preflight before apply and deploy only the exact full commit SHA. Never use local Wrangler, SSH, server credentials, or a workstation environment file.
9. Verify production: use the protected component health workflows with the explicit release SHA, contract checks, and browser checks as applicable. Compare against the baseline.
10. Observe: wait for the schedule-cycle count declared in config/runtime-target.yaml. Prefer natural DAG runs; do not manufacture production notifications.
11. Record: update durable repository evidence when an incident reveals a new fact. Report the deployed commit, checks, residual risk, and unrelated warnings precisely.