Promote Develop: Configure Refusal, WORKFLOW.md Reconciled, Interrupts Rule, Companion-Free Lint, Root hub_fetch_run, .codecov.yml - #4083

…ls (#4076)

## Summary

- **#4072:** `scripts/docker_lint.py` runs its one `git rev-parse
--absolute-git-dir` itself. It clears the same git location variables
`spec/git_env.py` lists, for that call and for its `git ls-files` target
discovery alike. It also carries its own copy of `local_review.py`'s
read-only rmtree handler. So it imports nothing from
`scripts/local_review.py` or `spec/`. Its `COMPANIONS` entry in
`catalog/snippets/hub_fetch_run.py` is now empty, so the Lint tasks
fetch the wrapper alone, still from `main`'s resolved commit.
`RESYNC.md` section 3 step 6 no longer cites a companion list as the
reason to re-copy the helper.
- **#3915:** the prose-gate provenance label names `hub_fetch_run.py` by
its current name, in the helper, its test, `GOVERNANCE.md` "Running the
Linters Locally", and `scripts/README.md`.
- **#4059:** the ruff task labels and their `dependsOn` entries read
`ruff format` and `ruff check` in
`catalog/snippets/configs/vscode-tasks-python.json` and the hub's
`.vscode/tasks.json`.
- **#4071:** `GOVERNANCE.md` "Repo-Scoped Secrets" gains one bullet
stating the owner-first host secret stem
`<shortName>_<purpose>[_<part>]`, with the `github_` provisioning
namespace unchanged. `CODESTYLE.md` is untouched.

## Tests

- `test_the_wrapper_imports_only_the_standard_library` fails if
`docker_lint.py` imports any module outside the standard library again.
- `test_its_git_location_list_is_the_hub_s` holds the copied variable
list equal to `spec/git_env.py`'s.
- `test_an_inherited_git_dir_does_not_move_the_snapshot` and
`test_an_inherited_git_dir_does_not_move_the_targets` fail if either git
call inherits a hook's `GIT_DIR`.
- `test_its_rmtree_handler_is_local_review_s` holds the copied
`unlink_read_only` body equal to `local_review.py`'s.
- `FetchedWrapperTests` now run the wrapper fetched alone, and fail
against the old importing wrapper.
- `test_ruff_tasks_take_the_tool_s_own_casing` fails on the old
capitalized labels.

Closes on promotion: #4072, #3915, #4059, #4071

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **Chores**
* Updated Python formatting and lint task labels to lowercase; the
combined formatting task uses the updated labels.
* Docker linting now handles Git environment settings and snapshot
cleanup more reliably, and fetches only the Docker lint script when
checking a commit.
* **Documentation**
* Updated guidance and provenance labels for secret-file naming and
script checks.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…ts (#4078)

## Summary

Adds the narrowed SIGINT and SIGTERM rule the maintainer chose on #3947
(option 1, answered 2026-11-10).

- `CODESTYLE.md` General gains an "Interrupts" subsection after
"Operations and Failure Messages". A Bash or Python script releases its
temporary paths, locks, and child processes on SIGINT or SIGTERM. It
writes persistent state through a temporary path and a rename. It prints
one line naming the signal, with no traceback, and exits 130 or 143. The
rule applies when a script is created or next edited, with no retrofit
sweep. Only a script holding a lock, temporary state, or a child process
owes a test that signals it mid-run, and that test is skipped on
Windows.
- `CODESTYLE.md` Python gains "Interrupts in Python": a SIGTERM handler
maps the signal onto `KeyboardInterrupt`, and the entry point catches
that exception once.
- `CODESTYLE.md` Shell gains "Interrupts in Shell": cleanup runs in the
`EXIT` trap, and the `INT` and `TERM` traps stop children and keep the
status.
- The `python-codestyle` and `shell-codestyle` skills carry these
sections as generated includes, regenerated with
`scripts/build_dist.py`. Each skill's description names the rule, and
python-codestyle's stays within the 1024-character limit.

### Mechanics stated for the answer's rules

These implement the answer's rules rather than adding new ones. They are
listed so reviewers can check them:

- Every Bash script sets the `INT` and `TERM` traps, and they also print
the signal line. A trap is the only place a shell script knows which
signal ended it, and without one a childless script would print nothing.
- The traps send SIGTERM to children and wait for them, with `|| :` on
both and `2>/dev/null` on `kill`. The children's process IDs sit in an
array set to `()` before the traps, and the trap skips both while
`${#pids[@]}` is 0. On Bash 3.2 under `set -u`, a constructed check
showed that count works on an empty array while `${pids[*]}` fails. A
background child ignores SIGINT. Under `set -eu`, a failed `kill` or
`wait`, or an unset variable, would end the trap before the line prints.
- A long-running external command runs in the background under `wait
"$pid"`, so its status still reaches `set -e`, with `<&0` when it reads
standard input. The trap's `kill` reaches only the process `$!` names.
So a function, a group, a subshell, a pipeline, or `sh -c` runs in the
foreground, where the trap runs once the interrupted command returns.
Only the script's own shell starts a background child, so the child
reaches the script's array and its `wait`. Bash runs a trap only after a
foreground command returns, while a trapped signal ends a `wait` at
once.
- A `subprocess.Popen` child runs without `shell=True` and is terminated
and waited for in a `finally` clause, since leaving its `with` block
does not stop it. A lower Python handler that catches
`KeyboardInterrupt` re-raises it. The rename uses `os.replace`, since
`os.rename` fails on Windows when the target exists.

### Generator fix (pre-existing defect this change exposes)

"Interrupts in Shell" is the last heading in `CODESTYLE.md`. An include
of a file's last heading also copied that file's trailing link-reference
definitions into the skill, which failed markdownlint MD053 in every
copy. This is a `pre-existing` defect in `scripts/build_dist.py`, fixed
here because this change needs it. A body that runs to the end of its
file now ends before those trailing definitions and their grouping
comments. Nothing else about region extraction changes.
`tests/test_build_dist.py` adds a test that fails on `develop` and
passes here, plus a guard showing that a trailing comment with no
definitions after it is kept.

## Verification

- `scripts/build_dist.py --check`: current.
- `tests/test_build_dist.py`: all tests pass. The new
trailing-definitions test fails against `develop`'s generator.
- Prose gate (`--diff origin/develop`), repo gate, ruff, and the Docker
markdownlint and editorconfig-checker runs: all clean.
- The bash trap behavior was checked with constructed probe scripts. The
`EXIT` trap runs when SIGINT or SIGTERM ends the script. A background
child outlives the script unless an `INT` or `TERM` trap stops it. With
the stated trap, SIGINT exits 130 and SIGTERM exits 143, each printing
its line and leaving no child running.

## Declined local-pass findings

- `scripts/build_dist.py`, `introduced`: a pass read "A script takes
this rule when it is created or next edited" as binding this script now,
since this pull request edits it. Declined. The rule binds an edit made
after it is on `develop`, and this pull request is the one that lands
it. The maintainer's answer also rules out a retrofit sweep. So the
script's next edit owes the rule, and the generator fix here stays
limited to ending a body before the trailing definitions.
- `.agents/skills/skill-lifecycle/SKILL.md` line 28, `introduced`: a
pass called its account of where an include body ends stale. Declined.
It describes a body that ends at a heading, which is unchanged, and
`heading_body`'s docstring now states the end-of-file case.
- `CODESTYLE.md` "Interrupts in Shell" and "Interrupts in Python",
`introduced`: a pass noted that an external command which starts
children of its own and does not pass SIGTERM on, such as `find -exec`,
leaves those children running. Declined. The decision names the children
the script started, and a command's own children are that command's to
stop.
- `spec/fidelity_text.py`, `introduced` design finding: a pass suggested
taking definition extents from the parser token's line map. Declined.
The scan reuses `link_definitions` for where each definition starts. The
only shape it misreads is a paragraph line directly after a trailing
definition, which this repository's Markdown never has.

Closes on promotion: #3947

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…equest Trigger (#4081)

## Summary

Reconciles the `WORKFLOW.md` rules that contradicted each other on the
pull request trigger, the tracker publish, and the S7 cleanup. Makes
D1.5 require a `pull_request` trigger on the gate, and teaches the audit
to report a gate without one as a finding it can fix.

- **Section 3 vs section 6 (#4011 item 1, #4051).** The operational
branch-model note now says the lint `pull_request` trigger filters no
base branch, matching section 6. Section 6 drops the clause that gave a
retarget as the reason for that rule. It now gives the stacked pull
request as the reason. It says a retarget starts no run and the head
keeps its stale check, so a retargeted pull request is pushed to, or
closed and reopened, before it merges.
- **Retarget wording (#4060).** `docs/reusable-workflows.md` states the
retarget the same way. The catalog stub keeps the default activity types
and does not change, since `edited` would rerun the gate on every title
or body edit.
- **D8.3 and S11 vs D4.1 (#4011 item 2).** A `main` pin publishes via
the gate only when the merge-bot merges it. A human merge under
`auto-merge: false` ships on the next publish.
- **S7 vs S9, D4.4, D5.2 (#4011 item 3).** S7 hands a schedule or push
run at an already-released version to S9, whose skipped asset delete no
longer contradicts S7's "no dangling artifacts".
- **D1.5 (#4048).** The workflow holding the required aggregator must
trigger on `pull_request`. `spec/audit.py`'s interface check now reports
a gate with no `pull_request` trigger as a finding whose remedy is
adding the trigger. Before, such a gate got only the off-pull-request
name finding, whose remedy alone could never post the check, or no
finding at all where it already used the pull-request-only name.
- The skill's generated `references/` copies are regenerated through
`scripts/build_dist.py`.

## Verification

- The new `CheckInterfaceCase` test fails against the previous
`spec/audit.py`, with the wrong finding for a literal name and no
finding for the pull-request-only expression. It passes with the change.
- `spec/audit.py` is at 2788 lines after merging develop, under its
3000-line ceiling.
- The full unittest suite and `spec/audit.py --selftest` pass on the
merged tree.
- The pre-commit gate (ruff, mypy, prose gate, eol), `build_dist.py
--check`, and markdownlint plus editorconfig-checker through
`docker_lint.py` pass.

## Local-Pass Findings

- `WORKFLOW.md` section 6, the `upstream-wrapper` row, `introduced`: its
test line traced every `main` pin to D8.3's gated publish. Fixed in the
second push, which scopes it to a merge-bot-merged pin.
-
`.agents/skills/branching-and-release-model/references/release-publish-mechanics.md`,
the upstream tracker passage, `pre-existing`, declined: it says a merged
bump "ships on the next publish, not immediately". That holds for every
case here, since even a merge-bot-merged `main` pin publishes in a run
after its merge rather than in the tracker's own run. This branch does
not change that case.

Closes on promotion: #4011, #4051, #4048, #4060

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **Documentation**
* Clarified which pull requests trigger lint checks and how retargeted
pull requests can be revalidated.
* Updated guidance on release-gate publishing, version-bump merges, and
scheduled or repeated publish runs.
* **Bug Fixes**
* The audit now flags required checks whose workflows lack a
pull-request trigger.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

## Summary

Every fleet repo now keeps `hub_fetch_run.py` in its repo root,
whichever commit hook it wires.

- **Before:** the Husky.Net snippet kept the helper at
`.husky/hub_fetch_run.py`, and the `pre-commit` framework snippet kept
it in the root.
- **Why the split could go:** nothing required it.
- The Husky.Net hook already moves to the top level before it runs a
gate.
- The audit and `python_directories.py` exempt the helper by its file
name, wherever it sits.
  - The helper reads nothing relative to its own location.
- **Why the root:** it is the only directory both hook types share.

## Changes

- `catalog/snippets/husky/pre-commit`: resolves the helper as
`$PWD/hub_fetch_run.py` after the existing `cd` to the top level, where
it used to resolve it from `dirname "$0"`. One edited comment corrects
the stated location, hence the `comments` label.
- `catalog/snippets/configs/vscode-tasks.json`: the 12 Lint task
arguments now name `${workspaceFolder}/hub_fetch_run.py`.
- `catalog/snippets/configs/vscode-tasks-python.json`: drops the two
comment lines describing the old Husky.Net layout.
- `GOVERNANCE.md`, `STANDUP.md`, `catalog/snippets/husky/README.md`,
`docs/pre-commit-hooks-rollout.md`: each now names the repo root as the
helper's location.
- `RESYNC.md` step 6: a helper still under `.husky/` moves to the root
in the same commit as its callers.
- `tests/test_hub_fetch_run.py`: both task snippets are checked against
one root path. Two new tests:
  - every task argument naming the helper names the root copy
- the Husky.Net hook resolves the helper only after its `cd` to the top
level

## Fleet impact

A live read of every registered repo's `develop` found none carrying
`.husky/hub_fetch_run.py`, so no repo needs to move the file.

- The Husky.Net repos do not call the helper from their hooks yet.
- Every repo that does carry it uses the `pre-commit` framework and
already keeps it in the root.
- Two repos keep a stale comment from the old Python tasks snippet. It
changes no behaviour, and the next routine resync replaces it.

## Verification

- Full unittest suite, run with `tests/requirements.txt`: 3882 tests
passed, 11 skipped.
- `shellcheck` and `shfmt -d` on the hook snippet: clean.
- Prose gate and EOL check: clean, with comments allowed for the one
edited hook comment.
- Local strict review, two passes:
- The first raised three introduced findings, all fixed in `2d7fb37e`:
an assertion that could not fail, the RESYNC rename-and-move wording,
and the rollout doc's copy destination.
  - The second raised none.
- After `develop` was merged in, with two conflicts resolved by keeping
both sides:
  - The full suite passed: 3880 tests.
- A further local pass raised one introduced finding. The root-location
claim said "every fleet repo", although the hub keeps no root copy. It
was fixed in `0f252f20` by scoping the claim to downstream repos, and
the re-review raised none.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…he Develop Checkout for an Unpromoted Entry (#4082)

## Summary

`repo-config/configure.sh apply` refuses a repository with no entry in
the registry it reads, before any write. Without the entry, the rulesets
and agent policy files came from the default policy, so a repository
whose entry sat on `develop` only was silently given a required status
check it may have declared off. The refusal names the registry and says
the entry may be on `develop` only. `apply` also refuses when
`registry/repos.json` is absent. `check` is unchanged.

The docs state the supported path for that case: a repository whose
registry entry has merged to the hub's `develop` but not yet reached
`main` is configured and checked, and its secrets audit run, from a hub
checkout at `develop`. Every other repository's run stays on `main`. Per
the maintainer's answer on the issue, no check refuses a non-`main`
checkout.

- `repo-config/configure.sh`: the refusal, matched case-insensitively so
a case-only near-miss still reaches `spec/resolve_description.py`'s own
refusal. The `jqr` helper moves above the registry region, whose lookups
use it, so its comment block reads as added and the pull request carries
the `comments` label.
- `tests/test_configure_archived.py`: the refusal's cases join the
harness that already lifts the registry region (an unlisted name, an
absent registry, a listed name in either letter case, a carriage return
on the entry count), and the end-to-end case covers an unregistered
`apply --checkout` with a recording `gh` stub. Four of them fail against
the previous script.
- `STANDUP.md` section 4, `docs/repo-config.md`,
`repo-config/README.md`: the refusal and the `develop` checkout.
- `OPERATIONS.md`, `AUDIT.md` section 6, and the
`branching-and-release-model` branch-protection reference: each named
only a `main` checkout, and two told an unregistered repository to pass
the model to `apply`.
- `GOVERNANCE.md` "Hub-Hosted Tooling": the `develop` case for
`configure.sh` and `spec/audit.py`.
- `standup-a-repo` step 8 and `audit-a-repo`'s configuration-check line:
the `develop` checkout. Generated skill trees regenerated through
`scripts/build_dist.py`.

## Local review

- Declined: reusing `archived_status` for the presence test. Its
exact-case match would refuse a case-only typo as "no entry, may be on
develop only". The case-insensitive count lets that typo reach
`spec/resolve_description.py`, whose refusal names the near-miss.

## Findings listed at the opening push, fixed in 7fe1a00

Each was fixed on the next push, and the local pass over that head
raised none.


- `docs/repo-config.md:18` (`introduced`): "`apply` refuses a repository
without one" reads as a repository without a model.
- `repo-config/configure.sh:220` (`introduced`): the refusal message's
second sentence runs past 25 words and carries two instructions.
- `repo-config/configure.sh:215` (`introduced`): the entry-count guard's
"(invalid JSON?)" hint names a cause the earlier status read already
catches.
- `tests/test_configure_archived.py:8` (`introduced`): the docstring
says "absent entry" where it means an absent registry under `check`.

## Dropped findings

- `repo-config/configure.sh` workflowModel lookup, below the registry
region: consolidation onto `jqr`, on text this change did not touch.

Closes on promotion: #4061

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>