pr-guard is inert until it joins DEFAULT_HOOK_IDS after a release tags it #1148

Closed
opened 2026-08-20 06:35:49 +00:00 by coilyco-ops · 0 comments
Owner

Why this exists

#1146 ships the pr-guard pre-push hook, but not in DEFAULT_HOOK_IDS. It had to come out to get CI green: the agentic-os#187 guard correctly rejected listing a hook that the pinned release tag does not carry, because that makes every consumer's pre-commit init fail with pr-guard is not present in repository ... rev aos-precommit-v0.32.0.

The consequence is that the hook does nothing for any consumer until this lands. It is installable by name for a repo that opts in explicitly, and otherwise inert. The whole point of #1146 is keeping default branches PR-only across the fleet, and that does not start happening until pr-guard is in the default rollout.

The sequence

Ordering matters, and each step is already automated:

  1. Merge #1146 to main.
  2. promote.yml fires on push to main and promotes the same sha to release.
  3. aos-precommit-release.yml fires on push to release because .pre-commit-hooks.yaml is in its paths filter, and cuts the next tag via tag-bump with tag_prefix: aos-precommit-v. Default bump is minor, so aos-precommit-v0.33.0.
  4. default_rev() resolves the latest release tag at runtime, so it picks up the new tag with no DEFAULT_REV bump commit.
  5. Then add "pr-guard" to DEFAULT_HOOK_IDS in scripts/apply-agentic-os-hooks.py. One line. test_default_hook_ids_present_at_default_rev will pass on its own because the tag now carries the hook.

Step 5 is the only manual change. Steps 2 and 3 need nothing but the merge.

A second gap worth fixing in the same pass

aos-precommit-release.yml filters on paths, and that list names hook scripts individually:

paths:
  - ".pre-commit-hooks.yaml"
  - "agentic_os/__init__.py"
  ...
  - "scripts/trufflehog-scan.sh"

scripts/pr-guard-pre-push.sh is not in it. The initial release will still fire, because #1146 also touches .pre-commit-hooks.yaml. But once the hook entry is stable, a later fix to pr-guard-pre-push.sh alone changes no listed path, so no release is cut, no tag moves, and consumers pinned to rev=aos-precommit-vX.Y.Z keep running the old script indefinitely with no signal that a fix exists.

scripts/trufflehog-scan.sh being on that list is the precedent: a hook's script is part of its installed surface. Add scripts/pr-guard-pre-push.sh alongside it.

Worth a wider check that every script referenced from .pre-commit-hooks.yaml appears in that paths list, since the same silent-staleness applies to any that do not. A test asserting that invariant would hold it in place the way #187's guard holds the rev/hook-list invariant.

Acceptance

  • "pr-guard" is in DEFAULT_HOOK_IDS and test_default_hook_ids_present_at_default_rev passes.
  • A release tag exists that carries the pr-guard entry in .pre-commit-hooks.yaml.
  • scripts/pr-guard-pre-push.sh is in the aos-precommit-release.yml paths filter.
  • A consumer repo running the rollout picks up pr-guard without naming it explicitly.

Blocked on #1146 merging.

## Why this exists #1146 ships the `pr-guard` pre-push hook, but **not** in `DEFAULT_HOOK_IDS`. It had to come out to get CI green: the agentic-os#187 guard correctly rejected listing a hook that the pinned release tag does not carry, because that makes every consumer's `pre-commit` init fail with `pr-guard is not present in repository ... rev aos-precommit-v0.32.0`. The consequence is that **the hook does nothing for any consumer** until this lands. It is installable by name for a repo that opts in explicitly, and otherwise inert. The whole point of #1146 is keeping default branches PR-only across the fleet, and that does not start happening until `pr-guard` is in the default rollout. ## The sequence Ordering matters, and each step is already automated: 1. Merge #1146 to `main`. 2. `promote.yml` fires on push to `main` and promotes the same sha to `release`. 3. `aos-precommit-release.yml` fires on push to `release` because `.pre-commit-hooks.yaml` is in its `paths` filter, and cuts the next tag via `tag-bump` with `tag_prefix: aos-precommit-v`. Default bump is `minor`, so `aos-precommit-v0.33.0`. 4. `default_rev()` resolves the latest release tag at runtime, so it picks up the new tag with no `DEFAULT_REV` bump commit. 5. **Then** add `"pr-guard"` to `DEFAULT_HOOK_IDS` in `scripts/apply-agentic-os-hooks.py`. One line. `test_default_hook_ids_present_at_default_rev` will pass on its own because the tag now carries the hook. Step 5 is the only manual change. Steps 2 and 3 need nothing but the merge. ## A second gap worth fixing in the same pass `aos-precommit-release.yml` filters on `paths`, and that list names hook scripts individually: ```yaml paths: - ".pre-commit-hooks.yaml" - "agentic_os/__init__.py" ... - "scripts/trufflehog-scan.sh" ``` `scripts/pr-guard-pre-push.sh` is **not** in it. The initial release will still fire, because #1146 also touches `.pre-commit-hooks.yaml`. But once the hook entry is stable, a later fix to `pr-guard-pre-push.sh` alone changes no listed path, so no release is cut, no tag moves, and consumers pinned to `rev=aos-precommit-vX.Y.Z` keep running the old script indefinitely with no signal that a fix exists. `scripts/trufflehog-scan.sh` being on that list is the precedent: a hook's script is part of its installed surface. Add `scripts/pr-guard-pre-push.sh` alongside it. Worth a wider check that every script referenced from `.pre-commit-hooks.yaml` appears in that `paths` list, since the same silent-staleness applies to any that do not. A test asserting that invariant would hold it in place the way #187's guard holds the rev/hook-list invariant. ## Acceptance * `"pr-guard"` is in `DEFAULT_HOOK_IDS` and `test_default_hook_ids_present_at_default_rev` passes. * A release tag exists that carries the `pr-guard` entry in `.pre-commit-hooks.yaml`. * `scripts/pr-guard-pre-push.sh` is in the `aos-precommit-release.yml` `paths` filter. * A consumer repo running the rollout picks up `pr-guard` without naming it explicitly. Blocked on #1146 merging.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agentic-os#1148
No description provided.