[EPIC] Migrate Aliyun ROS Resource Management to Terraform-like State Management

[Blankll]

Background

Currently, ServerlessInsight manages resources in two modes in parallel:

• Aliyun ROS template (legacy mode)
• Terraform-like state management (newer, recommended mode)

To mitigate conflicts, we standardize on a single solution: migrating all resource management to the Terraform-like state management system. Aliyun ROS implementation will be refactored and subsumed into this unified model.

---

Goal

Fully migrate Aliyun resource management from ROS template mode to the Terraform-like state management engine, removing all legacy code paths, configuration, and ensuring feature/web/API parity (including ROS coverage where possible).

---

Migration Requirements

• Refactor all Aliyun resource-related logic to operate via the unified Terraform-like stateful engine, maintaining support for all resources currently enabled in ROS.
• Remove any parallel/conditional handling of ROS-specific flows in resource management, planning, execution, and state tracking.
• Update configuration documentation/examples so YAML for Aliyun uses only provider-agnostic syntax consistent with the Terraform-like engine (no ROS-specific keywords, config blocks, CLI flags, etc.).
• Migrate state logic for Aliyun to the unified state store, support drift detection, plan/apply, idempotency, and correct dependency ordering. Verify parity with Tencent resource model.
• Update all relevant CLI commands (si deploy, si plan, etc.) so Aliyun is managed via the Terraform-like workflow.
• Remove/deprecate all legacy ROS modules and code paths after migration is tested and adopted.
• Call the bootstrap function to create resources; should migrate to call sdk functions directly.
• Conduct end-to-end tests to verify parity on typical Aliyun workflows (deploy function, create bucket, API Gateway config, environment variables, rollbacks, etc.).

---

Coding/Architecture Guidelines

• Use functional TypeScript: define functions as const xxx = (...) => .... Prefer functional decomposition over OOP; avoid classes unless strictly necessary.
• Prefer declarative/functional collection handling: replace for/while loops with map, filter, find, some, every, reduce, flatMap (and sort when appropriate). Favor pipeline-style transformations over step-by-step imperative logic.
• Favor immutability: avoid in-place mutation (push, splice, mutating objects/arrays, shared mutable state). Instead, return new arrays/objects and model changes as explicit state-transform functions (e.g., reducers).
• Prefer pure functions: keep functions small, composable, and side-effect-free where possible. If effects are required (I/O, logging), isolate them at the boundaries and keep core logic pure.
• Types: prefer type/enum over interface where possible; use type when it can fully replace an interface.
• Module boundaries: each module should export only via its index.ts; avoid deep imports.
• Export discipline: only export functions/types/constants that are used outside the module.
• Provider-agnostic design: keep provider-agnostic abstractions and follow clean separation of concerns.
• Comments and documentation: use as few inline comments as possible; behavior should be clear from tests and naming. When unifying/refactoring code, document the newly unified sections and the migration process with targeted comments and README updates.

---

Sub-Tasks

• Refactor Aliyun resource abstractions for Terraform-like CRUD lifecycle management
• Unify YAML/provider config syntax (drop ROS-specific elements)
• State management migration for Aliyun resources to unified state store
• Refactor CLI flows to use Terraform-like workflow for Aliyun
• Add migration handling for existing ROS user state/data
• Documentation updates (config, guides, migration steps)
• Remove/deprecate legacy ROS modules/code
• End-to-end feature parity tests (functions, buckets, APIs, etc.)

---

References

• Epic of Terraform-like Engine and tencent provider implementation: @geek-fun/serverlessinsight/issues/112
• Terraform Architecture: https://developer.hashicorp.com/terraform/internals
• Aliyun ROS docs: https://help.aliyun.com/zh/ros/product-overview/what-is-ros?spm=a2c4g.11174283.0.0.6ed84f44C6BL0x

---

Acceptance Criteria

• No Aliyun resource logic executes via ROS-only code after migration.
• All Aliyun resources fully managed via unified Terraform-like engine.
• Backwards compatibility for existing Aliyun users ensured or documented.
• Comprehensive test coverage for migrated workflows.