@@ -6,7 +6,7 @@ import chalk from 'chalk'
 import type { Command } from 'commander'
 import { clientFrom } from '../context.js'
 import type { QueryRowsResponse } from '../generated/v2-api.js'
-import { SimApiError } from '../http/client.js'
+import { SimApiError, type SimClient } from '../http/client.js'
 import { type Column, printList, sanitize, text } from '../output/render.js'
 
 /**
@@ -149,25 +149,101 @@ function contentTypeFor(name: string): string {
   return CONTENT_TYPES[extension] ?? 'application/octet-stream'
 }
 
-/** The route's own ceiling. Checked here so a 100 MB body is never sent to be refused. */
-const MAX_UPLOAD_BYTES = 100 * 1024 * 1024
+interface UploadPartUrl {
+  partNumber: number
+  url: string
+  headers: Record<string, string>
+}
+
+interface FileUpload {
+  id: string
+  size: number
+  partSize: number
+  partCount: number
+  uploadToken: string
+  file: { id: string } | null
+}
+
+/** The parts endpoint signs at most this many URLs per request. */
+const PART_URL_BATCH = 100
+
+/**
+ * Sends every part of a file to the storage URLs the API signs for it, and
+ * returns what `complete` needs to reassemble them.
+ *
+ * URLs are requested in batches because each one is short-lived: signing all
+ * 640 possible parts up front would leave the last ones expired by the time a
+ * slow connection reached them.
+ *
+ * Parts go out one at a time. Concurrency would be faster, but a failure
+ * mid-flight has to abort the whole upload anyway, and a sequential loop makes
+ * "which part failed" unambiguous.
+ */
+async function uploadParts(
+  client: SimClient,
+  workspaceId: string,
+  upload: FileUpload,
+  blob: Blob
+): Promise<Array<{ partNumber: number; etag?: string }>> {
+  const completed: Array<{ partNumber: number; etag?: string }> = []
+
+  for (let first = 1; first <= upload.partCount; first += PART_URL_BATCH) {
+    const partNumbers = []
+    for (let n = first; n < first + PART_URL_BATCH && n <= upload.partCount; n++) {
+      partNumbers.push(n)
+    }
+
+    const signed = await client.request<{ data: { parts: UploadPartUrl[] } }>(
+      `/api/v2/files/uploads/${encodeURIComponent(upload.id)}/parts`,
+      {
+        method: 'POST',
+        query: { workspaceId },
+        headers: { 'upload-token': upload.uploadToken },
+        body: { partNumbers },
+      }
+    )
+
+    for (const part of signed.data.parts) {
+      const start = (part.partNumber - 1) * upload.partSize
+      // `Blob.slice` is a view over the file on disk, so only the part being
+      // sent is ever read — the point of not buffering the upload.
+      const chunk = blob.slice(start, Math.min(start + upload.partSize, upload.size))
+
+      // boundary-raw-fetch: storage-signed URL on another origin, not the API
+      const response = await fetch(part.url, {
+        method: 'PUT',
+        headers: part.headers,
+        body: chunk,
+      })
+      if (!response.ok) {
+        throw new SimApiError(
+          `Part ${part.partNumber} failed with status ${response.status}`,
+          response.status
+        )
+      }
+
+      // S3-compatible stores identify a part by the ETag they return; the API
+      // treats it as optional because not every backend sends one.
+      const etag = response.headers.get('etag')?.replace(/"/g, '')
+      completed.push(etag ? { partNumber: part.partNumber, etag } : { partNumber: part.partNumber })
+    }
+  }
+
+  return completed
+}
 
 export function attachHandWritten(program: Command): void {
-  // ── files upload ── multipart, which the generated flag surface cannot express ──
+  // ── files upload ── a presigned multipart handshake, not one request ──────
   group(program, 'files')
     .command('upload <path>')
     .description('Upload a file to the workspace')
     .option('--folder-id <id>', 'Target folder (defaults to the workspace root)')
     .option('--name <name>', 'Store it under a different name')
     .action(
       async (path: string, options: { folderId?: string; name?: string }, command: Command) => {
-        const { client, profile } = clientFrom(command)
+        const { client } = clientFrom(command)
         const workspaceId = client.requireWorkspace()
 
-        if (!profile.apiKey) {
-          throw new SimApiError(`Not logged in on profile "${profile.name}". Run: sim login`, 0)
-        }
-
         let size: number
         try {
           const stats = await stat(path)
@@ -178,43 +254,54 @@ export function attachHandWritten(program: Command): void {
           throw new SimApiError(`Cannot read ${path}: ${(error as Error).message}`, 0)
         }
 
-        // Fail here rather than after streaming 100 MB the server will reject.
-        if (size > MAX_UPLOAD_BYTES) {
-          throw new SimApiError(
-            `${path} is ${(size / 1024 / 1024).toFixed(1)}MB; the limit is 100MB`,
-            0
-          )
-        }
+        // The server sizes its own parts, but it cannot reject an empty file any
+        // more cheaply than we can: a zero-byte upload has no parts to send.
+        if (size === 0) throw new SimApiError(`${path} is empty`, 0)
 
         const name = options.name ?? basename(path)
-        const url = new URL(`${profile.endpoint}/api/v2/files`)
-        url.searchParams.set('workspaceId', workspaceId)
-        if (options.folderId) url.searchParams.set('folderId', options.folderId)
-
-        // `openAsBlob` keeps the file on disk and reads it as the request is
-        // written; building a Buffer first would hold the whole upload in memory.
-        const body = new FormData()
-        body.append('file', await openAsBlob(path, { type: contentTypeFor(name) }), name)
 
-        const response = await fetch(url, {
+        const created = await client.request<{ data: FileUpload }>('/api/v2/files/uploads', {
           method: 'POST',
-          headers: { 'x-api-key': profile.apiKey },
-          body,
+          body: {
+            workspaceId,
+            name,
+            contentType: contentTypeFor(name),
+            size,
+            ...(options.folderId ? { folderId: options.folderId } : {}),
+          },
         })
+        const upload = created.data
 
-        const payload = (await response.json().catch(() => null)) as {
-          data?: { id?: string }
-          error?: { message?: string }
-        } | null
+        // Any failure past this point leaves an upload holding storage, so the
+        // rest runs under an abort that the server also uses to release it.
+        try {
+          const blob = await openAsBlob(path)
+          const parts = await uploadParts(client, workspaceId, upload, blob)
 
-        if (!response.ok) {
-          throw new SimApiError(
-            payload?.error?.message ?? `Upload failed with status ${response.status}`,
-            response.status
+          const completed = await client.request<{ data: FileUpload }>(
+            `/api/v2/files/uploads/${encodeURIComponent(upload.id)}/complete`,
+            {
+              method: 'POST',
+              query: { workspaceId },
+              headers: { 'upload-token': upload.uploadToken },
+              body: { parts },
+            }
+          )
+          console.log(
+            chalk.green(`✓ Uploaded ${name} (${completed.data.file?.id ?? completed.data.id})`)
           )
+        } catch (error) {
+          await client
+            .request(`/api/v2/files/uploads/${encodeURIComponent(upload.id)}`, {
+              method: 'DELETE',
+              query: { workspaceId },
+              headers: { 'upload-token': upload.uploadToken },
+            })
+            // The original failure is what the caller needs; a failed cleanup
+            // must not replace it with a message about the cleanup.
+            .catch(() => undefined)
+          throw error
         }
-
-        console.log(chalk.green(`✓ Uploaded ${name} (${payload?.data?.id ?? 'unknown id'})`))
       }
     )
 
 
@@ -50,6 +50,13 @@ export const CLI_CONTRACT: CliContract = {
   deleteCredential: {
     confirm: 'This deletes the credential; anything authenticating with it stops working.',
   },
+  deleteWorkflow: { confirm: 'This deletes the workflow and its run history.' },
+  deleteTableView: { confirm: 'This deletes the saved view and its filters.' },
+  deleteWorkflowGroup: {
+    // Not just the grouping: the documented behaviour is that every column the
+    // group fed goes with it, values included.
+    confirm: 'This deletes the group, every column it fed, and the values in them.',
+  },
   deleteFolder: {
     // The route archives the folder *and cascades to its contents*, so this is
     // the broadest delete on the surface — the message says so rather than
@@ -243,6 +250,40 @@ export const CLI_CONTRACT: CliContract = {
     describe: 'Enable or disable sharing for a file',
   },
 
+  // ─── The expanded tables surface ──────────────────────────────────────────
+  // `/cancel-runs`, `/rows/find`, `/restore`, `/columns/run` and the enrichment
+  // path all put a verb where the deriver expects a sub-resource, so each became
+  // a group holding a lone `create`.
+  cancelTableRuns: { command: 'tables cancel-runs', describe: 'Stop every running column job' },
+  findTableRows: { command: 'tables rows find', describe: 'Find rows matching a predicate' },
+  restoreTable: { command: 'tables restore', describe: 'Restore a deleted table' },
+  runTableColumn: { command: 'tables columns run', describe: 'Run a column’s workflow' },
+  runRowEnrichment: {
+    command: 'tables rows enrich',
+    describe: 'Run one row’s enrichment group',
+  },
+
+  // Transfers are a handshake: create, request part URLs, send the parts, then
+  // complete. Unlike `files upload` there is no single command driving this yet
+  // — the import body carries source/target/mapping choices a one-liner cannot
+  // express — so each step stays reachable under a name that says what it is.
+  createTableImport: { command: 'tables imports create' },
+  createTableImportPartUrls: {
+    command: 'tables imports parts',
+    describe: 'Sign upload URLs for a batch of parts',
+  },
+  completeTableImport: {
+    command: 'tables imports complete',
+    describe: 'Finish an import once every part is uploaded',
+  },
+  cancelTableImport: { command: 'tables imports cancel' },
+  cancelTableExport: { command: 'tables exports cancel' },
+  tableExportDownload: {
+    // GET, but it returns a signed URL rather than a listing.
+    command: 'tables exports download',
+    describe: 'Get the download URL for a finished export',
+  },
+
   // ─── Documents, not records ───────────────────────────────────────────────
   // The payload is the artifact: `sim workflows export <id> > wf.json` has to
   // produce something `sim workflows import` accepts back.
@@ -280,8 +321,18 @@ export const CLI_CONTRACT: CliContract = {
   },
 
   // ─── Not a terminal-shaped operation ──────────────────────────────────────
-  // Multipart upload; `sim files upload <path>` needs its own file-reading
-  // command rather than a generated flag surface.
-  uploadFile: { hidden: true },
+  // Multipart upload; `sim knowledge documents upload <path>` would need its own
+  // file-reading command rather than a generated flag surface.
   uploadKnowledgeDocument: { hidden: true },
+
+  // ─── Steps of a transfer, not commands ────────────────────────────────────
+  // Uploading is now a presigned multipart handshake: create the upload, ask for
+  // part URLs in batches, PUT each part to storage, then complete with the
+  // ETags — and abort if any of it fails. Exposing the steps individually would
+  // advertise a protocol whose halfway states leak storage, so `sim files
+  // upload` drives the whole sequence and these stay out of the surface.
+  createFileUpload: { hidden: true },
+  createFileUploadPartUrls: { hidden: true },
+  completeFileUpload: { hidden: true },
+  abortFileUpload: { hidden: true },
 }