June 2, 2026 - Reape0r - CLI field guide - SkyePay access - mutable current mirror - customer install proof

Reape0r: the Autonomous Cloud Repo Mirror, from checkout to restore.

This is the public field guide for the daemon agent. A customer should be able to buy access, download the package, install it from an IDE terminal, run a first mirror, read the receipt links in the terminal, and understand exactly how to restore their codebase when the day goes sideways.

💳 Money-path proof · Founder proof journal

Gray London Skyes inside a SkyePay editorial scene with checkout receipts, plan logic, and entitlement paths.
💳 Commerce writing has to show the money path, entitlement path, and receipt path in the same frame.
💳 Proofcheckout proof Boundarypayment honesty Nextentitlement follow-through
Reape0r is not a promise that a zip exists somewhere. Reape0r is a command-line custody lane: install, scan, mirror, verify, restore, and show the proof.

Why does a repo mirror installer have to explain itself like a product?

An installer touches trust. It may write config, scan source, connect to a workspace, and ask the customer to believe the restore path. That cannot be handled like a random script from a blog post.

Reape0r has to move through SkyePay, FS27/SkyGate identity, scoped workspace access, terminal commands, receipts, quotas, status, verify, and restore language that a real buyer can follow.

The proof has to speak in artifacts: digests, byte counts, vault paths, restore commands, package manifests, entitlement checks, and receipts that a future operator can read without guessing what happened.

Pressure map
  • Pulse: source custody, restore posture, owner control.
  • Proof: The guide earns its place when it tells the customer what the commands do, what good output looks like, what stays local, and what proof exists after the first mirror.
  • Boundary: The boundary is just as valuable as the artifact. Customer recovery, runtime packages, owner source custody, and private implementation source are not the same thing, and the public story gets stronger when it keeps those lanes separate.

The part that has to stay honest.

The boundary is just as valuable as the artifact. Customer recovery, runtime packages, owner source custody, and private implementation source are not the same thing, and the public story gets stronger when it keeps those lanes separate.

The useful move is to reduce the loss window, make restore evidence easier to read, and turn source safety into something a buyer can understand before the emergency hits.

The operator question I carry forward.

I want the reader to leave this piece with a sharper decision, not just a nicer impression. The question is not "does this sound impressive?" The question is whether the surface can help a real person act with more confidence after the click. That is where DevodeRator has to stay different from content noise.

The proof also has to survive a second read. A first read can be carried by energy, but a second read is where the claim either keeps its weight or starts to feel inflated. I care about that second read because a serious buyer, developer, or operator will come back to the page with sharper eyes after the first impression fades. The piece has to keep answering.

That means the public lane needs three things close together: the claim, the evidence shape, and the limit. The claim tells the reader what changed. The evidence shape tells them how the system knows. The limit tells them what is private, gated, unfinished, provider-bound, or waiting on a stronger receipt. When those three stay together, the public archive can be proud without getting sloppy.

I also want the reader to feel the operational consequence. If the lane is healthier, what becomes easier tomorrow? If the lane is weaker than it looked, what should be watched before money, trust, or reputation moves through it? That practical consequence keeps the writing tied to the business instead of floating above it.

For a founder, the useful question is what risk this lane reduces. For a developer, it is what architecture pressure the lane exposes. For a buyer, it is what proof can be followed without a private tour. For an operator, it is what next action becomes easier because the system exists. The article has to serve all four without pretending they are the same reader.

That is why I keep the proof and the boundary in the same room. Proof without boundary becomes hype. Boundary without proof becomes fear. The strong version says what happened, why it matters, where the public can inspect it, and where the private operating layer stays protected. That balance is the whole reason this archive can sell the 0S without turning the company inside out.

The next move is simple: keep making the lane more usable, keep the receipts close, keep the links loud enough to click, and keep the language alive enough that a serious reader remembers the point after the tab closes. That is the standard this archive has to carry now. âš¡

A customer-safe CLI does not only run. It explains the risk it is reducing.

What the customer is buying.

The customer buys a workspace-backed Reape0r access lane. SkyePay handles the order. FS27 and the shared 0S gate handle access. The installer does not create a new founder password, a second owner account, or a disconnected admin lane. The customer receives a package, a workspace key for uploads, and clear commands. Owner/admin operations stay behind the shared 0S gate.

