Skip to content

ATS-PFM-LLM-002Bound AI conversations and handle recoverable failures: Capability Test Specification

Markdown

ATS-PFM-LLM-002

Bound AI conversations and handle recoverable failures: Capability Test Specification

Markdown
  • DocumentProposed

KindAcceptance test setProduct areaPlatformModuleAI Requests, Usage and the Jazz AI TeammateRevision2

Read atservices-platform ad3f6a65

Coverage

  • Rule gap: FND-PFM-LLM-061
  • Transition gap: FND-PFM-LLM-061
  • Validation covered
  • Permission not-applicable
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency gap: FND-PFM-LLM-061
  • Invariant gap: FND-PFM-LLM-061
  • Interaction covered

Test Scenarios

14 scenarios proving CAP-PFM-LLM-002; 10 bound to an existing test.

01 Turn budget ends an unfinished conversationruleunitnegativetest
Proves
BR-CAP-PFM-LLM-002-01
Preconditions
A scripted model never offers an acceptable final answer.
Steps
Run with a small turn allowance.
Expected
Exactly the allowed requests execute before the loop returns its turn-limit outcome.
Data
Fixtures representing a scripted model never offers an acceptable final answer.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/run-tool-loop.spec.ts#stops a conversation that will not converge
02 Oversized tool batches run no handlersedgeunitnegativetest
Proves
BR-CAP-PFM-LLM-002-02
Preconditions
A nonfinal turn asks for more tools than remain.
Steps
Execute that conversation.
Expected
The batch ends the loop and none of its handlers runs.
Data
Fixtures representing a nonfinal turn asks for more tools than remain.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/run-tool-loop.spec.ts#runs no handler for the turn it refused, rather than half of it
03 Credit guard uses strict excessboundaryunitnegativetest
Proves
BR-CAP-PFM-LLM-002-03
Preconditions
Two nonfinal tool turns together cost more than the hold.
Steps
Execute both turns and inspect the ending and usage.
Expected
The loop stops after strict excess, preserving the charge of the crossing turn.
Data
Fixtures representing two nonfinal tool turns together cost more than the hold.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/run-tool-loop.spec.ts#stops when the reservation is spent, whether or not the next turn would have converged
04 No remaining time means no provider requestboundaryunitnegativetest
Proves
BR-CAP-PFM-LLM-002-04
Preconditions
The next turn has no conversation time left.
Steps
Start the loop under that time budget.
Expected
No request is sent for the expired turn.
Data
Fixtures representing the next turn has no conversation time left.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/run-tool-loop.spec.ts#stops before a turn it has no time left for
05 Retry classification separates recoverable faultsfailureunittest
Proves
BR-CAP-PFM-LLM-002-05
Preconditions
Provider examples include timeout, rate limit, server errors, malformed and unauthorized requests, connection reset and abort.
Steps
Classify each example with the retry policy.
Expected
Transient faults permit retry while permanent request or authority faults do not.
Data
Fixtures representing provider examples include timeout, rate limit, server errors, malformed and unauthorized requests, connection reset and abort.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/retry-policy.spec.ts#retries a 529, which is the provider telling us it is overloaded
06 Depleted provider credit does not retryfailureunitnegativetest
Proves
BR-CAP-PFM-LLM-002-06
Preconditions
A provider rate-limit response describes an exhausted balance.
Steps
Resolve its retry classification.
Expected
It is credit exhaustion with retry disabled.
Data
Fixtures representing a provider rate-limit response describes an exhausted balance.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/retry-policy.spec.ts#is not retried, because retrying it reads a purchase problem as load
07 Retries retain their own usage pricesruleapitest
Proves
BR-CAP-PFM-LLM-002-07
Preconditions
The first provider attempt fails and its retry succeeds.
Steps
Execute the request and inspect both attempt records.
Expected
Both attempts share a turn with distinct retry numbers; missing usage costs zero and reported retry usage receives its own price.
Data
Fixtures representing the first provider attempt fails and its retry succeeds.
Bound to
Source
services-platform:modules/llm/tests/integration/lifecycle/executions.integration.spec.js#prices the failed attempt, which reported nothing, at zero
08 Rejected answers can be repairedvalidationunittest
Proves
BR-CAP-PFM-LLM-002-10
Preconditions
The feature rejects one final answer and accepts the next.
Steps
Run the loop with that answer judge.
Expected
The model receives the rejection as a tool error, the rejected call uses tool budget and the accepted repair completes.
Data
Fixtures representing the feature rejects one final answer and accepts the next.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/run-tool-loop.spec.ts#answers the rejected call with what the consumer gave it, as that call’s own result
09 Cache marking remains within the provider boundboundaryunittest
Proves
BR-CAP-PFM-LLM-002-12
Preconditions
Stable content requests more cache markers than the provider accepts.
Steps
Construct the provider request.
Expected
At most four markers remain and the marked content text is preserved.
Data
Fixtures representing stable content requests more cache markers than the provider accepts.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/anthropic-provider.spec.ts#never sends more than the four Anthropic takes, however many blocks asked to be cached
10 Final acceptance precedes later budget guardsedgeunitproposed
Proves
BR-CAP-PFM-LLM-002-14
Preconditions
A turn offers an acceptable final answer alongside excess cost and requested tools.
Steps
Execute the turn and accept its final answer.
Expected
Completion wins over the later tool and credit checks; ordinary tools do not run and the accepted answer adds no answered-tool count.
Data
Fixtures representing a turn offers an acceptable final answer alongside excess cost and requested tools.
Source
services-platform:modules/llm/runtime/run-tool-loop.ts:runToolLoop
11 Missing tool handlers return a repairable errorfailureunitproposed
Proves
BR-CAP-PFM-LLM-002-15
Preconditions
A model asks for a tool with no handler before offering an answer.
Steps
Execute with that handler absent.
Expected
A tool error reaches the model and a later turn can complete within the remaining budgets.
Data
Fixtures representing a model asks for a tool with no handler before offering an answer.
Source
services-platform:modules/llm/runtime/run-tool-loop.ts:runToolLoop
12 Historical budgets explain a bounded conversationinteractionapiproposed
Proves
BR-CAP-PFM-LLM-002-01 BR-CAP-PFM-LLM-005-03
Preconditions
A request ends at its published turn limit and the next publication increases that limit.
Steps
Read the earlier request and run a freshly resolved scripted request.
Expected
The earlier ending retains its original routing budget; the later request uses the changed budget.
Data
An isolated workspace with the records, clock instants and caller authority stated in the preconditions.
Source
services-platform:modules/llm/tests/unit/runtime/run-tool-loop.spec.ts#stops a conversation that will not converge,services-platform:modules/llm/services/catalog/materialize-catalog.ts
13 Attempt history explains retry outcomesinteractionapiproposed
Proves
BR-CAP-PFM-LLM-002-07 BR-CAP-PFM-LLM-012-06
Preconditions
A scripted request first receives overload and then succeeds; another ends at its turn limit.
Steps
Read retained attempts and explain the limited request.
Expected
Retry numbering and costs remain distinct from turns, and the explanation names the retained routing limit.
Data
An isolated workspace with the records, clock instants and caller authority stated in the preconditions.
Source
services-platform:modules/llm/services/persistence/invocations.ts:recordInvocationAttempt,services-platform:modules/llm/services/explain/explain-invocation.ts
14 Retry exhaustion reports every attemptfailureunitnegativetest
Proves
BR-CAP-PFM-LLM-002-05
Preconditions
The suite owns isolated fixtures representing the valid control and the contrasting case described by its steps.
Steps
Script two transient failures followed by a success under the default retry budget.
Expected
All three attempts are reported in order, with failure classifications and increasing backoff before success.
Data
Suite-owned fixtures, with a fixed clock where dates or grant windows matter.
Bound to
Source
services-platform:modules/llm/tests/unit/runtime/execute-with-llm-retry.spec.ts#reports all three, so the two that were billed are not lost

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.