feat(aws-lambda-translate): new construct

.kiro/prompts/new-construct.md

@@ -0,0 +1,102 @@
+# Implement New AWS Solutions Construct
+
+You are tasked with implementing a new AWS Solutions Construct based on the specification file at `specs/{{arg1}}` and the README.adoc file that has already been created.
+
+## Implementation Steps
+
+1. **Read the specification file** at `specs/{{arg1}}` to understand:
+   - Main services involved
+   - Interface requirements (props)
+   - Incoming props validation checks
+   - Configuration and integration logic
+   - Construct properties to expose
+
+2. **Review the existing README.adoc** in the construct directory to ensure alignment with documented behavior
+
+3. **Create the directory structure** following the pattern:
+   ```
+   source/patterns/@aws-solutions-constructs/aws-{service1}-{service2}/
+   ├── lib/
+   │   └── index.ts
+   ├── test/
+   │   ├── integ.*.test.ts
+   │   └── test.*.test.ts
+   ├── package.json
+   ├── .npmignore
+   ├── .gitignore
+   └── README.md (brief)
+   ```
+
+4. **Implement lib/index.ts**:
+   - Add Apache 2.0 license header
+   - Import required CDK modules and core helpers
+   - Define Props interface matching README.adoc documentation
+   - Implement Construct class with:
+     - Public properties for all created resources
+     - Constructor that validates props, creates resources, and configures integrations
+   - Follow patterns from similar existing constructs
+
+5. **Add core helper functions** if needed:
+   - Create `core/lib/{service}-helper.ts` for new services
+   - Add validation functions (e.g., `CheckTranslateProps()`)
+   - Add VPC endpoint support if required
+
+6. **Create package.json**:
+   - Set correct name: `@aws-solutions-constructs/aws-{service1}-{service2}`
+   - Configure JSII targets for TypeScript, Python, Java, .NET
+   - Add dependencies on `@aws-solutions-constructs/core` and `aws-cdk-lib`
+   - Include standard scripts: build, lint, test, integ
+
+7. **Write unit tests** in `test/test.*.test.ts`:
+   - Test default configuration
+   - Test with custom props
+   - Test with existing resources
+   - Test VPC deployment scenarios
+   - Test error conditions and validation
+   - Achieve 95%+ code coverage
+
+8. **Write integration tests** in `test/integ.*.test.ts`:
+   - Test default deployment
+   - Test major architectural variations (with/without VPC, existing resources, etc.)
+   - Use `generateIntegStackName()` and `SetConsistentFeatureFlags()`
+
+9. **Create supporting files**:
+   - `.npmignore` - exclude test files and source maps
+   - `.gitignore` - exclude build artifacts
+   - `README.md` - brief description pointing to README.adoc
+
+10. **Validate implementation**:
+    - Run `npm run build` to compile TypeScript
+    - Run `npm run lint` to check code style
+    - Run `npm test` to verify unit tests pass with coverage
+    - Run `npm run integ` to create integration test snapshots
+
+## Key Requirements
+
+- Follow naming conventions from structure.md
+- Use core helper functions for resource creation
+- Implement least-privilege IAM permissions
+- Add environment variables for resource discovery
+- Support VPC deployment when appropriate
+- Match all prop and property descriptions to README.adoc comments
+- Ensure consistency with existing constructs for shared services
+- Follow ESLint rules in eslintrc.config.mjs
+- Add license headers to all source files
+
+## Reference Documentation
+
+Refer to the steering files for detailed guidance:
+- `.kiro/steering/structure.md` - Repository structure and patterns
+- `.kiro/steering/product.md` - Product requirements and best practices
+- `.kiro/steering/tech.md` - Technical implementation details
+- `.kiro/steering/test.md` - Testing requirements and patterns
+- `.kiro/steering/exceptions.md` - Known exceptions to standard patterns
+
+## Output
+
+Provide a complete, working implementation that:
+- Compiles without errors
+- Passes all linting checks
+- Has comprehensive test coverage
+- Follows all Solutions Constructs patterns and conventions
+- Matches the behavior documented in README.adoc

.kiro/prompts/new-readme.md

