replicas-cli 0.3.113 → 0.3.115

package/dist/index.cjs

@@ -24597,7 +24597,7 @@ Design from what you verified, not from what the README promises.
 
 **Variables** \u2014 every key the application or hooks need, with a one-line description and whether it is required to run locally. Keys only, never values.
 
-**Automations** \u2014 the set that should exist for this repository after saving, usually two to four. Each entry has a \`key\` and an \`action\`. \`create\` (the default) adds a new automation and needs a name, one-sentence description, a complete prompt an agent can execute unattended, and triggers. For an automation that already exists, pass its \`automation_id\` and a one-sentence \`note\` the reviewer sees next to it, then choose: \`update\` rewrites it with the full new content (also how you replace it with something better, under a new name if needed), \`keep\` leaves it untouched, \`disable\` turns it off. Every automation already attached to the environment must appear with one of those three; ones you leave out are not shown to the reviewer. Good candidates for new ones: pull request review focused on this codebase's conventions (\`pull_request.opened\` + \`pull_request.synchronize\`), nightly or weekly health checks (cron), documentation sync when code changes, dependency or security review, flaky-test triage. Only propose what the repository evidence supports.
+**Automations** \u2014 the set that should exist for this repository after saving. Propose only what the repository shows the team would use, like a chore people repeat or a check reviewers keep asking for. Each run uses a workspace, so zero new ones is a fine answer. Each entry has a \`key\` and an \`action\`. \`create\` (the default) adds a new automation and needs a name, one-sentence description, a complete prompt an agent can execute unattended, and triggers. For an automation that already exists, pass its \`automation_id\` and a one-sentence \`note\` the reviewer sees next to it, then choose: \`update\` rewrites it with the full new content (also how you replace it with something better, under a new name if needed), \`keep\` leaves it untouched, \`disable\` turns it off. Every automation already attached to the environment must appear with one of those three; ones you leave out are not shown to the reviewer. Ideas, if the evidence supports them: pull request review focused on this codebase's conventions (\`pull_request.opened\` + \`pull_request.synchronize\`), nightly or weekly health checks (cron), documentation sync when code changes, dependency or security review, flaky-test triage.
 
 Trigger shapes:
 
@@ -24849,7 +24849,7 @@ gh pr review 123 --request-changes --body "Changes needed"
 
 ## Media in GitHub workflows
 
-Media delivery is owned by \`references/MEDIA.md\`. Read it before adding screenshots, GIFs, recordings, diagrams, or HTML reports to a pull request, issue, review comment, or commit; it covers when to use a GIF instead of screenshots, the public links every image upload prints, recording previews, organization-only HTML links, and the required **View in Replicas** link.
+Media delivery is owned by \`references/MEDIA.md\`. Read it before adding screenshots, GIFs, recordings, diagrams, or HTML reports to a pull request, issue, review comment, or commit; it covers when to use a GIF instead of screenshots, the public links every image upload prints, recording previews, and organization-only HTML links.
 `;
 var GITHUB_ABILITY = {
   label: "GitHub",
@@ -24911,7 +24911,7 @@ await replicas.gitlab.request('/projects/group%2Frepo/pipelines', {
 
 ## Descriptions and media
 
-API updates replace the entire merge request description, so always preserve the required Replicas footer and co-author trailers. Media delivery is owned by \`references/MEDIA.md\`; read its GitLab section before adding media so the original bytes are uploaded to Replicas and GitLab and the dashboard link remains secondary.
+API updates replace the entire merge request description, so always preserve the required Replicas footer and co-author trailers. Media delivery is owned by \`references/MEDIA.md\`; read its GitLab section before adding media so the original bytes are uploaded to Replicas and GitLab.
 `;
 var GITLAB_ABILITY = {
   label: "GitLab",
@@ -24971,7 +24971,7 @@ var REFERENCE6 = `# GPU sandboxes
 ## One-shot runs
 
 \`\`\`bash
-replicas gpu run --gpu H100 --pull outputs -- python train.py
+replicas gpu run --pull outputs -- python train.py
 \`\`\`
 
 This starts a sandbox, copies the current directory to \`${COMPUTE_SANDBOX_WORKDIR}\` (git repositories honor \`.gitignore\`), streams the command's output, copies \`${COMPUTE_SANDBOX_WORKDIR}/outputs\` back to \`./outputs\`, stops the sandbox, and exits with the command's exit code. Add \`--keep\` to leave it running.
@@ -24979,7 +24979,7 @@ This starts a sandbox, copies the current directory to \`${COMPUTE_SANDBOX_WORKD
 ## Interactive sessions
 
 \`\`\`bash
-replicas gpu create --gpu A100-80GB --timeout 3h   # waits until running
+replicas gpu create                                # waits until running
 replicas gpu push                                  # . -> ${COMPUTE_SANDBOX_WORKDIR}
 replicas gpu exec -- nvidia-smi
 replicas gpu exec -- pip install -r requirements.txt
@@ -24997,7 +24997,7 @@ replicas gpu delete
 
 ## Choosing hardware and images
 
-- GPUs: ${GPU_TYPES.join(", ")} (default ${DEFAULT_GPU_TYPE}). Add a count for multi-GPU, e.g. \`H100:4\` (max ${COMPUTE_SANDBOX_LIMITS.maxGpuCount}). Pick the smallest GPU that fits: T4/L4 for small models and smoke tests, A100/H100 for real training.
+- GPUs, picked with \`--gpu\`: ${GPU_TYPES.join(", ")} (default ${DEFAULT_GPU_TYPE}). Add a count for multi-GPU, e.g. \`H100:4\` (max ${COMPUTE_SANDBOX_LIMITS.maxGpuCount}). Pick the smallest GPU that fits: T4/L4 for small models and smoke tests, A100/H100 for real training.
 - Default image: \`${DEFAULT_GPU_IMAGE}\`. Pass any public registry image with \`--image\`; the first start of a new image takes a few minutes to pull.
 - The sandbox has internet access. Download datasets and weights inside it rather than pushing them; pushes and pulls are capped at ${COMPUTE_SANDBOX_LIMITS.maxTransferBytes / 1024 ** 3} GiB.
 
@@ -25190,24 +25190,13 @@ ffmpeg is baked into the workspace image. If it's missing, install it with \`sud
 
 ### Before and after
 
-Record both with the same steps, window size, and crop. Say in one line what to watch for, then put the GIFs side by side in a table, or in labeled sections when they are wide:
-
-\`\`\`markdown
-The menu should open on its trigger. Before, it jumps about 95px up in half the openings.
-
-| Before | After |
-| --- | --- |
-| ![Language menu before fix](<before-gif-url>) | ![Language menu after fix](<after-gif-url>) |
-| [View in Replicas](<before-dashboard-url>) | [View in Replicas](<after-dashboard-url>) |
-\`\`\`
-
-Make comparisons easy to see at a glance, whether it's before and after or options to pick from. Crop to the part that changed, keep every version big enough to read, and make it clear which is which. Avoid tall full-page screenshots; at PR width the change is too small to see. For screenshots, a small HTML page with the crops, screenshotted at 2x, works well. For GIFs, the table above works.
+Make comparisons easy to see at a glance, whether it's before and after or options to pick from. Capture each version the same way, so only the change differs, and say in one line what to look for. Crop to the part that changed, keep every version big enough to read, and make it clear which is which. Avoid tall full-page screenshots; at PR width the change is too small to see. A new feature usually only needs the after. For screenshots, a small HTML page with the crops, screenshotted at 2x, works well. For GIFs, a two-column Markdown table works well.
 
 ## When to upload
 
 Upload to Replicas in these cases \u2014 and **only** these cases:
 
-1. **Media you produce.** Any screenshot, screen recording, generated diagram, audio clip, or HTML page you create that the user might want to see. Upload before doing anything else with the file (analyzing, deleting, sending elsewhere). This applies even when you're also sending the file to Slack, Linear, GitHub, or GitLab.
+1. **Media you show the user.** A screenshot, screen recording, generated diagram, audio clip, or HTML page, once you decide to show it to the user or share it. Screenshots you take only to check your own work stay local. Upload before you delete the file or send it anywhere else. This applies even when you're also sending the file to Slack, Linear, GitHub, or GitLab.
 2. **Files the user explicitly asks you to upload.** If the user sends or points at a file (image, video, audio, HTML) and asks you to upload it, run \`replicas media upload\`. Otherwise leave it alone \u2014 files in the workspace the user did not ask about should not be auto-uploaded as media.
 3. **Anything you plan to share externally (Slack, Linear, GitHub, GitLab, etc.).** Upload to Replicas first, then follow the destination's delivery path below.
 
@@ -25220,7 +25209,7 @@ If none of these apply, don't upload.
 1. First, run \`replicas media upload\` with the original file. Do not begin any destination upload until the command succeeds. This creates the canonical dashboard copy and prints an embed plus a per-file dashboard link. Every image gets a public link, so its printed embed works in chat and on GitHub.
 2. Include the printed embed line in the Replicas chat reply. HTML uses its printed page link instead of an image embed.
 3. Identify every destination in the task and use its inline representation from the table below. Slack, Linear, and GitLab require an upload of the same original bytes; GitHub uses the image's printed public embed.
-4. Put the **View in Replicas** dashboard link next to the destination embed as a secondary link.
+4. On Slack and Linear, put the **View in Replicas** dashboard link next to the destination embed as a secondary link. GitHub and GitLab need only the embed.
 5. Check each destination response. If its upload or public link fails, say so explicitly and keep the dashboard link; never claim that a dashboard link is an inline embed.
 
 | Destination | Required file delivery | Inline result |
@@ -25323,9 +25312,9 @@ Never reply with only dashboard links (for example a "Links:" list of \`?mode=me
 After \`replicas media upload\` succeeds, external delivery has two required follow-up steps for every file:
 
 1. **Use the destination's inline representation:** upload the raw bytes to Slack, Linear, or GitLab; embed the image's printed public link on GitHub.
-2. **Link the Replicas dashboard deep link** (\`?mode=media&media=<id>\` form) so the user can jump straight to the file in the workspace.
+2. **On Slack and Linear, link the Replicas dashboard deep link** (\`?mode=media&media=<id>\` form) so the user can jump straight to the file in the workspace. On GitHub and GitLab, the embed is enough.
 
-A dashboard link alone is not enough. An embed without the dashboard link is not enough. Do both.
+A dashboard link alone is never enough.
 
 Slack, Linear, and GitLab receive the original bytes through their native upload APIs. GitHub uses the printed public link for screenshots and recording previews.
 
@@ -25440,7 +25429,7 @@ Replicas authenticates GitHub with GitHub App tokens, which GitHub's attachment
 replicas media upload /tmp/screenshot.png --name "PR screenshot"
 \`\`\`
 
-2. Copy the printed \`![filename](<public-url>)\` line verbatim into the body file, followed by the matching **View in Replicas** link. Never use a local file path, a \`/v1/media/<id>\` URL, a Linear \`assetUrl\`, or an expiring storage URL.
+2. Copy the printed \`![filename](<public-url>)\` line verbatim into the body file. Never use a local file path, a \`/v1/media/<id>\` URL, a Linear \`assetUrl\`, or an expiring storage URL.
 3. Create or update the PR using the body file:
 
 \`\`\`bash
@@ -25463,7 +25452,7 @@ Do **not** commit screenshots to the repo, use placeholder URLs, expose the auth
 
 ### GitLab: native inline screenshots and videos
 
-GitLab supports native project Markdown uploads. For a GitLab destination, always upload the media to Replicas first, then POST the same original file to the repository's \`/projects/:id/uploads\` API using the workspace GitLab credential. Insert the returned \`markdown\` value into the merge request body or comment and include the Replicas dashboard link. Image uploads render inline; MP4, MOV, and WebM uploads render as inline video players.
+GitLab supports native project Markdown uploads. For a GitLab destination, always upload the media to Replicas first, then POST the same original file to the repository's \`/projects/:id/uploads\` API using the workspace GitLab credential. Insert the returned \`markdown\` value into the merge request body or comment. Image uploads render inline; MP4, MOV, and WebM uploads render as inline video players.
 
 Do not use a Replicas public link for GitLab when the native project upload succeeds; native uploads preserve project access controls. \`replicas.gitlab.request\` only sends JSON and cannot POST multipart file bytes, so without another supported upload path use the GitHub flow above instead: the image's printed public embed, and a poster linked to the recording's **View in Replicas** URL.
 
@@ -26383,6 +26372,7 @@ var DEFAULT_USER_PREFERENCES = {
   open_prs_in_graphite: false,
   open_links_in_desktop_app: false,
   port_forwarding: false,
+  follow_up_mode: "steer",
   memory_enabled: null,
   subagent_mcp_enabled: null,
   default_fast_mode: false,
@@ -28734,7 +28724,7 @@ var headlessAgentRequestSchema = external_exports.object({
 });
 
 // ../shared/src/cli-version.ts
-var CLI_VERSION = "0.3.113";
+var CLI_VERSION = "0.3.115";
 
 // ../shared/src/version.ts
 function compareVersions(v1, v2) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "replicas-cli",
-  "version": "0.3.113",
+  "version": "0.3.115",
   "description": "CLI for managing Replicas workspaces - SSH into cloud dev environments with automatic port forwarding",
   "main": "dist/index.cjs",
   "bin": {