frontpage-host 0.3.5 → 0.3.6

package/AGENTS.md

@@ -284,14 +284,14 @@ See [MAIL.md](./MAIL.md) for the complete save contract, reusable people picker
 
 Rule placement: read a rule revision, then use `people workspace rules.place` with `id`, `owner` and `expectedRevision`. This only organizes the rule; it does not change its trigger or execution. New UI rules/attachments save paused. Generic attachment calls still need explicit `enabled:false` for paused creation. Saved optional conditions and exact duration minutes remain supported through CLI and agent calls.
 
-The workspace validates and saves unfinished group settings before opening email setup. CLI and agent callers use `groups.create` / `groups.update` with a stable `requestKey` before attaching; `groups.count` reads the full visible match count. Group details Email and stage email tasks use the existing `frontpage mail save` / `save_mail_editor` completion. `attachment` checks saved group/stage emailVersion, creates paused rules, supports shared-template edits with rule revisions, and recovers identical retries. Read MAIL.md, Group and stage email tasks. Template get includes ruleUsage; deletion protects paused and active rule dependencies. Creating or saving never activates, enrolls or sends.
+Create the group before email setup. Existing group name/color edits save independently; membership edits apply only through Apply changes. X and Cancel discard unapplied membership edits immediately without a prompt. Activate/Pause and stage/rule saves do not require a group save. CLI and agent callers use `groups.create` / `groups.update` with a stable `requestKey` before attaching; `groups.count` reads the full visible match count. Group details Email and stage email tasks use the existing `frontpage mail save` / `save_mail_editor` completion. `attachment` checks saved group/stage emailVersion, creates paused rules, supports shared-template edits with rule revisions, and recovers identical retries. Read MAIL.md, Group and stage email tasks. Template get includes ruleUsage; deletion protects paused and active rule dependencies. Creating or saving never activates, enrolls or sends.
 
 ### People workspace navigation and selection
 
 People CRM has People and Groups tabs. Group details has Group details, Stages and Rules tabs. Group-entry emails remain rules with the same IDs. Stage Manage rules supports creating, placing, or attaching email without changing execution when placement changes. New attachments save paused.
 
-For a manual group, `groups.people` accepts `availability: "all" | "available" | "member"` through `--data`. The server applies saved membership before counts and paging. This filter never grants or requires email permission. In the UI, conditional groups use condition preview instead of manual additions. Existing explicit owner-exception operations stay available through the advanced service.
+For a manual group, `groups.people` accepts `availability: "all" | "available" | "member"` through `--data`. The server applies saved membership before counts and paging. This filter never grants or requires email permission. In the UI, conditional groups link to the People list filtered to that group instead of offering manual additions. Existing explicit owner-exception operations stay available through the advanced service.
 
-Before a reviewed `groups.update`, read `groups.list` and pass its `emailVersion` as optional `expectedGroup`. A 409 means the saved settings changed; read and review again before writing. Membership counts do not change this version. For the UI's Add people CSV behavior, pass `manualGroupsOnly:true` to `import.start`. The job keeps this choice and reports rows if a destination becomes conditional before processing; it never creates an include exception from that request. Retry with the same accepted key/payload, and inspect the saved job. Existing explicit advanced imports keep their prior contract when the option is omitted.
+`groups.update` supports optional expectedFields comparisons for independent label/color/mode/conditions/archivedAt edits; pass the original saved field values with the patch and a stable requestKey. A known absence of purchases is a non-match for last-purchase date conditions, not unknown. Before a reviewed `groups.update`, read `groups.list` and pass its `emailVersion` as optional `expectedGroup`. A 409 means the saved settings changed; read and review again before writing. Membership counts do not change this version. For the UI's Add people CSV behavior, pass `manualGroupsOnly:true` to `import.start`. The job keeps this choice and reports rows if a destination becomes conditional before processing; it never creates an include exception from that request. Retry with the same accepted key/payload, and inspect the saved job. Existing explicit advanced imports keep their prior contract when the option is omitted.
 
 Complete Store edits: use existing items update --file with changed fields and variantUpdates. stock requires expectedStock from a fresh items get. One transaction saves all changes or none. On 409 review current stock; never silently substitute it. firstVariant plus optionNames enables versions. Keep explicit stock/variant commands for single operations. Routines add accepts --request-id UUID; reuse that ID and exact schedule after a lost response. Ordinary form edits live only in the active task; Cancel keeps input, Discard loses unfinished input. Submitted payments, imports, builds, and API-key status are separate operations.

