…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>

…xt (#181)

The docs link-check job was named `build`, which is the bare context
GitHub Actions reports on the check-run. That's ambiguous repo-wide:
any future workflow with a `build:` job would also satisfy a required
status check matched by `build`. The required-status-check rule on
`main` (jackin-project/jackin-github-terraform#11) lists this context
explicitly, so we want it unique enough that only the docs link-check
ever satisfies it.

Rename the job from `build` to `docs-link-check`, which is unique
across the repo's workflows. Also update the deploy job's `needs:`
reference and the one prose mention in the docs-markdown-linting
roadmap doc.

The matching terraform PR
jackin-project/jackin-github-terraform#11 lists both `build` and
`docs-link-check` during the rename window, so this PR can merge
without deadlocking against the still-live `Docs / build` →
unmatched rule. After this merges and the terraform follow-up
applies, only `docs-link-check` will be required.

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

…xt (#181)

The docs link-check job was named `build`, which is the bare context
GitHub Actions reports on the check-run. That's ambiguous repo-wide:
any future workflow with a `build:` job would also satisfy a required
status check matched by `build`. The required-status-check rule on
`main` (jackin-project/jackin-github-terraform#11) lists this context
explicitly, so we want it unique enough that only the docs link-check
ever satisfies it.

Rename the job from `build` to `docs-link-check`, which is unique
across the repo's workflows. Also update the deploy job's `needs:`
reference and the one prose mention in the docs-markdown-linting
roadmap doc.

The matching terraform PR
jackin-project/jackin-github-terraform#11 lists both `build` and
`docs-link-check` during the rename window, so this PR can merge
without deadlocking against the still-live `Docs / build` →
unmatched rule. After this merges and the terraform follow-up
applies, only `docs-link-check` will be required.

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

…xt (#181)

The docs link-check job was named `build`, which is the bare context
GitHub Actions reports on the check-run. That's ambiguous repo-wide:
any future workflow with a `build:` job would also satisfy a required
status check matched by `build`. The required-status-check rule on
`main` (jackin-project/jackin-github-terraform#11) lists this context
explicitly, so we want it unique enough that only the docs link-check
ever satisfies it.

Rename the job from `build` to `docs-link-check`, which is unique
across the repo's workflows. Also update the deploy job's `needs:`
reference and the one prose mention in the docs-markdown-linting
roadmap doc.

The matching terraform PR
jackin-project/jackin-github-terraform#11 lists both `build` and
`docs-link-check` during the rename window, so this PR can merge
without deadlocking against the still-live `Docs / build` →
unmatched rule. After this merges and the terraform follow-up
applies, only `docs-link-check` will be required.

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

…xt (#181)

The docs link-check job was named `build`, which is the bare context
GitHub Actions reports on the check-run. That's ambiguous repo-wide:
any future workflow with a `build:` job would also satisfy a required
status check matched by `build`. The required-status-check rule on
`main` (jackin-project/jackin-github-terraform#11) lists this context
explicitly, so we want it unique enough that only the docs link-check
ever satisfies it.

Rename the job from `build` to `docs-link-check`, which is unique
across the repo's workflows. Also update the deploy job's `needs:`
reference and the one prose mention in the docs-markdown-linting
roadmap doc.

The matching terraform PR
jackin-project/jackin-github-terraform#11 lists both `build` and
`docs-link-check` during the rename window, so this PR can merge
without deadlocking against the still-live `Docs / build` →
unmatched rule. After this merges and the terraform follow-up
applies, only `docs-link-check` will be required.

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

…xt (#181)

The docs link-check job was named `build`, which is the bare context
GitHub Actions reports on the check-run. That's ambiguous repo-wide:
any future workflow with a `build:` job would also satisfy a required
status check matched by `build`. The required-status-check rule on
`main` (jackin-project/jackin-github-terraform#11) lists this context
explicitly, so we want it unique enough that only the docs link-check
ever satisfies it.

Rename the job from `build` to `docs-link-check`, which is unique
across the repo's workflows. Also update the deploy job's `needs:`
reference and the one prose mention in the docs-markdown-linting
roadmap doc.

The matching terraform PR
jackin-project/jackin-github-terraform#11 lists both `build` and
`docs-link-check` during the rename window, so this PR can merge
without deadlocking against the still-live `Docs / build` →
unmatched rule. After this merges and the terraform follow-up
applies, only `docs-link-check` will be required.

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>