cloud/.github/PULL_REQUEST_TEMPLATE.md

Description of the Change

Problem

Solution

Closes #

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• 🚀 New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🔧 Configuration change
• 🧪 Test update
• 🛡️ Security update

Areas Affected

• SDK Core (Call patterns, Transport, Configuration)
• Security Framework (PoW, Encryption, Signatures)
• Data Models (Request/Response types, Validation)
• Anonymizer Engine (PII/Secrets masking, Pattern recognition)
• License System (Validation, Introspection, Tier management)
• Examples (Integration patterns, Usage demonstrations)
• Documentation (README, API reference, Package docs)
• Testing (Unit tests, Benchmarks, Integration tests)

Testing and Verification

Test Configuration

Go Version:
SDK Version:
Host OS:
Target Services: [Update/Package/Support/AI]
License Type: [Free/Professional/Enterprise]

Test Steps

Test Results

Security Considerations

Performance Impact

Documentation Updates

• README.md updates
• API.md documentation updates
• Package documentation (doc.go files)
• Example code updates
• CONTRIBUTING.md updates
• Other:

Integration Notes

Checklist

Code Quality

• My code follows Go coding standards and project conventions
• I have added/updated necessary documentation (doc.go, README, API.md)
• I have added comprehensive tests covering new functionality
• All new and existing tests pass (go test ./...)
• I have run go fmt, go vet, and go mod tidy
• Benchmarks added for performance-critical changes

Security

• I have considered security implications of changes
• Cryptographic operations follow established patterns
• Sensitive data anonymization implemented where applicable
• No sensitive information exposed in logs or error messages
• PoW algorithm changes reviewed for FPGA/GPU resistance

Compatibility

• Changes are backward compatible with existing SDK users
• Breaking changes are clearly marked and documented
• Dependencies are properly updated and verified
• License validation compatibility maintained

Documentation

• Package documentation (doc.go) updated for public APIs
• Code comments follow project standards (lowercase, focus on why/how)
• Examples updated to demonstrate new functionality
• API.md updated for new endpoints or models

Additional Notes