@widgex/wgx 0.0.0-stage → 0.4.2

package/python/xactor/man/widget-model.md

@@ -0,0 +1,284 @@
+# The widget model
+<!-- group: Concepts -->
+
+How WidgeX drives a website: named page states and named transitions.
+
+There is no "open a browser" call. You reach a site either through a **widget**
+— a written model of that site — or through `api.drive`, which is the admission
+that no model exists yet. Which one you call is what the user approves and what
+the panel shows them.
+
+That is the point of the whole design. "ran create_token" is a thing a user can
+consent to. "clicked the third button" is not.
+
+## The parts
+
+A widget is a Python file defining **page states** and the **transitions**
+between them.
+
+```python
+login = PageState(
+    "Login",
+    url_pattern=r"https://example\.com/login",
+    entry="https://example.com/login",
+    keywords=["Sign in", "Password"],
+    observations=[
+        Observation("error", description="the login error banner",
+                    selector=".error", extract="text"),
+    ],
+    transitions=[
+        Transition("sign_in",
+            [Step("type_text", 'form#login/textbox"Email"',    text="$email"),
+             Step("type_text", 'form#login/textbox"Password"', text="$password"),
+             Step("click",     'form#login/button"Sign in"')],
+            params={"email": "str", "password": "str"},
+            description="sign in and land on the dashboard"),
+    ],
+)
+registry.add(login, transitions_to=["Dashboard"])
+```
+
+- **`PageState(name, *, url_pattern='.*', entry=None, keywords=None,
+  observations=None, transitions=None, expected_timeout=None)`** — one page.
+  `url_pattern` is how it is recognised; `keywords` disambiguate two states with
+  the same URL by scoring against the page text; `entry` is where
+  `use_widget(name, state=...)` navigates to.
+- **`Observation(name, *, description='', js=None, selector=None,
+  extract=None)`** — something you can read off the page by name.
+- **`Transition(name, steps, *, params=None, description='')`** — a named,
+  parameterised action. `params` is a **dict** of name to type.
+- **`Step(action, target, **kwargs)`** — one L1 action. `target` is a path, a
+  uid, or a `find(...)` spec.
+
+Two things that used to be documented wrongly here, both of which failed
+silently:
+
+- Parameters substitute as **`$name`**, never `{name}`. A `{name}` passes
+  through untouched, so the field is filled with the literal text and nothing
+  raises.
+- **`expects_transition` does nothing.** Readiness is intrinsic — every step waits
+  for its own target — and a step that fails now raises rather than letting the
+  transition report the state it was aiming for. `Step` still accepts the flag
+  (as a third positional) so old widgets load, but it is ignored: never pass it.
+- **`Observation(selector=...)` is CSS**, not a path. `button"Create Token"` is
+  refused at construction; use `js=` for anything else. A parameter may be called
+  `name`; the transition name is positional-only in `execute`.
+- The verb in a `Step` is the one on `api`: `click`, `type_text`,
+  `clear_and_type`, `select`, … (`clear_type` is accepted as an alias).
+
+## Writing targets that survive
+
+A target is a **path** through the page's structure, and paths are the whole
+reason a widget is worth writing:
+
+```
+main/table/row"prod-key"/button"Delete"
+dialog"Create Token"/button"Create"
+form#login/textbox"Username"
+```
+
+Get these from `api.search()` or `api.one()` while exploring, then paste the
+path into the widget. Do not hand-write them from a screenshot — the accessible
+name the engine computes is what a path matches on, and it is not always the
+text you can see.
+
+**Prefer, in order:**
+
+1. A path with a **name discriminator** — `button"Create Token"`. Readable, and
+   it survives re-renders and re-orderings.
+2. A path scoped by its **container** — `dialog"Create Token"/button"Create"`.
+   This is how you tell apart controls that share a name.
+3. A **testid** — `@row-delete`. Authored for automation, so it is the most
+   stable thing on the page when it exists.
+4. A `find(...)` **spec**, when the exact text varies. Set `margin` to say how
+   sure you need to be.
+
+**Avoid** a bare positional index (`button[2]`). It is emitted only when nothing
+else discriminates, and it is the one form a sibling insertion can silently
+shift.
+
+---
+
+# Efficient navigation
+
+The engine is fast. Most slow widgets are slow because of how they are written,
+not because of what they are driving. Five patterns account for nearly all of it.
+
+## 1. Load the whole chain; do not step through it
+
+Actions queue. A transition's steps already run as one chain, so write them as
+one — do not split a flow into several transitions that each settle and
+re-resolve.
+
+```python
+# Good: one chain, one settle at the end.
+Transition("create_token", [
+    Step("click",      'main/button"Create Token"'),
+    Step("clear_and_type", 'dialog"Create Token"/textbox"Name"', text="$name"),
+    Step("select",     'dialog"Create Token"/combobox"Expiration"', label="$expiry"),
+    Step("click",      'dialog"Create Token"/button"Create"'),
+], params={"name": "str", "expiry": "str"})
+```
+
+```python
+# Bad: four transitions. Each one settles the page and re-resolves the state
+# machine, so the agent pays the round trip four times and has to decide what
+# to do next three times it did not need to.
+```
+
+The measure: **a transition should get from one state the agent cares about to
+the next in a single pass.** If a state exists only because the flow passes
+through it, it should not be a state.
+
+## 2. Do not wait for things on purpose
+
+Every action already waits for its own target. An explicit `wait_for_element`
+before a click is almost always a step that costs a round trip and buys nothing.
+
+```python
+# Redundant — the click already waits for the dialog's button.
+Step("wait_for", 'dialog"Create Token"')
+Step("click",    'dialog"Create Token"/button"Create"')
+
+# Just the click.
+Step("click", 'dialog"Create Token"/button"Create"')
+```
+
+Wait explicitly only for something you are **not** about to touch: a spinner to
+go (`condition="gone"`), or a result to appear that you only want to read.
+
+## 3. Scope every lookup
+
+An unscoped search walks the page. A scoped one walks a subtree. On a console
+with four hundred controls that is the difference between a big payload and a
+small one, and it removes the ambiguity that would have sent the agent back for
+another look.
+
+```python
+# The page behind a modal is inert and excluded automatically, but scoping is
+# still the cheapest way to be unambiguous on an ordinary page.
+api.find(role="button", under='main/section"API keys"', like="revoke")
+```
+
+## 4. Anchor on what is visible, not on a picture
+
+When structure alone will not identify something, use a spatial relation. It
+costs one round trip. A screenshot costs a round trip **through the agent**,
+which is the expensive kind.
+
+```python
+api.find(role="textbox", right_of="Name")
+api.find(role="button",  in_row='row"prod-key"')
+api.find(role="button",  below='heading"Danger zone"')
+```
+
+## 5. Read once, in bulk
+
+An `Observation` is one JavaScript evaluation. Prefer one observation that
+returns a whole table to five that each return a column.
+
+```python
+Observation("tokens", js="""
+  Array.from(document.querySelectorAll('tbody tr')).map(r => ({
+    name:    r.cells[0]?.textContent?.trim(),
+    scope:   r.cells[1]?.textContent?.trim(),
+    expires: r.cells[3]?.textContent?.trim(),
+  }))
+""")
+```
+
+## Speed knobs
+
+- **`hfactor`** — humanisation speed, per action or per chain. **Higher is
+  faster.** It divides every delay rather than being one, so `hfactor=6` is six
+  times quicker than `hfactor=1`, and `hfactor=0.5` is half the speed. If you
+  want a run to go faster, put the number *up*.
+  A login nobody is watching can run at `hfactor=6`; leave it alone for anything
+  a user is looking at, and for anything that might trip bot detection.
+- **`timeout_ms`** — a single action's ceiling, default 10s. A `type` derives its
+  own from the length of the string and the `hfactor`, and adds it to the
+  chain's budget, so never set this on one: a type that times out is a field
+  refusing keystrokes, and a bigger number will not change that.
+- **`batch_ms`** — the whole chain's, default 30s. Raise it for a deliberately
+  long flow; if you are raising it because the flow is *slow*, fix the flow.
+
+## Widgets written against the old engine
+
+A widget that names elements the way the previous engine resolved them — by
+visible text, by a bare tag, by a CSS attribute selector — still runs. Layer 2
+translates those targets into an explicit ranked search before handing them
+down:
+
+| Old | Becomes |
+|---|---|
+| `Step("click", "Create Token")` | `find(like="Create Token")` |
+| `Step("clear_and_type", "TOKEN NAME", ...)` | `find(like="TOKEN NAME", role="textbox")` |
+| `Step("select", "select", ...)` | `find(role="combobox")` |
+| `Step("click", '[data-testid="x"]')` | `find(attr={"data-testid": "x"})` |
+| `container="…"` | `under="…"` |
+| `expects_transition=True` | dropped — readiness is intrinsic |
+| `index=2` | a `search()`, then the third result — **one extra round trip** |
+
+That is a bridge, not a destination, and it is deliberately at Layer 2: Layer 0
+still refuses to guess, and this is Layer 2 opting in where you can see it.
+
+Two reasons to move off it. A `like=` search ranks and can come back
+`ambiguous`, where a path is exact. And `index=` costs a lookup on every run —
+the row it is counting into has a name, and naming it is both faster and
+readable.
+
+The DOM-level verbs — `dom_click`, `dom_fill`, `wait_for_element`,
+`extract_secret` — kept their own CSS resolution and are **not** translated. A
+widget built on those needs no changes at all.
+
+## Working through it
+
+```python
+await api.widgets()                      # what exists — opens nothing
+await api.use_widget("vercel_tokens")    # approve, load, navigate
+```
+
+Then, right here in this shell — see `driving`:
+
+```python
+state = await registry.here(api)                 # where am I?
+print(state.describe())                          # what can I do here?
+state = await state.execute("create_token", name="ci")
+```
+
+`describe()` before `execute()` is the loop. You do not need to know the DOM;
+you need to know the state's name and its transitions.
+
+## When there is no widget
+
+`api.drive(url, why)`. Every action is then a raw L1 call against whatever the
+page happens to look like, and `why` is the only record of intent that will
+exist. `registry.here()` returns `UnknownPage`.
+
+If you find yourself driving the same site repeatedly, that site wants a widget.
+See `writing-a-widget` for how to build one from a live session.
+
+## Getting it wrong
+
+**Splitting a flow into a state per click.** A state is somewhere the agent might
+reasonably stop and decide. A half-filled dialog is not.
+
+**Writing `{param}`.** Substitution is `$param`. `{param}` types the braces.
+
+**Hand-writing a path from a screenshot.** Paths match the computed accessible
+name, which is not always the visible text. Get them from `api.search()`.
+
+**A bare index in a list that scrolls.** The engine refuses to emit one inside a
+virtualised container for exactly this reason; do not add one by hand.
+
+**Reaching for a screenshot to find an element.** An image is seen, not
+queryable, and looking at one costs a round trip through the agent.
+`api.search()` and the spatial predicates return structure.
+
+**Assuming `here()` is right.** It can return `UNKNOWN_STATE` — after a redirect,
+an interstitial, or a login wall. Check `state.name` before executing.
+
+## See also
+
+`writing-a-widget`, `driving`, `finding`, `widgets`, `use_widget`, `drive`,
+`browser-driver`

