Hook rollout coverage is checkout-driven, so non-resident repos silently never get the suite #991

New issue

Open

opened 2026-08-11 00:41:19 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-11 00:41:19 +00:00

Member

scripts/apply-agentic-os-hooks.py selects its targets from "every git working tree under ~/projects/<org>/*", overridable with $PROJECTS_ROOT. Coverage therefore depends on what happened to be cloned on one machine when the script last ran.

A repository that is deliberately not resident on disk is never a target, gets no managed block, and produces no error. The rollout reports success against the repos it did find.

Confirmed missed

coilyco-flight-deck/agent-proxy - no .pre-commit-config.yaml at all. pre-commit run --all-files fails with InvalidConfigError. Inventory of the resulting cleanup at coilyco-flight-deck/agent-proxy#87.
coilyco-flight-deck/ward-mcp - same, no config on main.

Both are absent from agentic-os-kai/data/repo-registry.md, whose own header describes it as repos "that are also checked out under ~/projects/<owner>/<repo>/". So residency and hook coverage are coupled, and residency is the accident.

Checked by fetching .pre-commit-config.yaml and README.md from each main and comparing status codes, so a private repo does not read as a missing file. ward, cli-guard, agent-compose, sirens-echo, eco-app, and website all have theirs.

Why this is the rollout's problem rather than each repo's

The repo-boundaries rule already puts fleet-wide mutation in the rollout layer rather than in the consumer. A consumer cannot opt into a suite it has never heard of, and there is no signal anywhere that it is uncovered. The .agentic-os-ignore marker gives a repo a deliberate, declarative opt-out, which is the right shape. What is missing is the opposite: a repo that never opted out and still is not covered.

Worth considering

Drive the target set from the Forgejo org listing rather than the on-disk tree, so absence from a laptop is not absence from the fleet. The script already talks to a Forgejo-hosted hook repo.
Failing that, add a coverage check that lists org repos lacking both a managed block and an .agentic-os-ignore, and report it rather than silently skipping.
Either way the gap should be visible in CI, not discovered by a human noticing a repo felt too quiet.

Secondary drift worth a decision

Consumers are spread across two tag trains. deploy is pinned at v0.102.0, which predates typos, actionlint, actions-run-one-line, source-doc-refs, and context-load-points. The script now defaults to aos-precommit-v0.18.0.

So a freshly rolled repo lands on a materially stricter suite than the established ones run, and absorbs new-hook friction the rest of the fleet has not hit yet. That is a separate question from coverage, but it decides what "covered" should mean before backfilling anyone.

`scripts/apply-agentic-os-hooks.py` selects its targets from "every git working tree under `~/projects/<org>/*`", overridable with `$PROJECTS_ROOT`. Coverage therefore depends on what happened to be cloned on one machine when the script last ran. A repository that is deliberately not resident on disk is never a target, gets no managed block, and produces no error. The rollout reports success against the repos it did find. ## Confirmed missed * `coilyco-flight-deck/agent-proxy` - no `.pre-commit-config.yaml` at all. `pre-commit run --all-files` fails with `InvalidConfigError`. Inventory of the resulting cleanup at coilyco-flight-deck/agent-proxy#87. * `coilyco-flight-deck/ward-mcp` - same, no config on `main`. Both are absent from `agentic-os-kai/data/repo-registry.md`, whose own header describes it as repos "that are also checked out under `~/projects/<owner>/<repo>/`". So residency and hook coverage are coupled, and residency is the accident. Checked by fetching `.pre-commit-config.yaml` and `README.md` from each `main` and comparing status codes, so a private repo does not read as a missing file. `ward`, `cli-guard`, `agent-compose`, `sirens-echo`, `eco-app`, and `website` all have theirs. ## Why this is the rollout's problem rather than each repo's The repo-boundaries rule already puts fleet-wide mutation in the rollout layer rather than in the consumer. A consumer cannot opt into a suite it has never heard of, and there is no signal anywhere that it is uncovered. The `.agentic-os-ignore` marker gives a repo a deliberate, declarative opt-out, which is the right shape. What is missing is the opposite: a repo that never opted out and still is not covered. ## Worth considering * Drive the target set from the Forgejo org listing rather than the on-disk tree, so absence from a laptop is not absence from the fleet. The script already talks to a Forgejo-hosted hook repo. * Failing that, add a coverage check that lists org repos lacking both a managed block and an `.agentic-os-ignore`, and report it rather than silently skipping. * Either way the gap should be visible in CI, not discovered by a human noticing a repo felt too quiet. ## Secondary drift worth a decision Consumers are spread across two tag trains. `deploy` is pinned at `v0.102.0`, which predates `typos`, `actionlint`, `actions-run-one-line`, `source-doc-refs`, and `context-load-points`. The script now defaults to `aos-precommit-v0.18.0`. So a freshly rolled repo lands on a materially stricter suite than the established ones run, and absorbs new-hook friction the rest of the fleet has not hit yet. That is a separate question from coverage, but it decides what "covered" should mean before backfilling anyone.

coilyco-ops referenced this issue from a commit

2026-08-11 01:00:28 +00:00

chore: adopt the catalog pre-commit suite at aos-precommit-v0.18.0

coilyco-ops referenced this issue from coilyco-flight-deck/agent-proxy

2026-08-11 01:01:48 +00:00

Adopt the catalog pre-commit suite at aos-precommit-v0.18.0 #90

coilyco-ops added the