[cchacs]

Closes #131 (sub-issue 1/5 of #102). Docs only — no loader, capability, or minHost behaviour change, and no work started on the dependent sub-issues.

What it adds

docs/compatibility.md — one row per host API from #102's dependency list, each with:

• the exact commit (full SHA, linked) and its UTC date,
• what it provides and where that surface lives at HEAD,
• the dependent plugin(s) and the specific feature that needs it,
• required vs. optional, with the failure mode spelled out,
• upstream or fork-only,
• the plugin revision each row was read at.

Plus: why the version string can't answer any of this (a VERSION history table — 0.3.0-alpha.2 spans 83 commits and three of the seven APIs), a candidate-baseline section, the minHost status (passthrough metadata, no enforcement, no feature-scoped field in the manifest schema), copy-pasteable per-row check commands, links to Visual Export's #6/#7, and an audit-metadata table stating exactly what was and was not done.

Corrections this audit found in #102's list

1. Lyrics Karaoke does not require 0dcc913. At 5e9d586 it imports the helper opportunistically and falls back to safepath.safe_join; neither shape is weaker on containment. It's a preferred path, not a floor — and difficulty_ladder's top-level from dlc_paths import … genuinely is one, because a missing module fails the whole routes.py import and no generation route is ever registered.
2. Splitscreen's need for f7c761c is optional, and the dependent feature is deterministic/coordinated frame rendering — not LAN sharing, which depends on 03e1c1d and is itself optional.
3. f7c761c is 2026-09-17 UTC, not Sep 16 (local timezone in Define a verifiable core compatibility baseline for current plugins #102).

Honesty notes

• Every row is source-audited, not runtime-certified — stated at the top of the document and in the audit table's "Not done" row. No plugin was run against a historical host build.
• The upstream/fork column is derived from gh api repos/got-feedback/feedBack/compare/<sha>...main, not from the SHA being resolvable on GitHub: f7c761c, 7633211 and e5339c0 all resolve upstream but are not on upstream main.
• e5339c0 is confirmed (via git merge-base --is-ancestor for all seven) to be the earliest commit descending from every row, so it is the cheapest single baseline identity — but the document says explicitly to name the row a feature needs, not the moving baseline.

Checklist

• Branched from and targets main
• Scoped to sub-issue 1/5 only
• CHANGELOG.md [Unreleased] updated
• No Tailwind classes added, so no stylesheet rebuild needed

[pullfrog]

Fixed by relabelling the commit subject — no content change.

Diagnosis. The only failing job was core-commit-labeling (fork-audit.yml). Its step rejects any commit in base..head that touches a non-excluded path without a core: / hook: / sync: / fix: subject prefix. 06e4f4e touched README.md, which is core under this fork's "what counts as core" rule (everything outside plugins/, docs/, tests/, scripts/, specs/, CHANGELOG.md, VERSION), while docs/ and CHANGELOG.md were excluded. So docs: add a host/plugin compatibility matrix… failed on both counts at once.

Fix. The exclusion list is per-file, so the README link index entry is what makes this a core commit. The fork policy has no docs: prefix, so the subject is now core(docs): add a host/plugin compatibility matrix pinned to commits (#131) — scoped parens are accepted by the regex, and the commit body gained a paragraph recording why core(docs): is used here and that docs: remains correct for the same change upstream.

Verified. git commit --amend preserved the tree (75476f4), the parent (d1980ff), and the author. Re-running the workflow's exclusion grep and prefix regex byte-for-byte over the range (1 commit, fully local so the repro is faithful) passes; the old subject still fails, matching CI. Force-pushed to docs/131-compat-baseline-matrix — new head 3fe9de8, identical tree. No file contents changed, so no other check is affected.

Task list (5/5 completed)

• Checkout PR docs: add a host/plugin compatibility matrix pinned to commits (#131) #137 branch
• Fetch check suite logs for failure diagnosis
• Verify failure was introduced by this PR
• Fix the issue and verify with exact CI command
• Commit and push to PR branch

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using big-pickle (free) ｜ 𝕏}

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[pullfrog]

Important

The audit itself is unusually solid — I reproduced every commit SHA, committer date, ancestry relation and the entire upstream/fork column using the document's own documented commands, and all seven host file:line references are exact. What should be fixed before merge is five factual errors in the supporting prose, all in the same "this is the precise identity" class the document exists to provide: a VERSION date off by one day, a Splitscreen commit cited as shipped that never merged, a warning attributed to a code path that never warns, a plugin's actual gate named incorrectly, and two per-row check commands that report a fully capable build as missing the API. Each is a prose edit.

Reviewed changes

• New docs/compatibility.md — a seven-row matrix mapping host APIs to the plugin features that need them, each row pinned to an exact commit with its UTC committer date, the host file:line surface, the dependent plugins, required-vs-optional with the failure mode spelled out, upstream-or-fork, and the plugin revision audited.
• "Why not version strings" — the complete VERSION history (four commits, ever) plus the commit ranges the single 0.3.0-alpha.2 string spans, and why that makes a commit hash the only usable identity today.
• Row-by-row evidence sections — for each row, the host surface at HEAD plus the dependent plugin's actual import/call shape, with the degrade path traced rather than asserted.
• Supporting sections — the candidate baseline (e5339c0) with its ancestry proof, the minHost-is-metadata status, copy-pasteable per-row check commands, three corrections to #102's dependency list, and an audit-metadata table that states what was not done.
• README.md / CHANGELOG.md — a docs-index entry and an [Unreleased] entry summarising the matrix.

Independently confirmed while reading: all seven row commits resolve with the exact dates in the table; the Upstream? column reproduces exactly via gh api repos/got-feedback/feedBack/compare/<sha>...main --jq .status (rows 1–4 ahead, rows 5–7 behind); upstream main really is eef58c8, which is why the last three rows cannot be upstream; the 278 / 83 commit ranges are right; the fork has no tags and no releases; b6169af6 is an ancestor of 0dcc913, so it genuinely contains none of the seven APIs; and Difficulty Ladder's unguarded import, Lyrics Karaoke's safe_join fallback and Feedpakr's insufficient-is not None guard all match what the document says.

ℹ️ The pins have no staleness signal

Every re-audit trigger the document lists — a commit superseded, a plugin's default branch moving past the audited revision, a release finally naming a baseline — is a silent event. Nothing in CI notices when one fires, and the failure mode is a confidently wrong table rather than a missing one. Piano already solves this exact problem in-ecosystem: tools/verify-host-surface.js re-checks its audited refs on a schedule so core drift fails loudly. The same shape would cover the seven plugin revisions here. Not a blocker for this sub-issue, but it is what decides whether this table is still true in six months.

ℹ️ Nitpicks

• Row 3, Chordr status string — window.chordr.getChartTransformStatus() returns "unavailable" (screen.js:411, exposed at :1006); "no-owner" is the dispatch reason that only ever appears inside the console warning (:414-415). "Reports a no-owner state" reads as a verbatim value.
• Row 2, Difficulty Ladder — read_member_bytes reads the arrangement (routes.py:3099) and generic pack JSON side files (:3211); the manifest goes through sloppak.load_manifest (:3080). "arrangement/manifest members" names one right and one wrong.
• Row 1, Lyrics Karaoke — the None return surfaces as 404 on lk_data/lk_playback, 400 on lk_align/lk_save_lyrics/lk_generate_pitch, and a 200 with is_sloppak: false on lk_status. "A 404 the caller already handles" is faithful to the plugin's own docstring but not to all five call sites.
• Row 2, Feedpakr — three of the four paths that reach the missing attribute are named; /api/plugins/feedpakr/lyrics-text calls sloppak_mod.read_member_bytes directly with no try around it, making it the least contained of the four. Worth naming, since the failure mode is the row's whole point.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using big-pickle (free) ｜ 𝕏}

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• docs/compatibility.md — the last unresolved finding (row 5's Required? cell) is fixed at this revision
• CHANGELOG.md — date bump matches the compatibility table

Verification notes

Incremental diff (9475347..6549627) is a single-line docs change: docs/compatibility.md:57 now reads "(feature-detected, degrades silently)" instead of "(feature-detected, warns and degrades)". This resolves the only remaining active inline finding (pullfrog comment 4170266048); the cell now agrees with the Row-5 evidence section at lines 147-153, which states the coordinated-frame path degrades silently and that the warn-once fires only from beginOfflineRender(). Re-read line 57 against the current diff — the fix is present and no other line changed. All five prior findings remain resolved at HEAD. No new defects in the changed line.

_{Reviewed by free · Input: 0 · Output: 0 · Cached: 0}

Previous Review Summaries (2 snapshots, latest commit 9475347)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 9475347)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• docs/compatibility.md — 5 previous findings all fixed in this revision
• CHANGELOG.md — date bump matches the compatibility table

Verification notes

Incremental diff (3fe9de8..9475347) is docs-only (+24/-12). All five prior findings re-verified against current HEAD and resolved: line-28 date now 2026-08-10; line-141 cites only 2301dd5 with a side-branch note; lines 147-153 state silent degradation and name both predicates; lines 163-166 gate Difficulty Ladder on fb.capabilities.dispatch; checks 1-2 at lines 238-241 carry PYTHONPATH=lib. CHANGELOG line 12 matches. No new defects in the changed lines.

_{Reviewed by free · Input: 0 · Output: 0 · Cached: 0}

Previous review (commit 3fe9de8)

Status: 5 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	5
SUGGESTION	0

Issue Details (click to expand)

All five findings below are already reported as active inline comments on this PR (by pullfrog[bot]); this review found no additional defects in the changed code. Each is a prose/factual correction in docs/compatibility.md (plus one in CHANGELOG.md).

WARNING

File	Line	Issue
docs/compatibility.md	28	ec1157a's author and committer dates are both 2026-08-10T04:42:08Z — the VERSION-history row is a day early, and the same date appears in the new CHANGELOG.md entry. Bump both to 2026-08-10.
docs/compatibility.md	141	87e3622a never shipped: compare/87e3622a...main in feedBack-plugin-splitscreen returns diverged, so the bridge implementation that SHA carries was never reachable from the default branch. 2301dd5 is the commit that actually introduces beginOfflineRender/endOfflineRender on main, and 1.14.8 is the right version to cite.
docs/compatibility.md	145	The live coordinated-frame path does not warn — _startDeterministicFrames() early-returns at screen.js:3842. The only coordinated-frames warn-once is at screen.js:740, inside beginOfflineRender(), so it fires only when an offline exporter asks for a frame.
docs/compatibility.md	156	Difficulty Ladder does not gate its per-player difficulty write on playerContexts; the write path is gated on fb.capabilities.dispatch (screen.js:1450-1462). playerContexts only gates main-context resolution.
docs/compatibility.md	228	Checks 1 and 2 fail from the repository root on a fully capable build, because lib/ is not on sys.path outside pytest. Prefix both with PYTHONPATH=lib.

Files Reviewed (3 files)

• docs/compatibility.md — new 290-line compatibility matrix; 5 findings (all WARNING, prose/factual)
• CHANGELOG.md — one [Unreleased] entry; the ec1157a date also appears here (covered by the line-28 finding)
• README.md — docs-index entry linking the new matrix; no issues

Verification notes

Independently re-checked against HEAD (3fe9de8) before publishing: the diff is docs-only (3 files, +295/-2). All host file:line references cited in the document resolve at d1980ff — lib/dlc_paths.py:43, lib/sloppak.py:587 (read_member_bytes) and :562 (load_manifest), static/capabilities.js:131 (chart-transform domain), static/capabilities/chart-transform.js (exists, exposes chartTransformDomain.version === 1), lib/routers/ws_sync.py:196 (@router.websocket("/ws/sync/{session_id}")), server.py:1664 (app.include_router(ws_sync.router)), static/highway.js:3037/3057/3071 (setExternalFrameDriver/renderFrame/renderFrameAt), static/capabilities/player-identity.js:112/117 (fb.playerContexts), static/highway.js:74-102 and :2770-2783 (top_difficulty), lib/song.py:715 (collapse_arrangement_phrases). Commit-count claims verified locally: 803bd0c..ec1157a^ = 278, ec1157a..d1980ff = 83, 803bd0c..b6169af6 = 14; b6169af6 contains neither dlc_paths.py nor read_member_bytes (so it genuinely holds none of the seven APIs); e5339c0 is a descendant of all seven row commits. pyproject.toml:5 sets pythonpath = [".", "lib"] (pytest-only) and Dockerfile:278 sets PYTHONPATH=/app/lib:/app, confirming the line-228 false-negative claim. The minHost passthrough quote (plugins/__init__.py:1427-1428) and the absence of any static/ read of min_host match the document; docs/plugin-manifest.schema.json has no feature-scoped field. No gh api calls to the upstream/fork compare endpoints were permitted in this sandbox, so the upstream-vs-fork column and the 87e3622a/2301dd5 splitscreen status assertions rest on the existing comments' evidence rather than fresh verification.

Fix these issues in Kilo Cloud

---

_{Reviewed by free · Input: 0 · Output: 0 · Cached: 0}

[pullfrog]

ℹ️ No critical issues — all five factual corrections landed exactly as flagged, and each one checks out against primary sources. One stale echo of the corrected claim survives in the summary table (inline).

Reviewed changes

• Corrected the ec1157a VERSION row to 2026-08-10 and matched the CHANGELOG.md entry, removing the local-vs-UTC slip the document exists to correct in #102's list.
• Dropped the unmerged 87e3622a from the Splitscreen 1.14.8 bridge citation, kept 2301dd5 as the single floor, and added an explicit "do not use it as a floor" note about the side-branch SHA Visual Export's own error text still cites.
• Rewrote row 5's Splitscreen bullet — the coordinated-frame path degrades silently, _canDriveFrames and renderFrameAt are two separate predicates, and the coordinated-frames warn-once fires only from beginOfflineRender().
• Rewrote row 6's Difficulty Ladder clause to name the real gate (fb.capabilities.dispatch, literal true only) and both fallback steps, instead of playerContexts.
• Prefixed the two Python row checks with PYTHONPATH=lib and documented the repo-root / outside-pytest caveat that made them report a capable build as absent.

Each fix was re-verified from primary sources rather than taken from the reply: ec1157a's author and committer dates are both 2026-08-10T04:42:08Z; compare/87e3622a...main on Splitscreen returns diverged (24 ahead / 5 behind) while compare/2301dd5...main returns ahead, behind_by=0; _canDriveFrames at Splitscreen 1600e8c (screen.js:3814) requires setExternalFrameDriver and renderFrame, with renderFrameAt checked separately at :739 / :753 and :3842 returning without logging anything; Difficulty Ladder's _applyDifficultyForContext at 9ac046a gates on fb.capabilities.dispatch (:1450), accepts only a literal true (:1458), then falls through to the context-owned highway (:1464) and window.setMastery (:1469); and both prefixed Python checks now succeed from the repo root while the unprefixed form still raises ModuleNotFoundError, which is exactly what the new note says. CHANGELOG.md keeps CRLF on all 849 lines.

｜ Fix 👍s ➔ ｜ View workflow run ｜ Using big-pickle (free) ｜ 𝕏

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using big-pickle (free) ｜ 𝕏}

[pullfrog]

✅ No new issues found — the last open finding is closed and the table is now internally consistent.

Reviewed changes

• Dropped warns and from row 5's Required? cell (docs/compatibility.md:57), so the summary verdict now reads "optional for Splitscreen (feature-detected, degrades silently)" and agrees with the row-5 evidence 90 lines below, which documents that _startDeterministicFrames() early-returns with nothing logged and that the coordinated-frames warn-once fires only from beginOfflineRender().

That was the whole delta — one cell in one table row. I read it against the full document rather than only the range-diff, to confirm the correction didn't leave the opposite claim echoing somewhere else: the summary cell, the row-5 detail (:147-153), and correction #2 in Corrections to #102's list (:265-268, "degrades to its per-panel self-scheduled loop", no warning claim) now all agree, and the fix preserves the wording the evidence section depends on — silent degrade for the live path, warn-once scoped to the offline-exporter entry point.

The doc is internally consistent across its other load-bearing claims: row verdicts match their evidence sections, the VERSION history table matches the 83/278 commit ranges quoted around it, the PYTHONPATH=lib caveat sits with both Python checks it explains, and the audit-metadata "Not done" row still matches the source-audit-only framing in the callout at the top. README.md and CHANGELOG.md are unchanged this round and both still carry their entries.

All six threads from the two prior pullfrog reviews are now resolved. Nothing here warrants changes before merge.

  ^{｜ View workflow run ｜ Using big-pickle (free) ｜ 𝕏}