0.7.0 - 2026-10-24

Release Notes

Reads that get past a challenge, a knowledge base per site, and an agent that
prepares a site itself. A read a site answers with a challenge page now
recovers in the browser installed on the computer, and every request in that
mode carries that browser's user agent; a change is still sent once, over
direct HTTP, after a single-use approval. itda writes down what it found and
tried for each site, itda fsck lists what was never tried or keeps failing,
and itda_shape shows the shape of a page or an answer without its values.
When setup keeps one read or none, itda_prepare lets the agent draft the
site from its docs, seeing shapes and evidence, never what the site holds.

Added

• itda_prepare, one MCP tool for an agent to prepare a site that
  itda_setup drafted thinly, as a loop the agent runs: start, recon
  (the entry page, the API description it links, its GraphQL schema, the
  routes its docs name and a draft itda made, each with an evidence id),
  read, search, propose, verify, review and install. itda calls
  no model and the agent never sees a value the site holds: only titles,
  paths, methods, field names, selectors, keys, types, pointers and counts.
  Each proposed operation is kept only when the evidence carries it (a
  documented or answering server, the route in the docs or a page at that
  path, something to check in an HTML answer), a declared read whose request
  asks for a change becomes a change, a route that needs a sign-in itda
  cannot use is dropped, and a draft that only reads the home page is
  refused. verify tries the kept reads through the same path every call
  takes, fills inputs from earlier answers with $result:<read>:<pointer>
  (scalars only), adds required_pointers from the field names at the top
  of the answer, says in counts where a page read's selectors miss, and
  never sends a change. Reads go only to the site's registrable domain and the
  hosts it links as documentation. A session has 120 calls, 48 page
  requests and 24 check requests (browser recovery counted), 6 reads per
  verify and two coverage and two repair rounds. install takes the same
  path as itda_setup. When itda_setup keeps one read or none, its result
  carries a remedy that names itda_prepare. recon with bundles: true
  also reads the scripts the entry page loads and keeps a route string only
  when one GET answers with data. skills/itda-prepare/SKILL.md is the loop
  for skill loaders.
• Reads that a site answers with a challenge page can recover through the
  browser installed on the computer. itda fetches the page inside a hidden
  browser window kept for that one site and account and, for a GET, lets
  the page render. Every request in this mode, a change or a sign-in form
  included, carries the browser's user agent, and the hidden window keeps the
  browser's own client hints, so the site sees one client whichever way a
  request goes and a clearance the browser earned holds for the direct
  requests too. itda remembers which way worked for an hour, per site,
  account and action, so the next call does not pay for the failed try
  again, and forgets a way that
  failed after a few minutes. The browser session stays warm in a worker
  process across CLI calls and closes after five idle minutes; changing an
  input does not restart it. Everything the page loads passes the same
  address and read checks as a direct request: other sites get neither the
  account's credentials nor a referrer, private addresses stay refused, and a
  page may send a GraphQL query, never a mutation. A challenge the browser
  did not get past fails that one read (blocked_by_site, paused: false)
  without pausing the site. A browser answer may be up to 16 MiB. The worker
  keeps its files under browser-runtime/ in the data directory, one
  directory per itda build; a build's directory is removed a day after it
  stopped being used. ITDA_TRANSPORT=http keeps direct HTTP only, with the
  pauses it always had. docs/HONEST_CLIENT.md has the rules,
  docs/TRANSPORT_BENCHMARKS.md the measurements.
• A local knowledge base per site, in itda.db. Setup, check, refresh and
  every call write down what was found and tried: the pages and actions,
  which list read can supply which detail read's input, every try with its
  stage, verdict, HTTP status and time, and the hashes of the definition and
  the last verdict. It keeps shapes only (selectors with match counts, field
  names, keys and types), never an answer, input, cookie, header value or
  record. Nothing that sends a request reads it, and itda remove deletes a
  site's rows. A call itda refused before sending (waiting for an approval,
  a bad input) is not counted as a try.
• itda fsck [site] runs fixed rules over the knowledge base and lists,
  worst first, the reads never tried, the reads that need an input (with the
  list read and pointer that can supply it), the reads that fail every recent
  try or now and then, and a definition or verdict file changed under itda,
  each with the command to run. It sends nothing; exit 0, or 1 when a gap is
  at priority 1. Over MCP, itda_manage takes fsck, and each gap carries the next tool to
  call with its arguments. itda setup ends with the top three.
• itda_shape, a read-only MCP tool: the shape of a page (selectors with
  counts, named fields, the keys and types of embedded data) or of an
  action's last answer (keys, types and pointers), from the knowledge base or,
  with fresh, read now the way setup reads a page. At most 24 KB and no
  values.
• itda ls --json and itda_sites say per site how many actions answered on
  their last try (verified), the recent pass_rate and the reads that fail
  now and then (unstable). itda ls --json and itda_sites with a site add
  a user_guide (what can be read, what can be changed, how one read feeds
  another) and two to four natural_prompts, made by rule in the person's
  language; itda describe <site> prints both.

Changed

• The knowledge base records a preparation loop's tries under a stage of
  their own, prepare, and its notes under the prepare scope; the pass
  rate, the last success and the itda fsck rules leave both out.

• The honest-client rule changes: itda no longer stops at a challenge. Every
  request carries the installed browser's user agent, a read may run inside
  that browser after a challenge, and a challenged read no longer pauses the
  site. What stays: a change is sent once, over direct HTTP, after a
  single-use approval; credentials go only to their own site and account; one
  request at a time per site, with Retry-After respected, whichever way the
  request goes; captchas are not solved.

Fixed

• Opening itda.db could fail with internal ("Local file operation
  failed") when another itda process, the browser worker or the MCP server,
  closed its connection at that moment: SQLite removed itda.db-wal while
  itda was making it private. A file that is gone is now left alone.

Install itda-cli 0.7.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/brnyxx/itda-cli/releases/download/v0.7.0/itda-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/brnyxx/itda-cli/releases/download/v0.7.0/itda-cli-installer.ps1 | iex"

Download itda-cli 0.7.0

File	Platform	Checksum
itda-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
itda-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
itda-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
itda-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
itda-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum