Firenook 0.2.0

0.2.0 — the first release for public use

• Pin the engine to 7a9614bea49f8208f96d2126b29ef11ee2f2810b, the merge of
  PR #117 on
  0.2.0-next.8. Its tree is the PR head's, bbd437e, which passed CI
  (run 39667251564)
  and the five-platform packed-install matrix
  (run 39667251694).
• A stable version. npm install firenook and a bare npx firenook get
  0.2.0 on any Node from 20 up; previews keep their own versions, and a
  preview install is told about 0.2.0.
• firenook init in a terminal. One screen with every choice made (the
  project id, the emulators on their usual ports, TypeScript, JavaScript or
  no Functions, the coding agents, the set-up), then the installs, Firenook
  pinned, the first build and the emulators started in the same terminal.
  TypeScript is the default, from the official template. Without a terminal
  it writes the files and prints the commands that finish the set-up;
  --yes runs them.
• TypeScript compiled as you save. --build runs each codebase's own
  build:watch beside the engine and starts it after the first compile;
  errors show in the log. emulators:exec --build runs build once and no
  test when it fails.
• Ordered and range queries. An order-preserving field index serves
  orderBy, range filters and cursors on a top-level field, and checks
  equality on other fields before a document is read; a batch get writes
  stored documents straight into the reply. The six query shapes the
  official emulator answered faster in the 0.2.0-next.6 benchmark are now
  1.8 to 8 times faster than it (orderBy an integer, limit 20: 12.0 ms
  against 96.3 ms). A store an earlier release wrote builds the index once
  on its first open (7.4 s for 211,202 documents, 49.3 s for 2.7 million on
  the benchmark server); an earlier release opening a 0.2.0 store rebuilds
  its own index.
• Node 22, 24 and 26. Older is refused with how to switch; an odd or
  newer major starts with a warning; a codebase whose engines.node asks for
  another Node is warned about, as the official emulator warns. doctor
  reports the Node and every problem.
• Older Linux. The engines need glibc 2.28 (RHEL 8, Debian 10, Ubuntu
  20.04, node:24-slim and later) instead of 2.39; Alpine and older systems
  are told what they lack.
• Security Rules as the official emulator applies them. A gRPC request
  without an Authorization header is signed out, not the owner.
  @firebase/rules-unit-testing works. A database firebase.json does not
  list follows the default database's rules; a Storage target with several
  buckets applies its rules to each; a denial names the rule line.
• Nothing reaches production. The console's snippets (Python Storage,
  Apple Firestore, Tasks and Eventarc everywhere) and emulators:exec, which
  now sets the official variables for the running emulators only. The demo
  credentials of exec and of the Functions workers take their token from
  the emulators: no firebase-admin release tested asked Google for one, and a
  function no longer falls back to the developer's own gcloud login.
• Functions. Params' defaults, .env.<alias>, the .env values at
  discovery, the project firebase use chose, warnings for triggers on
  services that do not run, functions:invoke --help, ext:vendor --offline, the Firebase login on Windows.
• REST. createDocument works, and every v1 method answers as the
  official emulator does (the differences kept are listed in
  COMPATIBILITY.md).
• Starts and stops. Two suites with one project id; Firestore closed
  after browser sessions; a killed launcher stops its engine, which saves
  the data; --import without metadata and a bad indexes file warn;
  firebase.json found from a folder inside the project; localhost and
  ::1 bound as officially.
• Polish. init --force keeps your rules, init --adopt keeps your
  formatting, --ui comes before ui.enabled: false, counts agree with
  their nouns, every service's lines reach the screen, CI=false is not CI.
• Data 0.2.0 saves opens in 0.2.0-next.8, which rebuilds its own field index
  first; no emulator protocol or port changed, except that localhost now
  binds ::1 as well for the hub and the console, as officially.
• Benchmarked against the official emulator on one
  application's two hours of traffic: 10 times less emulator memory (2.11
  against 22.57 GiB), writes 40 times faster (5.1 against 208 ms at the
  median), listener updates 19 times faster and 61% less CPU; a restart with
  the data kept is ready in 0.59 s against 30.8 s, and Firenook is faster on
  25 of 26 query shapes and ties on the last.
• Published straight to latest; the CLI's next stays on 0.2.0-next.8
  until it is moved by hand.

Earlier releases: packaging/CHANGELOG.md.

Firenook 0.2.0-next.8

0.2.0-next.8 — the Firestore tree at once, code in colour, npx on any Node

• Pin the engine to f7c3c663427fd181b0e67b31f960f6e5751b7d12, the merge of
  PR #112 on
  0.2.0-next.7. Its tree is the PR head's, 00eb599, which passed CI
  (run 39587506798)
  and the five-platform packed-install matrix
  (run 39587506927).
• npx firenook gets this release on any Node from 20 up. On any Node
  but 24, npx firenook init installed firenook@0.0.0, the placeholder
  that held the name before the first release, with its old advice: every
  release declared engines.node as >=24 <25, and for a bare name npm
  takes latest only when its engines admit the running Node, and otherwise
  the highest version that is not a preview. engines.node is now >=20,
  npm's own floor. The emulators still need Node 24, and now say so with the
  way to switch: "the emulators need Node 24, since your Functions run on
  it; this is Node 26.9.0. Switch to Node 24 (with nvm: nvm install 24) and
  run it again". init and the other commands run on any Node.
• The Firestore tree at once. The console's tree said "Mapping the
  database…" for minutes on a large store. Its first walk now reads the
  collection index instead of the documents (37 s instead of 133 s on 2.7
  million documents), a clean stop saves the tree with the data so the next
  start shows it in under a millisecond, and while a walk runs the root
  collections are listed with their counts. After a crash, or any change to
  the data since the stop, the tree is mapped again on first use.
• Code in colour. Every code block in the console (the Connect dialog,
  a document as code, a request as code) is coloured with the editor's
  palette, in the language it is: the Flutter, Swift, Kotlin and Java
  snippets are no longer marked as JavaScript, and environment variables
  read as .env lines.
• The console behind local proxies. Any name under localhost, such as
  portless's my-app.localhost, is answered like localhost;
  docs/console.md says how to reach the console through portless. .local
  and custom domains still need --allowed-hosts.
• Data next.8 saves opens in 0.2.0-next.7, which leaves the saved tree
  alone, and next.8 maps the tree again after next.7 changed the data
  (checked with a round trip). No emulator protocol or port changed.
• A consumer's gates passed on the candidate built from f33376b
  (0.2.0-local.gf33376b3cb3f), whose package is the PR head's (only a
  console journey changed after it): Extensions admission (24 admitted, 2 ignored
  upstream; ready in 2.4 s), the installed package smoke and its 26
  integration tests. The acceptance-host benchmark was not run: no write,
  query or import path changed.
• Published straight to latest: the CLI's next stays on 0.2.0-next.7
  until it is moved by hand.

0.2.0-next.7 — data kept without a seed, coding agents set up in one command, 54 MCP tools

• Pin the engine to 37fdd0387ea81f3131c20b594159113c86084a3a, the merge of
  PR #107 on
  0.2.0-next.6. Its tree is the PR head's, e8ecd33, which passed CI
  (run 39450933562)
  and the five-platform packed-install matrix
  (run 39450933535).
• A project with no seed keeps its data. --resume-state needed
  --import, so a project made with firenook init could not keep its data
  between runs. Now it needs only a state directory; data started without a
  seed records an empty one, and a start that mixes the two up (a seedless
  state given --import, or a seeded one started without it) is refused
  with the way on, nothing changed.
• --keep-data is short for --state-dir ./.firenook/state --resume-state, with or without --import. Keeping data stays opt-in, so
  --import ./data alone still starts from that data every time. init
  prints its start command with --keep-data.
• firenook mcp add gives the project's coding agents the MCP server:
  it writes .mcp.json (Claude Code), .cursor/mcp.json and
  .vscode/mcp.json for the agents it finds, keeping every other server,
  with --dry-run, --agent and --force. A second run changes nothing.
  init offers it once in a terminal; init --adopt lists it in its plan.
  The terminal's ? help names it.
• 54 MCP tools, up from 19. The function calls and the log (with each
  call's error and stack trace, and a replay), Security Rules (the rules in
  force, whether a request as a given user is allowed and which line
  decided, recent denials), Auth tokens and claims, Storage files (read,
  upload, delete, copy, move), Eventarc, Extensions, Pub/Sub topics and a
  backlog peek, Cloud Tasks, schedules, Firestore counts and collection-group
  queries, and a reset that asks for the project id before it clears more
  than one service. The new tools use the console's API, so they need the
  console on (the default). A {"$timestamp"} finer than a millisecond now
  keeps its precision when a tool writes it.
• firenook mcp with no arguments uses the one running suite, so an
  editor's install link needs no project id; with two running, it asks for
  --project.
• The console's Connect dialog has a Coding agent tab: the setup for
  Claude Code, Cursor, VS Code and any other agent, "Add to Cursor" and
  "Add to VS Code" install links, and when an agent last called.
• Functions start in under a second, not seven. Discovery waited about
  6 s for the SDK's discovery server to exit, kept open by an idle
  keep-alive connection; it now takes about 0.2 s. On the acceptance host, a
  project with seven functions and every emulator is ready in 0.78 s against
  6.82 s.
• Timestamps are stored to the microsecond, as in production: a finer
  value is rounded down at write, so the export no longer refuses it, and
  the export rounds down any finer value an earlier release saved.
• The Functions log line's duration prints 1.6ms, not
  1.6076249999999999ms.
• The console's document panel reads a bare id in doc= against the
  open collection instead of crashing.
• Checked against 0.2.0-next.6 on the acceptance host with the same data,
  instead of a new paired run against the official emulator, since no
  measured path changed: imports, resumed starts, writes, listener delivery
  and the query shapes match within run-to-run noise, and memory is 11 MB
  higher once ready (docs/benchmarks.md, benchmarks/next7-regression.json).
  The slow start the 0.2.0-next.6 run saw on a freshly copied state directory
  is the copy's pending writes reaching the disk, not Firenook.
