@monster-orange/den 0.4.3 → 0.4.5

package/CHANGELOG.md

@@ -4,6 +4,354 @@ All notable changes to Den are documented here. Each release lists the
 config and manifest changes a distribution must make to move to it under
 **Migrations**.
 
+## [0.4.5] - 2026-11-07
+
+Sign in with GitHub as the owner, from your other devices; approve a
+computer with a code; see that you're signed in (SEC-2a). Save the admin
+password without editing YAML (LK-4). Dev-metrics stay on this machine
+unless you opt in.
+
+### Added
+
+- **Sign in with GitHub.** A Den has one owner, a GitHub account:
+  `<cli> web owner link` runs GitHub's device flow in the terminal (a code
+  to enter at https://github.com/login/device) and stores only
+  `github:<id>` and the login (`web-owner.json`, 0600), never the token.
+  `web owner show` and `web owner unlink` too. The signed-out page then
+  has **Sign in with GitHub**: the server runs the flow, and the owner's
+  approval sets the same never-expiring session a one-time link does;
+  any other account sees "@<login> isn't allowed on this Den". At most
+  three sign-ins wait at once. Before an owner is linked the page says to
+  run `web owner link`. See docs/distributions.md, "Signing in with GitHub".
+- **Settings › Access.** The owner (link and unlink: shell-grade, so a
+  signed-in browser and never an agent's token), the
+  linked devices (browser, how it signed in, the client address the edge
+  vouched for, first and last seen) each with **Revoke**, which ends that
+  session at once, and **Pair a device**: a one-time link and its QR code
+  for an edge hostname you pick.
+- **`web.github_client_id`**: the GitHub App's client id (public). The
+  default is Den's own App, "Monster Orange Den" (`Iv23liKL12gnN6WvRV5b`);
+  a distribution sets its own App's id here, and an empty value turns Sign
+  in with GitHub off (the page then offers only the code and the link).
+  The App needs "Enable Device Flow" ticked and "Expire user authorization
+  tokens" off (docs/distributions.md, "The GitHub App").
+- **Expiring GitHub tokens are noticed.** If the App hands out expiring
+  tokens (`expires_in` or `refresh_token` in the answer), sign-in still
+  completes, and Den says once to switch off token expiry in the App's
+  settings (never with the token). `GET /api/web/owner` reports it as
+  `tokenExpiry`. Den never asks for `offline_access`.
+- **Approve this computer with a code.** The signed-out page shows a
+  six-character code (`XXX-XXX`, about 30 bits; the page polls with its own
+  128-bit id) and the command that approves it on the machine Den runs on:
+  `<cli> web approve <code>` (any case, dash optional; `--list` shows what
+  waits). The page signs itself in when it's approved, onto the page it
+  asked for. From a machine with SSH access the page gives the one-liner
+  (`ssh <host> '<cli> web approve <code>'`) and, for a host name, an Open
+  Terminal link. Codes expire after 10 minutes, are single-use, at most
+  five wait at once (the oldest drops) and are kept in memory only;
+  approvals are rate-limited and audited with who approved. The device is
+  labelled "approved with a code".
+- **Settings › Access › Waiting devices**: the computers waiting with a
+  code (browser and OS, address, when), each with **Approve** and **Deny**.
+- **`web.machine_name`** (Settings › Access › Machine name, in user.yml):
+  the name the signed-out page gives this machine. Default: the short
+  hostname. It's never taken from the browser's Host; the ssh one-liner's
+  target is the Host the browser used (without the port).
+- **The signed-out page says where to act.** "Sign in to <product>", which
+  machine Den runs on and why it asks (once per computer), Sign in with
+  GitHub (only with a client id), Approve this computer, and the one-time
+  link under "Other ways". Every command it prints names the machine it
+  runs on, has a copy button, and is `<cli>` when that's on PATH and this
+  distribution's, else the absolute path of its bin. English, Japanese and
+  Spanish.
+- **See that you're signed in.** A chip at the foot of the rail says
+  "Local", "Signed in · this device" or "@<login>" and opens Settings ›
+  Access. The first page after a sign-in says "This device is signed in
+  to <product> on <machine>", once. Linked devices lists every session
+  (GitHub, a code, a one-time link) with how it signed in, when, from
+  where, last seen and Revoke, and marks the one you're using as "This
+  device".
+- **Save the admin password without editing YAML (LK-4).** When a secrets
+  backend that keeps secrets (1Password, Doppler) is available and no
+  `secrets.refs.sudo` is set, the admin password prompt (shown when a
+  command is about to run sudo, LK-0) still offers "Save to <backend>".
+  Saving creates the item (1Password: "<Product> admin password" in your
+  default vault; Doppler: `<PREFIX>_LOCAL_ADMIN_PWD`) and writes
+  `secrets.refs.sudo` to your `config/local/user.yml`, so the password
+  survives restarts. A ref in the distribution's config still wins. The
+  vault status says so as `canSave`. A save error no longer carries the
+  backend's command line.
+- **`edge.proxy_protocol.trusted_ips`** (empty by default): the front
+  proxies (a TCP passthrough in front of the edge) whose PROXY protocol
+  every entrypoint accepts, so Den sees the real client through them.
+- **`web.edge_unattested: local | signin`** (default `signin`, read only
+  from `config/local/user.yml`): whether an edge client Den can't place
+  signs in. `local` keeps 0.4.4's (and 0.4.3's) behaviour.
+
+### Changed
+
+- **Dev-metrics are local unless you opt in.** Den sent its dev-metrics
+  whenever a DSN was present (in the env or a synced
+  `dev-metrics.config`). Sending now needs `metrics: { share: true }` in
+  `config/local/user.yml` (the boolean only); a DSN alone never sends. The
+  local `events.jsonl` is unchanged, and `CI=true` and
+  `DEV_METRICS_DISABLED=1` still stop sending.
+- **`<cli> web login` waits.** It prints the link and an 8-character code,
+  and blocks until the link is used ("Signed in: <browser> (<address>) at
+  <time>") or expires ("Expired: nobody used the link", exit 1). The link
+  asks for the code before it signs in; a wrong code is refused (five burn
+  the link, and wrong codes are rate-limited) and the link stays
+  single-use. `--no-wait` prints the link alone, as before, and asks for no
+  code; with no server running it behaves like `--no-wait` and says so.
+- **Edge visitors Den can't place sign in.** A client the edge reports
+  with no `X-Forwarded-For`, or with a Docker/VM gateway or bridge address
+  (what a TCP passthrough or Docker Desktop and OrbStack hand it), now sees
+  the signed-out page with Sign in with GitHub, unless
+  `web.edge_unattested: local`. Loopback and this machine's own addresses,
+  as the edge reports them, stay local, and localhost straight to the
+  server's port never signs in.
+- **The client is the right-most `X-Forwarded-For` entry**, the one the
+  edge appended (0.4.4 and earlier read the left-most, which a client could
+  write).
+- **The edge believes forwarded headers only from its own networks.** Den
+  renders `forwardedHeaders.trustedIPs` (loopback and the Docker ranges)
+  on every entrypoint, never `forwardedHeaders.insecure`. An `edge.args`
+  entry that sets `forwardedHeaders` or `proxyProtocol` is dropped with a
+  notice from `edge up`.
+- **"Your edge is reachable from other machines"** now reads "A browser it
+  can't place as this one signs in first (Sign in with GitHub, or a
+  pairing link)." (with `web.edge_unattested: local`, that anyone it can't
+  place can use terminals).
+- **`edge up` says when the running edge's command differs** from the one
+  it renders, and why, before recreating it.
+
+### Fixed
+
+- **The workspace commands run in is named: "CLI default".** Local Dev's
+  workspace list marked it with a bare accent dot and no label, and
+  picking a workspace in the top bar never moved the dot (by design: that
+  picks the view), so it looked broken. It now says "CLI default", with
+  a tooltip: CLI commands run there when you don't name a workspace, and
+  the top bar only changes what pages show. The top bar's Workspace menu
+  tags it "CLI default" (was "focus") and offers "Make <ws> the CLI
+  default"; the Workspaces pane's badge reads "active · CLI default" and
+  its button "Make CLI default". Nothing behaves differently.
+
+- **A browser signs in on a plain-http LAN bind** (`DEN_BIND_HOST` with
+  `web.allow_plain_http_remote`). A `web login --origin http://<LAN IP>:<port>`
+  link got 403 `origin_rejected`: the browser sends a plain-http origin that
+  isn't localhost no `Sec-Fetch-*` headers, and a navigation sends no
+  Origin. The sign-in GETs (`/auth` and the GitHub sign-in poll), which
+  carry their own one-time credential, now pass with neither header. Either
+  header, when present, is still checked, and every other GET that runs
+  something still needs this server's page or a bearer.
+- **`web up` with `DEN_BIND_HOST` on one address is ready when it serves.**
+  Its readiness probe (and `web sessions`/`web logout`'s calls) asked
+  127.0.0.1, so a server bound to a LAN IP or `::1` printed "did not become
+  ready" and exited non-zero. They ask the bound address now (loopback for
+  0.0.0.0 and `::`), with a Host the allowlist accepts and the CLI's
+  bearer: a LAN address answers an unsigned probe 401 `signin_required`.
+  `web up` names the bound address (`http://<LAN IP>:<port>`), not
+  localhost, which a LAN-only bind doesn't answer.
+
+### Migrations
+
+- **One edge recreate.** The edge's command changes (forwarded-header
+  trust), so the first `<cli> edge up` (or `stack up`) after upgrading
+  recreates it once, and says so: "<org>-edge's settings changed
+  (forwarded-header trust): recreating it once." Routes drop only while it
+  restarts.
+- **Edge visitors now see Sign in with GitHub** where 0.4.4 let a client
+  it couldn't place in. Link an owner (`<cli> web owner link`), approve
+  the computer with its code (`<cli> web approve <code>`) or pair with
+  `<cli> web login --host <name>`;
+  or set `web.edge_unattested: local` in `config/local/user.yml` to keep
+  0.4.4's behaviour on that machine.
+- **Scripts that run `<cli> web login` and read its output** should pass
+  `--no-wait`: it now waits for the link to be used.
+- **Remove `forwardedHeaders.*` and `proxyProtocol.*` from `edge.args`.**
+  They are ignored now; use `edge.proxy_protocol.trusted_ips` for a front
+  proxy.
+
+## [0.4.4] - 2026-11-07
+
+The admin password is for sudo, and nothing else (LK-0). An agent's
+terminal uses its pane's width, and Den knows Codex, Gemini and Grok as
+well as Claude Code (AG-0.5). A scoped agent gets a whole, honest picture
+through Den's MCP (MCP-2).
+
+### Changed
+
+- **Nothing asks for the admin password up front.** It was a lock: agent
+  start, stop and resume answered `423 locked` without it, and the pages
+  asked for it before agent actions, service actions and syncs. It is no
+  access check (that is sign-in, the Host/Origin/CSRF checks and agent
+  tokens), and Den now asks for it only when a command it runs is about to
+  run sudo. Agents, sessions, terminals and services whose commands run no
+  sudo never ask. The agent routes' `423 locked` is gone, and so is the
+  Start agent dialog's password field.
+- **A run that needs sudo says so, and the page asks then.** Every service
+  command (up, down, restart, setup, sync) gets a `sudo` shim first on its
+  PATH. With the password held, it gives it to sudo, as before. Without
+  it, sudo that needs no password (NOPASSWD, a warm cache) runs as it
+  would; anything else never prompts: the run's events carry
+  `{ "type": "needs-sudo", "command": "sudo <command>", "step": "<service>" }`
+  (sudo's own "a password is required" counts too, without the command).
+  The page then says "`sudo <command>` needs your admin password", in the
+  top layer, and runs the action again after it. Before asking, it asks
+  the server (another tab or device may have set it) and, when one is
+  stored, the vault. Local Dev no longer loads it from the vault on page
+  load.
+- **No Locked/Unlocked chip.** The top bar shows "🔑 Admin password
+  needed" only while a run waits for it. Settings › Command line › Admin
+  password says "Saved in 1Password", "Saved for this session" or "Not
+  saved", with Forget (`POST /api/sudo-password/forget`, which also clears
+  the vault's copy when this server saved or loaded it there).
+  `GET /api/sudo-password/status` adds `saved` and `vault`.
+- **Scoped answers say so (MCP-2.2).** `status`, `services`,
+  `applications`, `graph`, `stacks` and `workspaces` on a scoped server
+  carry a `scope` block: the workspace shown and what is left out
+  (`hidden: { repos: 6 }`), pointing at `org_summary`. Their descriptions
+  say "This workspace only", and a pinned server registers them without
+  the `workspace` parameter (with grants it stays, as the scope's own or a
+  granted one). A scoped `graph` is the workspace's own repos and the edges
+  out of them; unscoped it is labelled `map: "org-wide"`. Before, `graph`
+  listed every repo while every other tool showed one workspace's.
+- **Refusals say how to get more (MCP-2.3).** A call naming another
+  workspace says a person adds it to `agents.<id>.grants` in the org config
+  and restarts the agent; a refused log read says logs stay inside each
+  workspace and a grant does not widen them.
+- **`status` (MCP tool) is an object:** `{ env, counts, services }`, each
+  service with a `state` and, when it has no plain verdict, `why`. It was
+  the bare `/api/health` array.
+
+### Added
+
+- **The runtime catalog (AG-0.5).** Den ships, as data, the vendor CLIs it
+  can find: Claude Code (`den-claude`), OpenAI's Codex CLI (`codex`),
+  Google's Gemini CLI (`gemini`) and xAI's Grok Build (`grok`), each with
+  its binary names, version command, install directories and launch
+  command, checked against the vendor's docs. Installed runtimes are
+  listed first, with their versions, in the Start agent dialog, Settings
+  and `agents doctor`. A runtime other than Claude Code runs its own
+  interactive CLI in the workspace's directory, tagged "Den tools:
+  coming"; nothing is offered as startable unless it can start here.
+  When a catalog runtime is still not found, Den asks your interactive
+  shell (`$SHELL -ilc`) once, and says so (`interactive-shell`).
+- **Runtime paths per workspace.** `<ws>.agents.runtimes.<id>.bin` in
+  `config/local/workspaces.yml` wins over `agents.runtimes.<id>.bin` in
+  `config/local/user.yml`, which wins over what Den finds. **Settings ›
+  Agents › Runtimes** shows each runtime's status, version, path and its
+  source; **Set path…** runs the version command and refuses a path that
+  isn't that runtime, and a selector edits one workspace's paths.
+  `agents doctor -w <ws>` shows that workspace's.
+- **The Start agent dialog is the approved width** (the mock's 600px of
+  content: 638px wide, never wider than the window less 16px a side).
+- **`org_summary`, the org at a glance for every agent (MCP-2.1).** A new
+  read tool: every workspace and repo with status counts (running, partial,
+  stopped, inactive; up, down, redirect, not checked), the dependency graph
+  (names and edge kinds), the edge (up, TLS, whether HTTPS serves) and the
+  environments. Scoped, `yours` adds the agent's own workspace's services
+  in full, so "what are our servers?" is answered without `docker ps`. For
+  other workspaces it carries names and counts only: never logs, env
+  values, commands, URLs, paths or check output.
+- **`edge_status.https` (MCP-2.5)**: the TLS strategy, who supplies the
+  cert (`den` or `distribution`) and whether HTTPS is serving, from a TLS
+  handshake on the edge's https port. `edge status` prints it too.
+
+### Fixed
+
+- **A service's first lines reach the page.** A started service writes to
+  its log, and Den tails that log back to the page. The tail started at the
+  log's end, so a command that wrote and exited before the tail opened the
+  file (on Linux, a refused sudo) showed nothing, and the page never asked
+  for the admin password. The tail now reads from the start of this run.
+
+- **An agent's terminal uses the pane's width.** A session has one PTY
+  size, and the last viewer to resize it won: a second, narrower browser
+  (or a hidden tab) left the TUI wrapping at its width in every other
+  viewer. The viewer in use now wins: focusing a pane, typing in it after
+  another viewer changed the size, and the page being shown again each
+  send that pane's size; a hidden pane never resizes the PTY, and no
+  resize under 2×2 is sent (the server refuses one too). The server tells
+  every viewer the PTY's size on attach and on each change (a `size`
+  frame), so a viewer knows when it is out of step. A session host
+  that outlived an upgrade sends no such frame, so then every keystroke
+  says the typing viewer's size (the same size again redraws nothing). The cells are also
+  measured again once fonts finish loading and after a theme is applied,
+  so a theme's web font no longer leaves the terminal fitted to the
+  fallback font's width.
+- **A Settings row with its own control is drawn.** A custom row without a
+  write was drawn as an empty read-only value, so Browser sign-in showed
+  nothing; it now shows its state and Sign out.
+- **A redirect is not down (MCP-2.4).** A health check answered `302 →
+  /login` (a production app's login page) was reported down. The bug was
+  in the shared HTTP check, so the web health row and `<cli> status` had
+  it too. A 3xx is now `redirect`: ok null, with its status and target (the
+  query dropped), never green, so an ALB's 301 for a stopped service is
+  still not taken for up. `target.expect` listing the code counts it as up.
+  `<cli> status` shows `redirect 302 → /login`, and `up` and `restart` no
+  longer wait out a service that answers with a redirect.
+- **An unchecked service says why (MCP-2.4).** `ok: null` with no reason
+  (`runs: none` in beta and prod) now carries `why` on the web health row
+  and in `status`: no health check for the env, remote with no check, not
+  deployed in the env, or no manifest.
+- **An empty `stacks` explains itself (MCP-2.4):** `/api/stacks` says the
+  org config declares no `stacks:` and no repo of the workspace has a
+  `compose:` block (or the workspace doesn't exist); scoped, that the
+  stacks listed belong to repos outside it.
+- **`certIssued: false` while HTTPS works (MCP-2.5).** It meant "Den minted
+  the cert", which is false under `tls: files`. Renamed `certIssuedByDen`.
+- **Security: a scoped `mcp --call` goes through the scoped path, and
+  says so.** A review reported that `mcp --workspace A --actor agent:<id>
+  --call services '{"workspace":"B"}'` could read workspace B's services
+  (paths and commands included). A one-shot now lists and validates
+  against the pinned tools exactly as the stdio server registers them, a
+  `workspace` naming another workspace always reaches Den's refusal, and
+  `--call` prints its scope on stderr (`<cli> mcp --call: scoped to A as
+  agent:<id>`), so an unscoped run can't pass for a scoped one. Tests now
+  drive the real `bin/den mcp --call` entry.
+- **An ungranted workspace gets Den's refusal (MCP-2.3).** On a scoped
+  server with grants, naming a workspace that is not granted answered
+  `MCP error -32602 … expected one of "A"|"C"` (the schema). The
+  `workspace` parameter is now a name whose description lists the allowed
+  ones, and any other gets the refusal naming `agents.<id>.grants` and how
+  a person grants it.
+- **The org-wide map is org-wide.** `org_summary.graph` and an unscoped
+  `graph` held only the focused workspace's repos, so a repo only in
+  another active workspace was missing. They now merge every active
+  workspace's graph (`workspaces` names them; `order`, a startup order
+  within one workspace, only when one is active); `org_summary` keeps
+  names and edge kinds only. `graph` with a `workspace` is labelled
+  `map: "workspace"`.
+- **A service's command runs in its own workspace.** The Services page's
+  and the tests page's setup, up, down and restart sent no workspace, so a
+  service only in a non-focused active workspace failed: `Command "setup"
+  not found for <repo>/<svc> … Active workspace: <focus>`. They now send
+  the workspace the row was built from. (0.4.3 had the same bug.)
+- **`agents doctor -w <ws>` works.** It answered `workspaces not loaded`;
+  it now loads the workspaces config first, as `agents start` does.
+- **A redirect is a redirect in `status`.** A repo row's reason counted a
+  service that answered with a redirect as "1 not checked"; it now says
+  "1 redirect" (the web header and graph cards too).
+
+### Migrations
+
+- A page script that imported `requireUnlock`, `checkUnlock`,
+  `isUnlocked` or `onLockChange` from `header.js` or `topbar.js`: they are
+  gone. Run the action; when its run's events carry `needs-sudo`, the
+  shell asks (`sudoRun()` from `header.js`: `see(msg)` on each event,
+  `done(retry)` when the run ends).
+- A client that handled `423 locked` from the agent routes: it no longer
+  happens.
+- A distribution may add runtimes with `agents.runtime_catalog` (see
+  Runtimes in docs/distributions.md).
+- A script reading `<cli> mcp --call status` gets `{ env, counts, services
+  }` in place of the array: read `.services`.
+- `edge_status.certIssued` (and `/api/edge`'s) is deprecated: read
+  `certIssuedByDen`, or `https.serving` for whether HTTPS works. It goes in
+  the release after 0.4.4.
+
 ## [0.4.3] - 2026-11-06
 
 Agents start, and the edge counts as local.

package/README.md

@@ -10,8 +10,8 @@
 </p>
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="docs/images/0.4.3/hero-dark.png">
-  <img src="docs/images/0.4.3/hero-light.png" width="100%" alt="Den's Graph page: the demo workspace's services grouped by application, all healthy, with the status chip and the left rail">
+  <source media="(prefers-color-scheme: dark)" srcset="docs/images/0.4.5/hero-dark.png">
+  <img src="docs/images/0.4.5/hero-light.png" width="100%" alt="Den's Graph page: the demo workspace's services grouped by application, all healthy, with the status chip and the left rail">
 </picture>
 
 ## What Den is
@@ -24,7 +24,7 @@ It doesn't replace your tools. Your repos, Docker, your test runners, your secre
 yours. Den connects them and turns on good practice from the start.
 
 <p align="center">
-  <img src="docs/images/0.4.3/up.gif" width="100%" alt="make up in the Graph page: every stack down, then demo-api, demo-web and demo-notes come up in dependency order until the status chip reads All 3 healthy">
+  <img src="docs/images/0.4.5/up.gif" width="100%" alt="make up in the Graph page: every stack down, then demo-api, demo-web and demo-notes come up in dependency order until the status chip reads All 3 healthy">
 </p>
 
 ## How it helps
@@ -43,20 +43,21 @@ yours. Den connects them and turns on good practice from the start.
 - **Agents work by the same rules as you.** Start an agent from a persona (planner, orchestrator, developers,
   devops, reviewer, UX designer, or your own) in a workspace. Its terminal opens in the Agents tab and keeps
   running when you close the page or restart the web server. Over MCP it sees your stack with the same guards
-  and audit trail as a person, under a token of its own. Agents can read and investigate. Acting is opt-in,
-  and the lock still guards starting and stopping things.
+  and audit trail as a person, under a token of its own. Agents can read and investigate, and acting is opt-in.
+  Starting an agent never asks for your admin password: Den asks for it only when a command it runs needs sudo.
 - **Safe on localhost, signed in beyond it.** On localhost there is nothing to sign in to. Reached through the
-  edge or your network, every page and call needs a sign-in, and there is no password: `acme web login` prints a
-  one-time link.
+  edge from another machine, or over your network, every page and call needs a sign-in, and there is no password:
+  Sign in with GitHub as the Den's owner, approve the computer with a code (`acme web approve <code>`), or open a
+  one-time link from `acme web login`.
 - **Opinionated, not locked in.** Good defaults are switched on, and almost everything can be switched off. The
   safety guards stay on. Den never needs our accounts, secrets or certificates. Everything specific to you
   lives in your own repo.
 
 <p align="center">
-  <img src="docs/images/0.4.3/agents.png" width="49%" alt="The Agents tab: the demo workspace's sessions on the left, and one open in a terminal pane on the right, running demo-api's test and then the service">
-  <img src="docs/images/0.4.3/workspaces.png" width="49%" alt="The Workspaces page: the demo workspace's repos with their health, mode and Start, Stop, Restart and Logs actions">
-  <img src="docs/images/0.4.3/status-drawer.png" width="49%" alt="The status drawer: nothing needs attention, and every service in the demo workspace, by application, with its latency">
-  <img src="docs/images/0.4.3/edge.png" width="49%" alt="The Edge page: the edge container up, its ports and TLS, and every route it serves, Den's own and each stack's, with its upstream">
+  <img src="docs/images/0.4.5/agents.png" width="49%" alt="The Agents tab: the demo workspace's sessions on the left, and one open in a terminal pane on the right, running demo-api's test and then the service">
+  <img src="docs/images/0.4.5/workspaces.png" width="49%" alt="The Workspaces page: the demo workspace's repos with their health, mode and Start, Stop, Restart and Logs actions">
+  <img src="docs/images/0.4.5/status-drawer.png" width="49%" alt="The status drawer: nothing needs attention, and every service in the demo workspace, by application, with its latency">
+  <img src="docs/images/0.4.5/edge.png" width="49%" alt="The Edge page: the edge container up, its ports and TLS, and every route it serves, Den's own and each stack's, with its upstream">
 </p>
 
 ## Get started