0.5.0 - 2026-10-23

Release Notes

Uglier sites, fewer steps, and a bundle for Claude Desktop. itda setup now
reads pages whose content sits in frames, signs in with a password without a
browser, follows a session carried in the address, turns pages, recognises
known software, and refreshes a definition when the site changed. The landing
page says plainly what works and what does not. Every release now carries an
MCP Bundle per platform, so Claude Desktop installs itda by opening a file.

Added

• Frames: when itda draft page or itda setup fetches a page that is a
  shell whose content lives in one or more <iframe src> (or an older
  frameset) on the same origin, and the page has nothing of its own to read,
  itda fetches each frame page as itself, on the same pacing and with the same
  session, and drafts from the frame pages as pages of the site, each under
  the frame's own address. At most four frames are followed, at most two deep;
  a cross-origin frame, and a same-origin frame that answered with nothing,
  are listed in the notes and never fetched. The setup lines and the draft say
  what was followed ("Followed 1 frame: /frame/board."). itda refresh
  follows them again.

• Query sessions: a site that carries its session in the URL as a query key
  (?sid=...) rather than a cookie now gets a kind: browser auth entry with
  value_from: query:<key>. itda draft har, itda record and itda setup
  recognise it when a sign-in's answer hands the key out (in the redirect
  Location or on the first signed-in page) and every signed-in call carries
  it: every operation that sent it gets auth: session, the key is dropped
  from the operations' inputs, and the value goes to the keyring, never into
  the definition. itda login <site> captures it from the sign-in the same
  way it captures a cookie. At run time the value is appended to the query of
  each request; it is redacted in results, error text, the audit log and the
  recording kept for a refresh (addresses, Location headers and the links in
  recorded pages). value_from on a browser entry now accepts query:<key>
  beside cookie:<name>, with a validation error for anything else. Because
  the value rides in URLs, docs/THREAT_MODEL.md notes it can reach server
  and proxy logs. The definition format is unchanged: spec_version stays 1.

• cargo xtask check-changelog, run by CI: the changelog has one of each
  section per release, the newest release matches the workspace version, and
  the landing page and quickstart print the same version. CONTRIBUTING.md
  says what a minor and a patch version mean before 1.0.

• Sign in with a password, without a browser: a login block on a browser
  credential names the site's sign-in page and its user and password fields,
  and itda login <site> --user me reads the page as itda, fills the form
  in with the password you type (or pipe on stdin), sends it once with the
  hidden fields and cookies the page gave, and keeps the session the way a
  browser sign-in is kept. A redirect means the site accepted it; the form
  coming back is reported, never retried. itda setup <page> --user me does
  the same when the page needs a sign-in (a redirect to a sign-in page, 401
  or 403, or a "log in to see this" page that links to one), drafts from the
  page as you see it signed in, gives every action auth: session and writes
  the login block from the form it found. Over MCP, itda_setup never
  takes this path. --secret on itda login now names the API key path
  explicitly (api-key stays the name when the site has no sign-in form).

• examples/lab: Gitea, Redmine, WordPress, MediaWiki and a small legacy
  intranet (intranet/server.py, standard library only) in Docker Compose,
  pinned by digest, on fixed local ports, with one seeded account and a
  little content each, plus reviewed definitions in specs/. With
  ITDA_LAB=1, apps/cli/tests/lab.rs walks each one from itda setup --user through itda login, a read, a change approved in a terminal and
  the audit log. CI never runs it.

• examples/lab: three uglier intranets alongside the five, to measure what
  itda does on pages built the harder ways (intranet/framed.py,
  scripted.py, urltoken.py, standard library only). framed (8086) keeps
  the notices table two iframes deep, so setup from the home page finds only
  the shell; pointed at the frame it signs in and reads and writes the board,
  and specs/framed.yaml runs to an approved change. scripted (8087) draws
  the table from GET /api/notices in a script, so itda setup --watch-only
  watches the browser load it and drafts the read, and specs/scripted.yaml
  posts with the X-CSRF-Token from <meta name="csrf-token">. urltoken
  (8088) carries its session in ?sid= with no cookie; with frame following
  and query sessions in this release, setup signs in, reads the sid from the
  sign-in redirect and keeps it as a value_from: query:sid session, and
  specs/urltoken.yaml runs to an approved change. README.md records the
  measured outcome per case; the one itda cannot do yet - signing in from a
  shell whose frame redirects to a login, so framed from the home page still
  finds only the shell - is a test marked #[ignore] with the reason.

