@indigoai-us/hq-cli 5.345.191 → 5.345.193

package/CHANGELOG.md

@@ -2,6 +2,404 @@
 
 ## [Unreleased]
 
+## [5.345.193] — 2026-11-03
+- HQ's setup assistant answers the desktop app's end-of-setup handoff as the
+  assistant it is: who it is and what it can help with (questions, finding
+  things, running work, and whatever is left of setup), then exactly which
+  setup steps are still open, or that none are, and one question. HQ puts
+  the company folders on this computer and the assistant's progress note
+  under the note, so that first reply needs no command: the tool checks and
+  installs that used to run inline in the first turn now wait until the
+  person answers. The note can no longer be answered with silence. On a
+  fresh install on 2026-11-02 the owner saw the
+  app's hello ("As soon as you finish setting up in the app, I'll pick up from
+  there"), then a spinner for over three minutes with nothing behind it: the
+  note ran as a late, silenceable setup note with no working line.
+- Before slow work (the tool checks, an install, the import), the setup
+  assistant says what it is doing and about how long ("Give me about two
+  minutes to check what's on this computer, then I'll ask my first
+  question."); that one line now reaches the person even though the
+  assistant's other notes before a command do not. When it says nothing, or
+  goes quiet for 30 seconds after that line, it posts "Still working on it.
+  I'll post here as soon as I'm done." once. Every bot's kickoff turn posts
+  the usual working line after a silent minute, like other turns do.
+- `hq bot create --auto-approve` turns an HQ Fleet Runtime bot's command approval prompts off for
+  every sender (`autoApprove: true`, from hq-fleet-local 0.4.19). By default the prompts stay on
+  and the owner's own turns are always allowed. This replaces the `--no-auto-approve` flag and the
+  approvals-off default described in the 0.4.18 note above.
+- `hq bot jobs` and the local bot job code no longer describe local jobs as
+  EventBridge or cloud schedules. Comments describe the bot's own `jobs.json`
+  and inbox loop, and say the stored six-field `cron(...)` string is the
+  format hosted agent jobs also use. The internal `toEventBridgeCron` name is
+  kept.
+  - The refusal for a bare six-field cron expression now says the last field
+    would be a year (the form bot jobs are stored in) or the first one
+    seconds (Quartz), instead of naming EventBridge.
+  - The personal-bot message "the cloud only accepts them from company bots"
+    is removed. `hq bot jobs` answers from the bot's own `jobs.json` for every
+    bot kind, so a personal bot schedules local jobs like any other bot.
+- Dependency updates: AWS SDK clients 3.1157 -> 3.1160, @sentry/node 10.77.1 -> 10.78.0, and
+  varlock 1.23.0 -> 1.24.0. @tobilu/qmd stays at 2.5.3 so better-sqlite3 stays on 12, which
+  has prebuilt binaries; 13 would need a C++ toolchain to install.
+- CI: pnpm/action-setup 4 -> 5 in hq-cli workflows. v6 stays ignored because it fails on the
+  self-hosted runners (libatomic.so.1, see #2323); v5 runs on them.
+- `hq files purge` now reports that the version will be permanently deleted on a date 7 days out and can be cancelled until then; `hq files purge --cancel <path> --version-id <id>` cancels it. Against a server without the 7-day window, it reports that the version was deleted immediately.
+- `hq-hook`: the native `block-hq-glob` port (flag still off) now reads a planted
+  `.git` folder's HEAD and config the way git does. A HEAD git rejects, such as one
+  with a form feed after `ref:`, no longer stops the search for the repository, and
+  a config line git cannot parse makes the port ask git. It now blocks the same
+  Glob calls as the bash hook in these cases.
+- As of #2347, `hq bot create` is Fleet-only: every new local bot runs on the
+  HQ Fleet Runtime, and `--legacy-runtime` is refused. Bots that already run on
+  the model-CLI runner keep running as before.
+- On start, an HQ Fleet bot moves the jobs in its old `jobs.json` into the
+  Fleet schedule. `jobs.json` is renamed to `jobs.migrated.json` only when
+  every job moved. If some jobs could not move (for example a schedule pinned
+  to one year), `jobs.json` is kept with those jobs still in it, the jobs that
+  did move are taken out of it, and `hq` prints a warning naming the jobs left
+  behind. They do not run until you add them again with `hq bot jobs --add`.
+- Bots no longer run the signals engine by default. Both the daily 06:30 Fleet
+  signals job (`hq signals run --trigger job`) and the engine path in the
+  built-in hot-signal-sync job (#2306) are behind the default-off flag
+  `cli.bot-signals-engine-job`. With the flag off, a Fleet bot registers no
+  signals job and removes an existing one on its next start, and the built-in
+  job runs the hot-channel sync alone, as it did before. Turn it on for a
+  company in the flag registry, or on one computer by starting the bot with
+  `HQ_FLAG_CLI_BOT_SIGNALS_ENGINE_JOB=true`.
+- With `cli.bot-signals-engine-job` off (the default), HQ Fleet bots keep their
+  daily 06:30 hot-signal-sync job, and it runs the plain hot-channel sync
+  (`hq sources sync`). Before this fix, turning the flag off dropped the whole
+  job. The plain sync's report goes to the bot's `logs/hot-signal-sync.log`,
+  and the owner gets a DM only when the sync does not finish (for example,
+  when nobody is signed in). Turning the flag on switches the same job's script
+  to the signals engine on the next bot start.
+- Bump `@indigoai-us/hq-cloud` to 6.18.108. It accepts a delegated machine
+  session file (`HQ_MACHINE_SESSION_FILE`), so company Outpost jobs can run hq
+  as the Outpost (hq-cloud #1078). It also adds `--size` to Outpost
+  provisioning (hq-cloud #960).
+- `hq bot create` now always creates an HQ Fleet Runtime bot, including HQ's
+  setup assistant and the setup bots `hq pkg install --start-bot` starts. The
+  `agents.local-bots-hq-fleet-default` company flag is no longer read.
+  `--hq-fleet-runtime` is still accepted and changes nothing; `--legacy-runtime`
+  is refused; `--effort` and `--lean` are gone from `create`. A bot with no
+  `--provider` answers with Claude. Company bots still belong to exactly one
+  company. Bots that already run on the model-CLI runner keep running as before.
+- `hq bot jobs` on an HQ Fleet bot lists, adds, reschedules and removes jobs in
+  the runtime's own schedule, so they fire, and posts each result to your HQ DM.
+  `--quiet` and a `--tz` other than this computer's are refused for these bots.
+  On start, jobs an HQ Fleet bot had in `jobs.json` move into the runtime once;
+  the old file is kept as `jobs.migrated.json`.
+- HQ Fleet bots get the daily hot-signal-sync job at 06:30 as a runtime job. It
+  runs `hq signals run --trigger job --report-found` and posts to your DM only
+  when it found new signals. A personal bot gets one such job for each company
+  it serves, skipping a company another local bot already covers. A removed job
+  stays removed. `hq bot jobs` prints next-run times in UTC.
+  `hq signals run --report-found` prints the run reply only when signals were
+  found.
+- HQ Fleet bots move to newer HQ Fleet Local releases on their own: hq reads the
+  release HQ publishes (`/v1/fleet-local/releases/latest`), never moves to an
+  older one, and still requires a signature from a trusted key. The hq daemon
+  checks every 30 minutes and shortly after it starts, waits until a bot has no
+  turn or scheduled job running, then updates and restarts it. The check shows
+  in `hq daemon status` as `fleet-bots-update`.
+- HQ Fleet setup bots: the pack setup section is now part of a pack bot's
+  instructions, and HQ's setup assistant again offers to continue setup in the
+  Claude or Codex app when you use it a lot.
+- `hq bot status <name> --json` reports `channels: { slack, telegram }` for HQ
+  Fleet bots. `hq bot start`, `stop` and `restart` refuse an HQ Fleet bot held
+  for cloud promotion, as they already did for other bots.
+- HQ Fleet Local releases signed with the new v3 release key (from 0.4.20 on)
+  are trusted, next to the v1 and v2 keys. New HQ Fleet bots start on 0.4.20,
+  which adds Slack and Telegram for local bots and lets them see pictures and
+  files attached to HQ DMs.
+- Installing an HQ Fleet Local release now checks every file in the download
+  against the signed manifest, and the runtime archive against the hash the
+  manifest names, so a release can only install what its signature covers.
+- The hq daemon updates only HQ Fleet bots that are running, leaves a bot you
+  stopped alone, and restarts an updated bot only once it is idle; if a turn
+  starts during the download, the restart waits for the next check.
+- Jobs saved by older hq versions in the cron(...) or rate(...) form move into
+  the HQ Fleet Runtime with the same schedule. A job the runtime cannot run is
+  left in jobs.migrated.json and named in the bot log.
+- `hq bot`: HQ Fleet Local runtime package installs and service installs no longer
+  open a console window on Windows. Node hides a child only when none of its
+  stdio handles are inherited, so those steps now pipe their output and copy
+  both stdout and stderr to stderr. The output now appears when each step
+  finishes, not live while it runs.
+- The daemon now moves a running HQ Fleet bot to a new runtime only when HQ's latest-release pointer names one. With no pointer, a failed lookup, or a pointer that needs a newer hq-cli, running bots stay on the release they have. New bots, `hq bot start`, `restart` and `adopt` still use the release built into hq-cli.
+- `hq-hook`: the native `block-hq-glob` port (flag still off) now checks the
+  tools it relies on. It runs script tools where bash would, so it gives bash's
+  answer for them, including when a bad script turns a block into an allow. It
+  models compiled tools without starting them. It leaves the call to bash when the
+  environment exports bash functions or sets posix-mode options, when PATH is unset
+  or empty or has an entry starting with `~`, or when a tool on PATH cannot be
+  opened or is a file only a shell can read. This replaces the earlier note that it
+  answers every call without bash.
+- `hq-hook`: add a native port of the `block-hq-glob` hook behind its flag
+  (`hook-engine-port-block-hq-glob`, off). It answers every call without bash
+  and matches the bash hook's exit code and output, apart from the Windows path
+  spelling cases named in the hook-03 report.
+- `hq-hook`: the `block-credential-file-read` port follows the round-2 bash
+  guard (sha256 8abd1702) and its pin moves to it. The changes:
+  - cygpath gets the alias, PATH and trusted-path rules;
+  - `eval`, `source` and `.` turn off trust in command names;
+  - alias bodies are analysed where they are defined and where they are used;
+  - zsh glob forms are unknown word parts: a group inside a word, `^`, `#`
+    inside a word, and `~` after a glob character or with extended glob on;
+  - archivers may not take a directory that holds credentials;
+  - `~/.hq/secrets-cache/` is a credential store.
+  The vendored fixture and corpus are refreshed. The port flag stays off.
+- `hq-hook`: the `block-credential-file-read` port follows the round-3 bash
+  guard and its pin moves to it. zsh glob forms on an absolute home path or
+  relative to a cwd in HOME, a group at the start of a word (also after a
+  redirect or empty quotes), and quoted parts next to a group are refused;
+  `^` and `#` count only after `.`, `~` or `_`, so git revisions such as
+  `origin/main^` pass. The vendored fixture and corpus are refreshed. The
+  port flag stays off.
+- `hq-hook`: the `block-credential-file-read` port follows the round-4 bash
+  guard and its pin moves to it. `function f ( body )` bodies are checked
+  again, keywords before a word-start `(` count only in command position,
+  any unquoted `^` or mid-word `#` in a read operand blocks except for git
+  and npm-family commands, and the zsh numeric range `<N-M>` is a glob part.
+  The vendored fixture and corpus are refreshed. The port flag stays off.
+  For git and npm-family commands a `^`/`#` operand is checked as the
+  wildcard pattern zsh can expand it to, and a keyword after other prefix
+  keywords (`if ! ( .. )`, `time -p ( .. )`) still opens a subshell.
+  An unassigned variable in such a pattern is a wildcard (fails closed),
+  and `time -p -- ( .. )` opens a subshell.
+  The same applies to any git/npm operand where an unassigned expansion
+  sits next to a glob character (`${p}*`).
+- `hq-hook`: the `block-credential-file-read` port follows the round-6 bash
+  guard (hq-core-staging #1767) and its pin moves to it. A `function NAME (`
+  body is checked wherever `function` is in command position (inside `{ }`,
+  after `then`), the zsh short for loop `for f (LIST) BODY` fails closed, a
+  word with an unquoted `^` or mid-word `#` blocks in any command except git,
+  npm-family tools and `[[ ]]` (so `echo id^x | xargs cat` and
+  `for f in i#d_rsa; ...` block), a glob in a for/select list is checked as
+  a read operand, and the `://` exemption needs a network URL with a host
+  and no `..` given to a URL tool (`cat a://../i#d_rsa` blocks). `^`/`#`
+  inside `$(( ))` with no nested substitution is arithmetic, and words after
+  `]]` (zsh `while [[ c ]] { body }`) are analysed as a command. The
+  vendored fixture and corpus are refreshed. The port flag stays off.
+- `hq sources sync`: the hot-channel push-buffer drain now checks each buffer
+  file with the vault write guard before reading it. Before this, a buffer file
+  that was a link into another company was read and landed in the current
+  company before the per-file check refused it. The drain now fails closed on
+  such a file, with nothing read, landed, moved, or deleted. Follow-up to #2338.
+- The hot-channel writers now check every company-data write, rename, link and delete against the company-scoped write guard right before it happens, not only in the adapters step's preflight. This covers landing (documents, raw sidecars, the sources index), the cursor store, the run ledger, the sync lock and its takeover files, the signals pass (signal documents, the signals index, `_audience.yaml`), the signals alert state, the meetings notes writer and push-buffer cleanup. The push-buffer folder is also checked before it is read. A link that would carry any of these into another company's folder makes the run fail closed, and nothing is written there.
+- New write-guard helper `assertVaultPath(vaultRoot, file)`. For a `companies/{co}` vault it applies `assertAllowedPath` scoped to that company. For any other vault it requires the file to stay inside the vault after links are followed, and refuses a linked vault root or a linked file.
+- A `companies/{co}` folder that is itself a link to a folder outside the HQ root now stops the hot-channel sync for that company, as it already stopped `hq signals run`.
+- `writeFileAtomic` in `src/lib/hot-channels/landing.ts` now takes the vault root as its first argument.
+- `validateNewCandidates` requires its company scope. The unscoped plain delete branch, which production never used, is removed.
+- Hot signal sync: the Slack and Linear adapters now key items as `slack:{channel}:{ts}` and
+  `linear:{issueId}:{updatedAt}`. Slack reads only the push buffer and never polls history, so one
+  thread lands as one item. Linear backs off on a 429 (honoring Retry-After), keeps its watermark when
+  the limit outlasts the retries, and stays under 2,500 requests an hour.
+- Slack and Linear are on for every company. The hq-flags kill switches `hq.hot-channel-slack` and
+  `hq.hot-channel-linear` turn them off for a company when set to false; an absent flag keeps them on.
+  When the flag service cannot be read or times out, each switch keeps the last value read on this
+  machine for that company (saved in `workspace/signals/flags/{company}.json`), and stays on when it
+  was never read here. A default-off gate still fails closed on a failed read. `hq sources sync`, the bot's hot-signal-sync job and `hq signals run` all apply the
+  same gate, including adapters turned off in `core/settings/signals-adapters.yaml`.
+- Hot-channel Attio and Gmail adapters meet the hot-signal-sync US-010 bar.
+  - Attio still drains the webhook buffer, then pulls records (companies,
+    people, deals) and notes created since its watermark through the HQ
+    gateway, 50 per page. Its cursor is now JSON `{drain, pull}`; an old
+    plain cursor is read as the drain cursor.
+  - Attio event keys are `attio:{recordId}:{eventId}`. A create keys on the
+    Attio record or note id and the event type on both paths, so a record or
+    note that arrives by webhook and by the pull lands once. Other webhook
+    deliveries key on their record and the receiver's delivery hash.
+  - Upgrading keeps what the older Attio drain already landed: a delivery or
+    a pulled create whose document the older drain landed keeps that older
+    key, so the first pull after the upgrade lands no duplicates. Creates the
+    older drain never landed still land.
+  - Attio and Gmail retry a 429 up to three times, honor Retry-After, cap
+    requests per run, and leave the watermark where it was when the limit
+    persists. Gmail always calls the mailbox as `userId: "me"`.
+  - Gmail follows the hq-flags row `hq.hot-channel-gmail` (registered off by
+    default under an owner hold). Set on for a company, Gmail runs through
+    `hq sources sync` and `hq signals run`; off it is skipped with reason
+    `flag-off` and no mailbox call. When the flag cannot be read, Gmail is off
+    (fail closed), whatever was read before.
+  - The signals run record now holds items in and the token level
+    (workspace or user) for each adapter.
+- Signals: `runSignals` accepts `registeredAdapterIds`, so any hot channel added as one adapter plus one catalog entry is gated, synced and counted in the run record without changes to the adapters step.
+- `hq mesh daemon install` on Windows no longer fails with "Access is denied" for a standard user when the
+  shared task name `ai.getindigo.hq-mesh-daemon` already belongs to another account's task. It now registers
+  a per-user task (`ai.getindigo.hq-mesh-daemon.<user>`), and status, restart, uninstall and
+  `hq daemon migrate` follow that name.
+- `hq signals run` adapters step reads `core/settings/signals-adapters.yaml` when present.
+  - An adapter with `enabled: false`, or whose company flag is off, is skipped and recorded with reason `flag-off`. A channel hq-pro reports as gated is recorded the same way.
+  - The enabled adapters run in one sync. An enabled adapter that the hq-pro catalog does not list has nothing to run and no longer fails the step.
+  - Without the file every registered adapter runs, as before.
+  - After each run the signed-in person's vault cursors are copied to `workspace/signals/watermarks/{company}/{cursorKey}.json`. Teammates' cursors are not copied.
+- Hot-channel adapters declare `displayName`, `provider` and `watermarkKind`, and a contract test checks every registered adapter against the hq-pro hot-channel schema.
+- Signals: a malformed or unreadable `core/settings/signals-adapters.yaml` no longer breaks
+  `hq sources sync` or the bot's hot-signal-sync job. hq prints one warning and runs the adapters
+  without yaml gating (Slack and Linear on), as when the file is missing. Follow-up to #2309.
+- The bot's built-in hot-signal-sync job now runs the signals engine
+  (`runSignals` with `trigger: "job"`): garden, adapters, extract, garden,
+  upload, with the caps from `core/settings/signals.yaml` and a run record.
+  The job kind, company resolution and stale-company removal are unchanged.
+  - The owner report uses the storyboarded reply format: prose plus one
+    `hq-block` fence, with run complete, catch-up, late-start, finished with
+    problems, skipped, running and run-failed variants
+    (`src/lib/signals/reply.ts`), read from the v2 run record. A partial run
+    gets the amber "Finished with problems" badge with its reason, never the
+    green Complete badge. Error replies carry the fence too.
+  - When a run fails with a transient error (the run record has
+    `nextRetryAt`), the bot runs the job once more at that time, in the same
+    process. Only then does the failure reply offer "Wait for <time>"; config
+    and sign-in failures, and a failed retry, offer only "Try now". A stop or
+    restart cancels a pending retry.
+  - The run started right after the job is registered uses the `manual`
+    trigger, so a bot first started in the early morning still runs that
+    morning's job.
+  - Reply times use the job's own time zone from `jobs.json`.
+  - `formatJobCreatedReply` writes the job's own time zone in words (for
+    example "Mountain Time"), never a fixed zone.
+  - `hq bot jobs --every` accepts "every morning at 6" (and afternoon,
+    evening, night), giving `0 6 * * *`.
+- `hq signals run` extract step now runs the ontology worker's process-source
+  skill on each unprocessed item of every local-run source channel.
+  - One model turn per item under the main local bot's coding-tool login
+    (claude or codex; grok is refused). Candidates are written only through
+    `ontology-candidate.sh`; an item is marked done only after its turn succeeds.
+  - Each turn is confined to its own item. It runs from a temp folder outside
+    HQ, can read only the item's channel folder, and writes candidates only
+    through a per-item command that fixes the company, audience and source ref
+    and refuses `--body-file`. Claude runs with `--permission-mode dontAsk`,
+    `--restricted`, `--tools Read,Bash`, no MCP servers and no settings files;
+    codex runs with a permission profile that reads only that folder, writes
+    only the company's `_candidates` folders and has no network.
+  - After a turn the step touches only the new candidates that carry the
+    item's source ref. One written into another company is deleted and the
+    item fails. Candidates from other writers that appear during the turn
+    (other companies' bots, other sources, garden moving files into `_done`)
+    are left alone. Worklist items whose path or audience could inject text
+    into the prompt or leave the channel folder are refused.
+  - `--max-turns` applies per item for claude (codex has no turn cap);
+    `--max-budget-usd` is a run budget summed from each turn's reported cost.
+    When it runs out the step stops with `budget-exceeded` and leaves the rest
+    for the next run.
+  - Failed items are listed under `failures` and retried next run; a logged-out
+    claude is recorded as `signed-out`. The item's own new candidates without
+    `audience_key`, with another audience or with an unknown type are deleted
+    and counted.
+- `hq signals run` garden step reports accurate counts and adds two guards.
+  - `itemsIn` is the number of pending entity and signal candidates before
+    the run. `itemsOut` is promoted entities, signals and facts.
+  - Candidates whose `source_ref` or `path` points at the Build Your Own AGI
+    manuscript (`companies/indigo/knowledge/book/`) are not promoted. They stay
+    in place and are counted as `skipped`. Candidates left in `_held/` by a
+    run that stopped part-way are put back at the start of the next run.
+  - An entity candidate whose name is 0.8 to 0.95 similar to an existing
+    entity of the same type, or to an earlier pending candidate of the same
+    type, is not merged. It moves to `ontology/_candidates/_review/<date>/`
+    (local date) and a line is appended to `ontology/review/merges.jsonl`,
+    with `against` set to `entity` or `candidate`. These are counted as
+    `review`.
+- `hq signals run`: every write in a run is now held to that run's company.
+  The run record, lock, step writes, member projection, flag state and alert
+  state are checked against the company being run, and the write guard now
+  refuses any write that a link moves out of the root it names. A linked
+  `workspace/signals` or `companies/{co}/...` folder that resolves into another
+  company's folder fails the run with a write-guard error instead of writing
+  one company's data into another company's folder.
+- Behavior change: company-scoped signals writes under `workspace/` or
+  `personal/` now refuse to pass through any symlink inside the HQ root (for
+  example `workspace/signals` linked to another folder in HQ). A link that
+  points outside the HQ root, such as to an external disk, was already
+  refused. The error names the linked path. Replace the link with a real
+  folder to run signals again.
+- `hq signals run` runs the local signals engine for each company with
+  signals or ontology capture on.
+  - Fixed step order: garden, adapters, extract, garden, upload. `--step`
+    runs one step. Extract and upload are placeholders for now.
+  - The adapters step runs the same hot-channel sync as `hq sources sync`
+    and the bot's hot-signal-sync job. Without an HQ login it is skipped.
+  - Writes a run record per company (`schemaVersion: 2`) under
+    `workspace/signals/runs/<date>/`, updated at each step boundary. It has
+    `status` (`running`, `complete`, `partial`, `failed` or `skipped`), `pid`,
+    `jobRanAt`, `errorKind` (`transient`, `config` or `auth`),
+    `failureReason`, `nextRetryAt`, `partialReason`, `skipReason` and
+    `counts` (`sourcesIn`, `signalsOut`). `summary.json` in the same folder
+    keeps every company's latest entry.
+  - A `--trigger job` run counts as the day's job only when it finishes
+    complete or partial. A second job that day does nothing unless `--force`
+    is passed; chat, brief and manual runs do not reset it, and a failed job
+    does not block the next job fire. A transient failure records a retry
+    time 15 minutes after it finished.
+  - Each company runs under a lock file next to its record. A second run for
+    the same company exits 3 and prints the running run's start time and
+    trigger. A lock whose process is gone, or that is older than 3 hours, is
+    taken over and the takeover is noted in the record.
+  - Exit codes: 0 complete, partial, skipped or already ran; 1 failed; 2 usage
+    or config error; 3 another run holds the lock.
+  - A job that starts after `lateStartHour` runs garden only and is recorded
+    as partial (`late-start`), or failed if garden fails.
+  - A missing or failing `knowledge-prefs.sh` fails the company with a config
+    error instead of skipping it as if capture were off.
+  - `--max-turns` and `--max-budget-usd` default to `core/settings/signals.yaml`,
+    else 40 turns and $2.00. Invalid values in that file (for example
+    `maxTurns: 0`) are ignored with a warning.
+  - The engine's own writes (records, summary, locks) are checked against an
+    allow-list of signal folders and
+    written atomically through a temp file opened with O_EXCL; symlinks at
+    the target, dangling ones included, are refused. Deviation from the PRD:
+    the allow-list also includes each company's `sources/` folder, where the
+    hot-channel adapters land documents and cursors.
+- `hq signals run` now checks each company's run record for a silent stall: the extract step read
+  source items and produced no signals, or extract failed after the adapters step landed new
+  sources. Hot-channel landings that no declared source channel covers do not count on their own.
+  When it sees a stall, it sends the same signals-failure alert `hq sources sync` sends, deduped to
+  one owner DM per company per hour in `sources/_runs/@{personKey}/_alerts.json`. In the terminal
+  the alert prints to stderr and does not use the hourly dedupe, so it never holds back the bot's
+  owner DM. Healthy runs, quiet days, dry runs, a repeated job run on the same day, and an extract
+  skipped for `no-sources` or `ontology-worker-missing` send nothing. Programmatic callers pass the
+  owner-DM sender as `signalsAlert` on `runSignals`.
+- `hq signals run` writes `catchUp` into each company's summary.json entry, taken from that company's run record.
+- New `isRunRecord` type guard in `src/lib/signals/run-record.ts` checks a signals run record (contract v2) before the brief gate or desktop reads it. Its status and error-kind lists are typed against the engine's types, so they cannot drift.
+- `hq signals run` upload step posts sanitized meeting observations to the
+  caller's own `member-signals/{memberUid}/` prefix.
+  - One `POST /v1/files/contributions/company/{slug}/meetings` per signal
+    promoted since the last upload, with body `{ destination, contribution }`
+    where `contribution` is a `sanitized-contribution.v1` object built by the
+    new TypeScript sanitizer (`local-sanitizer/v1`). Signals without a
+    meeting source, an audience receipt that includes the caller, or
+    citation timestamps are skipped locally.
+  - The watermark lives at `workspace/signals/upload/<company>/<memberUid>.json`.
+  - A 403 `CONTRIBUTION_DISABLED` marks the step skipped (`flag-off`); a 401
+    or no HQ login marks it skipped with the step `errorKind: signed-out`.
+  - A 404 `WRITE_COMPANY_NOT_FOUND` stops the step after one request with a
+    config error. A 422 `WRITE_BUCKET_NOT_PROVISIONED` or a
+    `source_unavailable` rejection is retried on a later run instead of
+    being recorded as rejected.
+  - The step pulls the member's own projection
+    (`ontology/projections/members/<memberUid>/v1/`) into
+    `workspace/signals/projections/` and records `missing`, `stale` or
+    `ready`. hq-pro has no route that triggers the projection export yet;
+    the signals engine is intended to be its only caller once one exists,
+    and the desktop no longer calls it.
+  - `--dry-run` lists what would upload and sends nothing.
+  - The run record carries `uploaded: { count, bytes }`.
+- Vault sync is unchanged. `hq sync`, `hq sync push` and the background sync
+  runner push and pull exactly what they did before, and hq-cli does not
+  write `.hqignore` or `.hqsyncignore`. Promoted signals
+  (`companies/<co>/signals/@<key>/...`) and company `sources/` stay local
+  today, because hq-cloud refuses client uploads of `signals/**` and
+  `sources/**`. Sharing promoted signals through audience ACLs is a later,
+  separate hq-cloud change.
+- `hq signals run` holds three more writers to the run's company. The garden step checks both candidate trees before it starts and moves or deletes a candidate only through the company-scoped write guard. The adapters step refuses to start the hot-channel sync when a link under `companies/{co}/sources/` or `companies/{co}/signals/` leads out of that company's folder. The extract step refuses a channel when a link under either `_candidates/` folder does the same, for every runtime. In all three cases the step fails and writes nothing.
+- The extract step now works out which company owns a new candidate from its real path, with links followed. A file written through a linked folder into another company's tree counts as that company's file, so it is deleted there and the item fails. Every candidate delete goes through the guard.
+- The extract step's candidate wrapper checks the candidate path again on every call, right before it writes. It refuses when a link sits on or under either `_candidates/` folder, so a link the model turn creates after the step's preflight check cannot send a candidate into another company.
+- New write-guard helpers: `guardedRemove`, `guardedRmdir`, `realRelPath` and `assertNoEscapingLinks`.
+- `hq staff reset-test-account <email> --handoff-shared-companies` wipes a test
+  account that owns a company with real members. The company is kept and passes
+  to its next real member, and the plan names who gets it. Without the option,
+  the reset still refuses as before.
+
 ## [5.345.191] — 2026-11-02
 - `hq bot list` and `hq bot status --json` rows now carry `engine: "hq-fleet-runtime"` for a bot on
   the HQ Fleet Runtime, so the desktop app can tell a Fleet bot from a model-CLI bot (Create brief

package/assets/bot-workers/setup/worker.yaml

@@ -107,17 +107,17 @@ instructions: |
   one), follow "When the app hands you settled steps" below instead of the
   explain-or-jump question.
 
-  When you receive the kickoff, do the state check and start the first
-  unfinished step immediately, ending with exactly one concrete question or
-  action for the user:
-
-  1. The state check, quietly: your progress note; the "Owner context" block
-     (who they are and which companies they belong to in HQ Cloud);
-     `companies/manifest.yaml` and `companies/` (is there a company folder on
-     this computer); and the tools this HQ leans on (see step 1).
-  2. Do the part of step 1 you can do yourself right now (install a missing
-     tool, fix a broken one). Do not start step 2 yet.
-  3. Reply with one line on what you found or fixed, then ask, in exactly
+  When you receive the kickoff, reply within seconds, ending with exactly
+  one question:
+
+  1. The quick state check: your progress note (if the app put it under
+     the kickoff, it is already in front of you; otherwise one read), the
+     "Owner context" block (who they are and which companies they belong to
+     in HQ Cloud), and whether `companies/` has a company folder. Nothing
+     else. Do not check, install or repair tools in this turn: that is
+     step 1, and it starts after they answer, with a heads-up line first
+     (see "Before slow work" below).
+  2. Reply with one line on where things stand, then ask, in exactly
      these words:
 
      > Do you want me to explain HQ to you, and then continue with the setup, or just jump straight in?
@@ -168,7 +168,7 @@ instructions: |
      the tools on this Mac, HQ Cloud, their company, the work they already have,
      their business and the tools it runs on, a little about them, and their first bot.
   3. The explain-or-jump question, in the exact words from "When you receive
-     the kickoff", after doing step 1's checks quietly.
+     the kickoff". No tool checks before it.
 
   Then stop and wait. Do not preview later steps, do not number the steps, and
   do not ask them to confirm that they want to start.
@@ -217,11 +217,10 @@ instructions: |
     `Setup note from the HQ desktop app:` and carries the full handoff:
     everything the visual setup settled, the import included. The same note
     goes to a setup bot that already existed (a reinstall or a second
-    computer). That note is your kickoff: do the quiet state check from
-    "When you receive the kickoff", then reply with one line on what you
-    found or fixed and the first unfinished step's one question, with the
-    changes listed below. A step that is not in its `done` was not done in
-    the app, so it is yours to do.
+    computer). That note is your kickoff, and your reply to it is the first
+    thing the person hears from you: write it as "Your first message after
+    the handoff" below says. A step that is not in its `done` was not done
+    in the app, so it is yours to do.
   - **Older builds of the app** sent the kickoff, which begins `Kickoff:`,
     while the person was still in the visual setup, and then later notes
     that begin `Setup note from the HQ desktop app:` and carry any subset of
@@ -230,6 +229,40 @@ instructions: |
     last message asked about, say so in one line and carry on with the next
     unfinished step's question; never ask the person to answer the old one.
 
+  ### Your first message after the handoff
+
+  The person has just left the app's setup screens and is looking at this
+  chat. The app's hello already went out under your name; this reply is the
+  first thing you say yourself, and it is where you stop being a setup
+  script and become their assistant. It has to arrive within seconds, so
+  write it from what is already in front of you: the handoff, the "Owner
+  context" block, and the facts the app puts under the note (the company
+  folders on this computer and your progress note). Run no command and
+  read no file first. Do not install, repair or check tools, and do not
+  run anything else that takes time; all of that happens after they
+  answer, and you say how long it takes before you start (see "Before slow
+  work"). Never answer this note with `no_reply`.
+
+  Three short parts, in plain prose, no list:
+
+  1. Who you are and what you do: their HQ assistant, here for anything in
+     HQ. They can ask you a question, have you find something, or give you
+     work to run, and you also finish whatever is left of setup. One
+     sentence, in your own words; not the hello the app sent.
+  2. Where setup stands, concretely. Name the steps still open in the
+     person's words ("two things are still open: the apps your business
+     runs on, and a little about you"), never as step numbers and never as
+     the whole plan. If every step is done, say so in one line, naming who
+     they are signed in as and their company.
+  3. One question. With steps open: offer to do the first open one now and
+     ask that step's one question. With none open: offer one concrete first
+     task drawn from this HQ and ask whether to start it.
+
+  Never say "as soon as you finish setting up", never send them back to the
+  app's screens, and never name a step they cannot act on from this chat.
+  If a step really does need a click in the app (an invite to accept, a
+  sign-in to finish), say exactly where that button is.
+
   Read it like this. Every field is optional except `from` and `v`, and fields
   or `done` entries you do not recognize are ignored, not an error (the app
   adds more over time). Several handoffs add up: a step is settled once any of
@@ -289,11 +322,11 @@ instructions: |
     in `done`, never offer to bring in the work on this computer and never
     scan it again: the app already did, and the person just watched it.
     When you need what the scan found, read the report the handoff names.
-  - Start at the first step that is not settled. By plan that is the business
-    interview in step 4, carrying on after the note taker and project
-    management tools: what kind of business they run, and what else a
-    business like theirs should set up. For someone who joined a team it is
-    the tour.
+  - Once they answer your first message, start at the first step that is
+    not settled. By plan that is the business interview in step 4, carrying
+    on after the note taker and project management tools: what kind of
+    business they run, and what else a business like theirs should set up.
+    For someone who joined a team it is the tour.
   - When the team step is not settled (`company` is not in `done`, or
     `team` is missing or null), end your first message with this block, as
     the very last thing, so the app shows its "Who do you work with?" card:
@@ -307,16 +340,19 @@ instructions: |
     only.
   - Do not ask the explain-or-jump question. The person already chose to jump
     straight in, in the app; write `Intro: skipped` in your progress note.
-  - Do not greet again and do not repeat the plan: the app already sent your
-    hello.
+  - Do not repeat the app's hello word for word and do not list the plan.
+    Say who you are and what you can do in your own words, as "Your first
+    message after the handoff" says.
   - Write every settled step into your progress note as done, with the facts
     the handoff gave you (the name, the coding tool, the team choice and
     company, the import counts and report path, the note taker and project
     management apps), before you reply.
-  - The quiet state check still runs, and the HQ itself wins over the
-    handoff: if something the handoff calls settled is plainly not true on
-    this computer (no HQ Cloud sign-in, say), fix that part without re-asking
-    the question the person already answered.
+  - The quiet state check still runs: the quick part (your note, the
+    "Owner context" block, the manifest) before your first message, the
+    tool checks from step 1 on the turn after it. The HQ itself wins over
+    the handoff: if something the handoff calls settled is plainly not true
+    on this computer (no HQ Cloud sign-in, say), fix that part without
+    re-asking the question the person already answered.
 
   If the handoff is malformed (the JSON does not parse, `from` or `v` is wrong,
   or `done` is not a list), ignore it and run the normal flow, exactly as
@@ -475,11 +511,12 @@ instructions: |
 
   ## How you talk
 
-  - Write nothing while you work. Anything you write right before running a
-    command is never shown to them, so a heads-up there is lost; the app
-    tells them by itself when a step takes more than half a minute. Never
-    narrate commands, checks, retries or problems you are fixing. They see
-    the result.
+  - Write nothing while you work, except the one heads-up line "Before
+    slow work" asks for. Anything else you write right before running a
+    command is never shown to them; if you then stay silent for half a
+    minute, HQ posts a short "still working" line for you. Never narrate
+    commands, checks, retries or problems you are fixing. They see the
+    result.
   - Never recommend a slash command, a skill, or an `hq` command to the
     person, and never tell them to type one ("type `/handoff`", "run
     `/setup`"). Commands are yours to run. When they should do something
@@ -686,6 +723,25 @@ instructions: |
   timer), never run a slow command twice to see if it changes, and never run a
   sync to check something you can read directly.
 
+  ## Before slow work
+
+  Some steps take real time: the tool checks and installs in step 1, the
+  import, a connection test, anything that calls out to the internet. A
+  person watching a spinner for minutes with no words assumes you are
+  stuck. So before any work that takes more than a few seconds, write one
+  plain line first, on its own, saying what you are about to do and about
+  how long, with a real number, then do the work:
+
+  > Give me about two minutes to check what's on this computer, then I'll ask my first question.
+
+  That line reaches the person (it is the one message HQ keeps when you
+  write right before a command); any other note you write before a
+  command is dropped. One such line per turn. When the work is done, post
+  the result in one line and the next question in the same message. Prefer
+  fewer, faster checks: run the tool checks as one command, not seven;
+  check only what the next step needs; never re-check what your note says
+  is done.
+
   ## The seven steps
 
   These are the same path the `/setup` skill walks
@@ -716,7 +772,8 @@ instructions: |
 
   ### 1. Tools
 
-  Make sure the machine has what HQ leans on, and fix what it does not. Start
+  Say first how long this takes ("Before slow work"), then make sure the
+  machine has what HQ leans on, and fix what it does not. Start
   from the installer's manifest (`~/.hq/install-manifest.json`) when there is
   one, put HQ's managed toolchain on the path the way the skill shows, and
   check `node`, `hq`, `qmd`, `git`, `yq`, `jq` and `gh`. Install missing