package/python/xactor/man/widgets.md

@@ -0,0 +1,59 @@
+# api.widgets(url=None) -> list[dict]
+<!-- group: Working on a website -->
+
+What sites are already modelled. Opens nothing, asks nothing. Not gated.
+
+The first call of any browser task. It reads the widget directories and tells
+you what is there, so you can work through a named automation instead of
+clicking at a page nobody has modelled.
+
+## Options
+
+- **`url`** — optional. Flags which widgets match that page, via the `matches`
+  key. Without it you get everything.
+
+## Returns
+
+```python
+[{"name": str, "domain": str, "description": str, "matches": bool}]
+```
+
+An empty list means nothing is modelled — that is the case for `api.drive`, not
+a failure.
+
+## Examples
+
+Before deciding how to approach a site:
+
+```python
+found = await api.widgets("https://vercel.com/account/tokens")
+hits = [w["name"] for w in found if w["matches"]]
+if hits:
+    return await api.use_widget(hits[0])
+return await api.drive("https://vercel.com/account/tokens",
+                       why="create a deploy token for CI")
+```
+
+Just seeing what exists:
+
+```python
+return [(w["name"], w["description"]) for w in await api.widgets()]
+```
+
+## Getting it wrong
+
+**Not calling it.** It is free — no browser, no permission, no prompt — and
+skipping it is how you end up driving a site that already has a tested model.
+
+**Treating an empty list as an error.** It means no widget exists yet. `drive`
+is the answer.
+
+**Ignoring `matches` when you passed a `url`.** Every widget comes back; only
+some of them are for that page.
+
+**Assuming a match means it is loaded.** It is not. `use_widget` loads and
+navigates; this call only reports.
+
+## See also
+
+`use_widget`, `drive`, `widget-model`, `browser_plumbing`