• Sites that run known software are recognised. itda setup reads the
  page's HTML for GitLab, Jira, Confluence, Redmine, Discourse, MediaWiki,
  WordPress and Gitea or Forgejo (a generator meta, well-known asset paths,
  the Atlassian context-path metas, body classes), confirms the guess with
  exactly one GET to that software's own version or info endpoint, and then
  drafts from a template under sites/software/ instead of reading the page
  like any other: the reads an agent needs most, up to three changes marked
  as such, models and the software's own way of signing in, every operation
  with its documentation in evidence. The template's base_url is filled
  with the instance's API base, context path included (/jira, /w, a
  GitLab relative URL root, a Gitea appSubUrl, the WordPress API root the
  page links to); the site is named after the host; one line says so ("This
  looks like GitLab. Using its API at ."). The page draft still runs
  and its lists, forms and feeds join the template, the same method and path
  drafted once, and a page that needs a sign-in or scripts still gets the
  template when the software is confirmed. A fingerprint the API does not
  confirm is dropped quietly. itda setup --as <software> forces a
  template, --no-template skips them, itda check works on the result as
  on any site, and itda_setup over MCP takes template and names the
  template it used in its result. The site's sources.json names the
  template and its API base, so itda refresh fills the same template
  again, with the page read again when it still opens.

• itda refresh <site>: when itda check says site_changed, draft the
  site again from the sources it was set up from and merge the result with
  the installed definition. The site's name, title and address, defaults,
  auth and every action edited by hand are kept; actions the draft
  changed take the new version, ones it no longer drafts are dropped only
  when their read also failed, and new ones are tried once and added when
  they answer. The diff is printed in plain words (added, removed, changed,
  kept as edited) and written after a yes, or at once with -y; the site
  is checked right after and the verdict printed. Approvals for the site
  are withdrawn, as for any replaced definition: what the user reviewed is
  no longer what would be sent.
  To make that possible, itda setup, itda draft ... --install and itda record --install now write specs/<site>/sources.json next to the
  definition: the pages, the API description, the GraphQL endpoints asked,
  the recording when one was kept (copied under the site as
  recording.har with its cookie, token and session values, private
  fields and sign-in answers blanked), the draft's options and a hash of
  every operation as drafted. itda check now points at itda refresh <site> when a site
  changed, and itda check --all prints one verdict line per site.

• itda_manage over MCP gains refresh: the person confirms the diff in a
  form (a form nobody answers counts as no), and the site's tools are
  reloaded and checked. itda_check without a site already checks every
  site; the docs now say so.

• itda draft page and itda setup read a page that is one thing (an
  article, a package, a product, a bug) as its own content: the headline,
  the body text, what sits beside the headline, a date, an author and the
  values the page labels in definition lists and label-value rows, as
  html.page fields that each match once. Such a page used to be one read
  that checked the title. A page that is one thing with a named list of
  records on it (a package with its releases) gets both reads, and itda setup says "the page's own content" when it finds one.

• Repeated siblings of one shape become records when they share a title at
  one place: a link as before, or a heading, a text named as a title, or
  the record itself when it is a link with something inside. The fields come
  from what the records share: a summary, a byline, a date, and whatever
  sits under a class the site named (score, author, release__version
  becomes version), with build names left out and a text that reads as a
  date as published_at. Bare paragraphs, bare links and menus never
  qualify. A list read is described by what its records are (List the projects on Projects) when the page names them.

• A list whose links share one shape (/item/{id}, view.php?id=) gets a
  read of one record by its id, with the query keys every link sends as
  inputs with defaults and no response check yet.

• The page input follows the link marked rel="next" and starts at 0 for
  offset and start.

• itda setup watches what a page drawn by scripts loads by itself before
  asking anyone to record. When the page shows itda nothing but a title,
  carries scripts that could fetch something (a script file or a preloaded
  module, or an inline script that imports a module or mentions fetch,
  XMLHttpRequest, graphql or api) and a
  browser is installed, it opens the browser on the page in the same fresh
  profile recording uses, waits until the network has been quiet for two
  seconds (ten at most), scrolls once to the bottom, waits again, closes the
  window and drafts from the recording the way itda draft har does, the
  page's own address first so what the page itself shows is never lost to a
  busier API elsewhere. One line says what it saw (Watched the page load: 12 calls, 3 reads drafted., in English or Korean, counting the reads
  beyond a title check); only when no such read came out does it ask to
  record as before. Nothing in the window is clicked or typed, nothing it signed in
  with is kept, and a page whose scripts go to a sign-in page stops with the
  same auth_required words a redirect gets. --no-record skips the window
  too; a new --watch-only watches but never asks to record, for scripts.
  A site whose software is recognised gets its template instead and is not
  watched. itda_setup over MCP does the same, and says in its description
  and its result that a window opens briefly on the user's screen.

• Reads that list things can turn pages. A definition declares
  pagination (style: page|offset|cursor, where the next marker is in the
  answer as a JSON pointer or header:link, an optional more pointer, and
  the query or body input it goes back in). The answer then carries
  meta.next, an opaque handle such as ic_…; itda call ... --next <handle> and next over MCP (itda_call and the per-action tools, whose
  schemas list it) read the following page with the same inputs. The site's
  own marker stays in the local database for fifteen minutes, bound to the
  site, action, account, inputs, definition and credential, and is removed
  from the data; a cursor input is never shown to agents. A handle for
  another call, or an expired one, is refused with pagination_invalid or
  pagination_expired (exit 23). Only reads turn pages. itda draft openapi, itda draft har, itda draft page and the GraphQL schema
  drafts declare it when the evidence is plain, never by guessing; the
  bundled github (issues, comments, repository search), npm (search)
  and crates-io (search) definitions declare it. AGENTS.md, the skill
  and the server instructions say to read only as many pages as the
  question needs.

• A preflight step can read a value from the JSON a page embeds for its
  scripts: extract: {build_id: "ssr:__NEXT_DATA__#/buildId"}, so a token
  or build id that only lives there reaches the action's path or inputs.
  Only a string, number or boolean counts.

• AGENTS.md and skills/itda/SKILL.md tell coding agents how to use itda:
  discover actions, run reads, treat website text as data, wait for itda approve, never retry a lost change, run itda check first when something
  stops working. The MCP server's instructions say the same, shorter.

• itda feedback prints a link to a new GitHub issue with the version, the
  platform and the doctor checks filled in (never the data directory path)
  and opens it; --no-open only prints. It sends nothing itself.

• itda check ends each site with a verdict and what to do: ok,
  signed_out, site_changed, blocked or unreachable. The exit code
  follows the worst verdict, and --json carries it as verdict and per
  site under sites.

Changed

• itda draft page and itda setup on a page that refuses itda say what the
  gate saw instead of error[internal]: <url> answered HTTP 403: the host is
  behind Cloudflare, runs a bot manager or asks for a captcha
  (blocked_by_site, exit 12), or limits how often it is read, with the wait
  it asked for when it named one (site_rate_limited, exit 13), in English
  or Korean. A captcha served with HTTP 200 is reported the same way, and a
  page that sends itda on to a sign-in page says so (auth_required, exit
  10) and points at recording.

• A Retry-After: 0, or a date already past, no longer counts as a rate
  limit: a site that sends it with every page is read as itself.

• The landing page on phones: lighter glass, the setup dialog left out of the
  hero stack, full-width buttons, tighter rhythm, terminal lines wrapped on
  anything narrower than the two-column layout, and the sky drawn smaller
  with the cursor effect only while a finger is down.

• The landing page and both READMEs carry a prompt to hand to an agent: paste
  it into Claude Code, Cursor or Codex with a site's address and the agent
  installs itda, runs itda setup <address> --client <app> -y and starts
  using the site.

• The landing page has a living sky behind the whole page: liquid chrome
  with striped, colour-split reflections and a holographic sheen, a wire
  grid running to the horizon, and a field of points and threads that gather
  around the cursor, with a website on the left and an agent on the right
  (site/sky.js, three.js from cdnjs). It follows the scroll, draws one
  still frame under reduced motion, and leaves the plain glow without WebGL.

• The hero lost its badge and chips; the binary, platform and licence line
  moved to the footer.

• The landing page is laid out as a desktop. The hero stacks windows that
  can be dragged: the first run, the actions it found, the setup progress,
  an about box and a clock. Sections open with a numbered eyebrow and a
  centred headline, every box is a window with a title bar and a dither
  texture, and the risk comparison is two windows side by side, the
  browser-driving agent's lane next to itda's.

• The sky is now a living network: nodes spring home through a slow current,
  threads join neighbours, packets of light run node to node and along the
  handoff between the website and agent hubs. The cursor is a node too:
  nearby nodes gather and orbit it, its motion leaves a wake, threads run
  from it, and a click sends a ring through the field. Node count follows
  the viewport, with a lower cap on touch screens.

• The landing page's components now speak the same language as the sky:
  smoked-glass panels with a chrome hairline and faint scanlines, chrome
  headlines with a holographic accent, glossy pill buttons, Aqua-style
  window lights on the terminal, and chrome coins for the step numbers.

• itda <address> sets that site up, and itda github (or npm, crates-io,
  pypi) adds the ready-made site and connects the agent apps found on this
  computer; the README's one line is the one line you type. The tagline and
  the landing page say so.

• action_outcome_unknown now says that itda never resends a change on its
  own, and the runtime tests prove it against a server that drops the
  connection after taking the request.

• A bare itda in a terminal says what it is and asks for one address, then
  runs itda setup on it, so the first run is: type itda, paste, Enter.

• itda setup finds the agent apps on this computer (Claude Desktop, Claude
  Code, Cursor, Codex, or a project with a .vscode folder) and connects them
  all after one Enter; the numbered list only appears when none is found.

• itda setup asks whether the site needs a sign-in only when the page it
  fetched has a password form; a page without one is used as it is.

• The installer ends with "Open a new terminal window and type: itda".

• At the first prompt, a ready-made site's name (github, npm, crates-io,
  pypi) installs that site and connects the agent apps found on this
  computer.

