# Review a Messenger operating record

Review one JSON record under `maestro-messenger-flow-v1`. Do not repair it silently. Preserve the source record exactly and report evaluated findings separately.

Reference: https://maestrogtm.com/facebook-messenger-ads/

## Planning checks

- `contract_id` is exact.
- Offer name, buyer, promise and conversation value are resolved.
- Destination is `messenger`, `instagram`, `whatsapp`, `lead_form`, `website` or `hold`, with a reason.
- Messenger has an opening, entry branch IDs and complete branches.
- Branch IDs are unique; every entry and next branch exists; no branch is unreachable; no cycle exists; every path ends in a stop or handoff.
- Response owner, coverage, accepted target, escalation and outside-coverage behavior are resolved.
- CRM system, destination, field map, duplicate rule, failure route and failure owner are resolved.

Treat only the complete normalized values `Unknown`, `None`, `N/A`, `Unavailable`, `Pending`, `TBD` and empty as unresolved. Do not reject a legitimate name merely because it contains one of those words.

## Native evidence checks

Review all eight keys: Page linkage, destination availability, permissions, policy approval, publication, delivery, reply and CRM arrival.

`Verified` passes only when all of these conditions hold:

- reference is a specific HTTPS URL, `meta://` reference or `receipt:` identifier with at least six non-space characters after the scheme;
- `observed_at` is a real, non-future UTC ISO 8601 timestamp such as `2026-10-07T00:00:00Z`; impossible calendar dates do not pass;
- owner is specific;
- note explains what the receipt proves.

Reject placeholders and vague values including `placeholder`, bare `receipt`, `tomorrow`, `somebody`, `proof` and empty notes. Planned, requested, pending, observed without proof and denied states remain held. `Not applicable` is invalid for these eight checks when Messenger is selected.

Create stable request IDs `MESSENGER-EVIDENCE-<KEY>`. Preserve any supplied request owner, reason and reference. If owner is missing, use `Owner assignment required`; do not invent a person.

## Exact decision precedence

1. Malformed record or invalid branch logic → `Hold for native evidence`.
2. Missing planning fields → `Hold for native evidence`.
3. Complete `instagram`, `whatsapp`, `lead_form` or `website` route with a reason → `Use another destination`.
4. Complete Messenger plan → `Ready for native setup`.

Native launch is separate and stays `Hold for native evidence` until all required receipts pass.

## Required response

Return a JSON object with:

- `contract_id`, `record_id`, `revision`;
- `source_record` unchanged;
- `planning_outcome` using one exact allowed label;
- `planning_missing`;
- `validation_findings`;
- `native_launch_state`;
- `evidence_requests` with stable ID, field, owner, supplied state, reason and exact request;
- `next_action`.

Do not invent results or upgrade evidence. Do not say “launch ready” when only the plan is complete.


## Complete portable record skeleton

Use this exact closed shape. Do not add properties. `revision` is an integer of 1 or greater; `fictional` is boolean; `history`, `flow.entry_branch_ids`, `flow.branches` and `crm.field_map` are arrays. Destination and evidence states must use the values shown by the prompt rules. Every nested object is closed: unknown keys are validation findings.

```json
{
  "contract_id": "maestro-messenger-flow-v1",
  "record_id": "replace-with-stable-record-id",
  "revision": 1,
  "fictional": false,
  "offer": {
    "name": "Unknown",
    "buyer": "Unknown",
    "promise": "Unknown",
    "conversation_value": "Unknown"
  },
  "destination": {
    "proposed": "hold",
    "reason": "Unknown"
  },
  "flow": {
    "opening": "Unknown",
    "entry_branch_ids": [],
    "branches": []
  },
  "ownership": {
    "response_owner": "Unknown",
    "coverage_window": "Unknown",
    "response_target": "Unknown",
    "escalation_owner": "Unknown",
    "outside_coverage": "Unknown"
  },
  "crm": {
    "system": "Unknown",
    "destination": "Unknown",
    "field_map": [],
    "duplicate_rule": "Unknown",
    "failure_route": "Unknown",
    "failure_owner": "Unknown"
  },
  "native_evidence": {
    "page_linkage": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""},
    "destination_availability": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""},
    "permissions": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""},
    "policy_approval": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""},
    "publication": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""},
    "delivery": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""},
    "reply": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""},
    "crm_arrival": {"state": "Unknown", "reference": "", "observed_at": "", "owner": "", "note": ""}
  },
  "history": []
}
```

## Schema-invalid handling

Missing `fictional` or `history`, non-integer `revision`, invalid enum values, wrong field types and extra properties prevent `Ready for native setup`. Report them as stable validation findings before applying decision precedence. For a non-Messenger destination, do not emit Messenger evidence requests; return `Not evaluated for alternate destination` as the native state and name the next system-specific action.

## Canonical execution and literal output rules

The downloadable bundle includes `run-messenger-flow.mjs`, `artifacts/messenger-flow-evaluator.mjs` and `messenger-flow.schema.json`. They are the canonical implementation. Save the supplied JSON, then run:

```bash
node run-messenger-flow.mjs RECORD.json --pretty
node run-messenger-flow.mjs RECORD.json --handoff
```

The CLI accepts either a source record or a browser-downloaded evaluation envelope containing `source_record`. Do not replace its result with a subjective interpretation. If you cannot execute the bundle, return the source record unchanged and state `Canonical evaluation required`; do not invent a parallel decision, finding or request shape.

Apply these literals exactly when describing the canonical result:

- Any resolved string passes as a supplied planning value. Do not judge whether response targets, coverage windows or owner wording are sensible.
- Ownership and CRM handoff fields are required for every selected destination except `hold`. A missing alternate-route owner or handoff stays `Hold for native evidence`; Messenger evidence remains unevaluated.
- If any schema, planning or branch finding remains, native account receipt requests are deferred and the native state is `Hold for native evidence` for Messenger or `Not evaluated for alternate destination` for a selected alternate route.
- `hold` has native state `Hold for native evidence` and no Messenger requests.
- A complete alternate route has planning outcome `Use another destination`, native state `Not evaluated for alternate destination`, and no Messenger requests.
- Request IDs use hyphens, never underscores: `MESSENGER-EVIDENCE-<KEY-WITH-HYPHENS>`.
- Every request object uses keys `id`, `field`, `owner`, `supplied_state`, `reason`, `request`. Reason is exactly `<key with spaces> is not verified`. Request is the exact `evidenceLabels` sentence from the canonical evaluator. Missing owner becomes `Owner assignment required`.
- The eight exact request sentences are: `a dated receipt showing the intended Facebook Page is linked to the intended business and ad account`; `a dated Ads Manager receipt showing Messenger is available for the selected setup`; `a dated roles or access receipt showing the required people and system users have access`; `the native policy review or approval receipt for the ad and message flow`; `the native publication receipt with the intended identity, campaign, ad set and ad identifiers`; `a dated test showing the published ad opened the intended Messenger thread`; `a dated test showing the reply reached the named owner or queue`; `a destination read-back showing the expected CRM record and mapped fields`.
- Multiple entry branches are allowed. Every branch must be reachable from at least one supplied entry ID.
- `receipt:placeholder` and future UTC timestamps fail. There is no future-time grace period.
- Use `renderHandoff()` or `--handoff` for the readable export. Never reconstruct its Markdown tables independently.