aws-test-plugin 0.1.1__tar.gz → 0.1.2__tar.gz

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
       "name": "claude-aws-test-plugin",
       "source": "./",
       "description": "Generates E2E, integration, contract, performance, and load tests by reading actual handler code.",
-      "version": "0.1.1"
+      "version": "0.1.2"
     }
   ]
 }

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "aws-test-plugin",
   "description": "AI-powered test generation skills for AWS Python projects — Lambda, API Gateway, Step Functions, and Batch. Generates E2E, integration, contract, performance, and load tests by reading actual handler code.",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "author": {
     "name": "whitewhiteqq"
   },

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/.github/workflows/publish.yml

@@ -1,38 +1,16 @@
 name: Publish to PyPI
 
 on:
-  push:
-    tags:
-      - "v*"
+  release:
+    types: [published]
 
 permissions:
   contents: read
   id-token: write  # Required for trusted publishing
 
 jobs:
-  verify-release-tag:
-    name: Verify release tag is on main
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Verify tag commit is reachable from main
-        shell: bash
-        run: |
-          git fetch origin main --depth=1
-          release_commit=$(git rev-list -n 1 "$GITHUB_REF")
-          if ! git merge-base --is-ancestor "$release_commit" "origin/main"; then
-            echo "Release tags must point to a commit on origin/main."
-            exit 1
-          fi
-
   build:
     name: Build distribution
-    needs: verify-release-tag
     runs-on: ubuntu-latest
 
     steps:

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/CONTRIBUTING.md

@@ -130,7 +130,7 @@ Principles:
 - Default to `Rebase and merge` for pull requests into `develop` so that every individual commit — and its reasoning — is preserved in the public history. Use `Squash and merge` only when the branch contains exploratory or fixup commits that add no lasting value; when squashing, the single merge commit must capture all essential context from the branch (see Commit Message Style).
 - Avoid GitHub merge commits for routine pull requests because they create noisy branch divergence and a less readable graph.
 - Promote releases from `develop` to `main` with a maintainer-run fast-forward update so both branches share identical history.
-- Tag every release on `main` with an annotated tag (`git tag -a v0.1.0 -m "..."`). Pushing that tag is the PyPI publish trigger, so releases follow one path only: feature branch -> `develop` -> `main` -> version tag -> PyPI. The tag message should summarize what shipped, key decisions made since the prior release, and any known limitations. Annotated tags are git objects — they survive cloning and forking, unlike GitHub-only release notes.
+- Tag every release on `main` with an annotated tag (`git tag -a v0.1.0 -m "..."`). Then create a GitHub Release targeting that tag — creating the Release is the PyPI publish trigger. Releases follow one path only: feature branch -> `develop` -> `main` -> version tag -> GitHub Release -> PyPI. The tag message should summarize what shipped, key decisions made since the prior release, and any known limitations. Annotated tags are git objects — they survive cloning and forking, unlike GitHub-only release notes.
 
 ## Commit Message Style
 
@@ -267,7 +267,7 @@ must also land in the commit messages that enter `develop`.
 6. Submit a pull request to `develop` using `.github/pull_request_template.md`
 7. Merge pull requests with `Rebase and merge` (preferred — preserves individual commit reasoning) or `Squash and merge` (only when intermediate commits are noise); do not use merge commits
 8. Release `develop` to `main` with a maintainer-run fast-forward update after CI passes on `develop`; use `git merge --ff-only develop` from a local checkout of `main` so `main` advances without rewriting or duplicating commit history
-9. Create and push an annotated version tag from `main`; this tag is the only supported trigger for publishing to PyPI
+9. Create and push an annotated version tag from `main`, then create a GitHub Release targeting that tag; the Release is the PyPI publish trigger
 10. Review responsibility is assigned through `.github/CODEOWNERS`
 
 ## Maintainer Notes
@@ -275,12 +275,12 @@ must also land in the commit messages that enter `develop`.
 - Protect `main` and `develop` against direct pushes.
 - Enable `Rebase and merge` (preferred) and `Squash and merge` (fallback) for contributor pull requests into `develop`. Disable `Create a merge commit` to enforce linear history.
 - Do not rely on GitHub merge buttons for release promotion to `main`; use a local `git merge --ff-only develop` followed by `git push origin main`.
