@salesforce/afv-skills 1.36.0 → 1.38.0

package/skills/agentforce-generate/references/agent-audit-and-repair.md

@@ -0,0 +1,135 @@
+# Audit and Repair Existing Agents
+
+Repair an existing AgentScript agent without replacing its intended behavior
+with generic preferences.
+
+Org-backed validation requires an Agentforce-enabled org and Salesforce CLI.
+A bounded static review can proceed without org access, but must not be
+reported as compiler or runtime validation.
+
+## Contents
+
+- [Operating Contract](#operating-contract)
+- [Surface Preservation Gate](#surface-preservation-gate)
+- [Related Skill Boundaries](#related-skill-boundaries)
+- [Workflow references](#workflow-references)
+
+## Operating Contract
+
+1. **Use cases define correctness.** A checklist can reveal risk; it cannot
+   decide what the agent should do. Reconstruct the agent's intended use cases
+   before recommending or making behavioral changes.
+2. **Diagnose before editing.** Record the baseline, exact evidence, affected
+   use cases, and smallest credible fix first.
+3. **Make findings actionable.** Every finding must include a source location,
+   runtime consequence, affected use case, proposed change, and verification
+   method. Omit unsupported style opinions.
+4. **Prefer the smallest repair.** Do not redesign the agent, add subagents,
+   add persistent state, or add universal ambiguity, off-topic, or human-help
+   behavior unless the use cases require it.
+5. **Evaluate the control tradeoff.** Do not mechanically make every condition
+   deterministic or leave every condition to the model. More control improves
+   ordering and repeatability but costs flexibility, state, and maintenance.
+   More model latitude improves interpretation and recovery but makes behavior
+   probabilistic. Protect requirements whose failure cost warrants runtime
+   control; preserve model judgment where flexibility is valuable. When the
+   model needs a runtime value, inject it explicitly.
+6. **Choose the intervention level.** After diagnosis, assess Surface,
+   Structural, and Rewrite; recommend the smallest sufficient level, explain
+   the alternatives and tradeoffs, and obtain user choice before Structural or
+   Rewrite work. Never broaden the repair silently.
+7. **Compile locally, then validate against the target org.** Run the bundled
+   local compiler first. When an authenticated org is available, also use
+   `sf agent validate authoring-bundle --json` for target-org language
+   validation. Never claim language validity from a regex, a home-grown parser,
+   or prompt inspection. Treat diagnostics as evidence, not an optimization
+   score. Do not silence a diagnostic by violating documented AgentScript
+   syntax, removing intentional initialization, or changing behavior. Treat
+   reference lists and examples as guidance rather than exhaustive schemas.
+   When references, examples, the selected compiler, and the target validator
+   disagree, preserve an accepted existing construct, report the discrepancy,
+   and validate against the intended deployment target instead of deleting the
+   construct by inference.
+8. **Compare like with like.** Run the same use cases and evaluators against
+   the unchanged baseline and candidate. Label them explicitly. For Structural
+   or Rewrite candidates, account for every material removal of a subagent,
+   route, experience-specific branch, action, default, or user-visible
+   response before claiming capabilities were preserved.
+9. **Distinguish availability, invocation, execution, and effect.** A good
+   response or tool name does not prove that an external side effect occurred.
+10. **Calibrate every claim.** Distinguish language/compiler contracts,
+    runtime-source behavior, observed trace behavior, empirical heuristics, and
+    authoring recommendations. Do not turn a single trace, runtime version, or
+    preferred design into a universal rule. Use causal or categorical wording
+    only when the evidence supports it. Compilation alone supports “compiles”
+    or “candidate for review.” Use “safe,” “behavior-preserving,” “ready to
+    ship,” or equivalent language only when relevant behavior has also been
+    evaluated; otherwise state what remains untested.
+11. **Do not release.** This workflow authorizes local edits and proportionate
+    validation, not deployment, publication, activation, production execution,
+    or live consequential actions.
+12. **Deliver useful work before exhaustive work.** Create a durable audit
+    ledger or report shell after the initial scan, rank supported findings by
+    observable harm, and update the artifact as evidence or repairs land. Do
+    not make a complete runtime theory, complete reference review, or complete
+    rewrite a prerequisite for the first useful deliverable.
+13. **Bound investigation by decisions.** Follow a reference, source path, or
+    trace only when it can change a named finding, repair, or verification
+    decision. If a primary source and one relevant corroborating source do not
+    resolve a non-safety-critical semantic question, record the uncertainty
+    and proceed. If the uncertainty blocks a safe repair, deliver the ranked
+    findings and blocker instead of continuing an open-ended investigation.
+14. **Carry the contract into delegated work.** Give each delegated pass a
+    bounded artifact or cause group, priority order, lookup-only references,
+    and explicit output path. Require the first checkpoint after its initial
+    scan and a useful partial report when blocked. Do not hand a delegate a
+    broad mandatory reading list or an all-or-nothing final deliverable.
+
+## Surface Preservation Gate
+
+For a Surface-only request, use the original artifact as the byte-preserving
+baseline:
+
+1. List accepted findings before editing. Each must identify the original
+   source text, evidence, concrete consequence, and exact intended edit.
+2. Do not treat a draft as a generation task. Missing recommended fields,
+   optional messages, preferred formatting, or equivalent control-flow forms
+   are not repair findings by themselves.
+3. Edit the existing bundle in place. Preserve its directory, API name,
+   filenames, metadata, and equivalent control-flow form unless an accepted
+   finding specifically requires changing one of them. Do not emit a renamed
+   candidate bundle for an ordinary repair.
+4. Apply only edits on the accepted list. Do not improve tone, complete a
+   schema, reorder blocks, or normalize style opportunistically.
+5. Diff the candidate against the baseline. Revert every hunk that cannot be
+   mapped one-to-one to an accepted finding. If a hunk contains both required
+   and unrelated cleanup, narrow it before delivery.
+6. Validation is evidence, not permission to widen the repair. Do not change
+   block-scalar style, normalize equivalent control flow, or migrate otherwise
+   preserved metadata merely so an org validator can run; record the
+   validation limit and keep the unrelated bytes unchanged.
+
+This gate does not prevent evidence-backed Surface fixes. It prevents an
+authoring preference from silently expanding a bounded repair.
+
+Use [Diagnostic Catalog](agent-audit-diagnostic-catalog.md) as a lookup after
+the initial scan; do not preload it. Consult the relevant section of
+[Evaluation Loop](agent-audit-evaluation-loop.md) before recording a baseline,
+applying a repair, or accepting a candidate; do not preload sections for later
+steps.
+
+## Related Skill Boundaries
+
+- Use the parent skill's create or modify task domain for a new agent or one
+  already-specified edit.
+- Use `agentforce-observe` when production session or trace evidence is the
+  primary input.
+- Use `agentforce-test` when the task is only to author or run a predefined
+  functional or security test suite.
+
+## Workflow references
+
+Read both workflow references in order for a full audit or repair:
+
+1. [Audit Scope and Path Review](agent-audit-scope-path-review.md) — establish scope, scale large audits, reconstruct use cases, and inspect reachable paths.
+2. [Audit Repair and Report](agent-audit-repair-report.md) — select the intervention level, preserve a baseline, repair, evaluate, and report.

package/skills/agentforce-generate/references/agent-audit-candidate-verification.md

@@ -0,0 +1,160 @@
+# AgentScript Audit Candidate Verification
+
+Continue here after freezing the comparison, recording the baseline, and
+applying one coherent repair.
+
+## Contents
+
+- [Validate the candidate](#5-validate-the-candidate)
+- [Inspect more than the final text](#6-inspect-more-than-the-final-text)
+- [Evaluate reasoning boundaries](#7-evaluate-reasoning-boundaries)
+- [Decide whether to keep the repair](#8-decide-whether-to-keep-the-repair)
+- [Handle regressions](#9-handle-regressions)
+- [Report limitations](#10-report-limitations)
+
+## 5. Validate the candidate
+
+Run in this order:
+
+1. repository checks;
+2. `sf agent validate authoring-bundle --json`;
+3. the new regression case;
+4. affected existing cases;
+5. representative unaffected canaries;
+6. the complete frozen matrix before final acceptance.
+
+Use the same model, runtime, action mode, evaluator, and test data as baseline.
+
+## 6. Inspect more than the final text
+
+A response can look correct while the agent used the wrong mechanism. Evaluate:
+
+```text
+configured
+-> available
+-> invoked
+-> executed
+-> returned
+-> stored
+-> transitioned
+-> effected
+```
+
+Examples:
+
+- “I transferred you” does not prove `@utils.escalate` executed.
+- A tool invocation does not prove its external write succeeded.
+- A raw JSON result does not prove derived boolean state was stored.
+- A `checked=True` flag does not prove every branch input is usable.
+- A self-transition can prove a new reasoning iteration began, but not that the
+  eventual external action effected its target.
+
+## 7. Evaluate reasoning boundaries
+
+When a repair introduces a reasoning boundary, inspect both sides.
+
+Before the boundary:
+
+- the producer runs once;
+- the raw result is stored;
+- completion remains false;
+- no downstream branch reads default derived fields;
+- the transition or stage exit is guarded against repetition.
+
+After the boundary:
+
+- the effective prompt is rebuilt from the stored result;
+- only result-processing guidance is active;
+- the model-visible raw value is explicitly injected when needed;
+- one grouped state-update action requests all related fields and completion;
+- success or failure actions are unavailable until the grouped update has
+  produced the state required by their gates.
+
+A grouped state-update call expresses one semantic state change. Keep
+downstream actions unavailable until their complete required state is present;
+the grouping does not make model parsing deterministic.
+
+For a guarded self-transition, add regression cases for:
+
+- successful re-entry;
+- failed or malformed result;
+- no infinite loop;
+- second independent request after reset;
+- stale prior result not reused.
+
+Treat the self-transition as an explicit phase boundary, not as evidence that
+looping is generally desirable.
+
+## 8. Decide whether to keep the repair
+
+Keep the change only when:
+
+- the target case improves;
+- no critical or high-severity case regresses;
+- relevant compile diagnostics are no worse;
+- unaffected canaries are no worse;
+- no new unauthorized action becomes available;
+- no simulated result is presented as proof of a live effect;
+- the candidate stays within the selected intervention level;
+- every material removal in Structural or Rewrite work is preserved elsewhere
+  or recorded as an accepted behavior change.
+
+If results vary, run repeated trials with the same setup and report the
+distribution. Do not hide variance in an average.
+
+## 9. Handle regressions
+
+When a candidate regresses:
+
+1. identify the smallest repair group responsible;
+2. narrow or revert that group;
+3. keep the evaluator frozen;
+4. rerun structural checks;
+5. rerun the affected case and all previously passing regression cases.
+
+Do not:
+
+- weaken an expected outcome after seeing the candidate fail;
+- delete a failing case without showing it is outside the contract;
+- change from live to simulated actions to obtain a pass;
+- combine unrelated cleanup with a behavioral repair;
+- declare improvement from aggregate score while a critical case regresses.
+
+Stop and report a blocker when evaluation requires unavailable org access,
+missing action implementations, production-only side effects, or a material
+product-policy decision.
+
+For a large agent, use bounded repair batches:
+
+```text
+indexed first pass
+-> ranked ledger checkpoint
+-> select highest-impact supported cause group
+-> one small, coherent cause group
+-> full compiler check
+-> affected regression cases
+-> unaffected canary cases
+-> keep, narrow, or revert
+-> update the durable report
+-> next ranked group
+-> final cross-node check and frozen-matrix regression
+```
+
+## 10. Report limitations
+
+State explicitly:
+
+- artifact revisions compared;
+- explicit versus inferred cases;
+- compiler and Salesforce CLI version;
+- simulated versus live cases;
+- whether external effects were independently verified;
+- branches that could not be executed;
+- runtime, model, test-data, or evaluator differences;
+- assessed intervention levels, recommendation, user choice, and whether the
+  candidate remained within that scope.
+
+Use “not evaluated” instead of “passed” when evidence is unavailable.
+Compilation alone supports “compiles” or “candidate for review.” Use “safe,”
+“behavior-preserving,” “ready to ship,” or equivalent language only when the
+relevant behavior has been evaluated; otherwise state what remains untested.

package/skills/agentforce-generate/references/agent-audit-diagnostic-catalog.md

@@ -0,0 +1,156 @@
+# AgentScript Diagnostic Catalog
+
+Use this catalog after reconstructing the agent's use cases. A pattern is a
+finding only when it has a source location, reachable consequence, affected
+use case, minimal fix, and verification method.
+
+This catalog is a lookup index, not a required cover-to-cover review. Start
+with the artifact and its use cases, consult only categories that can confirm
+or reject a named observation, and return to the audit ledger after each
+relevant section.
+
+## Contents
+
+- [Post-diagnosis intervention levels](#post-diagnosis-intervention-levels)
+- [Control posture and tradeoffs](#control-posture-and-tradeoffs)
+- [Claim calibration](#claim-calibration)
+- [Focused diagnostic references](#focused-diagnostic-references)
+
+## Post-diagnosis intervention levels
+
+Assess all three levels after ranking findings. Mark each level **warranted** or
+**not warranted** from evidence, then recommend the smallest level that can
+resolve the accepted findings.
+
+### Surface
+
+Use for local bugs, typos with runtime impact, simple best-practice violations,
+and one-line or similarly bounded fixes. It may correct a predicate, action
+description, variable reference, indentation error, reset, or isolated prompt
+instruction without reorganizing the flow or changing its architecture.
+
+Choose Surface when the intended structure and contracts remain sound. State
+which deeper problems, if any, it intentionally leaves unresolved.
+
+Surface is not schema completion or style normalization. Preserve valid
+optional metadata and semantically equivalent control-flow shapes. Absence
+from an abbreviated reference list or example does not establish that an
+existing field is unsupported; use the selected compiler, target validator,
+or concrete runtime evidence. Likewise, do not add a missing field without a
+diagnostic and evidence for the correct value; a guessed value can change
+deployment semantics even when it compiles.
+
+### Structural
+
+Use for limited reorganization or basic structure changes when local edits
+cannot make sequencing, ownership, routing, or lifecycle behavior reliable. It
+may reorder or regroup existing logic, clarify a phase boundary, consolidate
+duplicated rules, or make a bounded state lifecycle explicit.
+
+Classify by behavioral coupling, not line count. Several individually small
+edits are Structural when they must change multiple producers, consumers, and
+reset paths that jointly encode one phase. In particular, when overlapping
+flags and a stage value describe the same lifecycle, local patches that leave
+contradictory combinations or unclear ownership do not make the design
+reliable. Consolidating that lifecycle is a Structural change. A single
+missing producer, gate, or reset can still be Surface when the surrounding
+state model remains coherent.
+
+Do not choose Surface merely because it fixes the highest-severity symptoms.
+If an accepted shared root cause still creates competing duties on the repaired
+happy path, Surface is an incomplete stabilization, not the smallest sufficient
+final repair. Recommend Structural and present Surface only as that bounded
+stopgap.
+
+Structural work preserves the agent's objectives and overall architecture. It
+costs more regression testing because several paths or prompt-resolution
+boundaries may change.
+
+For a cross-turn lifecycle reorganization, verify normal continuation,
+correction before commitment, cancellation or intent change, and reset or a
+second independent request. These cases test the state ownership; they do not
+justify adding persistent state when the flow does not otherwise need it.
+
+### Rewrite
+
+Use for a total redesign only when evidence shows the existing architecture
+cannot safely or maintainably satisfy the intended use cases. It may replace
+routing, state, subagent boundaries, or action contracts and therefore requires
+a complete frozen-matrix regression and contract review.
+
+Do not recommend Rewrite merely because the file is large or unfamiliar.
+Explain why Surface and Structural changes are insufficient and identify the
+behavioral and migration risks.
+
+### Choice and scope control
+
+For each level, report:
+
+- findings and use cases it resolves;
+- findings it leaves unresolved;
+- expected diff and architecture scope;
+- regression risk and evaluation burden;
+- compatibility or migration tradeoffs.
+
+Recommend one level, but let the user choose. A general request to fix findings
+defaults to Surface. Obtain explicit user choice before Structural or Rewrite,
+unless the user already selected that level in the request. Do not mix levels
+silently; if the chosen level is insufficient, stop and request a broader
+choice.
+
+## Control posture and tradeoffs
+
+Judge each flow on a spectrum from prompt-led to mixed to scripted. Do not
+award determinism merely for being deterministic, and do not flag a staged
+flow merely for having stages.
+
+More runtime control improves ordering, repeatability, auditability, and
+protection of consequential effects. It also adds state, lifecycle cases,
+maintenance, and rigidity when the user corrects themselves, digresses, or
+changes intent. More model latitude provides natural interpretation and
+recovery, but exact action choice and ordering remain probabilistic.
+
+For each disputed decision, record:
+
+- the observable cost if the model makes the wrong or reordered choice;
+- the conversational flexibility lost by locking the choice;
+- whether a mixed design can let the model interpret intent while runtime
+  gates only the consequence;
+- evidence from requirements, evaluations, or traces that justifies changing
+  the current posture.
+
+Recommend more control only when its reliability benefit exceeds its
+flexibility and lifecycle cost. Recommend less control only when doing so
+preserves the required invariants. A stage that spans turns needs the recovery
+paths relevant to its use cases; a short-lived guard does not automatically
+need correction, cancellation, retry, and expiry machinery.
+
+## Claim calibration
+
+Classify the basis of each finding before choosing its wording:
+
+| Basis | What it supports |
+|---|---|
+| Compiler or language contract | A statement scoped to the validated language/version |
+| Runtime source and tests | A statement scoped to the inspected runtime/version |
+| Repeated trace or evaluation evidence | An empirical reliability claim for the tested configuration |
+| Single trace | What happened in that session, not a universal causal rule |
+| Design analysis | A recommendation with explicit tradeoffs |
+| No direct evidence | A hypothesis to verify, not a finding |
+
+Search categorical terms such as `always`, `never`, `every`, `cannot`,
+`guarantees`, `ends the turn`, and `must` in the draft report and proposed
+guidance. Keep them only when the cited contract or invariant is equally
+categorical. State uncertainty and version scope where relevant.
+
+Do not infer causation from sequence alone. For example, a response after a
+state update does not prove the state update ended the turn, and a workaround
+that improved one trace does not prove why it worked.
+
+## Focused diagnostic references
+
+Load only the category needed for a supported finding:
+
+- [Instruction and Routing Diagnostics](agent-audit-diagnostics-instructions-routing.md) — language validity, instruction resolution, variable visibility, prompt pseudo-code, user-facing behavior, routing, and HyperClassifier fit.
+- [Action and State Diagnostics](agent-audit-diagnostics-actions-state.md) — action surfaces, output contracts, state lifecycle, turn sequencing, transitions, authority, and side effects.
+- [Architecture and Evaluation Diagnostics](agent-audit-diagnostics-architecture-evaluation.md) — architecture density, evaluation integrity, and non-findings that should not trigger edits.

package/skills/agentforce-generate/references/agent-audit-diagnostics-actions-state.md

@@ -0,0 +1,176 @@
+# AgentScript Action and State Diagnostics
+
+Use these categories only after the audit identifies a relevant action,
+contract, state, sequencing, transition, or authority concern.
+
+## Contents
+
+- [Action surface and contracts](#action-surface-and-contracts)
+- [Outputs and trusted decisions](#outputs-and-trusted-decisions)
+- [State and lifecycle](#state-and-lifecycle)
+- [Turn sequencing](#turn-sequencing)
+- [Transitions and message continuity](#transitions-and-message-continuity)
+- [Authority and side effects](#authority-and-side-effects)
+
+## Action surface and contracts
+
+Check:
+
+- an action is referenced but undefined, or defined but unreachable;
+- availability is broader than the use case;
+- an action remains available after success and can repeat;
+- descriptions overpromise capability or conflict with eligibility;
+- required inputs have no conversation, variable, or literal producer;
+- outputs are declared but not captured, or captured but never consumed;
+- implementation inputs and outputs disagree with the `.agent` contract;
+- a utility action is treated as though it returned action outputs.
+
+Fix:
+
+- Gate availability with trusted state.
+- Return typed outputs and bind them to named consumers.
+- Align the contract with the real implementation.
+- Remove dead actions only after proving they serve no intended use case.
+
+Evaluate availability, invocation, execution, output, and effect separately.
+Include negative cases where the action must be absent.
+
+## Outputs and trusted decisions
+
+Check:
+
+- raw JSON or display text controls authorization, eligibility, routing, or
+  success;
+- the model is asked to parse a value that should be typed;
+- a “checked” flag becomes true before every downstream value is stored;
+- stale structured values survive a new raw result;
+- the prompt assumes stored state is visible without explicit injection;
+- a `|` block is assumed to pause deterministic resolution so the model can act
+  before the next `set` or condition resolves.
+
+Fix:
+
+- Prefer typed outputs.
+- Normalize raw output deterministically before setting completion.
+- Request related result fields as one grouped semantic state update when
+  possible.
+- If model-driven normalization is unavoidable, create an explicit reasoning
+  boundary: first produce and store the raw result, then rebuild reasoning from
+  that state and store all derived fields plus completion together.
+- Treat a guarded self-transition as a last-resort phase boundary when a
+  deterministic producer resolves before a required model-selected
+  normalization call can occur, and no clearer supported stage or typed result
+  is available. Document its entry and exit guards.
+
+Apply this two-phase rule:
+
+```text
+1. Resolve deterministic run, set, and if statements and assemble all | text.
+2. Send the completed prompt to the model, which may call a tool or respond.
+```
+
+Evaluate:
+
+- Test true, false, malformed, missing, and stale-result cases.
+- Confirm the branch reads the current result, not a default.
+- Inspect the effective prompt before and after the reasoning boundary.
+
+## State and lifecycle
+
+Check:
+
+- state merely remembers dialogue that remains available in conversation
+  history and has no runtime consumer;
+- `current_step`, `question_asked`, or similar variables imitate a workflow
+  engine without deterministic consumers;
+- several booleans and a phase variable encode the same workflow position;
+- reachable combinations of state have no coherent meaning;
+- completion means attempted or initiated rather than effected;
+- request-scoped state leaks into a later request;
+- reset, retry, correction, cancellation, logout, or expiry semantics are
+  missing;
+- `before_reasoning` unconditionally erases a legitimate prior-turn value;
+- `after_reasoning` overwrites or advances state despite failure.
+
+Fix:
+
+- Remove state only when its control benefit does not justify its flexibility
+  and lifecycle cost.
+- Prefer one explicit phase value over several overlapping asking/answered
+  latches when deterministic sequencing is truly required.
+- Name state after the evidence it represents.
+- Give every mutable variable a producer, consumer, and lifecycle
+  proportionate to how long it lives and what it controls.
+
+Select the second-request, retry, cancellation, correction, and expiry paths
+that can affect the changed state before it stops mattering. Assert state
+transitions, not just response wording.
+
+## Turn sequencing
+
+Check:
+
+- prompt text asks the model to call an action, while later deterministic
+  conditions assume that action has already run;
+- one prompt asks a question and consumes the future answer immediately;
+- several model-selected tools are required in an exact order;
+- the model can return text instead of invoking a required action;
+- post-action and first-entry instructions can resolve together because their
+  predicates are not mutually exclusive and no control boundary separates
+  them.
+
+Fix:
+
+- Give each branch one next outcome.
+- Bind current-turn inputs directly to the real action when persistence is not
+  required.
+- Use deterministic chaining, an explicit reasoning boundary, or one
+  purpose-built action that owns the sequence when order protects correctness.
+- Do not describe `@utils.setVariables` as turn-ending or as guaranteeing
+  another reasoning iteration. It is a model-selected state-update tool whose
+  call updates state but does not itself define a turn boundary. The risk is
+  assuming that prompt text has already caused the call before the prompt is
+  sent.
+
+Evaluate the actual multi-turn sequence and inspect each reasoning iteration.
+
+## Transitions and message continuity
+
+Check:
+
+- the target subagent reprocesses the message that completed the source flow;
+- transition state is incomplete for the target's arrival path;
+- both source and target respond or perform the same work;
+- a flow cannot return or exit when supported use cases require it;
+- a generic “stay” rule traps genuine topic switches.
+
+Fix:
+
+- Define one owner for the arrival turn.
+- Pass explicit state only when the target needs it.
+- Make continuation and exit predicates reflect real use cases, not exhaustive
+  phrase lists.
+
+Evaluate the entry, continuation, cancellation, pivot, and return cases that
+the supported use cases can reach.
+
+## Authority and side effects
+
+Check:
+
+- a consequential action is gated by model-inferred or user-claimed authority;
+- confirmation exists only in prose;
+- two actions both appear to perform the same external effect;
+- idempotency is absent for repeatable writes, transfers, messages, or charges;
+- completion is set before a typed success result;
+- simulated execution is treated as proof of a live effect.
+
+Fix:
+
+- Gate on trusted authorization and confirmation evidence.
+- Choose one side-effect owner.
+- Use idempotency keys or returned identifiers where supported.
+- Claim only the strongest effect the runtime can verify.
+
+Evaluate unauthorized, unconfirmed, duplicate, failure, timeout, and retry
+cases. Verify the external record only when live execution is authorized.