cor status
cor conflicts
cor remote listThese commands are safe to use while a worker is running. Status reads local state without contacting current, so it tells you what the workspace knows, not whether the server is reachable at this moment.
Run cor remote add YOUR_SERVER:8787 once, or start
cor work in a terminal for guided setup. Confirm you are
inside the right project; use --root PATH if needed.
Check that current is running, the saved address is reachable, and the
expected port is open. Use cor remote list to inspect the
address. A configured worker retries automatically. On the server, its
startup output shows the listening address and data folder.
On current, authorize the matching public key with
cor keys add FILE.pub. Select the private key with
--identity PATH, or load it into your agent with
ssh-add PATH. cor whoami shows the
authenticated fingerprint.
Compare the host fingerprint with current's startup output. Confirm a new
host interactively, or pass the verified value with
--host-key SHA256:.... A changed host is refused; only replace
the saved pin after independently verifying a deliberate host-key rotation.
Choose another port, for example
cor current --bind '[::]:8788', then update clients with
the matching address. Keep the same data directory to preserve the
repository identity.
For a local test, use
cor current --bind '127.0.0.1:8787' and connect to
ssh://127.0.0.1:8787. The no-argument server also has an IPv4
fallback when IPv6 is unavailable.
Verify the address and server data directory. Repository identity is deliberately pinned to prevent accidental attachment to a different project. Use a new workspace for a different repository. Preserve existing client state and files; do not delete them to bypass the check.
Allow one second of quiet, or up to five seconds of intentional batching
during continuous saves. Large-file hashing and transfer take additional
time. Check both workers, the server connection, ignore rules, and
cor conflicts. If current is offline, changes remain local
until an exchange succeeds.
Check the root and nested .gitignore files plus root
.laplaceignore. An excluded directory must be re-included
before a child can be re-included. Git metadata, node_modules,
and Corotation internals always stay excluded.
That is the whole-package rule. Every path in the rejected batch stays blocked, including paths that could have succeeded alone. Inspect the full package and follow the repair workflow.
Stop the other owning work, sync, or
resolve process before running another writer. Stop current
before a manual baseline. Do not delete a lock file while its
owning process is running.
Corotation does not synchronize symlinks or special files. Exclude them explicitly. Use portable UTF-8 filenames and consistent spelling; case-only renames and Unicode normalization aliases across filesystems are not supported.
Run the PATH command printed by the installer, or open a new terminal after
allowing shell configuration. By default the executable is in
~/.local/bin. Check your chosen --bin-dir if you
used one.
The Just recipes clear RUSTC_WRAPPER. If using Cargo directly,
run env RUSTC_WRAPPER= cargo build --release --locked. If
SQLite compilation fails, check the native C toolchain as described in
the prerequisites.
Historical chunks, receipts, baselines, orphan uploads, and local recovery copies are currently retained. Recovery/conflict copies may contain full files. There is no garbage collector yet; never manually delete chunks referenced by current or a retained baseline.
A client whose received sequence is ahead of the restored authority refuses to reopen normally, rather than silently accepting lost history. Preserve both the client workspace and restored server data. Review the independent backup and unsynchronized work before deciding how to recover; there is no automatic history reconciliation command.
Inspect the error and the partial destination. Exports refuse existing output directories, so retry into a new folder after fixing the connection or storage problem. Verify the recovered files before using them to replace working content.
This is an early, working implementation with tests for concurrency, corrupted data, interrupted recovery, network exchange, native watching, batching, and CLI setup. It has not undergone prolonged production use or exhaustive power-loss testing.
Use independent backups for valuable work, and keep the current node and each client’s private state intact when diagnosing a problem.
Upgrade current and the client, then run cor login once. Corotation enrolls a separate device key and remembers it outside the project. Future commands and reconnects use that key without contacting your password manager. If it was revoked or lost, use cor login --renew.