# Fireflax automation handover and recovery worksheet Version 1.0.0 · reviewed 8 October 2026 · MIT licence for this template. Maintenance owner for the template: Fireflax repository maintainers; no individual ongoing support or response time is promised. Your workflow needs its own named owner below. This is an editable Markdown document: save a copy and replace the brackets. No signup or customer data is required. ## Blank worksheet | Item | Your record | | -------------------------------------- | ------------------------------------------------------------------------------------------------- | | Workflow and purpose | [one bounded workflow] | | Version, change record and review date | [version / changes / date] | | Process owner and backup | [actual names and agreed coverage] | | Technical maintenance owner | [actual name] | | Next maintenance review | [agreed date; check sooner after a change] | | Trigger and allowed sources | [what starts work; how unwanted input is rejected] | | Connected systems and environments | [source / destination / test or live] | | Account and permission owner | [person who can grant/revoke access] | | Credential location reference | [vault item/reference only; NEVER paste a key, password or token] | | Input/output field mapping | [exact field IDs, required values and record types] | | Normal operating assumptions | [coverage, volume, time zone, source availability and response expectations] | | One request's durable identifier | [how an incoming request and each intended effect are identified] | | Duplicate/update behavior | [repeat delivery versus new request; changed fields; comparison scope] | | Approval boundary | [what needs review; who can approve; what invalidates approval] | | Monitoring owner and location | [person / view or log / agreed check frequency] | | Evidence of success | [specific destination record or acknowledged intended effect; not merely a green upstream step] | | Evidence of failure/uncertainty | [missing confirmation, blocked state, mismatch and where retained] | | Pause owner and exact procedure | [name / steps / what stops / any in-flight actions that continue] | | Escalation and backup | [actual names / channel / agreed coverage] | | Recovery owner and checks | [name / inspect source and destination / distinguish done, not done and unknown] | | Retry rule and authorizer | [what may repeat; deduplication check; when fresh approval is required] | | Resume procedure | [explicit steps; what will and will not replay] | | Reversible internal changes | [changes that can actually be restored; backup/reference] | | Irreversible/external effects | [messages already sent, bookings, external writes; what cannot be unsent or automatically undone] | | Rollback limits | [what reset/rollback does NOT reverse; compensating action owner] | | Retained evidence | [version, synthetic test inputs, expected/observed results, reviewer and date] | | Unresolved risks and owner | [unknown / person / next action; do not mark accepted while required checks are missing] | | Handover acceptance | [operator name / rehearsal date / observed result / explicit acceptance] | Recovery checklist: 1. Pause the relevant workflow using the agreed procedure. Preserve the failed state and logs. 2. Identify the request and intended action. Check what the destination actually received or changed. 3. Classify the outcome as done, not done or uncertain. Do not resend blindly when uncertain. 4. Resolve the cause with the permission/technical owner. Check credentials by reference without copying secrets into this worksheet. 5. Confirm duplicate protections and whether the old approval is still valid. Obtain fresh review where required. 6. Resume only the intended action. Verify its result in the destination and record the evidence. 7. Close or escalate the incident, then update the change log and next review date. ## Filled fictional rehearsal: Northstar Plumbing This example is for the **offline Fireflax enquiry-routing starter 1.0.0**, not a connected business. Morgan and Riley below are fictional operators, not Fireflax staff or assigned support contacts. The browser demo has different storage/pause behavior; it keeps state in memory and has no CLI pause command. | Item | Example record | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Purpose/version | Rehearse one incoming enquiry, owner assignment, reviewed draft and recorded outcome; starter 1.0.0 | | Process/maintenance owner | Morgan, fictional coordinator; Riley, fictional backup and technical owner | | Permissions and credentials | Operator can run Node and read/write the extracted local folder; no customer systems or credentials | | Trigger | Operator explicitly runs `node cli.mjs submit fixtures/new-job.json` | | Inputs/outputs | Synthetic name/email/area/message → local queue record, category, owner, draft, reviewed outcome/history | | Operating assumption | One operator/process at a time, Node 22.23.2 tested, at most 20 sample enquiries | | Storage | `sample-state.json` in the current directory; temporary local rehearsal data, not a secure production record store | | Duplicate behavior | Same normalized email + area + message returns same record. Changing message/area may create a second record. Reset removes this memory | | Approval | Read/edit `reviewed-reply.txt`; explicit `approve` or `fail` command. Restore clears prior approval | | Monitoring | Morgan reads `node cli.mjs show` after each rehearsal step; this is not continuous monitoring | | Success check | One expected local record with intended status and approved text; no external effect exists | | Failure check | `blocked` retains draft, approved text and history; owner inspects it | | Pause | Morgan runs `node cli.mjs pause`. Future submit/approve/fail/restore commands exit without changing the state. No background work exists | | Recovery | Riley inspects state; Morgan explicitly resumes, restores and approves again after review | | Reset/rollback | `node cli.mjs reset` removes the local state. It cannot unsend a message or reverse any external action; this package has no such effects | | Change log | 1.0.0, 8 October 2026: first offline rehearsal package and worksheet | | Next review | [Actual adopting operator fills date before use]; no ongoing schedule is established by this example | | Acceptance | [Different operator records their actual rehearsal result]; author checks do not fill this field for them | ## Rehearsal a second operator can follow Extract the starter into a new folder. Use synthetic fixtures only. The README explains prerequisites and all commands. From that folder: ```sh node cli.mjs init node cli.mjs submit fixtures/new-job.json node cli.mjs show ``` Read the record and `reviewed-reply.txt`; edit that fictional reply if needed. Then: ```sh node cli.mjs fail DEMO-001 reviewed-reply.txt node cli.mjs pause node cli.mjs show node cli.mjs restore DEMO-001 ``` Expected: one blocked record retains the reviewed text. The restore attempt while paused must fail, with no state change. This is an intentional negative check, not a broken connection. To recover: ```sh node cli.mjs resume node cli.mjs restore DEMO-001 node cli.mjs show ``` Expected: `review`, draft retained, `approvedDraft: null`. Read the record/reply again, then: ```sh node cli.mjs approve DEMO-001 reviewed-reply.txt node cli.mjs show ``` Expected: one `completed` record with the freshly approved text. Record your version, date, commands, outcomes and unresolved differences in the acceptance field. `node cli-check.mjs` is an automated check of this local sequence; it does not replace an operator's manual inspection and acceptance. ## Limits No network connector, sending, live retry, exactly-once guarantee, uptime claim or customer result is demonstrated. In a connected workflow, a destination may have acted before a confirmation was lost. That uncertainty is absent from this local failure simulation and must be checked separately before a real retry. External effects need their own identifiers, evidence and recovery policy.