From 3f0132c92a1e407d12c72c9ba471032508aa0fdb Mon Sep 17 00:00:00 2001 From: PJ Date: Fri, 14 Aug 2026 17:50:37 +0530 Subject: [PATCH] fix(folio-web): bound the reachability properties by steps At one model call per step the model arm takes 359 seconds where the seeded arm takes 47, so a second-based deadline reported violations that were the arm's speed rather than the application's behaviour. The three cross-arm reachability properties now bound by steps, derived at the measured 6.383 steps per second. The two auth-transition properties keep seconds: a user waits through those regardless of which policy is driving. Claude-Session: https://claude.ai/code/session_01A5KmftdEJ49A9z5mF5ESrX --- examples/folio-web/sanderling/spec.ts | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/examples/folio-web/sanderling/spec.ts b/examples/folio-web/sanderling/spec.ts index b7e4ebb..15dbfef 100644 --- a/examples/folio-web/sanderling/spec.ts +++ b/examples/folio-web/sanderling/spec.ts @@ -119,13 +119,19 @@ const balanceMatchesTransactionDelta = always( ), ); -const loginReachable = eventually(() => loggedIn.current).within(90, "seconds"); +// The three reachability goals are bounded in steps, not seconds, because they +// are compared across action-selection policies and the model policy spends a +// provider call per step. A 300-step seeded run of this app takes about 47 +// seconds, so the wall-clock windows these replace are 6.38 steps per second: +// 90 s is 575 steps, 180 s is 1150, and 300 s is 1915. The window now costs +// the same whatever is driving. +const loginReachable = eventually(() => loggedIn.current).within(575, "steps"); const accountCreationReachable = eventually( () => accountCards.current.length > 0, -).within(180, "seconds"); +).within(1150, "steps"); const someTransactionExists = eventually( () => ledgerTxnCount.current > 0, -).within(300, "seconds"); +).within(1915, "steps"); export const properties = { loggedInLeavesLogin,