Fail closed on effective-rules rows with a missing or non-string type #141

Contract and scope

At 247b95e6214f687d0d838d1685cc0e99db664cd6, the closeout documentation promises that missing, malformed, or incomplete evidence fails closed. The readable-empty fallback is allowed only when both policy sources establish that no required contexts are configured.

This is a reproducible malformed-response validation gap. It is not a claim that GitHub currently emits the malformed responses below, nor an observed production incident. GitHub's effective branch rules endpoint returns typed rule objects; a row without a string discriminator is not a valid unrelated rule.

Reproduction

Use an isolated real SDK tracker containing an in_progress Task, a merged PR linking that Task, and synthetic HTTP responses through the existing fetchJSON/parseNextLink transport:

1. Classic required-status-check metadata returns HTTP 200 with { "contexts": [], "checks": [] }
2. Effective branch rules return HTTP 200 with:

[
  {
    "parameters": {
      "required_status_checks": [
        { "context": "not-run", "integration_id": 7 }
      ]
    }
  }
]

3. The exact PR head has one completed successful check named optional-CI; no not-run check or status exists. Legacy statuses return []
4. Call runCloseout(root, "fixture/project", { pr: "42", apply: true }, api)

Observed: closed=1, failed=0; the real Task changes to closed. The report says rule="fallback", code="head_checks_passed", and asserts that protection metadata is readable with no required contexts.

Expected: refuse closure with unavailable/incomplete evidence and leave durable tracker content unchanged. A malformed policy row cannot establish an empty required-check policy.

Controls and extent

• Add only "type": "required_status_checks" to the same row: closed=0; the Task remains in_progress, and durable tracker files remain byte-identical
• Replace the row with the valid unrelated rule { "type": "deletion" }: closed=1 under the documented fallback
• An independent 22-case head-policy matrix passes 18 cases but also reproduces unsafe acceptance for [{}], [{"type":null}], and [{"type":4}]
• HTTP 403/404 without declarations, unsuccessful/missing declarations, readable app bindings, latest legacy statuses, malformed page shapes, and valid unrelated rules behave as documented in that matrix

Root cause: closeout.ts lines 180–182 only validates that each row is an object. Every discriminator unequal to required_status_checks, including absent and non-string values, is silently skipped. Validate the discriminator before treating a row as an unrelated rule.

Suggested regression coverage: missing/null/non-string rule types should refuse with zero SDK closes and no durable writes, while a well-formed unrelated rule remains accepted. Include the declared-policy path so declarations cannot disguise malformed metadata as a verified source.

Duplicate check

Reviewed canonical tracker records and all-status GitHub collections on 2026-10-16: 140 issue/PR entries and 136 PRs across two pages each. No matching malformed-discriminator issue was found. #138/#140 address unavailable HTTP 403/404 metadata; this case receives HTTP 200 with structurally invalid rows and is not covered by the existing malformed-rules tests.

The recorded reproduction used disposable fixtures with PM telemetry explicitly disabled. No live trackers, repository settings, workflow pins, or GitHub integrations were changed.