Initial commit: reorganized source tree

- backend/: 13 Maven modules (cw-elevator-application, cloudwalk-cloud, intelligent-cwoscomponent, ninca-crk, etc.)
- frontend/: 4 Vue projects (elevator-front, cwos-portal, alarm-front, front_acs) + decompiled + scripts
- scripts/: build, test-env, tools (Docker Compose, service templates, API parity)
- docs/: AGENTS.md, superpowers specs, architecture docs
- .gitignore: standard Java/Maven exclusions

Moved from legacy maven-*/ root layout to backend/ organized structure.

docs/operations/ninca-common-component-organization-prod-rolling-upgrade-3-instances.md

@@ -0,0 +1,43 @@
+# 生产滚动升级：ninca-common-component-organization（三实例）
+
+**现场根目录（部署包）：**  
+`/media/zebra/9e8fa357-7db6-4d70-88ed-d5de5a059a663/星河湾星中星/部署包/ninca_common_component_organization_01-ninca_common_component_organization`  
+
+根下含 `bootstrap.properties`、`application-node.properties` 示例、`sql/`；三台各用子目录（本仓样例为 `…207` / `…208` / `…209`，与 `application-node.properties` 里 `component-organization-01`～`03` 对应）。
+
+---
+
+## 1. 为什么这样升级对终端用户额外风险小
+
+三台是**滚动替换**：任意时刻总有两台在跑，上游 Consul/Ribbon 或负载均衡会把流量导向健康实例，不会像整机停机那样突然断服务。  
+数据库脚本在 `**component-organization`** 库里**只执行一次**（维护窗口、由 DBA 或授权人在单点执行），避免三台各跑一遍弄乱数据。  
+若新版本在某台不满意，可**换回停机前备份的旧 JAR**；涉及访客楼层等策略时，也可在库或配置侧**关闭/禁用策略**降低影响（与研发确认具体字段）。运行与构建均为 **JDK 8**。
+
+---
+
+## 2. 升级顺序（先库后应用）
+
+1. **数据库（一次）**
+  在 `**component-organization`** 上按变更单执行对应 DDL/DML（脚本与部署包 `sql/`、`docs/sql/` 同源说明一致）。**同一迁移禁止在三台应用机上重复执行。** 慎用含 `DROP TABLE` 的「全量安装」类脚本；生产优先增量脚本。迁移验证落库后再动应用。
+2. **应用（逐台）**
+  建议顺序如 **207 → 208 → 209**（或按现网约定）。**每台流程：** 若现场有 LB/摘流习惯可先摘该实例 → `stop.sh` 停进程 → **备份当前 Fat JAR**（如加 `.bak.日期`）→ 上传新 JAR（与发布说明 **SHA-256** 一致；三台用同一制品）→ **JDK 8** 下 `start.sh` 启动 → 本节第 3 步检查通过后再处理下一台。  
+   保留各节点 `application-node.properties` 中的节点差异（Consul、instance-id、IP 等）；合并新版本键值时勿把数据源/Redis/注册中心改成测试环境。
+
+---
+
+## 3. 每台做完看什么（最多三条）
+
+- **健康：** `http://<节点IP>:<management.port>/actuator/health`（路径以现场为准）应为 **UP**。  
+- **日志：** `logs/` 下 info/error，无持续报错、无连库/注册中心失败风暴。  
+- **冒烟：** 按变更单做只读或低风险接口抽查；若本次含访客楼层策略，用只读方式确认读取符合预期。
+
+---
+
+## 4. 不满意怎么撤回
+
+**应用：** 停进程 → 把备份的 JAR 换回运行文件名 → 再起动并按上节三项看一眼。可只回滚有问题的那台。  
+**库：** 优先与研发确认是否可通过关策略、改配置规避；若必须还原库，由 DBA 在评估窗口内操作，必要时先停写或停齐三台应用，避免双写分叉。
+
+---
+
+**备忘：** 三台最终应用包 **SHA-256 一致**；`sql/README.txt` 中对含 `DROP` 的脚本风险有说明，执行前核对变更单。