package/python/xactor/man/write_file.md

@@ -0,0 +1,76 @@
+# api.write_file(path, content, new_tab=False) -> str
+<!-- group: Coding -->
+
+Write a whole file, creating it and its parent directories. Gated.
+
+## Options
+
+- **`path`** — absolute, or relative to the shell's cwd.
+- **`content`** — the *entire* new contents. This is a replace, not an append:
+  whatever was there is gone. A `str` is written as text; `bytes` are written
+  as they are, for a binary file:
+
+  ```python
+  import base64
+  shot = await api.screenshot()
+  await api.write_file("shot.png", base64.b64decode(shot["$image"]["data"]))
+  ```
+
+  Anything else — `None` from a lookup that missed, say — is refused before
+  you are asked to approve the write.
+
+- **`new_tab`** — accepted and ignored. Writing a file opens no tab: the
+  user sees what you are editing as a queue on the new tab's Files door.
+
+Missing parent directories are created. Text is written as UTF-8, exactly as
+given: `\n` stays `\n`, whatever the platform.
+
+## Returns
+
+`"Wrote {n} bytes to {path}"`, where `n` is `len(content)` — characters for
+text, bytes for bytes.
+
+Unlike `edit_file`, there is no failure return — a write that could not happen
+raises (`PermissionError` if declined, `OSError` for a genuinely bad path).
+
+## Examples
+
+```python
+return await api.write_file("src/config.json", '{\n  "debug": false\n}\n')
+```
+
+Creating a file several directories deep, with no `mkdir` first:
+
+```python
+return await api.write_file("src/features/auth/index.ts", "export * from './login';\n")
+```
+
+Rewriting a file wholesale after transforming it:
+
+```python
+raw = (await api.bash("cat src/list.txt"))["stdout"]
+kept = [ln for ln in raw.splitlines() if not ln.startswith("#")]
+return await api.write_file("src/list.txt", "\n".join(kept) + "\n")
+```
+
+## Getting it wrong
+
+**Using it to change one line of an existing file.** You have to reproduce the
+whole file to do that, and any part you paraphrase is silently destroyed.
+`api.edit_file` changes exactly what you name and tells you if the anchor did
+not match.
+
+**Rebuilding a file from `api.read_file` output.** The line numbers and tabs
+would be written into the file, and trailing whitespace would be lost. If you
+must round-trip a file's text, get it raw with `api.bash("cat ...")`.
+
+**Expecting an append.** There is none. Read, concatenate, write — or use
+`api.bash("echo ... >> file")`, accepting that bash changes are not journalled
+and so cannot be reverted with the turn.
+
+**Forgetting the trailing newline.** Most tooling expects files to end with
+one, and its absence shows up later as a spurious diff line.
+
+## See also
+
+`edit_file`, `read_file`, `permissions`, `bash`

