AbstractFramework 0.7.0

Email for each user, and installer fixes. Pins: AbstractCore 2.20.1, AbstractRuntime 0.8.0,
AbstractGateway 0.8.0 and AbstractAssistant 0.10.0; the terminal consoles are
abstractgateway-console 0.12.0 and abstractcore-console 0.5.0, and the browser apps
AbstractCode web 0.7.0 and AbstractObserver 0.3.0 (built on AbstractUIC ui-kit 0.2.0 and panel-chat
0.1.21). Every other version is unchanged from 0.6.3.

Added

• Your own mailbox on the gateway. Each user connects their own email account (IMAP/SMTP with a
  password or app password, or OAuth2 for Google and Microsoft) in the web console (Users → My
  email), the terminal console (@ on the Users screen) or PUT /api/gateway/me/email. The
  account is tested before it is saved, stored in the user's own data folder with its credentials
  encrypted, and every connection verifies TLS. The mailbox is read-only. Each user sets a recipient
  policy (allowlist or denylist of addresses and domains) and send limits (20 per hour and 100 per
  day by default); every send passes them. AbstractCore on its own gets the same account, one per
  install: abstractcore email ..., the core web console's Email tab and the core terminal
  console's Email screen. See Configuration.
  abstractcore email connect --password-stdin (and --client-secret-stdin for OAuth) reads the
  secret from stdin, so it never appears on a command line (AbstractCore 2.20.1).
• Email automations. The Assistant, the Observer and AbstractCode's browser client offer When
  an email arrives (the email.received@1 trigger: typed filters on sender, recipient, subject and
  attachments; hourly batches by default for automations that run a model, never more often than
  every 60 seconds; each message read once), Email me the result, and the recipients an
  automation may email without asking (only you, by default). Inbound mail reaches the agent as
  untrusted data in a fixed frame; an email-triggered automation never follows links from an email
  (fetch_url and browser_probe ask) unless you name those tools. See
  Email automations.
• Email notifications, off until you turn them on in My email → Notifications: automation
  results and failures (for automations set to email you), a run waiting for your approval, and
  runs started with an email notice. Each notice is sent once from a durable outbox, through your
  own account, to your registered address.
• Sign-in by email: "Forgot your token?" and "Email me a sign-in code" on the gateway's sign-in
  page for users with a connected account (single-use codes, 10-minute expiry).
• What administrators decide: whether email, agent email tools and sign-in by email are
  available, gateway-wide and per user. Agent email tools are off by default: an agent gets the
  email tools only when an administrator made them available, the user's account is connected, and
  the user turned them on. Administrators see a user's mailbox state, never mail.

Removed

• The ABSTRACT_EMAIL_* environment variables, the email accounts file and the gateway's email
  bridge. A gateway or an AbstractCore install that still has them imports that account once into
  the new settings; afterwards each variable still set is named at startup with the setting that
  replaced it.

Fixed

• One gateway per data directory when you re-run the installer. A gateway of this install that
  you started yourself (for example with the summary's Start line) is recognized: it listens on the
  install's port and serves the same data directory, as its serve record
  (<data dir>/run/gateway-serve.json) or its --data-dir says. install.sh and install.ps1 now
  keep that port and replace the gateway with their own start, instead of moving to the next port
  and starting a second gateway on the same data. A gateway of this install started by hand on
  another port is stopped too. The replacement starts the way the installer starts every gateway, so
  it binds as the gateway's Network setting says (for example 127.0.0.1), not with the --host the
  hand-started one was given. With --no-start (-NoStart, the console's Update) it keeps
  running and the summary says a restart is due. A program that is not this install's gateway
  keeps the port, as before.
• The installers signal only this install's gateway. Before any stop, the process must belong
  to your user, run abstractgateway serve and serve this data directory; the identity is checked
  again right before the signal (and before a SIGKILL). A gateway.pid or serve record left behind
  that names another program (a reused pid) is left alone and said so.
• Known limit on Windows with start at login on: Windows does not tell the installer which
  process the login item started, so a gateway of this data directory that you started yourself on
  the install's port is taken for the login item and left running. Stop it and re-run the
  installer to get the login item's gateway.
• A release published minutes earlier installs at once. The installers pass
  --refresh-package for abstractgateway and every package of the release matrix to
  uv tool install, so uv asks PyPI again instead of using its cached index page (which could say
  "no version of abstractgateway[gpu]==" until uv cache clean abstractgateway).

Changed

• Launch flags in the commands the installers print. The summary's Start line and the
  background start's command (the "same steps by hand" list) read
  abstractgateway serve --data-dir <data dir> (plus --host/--port when the gateway has no
  Network setting) instead of ABSTRACTGATEWAY_DATA_DIR=... ABSTRACTGATEWAY_USER_AUTH=1 ...; the
  gateway starts with user auth on by itself. The installers themselves still pass the data dir to
  the gateway commands they run (network, service install, claim-url) through
  ABSTRACTGATEWAY_DATA_DIR. Gateways before 0.3 (--pin) keep the environment form.