@@ -0,0 +1,88 @@
+# Create README.adoc for New AWS Solutions Construct
+
+You are tasked with creating a README.adoc file for a new AWS Solutions Construct based on the specification file at `.kiro/specs/{{arg1}}`.
+
+## Implementation Steps
+
+1. **Read the specification file** at `.kiro/specs/{{arg1}}` to understand:
+   - Construct name (aws-{service1}-{service2})
+   - Main services involved
+   - Interface requirements (all props)
+   - Configuration and default settings
+   - Construct properties to expose
+
+2. **Determine the correct location**:
+   - Path: `source/patterns/@aws-solutions-constructs/aws-{service1}-{service2}/README.adoc`
+
+3. **Review similar constructs** for reference:
+   - For Lambda-based constructs, reference `aws-lambda-dynamodb` or `aws-lambda-transcribe`
+   - Match the structure and style of existing README.adoc files
+
+4. **Create README.adoc** with the following sections:
+
+   **Header:**
+   - Module name and title
+   - Stability badge (use Experimental for new constructs)
+   - Reference documentation link
+   - Language package table (TypeScript, Python, Java)
+
+   **Overview:**
+   - Brief description of what the construct does
+   - Minimal deployable examples in TypeScript, Python, and Java
+   - Use realistic runtime versions (NODEJS_20_X, PYTHON_3_11, etc.)
+
+   **Pattern Construct Props:**
+   - Table with columns: Name, Type, Description
+   - Include all props from the spec interface
+   - Link to AWS CDK API documentation for all types
+   - Mark optional props with `?`
+   - Ensure descriptions match what will be in the code comments
+
+   **Pattern Properties:**
+   - Table with columns: Name, Type, Description
+   - List all public properties exposed by the construct
+   - Link to AWS CDK API documentation for all types
+
+   **Default Settings:**
+   - Subsection for each major service
+   - Bullet list of default configurations applied
+   - Highlight security best practices (encryption, IAM, logging, etc.)
+
+   **Architecture:**
+   - Reference to architecture diagram: `image::aws-{service1}-{service2}.png`
+   - Brief description of the diagram
+
+   **Example Lambda Function Implementation (if applicable):**
+   - For Lambda constructs, link to AWS SDK example code
+   - Use github.com/awsdocs/aws-doc-sdk-examples links
+
+   **Footer:**
+   - Copyright notice
+
+## Key Requirements
+
+- Use AsciiDoc format with proper syntax
+- Ensure prop descriptions will match code comments exactly
+- Include links to AWS CDK API documentation for all types
+- Use tabbed code blocks for multi-language examples
+- Follow the exact structure and style of existing README.adoc files
+- Mark new constructs as Experimental stability
+- Ensure all props from the spec are documented
+- Document VPC-related props if applicable
+- Document S3 bucket props if applicable
+- Be precise about default values and optional parameters
+
+## Reference Examples
+
+Review these existing constructs for structure:
+- `aws-lambda-dynamodb/README.adoc` - Basic Lambda pattern
+- `aws-lambda-transcribe/README.adoc` - Lambda with S3 buckets and async jobs
+
+## Output
+
+Create a complete README.adoc file at the correct location that:
+- Follows all Solutions Constructs documentation patterns
+- Accurately reflects the spec requirements
+- Provides clear, working examples in multiple languages
+- Documents all props and properties comprehensively
+- Matches the style and structure of existing constructs

.kiro/specs/aws-lambda-translate.md

@@ -0,0 +1,38 @@
+# AWS Solutions Constructs Product Documentation
+
+## Spec for aws-lambda-translate
+This should only be referenced when generating code and artifacts for aws-lambda-translate, for any other tasks it should be ignored
+
+### Main Services
+* Lambda Function
+* Amazon Translate - Translate is an API, there are no depoyed resources. So there are no translateProps in the construct interface
+
+### Interface
+* All required props for Lambda based constructs
+* This is the first Construct using Translate, so this will define the interface for Translate constructs
+  * A flag, asyncJobs, that defaults to false
+  * Source and Destination S3 bucket props, modeled on those created for aws-lamba-transcribe
+  * AdditionalPermissions - an array of strings listing additional IAM permissions to grant the Lambda function. Default will be List* and Read*, is asyncJobs is true it will add StartTextTranslationJob and StopTextTranslationJob
+
+### Incoming Props Checks
+* All Lambda checks in CheckLambdaProps()
+* A new CheckTranslateProps() in core/translat-helper.ts that includes
+  * If any Source and Destination bucket info is provided when asyncJobs is false, an error is thrown
+  * If useSameBucket is set and any Destination bucket props are provided and error is thrown
+
+### Configuration
+* Obtain the Lambda function
+* Grant the Lambda function access to
+  * Translate:Read* and Translate:List*
+  * if asyncJobs is true add StartTextTranslationJob and StopTextTranslationJob
+  * Add any additionalPermissions
+  * if asyncJobs is true, grant read access to the source bucket and write access to the destination bucket
+* As instructed, create or use a VPC and add a Translate VPC endpoint to the VPC
+  * This will require adding Translate VPC Endpoints to the core library
+* If asyncJobs is true
+  * Add StartTextTranslationJob and StopTextTranslationJob actions to the Lambda IAM policy
+  * Create the source and destination bucket(s) following the pattern in aws-lambda-transcribe
+
+### Construct Properties
+* Standard Lambda Function properties
+* Translate does not require any exposed properties on the construct

.kiro/steering/exceptions.md

@@ -0,0 +1,12 @@
+# AWS Solutions Constructs - Exceptions List
+
+## Overview
+The rules for construct architecture laid out in product.md, tech.md, structure.md and test.md are not unversally followed, for various reasons, including:
+* Improved understanding of how services should be defined as the library grew
+* Scenarios where resources must be declared by a particular construct, so other constructs can only accept an existing construct (example - API Gateway must be launched integrated with a backend service, so aws-cloudfront-apigateway can only accept an existing service)
+* Services must be launched at the top level due to the need to export specific elements (example - Bedrock Inference Profiles are launched in aws-lambda-bedrockinferenceprofile/lib/index.ts)
+This document will explicitly list new exceptions and gradually document exceptions that have already been implemented.
+
+### VPCs Required for OpenSearch and Elasticsearch
+OpenSearch domains and Elasticsearch domains must be launched in a VPC - so any construct referencing these services does not expose the deployVpc property as it MUST be true.
+