Add section-marker-rev to vault

[Golevka2001]

Adds a vault entry for section-marker-rev, the Spicetify v3 port of Aimarekin's section-marker,
revised by Golevka2001.

• Artifact: https://github.com/Golevka2001/section-marker-rev/releases/tag/section-marker-rev@2.0.0
• Tested on: Spicetify 3.0.0-rc.3

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: b62e6b02-b8a4-4316-b69f-9d1e44ecd222

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pullfrog]

Verdict: concerns

Provenance

• section-marker-rev@2.0.0 — unverified: Golevka2001/section-marker-rev has no attestation for this artifact. This review therefore covers the built output only — the zip downloaded from the release URL in vault/section-marker-rev.json (its sha256 matches the vault checksum 742fd9b8…126c4d). I did not clone a source repository or build anything.

Reviewed changes

• vault/section-marker-rev.json — new vault entry (kind extension, one artifact, no providers, checksum, metadata).

What the built module does

The zip contains index.js, index.css, mod.js, their source maps (which embed the original TypeScript), metadata.json, and spicetify-module.json. The module renders a song's audio-analysis sections as markers on the playbar. Reviewed behavior:

• No network primitives found — no fetch, XMLHttpRequest, WebSocket, EventSource, or sendBeacon, and no remote script/image URLs. The only data call is Spicetify.getAudioData(uri), which is a client API documented as a stdlibBoundary exception in the bundled metadata.json. No arbitrary host is contacted by the module.
• No remote or dynamic code — no eval, new Function, string setTimeout, remote import(), or injected <script>. DOM is built with createElement + classList + textContent; no innerHTML/insertAdjacentHTML.
• No credentials or session access — no Platform.AuthorizationAPI, getState().token, accessToken, cookies, or token exfiltration.
• No Spicetify internals abuse — no __SPICETIFY_DAEMON_TOKEN__, no 127.0.0.1:7967, no CORSProxy, no spicetify.modules.local.* writes (no localStorage use at all).
• No concealment — the embedded TypeScript in mod.js.map/index.js.map faithfully matches the compiled JS; no non-ASCII/zero-width padding and no reviewer-addressing text.

Finding

• ℹ️ Unbounded readiness wait could hang the loader. mod.js:393 (source app.ts:12 in the bundled source map) loops while (!client.player.data || !client.uri || !client.locale || !client.cosmos || !client.react) await new Promise(r => setTimeout(r, 100)), and the default export (mod.js:412–414) awaits main(). There is no attempt cap or timeout, so if any of those five stdlib client properties never becomes available (e.g. after a stdlib/client change), the module's load promise never settles and can stall the module loader. These are core stdlib properties, so real-world risk is low, but bounding the retry would remove the hang.

Not reviewed

• The source repository and its build pipeline (Golevka2001/section-marker-rev) — no verified commit to check out.
• Any package.json/lockfile/supply chain — no such files are bundled in the zip.
• Prior versions — the vault record contains only 2.0.0; nothing to diff against.
• Remote preview assets (README.assets/default.png, showcase.gif) — referenced only in metadata.json, not fetched or inspected.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}