synchronize_mip_package.py's PROFILE_REPOSITORIES still hardcodes audioinstruments/audioeffects to audioif, blocking their MIP publication from audiocomponents

[bdbarnett]

What's blocked

audiocomponents v0.2.0 is the first release of audioinstruments and
audioeffects from their new home (the audioif/audiocomponents split,
audiocomponents#2). The board session repointed pydevices-lock.json on
PyDevices/mip's PyDevices branch to name PyDevices/audiocomponents at
v0.2.0 for both entries (commit f94ef5e9), which is the fix
reusable-synchronize-mip-package.yml's own "Record this release in the
lockfile" step is designed to require.

That was not enough. Both queued publication runs still fail identically,
before and after the lockfile fix and after a rerun of each:

• audioinstruments: run 33814552433 — failure (rerun after the lockfile fix, same result)
• audioeffects: run 33814552790 — failure (rerun after the lockfile fix, same result)

Both fail with:

profile 'audioinstruments' requires PyDevices/audioif, not PyDevices/audiocomponents
##[error]Process completed with exit code 1.

(The audioeffects run hits the same line because "Synchronize every locked
source" iterates every profile in the lockfile, alphabetically, and dies on
audioinstruments first regardless of which profile was actually
dispatched.)

Root cause

This check is not lockfile-driven. scripts/synchronize_mip_package.py
(fetched by reusable-synchronize-mip-package.yml into
.pydevices-publishing-tools, at whatever tag publishing-tools-ref
resolves to — publishing-v6 by default, since PyDevices/mip's
process-mip-publication-request.yml doesn't override it) hardcodes a
second, independent source of truth:

PROFILE_REPOSITORIES = {
    "palettes": "PyDevices/palettes",
    "pdwidgets": "PyDevices/pdwidgets",
    "pygraphics": "PyDevices/pygraphics",
    "pydevices": "PyDevices/pydevices",
    "audioinstruments": "PyDevices/audioif",
    "audioeffects": "PyDevices/audioif",
}
...
expected_repository = PROFILE_REPOSITORIES[args.profile]
if args.source_repository_name != expected_repository:
    raise SystemExit(
        f"profile {args.profile!r} requires {expected_repository}, "
        f"not {args.source_repository_name}"
    )

Confirmed identical at both publishing-v6 (mip's coordinator default) and
publishing-v8 (audiocomponents' and audioif's current pin) — this map was
never updated for the split. Publishing tags are immutable by policy, so
neither existing tag can be patched in place.

What's needed

1. Update PROFILE_REPOSITORIES in scripts/synchronize_mip_package.py so
   audioinstruments and audioeffects map to PyDevices/audiocomponents
   (or, better, derive the expected repository from pydevices-lock.json
   itself rather than hardcoding it a second time — the lockfile is already
   the source of truth the "Record this release" step writes to, and having
   two disagreeing sources of truth is exactly what produced this outage).
2. Cut a new publishing tag (e.g. publishing-v9) carrying the fix, per
   publishing-automation.md's own rule that a reusable-workflow contract
   change is "an automation rollout, not a package release."
3. Update PyDevices/mip's process-mip-publication-request.yml uses:
   pin (currently @publishing-v6) to the new tag.
4. Retry the two queued audiocomponents publications
   (gh run rerun 33814552433 -R PyDevices/mip,
   gh run rerun 33814552790 -R PyDevices/mip, or a fresh manual dispatch
   with the same source-repository/source-ref/version/profile) once the new
   tag is live.

Current state

As of 2026-09-03 22:56 UTC, the live index still reports 0.1.1 for both
audioinstruments and audioeffects
(https://PyDevices.github.io/mip/package/6/audioinstruments/latest.json,
.../audioeffects/latest.json) — audioif's last publish. TestPyPI already
has both packages at 0.2.0
(https://test.pypi.org/project/pydevices-audioinstruments/0.2.0/,
https://test.pypi.org/project/pydevices-audioeffects/0.2.0/); only the MIP
index is stuck behind this script fix.

Related: #34 (a second, independent release-health race hit by this same
release).

[bdbarnett]

Fixed at the source: 9aef8e68 on main updates PROFILE_REPOSITORIES so both audio profiles name PyDevices/audiocomponents. Rather than cut a publishing tag at midnight, PyDevices/mip's coordinator now passes publishing-tools-ref: 9aef8e68… to the reusable (the input exists for exactly this; the reusable itself stays at @publishing-v6), and both profiles are being re-dispatched. When the next publishing tag is cut, that line becomes the tag and this issue closes. Note for the design: the map and the lockfile are two guards that must agree; deriving the map from the lockfile (mip's pydevices-lock.json is on the runner already) would leave one guard, edited in one place, by the humans who own the index.

[bdbarnett]

Audit 2026-09-04: partially addressed — two asks remain.

Done: ask 1 — scripts/synchronize_mip_package.py:79-88 maps both audio profiles to PyDevices/audiocomponents (9aef8e6, on the remote). Ask 4 — the outage is cleared: the index serves audioinstruments and audioeffects at 0.2.0, against 0.1.1 at filing.

Remaining: ask 2, cut publishing-v9 carrying the corrected map; and the tag half of ask 3, turning mip's publishing-tools-ref from a raw SHA into that tag. Until both land, every MIP publication depends on a floating commit pin inside a system whose other refs are immutable tags — which is the same discipline .github#26 exists to remove.

[bdbarnett]

Rolled out 2026-09-06: PR #37 merged as 290d23f and tagged publishing-v9; PyDevices/mip's coordinator now pins both the reusable and publishing-tools-ref to that tag (2b329693 on the PyDevices branch), retiring the floating commit pin. The lockfile is the single owner of profile → repository, enforced by the record step. The next publication proves the chain end to end; the index already serves both audio packages at 0.2.0, so nothing needed re-running.