operational-vs-release-workflow skill still describes repo-config/ as carried, not hub-hosted

[ptr727]

What happened

`.agents/skills/operational-vs-release-workflow/references/branch-protection-and-promotion.md` still describes `repo-config/` as a repo-relative path a downstream repo carries, which contradicts the model `repo-config.md`/`spec/divergences.json` moved to in #863 (the whole directory is hub-hosted now, reached from a hub checkout by name, not carried downstream).

Specific lines (checked against the hub's own current `main`):

• Line 13: ``repo-config/*.json`` payloads. Run ``repo-config/configure.sh apply /`` - reads as a bare command runnable from the downstream repo, when it now only resolves from a hub checkout.
• Line 17: See ``repo-config/README.md`` "Rulesets" for the configured state. - `repo-config/README.md` no longer exists in a downstream repo per the `retire` disposition in `spec/divergences.json`.
• Line 24: kept off in ``repo-config/settings.json`` - same issue.
• Line 108: See ``repo-config/README.md`` - same issue.

Context

Found while resyncing `ptr727/Financial-Modeling` onto the new `repo-config/` model (ptr727/Financial-Modeling#122). `GOVERNANCE.md`'s own `Workflow YAML Conventions` section and `workflow-ci-contract/SKILL.md` already say "the hub's `repo-config/` payloads" correctly - this one skill file's references doc appears to be the one place that didn't get the same pass.

Two other files a reviewer initially flagged alongside this one (`comment-and-doc-style/SKILL.md` and `comment-and-doc-style/references/carried-doc-references.md`) turned out to already be clean on current `main` - no `repo-config` mentions at all - so this issue is scoped to just the one file above.

[ptr727]

One more defect in the same file, same fix point, so noting it here rather than opening a second issue: current main's wrapping also breaks Markdown syntax, not just content accuracy.

Lines 13-14:

`repo-config/*.json` payloads. Run `repo-config/configure.sh apply <owner>/<repo>
release|operational` from a hub checkout at `main`. The names are load-bearing because governance

The inline code span opened before repo-config/configure.sh apply <owner>/<repo> closes only after release|operational on the next line - an inline code span can't contain a hard line break, so most Markdown renderers either fail to close it as code at all or render it oddly, and the command is split in a way that breaks copy/paste regardless of rendering. Rewrapping it onto one line (or a fenced block) fixes both this and the content-staleness issue above in the same edit.

Found via a suppressed Copilot finding while re-vendoring this file into ptr727/Financial-Modeling (#121).

[ptr727]

Reopening: the fix (#881/#882, commit 6d7800c) only addressed the Markdown code-span line-break bug from my follow-up comment. Three of the four originally-reported bare repo-config/README.md/repo-config/settings.json mentions are still present on current main (fa63163), unchanged from what this issue originally quoted:

$ git show origin/main:.github/skills/operational-vs-release-workflow/references/branch-protection-and-promotion.md | grep -n 'repo-config/README.md\|repo-config/settings.json'
17:explicitly for a repository outside the registry. See the hub's `repo-config/README.md`
26:  `repo-config/settings.json` for exactly this reason) deletes `develop` itself. Merge a promotion
110:same form, and do not reintroduce `app-id` / `CODEGEN_APP_ID`. See the hub's
111:`repo-config/README.md` "Secrets" for which secrets each mechanism needs.

Same in the .agents/skills/ source copy, so this isn't a build_dist.py desync -- the three mentions were simply never touched.

Found while resyncing ptr727/HomeAutomation-Config (#75/#76). CodeRabbit flagged all three as review findings on both PRs; declined locally each time as hub-owned verbatim content carried via scripts/carry.py, with a note to flag upstream here instead of diverging the local copy.

audit run 2026-08-25T13:46:24Z | hub fa63163

[ptr727]

Re-checked against current main (contains fa63163, the SHA this reopening cited) before doing anything else, since a PR would chase a non-issue otherwise.

All three mentions this reopening flagged already carry the "the hub's" qualifier, and have since #881 (commit 6d7800c, merged 2026-08-20):

17:explicitly for a repository outside the registry. See the hub's `repo-config/README.md`
25:  (and a repo's "Automatically delete head branches" toggle, kept off in the hub's
109:same form, and do not reintroduce `app-id` / `CODEGEN_APP_ID`. See the hub's

git merge-base --is-ancestor 6d7800c origin/main confirms fa63163 already contains that fix. The reopening comment's own git-show output quotes this exact text ("See the hub's repo-config/README.md", "kept off in the hub's repo-config/settings.json") -- so the claim that these are "unchanged...bare" mentions doesn't match the evidence it quoted itself.

repo-config/README.md and repo-config/settings.json also genuinely still exist in the hub today (per #861's disposition: hosted centrally, not carried downstream), so "the hub's repo-config/README.md" is an accurate live reference, not a dead path. Source (.agents/skills/) and generated (.github/skills/) copies are identical, so this isn't a build_dist.py desync either.

Likely actual friction: CodeRabbit's path-matcher on the downstream repo doesn't parse the "the hub's" prose qualifier and flags any repo-config/-shaped backtick span regardless of context -- the same false-positive class already declined on this content each time it recurred. That's a CodeRabbit-side limitation, not a wording gap here.

Closing as already resolved. Reopen with a specific line number if a genuinely unqualified (bare) mention turns up somewhere else.