The core behavior is simple: Reape0r keeps one mutable encrypted current mirror of the repo. The first run creates the current mirror. Later runs scan the repo again and replace the changed encrypted objects inside that same current mirror. When the customer downloads or restores, they are using the repaired current state, not a pile of manual delta packs.

Current plan and quota table.

Plan Price Workspaces Vault storage Mirror objects Wake and retention
Reape0r Starter Access $49/month 1 25 GB 100,000 1 device, 30-min wake, 30d receipts, 7d restore points
Reape0r Pro Access $149/month 5 100 GB 500,000 3 devices, 10-min wake, 90d receipts, 30d restore points
Reape0r Command Access $499/month 15 500 GB 2,000,000 10 devices, 5-min wake, 180d receipts, 90d restore points
Reape0r Sovereign Access $1,500+/month custom 1 TB+ custom custom devices, 1-5-min wake, custom retention
Auto-Install Add-On $13 one time Uses existing plan Uses existing plan One machine bootstrap Writes env file, runs first current mirror, attempts watcher service
Support and capacity add-ons $19-$299+ Uses existing plan Storage, devices, workspaces, wake, restore help Plan-scoped Concierge install, emergency restore, extra storage, workspace pack, device pack, priority wake review

Before the terminal.

The customer needs three things before running Reape0r: the package download, the workspace id, and a workspace upload key. They also need an unlock passphrase. The passphrase can be supplied through an environment variable, or Reape0r can generate one locally during auto-install and write it into a private env file. That env file is not for Git.

Customer variables
export SKYEVAULT_DROP_URL="https://skyevault-drop.graylondonskyes.workers.dev"
export SKYEVAULT_WORKSPACE_ID="your-workspace-id"
export SKYEVAULT_PORTAL_KEY="your-workspace-upload-key"
export SKYEVAULT_AGENT_PASSPHRASE="your-private-unlock-passphrase"
export SKYEVAULT_AGENT_PLAN="pro"
export SKYEVAULT_AGENT_INTERVAL_SECONDS="600"
export SKYEVAULT_REPO_PATH="$PWD"

Manual install from an IDE terminal.

Manual install is for users who are comfortable inside Bash. It extracts the package, runs doctor, initializes config, syncs the mutable current mirror, then starts watch mode when they are ready.

curl -L -o skyevault-agent-latest.tar.gz \
  "https://metraiyux-0s-full-system.graylondonskyes.workers.dev/downloads/skyevault-agent/releases/latest/skyevault-agent-latest.tar.gz"

tar -xzf skyevault-agent-latest.tar.gz
cd skyevault-agent

node bin/skyevault-agent.mjs doctor
node bin/skyevault-agent.mjs init \
  --workspace="$SKYEVAULT_WORKSPACE_ID" \
  --repo="$SKYEVAULT_REPO_PATH" \
  --vault-url="$SKYEVAULT_DROP_URL" \
  --plan="$SKYEVAULT_AGENT_PLAN" \
  --interval-seconds="$SKYEVAULT_AGENT_INTERVAL_SECONDS"

node bin/skyevault-agent.mjs sync --plan="$SKYEVAULT_AGENT_PLAN" --interval-seconds="$SKYEVAULT_AGENT_INTERVAL_SECONDS" --upload
node bin/skyevault-agent.mjs status

Auto-install from an IDE terminal.

Auto-install is the $13 helper lane. It writes a private env file, configures the repo, runs doctor, performs the first mutable current sync unless the user disables it, and attempts to install a background watcher service for the machine. It still uses the customer's existing Reape0r plan. It is not a second vault plan.

curl -L -o skyevault-agent-latest.tar.gz \
  "https://metraiyux-0s-full-system.graylondonskyes.workers.dev/downloads/skyevault-agent/releases/latest/skyevault-agent-latest.tar.gz"

tar -xzf skyevault-agent-latest.tar.gz
cd skyevault-agent

SKYEVAULT_AGENT_AUTO_INSTALL=1 \
SKYEVAULT_WORKSPACE_ID="$SKYEVAULT_WORKSPACE_ID" \
SKYEVAULT_DROP_URL="$SKYEVAULT_DROP_URL" \
SKYEVAULT_PORTAL_KEY="$SKYEVAULT_PORTAL_KEY" \
SKYEVAULT_AGENT_PASSPHRASE="$SKYEVAULT_AGENT_PASSPHRASE" \
SKYEVAULT_AGENT_PLAN="$SKYEVAULT_AGENT_PLAN" \
SKYEVAULT_AGENT_INTERVAL_SECONDS="$SKYEVAULT_AGENT_INTERVAL_SECONDS" \
SKYEVAULT_REPO_PATH="$SKYEVAULT_REPO_PATH" \
./install.sh
Auto-install options
# Skip the service attempt, but still write env/config and run first sync.
SKYEVAULT_AGENT_AUTO_INSTALL=1 SKYEVAULT_AGENT_SERVICE_MODE=none ./install.sh

