@salesforce/afv-skills 1.37.0 → 1.38.0

package/skills/agentforce-generate/references/agent-audit-diagnostics-architecture-evaluation.md

@@ -0,0 +1,68 @@
+# AgentScript Architecture and Evaluation Diagnostics
+
+Use these categories to evaluate architectural pressure, evidence quality, and
+cases that should remain non-findings.
+
+## Architecture and prompt density
+
+Check:
+
+- subagents exist without an objective, instruction, action, authority, or
+  escalation boundary;
+- routers duplicate behavior better handled in one execution block;
+- state and transitions compensate for unclear instructions rather than real
+  runtime needs;
+- huge product lists, phrase lists, and repeated rules obscure higher-priority
+  behavior;
+- one reasoning iteration must reconcile too many classifications, precedence
+  rules, exact sequences, or mutually dependent decisions for the deployed
+  model;
+- one subagent owns unrelated objectives or incompatible authority.
+
+Fix:
+
+- Start from the smallest architecture satisfying the use cases.
+- Split when a boundary materially changes objective, instructions, actions,
+  authority, or escalation and that separation is worth the routing and
+  lifecycle cost.
+- Remove duplicated prose before adding state.
+- Match the reasoning burden to the actual target model and configuration. If
+  the target model is unknown, report capability fit as unassessed.
+- Do not use a stronger model as a substitute for resolving contradictions,
+  impossible sequences, or missing runtime data.
+
+Evaluate with the deployed target model, representative routes, and prompt
+inspection. Vary phrasing at semantic boundaries. Do not treat reduced line
+count as a behavior result.
+
+## Evaluation integrity
+
+Check:
+
+- candidate-only tests;
+- changed expected behavior after seeing a failure;
+- aggregate score hiding a critical regression;
+- simulated actions presented as live proof;
+- parent and candidate labels that do not identify concrete revisions;
+- tests encoding generic preferences absent from the Agent Spec or baseline.
+
+Fix:
+
+- Freeze the matrix and evaluator before editing.
+- Record immutable baseline and candidate identifiers.
+- Separate structural, simulated, and live evidence.
+- Report individual critical cases as well as aggregate score.
+
+## Non-findings
+
+Do not automatically report:
+
+- a large file;
+- one execution block rather than several subagents;
+- absence of persistent state;
+- absence of generic ambiguity, off-topic, or human-help branches;
+- lack of a router in a focused workflow;
+- model judgment over unstructured user intent;
+- wording or formatting preferences without a reachable consequence.
+
+These become findings only when the use cases and evidence establish harm.

package/skills/agentforce-generate/references/agent-audit-diagnostics-instructions-routing.md

