Implement platform-product config and governance tagging defaults

[tukue]

Motivation

• Convert documented platform-as-a-product recommendations into enforceable repo-level guardrails by making environment selection explicit and standardizing governance metadata.

Description

• Add a typed platform configuration module (lib/platform-config.ts) with dev|stage|prod validation and per-environment default metadata values.
• Wire the CDK entrypoint to load platform config from CDK context or PLATFORM_ENV and pass it into the stack via bin/app.ts.
• Refactor the main stack to require platformConfig (CdkAppStackProps) and replace ad-hoc tags with standardized governance tags (environment, project, owner, cost-center, data-classification) sourced from config in lib/cdk-app-stack.ts.
• Update unit tests and snapshot (test/cdk-app-stack.test.ts, test/__snapshots__/cdk-app-stack.test.ts.snap) and add README documentation describing the new guardrails and how to select the environment.

Testing

• Ran npm run build successfully.
• Ran unit tests with npm test -- --runInBand and all tests passed.
• Ran synthesis with npm run synth -- -c platformEnv=stage and synthesis completed successfully (non-blocking Node/CDK warnings were emitted).

---

Codex Task

[amazon-q-developer]

Summary

This PR introduces platform configuration and governance tagging infrastructure with typed environment validation. The implementation is generally sound, but contains 2 critical logic errors that must be fixed before merge.

Critical Issues (Must Fix)

1. Silent default to 'dev' environment (lib/platform-config.ts:35-37): The code defaults to 'dev' when no environment is specified, creating a dangerous scenario where production deployments could accidentally use development configuration if environment variables aren't set. This contradicts the documented "fail-fast" behavior and violates the principle of explicit configuration.

2. Documentation-implementation mismatch (README.md:79): The README claims "fail-fast errors" but the implementation silently defaults, misleading users about the actual behavior.

Required Actions

Fix the resolvePlatformEnvironment function to throw an error when no environment is specified, ensuring deployments fail explicitly rather than defaulting to an incorrect environment. This aligns the implementation with the documented "fail-fast" behavior and prevents potentially catastrophic misconfigurations.

Once these critical issues are resolved, the PR will provide robust environment validation and governance tagging capabilities.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.

[amazon-q-developer]

🛑 Logic Error: Silently defaulting to 'dev' when no environment is specified creates a critical risk where production deployments could accidentally use development configuration if PLATFORM_ENV or platformEnv context are not set. This violates the principle of failing safely and could lead to incorrect infrastructure provisioning. Throw an error instead to force explicit environment selection.

Suggested change

	if (!normalized) {
	return 'dev';
	}
	if (!normalized) {
	throw new Error(
	'Platform environment must be explicitly specified via platformEnv context or PLATFORM_ENV. Allowed values: dev, stage, prod.',
	);
	}

[amazon-q-developer]

🛑 Logic Error: The README claims "fail-fast errors for invalid values" but the implementation silently defaults to 'dev' when no environment is specified (line 36 in platform-config.ts). This creates a critical mismatch where production deployments could accidentally use dev configuration if environment variables are not set. Update documentation to accurately reflect the default behavior or fix the implementation to fail-fast on missing values.