fix:fix workflow

deploy/server-maibot/README_DEPLOY_STEPS.txt

@@ -22,18 +22,26 @@ Gitea workflow:
 
 Current pipeline mode:
 - single-host release on the repo-level `build-host` runner
-- clones from local Gitea HTTP on `127.0.0.1:3000`
+- fetches the source commit from the workflow repository itself
+- defaults to `${gitea.server_url}/${gitea.repository}.git`
+- can override the clone URL with the repository variable `MAIBOT_REPO_URL`
+- authenticates Git over HTTP(S) with the built-in `GITEA_TOKEN`
+- performs a shallow fetch of the triggering commit instead of a full clone
 - stages source into `/srv/maibot/releases/<commit>`
 - builds `maibot-offline:<commit>` from the staged release using local base image `maibot-offline:latest`
 - tags the same image back to `maibot-offline:latest`
 - deploys from `/root/maibot-offline` with `docker compose up -d`
 
 Optional environment overrides for the workflow runtime:
+- `MAIBOT_REPO_URL`
 - `MAIBOT_RELEASE_ROOT`
 - `MAIBOT_RUNTIME_ROOT`
 - `MAIBOT_BASE_IMAGE`
 
-No repository secrets are required for the default same-host pipeline.
+Runner connectivity note:
+- if the runner cannot access `${gitea.server_url}` directly, set `MAIBOT_REPO_URL` to a runner-reachable HTTPS clone URL
+- for private repositories, the workflow uses the built-in `GITEA_TOKEN`, so no extra personal access token secret is needed
+- the repository or owner Actions settings must allow the job token to read repository contents
 
 Bootstrap note:
 - `deploy/server-maibot/Dockerfile.offline` is only for the first bootstrap or for refreshing the runtime base image.