feat: implement issue #1023 — canary autocut: scope bump signals to watched-path commits, paginate the range, and persist failed promotions

.github/workflows/canary-rollout.yml

@@ -258,6 +258,11 @@ jobs:
           # One TSV line per real promotion (agent, ring, sha, owning-repo) so the deployment
           # step records a deployment for EVERY move in a promote-all run, on the right host.
           CANARY_PROMOTIONS_LOG: ${{ runner.temp }}/promotions.tsv
+          # Sibling log of FAILED tag writes (agent, ring, sha, host, reason) — an UNEXPECTED
+          # write rejection, distinct from an expected gate-block (#1023 defect 2). The
+          # sync-promotion-failures step below turns a repeatedly-failing write into a durable,
+          # escalating tracking issue instead of a scrolling run-log line.
+          CANARY_PROMOTIONS_FAILED_LOG: ${{ runner.temp }}/promotions-failed.tsv
         run: |
           set -euo pipefail
           args=()
@@ -339,6 +344,23 @@ jobs:
           set -uo pipefail
           bash scripts/canary-rollout.sh sync-issues || echo "::warning::issue sync failed (non-fatal)"
 
+      # Escalate FAILED tag writes (#1023 defect 2). A gate-blocked promotion is expected and
+      # tracked by the step above; a rejected tag WRITE is UNEXPECTED and, before this, left only
+      # a run-log line. Reconcile this run's success/failure logs into a durable per-agent
+      # tracking issue whose consecutive-failure streak escalates to needs-human + dev-lead, and
+      # auto-closes when a write recovers. Best-effort + always(): promote-all returns non-zero
+      # when an agent's write failed, so this must run even after that step "fails".
+      - name: Escalate failed promotion tag-writes
+        if: always() && github.event_name == 'schedule'
+        env:
+          GH_TOKEN: ${{ steps.app-token.outputs.token }}
+          ISSUE_REPO: ${{ github.repository }}
+          CANARY_PROMOTIONS_LOG: ${{ runner.temp }}/promotions.tsv
+          CANARY_PROMOTIONS_FAILED_LOG: ${{ runner.temp }}/promotions-failed.tsv
+        run: |
+          set -uo pipefail
+          bash scripts/canary-rollout.sh sync-promotion-failures || echo "::warning::promotion-failure escalation failed (non-fatal)"
+
       # Reusable-registry drift audit (#1082): the registry (.agents{}) is the MANUAL source
       # of truth for what this pipeline manages — a *-reusable.yml added/renamed on a host but
       # never registered ships with ZERO staged rollout (no cut/soak/gate/dashboard) until a

AGENTS.md

@@ -142,15 +142,13 @@ E2E tests validate real functional requirements through the full stack. They exi
 
 ### What E2E Tests MUST Do
 
-1. **Full round-trip verification.** Action → API call → database mutation → response → frontend reflects new state. Not a subset — the whole chain.
-2. **Multi-layer assertions.** The frontend shows correct data AND the database contains the correct record AND side effects occurred (events published, notifications queued, cache invalidated).
-3. **Verify at the data layer.** After a form submission, query the database directly to verify the record exists with correct fields.
+1. **Verify at the data layer.** After a form submission, query the database directly to verify the record exists with correct fields.
    After a delete, verify it's gone. After auth, verify the token's claims and scopes. Do NOT stop at "success toast appeared."
-4. **Test error paths.** For every happy-path test, write corresponding tests for:
+2. **Test error paths.** For every happy-path test, write corresponding tests for:
    invalid input, unauthorized access, conflict/duplicate states, and not-found resources.
-5. **Test authorization boundaries.** Verify user A cannot access user B's resources. Verify regular users cannot hit admin endpoints. Verify expired/revoked tokens are rejected.
-6. **Use realistic data.** Factories that produce production-realistic data (unicode names, long strings, special characters, realistic cardinalities) — not `"test"` and `"foo"`.
-7. **Deterministic waits.** Wait for specific conditions (element visible, API response received, database row present) using polling with timeouts — never arbitrary sleeps.
+3. **Test authorization boundaries.** Verify user A cannot access user B's resources. Verify regular users cannot hit admin endpoints. Verify expired/revoked tokens are rejected.
+4. **Use realistic data.** Factories that produce production-realistic data (unicode names, long strings, special characters, realistic cardinalities) — not `"test"` and `"foo"`.
+5. **Deterministic waits.** Wait for specific conditions (element visible, API response received, database row present) using polling with timeouts — never arbitrary sleeps.
 
 ### Forbidden Patterns
 
