添加agent deployor

AGENTS.md

@@ -45,6 +45,23 @@ Important: there is no dedicated backend lint command and no dedicated backend t
 
 If you need one of these, run it explicitly from the file that already exists instead of inventing a new wrapper command.
 
+### Release and deploy commands
+
+- Frontend OSS publish from repo root:
+  `node scripts/deploy-front-oss.mjs`
+- Frontend OSS dry run from repo root:
+  `node scripts/deploy-front-oss.mjs --dry-run`
+- Frontend OSS publish without rebuilding from repo root:
+  `node scripts/deploy-front-oss.mjs --skip-build`
+- Backend package from `backend/`:
+  `mvn package`
+
+Important:
+
+- `scripts/deploy-front-oss.mjs` expects OSS credentials from environment variables or `.env.oss.local`.
+- The repository does not currently contain a checked-in backend deploy script. Backend delivery is therefore a two-step process: build `backend/target/yoyuzh-portal-backend-0.0.1-SNAPSHOT.jar`, then upload/restart it via `ssh` or `scp` using the real target host and remote procedure that are available at deploy time.
+- Do not invent a backend service name, process manager, remote directory, or restart command. Discover them from the server or ask only if they cannot be discovered safely.
+
 ## Role routing
 
 - `orchestrator`: default coordinator. It decides which specialist agent should work next, keeps cross-directory work aligned, and writes the final handoff. It should stay read-only.
@@ -53,6 +70,7 @@ If you need one of these, run it explicitly from the file that already exists in
 - `implementer`: code changes only. It owns edits in `backend/`, `front/`, `scripts/`, or docs, and may update nearby tests when the implementation requires it.
 - `tester`: verification only. It runs existing repo-backed commands and reports exact failures or missing commands. It should not rewrite source files.
 - `reviewer`: review only. It inspects diffs for correctness, regressions, missing tests, and command coverage gaps. It should stay read-only.
+- `deployer`: release and publish only. It builds the frontend and backend using existing commands, runs the checked-in OSS deploy script for the frontend, and handles backend jar upload/restart over SSH when credentials and remote deployment details are available.
 
 ## Default workflow
 
@@ -62,6 +80,7 @@ If you need one of these, run it explicitly from the file that already exists in
 4. Use `implementer` for the actual code changes.
 5. Use `tester` after implementation. Prefer the narrowest real command set that still proves the change.
 6. Use `reviewer` before final delivery, especially for cross-layer changes or auth/files/storage flows.
+7. Use `deployer` only after code is committed or otherwise ready to ship.
 
 ## Repo-specific guardrails
 
@@ -70,5 +89,7 @@ If you need one of these, run it explicitly from the file that already exists in
 - Backend local development behavior is split between `backend/src/main/resources/application.yml` and `application-dev.yml`; the `dev` profile uses H2 and mock CQU data.
 - Backend tests already exist under `backend/src/test/java/com/yoyuzh/...`; prefer adding or updating tests in the matching package.
 - Frontend tests already exist under `front/src/**/*.test.ts`; keep new tests next to the state or library module they verify.
+- For frontend releases, prefer `node scripts/deploy-front-oss.mjs` over ad hoc `ossutil` or manual uploads.
+- For backend releases, package from `backend/` and deploy the produced jar; do not commit `backend/target/` artifacts to git unless the user explicitly asks for that unusual workflow.
 
 Directory-level `AGENTS.md` files in `backend/`, `front/`, and `docs/` add more specific rules and override this file where they are more specific.