Point the README at the canonical repo; add compliance checks

[carochacs]

Found during a cross-repository audit of the eight feedBack repos.

Note: an earlier revision of this PR retargeted the install snippet at get-flashbacks. That was wrong and has been reverted — see below.

README

got-feedBack/feedBack-plugin-sectionmap is the canonical repo; this checkout is a fork of it. The install snippet now clones the canonical repo, and the app link points at got-feedBack/feedBack.

The remote in the original snippet was not actually broken. got-feedback/feedback-plugin-sectionmap already resolved to the canonical repo, because GitHub treats org-name casing as case-insensitive. What was genuinely stale was the pre-rename "Slopsmith" branding — the title, the app link text, and the /path/to/slopsmith/plugins example. The clone URL now spells the casing explicitly rather than relying on that normalisation.

Worth stating plainly since I got it wrong first time round: pointing a plugin's install instructions at a fork makes the plugin fork-specific and stops it being useful to the repo it came from. Installer-facing links belong on got-feedBack.

The clone target directory stays section_map, matching plugin.json's id. That pairing is what marks a plugin as a bundled core one for duplicate resolution — it is not a discovery requirement, since the loader registers plugins by manifest id whatever the folder is called. (That correction is feedBack#61; the "silent skip at discovery" phrasing is repeated across several repos' docs and is false.)

No version bump — nothing outside the README changed, and version-bumped-on-change only triggers on functional source.

Compliance checks

This repo's ci.yml calls the shared reusable-ci.yml, which runs the test suites and nothing else, while the org's original-repo plugins run their own custom-checks.yml. Enforcement was split down the middle — forks got tests but no spec checks, originals got spec checks but not always tests — and the audit found defects on both sides of that line.

compliance.yml adds three targeted jobs rather than the full sixteen: version-bumped-on-change, changelog-updated, idempotent-top-level-guard. Jobs self-skip where they don't apply (no CHANGELOG.md here).

Hardened after review:

• Diff against the merge base, not the base tip. On pull_request, base.sha is main's live tip, so a two-dot diff counts commits main acquired after the fork — demonstrated in this repo, where merge-base 738997b excludes main's base-only LICENSE commit.
• changelog-updated compares the [Unreleased] section itself rather than checking the file was touched; editing an already-released section used to pass.
• .css counts as functional source — the Host cache-busts plugin assets by version.
• The guard job documents its limitation: it proves a guard exists, not that every hotpath sits inside one.

The guard check found a bug in itself

Dry-running idempotent-top-level-guard against the sibling repos before adopting it caught a false positive: it only matched window.__flag dot access, so it failed this repo, whose guard is

const HOOK_KEY = '__slopsmithSectionMapHooksInstalled';
if (window[HOOK_KEY]) return;

section_map is the org's reference implementation of that guard, and the check would have flagged it as unguarded. The widened version recognises dotted, bracket-literal and bracket-const forms. No change to this repo's screen.js — the guard here was correct all along.

The right long-term home for these three jobs is got-feedBack/.github's reusable-ci.yml, so every repo picks them up from one reference instead of four copies. The file says so, and says to delete it when that lands.

Suite 16/16.

[deepsource-io]

DeepSource Code Review

We reviewed changes in a65c7d3...8c7f791 on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.

See full review on DeepSource ↗

PR Report Card

Overall Grade

Security   Reliability   Complexity   Hygiene

Code Review Summary

Analyzer	Status	Updated (UTC)	Details
Shell		Aug 13, 2026 3:09a.m.	Review ↗

---

Important

AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.

[pullfrog]

Important

The clone-URL fix and the two spec checks are solid (verified: the guard check dry-runs clean against screen.js, and all three jobs self-skip/pass on this PR), but the README's app link now points at a personal fork rather than the canonical app repo, and the git-diff jobs can false-fail PRs on base drift. Details inline.

Reviewed changes