• After adding itda to Claude Desktop on macOS, itda offers to restart the app
  when it is open, or says that opening it is enough; for Claude Code it runs
  claude mcp add itself when claude is on the PATH.

• itda doctor lists the agent apps whose settings already start itda.

• itda setup on a page of pypi.org, github.com, npmjs.com (with or
  without www.) or crates.io uses the ready-made definition itda add
  installs for it, says "This is PyPI. Using its JSON API." (or the site's
  name and API), does not fetch the page and tries the definition's reads;
  --no-template reads the page instead. itda_setup over MCP does the
  same and puts the line in its notes.

Removed

• The browser-fetch and browser transports and the derived credential
  kind, left over from the port: no code ran them, and a definition that named
  them was accepted and then refused at run time. itda add now refuses them
  with the field named.

Fixed

• Signing in from a shell whose frame redirects to a login. When a page is a
  shell and its same-origin frame answers with a redirect to a sign-in page,
  itda setup now treats it as if the top-level page had: with --user it
  signs in through that form and reads the frame again with the session, then
  drafts from it, instead of drafting only the shell's title. Following the
  frame's redirect to read the login form is a read; nothing is posted without
  the person's credentials and the usual consent. Without --user, setup names
  the sign-in the frame leads to, and itda draft page notes that the frame
  leads to a sign-in rather than only that it was not read.