• A consumer's gates passed on the candidate built from the PR head
  (0.2.0-local.ge8ecd3325537): Extensions admission (24 handlers admitted,
  2 ignored upstream, as the official emulator records), the installed
  package smoke and its 26 integration tests. Its stack with three Extensions
  was ready in 2.6 s, against 7.4 s on 0.2.0-next.6.
• Data kept without a seed needs 0.2.0-next.7; 0.2.0-next.6 refuses it and
  changes nothing. Data saved by 0.2.0-next.6 opens unchanged, and data
  0.2.0-next.7 saved from a seed opens in 0.2.0-next.6 (checked on the
  private consumer seed: 211,202 documents and 33,353 objects). No emulator
  protocol or port changed.
• Published straight to latest: the CLI's next stays on 0.2.0-next.6
  until it is moved by hand, and a preview install, which follows next, is
  not told about this release until then.

0.2.0-next.6 — data closed on stop, starts in milliseconds, the store's size

• Pin the engine to 767605db4248fed403523a24f6901fcc1e693d13, the merge of
  PR #93 on
  0.2.0-next.5. Its tree is the PR head's, 7d14d9b, which passed CI
  (run 39117077846)
  and the five-platform packed-install matrix
  (run 39117077854).
• A stop closes the data. Since 0.2.0-next.3 a stop left Firestore's
  store file marked open (and Storage's since 0.2.0-next.4), so every start
  after a stop repaired it first. The console's change feed, schema index
  and Overview count held the store they observed, Storage held a Firestore
  handle, and the console's whole-database walks ignored the stop. A stop
  once ready, or while starting, now closes Storage, then Firestore; one
  that cannot close a database is reported as a failed stop.
• A killed engine is no stop. The screen said "stopped … everything is
  kept" whenever a stop was asked for and the engine then ended, even by a
  kill. Now it says the stop did not finish and that the next start checks
  the data first; plain mode says the same in one line.
• Saved data opens in milliseconds. The documents' count is saved with
  every commit instead of decoding every document at each open: a 32.6 GB
  store of 2.7 million documents opened in 146 s and now in 67 ms, a 4.3 GB
  one in 1.4 s and now in 63 ms. The first start of data an earlier release
  wrote counts once and saves the result.
• firenook state:inspect --state-dir DIR shows what a stopped store's
  file holds, table by table, and how much of it is free.
• firenook state:compact --state-dir DIR returns a stopped store's
  free pages to the disk, copying the file first (a clone where the file
  system has one; --no-copy skips it). Every document stays as it is. On
  the 32.6 GB store: 32.60 GB to 27.79 GB in 16 minutes.
• The console Overview's Firestore card shows the store's size on disk.
• **The old documents table i...

Firenook 0.2.0-next.7

0.2.0-next.7 — data kept without a seed, coding agents set up in one command, 54 MCP tools

• Pin the engine to 37fdd0387ea81f3131c20b594159113c86084a3a, the merge of
  PR #107 on
  0.2.0-next.6. Its tree is the PR head's, e8ecd33, which passed CI
  (run 39450933562)
  and the five-platform packed-install matrix
  (run 39450933535).
• A project with no seed keeps its data. --resume-state needed
  --import, so a project made with firenook init could not keep its data
  between runs. Now it needs only a state directory; data started without a
  seed records an empty one, and a start that mixes the two up (a seedless
  state given --import, or a seeded one started without it) is refused
  with the way on, nothing changed.
• --keep-data is short for --state-dir ./.firenook/state --resume-state, with or without --import. Keeping data stays opt-in, so
  --import ./data alone still starts from that data every time. init
  prints its start command with --keep-data.
• firenook mcp add gives the project's coding agents the MCP server:
  it writes .mcp.json (Claude Code), .cursor/mcp.json and
  .vscode/mcp.json for the agents it finds, keeping every other server,
  with --dry-run, --agent and --force. A second run changes nothing.
  init offers it once in a terminal; init --adopt lists it in its plan.
  The terminal's ? help names it.
• 54 MCP tools, up from 19. The function calls and the log (with each
  call's error and stack trace, and a replay), Security Rules (the rules in
  force, whether a request as a given user is allowed and which line
  decided, recent denials), Auth tokens and claims, Storage files (read,
  upload, delete, copy, move), Eventarc, Extensions, Pub/Sub topics and a
  backlog peek, Cloud Tasks, schedules, Firestore counts and collection-group
  queries, and a reset that asks for the project id before it clears more
  than one service. The new tools use the console's API, so they need the
  console on (the default). A {"$timestamp"} finer than a millisecond now
  keeps its precision when a tool writes it.
• firenook mcp with no arguments uses the one running suite, so an
  editor's install link needs no project id; with two running, it asks for
  --project.
• The console's Connect dialog has a Coding agent tab: the setup for
  Claude Code, Cursor, VS Code and any other agent, "Add to Cursor" and
  "Add to VS Code" install links, and when an agent last called.
• Functions start in under a second, not seven. Discovery waited about
  6 s for the SDK's discovery server to exit, kept open by an idle
  keep-alive connection; it now takes about 0.2 s. On the acceptance host, a
  project with seven functions and every emulator is ready in 0.78 s against
  6.82 s.
• Timestamps are stored to the microsecond, as in production: a finer
  value is rounded down at write, so the export no longer refuses it, and
  the export rounds down any finer value an earlier release saved.
• The Functions log line's duration prints 1.6ms, not
  1.6076249999999999ms.
• The console's document panel reads a bare id in doc= against the
  open collection instead of crashing.
• Checked against 0.2.0-next.6 on the acceptance host with the same data,
  instead of a new paired run against the official emulator, since no
  measured path changed: imports, resumed starts, writes, listener delivery
  and the query shapes match within run-to-run noise, and memory is 11 MB
  higher once ready (docs/benchmarks.md, benchmarks/next7-regression.json).
  The slow start the 0.2.0-next.6 run saw on a freshly copied state directory
  is the copy's pending writes reaching the disk, not Firenook.
• A consumer's gates passed on the candidate built from the PR head
  (0.2.0-local.ge8ecd3325537): Extensions admission (24 handlers admitted,
  2 ignored upstream, as the official emulator records), the installed
  package smoke and its 26 integration tests. Its stack with three Extensions
  was ready in 2.6 s, against 7.4 s on 0.2.0-next.6.
• Data kept without a seed needs 0.2.0-next.7; 0.2.0-next.6 refuses it and
  changes nothing. Data saved by 0.2.0-next.6 opens unchanged, and data
  0.2.0-next.7 saved from a seed opens in 0.2.0-next.6 (checked on the
  private consumer seed: 211,202 documents and 33,353 objects). No emulator
  protocol or port changed.
• Published straight to latest: the CLI's next stays on 0.2.0-next.6
  until it is moved by hand, and a preview install, which follows next, is
  not told about this release until then.

0.2.0-next.6 — data closed on stop, starts in milliseconds, the store's size

• Pin the engine to 767605db4248fed403523a24f6901fcc1e693d13, the merge of
  PR #93 on
  0.2.0-next.5. Its tree is the PR head's, 7d14d9b, which passed CI
  (run 39117077846)
  and the five-platform packed-install matrix
  (run 39117077854).
• A stop closes the data. Since 0.2.0-next.3 a stop left Firestore's
  store file marked open (and Storage's since 0.2.0-next.4), so every start
  after a stop repaired it first. The console's change feed, schema index
  and Overview count held the store they observed, Storage held a Firestore
  handle, and the console's whole-database walks ignored the stop. A stop
  once ready, or while starting, now closes Storage, then Firestore; one
  that cannot close a database is reported as a failed stop.
• A killed engine is no stop. The screen said "stopped … everything is
  kept" whenever a stop was asked for and the engine then ended, even by a
  kill. Now it says the stop did not finish and that the next start checks
  the data first; plain mode says the same in one line.
• Saved data opens in milliseconds. The documents' count is saved with
  every commit instead of decoding every document at each open: a 32.6 GB
  store of 2.7 million documents opened in 146 s and now in 67 ms, a 4.3 GB
  one in 1.4 s and now in 63 ms. The first start of data an earlier release
  wrote counts once and saves the result.
• firenook state:inspect --state-dir DIR shows what a stopped store's
  file holds, table by table, and how much of it is free.
• firenook state:compact --state-dir DIR returns a stopped store's
  free pages to the disk, copying the file first (a clone where the file
  system has one; --no-copy skips it). Every document stays as it is. On
  the 32.6 GB store: 32.60 GB to 27.79 GB in 16 minutes.
• The console Overview's Firestore card shows the store's size on disk.
• The old documents table is cleared once its documents are copied to
  the current layout; stores first written before 0.1.0-next.3 carried a
  dead copy of every document.
• Published straight to latest. The release workflow can now publish
  the CLI to latest in its one trusted publish, and this release used it.
  npm sets one tag per publish, so the CLI's next stays on 0.2.0-next.5
  until it is moved by hand, and a preview install, which follows next,
  is not told about this release until then.
• Data saved by 0.2.0-next.6 stays readable by 0.2.0-next.5: the count is a
  new entry the earlier release ignores. No emulator protocol or port
  changed.

0.2.0-next.5 — saved data: a quick seed check, quick repairs, clean stops

• Pin the engine to 18becb031bed1459133a5307790edb0afe19b0ca, the merge of
  PR #85 (the
  seed record, quick repairs, clean stops while starting) on 0.2.0-next.4. Its
  tree is the PR head's, 2651940, which passed CI
  (run 39048498837)
  and the five-platform packed-install matrix
  (run 39048498797).
• The seed check reads file details. Saved data (--state-dir with
  --resume-state) is picked up after comparing each seed file's size and
  times with the record made at the import (native-seed.json, beside the
  receipt); only a file whose details changed is read. On a 7.8 GB seed the
  check went from 23 to 26 s to under a second.
• Files operating systems write never block a start: .DS_Store, ._*,
  Thumbs.db, desktop.ini, __MACOSX and the like are ignored, and the
  Storage import skips ._* files.
• A first import hashes the seed beside the import, on worker threads,
  instead of reading it twice in full around it.
• A changed seed names its files, and firenook state:adopt-seed --state-dir DIR --import DIR keeps the data with the seed as it is now
  (the previous receipt is kept beside the new one).
• Quick repairs. The store's durable commits save what a repair needs,
  so a start after a crash or a killed process repairs in moments instead of
  reading the whole store. --durability per-commit leaves it out to keep
  its commit latency.
• A repair shows its progress: the Firestore row reads repairing NN%
  with the store's size, and the plain log prints how far it has got.
• A stop while starting closes the data cleanly. Ctrl-C, SIGTERM, a
  closed terminal and the launcher's pipe are listened for from the first
  moment: a seed check or a repair is abandoned with nothing opened, an
  import into a fresh run's directory ends at once, one into saved data
  finishes first. Nothing is exported before the emulators served anything.
• The start-up limit counts quiet time: a start that reports as it goes,
  such as a long repair, is not stopped after 20 minutes.
• Saved data from 0.2.0-next.4 and earlier is checked in full once, t...

Firenook 0.2.0-next.6

0.2.0-next.6 — data closed on stop, starts in milliseconds, the store's size

• Pin the engine to 767605db4248fed403523a24f6901fcc1e693d13, the merge of
  PR #93 on
  0.2.0-next.5. Its tree is the PR head's, 7d14d9b, which passed CI
  (run 39117077846)
  and the five-platform packed-install matrix
  (run 39117077854).
• A stop closes the data. Since 0.2.0-next.3 a stop left Firestore's
  store file marked open (and Storage's since 0.2.0-next.4), so every start
  after a stop repaired it first. The console's change feed, schema index
  and Overview count held the store they observed, Storage held a Firestore
  handle, and the console's whole-database walks ignored the stop. A stop
  once ready, or while starting, now closes Storage, then Firestore; one
  that cannot close a database is reported as a failed stop.
• A killed engine is no stop. The screen said "stopped … everything is
  kept" whenever a stop was asked for and the engine then ended, even by a
  kill. Now it says the stop did not finish and that the next start checks
  the data first; plain mode says the same in one line.
• Saved data opens in milliseconds. The documents' count is saved with
  every commit instead of decoding every document at each open: a 32.6 GB
  store of 2.7 million documents opened in 146 s and now in 67 ms, a 4.3 GB
  one in 1.4 s and now in 63 ms. The first start of data an earlier release
  wrote counts once and saves the result.
• firenook state:inspect --state-dir DIR shows what a stopped store's
  file holds, table by table, and how much of it is free.
• firenook state:compact --state-dir DIR returns a stopped store's
  free pages to the disk, copying the file first (a clone where the file
  system has one; --no-copy skips it). Every document stays as it is. On
  the 32.6 GB store: 32.60 GB to 27.79 GB in 16 minutes.
• The console Overview's Firestore card shows the store's size on disk.
• The old documents table is cleared once its documents are copied to
  the current layout; stores first written before 0.1.0-next.3 carried a
  dead copy of every document.
• Published straight to latest. The release workflow can now publish
  the CLI to latest in its one trusted publish, and this release used it.
  npm sets one tag per publish, so the CLI's next stays on 0.2.0-next.5
  until it is moved by hand, and a preview install, which follows next,
  is not told about this release until then.
• Data saved by 0.2.0-next.6 stays readable by 0.2.0-next.5: the count is a
  new entry the earlier release ignores. No emulator protocol or port
  changed.

0.2.0-next.5 — saved data: a quick seed check, quick repairs, clean stops

• Pin the engine to 18becb031bed1459133a5307790edb0afe19b0ca, the merge of
  PR #85 (the
  seed record, quick repairs, clean stops while starting) on 0.2.0-next.4. Its
  tree is the PR head's, 2651940, which passed CI
  (run 39048498837)
  and the five-platform packed-install matrix
  (run 39048498797).
• The seed check reads file details. Saved data (--state-dir with
  --resume-state) is picked up after comparing each seed file's size and
  times with the record made at the import (native-seed.json, beside the
  receipt); only a file whose details changed is read. On a 7.8 GB seed the
  check went from 23 to 26 s to under a second.
• Files operating systems write never block a start: .DS_Store, ._*,
  Thumbs.db, desktop.ini, __MACOSX and the like are ignored, and the
  Storage import skips ._* files.
• A first import hashes the seed beside the import, on worker threads,
  instead of reading it twice in full around it.
• A changed seed names its files, and firenook state:adopt-seed --state-dir DIR --import DIR keeps the data with the seed as it is now
  (the previous receipt is kept beside the new one).
• Quick repairs. The store's durable commits save what a repair needs,
  so a start after a crash or a killed process repairs in moments instead of
  reading the whole store. --durability per-commit leaves it out to keep
  its commit latency.
• A repair shows its progress: the Firestore row reads repairing NN%
  with the store's size, and the plain log prints how far it has got.
• A stop while starting closes the data cleanly. Ctrl-C, SIGTERM, a
  closed terminal and the launcher's pipe are listened for from the first
  moment: a seed check or a repair is abandoned with nothing opened, an
  import into a fresh run's directory ends at once, one into saved data
  finishes first. Nothing is exported before the emulators served anything.
• The start-up limit counts quiet time: a start that reports as it goes,
  such as a long repair, is not stopped after 20 minutes.
• Saved data from 0.2.0-next.4 and earlier is checked in full once, then
  recorded; data saved by 0.2.0-next.5 stays readable by 0.2.0-next.4. The
  state format is unchanged: the record is a new file beside the receipt.
• No emulator protocol or port changed.

0.2.0-next.4 — the terminal UI

• Pin the engine to 8cf0bab1f16469b0c996e3d12d266feec8d87130, the merge of
  PR #82 (the terminal UI)
  on 0.2.0-next.3. Its tree is the PR head's, 768b1ec, which passed CI
  (run 39031424075)
  and the five-platform packed-install matrix
  (run 39031424125),
  whose suite smoke now also runs the terminal UI against the packaged engine.
• The terminal UI. In a terminal, emulators:start draws its own screen:
  a start-up card with a row per service filling in with how long it took and
  what it holds, the ready summary (the console's address, the ports, the
  start-up warnings once, a newer release), the log with a line per call, its
  duration and cause and the function's own output under it at its level,
  reloads and failed saves with the code around the error, and a footer
  pinned to the window's last line with the keys: o console, r reload,
  e export, w warnings, ? keys, q (or Ctrl-C) stop, saving first.
• A start that cannot run says what went wrong, how to fix it and what
  became of the data, and exits 1. A taken port names the program holding it,
  the command that stops it and a free port for firebase.json; saved data
  refused because its seed changed says so, and names a .DS_Store Finder
  wrote into the seed. Functions that do not load leave every emulator
  running and load again on the next save.
• The plain output is unchanged. Pipes, CI, log files, emulators:exec,
  --plain, FIRENOOK_PLAIN=1 and TERM=dumb get the same lines as before,
  All emulators ready alone on its line. NO_COLOR keeps the screen without
  colour; terminals without its symbols get plain characters
  (FIRENOOK_ASCII=1 asks for them).
• The release check asks the npm registry for firenook's version tags at
  most once a day, in the background, and shows a newer release on the next
  start with the install command for the project's package manager. It is off
  in CI, in the plain output and with FIRENOOK_NO_UPDATE_CHECK=1 or
  NO_UPDATE_NOTIFIER=1.
• Engine. firenook suite --terminal-events prints FIRENOOK_EVENT <json>
  lines in place of the human lines they stand for (DESIGN.md, the terminal).
  Refused saved data now says what changed in every output: an unfinished
  import, another state format, another project, other buckets, another seed
  path, or the seed's content.
• Journeys. The New user journey waits for the form to empty before
  typing the next user, which a reset on the page's answer had wiped once.
• No emulator protocol, port, command or state format changed.

0.2.0-next.3 — Firenook's own console, and Google's Emulator UI gone

• Pin the engine to 19f2338d667e729420df12c97eee96e65cd7adb5, the merge of
  PR #80 (five checks that
  failed now and then) on PR #79
  (the UI port serves the console alone), PR #78
  (the Overview, top bar and theme), PR #76
  (a call's end line follows its output) and PR #64
  (the console for every emulated service). Its tree is the PR head's,
  8b3d3d4, which passed CI
  (run 39026825633)
  and the five-platform packed-install matrix
  (run 39026825610).
• The console. /console on the UI port covers every service the suite
  runs: Firestore data, queries, explain and security rules; Authentication
  users, activity, the inbox of codes and links, and settings; Storage files
  and rules; Functions with their invocations, schedules and load log;
  Extensions; Eventarc; Pub/Sub; Cloud Tasks; Logs; and an Overview with each
  section's health, recent problems, snapshots and resets. It follows the
  engine live over one connection per browser and works offline.
• Google's Emulator UI is gone. Every feature of the Emulator UI 1.15 has a
  console screen (support/console-parity.md), so nothing is downloaded and
  the UI port serves the console alone. The port's root and the official UI's
  addresses (/firestore/…, /auth, /storage/…, /extensions/…,
  /logs?q=…) lead to the co...

Firenook 0.2.0-next.5

0.2.0-next.5 — saved data: a quick seed check, quick repairs, clean stops

• Pin the engine to 18becb031bed1459133a5307790edb0afe19b0ca, the merge of
  PR #85 (the
  seed record, quick repairs, clean stops while starting) on 0.2.0-next.4. Its
  tree is the PR head's, 2651940, which passed CI
  (run 39048498837)
  and the five-platform packed-install matrix
  (run 39048498797).