@@ -0,0 +1,283 @@
+# AgentScript Instruction and Routing Diagnostics
+
+Use these categories only after the audit identifies a relevant instruction,
+visibility, response, or routing concern.
+
+## Contents
+
+- [Language and structural validity](#language-and-structural-validity)
+- [Instruction resolution](#instruction-resolution)
+- [Prompt text that impersonates code](#prompt-text-that-impersonates-code)
+- [Behavioral duties versus response copy](#behavioral-duties-versus-response-copy)
+- [Routing and reachability](#routing-and-reachability)
+- [HyperClassifier router fit](#hyperclassifier-router-fit)
+
+## Language and structural validity
+
+Check:
+
+- unsupported blocks, hooks, utilities, conditional forms, or directives;
+- malformed structural indentation or mixed indentation;
+- missing required declarations in a complete bundle;
+- references to undeclared variables, actions, subagents, or outputs;
+- action targets or input/output schemas that disagree with implementations;
+- syntax copied from a newer or different AgentScript dialect.
+
+Evidence and fix:
+
+- Prefer `sf agent validate authoring-bundle --json` against the intended
+  target org.
+- Distinguish a complete bundle from an extracted fragment.
+- Use the smallest supported construct.
+- Do not patch around a compiler failure with prompt wording.
+
+Evaluate:
+
+- Require zero relevant compile errors.
+- Re-run contract discovery when action definitions change.
+
+## Instruction resolution
+
+Check:
+
+- a subagent `system.instructions` value unintentionally replaces global
+  identity, safety, or scope instructions;
+- a `system.instructions` value attempts to use `instructions: ->` or runtime
+  procedure statements instead of declarative prompt text;
+- a system merge field is treated as deterministic enforcement rather than a
+  current value rendered for the model;
+- global and local instructions demand incompatible outcomes;
+- model-facing instructions mention runtime-only concepts the model cannot see;
+- model-facing instructions name `@variables.X` without interpolating a value
+  the model must actually read;
+- model-facing instructions compare an interpolated value even though the
+  runtime already knows the exact fact and a stable consequence may be clearer
+  or safer as a runtime branch;
+- a conditional fragment assumes another fragment is present;
+- repeated instructions conflict, dilute precedence, or exceed useful context.
+
+Fix:
+
+- Put durable invariants in the effective system instruction for every block
+  that needs them.
+- Keep system instructions declarative. Move `run`, `set`, runtime `if`, and
+  transitions to supported lifecycle or reasoning procedure blocks.
+- Remove duplicate or contradictory prose.
+- Inject only the concrete values the model must read.
+
+Evaluate:
+
+- Inspect the effective prompt for each affected use case, not only the source.
+- Inspect system merge fields on the first iteration and after relevant state
+  changes.
+- Test one case per instruction-override boundary.
+
+### Variable visibility and decision ownership
+
+Classify each variable-like reference before changing it:
+
+| Source form | Meaning | Correct use |
+|---|---|---|
+| `if @variables.X == ...` | Runtime expression | Exact machine-known branch |
+| `with input = @variables.X` | Runtime binding | Pass a trusted value |
+| `| Current value: {!@variables.X}` | Prompt interpolation | Model must read the value |
+| `| Set next_destination to "self_service"` | Literal instruction | Model supplies a named parameter; no current value is needed |
+
+A bare `@variables.X` inside `|` text contributes only literal text; that token
+does not provide the stored value. The same value may be separately present in
+conversation or tool history. Interpolate when the current stored value is the
+one the prompt must reliably receive.
+
+Interpolation does not make a branch deterministic. This still delegates an
+exact comparison to the model:
+
+```agentscript
+| If {!@variables.account_status} == "blocked", do the blocked-account flow.
+```
+
+If stable behavior truly depends on that exact trusted value, use a runtime
+predicate and give the matching branch one concrete objective. If the
+condition depends on semantic intent—such as whether the user is asking for a
+human—or the use case benefits more from flexibility than strict
+repeatability, leave that judgment in model instructions.
+
+Do not auto-fix every compiler interpolation hint. First decide whether the
+text needs the value, merely names a parameter, or should not ask the model to
+evaluate the condition at all.
+
+## Prompt text that impersonates code
+
+Check:
+
+- indentation beneath `|` is treated as executable nesting;
+- `if {!@variables.X} == ...` inside prompt text is treated as a runtime
+  predicate;
+- Python-style `elif` is used instead of AgentScript `else if`, or a separate
+  `if` is nested inside a conditional body;
+- `Show`, `Ask`, `Call`, `Set`, `STOP`, or `Continue` is treated as a runtime
+  directive;
+- “Step 3” or “continue above” assumes prior prompt fragments survived;
+- `MANDATORY` or `DO NOT SKIP` substitutes for gating or sequencing;
+- adjacent same-scope prompt lines repeat `|` as though each marker creates a
+  step or boundary;
+- an action visually placed under one prompt branch remains globally available.
+
+Fix:
+
+- Use runtime constructs for machine-known behavior.
+- Use model instructions for intent, ambiguity, meaning, and other
+  situation-aware judgments.
+- Use explicit predicates or a supported mutually exclusive conditional
+  structure for exclusive branches.
+- When authoring new alternatives or when first-match priority matters, prefer
+  `if / else if / else`. Independent top-level `if` statements are valid when
+  multiple branches may run or their predicates are provably mutually
+  exclusive. Do not rewrite an equivalent form during a Surface repair without
+  a diagnostic or concrete overlap, gap, priority, or use-case consequence.
+  Spell the clause `else if`; `elif` is invalid.
+- Collapse adjacent same-scope prompt fragments into one `|` block with
+  aligned continuation lines. Start a new marker after a runtime statement or
+  branch when the structure requires a new fragment.
+- Preserve a valid `instructions: ->` block that contains only `|` prompt text
+  during a bounded repair. The absence of runtime statements does not make the
+  block defective. Changing it to `instructions: |` is cosmetic unless the
+  user explicitly requests scalar-style cleanup or runtime evidence shows a
+  behavior difference.
+- Make each resolved prompt fragment understandable with the other fragments
+  that can accompany it in the same reachable state.
+
+Evaluate:
+
+- Inspect both effective instructions and available actions for true and false
+  versions of each branch condition.
+- For a marker-only cleanup, compile the file and compare the resolved prompt
+  text before and after; do not claim a behavioral repair from formatting
+  alone.
+
+## Behavioral duties versus response copy
+
+Check:
+
+- ordinary instructions are written as finished dialogue instead of telling
+  the model what outcome, content, and constraints the response needs;
+- draft copy hides whether a line is a required fact, an example, a tone cue,
+  or the complete response duty;
+- two candidate replies can resolve into the same prompt even though their
+  underlying duties are mutually exclusive;
+- exact wording is implied by quotation or prose style but never stated as a
+  requirement;
+- rigid canned text discards relevant conversation context without a legal,
+  compliance, safety, brand, or grounding reason.
+
+Default to behavioral instructions:
+
+```agentscript
+if @variables.cart_validation_failed:
+    | Explain that one or more cart items are unavailable. Do not offer
+      payment. Ask the user to review or remove those items.
+else:
+    | Tell the user the current cart total is {!@variables.cart_total}. Ask
+      whether they want to proceed to payment or cancel.
+```
+
+This states what the model must accomplish while leaving ordinary wording
+responsive to the conversation. It also exposes the real branch duties for
+review.
+
+Use response copy only when the wording itself is part of the requirement. In
+that case, make the contract explicit rather than hoping the model infers it:
+
+```agentscript
+| Respond with exactly this approved notice, with no additions:
+  "This call may be recorded for quality and training purposes."
+```
+
+Examples and tone samples are not exact-copy requirements. Label them as
+examples and state which properties should carry over.
+
+Fix:
+
+- replace ordinary candidate dialogue with the intended response duty,
+  required facts, prohibited claims, and next conversational objective;
+- preserve merge fields for exact values the model must receive;
+- make mutually exclusive duties exclusive with runtime predicates when they
+  depend on trusted machine state;
+- retain exact copy only when the use case actually requires it, and say
+  `Respond exactly` or equivalent;
+- keep useful sample wording as a labeled example rather than an unlabeled
+  command.
+
+Evaluate:
+
+- inspect every reachable assembled prompt and name its single current
+  response duty;
+- vary the preceding conversation and confirm ordinary responses adapt while
+  preserving required facts and exclusions;
+- for exact-copy cases, assert the literal output and absence of additions;
+- do not report stylistic preference alone as a defect: identify the ambiguity,
+  conflict, lost context, or unsupported exact-copy requirement it causes.
+
+## Routing and reachability
+
+Check:
+
+- independent conditions can resolve simultaneously;
+- no condition handles a reachable state;
+- precedence is stated in prose but not represented by predicates;
+- a branch depends on an accidental default or a value with no producer;
+- a route is unreachable because an earlier transition or reset always wins;
+- a broad fallback steals a specific use case;
+- routing descriptions disagree with reasoning instructions.
+
+Fix:
+
+- Use mutually exclusive predicates or another supported mutually exclusive
+  structure.
+- Encode only machine-known precedence deterministically.
+- Add a fallback only when intended use cases require one.
+
+Evaluate:
+
+- Test each route positively and negatively.
+- Test ambiguous boundary utterances against neighboring routes.
+
+## HyperClassifier router fit
+
+Check:
+
+- `model://sfdc_ai__DefaultEinsteinHyperClassifier` is used on a node that must
+  answer, clarify, inspect images, set state, run domain actions, escalate,
+  delegate to a connected agent, or use `before_reasoning` or
+  `after_reasoning`;
+- a HyperClassifier reasoning action is anything other than
+  `@utils.transition`;
+- route descriptions overlap, omit important exclusions, or disagree with the
+  target subagents;
+- trusted state should remove an ineligible route but no `available when` guard
+  does so;
+- the design expects the router itself to respond when classification is
+  ambiguous instead of routing to an intended clarification or fallback
+  subagent;
+- an ordinary-model router is reported as defective merely because it does not
+  use HyperClassifier.
+
+Fix:
+
+- Add HyperClassifier only when the node can remain a pure transition selector
+  and routing latency is a requirement.
+- Move conversation and domain work to the target subagent, or keep an ordinary
+  model when those duties belong in the entry node.
+- Use `available when` for machine-known eligibility and distinct action
+  descriptions for semantic intent.
+- Do not create a router or additional subagents solely to use HyperClassifier.
+
+Evaluate:
+
+- Run `sf agent validate authoring-bundle --json` and confirm the router has no
+  unsupported actions or lifecycle hooks.
+- Preview positive and negative examples for every route, ambiguous boundaries,
+  follow-up turns, unavailable-route states, and the intended fallback.
+- Inspect traces for the selected transition. Do not infer correct routing from
+  plausible response text.
+- Treat a compatible ordinary-model router as an optimization opportunity only
+  when latency or observed transition reliability justifies the change.

package/skills/agentforce-generate/references/agent-audit-evaluation-loop.md

@@ -0,0 +1,191 @@
+# AgentScript Audit and Repair Evaluation Loop
+
+Use this loop to compare an unchanged AgentScript agent with a minimally
+repaired candidate. The goal is not to maximize a generic score. The goal is to
+improve the affected use cases without weakening the rest.
+
+## Contents
+
+- [Delivery guard](#delivery-guard)
+- [Freeze the comparison](#1-freeze-the-comparison)
+- [Build the use-case matrix](#2-build-the-use-case-matrix)
+- [Capture the baseline](#3-capture-the-baseline)
+- [Apply one coherent repair](#4-apply-one-coherent-repair)
+- [Continue candidate verification](#continue-candidate-verification)
+
+## Delivery guard
+
+Treat the comparison record as a durable artifact, not an end-of-task summary.
+Write the baseline identity and initial use cases as soon as they are known,
+then update the same record after each repair batch. Evaluate Critical and High
+findings before lower-priority hypotheses. Missing runtime access or unresolved
+non-blocking semantics becomes a stated limitation; it does not justify an
+open-ended research loop.
+
+## 1. Freeze the comparison
+
+Record:
+
+- baseline and candidate identity. Prefer a revision or digest when two
+  different artifacts are compared. For an unchanged local audit, an explicit
+  statement that baseline and candidate are the same byte-identical file is
+  sufficient; do not manufacture hashes for ceremony;
+- target org alias and API name, if used;
+- Salesforce CLI version;
+- local compiler provider, exact package version or source commit, and entry
+  path—or **compiler not used** with the recorded cause;
+- model and runtime surface;
+- action mode: simulated or live;
+- evaluator and expected outcomes;
+- use-case IDs and which are explicit versus inferred;
+- selected intervention level and the user's choice when Structural or Rewrite
+  is selected.
+
+Do not change these after seeing candidate results.
+
+Use labels that make the comparison unambiguous:
+
+```text
+baseline = unchanged agent at <revision-or-digest-or-path>
+candidate = repaired agent at <revision-or-digest-or-path>
+```
+
+When no change is made, write `candidate = baseline; file unchanged` instead of
+requiring a digest. “Parent” and “candidate” are meaningful only when the
+artifacts being compared are identified clearly enough to reproduce the result.
+
+## 2. Build the use-case matrix
+
+For each case, record:
+
+| Field | Meaning |
+|---|---|
+| ID | Stable case identifier |
+| Source | User requirement, Agent Spec, existing test, or inferred behavior |
+| Turns | Full multi-turn sequence |
+| Expected owner | Start agent or subagent |
+| Expected action | Required invocation, or `none` |
+| Forbidden actions | Actions that must not be available or invoked |
+| Expected state | Material state changes |
+| Expected effect | Observable external result, if any |
+| Evaluation mode | Static, simulated, preview live-action, or test suite |
+
+Include positive, negative, retry, continuation, and repeated-request cases only
+when material to the supported use cases.
+
+## 3. Capture the baseline
+
+### Structural validation
+
+Run the bundled local compiler first. Then, when a complete bundle and
+authenticated target org are available:
+
+```bash
+sf config get target-org --json
+sf agent validate authoring-bundle --json --api-name <BundleName>
+```
+
+Record exact diagnostics. Do not edit first and reconstruct the baseline later.
+Treat diagnostics as evidence, not an optimization score. Do not silence a
+warning by violating documented syntax, removing intentional initialization,
+or changing behavior. When compiler output conflicts with canonical guidance,
+preserve the documented behavior and report the discrepancy.
+
+When org validation is unavailable:
+
+- run documented repository checks that already exist;
+- record the static limitation;
+- do not claim compiler validity.
+
+Do not substitute regex or a home-grown parser for AgentScript validation.
+
+### Behavioral validation
+
+Use preview when safe:
+
+```bash
+sf agent preview start --json \
+  --authoring-bundle <BundleName> \
+  --simulate-actions \
+  -o <org-alias>
+
+sf agent preview send --json \
+  --session-id <session-id> \
+  --utterance "<case turn>" \
+  --authoring-bundle <BundleName> \
+  -o <org-alias>
+
+sf agent preview end --json \
+  --session-id <session-id> \
+  --authoring-bundle <BundleName> \
+  -o <org-alias>
+```
+
+Use `--simulate-actions` to test:
+
+- routing;
+- effective instructions;
+- action availability;
+- model selection;
+- response posture.
+
+Simulation does not prove:
+
+- output-dependent branches;
+- Apex or Flow behavior;
+- external writes;
+- transfer, message, charge, or record effects.
+
+Use `--use-live-actions` only with explicit approval, a verified non-production
+org, and safe data.
+
+### Preserve evidence
+
+For each case, retain:
+
+```text
+input turns
+effective instructions
+available actions
+invoked actions
+action outputs
+state changes
+transitions
+final response
+external effect verification
+```
+
+If the environment cannot provide one layer, mark it unavailable.
+
+## 4. Apply one coherent repair
+
+Repair one coherent cause group at a time, such as:
+
+- one malformed indentation family;
+- one premature completion/result-parsing family;
+- one action-availability and duplicate-effect family.
+
+Do not mix broad reformatting with behavioral changes.
+Do not exceed the selected intervention level. If the evidence shows the
+selected level cannot resolve the finding, stop and request a broader choice
+before editing further.
+
+Record for each change:
+
+- finding ID;
+- exact source location;
+- use case repaired;
+- invariant enforced;
+- expected observable difference.
+
+For Structural or Rewrite candidates, also record every material removed
+subagent, route, experience-specific branch, action, default, and user-visible
+response. Identify where each capability is preserved or name the accepted
+behavior change. Static “unused” analysis alone does not establish that a
+reachable capability is safe to remove.
+
+## Continue candidate verification
+
+After applying the coherent repair, continue with
+[Audit Candidate Verification](agent-audit-candidate-verification.md) to inspect
+the candidate, decide whether to keep it, handle regressions, and report limits.

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

@@ -0,0 +1,143 @@
+# AgentScript Audit Repair and Report
+
+Continue here after the scope and reachable-path review is complete.
+
+## Contents
+
+- [Select the Intervention Level](#4-select-the-intervention-level)
+- [Capture the Baseline](#5-capture-the-baseline)
+- [Apply the Selected Repairs](#6-apply-the-selected-repairs)
+- [Evaluate and Iterate](#7-evaluate-and-iterate)
+- [Report the Result](#8-report-the-result)
+
+## Workflow (continued)
+
+### 4. Select the Intervention Level
+
+Assess Surface, Structural, and Rewrite against the ranked findings using the
+criteria in the Diagnostic Catalog. For each level, state whether it is
+warranted, what it would change, which findings it would leave unresolved, and
+its regression and evaluation cost.
+
+Recommend the smallest level that can resolve the accepted findings. Record an
+explicit user choice before Structural or Rewrite changes. A general request
+to fix the agent authorizes Surface repairs only; stop and ask before crossing
+that boundary. If a selected level proves insufficient, report why and request
+a new choice instead of expanding the scope silently.
+
+"Smallest sufficient" means the smallest level that resolves every accepted
+finding affecting an intended use case, including a shared root cause. Do not
+recommend Surface as the final repair when it only makes a path reachable but
+leaves overlapping state that still assembles competing duties on that path.
+In that situation, recommend Structural; Surface may be offered only as an
+explicitly incomplete stabilization option.
+
+Do not classify a repair from the number of edited lines alone. If reliable
+sequencing requires coordinated changes across several phase variables,
+producers, consumers, and reset paths, treat the coupled state ownership as a
+Structural problem even when each individual edit looks small. Keep Surface
+for isolated wiring defects whose surrounding lifecycle remains coherent.
+
+When the proposed Structural change reorganizes a cross-turn lifecycle, name
+the regression cases that prove the new ownership works: normal continuation,
+correction before commitment, cancellation or intent change, and reset or a
+second independent request. Include only boundaries material to the flow; do
+not add state or ceremony solely to satisfy this list.
+
+### 5. Capture the Baseline
+
+- Run available project checks and Salesforce CLI validation before editing.
+- Run the use-case matrix against the unchanged agent when a safe execution
+  surface is available.
+- Use a fresh session for each independent case. Keep one session only for the
+  turns of a deliberate multi-turn case.
+- Use simulated actions only for routing, instruction, and action-selection
+  checks. Do not use simulation to claim output-dependent branches or external
+  effects work.
+- Run live actions only with explicit user approval, a confirmed
+  non-production environment, and safe test data.
+- If runtime testing is unavailable, record a static baseline and state the
+  limitation. Do not invent a score.
+
+Preserve baseline results separately from candidate results.
+
+### 6. Apply the Selected Repairs
+
+Fix one coherent cause group at a time:
+
+1. syntax, structural, and unsupported-language failures;
+2. authorization, safety, and duplicate-side-effect failures;
+3. dead, overlapping, or incorrectly gated paths;
+4. output, state, lifecycle, and continuation failures;
+5. unnecessary complexity with a demonstrated failure mode.
+
+For each group:
+
+- remain within the selected intervention level;
+- change the narrowest runtime construct that owns the problem;
+- preserve valid optional metadata and unrelated bytes in bounded repairs;
+- do not normalize equivalent control flow merely because another form is
+  preferred for newly authored code;
+- use `available when`, typed outputs, deterministic assignments, an explicit
+  reasoning boundary, or a purpose-built implementation that owns the complete
+  sequence when prose cannot enforce the invariant;
+- keep semantic intent tests in model instructions, and move exact comparisons
+  over trusted runtime values into AgentScript control when their consequences
+  require stable enforcement;
+- interpolate a runtime value only when the model must read that value; do not
+  rewrite literal parameter names or author documentation mechanically;
+- remove state with no named runtime or later exact-output consumer and no
+  evidence-preservation need beyond the usable history window;
+- set completion only from the strongest result the runtime can prove;
+- keep logic changes separate from broad formatting cleanup;
+- for Structural or Rewrite work, record where each removed subagent,
+  route, experience-specific branch, action, default, and user-visible
+  response went—or identify the accepted behavior change;
+- preserve unrelated behavior and wording.
+
+If the user requested diagnosis only, stop before editing and provide the
+repair and evaluation plan.
+
+### 7. Evaluate and Iterate
+
+After each coherent repair group:
+
+1. rerun project checks and Salesforce CLI validation;
+2. replay the same baseline use cases with the same evaluator;
+3. run the new regression case that exposes the repaired defect;
+4. inspect effective instructions, action availability, invocation, outputs,
+   state changes, transitions, and effects—not only final response text;
+5. compare baseline and candidate for the selected unaffected canary cases;
+6. verify every material removal in Structural or Rewrite work is preserved
+   elsewhere or recorded as an accepted behavior change;
+7. keep the change only when the target case improves and unrelated cases are
+   no worse.
+
+If a candidate regresses, narrow or revert that repair and repeat. Do not
+change the evaluator to make the candidate pass.
+
+### 8. Report the Result
+
+Update the report throughout the audit rather than creating it only at the end.
+Return the final checkpoint with the most consequential supported information
+first:
+
+1. **Health summary:** what is broken, risky, or sound.
+2. **Use-case matrix:** explicit versus inferred cases and expected outcomes.
+3. **Findings:** severity, location, evidence, affected cases, and disposition.
+4. **Intervention:** assessment of all three levels, recommendation, user
+   choice, and selected scope.
+5. **Changes:** the minimal repair made for each accepted finding.
+6. **Baseline versus candidate:** same cases, same evaluator, exact results.
+7. **Validation:** local compiler provider and version or source commit—or
+   **compiler not used** with cause—plus target-org CLI, preview/test mode,
+   action mode, and limits.
+8. **Remaining risks:** only evidence-backed unresolved items.
+
+If work stops early because of missing evidence, access, approval, or an
+unresolved safety-critical contract, still return the current ranked ledger,
+completed checks, completed changes if any, and the exact next decision needed.
+Never substitute continued research for a deliverable blocker report.
+
+State “no actionable finding” when that is the evidence. An audit is not
+required to prescribe a change.