@tablation/crew 0.0.0-stage → 0.1.1

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Brad Choate
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,3 +1,302 @@
-# Temporary Holding Version
+# crew
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+A standing team of headless agents that picks work off a
+[Tablation](https://tablation.com) board, does it on a machine you control,
+and reports back on the board.
+
+**Documentation: <https://crew.tablation.dev>** — start with
+[Getting started](https://crew.tablation.dev/getting-started). The source is in
+`docs/`.
+
+Each **seat** is a row in the board's Crew table that happens to be a robot,
+with a brief (`prompts/<promptSet>/`, see "Prompt sets" below) and a slice
+of the queue. A seat is named in that table and answers to that name, in the
+queue digest and in the comments it writes on tickets. Everything the crew
+knows about a run — what to build, what is blocked, what has shipped — is
+table data, and every step it takes is visible as a status change or a
+comment on the ticket. There is no hidden state and no queue but the board.
+
+Every agent is handed a roster at the top of its prompt: who else is aboard,
+what each of them is called, and which rows are **holds** — the people using
+this ship, and the interactive sessions they work through. A ticket assigned
+to a hold is off limits to every seat, whatever its status, which is how a
+person takes something over without racing the crew for it.
+
+Today's crew has four polled seats, described below under the `default`
+prompt set (the three-lane dev/design/QA policy this repo ships with — see
+"Prompt sets" below for others, and for writing your own):
+
+| Seat | Owns | Brief |
+| --- | --- | --- |
+| **dev** | approved tickets that don't need design work | `prompts/default/personas/lane-dev.md` |
+| **design** | approved tickets flagged *Needs design* | `prompts/default/personas/lane-design.md` |
+| **qa** | everything at `fixed` or `qa`, whoever built it | `prompts/default/personas/lane-qa.md` |
+| **triage** | tickets assigned to the triage seat | `prompts/default/personas/lane-triage.md` |
+
+A fifth persona, **pair**, rides `crew agents sync` alongside these four but
+is not polled: it is the identity a live, interactive session (an IDE
+conversation, not a scheduled run) uses when it touches the tracker. It has
+no Crew-table seat, is never assigned a ticket by the poll loop, and its
+brief (`prompts/default/personas/lane-pair.md`) is not prefixed with
+`common.md` — none of the polling loop's shared policy describes it. `crew
+agents prompt pair` prints its current persona text (a workspace admin's
+live edit if there is one, else the local default) for something like a
+`SessionStart` hook to feed into a session at start.
+
+Alongside personas, a prompt set can also ship **skills** —
+`prompts/<promptSet>/skills/*.md`, each one YAML frontmatter (`name`,
+`description`) plus a markdown prompt body. A skill isn't a seat: it's not
+polled and not concatenated into every run's prompt, just synced into the
+workspace's `Agent Skills` table so any session can fetch it by name on
+demand. `crew agents sync [route]` pushes both personas and skills in one
+run — "agents" here means every agent-shaped resource crew owns, not just
+the Agents table; `crew skills sync [route]` is the same create/update/
+diverged sync narrowed to skills alone, for when you've only touched
+`skills/`. Example use — a Pair session invoked via an Epic's
+`grill_link` looks up the `Grill-Me` skill through the Tablation MCP tool
+`agent_skills_controller_get_skill` and follows it. `prompts/default/skills/
+grill-me.md` is the shipped example.
+
+One role runs per cycle, whichever holds the most urgent actionable ticket
+(`src/priority.ts` decides, and the same module sorts the digest that agent is
+handed, so the two can never disagree). QA outranks the building roles whenever
+it has anything to check. If the winning role turns out to have nothing it can
+actually do, the cycle falls through to the runner-up rather than idling.
+
+Merging and deploying are **not** an agent's job. After the agent phase, a
+release phase takes whatever the remote has, squash-merges every QA-verified
+branch, bumps the version, writes the changelog and runs the repo's deploy
+hook. A headless session is never handed permission to push to production.
+
+A branch that will not merge is **handed back**, not skipped. The release
+rewinds it, merges the base into the branch in its own worktree, and returns
+the ticket to the dev lane with the conflict left in place to look at — so the
+seat that resolves it is one with the ticket's context, and QA checks the
+resolution like any other change. A branch that was merely stale merges
+cleanly at that point and nobody is woken at all. Conflicting a second time
+stops at `needs_info` rather than looping.
+
+## Prompt sets
+
+The seats above and their briefs are policy, not mechanism — a fact about
+*how* one particular workspace likes to work, not about what crew itself
+can do. `prompts/` ships more than one of these as complete, ready-to-run
+policies:
+
+| Directory | Policy |
+| --- | --- |
+| `prompts/default/` | Three lanes — dev, design (gated by a *Needs design* flag), QA. |
+| `prompts/dev-qa/` | Two lanes — dev builds everything, QA checks it. No design gate. |
+
+A route picks one with `promptSet:` in `crew.yaml` (see
+`crew.example.yaml`) — a bare name resolves under this repo's own
+`prompts/`, defaulting to `default` when omitted. Different routes on the
+same ship can run different prompt sets, since which workflow a workspace
+wants is a fact about that workspace, not about the machine running it.
+
+**Writing your own** is the expected path once a shipped preset doesn't
+fit: copy a preset directory (`cp -r prompts/default ~/my-crew-policy`),
+edit its prose, and point `promptSet` at the copy (`~/my-crew-policy` or a
+relative path) — no fork of this repo required. A prompt set is a complete,
+self-contained fork of `personas/common.md` + one `personas/lane-<role>.md`
+per seat, plus whatever `skills/*.md` it wants, not a diff against another
+one; each persona file is read as plain prose concatenated ahead of the
+per-run roster/environment/queue sections
+(`src/agent.ts`'s `assemblePrompt`), so there's no templating layer to
+learn. `prompts/dev-qa/` is a worked example of trimming a lane out of
+`default` cleanly, including the unused `lane-design.md` stub every
+preset still needs today — see the next paragraph for why.
+
+One current limit: **the role set itself is fixed** — `src/config.ts`'s
+`RoleName` (`dev`, `design`, `qa`, `triage`, `pair`) — so even a prompt set
+with no real use for a polled seat (`dev-qa`'s `design`) still needs a
+`lane-<role>.md` file for every one of them, `pair` included, or `crew
+agents sync` and `planAgentRun` throw looking for it. `prompts/dev-qa/
+lane-design.md` handles this by being a brief that just says "do nothing,
+you shouldn't be staffed" — copy that pattern for any polled seat your own
+policy doesn't use (`pair` is never polled, so its own brief just needs to
+exist, not disclaim itself). Making the seat set itself policy-defined, so
+a prompt set could add or drop a role outright, is a larger change than
+prompt sets took and hasn't been done.
+
+## What a workspace has to provide
+
+The crew reads its meaning from the board, not from its own source. Statuses,
+the priority order, and which column plays which role are **per-workspace
+facts**, because a ship can be connected to several boards that each made
+different choices. `docs/CONTRACT.md` documents the defaults and what a
+workspace has to override if it names things differently.
+
+## Install
+
+```sh
+git clone <this repo> crew
+cd crew
+cp crew.example.yaml ~/.config/crew/crew.yaml
+chmod 600 ~/.config/crew/crew.yaml     # it holds an API key
+$EDITOR ~/.config/crew/crew.yaml
+bin/crew doctor                        # read-only preflight
+```
+
+The config lives in `~/.config/crew/` rather than in the checkout: it describes
+the **machine**, so reinstalling or replacing the checkout does not lose it.
+`crew` looks in `$CREW_CONFIG`, then `$XDG_CONFIG_HOME/crew`, then
+`~/.config/crew/crew.yaml`, and only then beside the checkout.
+
+`crew connect` resolves a workspace/project's ids into the state tree so you do
+not have to look them up by hand. `doctor` then checks the config against
+reality: the checkouts, the tools on PATH, the agent binary, the repo's hooks,
+and whether the board answers. Nothing writes, wakes an agent or deploys until
+a route has `enabled: true`.
+
+Then install it as a real service:
+
+```sh
+bin/crew install           # writes and loads this platform's own units
+bin/crew install --dry-run # see what it would do first
+bin/crew uninstall         # unload and remove them
+```
+
+`install` writes three independent units — `run`, `release` and
+`passengers` — and picks the mechanism itself per host: launchd on macOS, a
+systemd **user** unit on Linux (falling back to a crontab line where
+`systemctl` is not usable), or an error on Windows (not built yet). It always
+uses an absolute interpreter path (`process.execPath`) and points each unit's
+own log at a *different* file than the crew's own — pointing both at one file
+was hit for real, and doubles every line.
+
+`run` is a **persistent service**: `crew daemon`, the long-running loop that
+chains cycles immediately when there's work and backs off when there isn't
+(launchd `KeepAlive`/systemd `Restart=on-failure` restart it if it crashes).
+Installing it starts it, the same as installing any other service would.
+`bin/crew daemon start|stop|status|restart` control that same service
+directly — useful without a full reinstall — except on the plain-crontab
+fallback, which cannot supervise a persistent process and so keeps the old
+one-shot-per-fire `crew run` instead. `release` and `passengers` stay on
+their own fixed timers/crontab lines, one-shot per fire same as always: the
+first run of each happens one interval after `install`, and each fire is a
+few API calls — a full agent session only starts when that cheap check finds
+something worth waking for.
+
+The daemon also updates itself: on an idle pass (never mid-cycle) it checks
+whether its own installed files (`src`/`dist`/`bin`, or the binary itself for
+a compiled install) have changed since it started, and if so exits cleanly —
+the same crash-recovery restart above then relaunches it against whatever is
+now on disk. `crew daemon restart` forces this immediately, for a manual
+`git pull && crew daemon restart` instead of waiting for the next idle tick.
+
+`launchd/com.tablation.crew.plist` is kept only as a reference for what
+`install` generates — hand-editing and loading it directly still works, but
+`crew install`/`crew uninstall` is the supported path now.
+
+## Commands
+
+```
+crew poll [route]              decide a cycle and report it; writes nothing
+crew run [route] [--role R]    run the winning role's session, then release
+crew daemon [route]                run the persistent supervisor loop in the foreground
+crew daemon start|stop|status      control the installed `run` service directly
+crew daemon restart                stop then start it (force-picks-up an update)
+crew release [route]           merge what QA verified, version it, ship it
+crew merge [route]             merge verified branches and stop
+crew deploy [route]            release now, even with nothing new to merge
+crew watch [route]             live view of what the crew is doing
+crew status [route]            paused/running state
+crew doctor [route] [--fix]    preflight; --fix enables clean routes, offers crew install
+crew ports [route]             which checkout owns which ports, and what is up
+crew reap [route]              kill servers left behind by removed worktrees
+crew drop [route] NNN          remove a merged ticket's worktree and branch
+crew sync [route]              fast-forward the checkout and its worktrees from the remote
+crew pause|resume [route] [R]  pause everything, or one role
+crew log [route]               tail the log
+crew inbox [--member NAME]    your tickets across every workspace
+crew connect WS[/PROJECT]     resolve a workspace/project's ids into the state tree
+crew repos add ROUTE PATH     attach a local checkout to a route in crew.yaml (--dry-run previews)
+crew repos list ROUTE         the checkouts a route has, and the tracker Repos row each matches
+crew install                  write and load this platform's scheduler unit
+crew uninstall                unload and remove it
+```
+
+Every command that could change something takes `--dry-run`.
+
+## One ship, many boards
+
+A ship connects to several workspaces at once, and ranks their queues against
+each other — a P0 on one board outranks a P2 on another. The ship is identified
+by `ship.name` matching a row in each board's Ships table; a crew member is
+identified by email, so the same person is recognised across workspaces.
+
+An area of development spans **several repositories**, so a checkout is a
+property of the ticket, not of the route: `repos:` maps each name in the
+board's Repos table to a directory on this machine. Naming even one repo
+there makes it a closed list — several ships can divide a multi-repo area's
+work between them, and anything not named is deliberately another ship's,
+marked `NO CHECKOUT` in the digest rather than left blank (blank would read
+as "work it here", which is the wrong directory).
+
+Leaving `repos:` out entirely means the opposite: this ship serves
+*everything* the board's Repos table lists, each checkout defaulting to
+`<reposBasePath>/<workspace>/<repoName>` — `reposBasePath` is `~/Crew`
+unless a `ship:` or route-level `reposBasePath:` says otherwise. A repo
+that doesn't exist yet at its derived path is cloned there automatically
+the first time a ticket actually needs it (from the Repos table's own
+`remote` column, `owner/repo` over SSH) — not up front on `crew connect`,
+which only discovers names and remotes, never fetches anything itself.
+
+## What lives where
+
+```
+bin/crew          the entry point
+src/              the implementation (Node, run directly via type stripping)
+test/             its tests, including a fake board for integration runs
+prompts/          prompt sets — prompts/<name>/personas/{common.md,lane-<role>.md}
+                  + prompts/<name>/skills/*.md
+docs/             CONTRACT.md, REPO_SPEC.md, MIGRATION.md
+launchd/          timer templates (edit the paths before installing)
+crew.example.yaml copy to ~/.config/crew/crew.yaml
+```
+
+The crew carries no ids, no absolute paths, no project commands and no device
+names. Anything specific to a **machine** belongs in `crew.yaml`; anything
+specific to a **repository** belongs in that repository's own `.crew.yaml`
+(`docs/REPO_SPEC.md`), which declares its platform, hooks, branch naming,
+versioning and release mode:
+
+| hook | required | what it is for |
+| --- | --- | --- |
+| `test` | yes | run the suite before a release |
+| `build` | yes | build it |
+| `deploy` | when `release.mode: local` | ship it |
+| `setup` | no | prepare a fresh worktree |
+| `ports` | no | print this checkout's port assignments |
+| `version` | no | print the current version |
+| `bump` | no | produce and print the next one |
+| `merged` | no | ask the forge whether a branch actually landed |
+| `released` | no | confirm a commit is live (a sha, or an exact version) |
+
+The crew carries no commands of its own: everything it runs to test, build,
+version or ship a repository comes from that repository's own file.
+
+One hook is the exception and lives in `crew.yaml` instead: `notify`, which is
+handed a level (`ok` / `warn` / `fail`), a headline and a detail line whenever a
+release ships or is blocked. Where that should be *shown* — a desktop
+notification, a status widget, a webhook, a push — is a fact about the machine
+and the person watching it, not about the code. Define none and release state
+simply goes to the log.
+
+A repo's own `.crew.yaml` wins over anything repeated in `crew.yaml`, and
+`crew doctor` reports the duplication as drift. The client can still configure
+a repo that has no `.crew.yaml` of its own.
+
+## Status
+
+Live on macOS, driving this project's own board. Triage is a **seat**, not a
+second process — there is one timer to install, not two.
+
+The bash implementation this replaces has been deleted. Where its behaviour was
+the only specification of something — the priority matrix, the QA digest, the
+crew labels — it was captured as a fixture under `test/fixtures/` first, so the
+tests still hold the port to what the original did.
+
+Outstanding: Linux has not been exercised end to end, and the API key sits in
+`crew.yaml` in plaintext until the device-code flow and keychain storage land.

package/bin/crew

@@ -0,0 +1,29 @@
+#!/usr/bin/env node
+// crew — the runner. See src/cli.ts.
+//
+// Runs the built output when it exists, and falls back to running TypeScript
+// directly so a checkout works without a build step. The bash runner this
+// replaces is kept as bin/crew-legacy.sh until cutover is done.
+import { existsSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+import { fileURLToPath, pathToFileURL } from 'node:url';
+
+const here = dirname(fileURLToPath(import.meta.url));
+const built = join(here, '..', 'dist', 'cli.js');
+const source = join(here, '..', 'src', 'cli.ts');
+
+// CREW_FROM_SOURCE=1 skips the bundle even when one exists. crew's own test
+// suite sets it on every CLI it spawns (test/helpers/crew-bin.ts): dist/ is
+// rebuilt by the release's build hook, which runs AFTER the test gate, so
+// without this the gate exercises the previous release's bundle (CREW-988).
+const fromSource = process.env.CREW_FROM_SOURCE === '1' && existsSync(source);
+
+if (existsSync(built) && !fromSource) {
+  await import(pathToFileURL(built).href);
+} else if (existsSync(source)) {
+  // Node >=22.18 strips types natively; older needs --experimental-strip-types.
+  await import(pathToFileURL(source).href);
+} else {
+  console.error('crew: no dist/cli.js and no src/cli.ts — is this a complete checkout?');
+  process.exit(1);
+}

package/crew.example.yaml

@@ -0,0 +1,132 @@
+# crew.yaml — what this ship is, and what it is connected to.
+#
+# Copy to ~/.config/crew/crew.yaml (NOT into the checkout): it describes this
+# MACHINE, so replacing or reinstalling the crew checkout must not lose it.
+# `crew` looks in $CREW_CONFIG, then $XDG_CONFIG_HOME/crew, then
+# ~/.config/crew/crew.yaml, and only then beside the checkout.
+#
+# It holds an API key in plaintext, so: chmod 600.
+#
+# Unknown keys are an ERROR, not a warning. A typo that silently did nothing
+# would be indistinguishable from a setting that does not work.
+
+ship:
+  # Must match a row in the board's Ships table — that row is how the crew
+  # knows which seats are aboard here rather than on someone else's machine.
+  name: "My Mac"
+
+  # Detected from the host. Set it only to override.
+  # platform: macos | linux
+
+  agent:
+    bin: "/usr/local/bin/claude"     # absolute: a timer runs with a minimal PATH
+    model: "claude-sonnet-5"
+    # Extended thinking budget, passed as MAX_THINKING_TOKENS. Defaults to
+    # 4096 when omitted — without it the CLI never emits `thinking` stream
+    # blocks, so Agent Log Cycles reporting has nothing to report. Set to 0
+    # to disable (less latency/cost, no cycles reported).
+    # maxThinkingTokens: 4096
+
+  # shell: bash                      # defaults per platform
+  extraPath: "/opt/homebrew/bin"     # prepended for hooks
+  useNvm: true                       # source the repo's .nvmrc before hooks
+  # stateDir: "state"                 # defaults to "state", relative to THIS file
+  logFile: "/tmp/crew.log"           # give each runner its own file — a shared one interleaves
+  # Defaults to "Mozilla/5.0 CrewAgent/<this checkout's version>". The
+  # Mozilla/5.0 prefix is load-bearing: Cloudflare blocks a bare tool
+  # User-Agent before it reaches the tracker API. Set this only to identify
+  # a specific ship in the tracker's own request logs.
+  # userAgent: "Mozilla/5.0 CrewAgent/1.0"
+
+  # Where a repo's checkout lives when a route's own `repos:` doesn't say so
+  # explicitly (see `repos:` below) — defaults to "~/Crew" if omitted here
+  # and at every route. A route-level `reposBasePath:` overrides this one.
+  # reposBasePath: "~/Crew"
+
+# One ship, many boards. Each route is one workspace/project pair + one area
+# of development within it — `crew run my-workspace/my-product`, the same
+# string `crew connect` takes, addresses it; there is no separate `name:` to
+# keep in sync with that. Keys are workspace-scoped in general, so a route
+# normally carries its own — but if one key happens to be valid for all of
+# them (a personal account key), declare it once as `ship.apiKey` instead and
+# every route that omits its own picks it up.
+routes:
+  - route: my-workspace/my-product
+    enabled: false                   # nothing writes, wakes an agent or deploys until this is true
+    area: "My Product"               # the row of its Projects table this route works
+
+    # An area spans several repositories, and each needs its own checkout on
+    # this machine. Keyed by the name the board's Repos table uses. Naming
+    # even one repo here makes this a CLOSED list — a ticket for a repo not
+    # listed is one this ship deliberately doesn't work (another ship may),
+    # and the queue digest marks it NO CHECKOUT rather than leaving it blank.
+    repos:
+      My Product: "/home/me/src/my-product"
+      My Product CLI: "/home/me/src/my-product-cli"
+
+    # Leave `repos:` out entirely instead to serve every repo the board's
+    # Repos table lists, each one defaulting to
+    # `<reposBasePath>/my-workspace/<repoName>` and cloned there
+    # automatically (from that repo's own `remote` column) the first time a
+    # ticket actually needs it — nothing to list by hand, nothing fetched
+    # up front by `crew connect`.
+
+    # A single-repo route may use `dir:` instead of `repos:`.
+    # dir: "/home/me/src/my-product"
+
+    worktreePrefix: "myproject-issue-"
+
+    # Opt this route's ship into Host Passengers for this route's workspace
+    # (ISSUE-644): `crew connect` syncs this onto that workspace's own Ships
+    # row. Config-truth lives here, on the machine — never edit a Ships row
+    # by hand expecting it to stick. Defaults to false (not hosting).
+    # hostPassengers: true
+
+    # Which lane-behavior policy this workspace's agents follow — the
+    # prose in prompts/<name>/personas/{common.md,lane-<role>.md}, plus
+    # whatever prompts/<name>/skills/*.md it ships. Bare name ("dev-qa")
+    # picks a preset shipped under crew's own prompts/; a path
+    # ("./my-policy" or "~/my-crew-policy") points at a fully custom set
+    # you copied and edited yourself, so adopting your own workflow never
+    # requires forking crew. Defaults to "default" (the three-lane
+    # dev/design/QA policy this repo ships with) when omitted. See
+    # prompts/default/ for the shape a custom set needs to have.
+    # promptSet: "dev-qa"
+    # What a host must be to build a repo lives in THAT repo's own .crew.yaml
+    # (any | unix | macos | linux | windows) — never here. A route can span
+    # repos with different needs; the ship refuses a route only when it can
+    # satisfy none of them.
+    # Defaults to https://app.tablation.com when omitted here and on `ship:`.
+    # Only needed for a self-hosted tracker.
+    # baseUrl: "https://app.tablation.com"
+    apiKey: "REPLACE_ME"             # or omit if `ship.apiKey` covers this workspace too
+
+    # Where release state should be SHOWN is a fact about this machine and the
+    # person watching it, not about the code — so unlike every other hook,
+    # notify lives here rather than in the repo's .crew.yaml. It receives
+    # CREW_LEVEL (ok|warn|fail), CREW_HEADLINE, CREW_DETAIL, CREW_ROUTE
+    # and CREW_SHIP, and decides everything else. Define none and release state
+    # simply goes to the log.
+    #
+    # hooks:
+    #   notify: 'terminal-notifier -title "$CREW_HEADLINE" -message "$CREW_DETAIL"'
+
+    # Prefer putting hooks, labels and release settings in the REPO's own
+    # .crew.yaml (docs/REPO_SPEC.md) rather than here. A repo that carries one
+    # shadows anything repeated here, and `crew doctor` reports that as drift.
+    # These exist for a repo you cannot add a .crew.yaml to:
+    #
+    # hooks:
+    #   test: "npm test"
+    #   build: "npm run build"
+    #   deploy: "./deploy.sh"
+
+    # Discovered from the board, not authored by hand, and NOT in this file:
+    # `crew connect my-workspace/my-product` (or a matching hand-filled JSON)
+    # writes state/resolved/my-workspace/my-product.json — workspaceId,
+    # projectId, areaModelId/areaId, the Issues/Comments/Crew model ids, each
+    # role's seat, the operator (the human this ship belongs to — set by
+    # hand; there is no way to derive it), and any hold (a row a person works
+    # through; a ticket assigned to one is off limits to every seat,
+    # whatever its status). Without it every cycle would re-resolve the same
+    # ids over the network instead of reading a local cache.