• The seed check reads file details. Saved data (--state-dir with
  --resume-state) is picked up after comparing each seed file's size and
  times with the record made at the import (native-seed.json, beside the
  receipt); only a file whose details changed is read. On a 7.8 GB seed the
  check went from 23 to 26 s to under a second.
• Files operating systems write never block a start: .DS_Store, ._*,
  Thumbs.db, desktop.ini, __MACOSX and the like are ignored, and the
  Storage import skips ._* files.
• A first import hashes the seed beside the import, on worker threads,
  instead of reading it twice in full around it.
• A changed seed names its files, and firenook state:adopt-seed --state-dir DIR --import DIR keeps the data with the seed as it is now
  (the previous receipt is kept beside the new one).
• Quick repairs. The store's durable commits save what a repair needs,
  so a start after a crash or a killed process repairs in moments instead of
  reading the whole store. --durability per-commit leaves it out to keep
  its commit latency.
• A repair shows its progress: the Firestore row reads repairing NN%
  with the store's size, and the plain log prints how far it has got.
• A stop while starting closes the data cleanly. Ctrl-C, SIGTERM, a
  closed terminal and the launcher's pipe are listened for from the first
  moment: a seed check or a repair is abandoned with nothing opened, an
  import into a fresh run's directory ends at once, one into saved data
  finishes first. Nothing is exported before the emulators served anything.