• Approving in the client works on MCP protocol 2026-07-28, which Claude
  Code 2.1.289 negotiates: that revision took server-to-client requests
  away, so the elicitation/create request itda sent was dropped unseen
  and the call hung until itda gave up. itda now hands the form back as the
  call's result (resultType: input_required), the client shows it, and
  calls again with the answer and the approval id as requestState; the id
  only ever names an approval itda stored for this very call, and anything
  else is asked again. The confirmations itda_manage and itda_login put
  to the person go the same way. Clients on the earlier handshake keep the
  request they had. The review the form shows no longer starts with a blank
  line, and leaves "as account" out when the site has no accounts: Claude
  Code cut a five-line review to its first three and hid the request and the
  inputs behind "(+2 more lines)", and shows the four-line one whole.
• A change answered with a redirect (post, then redirect, then get, as
  Gitea, Redmine and most server-rendered sites do) is reported as landed,
  with the address the site pointed at, instead of request_failed. A
  redirect to a sign-in page is reported as auth_required, since the site
  is asking for a session it no longer accepts.
• The cookies a preflight step's answer sets go along with the change, so a
  Rails site (Redmine) that rewrites its session cookie on every answer
  accepts the token it just handed out.
• A read redirected to an address itda will not follow, such as a sign-in
  page with a reauth parameter (WordPress), is answered as the redirect it
  is instead of failing with bad_url, so itda setup can name the
  sign-in page.
• Two itda processes starting on a fresh data directory at once (the MCP
  server and itda approve, say) no longer race in the database setup:
  Store::migrate reads the schema version and applies the steps in one
  immediate transaction.
• A GraphQL document nested deeper than 32 levels is refused before it is
  parsed, with a clear message in a definition's default and bad_request
  for an agent's input, instead of running the parser out of stack.