package/MAIL.md

@@ -35,7 +35,7 @@ The workspace's Back button returns to the source series. If template edits are
 
 Group details has an Email section. It shows ordinary rules whose actual trigger is someone joining that group and whose actions send a template or start a series. It uses the same records as Rules. Saved conditions and extra actions stay visible. Moving a rule's placement does not change where it runs.
 
-Use the shared Add email control to select a saved template, create a template, or use a saved series. Stage Manage rules uses the same template task. With unsaved group edits, the workspace labels the action **Save group & add email**. Choosing an action validates and saves the group before opening the picker or editor. Missing conditions stay on the group page with an error. A failed group save retains the inputs and does not navigate. Canceling email setup leaves the group saved without a new attachment. Creating or attaching saves one **paused** rule with no extra conditions. A notice beside attached paused emails says to click Activate. Nothing activates, enrolls or sends until the owner explicitly activates the rule for future events. The older `attachments.create` operation keeps its documented defaults; the new completion below always creates paused rules.
+Use the shared Add email control to select a saved template, create a template, or use a saved series. Stage Manage rules uses the same template task. Create the group first. Existing groups save name and color independently; membership edits stay inside How people join until Apply changes. Adding an email does not apply membership edits. Canceling email setup adds no attachment. Creating or attaching saves one **paused** rule with no extra conditions. The attached email notice explains that Activate turns it on for future people joining the group. Activate and Pause save immediately, without another group save. Nothing activates, enrolls or sends merely from attachment. The older `attachments.create` operation keeps its documented defaults; the completion below always creates paused rules.
 
 The existing command and agent operation handle the complete save:
 
@@ -67,7 +67,7 @@ The response returns `complete:true`, `document` and `rule`. Repeating the same
 
 To attach an existing source, omit `document`. Add either `attachment.templateId` or `attachment.seriesId` and its `expectedSourceUpdatedAt` from a fresh template/series get. A series needs at least one saved step. The result includes the source and paused rule. To edit shared content from an existing entry rule, supply the existing document with `expectedUpdatedAt`, plus `attachment.ruleId` and `expectedRevision` from `rules.get`. This saves the content while leaving the rule's conditions, actions, version, enabled state, activation time and history unchanged. Stale group, stage, source or rule checks return a conflict; keep the draft and review the saved records before making a revised request.
 
-The workspace uses the existing template editor and returns to the source group or Stages after Save email & attach to group. Unfinished group, rule, stage, picker and template edits stay in memory only. Leaving uses the shared unsaved-changes modal: Cancel keeps editing; Discard and continue loses those edits and leaves without a network request. Refresh or closing the tab discards unfinished work without a browser prompt. Clean navigation and opening saved records show no warning. There is no editor backup or Recover save action. A template task keeps its source context in memory during the active flow; a refreshed task must be reopened from its source. A self-test sends only test content and does not complete a pending group task. Retry a submitted save with the exact original key and payload after a lost response; this does not require an editor backup.
+The workspace uses the existing template editor and returns to the source group or Stages after Save email & attach to group. Unfinished group, rule, stage, picker and template edits stay in memory only. Closing the membership editor with X, Cancel, or Escape immediately discards its unapplied edits, without a confirmation. Other unfinished editors retain the shared unsaved-changes modal: Cancel keeps editing; Discard and continue loses those edits and leaves without a network request. Refresh or closing the tab discards unfinished work without a browser prompt. Clean navigation and opening saved records show no warning. There is no editor backup or Recover save action. A template task keeps its source context in memory during the active flow; a refreshed task must be reopened from its source. A self-test sends only test content and does not complete a pending group task. Retry a submitted save with the exact original key and payload after a lost response; this does not require an editor backup.
 
 Templates remain shared. Changes affect future uses; already queued messages keep their content snapshots. Template get exposes `ruleUsage`; the UI also shows rule usage beside existing dependencies. Deleting a template used by a live rule, including a paused rule, fails with a conflict naming the rule. Remove the template action or archive the rule first. Series, form and receipt dependencies still apply. Archiving a rule keeps its run history and saved actions. Never activate, enroll or send without the user's instruction.
 

