Skip to content

feat: per-site MCP serverInfo instructions (BLOCK-19) #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
zackkatz merged 5 commits into from
May 20, 2026
Merged

feat: per-site MCP serverInfo instructions (BLOCK-19) #16

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
811dee0
feat(plugin+mcp): per-site MCP serverInfo instructions addendum (BLOC…
zackkatz May 20, 2026
cd15b86
fix(plugin+mcp): address BLOCK-19 review (public API, redirects, UTF-…
zackkatz May 20, 2026
623c35b
fix(plugin+mcp): code-point safety for client counter and TS truncati…
zackkatz May 20, 2026
5203c91
fix(enricher): respect explicit plaintext + build innerHTML for fresh…
zackkatz May 20, 2026
9ff3169
docs(agents): document the tagging convention
zackkatz May 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -562,6 +562,17 @@ The MCP server version is informational; the plugin version is what site owners
- If the MCP server side also moved, bump `package.json` in the same commit
3. Push.

### Tagging the release

Every plugin version bump gets a matching annotated git tag. Tags live on the merge commit on `main`; never on a feature branch tip.

- **Format**: `v{plugin-version}` — e.g. `v1.7.0`. Match the plugin version, not the MCP server version. (When the MCP server bumps independently without a plugin bump, no tag — server versions are informational.)
- **Annotated, not lightweight**: `git tag -a v1.7.0 -m "<release notes>"`. Lightweight tags don't carry a message and don't show up in `git show`.
- **Tag message**: the same prose as the `readme.txt` `Upgrade Notice` for that version, plus a `Highlights:` bulleted list of the headline changes. Look at `git show v1.6.0` for the canonical shape.
- **Push the tag explicitly**: `git push origin v1.7.0`. Bare `git push` does not push tags. Without this step the tag exists locally only and `gh release create` can't find it.
- **When to tag**: after the version-bump commit has landed on `main` (via PR merge or direct push). Tagging on the feature branch and merging via squash strands the tag on a dead commit.
- **GitHub release**: optional, but if you create one, attach it to the tag (`gh release create v1.7.0 --notes-file …` or via the UI). The marketplace pin / Composer installer reads the tag, not the release.

### Backfilling missing entries

If a version was bumped without a corresponding `readme.txt` entry (it happens — historically `1.4.1`, `1.4.2`, and `1.5.0` all shipped without changelog updates), audit the commits that landed between the previous bump and the version bump commit (`git log <prev-bump>..<this-bump> -- wordpress-plugin/gk-block-api/`) and write the missing entries. Keep the Upgrade Notice and Changelog sections in strict reverse-chronological order across all versions.
Expand Down
Loading
Loading