• The start-up limit counts quiet time: a start that reports as it goes,
  such as a long repair, is not stopped after 20 minutes.
• Saved data from 0.2.0-next.4 and earlier is checked in full once, then
  recorded; data saved by 0.2.0-next.5 stays readable by 0.2.0-next.4. The
  state format is unchanged: the record is a new file beside the receipt.
• No emulator protocol or port changed.

0.2.0-next.4 — the terminal UI

• Pin the engine to 8cf0bab1f16469b0c996e3d12d266feec8d87130, the merge of
  PR #82 (the terminal UI)
  on 0.2.0-next.3. Its tree is the PR head's, 768b1ec, which passed CI
  (run 39031424075)
  and the five-platform packed-install matrix
  (run 39031424125),
  whose suite smoke now also runs the terminal UI against the packaged engine.
• The terminal UI. In a terminal, emulators:start draws its own screen:
  a start-up card with a row per service filling in with how long it took and
  what it holds, the ready summary (the console's address, the ports, the
  start-up warnings once, a newer release), the log with a line per call, its
  duration and cause and the function's own output under it at its level,
  reloads and failed saves with the code around the error, and a footer
  pinned to the window's last line with the keys: o console, r reload,
  e export, w warnings, ? keys, q (or Ctrl-C) stop, saving first.
• A start that cannot run says what went wrong, how to fix it and what
  became of the data, and exits 1. A taken port names the program holding it,
  the command that stops it and a free port for firebase.json; saved data
  refused because its seed changed says so, and names a .DS_Store Finder
  wrote into the seed. Functions that do not load leave every emulator
  running and load again on the next save.
• The plain output is unchanged. Pipes, CI, log files, emulators:exec,
  --plain, FIRENOOK_PLAIN=1 and TERM=dumb get the same lines as before,
  All emulators ready alone on its line. NO_COLOR keeps the screen without
  colour; terminals without its symbols get plain characters
  (FIRENOOK_ASCII=1 asks for them).
• The release check asks the npm registry for firenook's version tags at
  most once a day, in the background, and shows a newer release on the next
  start with the install command for the project's package manager. It is off
  in CI, in the plain output and with FIRENOOK_NO_UPDATE_CHECK=1 or
  NO_UPDATE_NOTIFIER=1.
• Engine. firenook suite --terminal-events prints FIRENOOK_EVENT <json>
  lines in place of the human lines they stand for (DESIGN.md, the terminal).
  Refused saved data now says what changed in every output: an unfinished
  import, another state format, another project, other buckets, another seed
  path, or the seed's content.
• Journeys. The New user journey waits for the form to empty before
  typing the next user, which a reset on the page's answer had wiped once.
• No emulator protocol, port, command or state format changed.

0.2.0-next.3 — Firenook's own console, and Google's Emulator UI gone

• Pin the engine to 19f2338d667e729420df12c97eee96e65cd7adb5, the merge of
  PR #80 (five checks that
  failed now and then) on PR #79
  (the UI port serves the console alone), PR #78
  (the Overview, top bar and theme), PR #76
  (a call's end line follows its output) and PR #64
  (the console for every emulated service). Its tree is the PR head's,
  8b3d3d4, which passed CI
  (run 39026825633)
  and the five-platform packed-install matrix
  (run 39026825610).
• The console. /console on the UI port covers every service the suite
  runs: Firestore data, queries, explain and security rules; Authentication
  users, activity, the inbox of codes and links, and settings; Storage files
  and rules; Functions with their invocations, schedules and load log;
  Extensions; Eventarc; Pub/Sub; Cloud Tasks; Logs; and an Overview with each
  section's health, recent problems, snapshots and resets. It follows the
  engine live over one connection per browser and works offline.
• Google's Emulator UI is gone. Every feature of the Emulator UI 1.15 has a
  console screen (support/console-parity.md), so nothing is downloaded and
  the UI port serves the console alone. The port's root and the official UI's
  addresses (/firestore/…, /auth, /storage/…, /extensions/…,
  /logs?q=…) lead to the console's page for the same thing.
  /api/config, the logging WebSocket and the Firestore Requests socket are
  unchanged.
• CLI. firenook setup downloads nothing and stays so that scripts which
  run it keep passing. The engine's --ui-archive argument is gone; the npm
  package never passed it by hand. doctor no longer reports asset files.
• Functions. A call's last log lines no longer appear after its own
  Finished "…" line. The source watcher waits for a second of quiet after
  the last change (at most five after the first), as the official CLI does,
  and an extension's parameter file is read only once it holds still, so a
  save caught between truncate and write no longer reloads an instance with
  every value at its default.
• No emulator protocol, port, command or state format changed otherwise. A
  state written by 0.2.0-next.2 was picked up by a local candidate of this
  revision, written to there, and picked up by 0.2.0-next.2 again. The same
  candidate started a real project with three registry extensions: 24
  handlers admitted, the 2 that firebase-tools ignores reported.

0.2.0-next.2 — the read path, incremental listeners and a field index

• Pin the engine to 63d554c15f2699cf623c7fac19a4d1393c77f322, the qualified head of
  PR #66 (the equality field
  index) on PR #67 (clippy on
  Rust 1.99), PR #63 (the
  console scaffold) and PR #62
  (the read path). This exact revision passed CI
  (run 37119862089)
  and the five-platform packed-install matrix
  (run 37119862029);
  locally the workspace tests (51 suites), clippy, the packaging tests (92/92)
  and the Firestore conformance suite in memory and disk modes (37/37 each)
  passed, and a store written by it reopened on 0.2.0-next.1, was written
  there and reopened here with its field index rebuilt.
• Firestore no longer reads the whole store to serve the Emulator UI and the
  listings it polls: ListCollectionIds, ListDocuments with missing
  documents or no collection id, recursive delete and clear-database walk keys
  under a prefix; an unfiltered count() reads only the scope index; REST
  runQuery honours select. Firestore reads run on a bounded read pool
  instead of the shared async workers, so a long scan no longer stalls Auth,
  Storage or the UI; Auth persists its state only when a request changed it;
  the Requests-diagnostics report is summarized once a minute.
• Listen streams wake on a commit notifier instead of ...

Firenook 0.2.0-next.4

0.2.0-next.4 — the terminal UI

• Pin the engine to 8cf0bab1f16469b0c996e3d12d266feec8d87130, the merge of
  PR #82 (the terminal UI)
  on 0.2.0-next.3. Its tree is the PR head's, 768b1ec, which passed CI
  (run 39031424075)
  and the five-platform packed-install matrix
  (run 39031424125),
  whose suite smoke now also runs the terminal UI against the packaged engine.
• The terminal UI. In a terminal, emulators:start draws its own screen:
  a start-up card with a row per service filling in with how long it took and
  what it holds, the ready summary (the console's address, the ports, the
  start-up warnings once, a newer release), the log with a line per call, its
  duration and cause and the function's own output under it at its level,
  reloads and failed saves with the code around the error, and a footer
  pinned to the window's last line with the keys: o console, r reload,
  e export, w warnings, ? keys, q (or Ctrl-C) stop, saving first.
• A start that cannot run says what went wrong, how to fix it and what
  became of the data, and exits 1. A taken port names the program holding it,
  the command that stops it and a free port for firebase.json; saved data
  refused because its seed changed says so, and names a .DS_Store Finder
  wrote into the seed. Functions that do not load leave every emulator
  running and load again on the next save.
• The plain output is unchanged. Pipes, CI, log files, emulators:exec,
  --plain, FIRENOOK_PLAIN=1 and TERM=dumb get the same lines as before,
  All emulators ready alone on its line. NO_COLOR keeps the screen without
  colour; terminals without its symbols get plain characters
  (FIRENOOK_ASCII=1 asks for them).
• The release check asks the npm registry for firenook's version tags at
  most once a day, in the background, and shows a newer release on the next
  start with the install command for the project's package manager. It is off
  in CI, in the plain output and with FIRENOOK_NO_UPDATE_CHECK=1 or
  NO_UPDATE_NOTIFIER=1.
• Engine. firenook suite --terminal-events prints FIRENOOK_EVENT <json>
  lines in place of the human lines they stand for (DESIGN.md, the terminal).
  Refused saved data now says what changed in every output: an unfinished
  import, another state format, another project, other buckets, another seed
  path, or the seed's content.
• Journeys. The New user journey waits for the form to empty before
  typing the next user, which a reset on the page's answer had wiped once.
• No emulator protocol, port, command or state format changed.

0.2.0-next.3 — Firenook's own console, and Google's Emulator UI gone

