@siteoshq/cli 1.3.0 → 1.5.0

package/README.md

@@ -231,3 +231,53 @@ A report records the revision, runtime, observed Edge location, scenario scope a
 The check covers one route and a bounded observation window, not hidden first-party/server-side
 tracking, every delayed interaction, visual accessibility or legal compliance. Repeat after
 website/publication changes and preserve a separate GTM Tag Assistant check where applicable.
+
+### Forms inbox
+
+Use `siteos forms submissions list --environment <slug> --form <form-id> --json` to search complete
+history. Filters include `--query`, `--status`, `--from`, `--to`, `--limit` (1–100), and `--cursor`.
+The response contains the filtered total and a continuation cursor. Full answers and the saved
+version's labels are available with `siteos forms submissions read --environment <slug> --form
+<form-id> --submission <id> --json`.
+
+`siteos forms submissions status --environment <slug> --form <form-id> --submission <id> --status
+read --expected-status new --json` changes status without overwriting concurrent triage. Statuses
+are `new`, `read`, `archived`, and `spam`. These management commands require the matching Forms inbox
+server release. They use the selected common Project/environment and a scoped Auth grant.
+`forms definition check` compiles the schema locally using the same strict Ajv policy as sync.
+
+### Form archive and deletion
+
+These commands require the lifecycle API on the selected server. Owner/admin rights are required
+for changes; members can list and read. Read a form to obtain its current revision before changing it.
+
+```sh
+siteos forms definition list --environment production --status all --json
+siteos forms definition read --environment production --form <form-id> --json
+siteos forms definition archive --environment production --form <form-id> --expected-revision <revision> --json
+siteos forms definition restore --environment production --form <form-id> --expected-revision <revision> --json
+siteos forms definition delete --environment production --form <form-id> --json
+siteos forms definition delete --environment production --form <form-id> --apply --confirm <form-key> --expected-revision <revision> --expected-submissions <count> --json
+```
+
+Delete without `--apply` only previews the exact Project, Environment, form and submitted-answer
+count. Use the values from that reviewed preview when applying; a stale revision or count conflicts.
+Archive stops new submissions and preserves history. Delete permanently removes versions and
+answers from the working database, retaining only a reserved-key tombstone. That form key cannot be
+reused. Shared Environment credentials remain active for other forms. Sync refuses archived/deleted
+keys and never removes forms missing from a local manifest. Backups follow deployment retention;
+they are not an in-app restore mechanism.
+
+### Automatic Forms deployment
+
+Generate Forms JSON from the shared host validation schema during build. Install a release-only
+key once with `siteos forms deployment-key issue --environment production --install --json`.
+Store `SITEOS_FORMS_DEPLOYMENT_KEY` in the CI secret store and configure explicit
+`SITEOS_FORMS_PUBLIC_URL`. Keep the submission credential on the website server.
+
+Run `siteos forms deploy --manifest .siteos/forms/manifest.json --json` before routing traffic to a
+new release. This needs no interactive Auth or local Project state and publishes atomically.
+Definitions include a generated SHA-256 `sourceExportId`; runtime sends it as `contractVersion`.
+A changed field requires a normal build/release, not a second hand-edited validation schema.
+`forms deployment-key list|revoke` manages release keys; submission keys cannot publish.
+See the SiteOS Forms skill for the portable generator and version serialization contract.