@@ -230,6 +228,8 @@ assert getText("[test-id='order-id']") contains dbOrder.orderId
 
 ### Frontend E2E (Web and Mobile)
 
+- **Full round-trip verification.** Action → API call → database mutation → response → frontend reflects new state. Not a subset — the whole chain.
+- **Multi-layer assertions.** The frontend shows correct data AND the database contains the correct record AND side effects occurred (events published, notifications queued, cache invalidated).
 - **Run against the real backend** — not a mocked API layer. The frontend E2E test environment connects to a real API backed by a real (test) database.
 - **Test full navigation flows** — deep links, back navigation, tab switching with state preservation, modal dismissal.
 - **Test offline/online transitions** (mobile) — disable network, verify cached data displays and writes queue, re-enable, verify sync.
@@ -784,8 +784,10 @@ Before starting work on **any** GitHub issue, an agent MUST:
 2. **Check for an open PR referencing the issue.** If one exists, skip the issue or comment on the PR instead.
 
    ```bash
-   gh pr list --repo <owner>/<repo> --state open --search "closes #<issue-number>" --json number | \
-     jq 'length > 0'
+   for kw in close closes closed fix fixes fixed resolve resolves resolved; do
+     gh pr list --repo <owner>/<repo> --state open --limit 1000 \
+       --search "$kw #<issue-number>" --json number --jq '.[].number'
+   done | sort -nu | jq -sR 'split("\n") | map(select(. != "")) | length > 0'
    ```
 
 3. **Claim the issue immediately** by adding the `in-progress` label — before writing any code.
@@ -809,7 +811,7 @@ If found, comment on the existing PR rather than creating a competing one.
 
 ```bash
 # Check if any open PR already creates the target file
-gh pr list --repo <owner>/<repo> --state open --json files \
+gh pr list --repo <owner>/<repo> --state open --limit 1000 --json files \
   --jq '.[].files[].path' | grep -qx "<path/to/file>" && echo "FILE ALREADY IN OPEN PR"
 ```
 
@@ -1086,6 +1088,33 @@ Before starting a stacked Epic/Feature workflow, verify:
 - **CI runs on each PR independently.** Ensure CI is configured to run against the PR's base branch, not just `main`. Most CI systems (GitHub Actions, etc.) handle this correctly by default.
 - **PR review is incremental.** Reviewers see only the diff between the Epic/Feature branch and its parent — not the entire stack. This keeps reviews focused and manageable.
 
+#### Pull Request Limits (automation open-PR cap)
+
+The org enforces a **soft ceiling on concurrent open, non-draft automation PRs
+org-wide** so automation cannot outrun merge throughput and inflate the
+auto-rebase fan-out. Full standard, rationale, and operator runbook:
+[`standards/pr-limits.md`](https://github.com/petry-projects/.github/blob/main/standards/pr-limits.md).
+
+- **GitHub has no native "max open PRs" surface** (no repo setting, org setting,
+  or ruleset rule — verified in the [ADR](https://github.com/petry-projects/.github/blob/main/docs/initiatives/pull-request-limits-adr.md)),
+  so this is enforced **source-side** by [`scripts/lib/pr-limit-gate.sh`](https://github.com/petry-projects/.github/blob/main/scripts/lib/pr-limit-gate.sh):
+  a PR-creating workflow asks the gate before opening a PR and **defers** (never
+  fails or closes) when the queue is at the cap. Live-path wiring is Story 3 (#508).
+- **The configured value lives only in [`standards/pr-limits.json`](https://github.com/petry-projects/.github/blob/main/standards/pr-limits.json)** —
+  the single source of truth. Read it with `jq`; never hardcode or restate it.
+
+> **Exempt actors are sanctioned policy, not drift.** `dependabot[bot]`,
+> `OrganizationAdmin`, `@petry-projects/org-leads`, the `dependabot-automerge-petry`
+> app, and `security`-labeled PRs are on the cap's exempt list — never blocked
+> and never counted. This mirrors the ruleset bypass-actor allowance (see
+> [Ruleset remediation](https://github.com/petry-projects/.github/blob/main/standards/ruleset-remediation-runbook.md)):
+> `dependabot[bot]` is already bounded by its own per-ecosystem
+> `open-pull-requests-limit` (so counting it here would double-cap and could
+> starve a security PR), the human/admin actors are break-glass and maintainer
+> traffic, and the app only operates on existing PRs. A compliance audit should
+> treat these as intentional exemptions. To change the cap or the exempt list,
+> follow the runbook in [`standards/pr-limits.md`](https://github.com/petry-projects/.github/blob/main/standards/pr-limits.md).
+
 ---
 
 ## Agent Operation Guidance