• Pin the engine to 19f2338d667e729420df12c97eee96e65cd7adb5, the merge of
  PR #80 (five checks that
  failed now and then) on PR #79
  (the UI port serves the console alone), PR #78
  (the Overview, top bar and theme), PR #76
  (a call's end line follows its output) and PR #64
  (the console for every emulated service). Its tree is the PR head's,
  8b3d3d4, which passed CI
  (run 39026825633)
  and the five-platform packed-install matrix
  (run 39026825610).
• The console. /console on the UI port covers every service the suite
  runs: Firestore data, queries, explain and security rules; Authentication
  users, activity, the inbox of codes and links, and settings; Storage files
  and rules; Functions with their invocations, schedules and load log;
  Extensions; Eventarc; Pub/Sub; Cloud Tasks; Logs; and an Overview with each
  section's health, recent problems, snapshots and resets. It follows the
  engine live over one connection per browser and works offline.
• Google's Emulator UI is gone. Every feature of the Emulator UI 1.15 has a
  console screen (support/console-parity.md), so nothing is downloaded and
  the UI port serves the console alone. The port's root and the official UI's
  addresses (/firestore/…, /auth, /storage/…, /extensions/…,
  /logs?q=…) lead to the console's page for the same thing.
  /api/config, the logging WebSocket and the Firestore Requests socket are
  unchanged.
• CLI. firenook setup downloads nothing and stays so that scripts which
  run it keep passing. The engine's --ui-archive argument is gone; the npm
  package never passed it by hand. doctor no longer reports asset files.
• Functions. A call's last log lines no longer appear after its own
  Finished "…" line. The source watcher waits for a second of quiet after
  the last change (at most five after the first), as the official CLI does,
  and an extension's parameter file is read only once it holds still, so a
  save caught between truncate and write no longer reloads an instance with
  every value at its default.
• No emulator protocol, port, command or state format changed otherwise. A
  state written by 0.2.0-next.2 was picked up by a local candidate of this
  revision, written to there, and picked up by 0.2.0-next.2 again. The same
  candidate started a real project with three registry extensions: 24
  handlers admitted, the 2 that firebase-tools ignores reported.

0.2.0-next.2 — the read path, incremental listeners and a field index

• Pin the engine to 63d554c15f2699cf623c7fac19a4d1393c77f322, the qualified head of
  PR #66 (the equality field
  index) on PR #67 (clippy on
  Rust 1.99), PR #63 (the
  console scaffold) and PR #62
  (the read path). This exact revision passed CI
  (run 37119862089)
  and the five-platform packed-install matrix
  (run 37119862029);
  locally the workspace tests (51 suites), clippy, the packaging tests (92/92)
  and the Firestore conformance suite in memory and disk modes (37/37 each)
  passed, and a store written by it reopened on 0.2.0-next.1, was written
  there and reopened here with its field index rebuilt.
• Firestore no longer reads the whole store to serve the Emulator UI and the
  listings it polls: ListCollectionIds, ListDocuments with missing
  documents or no collection id, recursive delete and clear-database walk keys
  under a prefix; an unfiltered count() reads only the scope index; REST
  runQuery honours select. Firestore reads run on a bounded read pool
  instead of the shared async workers, so a long scan no longer stalls Auth,
  Storage or the UI; Auth persists its state only when a request changed it;
  the Requests-diagnostics report is summarized once a minute.
• Listen streams wake on a commit notifier instead of a 10 ms poll and
  maintain their views incrementally, falling back to full evaluation only
  for window exits and moves, offset, limit_to_last and nearest-neighbour
  queries.
• Disk state keeps an equality index over every document's top-level fields:
  a query with == or in on them reads only the documents holding the value
  instead of its whole collection. Every filter is still evaluated on each
  candidate, so results are unchanged; ranges, or, !=, not-in, array
  membership, nested paths and collection groups still scan. A state last
  written by an earlier release rebuilds the index on its first start, in the
  pass that already reads every document (measured at 246 s for a 32.6 GB,
  1.9-million-document state); FIRENOOK_FIELD_INDEXES=0 turns it off.
• The emulator's own console is served under /console on the UI port,
  beside the Google Emulator UI, which stays the default. It is an early
  scaffold: overview, shell and command palette.
• No emulator behaviour, port, command or file format changed otherwise; the
  index tables are ignored by 0.2.0-next.1, which can still open the state.

0.2.0-next.1 — Firenook: the project renamed, one license

• Pin the engine to 9d6925115e12e49524b9991f5924d112eb14ffd1, the qualified head of
  PR #58 (the rename) on the
  next.9 engine. This exact revision passed CI
  (run 35445747233)
  and the five-platform packed-install matrix
  (run 35445747328);
  a local candidate built from it passed the packed npm and Bun installs and
  the complete-suite smoke, and the native-upgrade verifier resumed state
  written by the last engine published under the old name
  (0.1.0-next.3) with it: import, in-place adoption, reopen, both browser
  listen modes, portable rollback. Every oracle corpus replays unchanged
  (Functions/Extensions 271/271, Cloud Tasks 61/61, Auth 1068 steps with 0
  mismatches, Pub/Sub 916 steps with 0 mismatches). The engine is the
  0.1.0-next.9 engine plus the rename, the store-file adoption and the
  legacy resume-token decoding; no emulator behaviour changed.
