@oddington/cli 0.1.42 → 0.1.44

package/README.md

@@ -1,4 +1,4 @@
-# Oddington CLI
+# OS CLI
 
 The CLI lets people and routines work with their OS from a terminal.
 
@@ -22,15 +22,38 @@ Run `os --help` or add `--help` to any command for the full command list.
 Commands print readable output by default. Add `--json` when another program
 will consume the result.
 
+Dropbox setup uses an offline OAuth URL and hidden one-time code entry:
+
+```sh
+os connection create dropbox --workspace example --name os-files
+os connection create dropbox --workspace example --name business --access full-dropbox --root "/Business"
+os connection list --workspace example --all
+os connection inspect --workspace example --id <returned-id>
+os connection test --workspace example --connection dropbox/business
+```
+
+The default is App Folder, privately available to Files. Full Dropbox requires a
+separate saved connection, OAuth application and grant, plus an explicit existing
+folder; setup and testing only read provider state. Neither create command selects
+File storage. Full Dropbox cannot be a File store. Its declared root is the base
+path trusted routines must use, not provider-enforced token containment. Routine
+Dropbox calls change provider data immediately, independently of publication.
+Disconnect prevents new delivery but does not revoke an already delivered token.
+The operator must register and configure separate App Folder and Full Dropbox
+applications on the OS service. The application mode is that verified backend
+registration, never an inference from Dropbox account namespace metadata.
+Missing Full Dropbox setup refuses only that setup path; it does not disable App
+Folder authorization.
+
 Sign-in and session operations use `https://auth.oddington.ai`. Connection
 management, repository targets, local app repository context, Dropbox authorization,
 remote File-storage configuration and Routine deployment use `https://api.oddington.ai`. These addresses are fixed; workspace
-configuration and `ODDINGTON_OS_ORIGIN` do not override them.
+configuration and `OS_ORIGIN` do not override them.
 
 Connection use is the canonical `POST /workspaces/<workspace>/connections/use`
 operation on the API host. The verified member or retained Run supplies authority;
 the request names the Connection and exact Run ID. Hosted ad hoc execution needs
-both `ODDINGTON_CONNECTION_RUN_TOKEN` and `ODDINGTON_CONNECTION_RUN_ID`.
+both `OS_CONNECTION_RUN_TOKEN` and `OS_CONNECTION_RUN_ID`.
 Inbox publication goes directly to the selected workspace's `/api/inbox/check`,
 `/api/inbox/publish`, `/api/inbox/resolve` and `/api/inbox/files` operations.
 Data and shared Files go directly to their OS owners. Local publication validates
@@ -320,7 +343,7 @@ Never put credentials in command arguments, logs, or issues. `inspect`, `list`,
 and other CLI output never reveal saved credentials.
 
 `os run` passes a short-lived credential to the child process in
-`ODDINGTON_CONNECTION_CREDENTIAL`. Only run trusted code, and do not print or
+`OS_CONNECTION_CREDENTIAL`. Only run trusted code, and do not print or
 retain that value.
 
 ## Deploy routines
@@ -586,7 +609,7 @@ or attach anything. CSV parsing hints (`csv.encoding`, `csv.delimiter`,
 and verified PDF pages. Unsupported files remain preserved and downloadable.
 
 Member-authored files may use `workingRoot` in the SDK, `--working-root` on the
-file command, or `ODDINGTON_INBOX_WORKING_ROOT`. Named routine Runs receive
+file command, or `OS_INBOX_WORKING_ROOT`. Named routine Runs receive
 their resolved worktree root from OS. The file command defaults to the current directory:
 
 ```sh
@@ -615,7 +638,7 @@ the File; delete that use through its owning capability first. Read access does
 not allow deleting another member's or an installed routine's File.
 
 The command uses the published SDK and the CLI member session. Configured
-`ODDINGTON_FILES_ROOT` selects the existing managed local owner, including
+`OS_FILES_ROOT` selects the existing managed local owner, including
 uploaded-cache cleanup. Success means physical cleanup and durable completion;
 repeating a completed command succeeds. Temporary failures remain retryable,
 and a pending File stays inaccessible. R2 cleanup removes only the exact pinned