Elevate requirements to organizational/architectural policy

- Security: no IAM in service repos, no custom auth, no direct external calls
- Architecture: no cross-cloud SDKs, no cross-service DB access, no hardcoded tenant/env config
- DevOps: Foxtrot-compatible Helm (no custom ingress), no infra provisioning in service repos, no pinned infra versions
- Cost: resource tagging, no unbounded allocation, no per-tenant infra
- Updated checker and demo to match
- These are NOT static code analysis — they catch organizational policy violations that SonarQube/Checkstyle miss

architecture/requirements.md

@@ -1,39 +1,36 @@
 # Architecture Requirements
 
 Phase: design
-Enforcement: informational (graduating to blocking Q3 2026)
+Enforcement: informational
 
-## ARCH-001: API Contract First
+## ARCH-001: No Cross-Cloud Dependencies
 
-All new or modified REST APIs MUST have an updated OpenAPI/Swagger spec BEFORE implementation begins.
+Services MUST NOT import cloud-provider-specific SDKs directly. All cloud interactions go through the platform abstraction layer.
 
-**Rule:** If a PR adds or changes an endpoint, the corresponding `openapi.yaml` or Swagger annotation must be updated in the same PR.
+**Rule:** No direct imports of `com.amazonaws.*`, `com.google.cloud.*`, or `com.azure.*` in service code. Use the platform's cloud-agnostic interfaces. If your service runs on AWS today, it must be deployable to GCP tomorrow without code changes.
 
-**Test:** Diff check — if files in `src/**/controller/**` or `src/**/api/**` changed, verify `**/openapi*.yaml` or `**/swagger*.yaml` also changed.
+**Test:** Scan imports for cloud-provider SDK packages outside the platform abstraction layer.
 
-## ARCH-002: Service Boundary Respect
+## ARCH-002: No Cross-Service Database Access
 
-Changes to a service MUST NOT directly import or reference internal classes from another service's module.
+Services MUST NOT directly query another service's database. All cross-service data access goes through APIs or events.
 
-**Rule:** Cross-service communication happens through APIs, events, or SDK interfaces only. No direct classpath coupling between service modules.
+**Rule:** Each service owns its schema. No shared database connections, no cross-schema joins, no direct table access outside your service boundary. If you need data from another service, call its API or consume its events.
 
-**Test:** Import scan — flag imports crossing module boundaries (e.g., `import com.reltio.server.internal.*` from SDK module).
+**Test:** Scan datasource configs and SQL for references to schemas/tables outside the service's declared ownership.
 
-## ARCH-003: Breaking Change Protocol
+## ARCH-003: No Hardcoded Tenant or Environment Configuration
 
-Any breaking API change (removed field, changed type, renamed endpoint) MUST include:
-1. A deprecation annotation on the old path
-2. A migration note in the PR description
-3. A minimum 30-day dual-support window
+Services MUST NOT contain hardcoded tenant IDs, environment URLs, or deployment-specific configuration in source code.
 
-**Rule:** Breaking changes without deprecation path are rejected.
+**Rule:** All tenant and environment config comes from the platform config plane (environment variables, config service, or Helm values). No `if (tenant == "acme")` logic. No `https://prod.reltio.com` literals.
 
-**Test:** Detect removed/renamed public API methods or fields in diff. Flag if no `@Deprecated` annotation present.
+**Test:** Scan for URL literals matching known environment patterns, hardcoded tenant identifiers, environment-switching conditionals.
 
-## ARCH-004: Multi-Repository Coordination
+## ARCH-004: API Contract Versioning
 
-For changes spanning multiple repositories (e.g., SDK + Server), the design spec MUST list all affected repos and the order of deployment.
+All public API changes MUST maintain backward compatibility or follow the deprecation protocol (minimum 30-day dual-support window).
 
-**Rule:** Multi-repo PRs must reference a shared Jira ticket and declare deployment sequence.
+**Rule:** No removed fields, renamed endpoints, or changed response shapes without a versioned migration path. Breaking changes require a new API version.
 
-**Test:** If PR description references multiple repos, verify Jira link present.
+**Test:** Diff OpenAPI specs between branches. Flag removed paths, removed required fields, or changed response types.