package/PEOPLE.md

@@ -72,7 +72,7 @@ frontpage people groups archive --id GROUP_ID --site YOUR_SITE --json
 frontpage people groups restore --id GROUP_ID --site YOUR_SITE --json
 ```
 
-For a reviewed group edit, read `groups.list` and pass the saved `emailVersion` as `expectedGroup` through `--data` or `--file` with `groups.update`. The workspace does this automatically. A changed name, color, mode, conditions or archive state returns 409 before writing. Membership counts do not invalidate the version. Read the latest group and review the change before trying again; do not replace the version and silently overwrite another edit. The check is optional for existing API callers.
+For a reviewed group edit, read `groups.list` and pass the saved `emailVersion` as `expectedGroup` through `--data` or `--file` with `groups.update`. Email tasks use this full saved-configuration check. A changed name, color, mode, conditions or archive state returns 409 before writing. Membership counts do not invalidate the version. Read the latest group and review the change before trying again; do not replace the version and silently overwrite another edit. The check is optional for existing API callers. For an independent field edit, `groups.update` also accepts `expectedFields`, an object containing saved values for any of `label`, `color`, `mode`, `conditions`, and `archivedAt`. Only those fields are compared. Example: `{"id":"GROUP_ID","label":"New name","expectedFields":{"label":"Old name","archivedAt":null},"requestKey":"unique-name-save"}`. Omitted update fields keep their current saved values. A stale comparison returns 409 without writing. Review the latest saved values before submitting a revised edit; do not silently replace a failed comparison.
 
 ### Select people from a manual group
 
@@ -91,7 +91,7 @@ frontpage people workspace membership.addMany --file selected-people.json --site
 
 `groups.preview` accepts `limit` (1 to 200, default 200) and `cursor`, and returns `checked`, `unknown`, `matches` and `nextCursor`. A page can have no matches while more people remain to check. Counts describe the people checked so far, not saved membership. Match rows include phone as well as email. Pass `expectedConditions` with a saved group ID to reject a changed condition/mode between pages. Explicit `conditions` previews edits without saving them. Neither preview changes membership or sends emails.
 
-`groups.count` accepts a saved group `id` or explicit `conditions` and returns `matched`, `checked`, `unknown`, `complete` and `sendsNothing`. It counts all visible people in one consistent read; it does not return a sampled page. `unknown > 0` means the count is incomplete, never that those people do not match. It changes no memberships and sends no emails.
+`groups.count` accepts a saved group `id` or explicit `conditions` and returns `matched`, `checked`, `unknown`, `complete` and `sendsNothing`. It counts all visible people in one consistent read; it does not return a sampled page. `unknown > 0` means the count is incomplete, never that those people do not match. It changes no memberships and sends no emails. A known purchase count of zero means last-purchase date comparisons do not match; it is not an unavailable fact or a purchase today. Use purchaseCount equal to zero for people who have never purchased. Actual unavailable facts remain unknown. The workspace shows a simple count for a complete result and a retry message for a failed or incomplete count.
 
 ```sh
 frontpage people groups count --file repeat-buyers.json --site YOUR_SITE --json
