…ly (#11)

Fix the required-status-checks context I introduced in #10. The
context "Docs / build" was the workflow / job display name that
appears in the GitHub PR UI, but GitHub matches against the bare
check-run name, which for the Docs workflow is "build". Result:
zero check-runs ever satisfied the rule, every PR's
mergeStateStatus turned BLOCKED right after #10 applied (see
jackin-project/jackin#180 — green build but blocked merge).

Switch the map to a transitional dual-context list:

- "build" — the current docs link-check job name. Restores merges
  immediately after this applies.
- "docs-link-check" — the unique name the docs job will rename to in
  jackin-project/jackin (PR to follow). Listing it here ahead of the
  rename keeps PRs unblocked across the rename window.

Once the rename PR merges in jackin, drop "build" from this list in
a follow-up apply so we don't have an extra context that could be
silently satisfied by a future unrelated workflow's "build" job.

Verified locally:
- `tofu fmt -check` clean
- `tofu validate` clean
- Pre-commit secret scan clean

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…ck (#12)

Replace the dual-context list ["build", "docs-link-check"] from #11
with ["docs-link-check"] only.

The dual-context attempt was based on a wrong assumption that the
required_status_checks list is OR-semantics (any one must pass). It's
AND-semantics (every entry must pass). After #11 applied:

- jackin-project/jackin#180 has Docs/build green, no docs-link-check
  check on its branch -> blocked, missing docs-link-check.
- jackin-project/jackin#181 (the rename PR) has Docs/docs-link-check
  green, no build check on its branch -> blocked, missing build.

Each PR can only ever produce one of the two names, so AND-semantics
makes the rule unsatisfiable.

The fix: drop the legacy "build" context, since the rename PR (#181)
will produce only "docs-link-check" once merged. Apply order:

1. Apply this PR.
2. #181 unblocks (it has docs-link-check green) -> merge it. Main
   now produces docs-link-check on every push.
3. Sync #180 with main (rebase or merge from main into the PR branch)
   so its CI run also produces docs-link-check -> #180 unblocks ->
   merge it.

No admin override, no enforcement-disabled window, no bypass_actors
weakening. The rule simply hops to its target context and existing
PRs adapt naturally on rebase.

Verified locally:
- `tofu fmt -check` clean
- `tofu validate` clean (pre-existing vulnerability_alerts deprecation
  warning unrelated)
- Pre-commit secret scan clean

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…#180)

Add an Internal cleanups entry capturing the WARN that the post-#176
deploy run on main surfaces in `Check deployed docs links`:

  [WARN] No files found for this input source

The run reports Total 4703 / Successful 4703 / Errors 0, so the gate
holds today, but the warn means at least one of the 46 deployed-page
inputs resolved to zero extractable links. If a future regression
caused several inputs to silently skip, the warn count is the only
tell — so investigate and either fix the cause or document and
suppress the warn.

Entry includes:
- The exact warn string and its source (the lychee 0.24.1 binary,
  confirmed via `strings`).
- Three hypotheses (redirect → non-HTML; anchorless page; empty
  positional arg from `eval`).
- A one-line repro that names the offending input via `--verbose`.
- Definition-of-done: clean run, or documented benign + filtered.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…#180)

Add an Internal cleanups entry capturing the WARN that the post-#176
deploy run on main surfaces in `Check deployed docs links`:

  [WARN] No files found for this input source

The run reports Total 4703 / Successful 4703 / Errors 0, so the gate
holds today, but the warn means at least one of the 46 deployed-page
inputs resolved to zero extractable links. If a future regression
caused several inputs to silently skip, the warn count is the only
tell — so investigate and either fix the cause or document and
suppress the warn.

Entry includes:
- The exact warn string and its source (the lychee 0.24.1 binary,
  confirmed via `strings`).
- Three hypotheses (redirect → non-HTML; anchorless page; empty
  positional arg from `eval`).
- A one-line repro that names the offending input via `--verbose`.
- Definition-of-done: clean run, or documented benign + filtered.

Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Codex <codex@openai.com>

…#180)

Add an Internal cleanups entry capturing the WARN that the post-#176
deploy run on main surfaces in `Check deployed docs links`:

  [WARN] No files found for this input source

The run reports Total 4703 / Successful 4703 / Errors 0, so the gate
holds today, but the warn means at least one of the 46 deployed-page
inputs resolved to zero extractable links. If a future regression
caused several inputs to silently skip, the warn count is the only
tell — so investigate and either fix the cause or document and
suppress the warn.

Entry includes:
- The exact warn string and its source (the lychee 0.24.1 binary,
  confirmed via `strings`).
- Three hypotheses (redirect → non-HTML; anchorless page; empty
  positional arg from `eval`).
- A one-line repro that names the offending input via `--verbose`.
- Definition-of-done: clean run, or documented benign + filtered.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…#180)

Add an Internal cleanups entry capturing the WARN that the post-#176
deploy run on main surfaces in `Check deployed docs links`:

  [WARN] No files found for this input source

The run reports Total 4703 / Successful 4703 / Errors 0, so the gate
holds today, but the warn means at least one of the 46 deployed-page
inputs resolved to zero extractable links. If a future regression
caused several inputs to silently skip, the warn count is the only
tell — so investigate and either fix the cause or document and
suppress the warn.

Entry includes:
- The exact warn string and its source (the lychee 0.24.1 binary,
  confirmed via `strings`).
- Three hypotheses (redirect → non-HTML; anchorless page; empty
  positional arg from `eval`).
- A one-line repro that names the offending input via `--verbose`.
- Definition-of-done: clean run, or documented benign + filtered.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…ly (#11)

Fix the required-status-checks context I introduced in #10. The
context "Docs / build" was the workflow / job display name that
appears in the GitHub PR UI, but GitHub matches against the bare
check-run name, which for the Docs workflow is "build". Result:
zero check-runs ever satisfied the rule, every PR's
mergeStateStatus turned BLOCKED right after #10 applied (see
jackin-project/jackin#180 — green build but blocked merge).

Switch the map to a transitional dual-context list:

- "build" — the current docs link-check job name. Restores merges
  immediately after this applies.
- "docs-link-check" — the unique name the docs job will rename to in
  jackin-project/jackin (PR to follow). Listing it here ahead of the
  rename keeps PRs unblocked across the rename window.

Once the rename PR merges in jackin, drop "build" from this list in
a follow-up apply so we don't have an extra context that could be
silently satisfied by a future unrelated workflow's "build" job.

Verified locally:
- `tofu fmt -check` clean
- `tofu validate` clean
- Pre-commit secret scan clean

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…ck (#12)

Replace the dual-context list ["build", "docs-link-check"] from #11
with ["docs-link-check"] only.

The dual-context attempt was based on a wrong assumption that the
required_status_checks list is OR-semantics (any one must pass). It's
AND-semantics (every entry must pass). After #11 applied:

- jackin-project/jackin#180 has Docs/build green, no docs-link-check
  check on its branch -> blocked, missing docs-link-check.
- jackin-project/jackin#181 (the rename PR) has Docs/docs-link-check
  green, no build check on its branch -> blocked, missing build.

Each PR can only ever produce one of the two names, so AND-semantics
makes the rule unsatisfiable.

The fix: drop the legacy "build" context, since the rename PR (#181)
will produce only "docs-link-check" once merged. Apply order:

1. Apply this PR.
2. #181 unblocks (it has docs-link-check green) -> merge it. Main
   now produces docs-link-check on every push.
3. Sync #180 with main (rebase or merge from main into the PR branch)
   so its CI run also produces docs-link-check -> #180 unblocks ->
   merge it.

No admin override, no enforcement-disabled window, no bypass_actors
weakening. The rule simply hops to its target context and existing
PRs adapt naturally on rebase.

Verified locally:
- `tofu fmt -check` clean
- `tofu validate` clean (pre-existing vulnerability_alerts deprecation
  warning unrelated)
- Pre-commit secret scan clean

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>