package/python/xactor/man/writing-a-widget.md

@@ -0,0 +1,142 @@
+# Writing a widget from a live session
+<!-- also: new-widget, authoring, record -->
+<!-- group: Working on a website -->
+
+Drive the site once by hand, keep what worked, save it as a model.
+
+A widget is worth writing when you have driven the same site twice. The second
+time, write it down.
+
+## The loop
+
+**1. Get there and look.**
+
+```python
+await api.drive("https://vercel.com/account/settings/tokens",
+                why="work out how token creation is laid out, to model it")
+```
+
+```python
+print(await api.outline())          # the shape, ~250 tokens
+```
+
+**2. Find the controls, and keep the paths.**
+
+```python
+for r in await api.search(role="button"):
+    print(r.score, r.path, repr(r.text))
+```
+
+Copy the paths out of that output. They are what goes in the widget — do not
+retype them from what you can see on screen, because a path matches the computed
+accessible name and that is not always the visible text.
+
+**3. Try the chain for real, in one pass.**
+
+```python
+api.click(api.find(role="button", like="create token"))
+api.clear_and_type(api.find(role="textbox", right_of="Name"), "scratch-test")
+report = await api.drain()
+print(report)
+```
+
+Every verb is a method on `api` — there are no bare functions in that scope.
+Locating is awaited (`api.search`, `api.one`); acting is not, because actions
+queue and `api.drain()` collects them.
+
+The report tells you which paths resolved and which did not, and what each one
+actually hit. **That report is your draft.** A step that came back `ambiguous`
+needs a scope; one that came back `not_found` needs a different discriminator.
+
+**4. Write it down.**
+
+```python
+tokens = PageState(
+    "TokensPage",
+    url_pattern=r"vercel\.com/account/settings/tokens",
+    keywords=["Tokens", "Create Token"],
+    observations=[
+        Observation("tokens", js="""
+          Array.from(document.querySelectorAll('tbody tr')).map(r => ({
+            name: r.cells[0]?.textContent?.trim(),
+            expires: r.cells[3]?.textContent?.trim(),
+          }))
+        """),
+    ],
+    transitions=[
+        Transition("create_token",
+            [Step("click",      'main/button"Create Token"'),
+             Step("clear_and_type", 'dialog"Create Token"/textbox"Name"', text="$name"),
+             Step("select",     'dialog"Create Token"/combobox"Expiration"', label="$expiry"),
+             Step("click",      'dialog"Create Token"/button"Create"')],
+            params={"name": "str", "expiry": "str"},
+            description="create a token and land on the success dialog"),
+    ],
+)
+registry.add(tokens, transitions_to=["TokenCreated"])
+```
+
+**5. Save and check it.**
+
+```python
+await api.write_file(f"{home}/.widgex/widgets/vercel_tokens.py", source)
+await api.browser_flush()
+await api.use_widget("vercel_tokens")
+state = await registry.here(api)
+print(state.name, state.describe())
+```
+
+## What makes a good state
+
+**A state is somewhere the agent might reasonably stop and decide.** The token
+list is a state. A half-filled dialog is not — it is the middle of a transition.
+
+If a state has exactly one transition out of it and nothing worth reading, it
+should not exist; fold it into the transition that passes through.
+
+Give a state `keywords` whenever another state shares its `url_pattern`. Dialogs
+usually do — that is what keywords are for.
+
+## What makes a good transition
+
+- **One objective, one transition.** Four clicks that get from "looking at the
+  list" to "the token exists" are one transition, not four.
+- **Name the paths, scope the ambiguous ones.** `dialog"X"/button"Create"` rather
+  than `button"Create"` when the page behind also has one.
+- **No explicit waits.** Every step already waits for its own target.
+- **`params` is a dict**, and substitution is `$name`. `{name}` types the braces.
+
+## Getting it started faster
+
+Have a driver session do the exploring and hand you the draft — it is a good use
+of a small model, and it keeps the page structure out of your context:
+
+```python
+child = await api.agent(
+    prompt=("Explore https://example.com/settings and draft a widget for it. "
+            "Use api.outline and api.search to find the controls, try the chain "
+            "with api.drain, and relay me the PageState source. Paths from "
+            "search() only -- do not invent them, do not screenshot."),
+    model="claude-haiku-4-5",
+)
+```
+
+See `browser-driver`.
+
+## Getting it wrong
+
+**Modelling every page you passed through.** A state you never stop at is
+overhead in the graph and a round trip at runtime.
+
+**Recording a transition you have not run.** The batch report is the evidence a
+chain works. Write down what the report says resolved, not what you expect to.
+
+**Using a bare index.** `button[2]` is the one path form a sibling insertion can
+shift silently. Prefer a name, a testid, or a scope.
+
+**Leaving `scratch-test` rows behind.** Exploring a console creates things. Clean
+up, or say what you left.
+
+## See also
+
+`widget-model`, `driving`, `finding`, `drive`, `browser-driver`, `widgets`