@@ -99,9 +99,9 @@ frontpage people groups count --file repeat-buyers.json --site YOUR_SITE --json
 
 Both `groups.create` and `groups.update` accept `requestKey` (1–120 characters). Retry an uncertain save with exactly the same key and payload to receive the original saved group without another write. Changing the payload with that key returns a conflict. Keep `expectedGroup` unchanged on a retry; a confirmed new edit uses a new key.
 
-A conditional group must have at least one complete condition. In the workspace, Save group and Save group & add email use the same validation. An incomplete group stays on its page with a field error. A valid save-and-email action saves the group before opening the email editor or picker. Saving the new email attaches its paused rule and returns to the saved group. Canceling a new email leaves the saved group without that attachment. Membership never grants email permission.
+A conditional group must have at least one complete condition. The workspace creates a new group through Create group before email, stage, or rule setup. Existing groups have no page-wide Save group button: valid names save when editing finishes, colors save on selection, and How people join opens a separate editor. Apply changes saves complete membership settings together. X, Cancel, or Escape discards unapplied membership edits and closes immediately without another prompt. The backdrop does not close that editor. A save in progress must finish before closing. Other unfinished forms retain their existing navigation protection. Activate and Pause save immediately; stages and rules use their own editor saves. A name edit does not disable these independent actions. Saving a new email attaches a paused rule and returns to the saved group. Canceling email setup adds no attachment. Membership never grants email permission.
 
-When changing to **Match conditions**, membership will update to match the conditions, and some people may join or leave. When changing to **Add people**, current members stay and the group stops updating from conditions. Existing exceptions, saved pauses, stages and history stay saved. The UI shows this effect before Save and does not add a confirmation step.
+When changing to **Match conditions**, membership will update to match the conditions, and some people may join or leave. When changing to **Add people**, current members stay and the group stops updating from conditions. Existing exceptions, saved pauses, stages and history stay saved. The membership editor shows this effect before Apply changes and adds no second confirmation.
 
 ### Keep a group matched to conditions
 

package/dist/registry.js

@@ -490,7 +490,7 @@ export const COMMANDS = [
         ],
         flags: [
             "Workspace: groups list|get|people|create|update|archive|restore|preview|count; stages create|update|reorder|archive|restore; membership get|add|addMany|remove|move|stage|advance|override|hold; rules list|get|create|update|place|enable|pause|archive|validate|preview|runs|retry; attachments create; import preview|start|get|retry; person permission|lookup|activity|update; audience preview; overview; sources. Use workspace notes.add|template.campaign|series.preview|series.enrol for the remaining shared operations.",
-            "groups count checks all visible people without changing membership. groups create/update accept --request-key for exact retries and expectedGroup through JSON for stale-save checks. Keep the original key and payload after an uncertain save.",
+            "groups count checks all visible people without changing membership. groups create/update accept --request-key for exact retries and expectedGroup or field-scoped expectedFields through JSON for stale-save checks. Known absence of purchase history does not match last-purchase date conditions. Keep the original key and payload after an uncertain save.",
             "All workspace operations accept --file JSON or --data JSON. Named flags: --id --label --name --group --stage --person --from-group --mode --color --position --terminal --enabled --hold --allowed --archived --reset --override include|exclude|auto --email-kind template|series --email-id --rule --run --cursor --limit --request-key. Boolean flags take true|false. Complex conditions/actions/mappings use JSON.",
             "CSV: --csv PATH plus --file mapping.json. New contacts default to allowed; JSON emailPermission can select unknown or not_allowed. Row values override the list choice; saved refusals, unsubscribes and suppressions remain protected. import start requires a stable --request-key. Retry the same import with the same key and contents.",
             "list/export: --group GROUP_ID --stage STAGE_ID. See package PEOPLE.md for full examples and every JSON shape.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "frontpage-host",
-  "version": "0.3.5",
+  "version": "0.3.6",
   "description": "Frontpage CLI \u2014 manage your site from the terminal",
   "type": "module",
   "bin": {