… rules (#267)

Codify two CI-merge-safety rules in `PULL_REQUESTS.md` plus a one-line cross-reference in `AGENTS.md`. The recent #256 → #266 incident exposed a class of break invisible to PR-time CI: a workflow-level env var (`BUILDX_BUILDER`) leaked into the `publish-manifest` job, where docker buildx read it as the default-builder selection and failed at runtime — but only on push to main, because that job is push-only and never runs on a `pull_request` event.

Three rules now live in `PULL_REQUESTS.md`. First, third-party-CLI env vars (`BUILDX_BUILDER`, `DOCKER_BUILDKIT`, `GH_TOKEN`/`GITHUB_TOKEN`, `KUBECONFIG`, `AWS_PROFILE`, `RUSTUP_TOOLCHAIN`, `npm_config_*`) must be scoped to the consuming job; workflow-level `env:` is reserved for in-house naming/paths. Second, registry / production publishing must hard-gate on main — the `is_publish` flag pattern from `construct.yml` is the canonical shape, and PRs / feature-branch dispatches must build-and-verify only, never publish. Third, push-only / main-only / `workflow_run`-gated jobs (`build-validator`, `publish-manifest`, `deploy`, `publish-preview`) must be smoke-tested via `gh workflow run --ref <feature-branch>` before requesting merge, since PR-time CI structurally cannot exercise them.

A companion terraform PR (jackin-project/jackin-github-terraform#14) raises the matching protection-rule changes — required-status-check list, single approving review, strict up-to-date branch policy.

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

…ntainer repo

The previous PR (#14) raised `required_approving_review_count` from
0 to 1 as part of the post-#266 hardening, on the assumption that a
human reviewer would be available before each merge. The repo is
operated by a single maintainer, and GitHub does not let the PR
author approve their own pull request, so the rule blocks every
merge instead of gating it.

Revert to `required_approving_review_count = 0`. The remaining
hardening from #14 stays in place: `strict_required_status_checks_policy = true`
ensures the green CI run reflects the exact code that lands on
main, and the expanded required-status-check list (`ci-required`,
`construct-required`, `docs-required`, `docs-link-check`,
`validate`, `DCO`) gives every gated workflow a hard gate at the
GitHub layer.

Add a code comment naming the constraint so a future change does
not silently re-flip the knob without checking whether the project
has gained additional reviewers in the meantime.

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

…ntainer repo (#15)

Revert `required_approving_review_count` from 1 back to 0 on the `jackin` repo's `protect_main` ruleset. The previous change in #14 raised it under the assumption a human reviewer would always be available, but the repo is operated by a single maintainer and GitHub does not let a PR author approve their own pull request — the rule blocks every merge instead of gating it.

The other improvements from #14 stay in place: `strict_required_status_checks_policy = true` ensures every PR runs CI against the actual merge state, and the expanded required-status-check list still gives every gated workflow a hard gate at the GitHub layer. A code comment names the solo-maintainer constraint so a future change does not silently re-flip the knob.

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

Capture an invariant that has been silently shaping recent decisions but was nowhere written down: jackin has exactly one human contributor, and GitHub does not let a PR author approve their own pull request. The previous CI hardening round (jackin-project/jackin-github-terraform#14) raised `required_approving_review_count` to 1 on the assumption a second reviewer was available — they are not — and the resulting trap blocked every merge until it was reverted in jackin-project/jackin-github-terraform#15.

Add a 'Project staffing: solo maintainer' section at the top of `AGENTS.md` naming the constraint and the four downstream consequences: branch protection cannot require an approving review; "get a second pair of eyes" is not an available pre-merge step (pre-merge confidence comes from CI, the path-aware aggregator status checks, the strict up-to-date branch policy, and the agent following PULL_REQUESTS.md); multi-agent review is the load-bearing substitute for the missing second human, not optional polish; and for irreversible or high-blast-radius changes the agent should prefer asking the operator to confirm one more time over assuming green CI is sufficient.

The rule retires when the project gains additional human reviewers.

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

… rules (#267)

Codify two CI-merge-safety rules in `PULL_REQUESTS.md` plus a one-line cross-reference in `AGENTS.md`. The recent #256 → #266 incident exposed a class of break invisible to PR-time CI: a workflow-level env var (`BUILDX_BUILDER`) leaked into the `publish-manifest` job, where docker buildx read it as the default-builder selection and failed at runtime — but only on push to main, because that job is push-only and never runs on a `pull_request` event.

Three rules now live in `PULL_REQUESTS.md`. First, third-party-CLI env vars (`BUILDX_BUILDER`, `DOCKER_BUILDKIT`, `GH_TOKEN`/`GITHUB_TOKEN`, `KUBECONFIG`, `AWS_PROFILE`, `RUSTUP_TOOLCHAIN`, `npm_config_*`) must be scoped to the consuming job; workflow-level `env:` is reserved for in-house naming/paths. Second, registry / production publishing must hard-gate on main — the `is_publish` flag pattern from `construct.yml` is the canonical shape, and PRs / feature-branch dispatches must build-and-verify only, never publish. Third, push-only / main-only / `workflow_run`-gated jobs (`build-validator`, `publish-manifest`, `deploy`, `publish-preview`) must be smoke-tested via `gh workflow run --ref <feature-branch>` before requesting merge, since PR-time CI structurally cannot exercise them.

A companion terraform PR (jackin-project/jackin-github-terraform#14) raises the matching protection-rule changes — required-status-check list, single approving review, strict up-to-date branch policy.

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

Capture an invariant that has been silently shaping recent decisions but was nowhere written down: jackin has exactly one human contributor, and GitHub does not let a PR author approve their own pull request. The previous CI hardening round (jackin-project/jackin-github-terraform#14) raised `required_approving_review_count` to 1 on the assumption a second reviewer was available — they are not — and the resulting trap blocked every merge until it was reverted in jackin-project/jackin-github-terraform#15.

Add a 'Project staffing: solo maintainer' section at the top of `AGENTS.md` naming the constraint and the four downstream consequences: branch protection cannot require an approving review; "get a second pair of eyes" is not an available pre-merge step (pre-merge confidence comes from CI, the path-aware aggregator status checks, the strict up-to-date branch policy, and the agent following PULL_REQUESTS.md); multi-agent review is the load-bearing substitute for the missing second human, not optional polish; and for irreversible or high-blast-radius changes the agent should prefer asking the operator to confirm one more time over assuming green CI is sufficient.

The rule retires when the project gains additional human reviewers.

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