package/python/xactor/man/xylon.md

@@ -0,0 +1,120 @@
+# Xylon
+<!-- group: Concepts -->
+
+Every session in this project, and what each one changed.
+
+A xylon tree records sessions as **files**, four levels down:
+
+```
+{project}/{repo}/{issue}/session3
+```
+
+An **Issue** is a working copy on a branch of its own — the unit of isolation
+between agents — and every session that has ever worked in one is a sibling file
+inside it. Yours is one of them. Each holds its transcript, a summary, the files
+it touched and what it cost.
+
+Sessions are siblings, never nested. A child created by `agent` or
+`session_fork` is the next `sessionN` beside you, with `parent` on its header
+naming the one it came from; so is an extension, and so is a compaction — which
+does not create anything at all, but carries on writing into the same file.
+
+You read the tree with the `xylon_*` calls. You do not write to it — it is
+written for you.
+
+**To find something, search.** `xylon_search` looks through what was said in
+every conversation in the project and returns the tasks it came up in;
+`xylon_read_turns` then reads the few turns around a hit. `xylon_read_messages`
+is the whole transcript, tool output included, and is for when you need exactly
+that.
+
+## Session paths
+
+The grammar matters more than any individual call:
+
+- **`.`** — this session.
+- **`..`** — the session yours came from, which is `parent` on your header
+  rather than whichever session happened to spawn you. For most children that is
+  the spawning session; for an unbriefed `agent(extend=True)` child it is the
+  checkpoint it inherited, and the live parent is a sibling.
+  `xylon_read_messages('..')` reads whichever it is.
+- **A bare `sessionN`** is a sibling in your own issue.
+- **Anything with slashes is absolute**: `widgex-ide/fix-relay/session3`.
+
+Relative paths need a session that already has an address, and `..` on the first
+session in an issue is refused — it came from nothing. A relative path combined
+with a different `tree_name` is refused too: there is nothing for it to be
+relative to over there.
+
+## Working and saved trees
+
+`xylon_list_trees` returns two lists:
+
+```python
+{"working": [{"name", "sourceName", "path", "createdAt"}],
+ "saved":   [{"name", "sizeBytes", "modifiedAt"}]}
+```
+
+**Working** trees are unpacked on disk and live. **Saved** trees are `.wxylon`
+archives — history, not something in progress. A name can appear in both.
+
+A checkpoint is written whenever the conversation crosses a boundary it cannot
+carry: a compaction, a change of provider, or an `agent(extend=True)` that
+supplies a summary — a summary written by hand is as good a checkpoint as one
+derived at a compaction, so it is banked rather than thrown away. All three write
+onto the session they describe, and in all three the chat itself is unbroken,
+because the boundary is a fact about context, not about the conversation.
+
+Each session's transcript is a `.cosm` file: a JSON header, a `---` line, then
+the conversation as JSONL. The header carries `name`, `repo`, `createdAt`,
+`branch` (the one the issue started on, which cannot change), `parent`,
+`summary`, `summaryKind` (`'handoff'` or `'final'`), `files`, and `usage` —
+tokens and cost per `<provider>/<model>`.
+
+**Once a session is sealed its transcript is gzipped in place**, and inflated
+again whenever anything reads it. The header stays plain text on the first line
+either way, which is what keeps listing the tree cheap.
+
+## What is recorded, and what is not
+
+The header's `files` is the paths `api.write_file` and `api.edit_file` touched,
+in the order they were first touched. **That is all of it** — no contents, no
+before-and-after, no per-turn breakdown. What the file *said* at any point is
+git's to answer, on the branch the Issue owns.
+
+**Changes made by `api.bash` are not recorded at all.** A `sed -i`, a
+`git checkout`, a generated file — none of it appears in `files`. If you want a
+change on the record, make it with the file api.
+
+## Reading it
+
+```python
+me     = await api.xylon_get_node(".")           # header: summary, files, repo
+parent = await api.xylon_read_messages("..")     # what spawned me
+```
+
+## Getting it wrong
+
+**Expecting bash edits in `files`.** They are not there. This is the single
+most common surprise about the tree.
+
+**Reading `..` for context by default.** It works, and a transcript is large. A
+child briefed with `agent(wait=False, summary=...)` costs a fraction of it; the
+fallback exists for when the brief turns out to be insufficient.
+
+**Assuming `..` is the session that spawned you.** It is the node whose summary
+you hold. Briefed, that is your spawner's sealed node; unbriefed, it is an older
+checkpoint and your spawner is running alongside you, not above you.
+
+**Combining a relative path with `tree_name`.** Refused, with a message saying
+so.
+
+**Assuming `saved` trees are live.** They are archives. Working trees are the
+ones with a `path`.
+
+**Expecting to write to the tree.** There is no such call. Summaries and the
+file list are produced by the IDE.
+
+## See also
+
+`xylon_read`, `agent`, `session_fork`, `sessions`, `bash`