Product Excellence 1.6.0

• The landing page describes journeys, one-sentence missions, operator-assisted
  runs, routes and network profiles.

• A journey can change the way out mid-run. A scenario step names a saved
  proxy route, or direct, and the connections that follow leave that way. The
  run owns a relay on its own machine and the browser or the emulator is pointed
  at it once, so the route behind it changes without a new session: the
  connections opened on the previous route are dropped, the new exit address is
  probed and recorded, and a route that cannot be established stops the run
  instead of quietly going out directly. A route may carry the link speed it is to
  be measured under. Upstream credentials stay in the relay and reach neither the
  page, the device nor the record.
  Only HTTP(S) upstreams can be switched to. What this establishes is the exit
  address per switch, nothing about country, ISP or carrier: DNS is resolved on
  this machine and UDP/QUIC is never proxied. Every browser engine and the
  emulator were accepted live against two tagged upstreams, each one's own
  request read back on the route that carried it; the transcripts are kept in
  artifacts/route-live/.

• An Android journey can take a route too. The emulator is launched against
  the run's relay with -http-proxy, so nothing in the guest holds a proxy
  setting and no app can opt out of it. The designated AVD must not already be
  running: one that is was never launched against this relay, and the run says so
  before touching a single setting on it.

• An Android mission can name a network profile. Its latency and bandwidth are
  applied through the emulator console, which the transport gate measured to
  change traffic on the mobile radio only — so a profile that shapes takes the
  device to mobile data first, and shaping asked for over Wi-Fi is refused rather
  than reported as applied. The profile is the condition the run is measured
  under, not a fault in it; a network: restore step goes back to it, and the end
  of the run goes back to the device's own settings. Offline, jitter, loss,
  reordering and periodic disconnects were never measured there and are refused.
  The full transport gate transcript is kept in artifacts/android-gate/.

• A mission starts from one sentence. The new mission form opens on What do
  you want to find out?. Write it in your own words and four whole missions come
  back as cards, in two groups: two the worker works out for itself from the goal
  alone, and two scenarios with every step already written, in order and in plain
  words. Each card says what it would change — Chromium for a shaped link, a person
  at the screen for a manual step, an Android target for an app event — and what
  has to exist first.
  Use this goal or Use this scenario fills in the name, goal, mode, pillars
  and steps, and raises the time and action budgets if the steps need the room.
  Nothing is saved and nothing runs until you press Save mission or Save and
  run.

• A mission the worker gets wrong no longer costs the whole answer. One
  suggestion that does not fit the contract is dropped and named underneath the
  cards that survived, instead of failing the minute you waited for.

• Change a mission by describing the change. Change something takes a
  sentence such as "add a relaunch before the last check" and returns the whole
  mission changed, as one card you apply the same way. Undo, beside the
  mission heading, puts back the name, goal, steps, mode, pillars, browser and
  budgets exactly as they were before the last thing the worker filled in.

• Steps read as a list before they read as a form. The Steps section shows
  the scenario as numbered sentences; Edit steps opens the rows and closes them
  again. Shipped journeys, the sentence drafter and the YAML editor moved under
  Other ways to get steps, and all four spellings stay the same steps.

• A manual step can name the value it needs, such as a one-time code, in its
  own field. The name is saved; the value never is.

• Write it yourself opens the same empty form, so every manual tool and every
  saved setting stays reachable with no AI worker signed in.

• A run can ask you which way to sign in. A screen that offers a password, a
  code by SMS, a code by a call and a Google account is asking which way in, not
  for a secret. Web runs and Android journeys now pause with those options as
  buttons on the run page; you pick one and the run clicks or taps it and carries
  on. Skip and Stop run stay beside them.

• A run can ask you for a value instead of giving up. When a web run or an
  Android journey reaches a field it has no value for (a phone number, email,
  username, password, one-time code, authenticator code or card details), it
  pauses and the run page asks for that value, with Skip and Stop run
  next to it. The value is filled into the field, masked in screenshots and
  scrubbed from the saved evidence, and never stored in the run.

• Missions can carry an ordered scenario, on Android and on the web. Up to 40
  steps on one device or in one browser page: goals for the AI worker, checks
  that a fact becomes true, holds that a fact stays true, events done to the
  device or the page, and manual steps handed to the person sitting at it. One
  vocabulary and one interpreter serve both platforms; the target decides what a
  step acts on. A mission without a scenario runs exactly as before. Two things
  differ on the web: link shaping needs Chromium, and a saved device state cannot
  be loaded, because a website mission carries its session through a persona.

• Twelve shipped journeys, none of them tied to a platform, cover the
  questions that need state: playback across a transport switch or a dropped
  connection, a download over a weak link with pauses, downloads and search
  history per account, a notification opened much later, a shared link opened
  while signed out, a session and a filter across a restart, sign-out that really
  signs out, back after a search, a form rejecting bad input, and checkout up to
  payment on a slow link.

• A journey gallery, and fill in the blanks. Missions → Start from a
  journey searches the twelve by name, description and tag, says what each one
  needs, and opens the mission form with the target, name, goal, time limit and
  steps already set. Every blank a journey leaves is listed above the steps with
  its own labelled field; filling one fills every occurrence across the name, the
  goal and the steps. The run button says how many are left and stays disabled
  until none are, and the server still refuses a mission that holds one.

• screen replaces activity as the fact for where the app is: the focused
  activity on Android, the page address on the web. A new back event goes
  back on either platform. Drafting works from the goal when no sentence is
  given, and the time limit fits itself to the waits a journey commits to.

• A guided builder, and the same steps as YAML. Ordered rows with native
  controls for every step kind, event and fact; move, duplicate and remove from
  the keyboard; a budget line that offers to raise the limit when the waits need
  more time. The advanced view spells the same steps as text, and text that does
  not parse stays in the editor instead of replacing working rows.

• Draft the steps from a sentence. The signed-in AI worker writes a first
  scenario, validated against the same schema the form uses. Nothing is replaced
  until you say so, and drafting never touches the device.

• Manual steps without recording credentials. Recording is stopped and
  confirmed stopped before the operator notice appears. The run page shows the
  instruction, the paused recording, the real remaining time and a Continue
  control; the recording resumes afterwards and the gap is reported.

• The run page shows the scenario. A numbered progress strip and a step
  table, each step reporting a word and its evidence rather than a colour.
  Measurements that were not available and questions about intended behaviour
  are listed apart from the defects, and a refresh no longer takes the control
  out from under you.

• Evidence that cannot be read is never read as a failure. An unreachable
  screen, an unknown foreground package or a parser error makes a step
  unavailable: a coverage gap, not a defect.

• Unconfirmed behaviour is a question, not a defect. A check marked
  policy: unknown is recorded as an observation with severity info. It deducts
  nothing and blocks nothing.

• Start state is explicit. Fresh app data, keep what the last run left, or
  load a device state saved on this Mac. Saved states live under Settings →
  Android device: never overwritten, validated against what is on disk before
  they load, and refused while a run owns the device.

• Comparison says what it can establish. Matching conditions and the right to
  call a finding reproduced are answered separately, with the actual reason when
  a reproduction cannot be claimed: a different build, a start state that was
  inherited rather than established, an operator attestation, or a required step
  left without evidence.

Product Excellence 1.2.0

• The repository is brand-neutral. New installations start with an example
  workspace and ten generic missions. Site-specific preset packs, profiles,
  live-test targets and published historical claims were removed; private local
  runtime data is left untouched.
• The product tour remains intact. Static image assets and the README image
  gallery are preserved, while the surrounding source text uses neutral terms.