Remove in-app SDK (#43)

* chore: delete internal/agent package

* chore(build): remove sdk-android from gradle settings

* chore(makefile): remove sdk-android targets

* chore(ci): remove release-android job from release workflow

* chore(folio): remove sdk-android dependency

* chore(folio): remove SDK initialization from FolioApplication

* chore(folio): delete snapshot extractor files

* feat(folio): add balance to account card content description

* feat(folio): add hierarchy content descriptions to LedgerScreen

* refactor(folio): rewrite spec.ts to use ax extractors

* docs: remove in-app SDK from README

* feat(folio): add focused_input indicator to App

* docs: remove in-app SDK from index

* refactor(runner): remove agent SDK connection and snapshot step

* test(runner): update tests for SDK removal

* docs: remove Android SDK section from getting-started

* refactor(testrun): remove agent SDK connection setup

* docs: remove snapshots from writing-specs

* docs: remove in-app SDK from architecture doc

* docs(folio): update README for SDK removal

* docs: update per-step cycle diagram in architecture doc

* fix(folio): detect screens from unique element presence, not id: selectors

testTag() in Compose is not exposed as resource-id without testTagsAsResourceId.
Use desc: selectors for elements unique to each screen instead of id: path queries.

* feat(folio): add screen root contentDescription for scoped ax selection

Each screen root gets semantics { contentDescription = "ScreenName" } so
sanderling specs can scope element lookups through the screen: desc:LoginScreen > desc:login_submit.

* fix(folio): scope all ax selectors through screen root nodes

Use desc:ScreenName > desc:element path queries so every selector is
rooted at the screen level. focusedInput stays unscoped since it lives
in the app root, outside any screen.

* fix(folio): guard newAccountBalanceIsZero against navigation false positives

Scoped selectors return [] when not on HomeScreen so accounts vanish and
reappear as apparently-new on each visit. Skip the check when prev was empty.

* chore(folio): link @sanderling/spec to local pkg/spec for IDE type checking

* feat(spec): add desc, class, clickable, enabled, checked, focused, selected to AccessibilityElement

Runtime fields set by the verifier were missing from the TypeScript type,
causing linting errors on el.desc and related accesses in specs.

* chore(folio): switch to bun, add tsconfig.json for IDE type checking

- Remove package-lock.json, add bun.lock
- Add tsconfig.json so VSCode resolves @sanderling/spec types
- Fix parseAccount/parseLedgerRow to accept string | undefined
This commit is contained in:
pj authored and GitHub committed 2026-04-25 20:04:29 +07:00
1 parent 6c32fb0e1d
commit 776becdf4b
60 files changed
+298 -3354

No files matched your search

-27
View File
@@ -11,7 +11,6 @@ import { extract, always, now, actions, weighted, Tap, taps, swipes } from "@san
// 1. Extractors pull values from each observed state.
const loggedIn = extract((s) => !!s.ax.find("id:home-tab-bar"));
const cartCount = extract<number>((s) => (s.snapshots.cart_count as number) ?? 0);
// 2. Properties are LTL formulas evaluated every step.
export const properties = {
@@ -34,7 +33,6 @@ What extractors see:
```ts
interface State {
ax: AccessibilityTree; // view hierarchy
snapshots: Record<string, unknown>; // values registered by the in-app SDK
screen: { id: string; hash: string };
lastAction: Action | null;
logs: LogEntry[]; // since previous state
@@ -45,8 +43,6 @@ interface State {
`ax.find("text:Click me")`, `ax.find("id:login-form")`, `ax.findAll("role:todo-row")` are the common accessors. Prefer stable testID-style identifiers over positional selectors, for the same reason you would in Espresso or XCUITest.
`snapshots` is populated by the in-app SDK via `Sanderling.extract("name") { value }`. Use it when the UI does not expose a value you need, such as business-logic state or hidden fields.
## Pattern: preconditions (login, onboarding)
sanderling has no setup phase and no fixtures. Preconditions are action generators with two properties:
@@ -129,29 +125,6 @@ loginSucceedsWithin30s: eventually(() => loggedIn.current).within(30, "seconds")
`within` takes `"milliseconds"`, `"seconds"`, or `"steps"`. Useful for liveness checks: the loading spinner eventually goes away, the deep link eventually lands on `/home`.
## Pattern: snapshot-backed properties
When the UI does not expose a value but the app knows it, use the SDK's extractor registry:
```kotlin
// in the app (Android)
Sanderling.extract("cart_count") { store.cart.size }
```
```ts
// in the spec
const cartCount = extract<number>((s) => (s.snapshots.cart_count as number) ?? 0);
export const properties = {
cartMonotonicAfterAdd: always(() => {
const previous = cartCount.previous;
return previous === undefined || cartCount.current >= previous;
}),
};
```
This pattern lets you write properties against business logic that no UI element exposes.
## Pattern: weighted exploration sub-trees
Nest `weighted` to group related actions and tune their collective rate: