@ricsam/r5d-worker 0.0.74 → 0.0.75

package/README.md

@@ -13,15 +13,17 @@ The worker uses the existing `r5dctl` config file and accepts `R5D_WORKER_TOKEN`
 ~/.r5d/projects/<namespace>/<project>/<branch-name>
 ```
 
-Web shells and agent shell commands receive a server-issued `r5dctl` credential automatically. The credential is scoped to the signed-in user and revoked when the shell or command finishes, so commands such as `r5dctl auth status` do not require a separate login on the worker host.
+Web shells and agent shell commands receive a server-issued `r5dctl` credential automatically. The credential is scoped to the signed-in user and revoked when the shell or command finishes, so every `r5dctl` command can use the user's account without a separate login on the worker host. Worker-specific process and session operations remain bound to the worker that received the credential.
 
 When the user has signed in with GitHub, web shells and agent commands also receive that OAuth credential through `GH_TOKEN`. GitHub CLI commands such as `gh pr`, `gh issue`, and `gh workflow` therefore use the signed-in user's permissions without a separate `gh auth login` on the worker host. Signing in again refreshes the granted OAuth scopes for subsequently started commands and shells.
 
-Visible branch checkouts are the user/agent workbench. Their `origin` is the authenticated r5d canonical project repository; GitHub remains available separately through `gh` and the injected OAuth credential. r5d workspace metadata lives under `~/.r5d/sync`, and each worker behaves like an eventually consistent Git client. Known writes advance a durable dirty generation and coalesce into a publication after five quiet seconds or at a process/agent boundary. Publications run while ordinary shells and commands remain active: the worker rejects unstable snapshots and hydrates only paths that still match their captured preimages. The worker uploads an immutable candidate, while the server alone promotes canonical `main` with compare-and-swap. A 60-second scan catches missed notifications and out-of-band edits. Canonical remediation shells are the exception because they edit the hidden synchronization checkout directly and remain serialized with exact synchronization.
+Project folders are the user/agent workbench. The primary branch is an ordinary clone and every sibling branch is a linked Git worktree, so branches share objects and refs and can cherry-pick or merge each other's commits directly. Connected projects keep GitHub as `origin`; greenfield projects use the r5d project repository. HTTP credentials are supplied through a worker-managed credential helper and are never written into synchronized files.
 
-Branch names managed by r5d use lowercase letters, numbers, internal hyphens, and slash-separated segments, for example `ft/esm-support`. They may contain at most 45 characters. On the first start after upgrading to the nested checkout layout, the worker atomically moves each unambiguous legacy `<namespace>-<project>` directory to `<namespace>/<project>`. If both paths exist, it preserves both and stops with recovery instructions.
+The hidden clone at `~/.r5d/sync/workspace` synchronizes working trees through ordinary Git: after five quiet seconds (or a process boundary), the worker commits mounted project and plan trees, rebases onto `origin/main`, and pushes. It retries push races, blocks oversized diffs for confirmation, and snapshots both heads when a rebase conflicts. A 60-second cycle catches out-of-band edits. Inner `.git` data is always excluded. After the outer workspace tree is reachable, changed project HEADs are force-pushed by explicit URL to the hidden per-project mirror; this tree-first ordering ensures a newly connected worker never observes a head newer than its synchronized tree.
 
-Releases that change the worker protocol are explicitly documented as breaking server/worker cutovers. For those releases, run the release-specific preflight and backfill against the production database, stop and upgrade workers to the required version, deploy the matching server, and then reconnect workers. Older workers are rejected before WebSocket upgrade rather than receiving incompatible target or manifest messages. Protocol-compatible releases use the ordinary worker update flow.
+Branch names managed by r5d use lowercase letters, numbers, internal hyphens, and slash-separated segments, for example `ft/esm-support`. They may contain at most 45 characters.
+
+Releases that change the worker protocol are explicitly documented as breaking server/worker cutovers. For those releases, run the release-specific preflight and backfill against the production database, stop and upgrade workers to the required version, deploy the matching server, and then reconnect workers. Older workers are rejected before WebSocket upgrade rather than receiving incompatible workspace configuration messages. Protocol-compatible releases use the ordinary worker update flow.
 
 Worker labels are mandatory and unique per user. Choose labels that describe host capabilities, such as `macos`, `linux`, `ios`, or `ec2-build`.