Artifact attestation and AGENT.md

.github/workflows/release.yml

@@ -9,6 +9,8 @@ on:
 
 permissions:
   contents: write
+  id-token: write
+  attestations: write
   pull-requests: read
 
 jobs:
@@ -177,25 +179,37 @@ jobs:
 
       - name: Commit version and changelog updates
         if: steps.bump.outputs.bump_type != 'none'
+        id: release_commit
         run: |
           git config user.name "github-actions[bot]"
           git config user.email "github-actions[bot]@users.noreply.github.com"
           git add package.json manifest.json versions.json CHANGELOG.md
           git commit -m "chore: release ${{ steps.version.outputs.new_version }} [skip ci]"
           git push
+          echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
 
       - name: Build release artifacts
         if: steps.bump.outputs.bump_type != 'none'
         run: npm run build
 
+      - name: Generate artifact attestation
+        if: steps.bump.outputs.bump_type != 'none'
+        uses: actions/attest@v4
+        with:
+          subject-path: |
+            main.js
+            manifest.json
+
       - name: Create GitHub Release
         if: steps.bump.outputs.bump_type != 'none'
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           NEW: ${{ steps.version.outputs.new_version }}
           DESCRIPTION: ${{ steps.changelog_entry.outputs.description }}
+          RELEASE_SHA: ${{ steps.release_commit.outputs.sha }}
         run: |
           gh release create "${NEW}" \
+            --target "${RELEASE_SHA}" \
             --title "${NEW}" \
             --notes "${DESCRIPTION}" \
             main.js manifest.json

.github/copilot-instructions.md → AGENT.md

@@ -1,9 +1,9 @@
-# Copilot Instructions — Text Tools (Obsidian Plugin)
+# Agent Instructions - Text Tools (Obsidian Plugin)
 
 ## Build, Test, Lint
 
 ```bash
-npm run build          # Type-check (tsc -noEmit) + esbuild production bundle → main.js
+npm run build          # Type-check (tsc -noEmit) + esbuild production bundle -> main.js
 npm run dev            # esbuild watch mode (auto-rebuilds on save)
 npm run test           # vitest run (all tests)
 npm run test -- src/transforms/lines.test.ts                 # single test file
@@ -34,8 +34,8 @@ Commands that need user input use `InputModal` or `TwoInputModal` (in `src/modal
 
 ### Key helpers in `src/utils.ts`
 
-- `transformSelections(editor, fn)` — Apply a `string → string` transform to every non-empty selection. Returns `false` if nothing is selected.
-- `normalizeRange(anchor, head)` — Normalize selection direction to `{from, to}`.
+- `transformSelections(editor, fn)` - Apply a `string -> string` transform to every non-empty selection. Returns `false` if nothing is selected.
+- `normalizeRange(anchor, head)` - Normalize selection direction to `{from, to}`.
 
 ### Settings
 
@@ -45,18 +45,18 @@ Commands that need user input use `InputModal` or `TwoInputModal` (in `src/modal
 
 - **Adding a new transform**: Write the pure function in the appropriate `src/transforms/*.ts` file, then register the command in the corresponding `register*Commands()` method in `main.ts`. If it needs no user input, add it to the `cmds` or `simple` tuple array. If it needs input, use `InputModal` or `TwoInputModal`.
 - **Tests are co-located**: Test files live next to their source (e.g., `src/transforms/lines.test.ts`). Vitest discovers `src/**/*.test.ts`.
-- **Line operations must normalize CRLF**: Functions in `lines.ts` use `normalizeLineEndings()` / `getLines()` to handle `\r\n` → `\n` before processing. Use these helpers instead of raw `text.split("\n")`.
-- **Sorting must preserve trailing newlines**: Use `withPreservedTrailingNewline()` wrapper for sort operations — editors often include a trailing newline when selecting full lines.
+- **Line operations must normalize CRLF**: Functions in `lines.ts` use `normalizeLineEndings()` / `getLines()` to handle `\r\n` -> `\n` before processing. Use these helpers instead of raw `text.split("\n")`.
+- **Sorting must preserve trailing newlines**: Use `withPreservedTrailingNewline()` wrapper for sort operations. Editors often include a trailing newline when selecting full lines.
 - **The `perLine()` helper** in `case.ts` applies a function to each line independently. Use it for per-line transforms that don't need cross-line context.
 - **Multi-selection aware**: All commands must work with multiple simultaneous selections. Use `transformSelections()` or iterate `editor.listSelections()` in reverse.
-- **Obsidian API is external**: `obsidian`, `electron`, and `@codemirror/*` are externalized by esbuild — never bundle them.
+- **Obsidian API is external**: `obsidian`, `electron`, and `@codemirror/*` are externalized by esbuild. Never bundle them.
 - **Pull request descriptions must use the required changelog markup**: PR descriptions must contain the expected sections for the Release pipeline used to update changelog and release notes. See the following "Pull request description content" section.
 
 ### Pull request description content
 
-PR descriptions must contain the expected sections for the Release pipeline used to update the changelog and release notes. Follow the [PULL_REQUEST_TEMPLATE.md](./PULL_REQUEST_TEMPLATE.md) template and fill in the description and type of change (major, minor, patch). Note that the markup comment tags (`<!--changelog-description-start-->`, `<!--changelog-description-end-->`, `<!--changelog-type-start-->`, and `<!--changelog-type-end-->`) are required for the pipeline to identify the sections. The description should be concise but informative, as it will be used in the changelog and release notes.
+PR descriptions must contain the expected sections for the Release pipeline used to update the changelog and release notes. Follow the [PULL_REQUEST_TEMPLATE.md](.github/PULL_REQUEST_TEMPLATE.md) template and fill in the description and type of change (major, minor, patch). Note that the markup comment tags (`<!--changelog-description-start-->`, `<!--changelog-description-end-->`, `<!--changelog-type-start-->`, and `<!--changelog-type-end-->`) are required for the pipeline to identify the sections. The description should be concise but informative, as it will be used in the changelog and release notes.
 
- The type of change must be accurately indicated to ensure proper versioning. **Exactly one** of the Major/Minor/Patch checkboxes must be checked — the release workflow picks the first matching checked box (Major → Minor → Patch) and will fail to create a release if none are checked.
+The type of change must be accurately indicated to ensure proper versioning. **Exactly one** of the Major/Minor/Patch checkboxes must be checked. The release workflow picks the first matching checked box (Major -> Minor -> Patch) and will fail to create a release if none are checked.
 
 Sample:
 
@@ -71,9 +71,9 @@ Fix code quality issues: sentence case, promise handling, deprecated functions,
 
 <!--changelog-type-start-->
 
-- [ ] **Major** – Breaking change (requires a new major version bump)
-- [ ] **Minor** – New feature, backward-compatible (requires a new minor version bump)
-- [x] **Patch** – Bug fix or internal improvement, backward-compatible (requires a new patch version bump)
+- [ ] **Major** - Breaking change (requires a new major version bump)
+- [ ] **Minor** - New feature, backward-compatible (requires a new minor version bump)
+- [x] **Patch** - Bug fix or internal improvement, backward-compatible (requires a new patch version bump)
 
 <!--changelog-type-end-->
 ```