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

aws_test_plugin-0.1.2/.claude-plugin/marketplace.json

@@ -0,0 +1,17 @@
+{
+  "name": "claude-aws-test-plugin",
+  "owner": {
+    "name": "whitewhiteqq"
+  },
+  "metadata": {
+    "description": "AI-powered test generation skills for AWS Python projects — Lambda, API Gateway, Step Functions, and Batch."
+  },
+  "plugins": [
+    {
+      "name": "claude-aws-test-plugin",
+      "source": "./",
+      "description": "Generates E2E, integration, contract, performance, and load tests by reading actual handler code.",
+      "version": "0.1.2"
+    }
+  ]
+}

{aws_test_plugin-0.1.0 → 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.0",
+  "version": "0.1.2",
   "author": {
     "name": "whitewhiteqq"
   },

{aws_test_plugin-0.1.0 → 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 "..."`). 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,18 +267,20 @@ 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. Review responsibility is assigned through `.github/CODEOWNERS`
+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
 
 - 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 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:
+- 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.0 → aws_test_plugin-0.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aws-test-plugin
-Version: 0.1.0
+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,6 +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 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.0 → aws_test_plugin-0.1.2}/README.md

@@ -267,6 +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 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.0 → aws_test_plugin-0.1.2}/agents/aws-test-engineer.md

@@ -1,6 +1,6 @@
 ---
 name: aws-test-engineer
-purpose: >
+description: >
   Generate, run, and fix comprehensive tests for AWS Python projects.
   Analyzes actual handler code to produce E2E, integration, contract,
   performance, and load tests. Works with Lambda, API Gateway,
@@ -12,29 +12,6 @@ skills:
   - aws-integration-testing
   - aws-contract-testing
   - aws-perf-load-testing
-definition_of_done:
-  - All discovered AWS components have corresponding test files
-  - Unit tests cover every branch, boundary value, and edge case in business logic
-  - Every code path (happy path, error handling, edge cases) has a test
-  - Tests pass locally with moto/testcontainers (no real AWS calls)
-  - Test coverage for handler logic is >= 80% (branch coverage)
-  - Performance benchmarks have defined thresholds
-  - Load test locustfiles match API spec endpoints
-  - Test data uses prefixes for easy cleanup (TEST-, E2E-TEST-, LOAD-TEST-)
-  - conftest.py provides shared fixtures for all test types
-  - pytest.ini configures markers and test paths
-  - No secrets, API keys, or tokens hardcoded in test files
-  - .env.example documents required configuration variables
-  - All offline tests can run in 1 click via `python scripts/run_tests.py all`
-  - Installation guidance lists the required test dependency groups
-safety:
-  - Never run tests against production without explicit user confirmation
-  - Never make real AWS API calls — use moto or testcontainers
-  - Never store credentials, API keys, or tokens in test files
-  - Never delete production data
-  - Load tests must have --run-time set (no unbounded runs)
-  - All test data is prefixed and self-cleaning
-  - Use .env files (gitignored) for secrets, never commit .env
 ---
 
 # AWS Test Engineer Agent
@@ -93,3 +70,30 @@ source code, not from generic templates.
 | Performance | pytest-benchmark | Yes | No |
 | E2E | requests + pytest | No | Yes |
 | Load | Locust | No | Yes |
+
+## Definition of Done
+
+- All discovered AWS components have corresponding test files
+- Unit tests cover every branch, boundary value, and edge case in business logic
+- Every code path (happy path, error handling, edge cases) has a test
+- Tests pass locally with moto/testcontainers (no real AWS calls)
+- Test coverage for handler logic is >= 80% (branch coverage)
+- Performance benchmarks have defined thresholds
+- Load test locustfiles match API spec endpoints
+- Test data uses prefixes for easy cleanup (TEST-, E2E-TEST-, LOAD-TEST-)
+- conftest.py provides shared fixtures for all test types
+- pytest.ini configures markers and test paths
+- No secrets, API keys, or tokens hardcoded in test files
+- .env.example documents required configuration variables
+- All offline tests can run in 1 click via `python scripts/run_tests.py all`
+- Installation guidance lists the required test dependency groups
+
+## Safety Rules
+
+- Never run tests against production without explicit user confirmation
+- Never make real AWS API calls — use moto or testcontainers
+- Never store credentials, API keys, or tokens in test files
+- Never delete production data
+- Load tests must have --run-time set (no unbounded runs)
+- All test data is prefixed and self-cleaning
+- Use .env files (gitignored) for secrets, never commit .env

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

@@ -1,6 +1,6 @@
 [project]
 name = "aws-test-plugin"
-version = "0.1.0"
+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.0 → aws_test_plugin-0.1.2}/skills/aws-contract-testing/SKILL.md

@@ -1,9 +1,5 @@
 ---
 name: aws-contract-testing
-license: Apache-2.0
-metadata:
-  author: whitewhiteqq
-  version: "0.1.0"
 description: >
   Generate contract tests that validate API schemas, request/response shapes,
   required fields, security definitions, and step function input/output

{aws_test_plugin-0.1.0 → aws_test_plugin-0.1.2}/skills/aws-e2e-testing/SKILL.md

@@ -1,9 +1,5 @@
 ---
 name: aws-e2e-testing
-license: Apache-2.0
-metadata:
-  author: whitewhiteqq
-  version: "0.1.0"
 description: >
   Generate comprehensive end-to-end tests for AWS Python services by reading
   the actual handler code logic. Covers API Gateway Lambda proxies,

{aws_test_plugin-0.1.0 → aws_test_plugin-0.1.2}/skills/aws-integration-testing/SKILL.md

@@ -1,9 +1,5 @@
 ---
 name: aws-integration-testing
-license: Apache-2.0
-metadata:
-  author: whitewhiteqq
-  version: "0.1.0"
 description: >
   Generate comprehensive integration tests for AWS Python Lambda functions,
   Batch jobs, and services that interact with S3, DynamoDB, RDS/PostgreSQL,

{aws_test_plugin-0.1.0 → aws_test_plugin-0.1.2}/skills/aws-perf-load-testing/SKILL.md

@@ -1,9 +1,5 @@
 ---
 name: aws-perf-load-testing
-license: Apache-2.0
-metadata:
-  author: whitewhiteqq
-  version: "0.1.0"
 description: >
   Generate performance benchmarks and load tests for AWS Python services.
   Performance tests measure Lambda latency, memory usage, cold start time,

{aws_test_plugin-0.1.0 → aws_test_plugin-0.1.2}/skills/aws-test-orchestrator/SKILL.md

@@ -1,9 +1,5 @@
 ---
 name: aws-test-orchestrator
-license: Apache-2.0
-metadata:
-  author: whitewhiteqq
-  version: "0.1.0"
 description: >
   Master skill for testing AWS Python projects. Discovers project components
   (Lambda, API Gateway, Step Functions, Batch), reads handler code logic,

{aws_test_plugin-0.1.0 → aws_test_plugin-0.1.2}/skills/aws-unit-testing/SKILL.md

@@ -1,9 +1,5 @@
 ---
 name: aws-unit-testing
-license: Apache-2.0
-metadata:
-  author: whitewhiteqq
-  version: "0.1.0"
 description: >
   Generate thorough unit tests for AWS Python business logic with full branch
   coverage, boundary value analysis, and edge case testing. Isolates pure

{aws_test_plugin-0.1.0 → 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.0"
+__version__ = "0.1.2"

{aws_test_plugin-0.1.0 → 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.0 → 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" },