mirror of
https://github.com/got-feedBack/feedBack.git
synced 2026-08-11 03:09:57 +00:00
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:
@@ -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.
|
||||
Reference in New Issue
Block a user