• README.md — Retargeted the install snippet from got-feedback/feedback-plugin-sectionmap.git to this repo's canonical clone URL (get-flashbacks/feedBack-plugin-sectionmap.git; the section_map target dir is correctly kept, matching the plugin.json id), and refreshed the pre-rename "Slopsmith" naming in the title, the app link, and the install path.
• .github/workflows/compliance.yml (new) — Three plugin-spec compliance jobs: version-bumped-on-change (a .py/.js/.html change outside tests/ must come with a plugin.json version change), idempotent-top-level-guard (a window.__* reload guard is required when listeners/timers are present), and changelog-updated (self-skips — this repo has no CHANGELOG.md).

Verified while reviewing: the guard regex passes screen.js via the bracket-const form (window[HOOK_KEY] plus the '__slopsmithSectionMapHooksInstalled' literal); this PR itself only touches README.md and the workflow, so all three jobs skip/pass here; and the node suite is still 16/16.

ℹ️ The guard check proves a guard exists, not that every hotpath is inside it

idempotent-top-level-guard only requires some window.__* flag anywhere in the file. A future change that adds a bare top-level setInterval/addEventListener outside an already-present guard — exactly the reload-duplication bug this job exists to catch — leaves has_guard true and passes. The bracket_const heuristic can also credit a guard when window[someVar] and an unrelated '__…' literal happen to coexist. Both are inherent to a regex check and reasonable for a targeted subset, but worth recording as an accepted limitation so a later contributor doesn't read the green check as proof of idempotency.

ℹ️ Nitpicks

• changelog-updated's step is named "CHANGELOG.md Unreleased section must be updated" but the script only requires CHANGELOG.md to appear in the diff — any edit anywhere (e.g. inside an already-released section) passes. Enforce the Unreleased heading, or rename the step to match what it verifies.
• version-bumped-on-change treats only .py/.js/.html as functional source. Spec best-practices rule 39 requires a version bump for stylesheet changes too (the Host cache-busts plugin assets by version), so a .css-only change slips through. No current impact here — this plugin styles inline — but it will matter if the repo ever ships assets/plugin.css.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Big Pickle (free) ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — incremental delta since the prior Pullfrog review (a39d53b):

• Retargeted the README's app line from the personal fork to the canonical got-feedBack/feedBack.
• Switched version-bumped-on-change and changelog-updated to diff against the merge-base instead of the live base tip, so base-only commits no longer false-fail stale PRs (verified here: merge-base 738997b excludes main's base-only LICENSE commit).
• Added .css to the functional-source extension list in both jobs (spec best-practices rule 39).
• Reworked changelog-updated to compare the [Unreleased] section between base and head rather than requiring any CHANGELOG.md edit.
• Documented the guard check's presence-only limitation as a comment in idempotent-top-level-guard.

All four prior findings (app-link fork regression, base-drift false failures, .css gap, step-name-vs-behavior mismatch) are addressed. I dry-ran the new unreleased() comparison — it correctly passes on a genuine [Unreleased] content change and fails on an edit confined to an already-released section — and confirmed the merge-base diff of this branch against main shows only the two PR files.

  ^{｜ View workflow run ｜ Using Big Pickle (free) ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — incremental delta since the prior Pullfrog review (e52997b):

• Retargeted the README's install snippet from this fork's get-flashbacks/feedBack-plugin-sectionmap.git back to the canonical got-feedBack/feedBack-plugin-sectionmap.git, keeping the section_map target directory.

Verified: the canonical repo exists and the URL casing is exact, so the clone target is valid; the app link, install path, and clone URL now all consistently point at the canonical got-feedBack org; and section_map still matches plugin.json's id (the "silently skipped at discovery" constraint). compliance.yml is unchanged since the prior approving review.

ℹ️ PR description is stale on the install target

The PR description says the snippet "Now get-flashbacks/feedBack-plugin-sectionmap" and argues the original URL was "not where this repo lives". Both are out of step with the branch: the head commit installs from the canonical got-feedBack/feedBack-plugin-sectionmap, and the original got-feedback/feedback-plugin-sectionmap already resolved to that same canonical repo (GitHub treats org-name casing as case-insensitive) — so the genuinely broken part of the old snippet was the pre-rename "Slopsmith" branding, not the remote. A one-line touch-up when merging would let the merged record describe what actually shipped.

  ^{｜ View workflow run ｜ Using Big Pickle (free) ｜ 𝕏}