-- Do not publish to PyPI from a feature branch or from `develop`. PyPI releases are created only after `develop` has been fast-forwarded into `main` and an annotated `v*` tag has been pushed from that `main` commit.
+- Do not publish to PyPI from a feature branch or from `develop`. PyPI releases are triggered only by creating a GitHub Release after `develop` has been fast-forwarded into `main` and an annotated `v*` tag has been pushed from that `main` commit.
 - Configure `develop` branch protection or rulesets to require linear history and the CI checks `Test (Python 3.10)`, `Test (Python 3.11)`, `Test (Python 3.12)`, `Test (Python 3.13)`, `Lint`, `Type Check`, and `Security`.
 - Configure `main` so only maintainers can update it, with no force pushes or deletions.
 - Keep release updates focused. Avoid mixing repository governance, experiments, and product changes in the same release.
 - Do not rewrite shared branch history unless there is a clear operational reason and the change is communicated.
-- After each fast-forward update to `main`, create an annotated tag and push it to publish that version to PyPI:
+- After each fast-forward update to `main`, create an annotated tag, push it, and then create a GitHub Release targeting that tag to publish to PyPI:
   ```bash
   git tag -a v<VERSION> -m "v<VERSION>: <one-line theme>
 

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aws-test-plugin
-Version: 0.1.1
+Version: 0.1.2
 Summary: AI-powered test generation skills for AWS Python projects — works with Claude Code, GitHub Copilot, and Codex
 Project-URL: Homepage, https://github.com/whitewhiteqq/aws-test-plugin
 Project-URL: Repository, https://github.com/whitewhiteqq/aws-test-plugin
@@ -329,7 +329,7 @@ See [CONTRIBUTING.md](CONTRIBUTING.md) for details.
 ## Review Flow
 
 - Pull requests should target `develop`; maintainers promote `develop` to `main` with a fast-forward release update.
-- PyPI publishing happens only from an annotated `v*` tag pushed from `main` after that promotion.
+- PyPI publishing is triggered by creating a GitHub Release targeting an annotated `v*` tag on `main`.
 - Review ownership is defined in `.github/CODEOWNERS`.
 - Pull request expectations are defined in `.github/pull_request_template.md`.
 

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/README.md

@@ -267,7 +267,7 @@ See [CONTRIBUTING.md](CONTRIBUTING.md) for details.
 ## Review Flow
 
 - Pull requests should target `develop`; maintainers promote `develop` to `main` with a fast-forward release update.
-- PyPI publishing happens only from an annotated `v*` tag pushed from `main` after that promotion.
+- PyPI publishing is triggered by creating a GitHub Release targeting an annotated `v*` tag on `main`.
 - Review ownership is defined in `.github/CODEOWNERS`.
 - Pull request expectations are defined in `.github/pull_request_template.md`.
 

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "aws-test-plugin"
-version = "0.1.1"
+version = "0.1.2"
 description = "AI-powered test generation skills for AWS Python projects — works with Claude Code, GitHub Copilot, and Codex"
 readme = "README.md"
 requires-python = ">=3.10"

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/src/aws_test_plugin/__init__.py

@@ -1,3 +1,3 @@
 """aws-test-plugin — AI-powered test generation for AWS Python projects."""
 
-__version__ = "0.1.1"
+__version__ = "0.1.2"

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/tests/test_cli.py

@@ -102,22 +102,6 @@ def test_skill_description_under_1024_chars():
         assert len(desc) <= 1024, f"{skill.name}: description is {len(desc)} chars (max 1024)"
 
 
-def test_skill_has_license():
-    """Every SKILL.md should have a license field."""
-    skills_dir = _get_data_dir() / "skills"
-    for skill in skills_dir.iterdir():
-        if not skill.is_dir():
-            continue
-        skill_md = skill / "SKILL.md"
-        if not skill_md.exists():
-            continue
-
-        content = skill_md.read_text(encoding="utf-8")
-        parts = content.split("---", 2)
-        if len(parts) >= 3:
-            assert "license:" in parts[1], f"{skill.name}/SKILL.md missing license"
-
-
 def test_skill_reference_links_resolve():
     """Reference file links in SKILL.md must point to existing files."""
     skills_dir = _get_data_dir() / "skills"

{aws_test_plugin-0.1.1 → aws_test_plugin-0.1.2}/uv.lock

@@ -1,5 +1,5 @@
 version = 1
-revision = 2
+revision = 3
 requires-python = ">=3.10"
 resolution-markers = [
     "python_full_version >= '3.11'",
@@ -76,7 +76,7 @@ wheels = [
 
 [[package]]
 name = "aws-test-plugin"
-version = "0.1.0"
+version = "0.1.1"
 source = { editable = "." }
 dependencies = [
     { name = "defusedxml" },