mirror of
https://github.com/got-feedBack/feedBack.git
synced 2026-07-27 23:31:54 +00:00
22332bef22
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> |
||
|---|---|---|
| .claude/skills | ||
| .github | ||
| .specify | ||
| content/starter | ||
| data/progression | ||
| docs | ||
| lib | ||
| plugins | ||
| scripts | ||
| specs | ||
| static | ||
| tests | ||
| tools | ||
| .dockerignore | ||
| .feedpak-spec-ref | ||
| .gitattributes | ||
| .gitignore | ||
| build-proxmox-ct.sh | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| docker-compose.nas.yml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| eslint.config.js | ||
| feedpak-spec-exceptions.yml | ||
| LICENSE | ||
| main.py | ||
| package-lock.json | ||
| package.json | ||
| playwright.config.ts | ||
| pyproject.toml | ||
| requirements-test.txt | ||
| requirements.txt | ||
| server.py | ||
| SUPPORTERS.md | ||
| tailwind.config.js | ||
| TODO.md | ||
| uv.lock | ||
| VERSION | ||