# Keep the setup local and skip the first upload.
SKYEVAULT_AGENT_AUTO_INSTALL=1 SKYEVAULT_AGENT_UPLOAD=0 ./install.sh

# Machine-readable proof mode for CI.
SKYEVAULT_AGENT_AUTO_INSTALL=1 SKYEVAULT_AGENT_JSON=1 ./install.sh

Day-to-day commands.

Normal commands print human output. Links are shown in terminal-friendly blue when the terminal supports it, and the same destinations are still printed as plain text for terminals that cannot display clickable links. Add --json when automation needs structured receipt output.

# See the latest mirror, receipt path, restore kit, upload state, and config.
node bin/skyevault-agent.mjs status

# Update the one mutable current mirror.
node bin/skyevault-agent.mjs sync --plan="$SKYEVAULT_AGENT_PLAN" --interval-seconds="$SKYEVAULT_AGENT_INTERVAL_SECONDS" --upload

# Keep it alive on the paid wake cycle. Faster raw values are clamped by entitlement.
node bin/skyevault-agent.mjs watch --plan="$SKYEVAULT_AGENT_PLAN" --interval-seconds="$SKYEVAULT_AGENT_INTERVAL_SECONDS" --upload

# Verify the latest current receipt.
node bin/skyevault-agent.mjs verify --receipt=/path/to/current-receipt.json

# Restore into a repaired folder.
node bin/skyevault-agent.mjs restore \
  --receipt=/path/to/current-receipt.json \
  --out=/tmp/repaired-repo

What good output looks like.

A successful Reape0r command should show the product name, status, workspace, repo, custody model, file count, byte count, changed count, digest, upload state, receipt link, restore-kit link, current manifest link, and next commands. That is the same proof shape I expect in chat, moved into the CLI where the customer needs it.

Minimum proof a customer should see
  • Status: OK
  • Model: mutable-current-mirror
  • Receipt link or file path
  • Restore kit link or file path
  • Current manifest link or file path
  • Upload state with uploaded/skipped/failed wording
  • Next commands for status, watch, or restore

How restore works in plain English.

The current receipt points at the current manifest. The current manifest points at encrypted current objects. Restore decrypts each object using the customer's unlock material and writes the repaired folder. The output folder should look like the repo state Reape0r saw during the last successful scan. If Reape0r runs every ten minutes, the normal loss window is the work that changed after the last scan and before the next one.

That is why mutable current matters. The buyer is not expected to collect an old base artifact plus a list of separate delta artifacts. The customer asks for the backup, and the restore lane is supposed to give the repaired current codebase.

Troubleshooting without panic.

Doctor says tar or git is missing

Install the missing local dependency, then run node bin/skyevault-agent.mjs doctor again. Reape0r uses the local machine to scan and package repo state, so the basics must be present.

Upload is skipped

Most skipped uploads mean the package does not see SKYEVAULT_PORTAL_KEY. Re-source the env file or export the key again, then run sync --upload.

Verify cannot unlock

Set the same passphrase env var used at sync time, or point Reape0r at the local unlock file written during auto-install. Without the unlock material, the encrypted mirror stays closed.

Restore folder is not empty

Pick a new output folder. If you are intentionally restoring over an existing folder, use --force only after you understand what will be overwritten.

The honest production standard.

A customer-facing daemon earns release through the payment lane, entitlement handoff, package manifest, archive checksum, install script, auto-install path, sync proof, verify proof, restore proof, no secret leakage, and live HTTP proof that the customer surfaces still answer. This is the bar Reape0r has to keep.

Receipts to expect from release work
  • test-artifacts/skyevault-agent-package/latest.json
  • test-artifacts/skyevault-agent-platform/latest.json
  • test-artifacts/skyevault-agent-auto-install/latest.json
  • test-artifacts/skyevault-agent-sales-readiness/latest.json