ci: gate core against the feedpak spec

feedpak is published as an open format with its own repo, normative spec,
JSON Schemas, and reference validator. That makes the spec a contract with
everyone outside this repo: third-party packers, converters, and players
build against it, and it is meant to be the complete description of a pack.

Nothing enforced that. #583 added a manifest key (`original_audio`) that
core, lib/enrichment.py, and the stems plugin all now depend on, but which
was never added to the spec — so a spec-compliant pack stopped being a
fully-working pack, the reference validator could not warn authors about a
key it had never heard of, and third-party tooling began emitting an
`original/` directory reverse-engineered from an example in a code comment.
See #933.

We cannot mechanically prove core interprets a key the way the spec means.
We can prove three surface properties, and they cover the drift that
actually happens:

  1. key-coverage — every manifest key core reads is declared in the spec's
     manifest.schema.json (AST scan of lib/sloppak.py, lib/enrichment.py,
     lib/songmeta.py).
  2. forward — core's load_song() ingests every example pack the spec ships.
  3. reverse — every pack committed here passes the spec's own
     tools/validate.py (7/7 pass today).

The spec is pinned by SHA in .feedpak-spec-ref rather than tracked from its
default branch, so a change over there cannot redden an unrelated PR here;
bump it in its own PR, where a red result is precisely the signal that core
does not satisfy the new spec.

A gate with no legitimate way to say "yes, deliberately, not yet" gets
switched off the first time it blocks a release, so there are two escape
hatches: the reserved `x-` key prefix (always permitted, and it tells every
third-party packer the key is not stable surface), and
feedpak-spec-exceptions.yml, which requires a tracking issue per entry. An
exception that goes stale — the spec caught up, or core stopped reading the
key — fails the build, so the allowlist cannot become somewhere drift
quietly accumulates. `original_audio` is seeded there against #933 so the
gate lands green and starts blocking the next instance immediately, rather
than requiring #933 to be resolved first.

Dev/CI tooling only; never on the serve or Docker path (constitution
Principle I). jsonschema is installed in the CI job, not added to
requirements.txt.

Signed-off-by: topkoa <topkoa@gmail.com>
This commit is contained in:
topkoa
2026-07-12 23:30:45 -04:00
parent 342def3851
commit 22332bef22
6 changed files with 453 additions and 0 deletions
+30
View File
@@ -0,0 +1,30 @@
# Manifest keys core reads that the feedpak spec does not (yet) define.
#
# This file exists so the spec-conformance gate (tools/check_spec_conformance.py)
# can be honest instead of being switched off. A gate with no legitimate way to
# say "yes, deliberately, not yet" gets commented out the first time it blocks a
# release — so drift that is *known and tracked* is allowed to sit here, and
# only drift that is unknown and untracked fails the build.
#
# Rules:
# - Every entry needs a tracking issue. No issue, no exception.
# - Entries are debt, not policy. The fix is to land the key in the spec
# (github.com/got-feedback/feedpak-spec) and delete the entry.
# - The gate fails if an entry goes stale — i.e. the spec caught up, or core
# stopped reading the key. The allowlist must never become a hiding place.
#
# For a key that is genuinely experimental and not yet ready for the spec,
# prefer the reserved `x-` prefix (e.g. `x-my_new_key`) over an exception: the
# gate permits `x-`-prefixed keys unconditionally, and the prefix tells every
# third-party packer that the key is not stable surface.
exceptions:
- key: original_audio
issue: https://github.com/got-feedback/feedback/issues/933
reason: >-
Added by #583 (the full mix played while every stem fader sits at unity,
since demucs recombination is lossy). Core, lib/enrichment.py, and the
stems plugin all depend on it, but it was never added to the spec — the
drift this gate exists to prevent. Seeded here so the gate lands green and
starts blocking the *next* instance immediately; remove once the spec
adopts the key.