• api_denied (exit 14): a 403 that is not a sign-in problem says the site
  refused that one request as not allowed, with upstream_status and, when
  the site's JSON answer names one of a short list of reasons,
  provider_reason; nothing else from the answer is passed on. A 403 whose
  reason says the session was rejected stays auth_required. Every refusal
  now carries upstream_status, and itda check counts an address answered
  with 404, 405 or 410 and a query answered with errors (query_failed,
  exit 11) as site_changed.
• approval_pending (exit 20): a call with an approval the user has not
  answered yet is told to wait and call again with the same id, with the
  command to run in command; the approval stays. A call with other inputs
  withdraws the approval (approval_expired, reason: inputs_changed).
  itda reject also withdraws a granted approval, and itda logout, itda remove, a new itda login and replacing a definition withdraw every
  approval for the site or account. The review itda approve prints, and the
  form an MCP client shows, name the action, say what it does in the
  definition's words, and cut a value longer than 500 characters with its
  length.
• A read is classified again after its preflight steps with the found values
  filled in; one that would now be a change stops with effect_changed
  (exit 2) and is not sent. Headers and inputs that override the method
  (X-HTTP-Method-Override and the like) are refused at install and before
  sending. A GraphQL answer that carries errors behind a 2xx is
  action_outcome_unknown for a change and query_failed for a read, never
  a success.
• itda audit and itda doctor show a change_started record with no
  outcome after it as a change with an unknown outcome (the process stopped
  after it was sent), and itda_manage audit returns them under
  unknown_outcome. A change that failed before anything left the machine
  (no turn at the gate, a name that did not resolve, a refused connection)
  keeps its network code and is reported as not sent instead of unknown.
• Long secrets are sealed into vault.sealed under the data directory
  (AES-256-GCM, a fresh nonce per write) with one 32-byte master key per data
  directory kept in the system keyring; every browser session goes there,
  and so does anything over 1024 bytes or that the keyring refuses as too
  long (Windows Credential Manager caps a credential at
  CRED_MAX_CREDENTIAL_BLOB_SIZE, 2560 bytes). API keys stay in the keyring.
  Existing entries keep working and move on their next write, in both
  directions; itda doctor says where secrets are. The cipher comes from
  aws-lc-rs, already built through rustls.
• itda describe <site>[.<action>] prints each action's inputs and a command
  to copy, with a placeholder for every input it cannot run without;
  itda ls --json carries the same command as example. An unknown site,
  action or input names the nearest one ("Did you mean"), in the CLI and
  over MCP.
• itda mcp --site <name> serves one site only: its actions are the only
  tools, itda_setup is refused, and the other management tools stay inside
  it.
• Two more ways to install, from the next release on. Every release carries
  one MCP Bundle per platform (itda-<target>.mcpb): open it and Claude
  Desktop installs itda with its tools, no terminal needed; approving a
  change still happens in a terminal with itda approve. The bundle is
  packed by cargo xtask mcpb from the release archives, with a manifest
  that follows the MCPB spec (manifest_version 0.3, server.type
binary, itda mcp as the command). A winget manifest for 0.4.0
  (manifests/b/brnyxx/itda/) is ready to submit to winget-pkgs and is not
  submitted yet.
