obsidian-dev-skills 1.2.2 → 1.2.4

package/obsidian-ops/references/scorecard-compliance.md

@@ -104,6 +104,8 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
       - uses: pnpm/action-setup@v4
       - uses: actions/setup-node@v4
         with:
@@ -123,14 +125,66 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           VERSION: ${{ steps.version.outputs.version }}
         run: |
+          COMMIT_NOTES=$(git log -1 --pretty=format:%B)
+          PREV_TAG=$(git tag --sort=-creatordate --merged HEAD | grep -v "^${VERSION}$" | head -n 1 || true)
+          if [ -n "$PREV_TAG" ]; then
+            COMPARE="**Full Changelog**: https://github.com/${GITHUB_REPOSITORY}/compare/${PREV_TAG}...${VERSION}"
+          else
+            COMPARE="**Full Changelog**: https://github.com/${GITHUB_REPOSITORY}/commits/${VERSION}"
+          fi
+          NOTES=$(printf "%s\n\n---\n\n%s\n" "$COMMIT_NOTES" "$COMPARE")
           gh release create "$VERSION" \
             --title="$VERSION" \
-            --generate-notes \
+            --notes "$NOTES" \
             main.js styles.css manifest.json
 ```
 
 Then cut releases by pushing a tag (e.g. `git tag 0.1.0 && git push origin 0.1.0`) instead of uploading files manually. The workflow attaches the assets and registers the attestation, which the scorecard checks against the source repo for byte-for-byte reproducibility.
 
+### Build verification failed (non-reproducible build)
+
+> Build verification failed: the `main.js` built from source does not match the release artifact.
+
+This appears even when attestation passes — attestation proves CI built the
+asset; build verification proves the asset can be **reproduced** byte-for-byte
+from the tagged source. The single most common cause is an **inline sourcemap**
+in the production build.
+
+`sourcemap: "inline"` in `esbuild.config.mjs` base64-embeds the build machine's
+**absolute file paths** into `main.js`. GitHub Actions builds at
+`/home/runner/work/<repo>/...`; the scorecard's reproducer builds at a
+different path. Same source, byte-different `main.js` → verification fails. (It
+also bloats the shipped file and leaks build paths.)
+
+**Fix**: gate the sourcemap on build mode so production ships without one.
+Compute the flag before `esbuild.context(...)` and reference it on the
+`sourcemap` field:
+
+```js
+// Production builds must be reproducible. An inline sourcemap embeds the
+// build machine's absolute file paths into main.js, so CI and the scorecard
+// reproducer produce byte-different output. Ship production with no
+// sourcemap; keep the inline sourcemap only for the dev/watch build.
+const isProduction =
+	process.argv.slice(2).includes("build") ||
+	process.argv.slice(2).includes("production");
+
+const context = await esbuild.context({
+	// ...
+	sourcemap: isProduction ? false : "inline",
+	// ...
+});
+```
+
+(`pnpm build` runs `node esbuild.config.mjs production`; `pnpm dev` runs it
+with no args, so dev/watch keeps the inline sourcemap for local debugging.)
+
+Other reproducibility killers to rule out if the sourcemap is already gated:
+commit `pnpm-lock.yaml` and use `pnpm install --frozen-lockfile` in CI (so the
+dependency tree is identical), pin the CI Node version, and never hand-edit
+`main.js` after building or upload a locally built asset — let the workflow
+build and attach it.
+
 ### Duplicate CSS selectors
 
 > Unexpected duplicate selector ".foo .bar", first used at line N.

package/obsidian-ops/references/versioning-releases.md

@@ -43,6 +43,8 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
       - uses: pnpm/action-setup@v4
       - uses: actions/setup-node@v4
         with:
@@ -65,15 +67,25 @@ jobs:
           if gh release view "$VERSION" >/dev/null 2>&1; then
             gh release upload "$VERSION" main.js styles.css manifest.json --clobber
           else
+            COMMIT_NOTES=$(git log -1 --pretty=format:%B)
+            PREV_TAG=$(git tag --sort=-creatordate --merged HEAD | grep -v "^${VERSION}$" | head -n 1 || true)
+            if [ -n "$PREV_TAG" ]; then
+              COMPARE="**Full Changelog**: https://github.com/${GITHUB_REPOSITORY}/compare/${PREV_TAG}...${VERSION}"
+            else
+              COMPARE="**Full Changelog**: https://github.com/${GITHUB_REPOSITORY}/commits/${VERSION}"
+            fi
+            NOTES=$(printf "%s\n\n---\n\n%s\n" "$COMMIT_NOTES" "$COMPARE")
             gh release create "$VERSION" \
               --title="$VERSION" \
-              --generate-notes \
+              --notes "$NOTES" \
               main.js styles.css manifest.json
           fi
 ```
 
 **Why read the version from `manifest.json`**: the workflow runs from either a tag push (where `github.ref_name` is the tag) or a `workflow_dispatch` from a branch (where `github.ref_name` is the branch name, e.g. `master`). Using `github.ref_name` directly would title a manually-triggered release after the branch. Reading from `manifest.json` is consistent across both triggers and matches what Obsidian's plugin loader actually reads.
 
+**Why build the release notes manually instead of `--generate-notes`**: `--generate-notes` produces an auto-changelog headed by a "What's Changed" PR list and a "Full Changelog" compare link. For plugins maintained by a single person without a PR workflow, that auto-generated body is usually just the compare link with no context. Reading the latest commit message gives the reader the actual "what changed and why" up front. The compare link is still appended underneath for the full diff. `fetch-depth: 0` is required so `git tag --merged HEAD` has the tag history to find the previous version.
+
 Cut releases by pushing a tag (`git tag 0.1.0 && git push origin 0.1.0`). The workflow attaches the three required assets and registers the attestation. The scorecard's "Build verified" signal also fires once the workflow has run, because the attested artifacts can be reproduced byte-for-byte from source.
 
 For the full set of scorecard signals and their fixes, see [scorecard-compliance.md](scorecard-compliance.md).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "obsidian-dev-skills",
-  "version": "1.2.2",
+  "version": "1.2.4",
   "description": "Agent skills for Obsidian plugin and theme development, including community scorecard compliance, release workflow attestation, and dependency vulnerability hygiene.",
   "keywords": [
     "obsidian",