wawesome 0.6.0 → 0.8.0

package/README.md

@@ -106,6 +106,11 @@ npx wawesome deploy
 | `npx wawesome logs [func]`              | List recent past invocations for a function                         |
 | `npx wawesome logs --invocation <id>`   | Fetch full stdout/stderr log body for a specific invocation         |
 | `npx wawesome logs <func> --follow`     | Follow live output (waits for the next invocation if needed)        |
+| `npx wawesome invoke [func]`            | Fire a function run immediately and follow its output live          |
+| `npx wawesome cron [func]`              | List schedules for a function or app                                |
+| `npx wawesome cron pause <name>`        | Pause a schedule by name (survives future deploys)                  |
+| `npx wawesome cron resume <name>`       | Resume a paused schedule (no backfill)                              |
+| `npx wawesome cron history [func]`      | Read background run history for scheduled and manual runs           |
 | `npx wawesome version list`             | List version history for the current function                       |
 | `npx wawesome version switch <v>`       | Roll back or promote a specific function version                    |
 | `npx wawesome env list`                 | View environment variables for the current app                      |
@@ -203,6 +208,77 @@ exponential back-off (up to 3 retries). Non-recoverable errors like authenticati
 
 ---
 
+## ⚡ Manual Invocation
+
+Fire a background run of a Function immediately without waiting for a schedule tick or deploying code:
+
+```bash
+# Invoke the function in the current directory and follow its output
+npx wawesome invoke
+
+# Invoke a specific function by name
+npx wawesome invoke my-function
+
+# Send custom HTTP method and request body
+npx wawesome invoke -m POST -d '{"event":"audit"}'
+
+# Fire without following live output
+npx wawesome invoke --no-follow
+```
+
+---
+
+## ⏰ Schedules & Cron Management
+
+Manage recurring Schedules and inspect background run history directly from your terminal.
+
+### 1. List Schedules
+
+List a Function's Schedules with expression, state, and next run in UTC:
+
+```bash
+# List schedules for the function in the current directory
+npx wawesome cron
+
+# List schedules for a specific function
+npx wawesome cron list my-function
+
+# List schedules across all functions in an App
+npx wawesome cron list --app my-app
+```
+
+The output clearly distinguishes the three off-states:
+- `paused`: stopped by a user, resumable with `wawesome cron resume <name>`
+- `not in this config file`: disabled because it was removed from configuration, resumable only by declaring it again in code
+- `suspended`: suspended by the non-payment ladder, resumable only after settling workspace balance
+
+### 2. Pause and Resume Schedules
+
+```bash
+# Pause a schedule by name (stops queued ticks and survives future deploys)
+npx wawesome cron pause nightly-reconcile
+
+# Pause with an optional reason for incident context
+npx wawesome cron pause nightly-reconcile --reason "database maintenance"
+
+# Resume a paused schedule (recomputes next run from now, no catch-up backfilling)
+npx wawesome cron resume nightly-reconcile
+```
+
+### 3. Read Run History
+
+Inspect past scheduled and manual runs, showing when each run was due, when it started, pool delay, and how it ended:
+
+```bash
+# View run history for the current function
+npx wawesome cron history
+
+# Filter run history by state (pending, running, dispatched, skipped, missed, cancelled, lost, failed)
+npx wawesome cron history my-function --state failed
+```
+
+---
+
 ## ⚙️ Configuration & Custom Gateway
 
 ### `wawesome-function.json`
@@ -220,6 +296,12 @@ Every project directory includes a `wawesome-function.json` file generated durin
 `app` is the App this Function is deployed into, and it is client-facing — every deploy from this
 directory is scoped to it.
 
+`function` is the address. Changing it does not rename anything: your Function's URL is built from
+its name, so the next deploy lands on a Function of its own and the old one stays live at the old
+URL, serving the code its callers already hold. The CLI remembers where this directory last
+deployed and asks before that happens, naming both URLs. If you meant it, delete the old Function
+from the dashboard once nothing calls it.
+
 Add `"assets"` to deploy static files beside your code:
 
 ```json
@@ -330,8 +412,9 @@ curl -X POST http://localhost:3000/x/my-tenant-slug/default-app/nightly-reconcil
   -H "x-wawesome-trigger: schedule"
 ```
 
-Because production strips the reserved header namespace inbound, a request that works locally
-provably cannot work against the Public address.
+Production strips the reserved header namespace inbound, so the same header against your App's own
+hostname reaches nothing that reads it: the run is a `caller`'s, and a private Function is a 404
+either way. Skipping your own authorization for a `schedule` run therefore opens nothing.
 
 Making a Function private takes nothing but the deploy. Making it public again does not: deleting
 the line is refused, and the deploy tells you so having written nothing.