• Five MCP tools so an agent never needs a terminal to set a site up or
  look after it: itda_setup (look at a page as itda, draft, try every
  read once, keep what works; the site's actions become tools in the same
  session, announced with notifications/tools/list_changed, which the
  server now declares with tools.listChanged), itda_login (the person
  signs in in their own browser, after a form in clients that show one;
  the definition must name the sign-in cookie), itda_check (the verdict
  per site, as itda check --json), itda_sites (what is set up, with
  the last check's time and verdict, now kept in specs/<site>/check.json)
  and itda_manage (remove and resume after the person confirms in a
  form, approvals, audit). itda_setup never asks anyone to record and
  never keeps a credential; pages that need a sign-in, or still show nothing
  after the watched load above, are refused with the command to run
  instead. The server instructions, AGENTS.md and the skill say when to
  call them.
• A new itda-setup crate holds the steps behind itda setup, itda login --browser, itda check and the installed sites, with the questions
  answered through a trait and progress reported through a callback, so the
  command line and the MCP server run the same code. The CLI's words and
  questions are unchanged.
• itda draft page and itda setup draft a typed read for each list they
  find in a page's embedded data, instead of one read that returns the whole
  payload: an ItemList or a list of one typed thing (NewsArticle,
  Product...) in ld+json, and in __NEXT_DATA__, __NEXT_F__,
  __APOLLO_STATE__, __PRELOADED_STATE__ and the like the list of objects
  with the most to read. Each read is named after what it holds
  (list-news-articles), points extract_pointer at the list and keeps up
  to eight plain fields of every record through a model, ids and titles
  first and credentials left out. itda check counts its records. The whole
  payload is drafted only when no list is in it.
• An Apollo cache (__APOLLO_STATE__) is also grouped by typename, so a
  definition can point at /Question or /Product.
• defaults.interval in a site definition asks for more time between
  requests to that site (2s, 500ms, up to 30 s). itda's own pace, one
  request at a time per site about 1.2 seconds apart, is the floor; a
  definition can only slow it down. A value that is not a time is refused
  by itda add.
• A site that answers a read with 429 or 503 and a Retry-After of ten
  seconds or less gets that wait, once, and the read is tried again. A longer
  wait stops the read with site_rate_limited, itda check reports the site
  as blocked, and the error, the check result (retry_after_s) and the MCP
  server instructions say how long the site asked for. A change is never sent
  twice.
• Requests queued in one process now take turns in order instead of polling
  the shared gate against each other.
• A draft that sees a GraphQL endpoint (a recorded call to it, or a page
  naming a same-origin /graphql path) asks it once, with the standard
  introspection query, what it offers, and drafts one read per root Query
  field whose arguments are scalars, enums or ids: the field name is the
  action, the arguments are typed inputs, and the selection is the field's
  scalars two levels deep, 24 at most. An optional argument that holds an
  object or a list is left out and listed; a field that requires one is
  listed instead. Mutation fields are listed in the notes and never
  drafted. A site with introspection off is drafted from
  its pages and calls alone. The query is sent as itda, read-only, with a
  size cap, by itda draft page, itda draft har, itda record and
  itda setup.
• An optional input the agent leaves out now leaves the json_template
  body too, instead of standing in as an empty string where a number or
  null belongs; GraphQL variables typed Int or Boolean need that.
• itda draft page and itda setup read the API description a site
  publishes: the one the page links to, else /openapi.json on the same
  origin when it answers with one (one GET, as itda, at most 4 MB). Its reads
  join the draft the way itda draft openapi makes them, drafted once when the page already had the same path;
  its changes become notes, and a read keyed by a credential input is left
  out and listed. A description on another address is noted, not merged,
  and one that does not parse leaves the page draft as it is. The
  header comment and each merged action's evidence name where it came from,
  and itda setup says what it read in one line.
• Requests send Accept-Language: * (no preference) instead of
  ko-KR,ko;q=0.9,en;q=0.8, a value left over from the browser header block
  itda was derived from. pypi.org answered a project page asked for with any
  Korean Accept-Language (ko, ko-KR or that list) with a 3 KB "Client
  Challenge" page and kept challenging every request from the same address
  for a few minutes after, so itda draft page https://pypi.org/project/requests/ drafted the challenge instead of the
  322 KB page. Leaving the header out is not enough: amazon.com then sends a
  gzip body itda does not decode. A definition that needs a language can
  still set one in defaults.headers.
• A challenge page served with HTTP 200 (small, titled as a challenge, only
  a script and no link to follow, as bugzilla.mozilla.org's bug list and
  pypi.org answer when they challenge) now counts as a block: the site is
  paused, itda draft page and itda setup say the site's bot protection
  refused itda (blocked_by_site, exit 12), and itda check says
  blocked. Before, it was drafted as a read named after the challenge and
  checked as ok.
• Drafts leave ad slots out of a page's records (an element whose class, id
  or label marks it as an ad: AdHolder, ad-*, sponsored,
  aria-label="Sponsored"): when ads share their classes with the records
  beside them, the records' selector excludes the ad class. On amazon.com
  the draft had picked the sponsored results, which are not there when the
  first page is asked for by number.
• The page input a draft adds when a page links to its next page (page,
  offset, start and the like) has no default any more, so the read and
  itda check ask for the address the draft saw until an agent or a page
  handle asks for another page; the next page is still counted from 1, or
  from 0 for an offset. Sending page=1 made some sites answer with
  different markup and the check fail.
• A read the site blocks or challenges while itda setup tries it is left
  out with ": the site does not give itda this page", nothing more is
  sent to the site in that run (the reads after it are kept and shown as not
  tried, for the next itda check), and the site is not left paused, so a
  challenge on pypi.org's search page no longer takes the three feeds after
  it down too. itda check and calls on an installed site still pause it.

Install itda-cli 0.5.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/brnyxx/itda-cli/releases/download/v0.5.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.5.0/itda-cli-installer.ps1 | iex"

Download itda-cli 0.5.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