• The project is renamed from Fireside to Firenook; this is the first release
  under the new name and the minor version moves because the command and the
  package names change. @fireside-dev/cli becomes firenook (binary
  firenook), the platform packages @fireside-dev/<platform> become
  `@firenook/cli-<plat...

Firenook 0.2.0-next.3

0.2.0-next.3 — Firenook's own console, and Google's Emulator UI gone

• Pin the engine to 19f2338d667e729420df12c97eee96e65cd7adb5, the merge of
  PR #80 (five checks that
  failed now and then) on PR #79
  (the UI port serves the console alone), PR #78
  (the Overview, top bar and theme), PR #76
  (a call's end line follows its output) and PR #64
  (the console for every emulated service). Its tree is the PR head's,
  8b3d3d4, which passed CI
  (run 39026825633)
  and the five-platform packed-install matrix
  (run 39026825610).
• The console. /console on the UI port covers every service the suite
  runs: Firestore data, queries, explain and security rules; Authentication
  users, activity, the inbox of codes and links, and settings; Storage files
  and rules; Functions with their invocations, schedules and load log;
  Extensions; Eventarc; Pub/Sub; Cloud Tasks; Logs; and an Overview with each
  section's health, recent problems, snapshots and resets. It follows the
  engine live over one connection per browser and works offline.
• Google's Emulator UI is gone. Every feature of the Emulator UI 1.15 has a
  console screen (support/console-parity.md), so nothing is downloaded and
  the UI port serves the console alone. The port's root and the official UI's
  addresses (/firestore/…, /auth, /storage/…, /extensions/…,
  /logs?q=…) lead to the console's page for the same thing.
  /api/config, the logging WebSocket and the Firestore Requests socket are
  unchanged.
• CLI. firenook setup downloads nothing and stays so that scripts which
  run it keep passing. The engine's --ui-archive argument is gone; the npm
  package never passed it by hand. doctor no longer reports asset files.
• Functions. A call's last log lines no longer appear after its own
  Finished "…" line. The source watcher waits for a second of quiet after
  the last change (at most five after the first), as the official CLI does,
  and an extension's parameter file is read only once it holds still, so a
  save caught between truncate and write no longer reloads an instance with
  every value at its default.
• No emulator protocol, port, command or state format changed otherwise. A
  state written by 0.2.0-next.2 was picked up by a local candidate of this
  revision, written to there, and picked up by 0.2.0-next.2 again. The same
  candidate started a real project with three registry extensions: 24
  handlers admitted, the 2 that firebase-tools ignores reported.

0.2.0-next.2 — the read path, incremental listeners and a field index

• Pin the engine to 63d554c15f2699cf623c7fac19a4d1393c77f322, the qualified head of
  PR #66 (the equality field
  index) on PR #67 (clippy on
  Rust 1.99), PR #63 (the
  console scaffold) and PR #62
  (the read path). This exact revision passed CI
  (run 37119862089)
  and the five-platform packed-install matrix
  (run 37119862029);
  locally the workspace tests (51 suites), clippy, the packaging tests (92/92)
  and the Firestore conformance suite in memory and disk modes (37/37 each)
  passed, and a store written by it reopened on 0.2.0-next.1, was written
  there and reopened here with its field index rebuilt.
• Firestore no longer reads the whole store to serve the Emulator UI and the
  listings it polls: ListCollectionIds, ListDocuments with missing
  documents or no collection id, recursive delete and clear-database walk keys
  under a prefix; an unfiltered count() reads only the scope index; REST
  runQuery honours select. Firestore reads run on a bounded read pool
  instead of the shared async workers, so a long scan no longer stalls Auth,
  Storage or the UI; Auth persists its state only when a request changed it;
  the Requests-diagnostics report is summarized once a minute.
• Listen streams wake on a commit notifier instead of a 10 ms poll and
  maintain their views incrementally, falling back to full evaluation only
  for window exits and moves, offset, limit_to_last and nearest-neighbour
  queries.
• Disk state keeps an equality index over every document's top-level fields:
  a query with == or in on them reads only the documents holding the value
  instead of its whole collection. Every filter is still evaluated on each
  candidate, so results are unchanged; ranges, or, !=, not-in, array
  membership, nested paths and collection groups still scan. A state last
  written by an earlier release rebuilds the index on its first start, in the
  pass that already reads every document (measured at 246 s for a 32.6 GB,
  1.9-million-document state); FIRENOOK_FIELD_INDEXES=0 turns it off.
• The emulator's own console is served under /console on the UI port,
  beside the Google Emulator UI, which stays the default. It is an early
  scaffold: overview, shell and command palette.
• No emulator behaviour, port, command or file format changed otherwise; the
  index tables are ignored by 0.2.0-next.1, which can still open the state.

0.2.0-next.1 — Firenook: the project renamed, one license

• Pin the engine to 9d6925115e12e49524b9991f5924d112eb14ffd1, the qualified head of
  PR #58 (the rename) on the
  next.9 engine. This exact revision passed CI
  (run 35445747233)
  and the five-platform packed-install matrix
  (run 35445747328);
  a local candidate built from it passed the packed npm and Bun installs and
  the complete-suite smoke, and the native-upgrade verifier resumed state
  written by the last engine published under the old name
  (0.1.0-next.3) with it: import, in-place adoption, reopen, both browser
  listen modes, portable rollback. Every oracle corpus replays unchanged
  (Functions/Extensions 271/271, Cloud Tasks 61/61, Auth 1068 steps with 0
  mismatches, Pub/Sub 916 steps with 0 mismatches). The engine is the
  0.1.0-next.9 engine plus the rename, the store-file adoption and the
  legacy resume-token decoding; no emulator behaviour changed.
• The project is renamed from Fireside to Firenook; this is the first release
  under the new name and the minor version moves because the command and the
  package names change. @fireside-dev/cli becomes firenook (binary
  firenook), the platform packages @fireside-dev/<platform> become
  @firenook/cli-<platform>, every FIRESIDE_* environment variable becomes
  FIRENOOK_* (FIRENOOK_SHUTDOWN, FIRENOOK_CONTROL_STDIN,
  FIRENOOK_OFFLINE, FIRENOOK_LOCATOR_DIR, FIRENOOK_FUNCTIONS_HOST_READY,
  FIRENOOK_WORKER_*, FIRENOOK_DEFAULT_*, FIRENOOK_PUBLIC_POLICY,
  FIRENOOK_PUBLICATION_POLICY, …), the run directory .fireside/runs becomes
  .firenook/runs, the MCP tools fireside_* become firenook_*, and
  fireside native … becomes firenook native …. No alias of the old names
  is kept. The hub locator file (hub-<projectId>.json), the default ports,
  the firebase.json handling and the Emulator UI asset flow are unchanged.
  Persisted suite state written by an earlier release is adopted in place:
  the store files fireside.redb/fireside.wal are renamed to
  firenook.redb/firenook.wal once, before the state is validated, so a
  --resume-state directory keeps its data across the upgrade (CI resumes
  the last engine published under the old name, 0.1.0-next.3, with this
  one).
• One license: the MIT/Apache dual license is replaced by the Apache License
  2.0 alone (LICENSE), with a NOTICE file and TRADEMARKS.md (forks and
  modified builds are distributed under another name). Both files ship in
  every package.
• The repository moves to github.com/firenook-dev/firenook; GitHub redirects
  the old URLs. Release history, banked benchmark results and the frozen
  oracle corpora keep the identifiers they were recorded and digest-pinned
  with (project ids such as demo-fireside-*), and
  scripts/check-independence.mjs now fails on any other occurrence of the
  former name.

0.1.0-next.9 — Cloud Tasks emulator, every configuration shape, the CLI surface

• Pin the engine to 7fb0c350078c94fc65a83a6f3c012a917779fbbd, the qualified head of
  PR #55 (Phases K, L and
  M) on the next.8 engine. This exact revision passed CI
  (run 35437156565)
  and the five-platform packed-install matrix
  (run 35437156569),
  and a local candidate built from it passed a representative private
  consumer's extensions, integration and installed-launcher gates and its
  nine browser journeys on the full-data stack, plus an end-to-end run of
  every new command on a project scaffolded by fireside init; see
  support/phase-k-tasks.md, support/phase-l-configuration.md,
  support/phase-m-cli.md and the receipts blocks of the three gate
  files under benchmarks/. The per-release-line two-hour soak stands from
  next.6 and next.7.
• Cloud Tasks is a full emulator (Phase K). The Tasks port serves the four
  routes of the official emulator — queue re...

Firenook 0.2.0-next.2

0.2.0-next.2 — the read path, incremental listeners and a field index

• Pin the engine to 63d554c15f2699cf623c7fac19a4d1393c77f322, the qualified head of
  PR #66 (the equality field
  index) on PR #67 (clippy on
  Rust 1.99), PR #63 (the
  console scaffold) and PR #62
  (the read path). This exact revision passed CI
  (run 37119862089)
  and the five-platform packed-install matrix
  (run 37119862029);
  locally the workspace tests (51 suites), clippy, the packaging tests (92/92)
  and the Firestore conformance suite in memory and disk modes (37/37 each)
  passed, and a store written by it reopened on 0.2.0-next.1, was written
  there and reopened here with its field index rebuilt.
• Firestore no longer reads the whole store to serve the Emulator UI and the
  listings it polls: ListCollectionIds, ListDocuments with missing
  documents or no collection id, recursive delete and clear-database walk keys
  under a prefix; an unfiltered count() reads only the scope index; REST
  runQuery honours select. Firestore reads run on a bounded read pool
  instead of the shared async workers, so a long scan no longer stalls Auth,
  Storage or the UI; Auth persists its state only when a request changed it;
  the Requests-diagnostics report is summarized once a minute.
• Listen streams wake on a commit notifier instead of a 10 ms poll and
  maintain their views incrementally, falling back to full evaluation only
  for window exits and moves, offset, limit_to_last and nearest-neighbour
  queries.
• Disk state keeps an equality index over every document's top-level fields:
  a query with == or in on them reads only the documents holding the value
  instead of its whole collection. Every filter is still evaluated on each
  candidate, so results are unchanged; ranges, or, !=, not-in, array
  membership, nested paths and collection groups still scan. A state last
  written by an earlier release rebuilds the index on its first start, in the
  pass that already reads every document (measured at 246 s for a 32.6 GB,
  1.9-million-document state); FIRENOOK_FIELD_INDEXES=0 turns it off.
• The emulator's own console is served under /console on the UI port,
  beside the Google Emulator UI, which stays the default. It is an early
  scaffold: overview, shell and command palette.
• No emulator behaviour, port, command or file format changed otherwise; the
  index tables are ignored by 0.2.0-next.1, which can still open the state.

0.2.0-next.1 — Firenook: the project renamed, one license

• Pin the engine to 9d6925115e12e49524b9991f5924d112eb14ffd1, the qualified head of
  PR #58 (the rename) on the
  next.9 engine. This exact revision passed CI
  (run 35445747233)
  and the five-platform packed-install matrix
  (run 35445747328);
  a local candidate built from it passed the packed npm and Bun installs and
  the complete-suite smoke, and the native-upgrade verifier resumed state
  written by the last engine published under the old name
  (0.1.0-next.3) with it: import, in-place adoption, reopen, both browser
  listen modes, portable rollback. Every oracle corpus replays unchanged
  (Functions/Extensions 271/271, Cloud Tasks 61/61, Auth 1068 steps with 0
  mismatches, Pub/Sub 916 steps with 0 mismatches). The engine is the
  0.1.0-next.9 engine plus the rename, the store-file adoption and the
  legacy resume-token decoding; no emulator behaviour changed.
• The project is renamed from Fireside to Firenook; this is the first release
  under the new name and the minor version moves because the command and the
  package names change. @fireside-dev/cli becomes firenook (binary
  firenook), the platform packages @fireside-dev/<platform> become
  @firenook/cli-<platform>, every FIRESIDE_* environment variable becomes
  FIRENOOK_* (FIRENOOK_SHUTDOWN, FIRENOOK_CONTROL_STDIN,
  FIRENOOK_OFFLINE, FIRENOOK_LOCATOR_DIR, FIRENOOK_FUNCTIONS_HOST_READY,
  FIRENOOK_WORKER_*, FIRENOOK_DEFAULT_*, FIRENOOK_PUBLIC_POLICY,
  FIRENOOK_PUBLICATION_POLICY, …), the run directory .fireside/runs becomes
  .firenook/runs, the MCP tools fireside_* become firenook_*, and
  fireside native … becomes firenook native …. No alias of the old names
  is kept. The hub locator file (hub-<projectId>.json), the default ports,
  the firebase.json handling and the Emulator UI asset flow are unchanged.
  Persisted suite state written by an earlier release is adopted in place:
  the store files fireside.redb/fireside.wal are renamed to
  firenook.redb/firenook.wal once, before the state is validated, so a
  --resume-state directory keeps its data across the upgrade (CI resumes
  the last engine published under the old name, 0.1.0-next.3, with this
  one).
• One license: the MIT/Apache dual license is replaced by the Apache License
  2.0 alone (LICENSE), with a NOTICE file and TRADEMARKS.md (forks and
  modified builds are distributed under another name). Both files ship in
  every package.
• The repository moves to github.com/firenook-dev/firenook; GitHub redirects
  the old URLs. Release history, banked benchmark results and the frozen
  oracle corpora keep the identifiers they were recorded and digest-pinned
  with (project ids such as demo-fireside-*), and
  scripts/check-independence.mjs now fails on any other occurrence of the
  former name.

0.1.0-next.9 — Cloud Tasks emulator, every configuration shape, the CLI surface

• Pin the engine to 7fb0c350078c94fc65a83a6f3c012a917779fbbd, the qualified head of
  PR #55 (Phases K, L and
  M) on the next.8 engine. This exact revision passed CI
  (run 35437156565)
  and the five-platform packed-install matrix
  (run 35437156569),
  and a local candidate built from it passed a representative private
  consumer's extensions, integration and installed-launcher gates and its
  nine browser journeys on the full-data stack, plus an end-to-end run of
  every new command on a project scaffolded by fireside init; see
  support/phase-k-tasks.md, support/phase-l-configuration.md,
  support/phase-m-cli.md and the receipts blocks of the three gate
  files under benchmarks/. The per-release-line two-hour soak stands from
  next.6 and next.7.
• Cloud Tasks is a full emulator (Phase K). The Tasks port serves the four
  routes of the official emulator — queue registration, enqueue, delete and
  /queueStats — with its Express-shaped answers, registers a queue for
  every onTaskDispatched export at readiness and after each reload with the
  function's URL as the default target, and dispatches exactly as
  taskQueue.js does: a token bucket per queue that starts empty and refills
  once a second, dispatch slots sized by maxConcurrentDispatches, the
  X-CloudTasks-QueueName/TaskName/TaskRetryCount/TaskExecutionCount/
  TaskETA headers with the caller's headers overriding them and
  TaskPreviousResponse from the second attempt, the retry ladder with its
  backoff formula and the maxAttempts off-by-one, the execution count
  incremented on non-5xx failures only, the dispatchDeadline abort, and
  the controller's cadence (idle queues polled once a second, active queues
  continuously). getFunctions().taskQueue().enqueue() and .delete() from
  a function or an app with CLOUD_TASKS_EMULATOR_HOST set reach the
  handler as on the official suite. The corpus recorded from firebase-tools
  15.22.0 (6 programs, 61 steps, 39 handler observations in
  conformance/fixtures/tasks-v1) replays with 0 mismatches and no named
  divergence, three runs identical; the Functions runtime corpus replays
  unchanged with the emulator mounted. Not done because the official
  emulator does not do it either: scheduleTime as a delay, OIDC tokens on
  dispatch, queue pause/resume/purge, task listing, the Cloud Tasks v2 API,
  persistence, a UI tab.
• Every configuration shape of the tracker starts (Phase L). A service
  starts when firebase.json configures it, exactly as the official
  filterEmulatorTargets decides, and --only narrows the set; a project
  without Functions or Storage runs (Eventarc and Tasks follow Functions,
  the requests WebSocket follows Firestore, the UI and logging listeners
  follow emulators.ui.enabled, the hub always runs). Any project id is
  accepted: a demo-* id prints the official demo line, a real id prints
  the official "will affect production" warning for services not running,
  and the suite never contacts Firebase either way (every worker gets the
  emulator hosts and no Google credentials; user code with explicit
  credentials can still reach the real project). Any listen host is bound;
  a wildcard is announced to clients as the loopback address as the official
  connectableHostname does, and a non-loopback bind prints one warning
  because the emulators have no authentication. emulators.singleProjectMode
  (default true) warns once per foreign project id with the official Auth
  wording. firestore may list several databases, each with its own rules
  (a project-wide hot reload replaces every database's rules, as
  officially); every database is exported and imported. The storage section
  may be the {rules} object, the target array, or absent (demo projects
  get...

Firenook 0.2.0-next.1

0.2.0-next.1 — Firenook: the project renamed, one license

• Pin the engine to 9d6925115e12e49524b9991f5924d112eb14ffd1, the qualified head of
  PR #58 (the rename) on the
  next.9 engine. This exact revision passed CI
  (run 35445747233)
  and the five-platform packed-install matrix
  (run 35445747328);
  a local candidate built from it passed the packed npm and Bun installs and
  the complete-suite smoke, and the native-upgrade verifier resumed state
  written by the last engine published under the old name
  (0.1.0-next.3) with it: import, in-place adoption, reopen, both browser
  listen modes, portable rollback. Every oracle corpus replays unchanged
  (Functions/Extensions 271/271, Cloud Tasks 61/61, Auth 1068 steps with 0
  mismatches, Pub/Sub 916 steps with 0 mismatches). The engine is the
  0.1.0-next.9 engine plus the rename, the store-file adoption and the
  legacy resume-token decoding; no emulator behaviour changed.
• The project is renamed from Fireside to Firenook; this is the first release
  under the new name and the minor version moves because the command and the
  package names change. @fireside-dev/cli becomes firenook (binary
  firenook), the platform packages @fireside-dev/<platform> become
  @firenook/cli-<platform>, every FIRESIDE_* environment variable becomes
  FIRENOOK_* (FIRENOOK_SHUTDOWN, FIRENOOK_CONTROL_STDIN,
  FIRENOOK_OFFLINE, FIRENOOK_LOCATOR_DIR, FIRENOOK_FUNCTIONS_HOST_READY,
  FIRENOOK_WORKER_*, FIRENOOK_DEFAULT_*, FIRENOOK_PUBLIC_POLICY,
  FIRENOOK_PUBLICATION_POLICY, …), the run directory .fireside/runs becomes
  .firenook/runs, the MCP tools fireside_* become firenook_*, and
  fireside native … becomes firenook native …. No alias of the old names
  is kept. The hub locator file (hub-<projectId>.json), the default ports,
  the firebase.json handling and the Emulator UI asset flow are unchanged.
  Persisted suite state written by an earlier release is adopted in place:
  the store files fireside.redb/fireside.wal are renamed to
  firenook.redb/firenook.wal once, before the state is validated, so a
  --resume-state directory keeps its data across the upgrade (CI resumes
  the last engine published under the old name, 0.1.0-next.3, with this
  one).
• One license: the MIT/Apache dual license is replaced by the Apache License
  2.0 alone (LICENSE), with a NOTICE file and TRADEMARKS.md (forks and
  modified builds are distributed under another name). Both files ship in
  every package.
• The repository moves to github.com/firenook-dev/firenook; GitHub redirects
  the old URLs. Release history, banked benchmark results and the frozen
  oracle corpora keep the identifiers they were recorded and digest-pinned
  with (project ids such as demo-fireside-*), and
  scripts/check-independence.mjs now fails on any other occurrence of the
  former name.

0.1.0-next.9 — Cloud Tasks emulator, every configuration shape, the CLI surface

• Pin the engine to 7fb0c350078c94fc65a83a6f3c012a917779fbbd, the qualified head of
  PR #55 (Phases K, L and
  M) on the next.8 engine. This exact revision passed CI
  (run 35437156565)
  and the five-platform packed-install matrix
  (run 35437156569),
  and a local candidate built from it passed a representative private
  consumer's extensions, integration and installed-launcher gates and its
  nine browser journeys on the full-data stack, plus an end-to-end run of
  every new command on a project scaffolded by fireside init; see
  support/phase-k-tasks.md, support/phase-l-configuration.md,
  support/phase-m-cli.md and the receipts blocks of the three gate
  files under benchmarks/. The per-release-line two-hour soak stands from
  next.6 and next.7.
• Cloud Tasks is a full emulator (Phase K). The Tasks port serves the four
  routes of the official emulator — queue registration, enqueue, delete and
  /queueStats — with its Express-shaped answers, registers a queue for
  every onTaskDispatched export at readiness and after each reload with the
  function's URL as the default target, and dispatches exactly as
  taskQueue.js does: a token bucket per queue that starts empty and refills
  once a second, dispatch slots sized by maxConcurrentDispatches, the
  X-CloudTasks-QueueName/TaskName/TaskRetryCount/TaskExecutionCount/
  TaskETA headers with the caller's headers overriding them and
  TaskPreviousResponse from the second attempt, the retry ladder with its
  backoff formula and the maxAttempts off-by-one, the execution count
  incremented on non-5xx failures only, the dispatchDeadline abort, and
  the controller's cadence (idle queues polled once a second, active queues
  continuously). getFunctions().taskQueue().enqueue() and .delete() from
  a function or an app with CLOUD_TASKS_EMULATOR_HOST set reach the
  handler as on the official suite. The corpus recorded from firebase-tools
  15.22.0 (6 programs, 61 steps, 39 handler observations in
  conformance/fixtures/tasks-v1) replays with 0 mismatches and no named
  divergence, three runs identical; the Functions runtime corpus replays
  unchanged with the emulator mounted. Not done because the official
  emulator does not do it either: scheduleTime as a delay, OIDC tokens on
  dispatch, queue pause/resume/purge, task listing, the Cloud Tasks v2 API,
  persistence, a UI tab.
• Every configuration shape of the tracker starts (Phase L). A service
  starts when firebase.json configures it, exactly as the official
  filterEmulatorTargets decides, and --only narrows the set; a project
  without Functions or Storage runs (Eventarc and Tasks follow Functions,
  the requests WebSocket follows Firestore, the UI and logging listeners
  follow emulators.ui.enabled, the hub always runs). Any project id is
  accepted: a demo-* id prints the official demo line, a real id prints
  the official "will affect production" warning for services not running,
  and the suite never contacts Firebase either way (every worker gets the
  emulator hosts and no Google credentials; user code with explicit
  credentials can still reach the real project). Any listen host is bound;
  a wildcard is announced to clients as the loopback address as the official
  connectableHostname does, and a non-loopback bind prints one warning
  because the emulators have no authentication. emulators.singleProjectMode
  (default true) warns once per foreign project id with the official Auth
  wording. firestore may list several databases, each with its own rules
  (a project-wide hot reload replaces every database's rules, as
  officially); every database is exported and imported. The storage section
  may be the {rules} object, the target array, or absent (demo projects
  get the official open default rules); .firebaserc may be absent;
  emulators.database/hosting/dataconnect/apphosting entries are skipped
  with a warning instead of refused. The rules parser now accepts
  allow read, write; without a condition and rules_version='2' without
  a semicolon, both written by the official templates. The Functions worker
  declares its routes in Express 4 and 5 syntax (firebase-functions 7.3 and
  later ship Express 5) and sees a gcloud directory under the suite state
  holding a synthetic credential, so the Admin SDK's task-queue client never
  probes the Compute Engine metadata server.
• The CLI carries every command row except the terminal launch experience
  (Phase M): emulators:export on a running suite through the official hub
  locator, init (non-interactive, official rules and index templates, a
  JavaScript codebase) and init --adopt (diagnoses an existing
  firebase.json and adds what Fireside needs), use, target:apply /
  target:clear (pure .firebaserc edits, no login), firestore:delete
  (a new path-scoped emulator route; recursive and whole-database deletes
  need --force), functions:invoke --event-data (the official shell's
  envelopes for Firestore, Storage, Pub/Sub, Auth, schedules, Eventarc custom
  events and task queues, posted to the running suite), mcp (a
  dependency-free stdio Model Context Protocol server with status,
  Firestore, Auth, Storage, Functions, Pub/Sub, Tasks and export tools),
  --debug (one fireside-debug.log per run under .fireside/runs, never
  deleted), the official -P/-c/--json/--non-interactive/
  --log-verbosity/--ui/--force flags, and emulators:exec "<script>"
  run through the shell as the official CLI does (the -- argv form stays
  free of shell interpretation). emulators:exec keeps the Emulator UI off
  unless --ui is given, as officially. functions:shell is deliberately
  not provided: Fireside never starts a second Functions runtime. The
  default auxiliary ports are now the official ones (logging 4500, Eventarc
  9299, Tasks 9499) when firebase.json names none.
• Left for 0.1.0-next.10: the own Emulator UI and the terminal launch
  experience (banner and status table).

0.1.0-next.8 — complete Authentication and a full Pub/Sub emulator

• Pin the engine to 03000f0cc082c1b69f06c67b6a99a5417c840243, the qualified
  head of PR #50 (Phases I
  and J) on the next.7 engine. This exact revision passed CI
  (run 35364256374)
  and the five-platform packed-install matrix
  (run 35364256373),
  and a local candidate built from it passed a representative private
  ...

Fireside 0.1.0-next.9

0.1.0-next.9 — Cloud Tasks emulator, every configuration shape, the CLI surface

• Pin the engine to 7fb0c350078c94fc65a83a6f3c012a917779fbbd, the qualified head of
  PR #55 (Phases K, L and
  M) on the next.8 engine. This exact revision passed CI
  (run 35437156565)
  and the five-platform packed-install matrix
  (run 35437156569),
  and a local candidate built from it passed a representative private
  consumer's extensions, integration and installed-launcher gates and its
  nine browser journeys on the full-data stack, plus an end-to-end run of
  every new command on a project scaffolded by fireside init; see
  support/phase-k-tasks.md, support/phase-l-configuration.md,
  support/phase-m-cli.md and the receipts blocks of the three gate
  files under benchmarks/. The per-release-line two-hour soak stands from
  next.6 and next.7.
• Cloud Tasks is a full emulator (Phase K). The Tasks port serves the four
  routes of the official emulator — queue registration, enqueue, delete and
  /queueStats — with its Express-shaped answers, registers a queue for
  every onTaskDispatched export at readiness and after each reload with the
  function's URL as the default target, and dispatches exactly as
  taskQueue.js does: a token bucket per queue that starts empty and refills
  once a second, dispatch slots sized by maxConcurrentDispatches, the
  X-CloudTasks-QueueName/TaskName/TaskRetryCount/TaskExecutionCount/
  TaskETA headers with the caller's headers overriding them and
  TaskPreviousResponse from the second attempt, the retry ladder with its
  backoff formula and the maxAttempts off-by-one, the execution count
  incremented on non-5xx failures only, the dispatchDeadline abort, and
  the controller's cadence (idle queues polled once a second, active queues
  continuously). getFunctions().taskQueue().enqueue() and .delete() from
  a function or an app with CLOUD_TASKS_EMULATOR_HOST set reach the
  handler as on the official suite. The corpus recorded from firebase-tools
  15.22.0 (6 programs, 61 steps, 39 handler observations in
  conformance/fixtures/tasks-v1) replays with 0 mismatches and no named
  divergence, three runs identical; the Functions runtime corpus replays
  unchanged with the emulator mounted. Not done because the official
  emulator does not do it either: scheduleTime as a delay, OIDC tokens on
  dispatch, queue pause/resume/purge, task listing, the Cloud Tasks v2 API,
  persistence, a UI tab.
• Every configuration shape of the tracker starts (Phase L). A service
  starts when firebase.json configures it, exactly as the official
  filterEmulatorTargets decides, and --only narrows the set; a project
  without Functions or Storage runs (Eventarc and Tasks follow Functions,
  the requests WebSocket follows Firestore, the UI and logging listeners
  follow emulators.ui.enabled, the hub always runs). Any project id is
  accepted: a demo-* id prints the official demo line, a real id prints
  the official "will affect production" warning for services not running,
  and the suite never contacts Firebase either way (every worker gets the
  emulator hosts and no Google credentials; user code with explicit
  credentials can still reach the real project). Any listen host is bound;
  a wildcard is announced to clients as the loopback address as the official
  connectableHostname does, and a non-loopback bind prints one warning
  because the emulators have no authentication. emulators.singleProjectMode
  (default true) warns once per foreign project id with the official Auth
  wording. firestore may list several databases, each with its own rules
  (a project-wide hot reload replaces every database's rules, as
  officially); every database is exported and imported. The storage section
  may be the {rules} object, the target array, or absent (demo projects
  get the official open default rules); .firebaserc may be absent;
  emulators.database/hosting/dataconnect/apphosting entries are skipped
  with a warning instead of refused. The rules parser now accepts
  allow read, write; without a condition and rules_version='2' without
  a semicolon, both written by the official templates. The Functions worker
  declares its routes in Express 4 and 5 syntax (firebase-functions 7.3 and
  later ship Express 5) and sees a gcloud directory under the suite state
  holding a synthetic credential, so the Admin SDK's task-queue client never
  probes the Compute Engine metadata server.
• The CLI carries every command row except the terminal launch experience
  (Phase M): emulators:export on a running suite through the official hub
  locator, init (non-interactive, official rules and index templates, a
  JavaScript codebase) and init --adopt (diagnoses an existing
  firebase.json and adds what Fireside needs), use, target:apply /
  target:clear (pure .firebaserc edits, no login), firestore:delete
  (a new path-scoped emulator route; recursive and whole-database deletes
  need --force), functions:invoke --event-data (the official shell's
  envelopes for Firestore, Storage, Pub/Sub, Auth, schedules, Eventarc custom
  events and task queues, posted to the running suite), mcp (a
  dependency-free stdio Model Context Protocol server with status,
  Firestore, Auth, Storage, Functions, Pub/Sub, Tasks and export tools),
  --debug (one fireside-debug.log per run under .fireside/runs, never
  deleted), the official -P/-c/--json/--non-interactive/
  --log-verbosity/--ui/--force flags, and emulators:exec "<script>"
  run through the shell as the official CLI does (the -- argv form stays
  free of shell interpretation). emulators:exec keeps the Emulator UI off
  unless --ui is given, as officially. functions:shell is deliberately
  not provided: Fireside never starts a second Functions runtime. The
  default auxiliary ports are now the official ones (logging 4500, Eventarc
  9299, Tasks 9499) when firebase.json names none.
• Left for 0.1.0-next.10: the own Emulator UI and the terminal launch
  experience (banner and status table).

0.1.0-next.8 — complete Authentication and a full Pub/Sub emulator

• Pin the engine to 03000f0cc082c1b69f06c67b6a99a5417c840243, the qualified
  head of PR #50 (Phases I
  and J) on the next.7 engine. This exact revision passed CI
  (run 35364256374)
  and the five-platform packed-install matrix
  (run 35364256373),
  and a local candidate built from it passed a representative private
  consumer's extensions, integration and installed-launcher gates and its
  nine browser journeys (one-time-code login and sign-out/sign-in included)
  on the full-data stack, reopening the working state written by next.7; see
  support/phase-i-auth.md, support/phase-j-pubsub.md and the receipts
  blocks of benchmarks/phase-i-auth.json and benchmarks/phase-j-pubsub.json.
  The paired two-hour soak is a per-release-line gate and was waived for this
  release: the change set is confined to Auth and Pub/Sub, and both are proven
  by oracle replay against the official emulators.
• Authentication is complete (Phase I). crates/auth-front is rebuilt around
  the Identity Toolkit OpenAPI document that the official emulator itself
  routes and validates with (bundled under crates/auth-front/spec with its
  provenance), so routing, security, validation, coercion and error prose
  match operation by operation. Every one of the 61 operations the official
  Auth emulator implements is ported: password, anonymous, custom-token,
  email-link, phone and fake-IdP sign-in (Google, Apple, SAML and OIDC-shaped
  credentials), account update and delete, OOB and phone codes, session
  cookies, tenants, SMS multi-factor, passkeys, Admin batch create/get/delete/
  query, project and tenant configuration, the emulator inspection routes, the
  legacy relyingparty routes, blocking functions on every sign-in path,
  user.create/user.delete multicasts, official-format export/import and
  the popup/redirect helper pages. The corpus recorded from firebase-tools
  15.22.0 (61 programs, 1,068 steps in conformance/fixtures/auth-v1)
  replays with 17,303 compared values, 0 mismatches and four named
  divergences (V8-versus-serde parse prose in two error messages, the Node
  stack trace the official emulator appends to a 500 log line, and
  Fireside's own account-picker page whose offered accounts are compared
  exactly), three runs identical; the real-SDK popup/redirect browser gate
  and the Emulator UI Auth tab were checked against the candidate. Accounts
  exported by next.7 import unchanged, and passwords stored with the earlier
  digest still sign in and are upgraded on that sign-in. fireside native auth runs the service alone (--state-file persists it) and 500-class
  failures are logged with the official emulator's first line.
• Pub/Sub is a full emulator (Phase J). crates/pubsub-front is a broker
  behind tonic gRPC services and an HTTP/JSON transcoder on one port: every
  RPC of google.pubsub.v1 Publisher, Subscriber and SchemaService and of
  google.iam.v1 IAMPolicy, with leases and ack deadlines, redelivery behind
  later messages, dead-letter and retry policies, ordering keys, filters,
  message retention, seek to time or snapshot, snapshots, pull, streaming
  pull, push delivery with the official one-second retry, and Avro schemas
  with revisions, topic binding and message validation. The corpus recorded
  from the official Pub/Sub emulator 0.8.33 (42 programs, 916 steps over gRPC,
  HTTP/JSON, streaming pull and a recording pus...