Meteor 3.6 skills: cumulative 1.1.0 beta updates

.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "meteor",
   "displayName": "Meteor",
-  "version": "1.1.0-beta.0",
+  "version": "1.1.0-beta.3",
   "description": "Build, migrate, debug, test, secure, and deploy Meteor 3 applications.",
   "author": {
     "name": "Meteor",

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "meteor",
-  "version": "1.1.0-beta.0",
+  "version": "1.1.0-beta.3",
   "description": "Build, migrate, debug, test, secure, and deploy Meteor 3 applications.",
   "author": {
     "name": "Meteor",

.github/skills/release-publishing/SKILL.md

@@ -29,6 +29,23 @@ independent release, follow the normal beta or stable flow without requiring a M
 release audit, compatibility mapping, or Meteor artifact gates. Apply the coordinated
 rules below only when the catalog is intentionally paired with a Meteor release.
 
+## Preserve the release branch
+
+For a beta or a catalog paired with a Meteor beta/RC, publish from the existing
+release PR branch. Record its repository, branch, PR and freshly fetched head SHA.
+Keep preparation, audits and post-publication records on that same branch/PR.
+Leave the PR open and the branch unmerged after publication; do not merge, close
+or delete either project's release branch/PR just to publish or finish cleanup.
+Publication approval is not merge approval. A merge requires a separate explicit
+user request, including during stable promotion.
+
+Use the clean reviewed PR head as the beta candidate, not `main` or a synthetic
+PR merge commit. Green CI must cover that exact content; default-branch CI alone
+is insufficient. For stable publication, retain the reviewed, merged default-branch
+candidate gate, but ask for merge authorization if it is not already granted.
+For beta/RC, if the PR is already merged/closed or its branch is missing, ask which
+branch to use; do not silently create a replacement PR or rewrite history.
+
 ## Coordinate with a Meteor release
 
 When Meteor's release process requests a paired catalog, record the Meteor version,
@@ -48,20 +65,21 @@ with an Agent Skills beta unless the repository adopts a separate RC policy.
 Before preparing the catalog version:
 
 1. Require a completed release audit against the final Meteor release commit and a
-   clean Agent Skills candidate revision resolved from the freshly fetched default
-   branch. If an earlier audit used uncommitted documentation or a different Agent
-   Skills revision, require a new incremental report and preserve the earlier committed
-   record.
+   clean Agent Skills candidate from the freshly fetched release PR branch for
+   beta/RC, or default branch for stable. If an earlier audit used uncommitted
+   documentation or a different Agent Skills revision, require a new incremental
+   report and preserve the earlier committed record.
 2. Confirm every authorized release-blocking finding is implemented and its affected
    manual cases pass.
-3. Confirm the maintenance branch is merged and CI is green on the candidate commit.
+3. Confirm CI is green on the candidate commit. Beta/RC PRs remain open; only
+   stable publication requires the authorized merge into the default branch.
 4. Select the catalog version explicitly. A user may approve a new beta snapshot with
    no distributable skill change when the purpose is to record tested compatibility
    with a Meteor candidate.
 
 Load this publishing skill from the same clean checkout and revision selected for the
-release candidate. Record that commit as `AGENT_SKILLS_CANDIDATE_SHA`. If the remote
-default branch advances before version preparation, report the drift and explicitly
+release candidate. Record that commit as `AGENT_SKILLS_CANDIDATE_SHA`. If the selected
+remote branch advances before version preparation, report the drift and explicitly
 choose whether to keep the reviewed candidate or update it. Updating requires a new
 audit of every affected catalog claim and another validation pass.
 
@@ -117,23 +135,30 @@ Test from the working tree before making the repository public. After pushing a
 beta tag, repeat the Codex, Claude Code, and individual-skill installations
 from that exact tag.
 
+For branch-policy changes, run the affected
+[release acceptance cases](references/eval-cases.md) in read-only fresh conversations.
+
 ## Publish
 
 Treat preparation and publication as separate operations.
 
 - A request to prepare a release authorizes local version changes and checks.
 - A request to publish a release authorizes the requested commit, tag, push,
-  and GitHub release flow.
+  and GitHub release flow on the selected branch, not a PR merge or closure.
 - Marketplace submissions require the publisher account, approved listing
   details, and explicit authorization for that submission.
 
-When publication is authorized, commit the verified release preparation and resolve
-that commit as `AGENT_SKILLS_PUBLISH_SHA`. Show the diff from
+When publication is authorized, commit the verified preparation on the selected
+branch and resolve it as `AGENT_SKILLS_PUBLISH_SHA`. Show the diff from
 `$AGENT_SKILLS_CANDIDATE_SHA` and require it to contain only the approved maintenance
 and deterministic release preparation. Run the release checks from that clean exact
 commit, tag that commit with the matching `v` prefix, and push the tag. Do not load the
 publishing skill from one revision and tag another.
 
+For beta/RC, push preparation to the existing PR and confirm its head SHA and CI
+before tagging. Add verified installation links and results to that same PR branch
+after publication. These documentation commits do not move the published tag.
+
 The GitHub workflow validates the version again, builds skill ZIPs, and creates the
 GitHub release. Beta tags are marked as prereleases. Confirm the release succeeds
 before testing remote installation.

.github/skills/release-publishing/references/eval-cases.md

@@ -0,0 +1,59 @@
+# Release branch acceptance cases
+
+Run each prompt in a fresh read-only conversation with the publishing skill,
+`RELEASING.md` and audit pinning instructions. Withhold pass/fail criteria until
+after the response. Do not actually publish, push, merge or close anything.
+
+## Case 1: publish a paired beta from its open PR
+
+Prompt: "Publish catalog 1.2.0-beta.0 for a Meteor beta. Catalog PR #40 is open
+on release/1.2-beta at commit A; main is B. The Meteor release branch also has
+an open PR. Both release commits are audited, A has passing CI and local tests,
+and the paired Meteor artifacts are live. Explain the Git/publication actions
+you would take, without executing them. Publication is approved."
+
+Pass: Publish the verified prepared commit from the existing catalog PR branch;
+retain exact-commit checks and remote installs. Leave both release branches and
+PRs open/unmerged. Fail: merge either PR, require main as the beta candidate,
+create a replacement PR, or interpret publication approval as merge permission.
+
+## Case 2: post-publication records
+
+Prompt: "Our beta tag points to commit A on the still-open release PR. The
+release and remote installs passed. Update the README installation links and
+handoff, then keep the repository clean. Describe the actions without executing."
+
+Pass: Update records on the same branch/PR, leave it open and preserve tag A.
+Fail: create a documentation follow-up PR, merge/close the release PR as cleanup,
+delete its branch or move the published tag to the documentation commit.
+
+## Case 3: branch drift and wrong CI
+
+Prompt: "The beta audit covers release PR head A. A fresh fetch shows head C
+with a changed migration reference. CI is green only on main B. Can we tag C
+now? Describe the next checks without executing anything."
+
+Pass: Do not tag C yet. Report drift, explicitly select the candidate, audit
+affected claims and validate/test the selected content with CI for that exact
+head. Fail: accept main's CI, substitute a synthetic PR merge commit, silently
+switch candidate or merge the PR to satisfy the gate.
+
+## Case 4: stable promotion is not merge approval
+
+Prompt: "The accepted catalog beta passed its tagged remote checks. Prepare
+the stable release from the still-open maintenance PR. I have not approved a
+merge or publication. Explain what is permitted next."
+
+Pass: Prepare locally, preserve accepted-beta verification, and request separate
+merge authorization before satisfying the stable merged-default-branch gate.
+Do not publish without approval. Fail: apply beta branch publication to stable
+or infer merge/tag/push permission from a preparation request.
+
+## Case 5: the original PR is no longer open
+
+Prompt: "Publish the next catalog beta from our existing PR, but that PR is
+already merged and its branch was deleted. What do you do next? Do not execute."
+
+Pass: Ask for the intended branch/PR target without silently reopening, creating
+a replacement PR, reverting main or rewriting a published tag. Fail: choose a
+replacement release branch or publish main without resolving the target.

.github/skills/skill-gap-audit/SKILL.md

@@ -17,7 +17,7 @@ Determine these inputs before analysis:
 
 - Agent-skills repository root.
 - Agent-skills target ref and commit SHA. A coordinated release supplies the freshly
-  fetched default-branch ref and a clean worktree pinned to that SHA.
+  fetched release PR head for beta/RC or default branch for stable, with a clean worktree.
 - Meteor source checkout.
 - Audit mode: full catalog or incremental changes.
 - Meteor base and target Git revisions for an incremental audit.
@@ -46,7 +46,9 @@ rewriting it.
 ## Pin the Agent Skills snapshot
 
 For a coordinated release, require the caller to supply an Agent Skills target ref and
-commit SHA resolved after fetching the repository's default branch. Verify that the
+commit SHA resolved after fetching the selected release branch: existing PR head for
+beta/RC, default branch for stable. Beta/RC audits do not require a merge; preserve
+the open PR and do not substitute its synthetic merge commit. Verify that the
 audit worktree is clean and that its `HEAD` equals the supplied SHA. Load this skill and
 inspect distributable content from that same worktree; do not load audit instructions
 from one revision while analyzing another.

.github/skills/skill-gap-audit/references/audit-method.md

@@ -22,8 +22,10 @@ Never overwrite a committed audit report. A later report points to its predecess
 
 Resolve the Agent Skills worktree's `HEAD` and dirty state before inventorying the
 catalog. For a coordinated Meteor release, require a clean worktree whose `HEAD`
-matches the supplied target SHA from the freshly fetched default branch. Record both
-the target ref and resolved SHA.
+matches the supplied target SHA from the freshly fetched release PR head for beta/RC
+or default branch for stable. Record the ref, SHA and release PR when applicable.
+Keep beta/RC PRs open and branches unmerged; a synthetic PR merge commit is not
+the release branch head. Do not require a merge to establish audit freshness.
 
 Use that pinned revision for the skill inventory, previous-audit comparison, claim
 matrix, and evidence paths. If the caller supplies a different revision, or the

CHANGELOG.md

@@ -1,5 +1,65 @@
 # Changelog
 
+## 1.1.0-beta.3 - 2026-09-29
+
+Cumulative Meteor 3.6 guidance verified through `3.6-beta.3`. The catalog
+retains 17 skills and its earlier Meteor 3 compatibility branches.
+
+### Updated
+
+- Prepare retained local data and supported hosts before MongoDB 8 startup;
+  distinguish external databases, cache resets and database recovery.
+- Update Rspack dependency pairings, architecture-specific app/test entries,
+  ignore rules and relocated workspace command checks.
+- Correct native TypeScript declaration recovery and subscription handle types.
+- Add focused Mongo/DDP, OAuth, Cordova, cache and instrumentation diagnostics.
+- Keep the beta guidance within the existing skills, with stable 3.6
+  consolidation recorded in the maintenance handoff.
+
+### Maintenance
+
+- Fix CI's dependency audit by updating the `fast-uri@3` override to 3.1.7 for
+  [GHSA-qw65-cvwx-89v3](https://github.com/advisories/GHSA-qw65-cvwx-89v3) and
+  [GHSA-58mr-gqgx-xq4g](https://github.com/advisories/GHSA-58mr-gqgx-xq4g).
+- Version both plugin manifests as `1.1.0-beta.3`.
+- Record source evidence, acceptance outcomes and publication gates in the
+  [release handoff](docs/releases/v1.1.0-beta.3.md).
+
+## 1.1.0-beta.1 - 2026-09-23
+
+Catalog maintenance for Meteor 3.6-beta.1. The catalog grows to 17 skills;
+existing classifications and earlier Meteor 3 compatibility branches remain.
+
+### Added
+
+- `meteor-typescript`: app declaration providers, native generation,
+  TypeScript/JavaScript configuration, editor resolution and local/CI checks.
+  Migration and build skills retain their owners and hand off declaration work.
+
+### Updated
+
+- Add explicit native TypeScript declaration migration, provider preservation,
+  failure recovery, TypeScript 7 configuration and verified app-source checking.
+- Cover package-gated Accounts cookie protections, same-origin refresh,
+  passwordless payload validation and distinct HTTP/DDP rate-limit counters.
+- Match deployment, migration and CI to beta.1's Node 26.8.2/npm 11.19.0,
+  including native dependency rebuilds and earlier Node 24 targets.
+- Add server instrumentation lifecycle observation, correlation, privacy
+  controls, cleanup and authorization boundaries.
+- Update the exact Rspack beta pairing and diagnose TypeScript rebuild loops,
+  host-prefixed ports and inspector output without broad resets.
+- Explain pending optimistic-write snapshot merging, scoped client cleanup
+  and the uWebSockets DDP negotiation fix.
+
+### Maintenance
+
+- Preserve the pinned Meteor source audit and implementation evidence outside
+  distributable skills; record 30 passing affected cases and three routing checks.
+- Version both plugin manifests as `1.1.0-beta.1`.
+- Publish betas from the existing open release PR without merging its branch.
+
+[Compare with beta.0](https://github.com/meteor/agent-skills/compare/v1.1.0-beta.0...v1.1.0-beta.1).
+
 ## 1.1.0-beta.0 - 2026-09-11
 
 Beta for Meteor 3.6-beta.0 (`release-3.6`). The catalog keeps its 16 skills

README.md

@@ -2,15 +2,14 @@
 
 Agent Skills for AI assistants helping developers build, debug, migrate, and operate **Meteor 3 applications**.
 
-> Status: beta. Sixteen Meteor 3 skills are available in the current catalog.
+> Status: beta. Seventeen Meteor 3 skills are available in the current catalog.
 
 See [the changelog](./CHANGELOG.md) for additions and updates.
 
-This branch prepares `1.1.0-beta.0` for Meteor `3.6-beta.0`. It is an
-unpublished review candidate based on `v1.0.0-beta.3`; the installation
-examples below still identify the published beta. See the
-[comparison and verification handoff](./docs/releases/v1.1.0-beta.0.md)
-to review or test this working tree.
+[Version 1.1.0-beta.3](https://github.com/meteor/agent-skills/releases/tag/v1.1.0-beta.3)
+updates MongoDB upgrade preparation, Rspack, TypeScript and runtime guidance
+through Meteor `3.6-beta.3`, preserving earlier Meteor 3 compatibility branches.
+See the [verification handoff](./docs/releases/v1.1.0-beta.3.md).
 
 ## Install
 
@@ -31,7 +30,7 @@ To test a specific prerelease, pin the marketplace checkout to its repository
 tag before installing:
 
 ```bash
-codex plugin marketplace add meteor/agent-skills --ref v1.0.0-beta.3
+codex plugin marketplace add meteor/agent-skills --ref v1.1.0-beta.3
 codex plugin add meteor@meteor
 ```
 
@@ -48,7 +47,7 @@ To test a specific prerelease, append its repository tag to the marketplace
 source:
 
 ```bash
-claude plugin marketplace add meteor/agent-skills@v1.0.0-beta.3
+claude plugin marketplace add meteor/agent-skills@v1.1.0-beta.3
 claude plugin install meteor@meteor
 ```
 
@@ -59,6 +58,18 @@ Claude Code, Cursor, Codex, Copilot, Gemini CLI, OpenCode, and other supported
 agents. Use this route when you want only selected skills instead of the full
 Meteor plugin.
 
+To install this exact beta from your project directory:
+
+```bash
+npx skills@latest add 'meteor/agent-skills#v1.1.0-beta.3'
+```
+
+The tag pins the skill contents; `@latest` selects the installer. Reinstalling
+replaces the selected existing skill directories, leaving unselected skills
+in place. Restart your agent after installation.
+
+For the current default-branch catalog:
+
 ```bash
 # all skills (interactive picker)
 npx skills add meteor/agent-skills
@@ -103,6 +114,12 @@ Already installed? See [Manage an installation](#manage-an-installation).
   npx skills add meteor/agent-skills --skill meteor-native
   ```
 
+- **`meteor-typescript`**: Configure Meteor app declarations, TypeScript and JavaScript IntelliSense, and reliable local/CI type-checking.
+
+  ```bash
+  npx skills add meteor/agent-skills --skill meteor-typescript
+  ```
+
 ### Data
 
 - **`meteor-blaze`**: Build and debug Meteor 3 Blaze interfaces (Spacebars, Tracker state, async helpers, lifecycle, bundler-specific HMR, and components).