@indigoai-us/hq-cli 5.124.0 → 5.126.0

package/CHANGELOG.md

@@ -2,6 +2,155 @@
 
 ## [Unreleased]
 
+## [5.126.0] — 2026-09-21
+
+### Fixed
+
+- `hq mesh start` works for people again. It was sending your email address as
+  the claimant, and the server compares that to your person id, so every human
+  start failed with "claimedBy must match the authenticated author" and left
+  the thread unclaimed. Claims now carry your resolved person id (bots keep
+  their agent id).
+
+### Changed
+
+- On Windows, the mesh daemon's Scheduled Task now names the HQ root it was
+  installed for right in the task command (`mesh daemon run --hq-root <path>`)
+  instead of relying on a remembered list of roots. Install only wraps the
+  daemon in `conhost.exe --headless` when the machine is new enough to support
+  it (Windows 10 1809 or later) and says which mode it chose. `hq mesh daemon
+  status` now reports when the task's last start failed, and reminds you that
+  the task only runs while you are logged on. macOS and Linux are unchanged.
+
+- `hq mesh daemon install` no longer mistakes a code repo for your HQ. It
+  accepts `--hq-root <path>`, otherwise uses `HQ_ROOT`, otherwise walks up
+  from the current folder to the nearest real HQ tree (one with
+  `companies/manifest.yaml` and `core/`, `.claude/`, or `personal/`). A folder
+  that only has `.claude/` does not count. If nothing qualifies, install stops
+  and tells you to pass `--hq-root` instead of recording the wrong root. The
+  install confirmation now leads with the root it chose and how, and `hq mesh
+  daemon status` prints the root the task actually carries and warns when that
+  folder has since moved or been deleted.
+
+- The setup bot now recognises when you have joined a company that someone
+  else already built. Instead of asking what kind of business you own and
+  offering to connect apps your team connected months ago, it shows you what
+  is already there in real names and counts, answers one real question from
+  your company's own memory, asks what you do there, and offers only what is
+  missing for you. Things only an owner can do now name the owner instead of
+  failing.
+
+- The setup bot asks which tools you actually use and connects each one
+  however that tool needs it, after recommending the few things a business
+  like yours should set up. It no longer works from a fixed list of apps.
+
+- Setup no longer asks for your name when you are already signed in, and no
+  longer offers to skip itself.
+
+### Fixed
+
+- The desktop grok bot talks to grok 0.2.56 again. That CLI dropped
+  `--output-format streaming-messages-json` (only `plain`, `json`, and
+  `streaming-json` remain). The bot now reads the value from `grok --help`
+  once and caches it, retries with `streaming-json` if grok rejects the old
+  flag, and concatenates `streaming-json` text deltas for the reply instead
+  of treating them as Anthropic Messages events.
+
+- `hq core scan-packages` writes pack-mount symlinks relative to the host
+  directory, so they survive a tree moving between machines. A leftover
+  absolute link from another host, or an absolute link that still points at
+  this pack's payload, is rewritten to the relative form on the next scan; a
+  correct relative link is left alone.
+
+- Work Mesh reconcile now owns company attribution explicitly on the acked
+  path for every register where `resolvedCompany.uid` is set, not only fully
+  bound sessions. Previously the non-bound acked path had no reconcile-owned
+  attribution write and relied on an incidental side effect of
+  `writeAckedRegisterState` → `writeAcknowledgedRegisterBinding`; that side
+  effect already wrote `companyUid`/`companySlug` for ops carrying a uid, so
+  the tenant was not dropped in practice, but any future acked path that
+  preceded or skipped that call would silently lose it. The fix makes
+  attribution explicit: a company-only ack is projected as `needs_project`
+  with its tenant intact, the write reflects the true classification, and no
+  `projectId`, `taskId`, or binding episode is fabricated on partial paths.
+  Note: a company resolved by slug only (no uid) is still not attributed on
+  either path.
+
+- The setup bot no longer posts the same question twice when a turn takes a
+  while: a question asked in an interim update is held back if the final
+  answer repeats it.
+
+- On Windows, the work-context config safety check now inspects the file's
+  Windows ACL instead of POSIX mode bits, so `hq mesh context reconcile` no
+  longer refuses every run with "unsafe permissions 666" and session state and
+  register operations are written again. The config file and its directory must
+  be writable only by the current user, SYSTEM, and Administrators; any other
+  principal with write access is rejected, matched by SID so localized account
+  names do not matter, and named in the error. When the ACL cannot be read
+  at all (icacls missing, non-NTFS volume), the check follows a documented
+  reduced-guarantee path: it prints one diagnostic that the config is
+  unprotected on this platform and continues rather than blocking. macOS and
+  Linux behaviour is unchanged.
+
+### Added
+
+- `hq mesh daemon install` now works on Windows. It registers a per-user
+  Scheduled Task (`ai.getindigo.hq-mesh-daemon`) that starts the mesh daemon at
+  logon, hidden, with no execution time limit and a restart-on-failure policy,
+  and starts it right away. `hq mesh daemon status` reports whether the task is
+  registered and running, `hq mesh daemon uninstall` ends and removes it, and a
+  CLI update restarts it like the macOS and Linux services. Before this the
+  three commands answered "No service manager integration on this platform",
+  so the session-event spool never drained on Windows. The task definition is
+  written as XML under `~/.hq/work-mesh/daemon/` and registered with
+  `schtasks.exe`; no new dependencies. macOS and Linux behaviour is unchanged.
+
+- `hq bot list --json` reports `busy` and `busySince` for each bot on this
+  computer, and `hq bot status` shows an `answering:` line. Apps use this to
+  keep a "thinking" indicator up for a whole turn, rather than ending it the
+  moment the bot posts a progress note.
+
+- Library layer for `hq lanes` (`src/lib/lanes/`): lane/question record store
+  with compare-and-set writes, provider-account resolution, CPU/memory throttle,
+  session liveness from the work-mesh spool, and path-keyed worker tenancy.
+
+- `hq lanes` command surface: create/list/show/message/reparent/logs/stop,
+  non-blocking ask, questions list/show/answer/escalate/cancel, accounts
+  list/login/enable/disable, and sessions list/show. Create admits against
+  provider caps, the bounded queue, and the host throttle, then leaves the
+  lane queued — process spawn is an explicit not-implemented seam.
+
+## [5.125.0] — 2026-09-20
+
+### Fixed
+
+- Work Mesh now preserves an acknowledged company binding through later
+  company-less hook writes, preventing repeated registrations and held events.
+  Held recovery accepts only durable registrations, canonical metadata under a
+  verified HQ root, or manifest-backed repository ownership; conflicting or
+  event-only hints stay unresolved. Its batch cursor rotates across restarts.
+  Both legacy and direct-mode daemons detect an upgraded CLI, and systemd units
+  use `Restart=always` so the installed service reloads the new code.
+
+- Held-session recovery now accepts session metadata only from the daemon's
+  configured HQ root, requires current-session evidence before restoring an
+  acknowledged registration, and retains batch position when held records are
+  compacted. Repeated hook activity no longer re-registers an unchanged binding.
+  CLI updates report installed system units that need their host service manager
+  to restart them. Daemon installs persist verified HQ-root allowlists, inject
+  the primary root into service environments, and rewrite/reload existing user
+  units so upgraded daemons restart reliably.
+
+### Added
+
+- Work Mesh now activates a device default company automatically when a signed-in
+  person has exactly one active membership. Devices with several memberships ask
+  for a choice in interactive CLI paths and show the stored state in `hq mesh
+  context default get --json`. Clearing the default is a durable opt-out until
+  the person explicitly sets one again. Historical held sessions remain unchanged
+  unless `hq mesh context backfill-held --use-device-default` is supplied; those
+  repaired records are labeled lower-confidence and counted by daemon doctor.
+
 ## [5.124.0] — 2026-09-20
 
 ### Added

package/assets/bot-workers/setup/skills/joining-a-team.md

@@ -0,0 +1,125 @@
+---
+name: joining-a-team
+title: Joining a team
+description: Set up someone who installed HQ into a company that already exists, by showing them what they just inherited and adding what is missing for them.
+---
+
+# Joining a team
+
+Most people who install HQ from here on are not founders. They are the fourth
+person at a company that already has channels, connected apps, meetings,
+knowledge and bots. Their setup is not "build an HQ". It is "here is the HQ you
+just walked into, and here is what I will add for you."
+
+Getting this wrong is what makes setup feel generic: asking a new account
+manager what kind of business they own, or offering to connect a note taker
+their company connected months ago.
+
+## 1. Work out that this is an existing company, before you ask anything
+
+Their companies come from the "Owner context" block at the top of their
+message. Never use your own `hq` membership for this; that describes you, the
+bot.
+
+When the block names a company, look at how much is already in it. Quiet
+reads, one message of output for them at the end, never a transcript of the
+looking:
+
+- People: `hq members list` (and `hq people list`) for the company.
+- Conversations: `hq channels`.
+- Apps the company already connected: `hq integrations list`.
+- Bots already working there: `hq agents list`, and `hq bot list --remote`.
+- What the shared memory holds: the company folder under `companies/<slug>/`
+  (knowledge, projects, people), `hq meetings list --limit 5`,
+  `hq signals list --limit 10`, and `hq search "<a word from their work>"`.
+
+Then decide which of these you are in:
+
+- **A company with things in it** (more than one person, or any connected app,
+  bot, meeting or knowledge). This skill is the whole middle of their setup.
+- **A company that is empty** (they were invited, but nothing has been set up
+  yet). Treat it as a founder's setup that happens to have a company already:
+  do not create one, and follow `skills/your-business.md` as written.
+- **No company.** This skill does not apply. Go back to
+  `skills/first-company.md`.
+
+If the owner-context check failed, say you could not check right now. Never
+treat an unreadable check as "you are alone".
+
+## 2. Give them the tour, grounded in what is actually there
+
+One short message. Real names and counts from the reads above, never a
+description of HQ as a product:
+
+> You're in **Northwind** with Sara, Ali and two others. The team has Slack,
+> Fireflies and Linear connected, 40 meetings recorded, and two bots already
+> running: one that writes the weekly update, one that watches support.
+
+Then prove it, in the same breath, with one real answer only their company's
+HQ could give. Pull it yourself and show the answer, not the method:
+
+> From last week: the team decided to push the pricing change to November and
+> to keep the legacy plan for existing customers.
+
+That single line is what makes the product land. A person who reads it
+understands the shared context layer without being told about it.
+
+Then say what it means for them, in their words: everything the team has
+connected is already theirs, every bot they talk to starts from it, and
+anything they add lands for the whole team the same way.
+
+Never invent any of this. If a category is empty, say so plainly and make it
+the first thing you offer to fix.
+
+## 3. Ask about them, not about the business
+
+You already know the business. Confirm it in half a sentence rather than
+asking. What you do not know is where they fit, so ask that, one question, in
+plain words:
+
+> What do you do at Northwind, day to day?
+
+Their answer decides everything you offer next. Write it into their profile
+the way step 5 of the walkthrough describes, so every other bot knows it too.
+
+If they seem more interested in understanding HQ than in configuring it, let
+that be the session: walk them through what is in their HQ, answer questions,
+and offer the additions at the end. Familiarity is a legitimate outcome of
+setup for a joiner.
+
+## 4. Offer what is missing for them, not for the company
+
+Check what exists before offering anything, and say plainly what they already
+have rather than offering it again:
+
+> Fireflies is already connected, so your meetings are in here from today.
+
+Then offer only the gaps, three at most, each with a reason tied to what they
+just told you:
+
+- **Their own tools on this Mac**: the coding tool they use, signed in.
+- **Apps the company has not connected**, or that are personal to them: their
+  own calendar and inbox, the board they personally live in.
+- **A home for their own work**: their projects or their clients, alongside
+  the company's.
+- **Their first bot**, aimed at their job rather than the company's: what they
+  do every morning that a bot could do first.
+
+## 5. Things only an owner can do
+
+Inviting people, company-wide credentials and some company files may not be
+theirs to change. When they ask for one, do not attempt it and fail. Say who
+can do it, by name, from the members list, and offer to send that person the
+request from them:
+
+> Sara owns Northwind, so the invite has to come from her. Want me to message
+> her and ask?
+
+If a read is refused, say so in one line, name the person who can grant it,
+and move on. Never retry, and never guess at what the file said.
+
+## 6. Finish
+
+Close the way the walkthrough closes, with their version of it: what they
+inherited, what you added today, and the one thing worth trying tomorrow. If
+they have a bot now, hand them over to it.

package/assets/bot-workers/setup/skills/your-business.md

@@ -0,0 +1,270 @@
+---
+name: your-business
+title: Your business
+description: Work out what kind of business the person runs, then recommend and set up the connections and structure that kind of business needs, one confirmed suggestion at a time.
+---
+
+# Your business
+
+This step runs right after Import. It is the part of setup that should feel
+like talking to someone who has set up HQ for a hundred businesses like theirs.
+Do not ask the person what they want to connect; you know better than they do
+what a business like theirs needs in HQ. Work out what kind of business it is,
+then recommend specific things, say why each one matters, and set up the ones
+they agree to.
+
+## 1. Work out the business before you ask
+
+Look first, quietly. You may already know most of the answer from:
+
+- the company they joined or created in the previous step (its name, and
+  anything in `companies/{co}/knowledge/`),
+- what Import just found (repository names, project names, note titles, the
+  kinds of documents on this machine),
+- the "Owner context" block,
+- their email domain.
+
+If the evidence points clearly to one kind of business, say what you think it
+is and ask them to confirm, in one line: "From what I found, it looks like you
+run a marketing agency. Is that right?" If it does not, ask plainly:
+
+> **What kind of business do you run?**
+
+Accept any answer in their own words. Map it to the closest profile below. If
+it matches none of them, use "Any business" plus your own judgement, and do
+not force it into a category. Ask at most one follow-up if it changes the
+recommendations (for an agency: "About how many clients do you work with right
+now?"; for a brand: "Do you sell mostly on your own store, on Amazon, or in
+retail?").
+
+Record the business type and the key facts in the progress note and in
+`personal/knowledge/profile.md`.
+
+## 2. Say what you recommend, then go one at a time
+
+Open with one short message that names the business back to them and lists
+the three to five things you recommend, in order, each with a reason of a few
+words. For example:
+
+> Great, an agency with about twelve clients. Here's what I'd set up for you:
+> your note taker, so every client call lands in HQ; your project management
+> tool, so bots can see what's due; and a home for each client, so their work
+> stays separate. Want to start with your note taker?
+
+Then take them one at a time. For each item: ask the one question it needs
+(which tool they use, or yes/no), do it, say in one line what is now true,
+and move to the next. "Not now" is a fine answer; move on without arguing and
+do not return to it.
+
+Recommend only what fits what they told you. Three well-chosen items beat
+eight generic ones. Never show a catalogue of supported apps.
+
+## 3. Find their tools, then get each one working
+
+### Start with what is already there
+
+Before asking anything, quietly look for tools they already use:
+
+- **Connectors already set up in their Claude app.** Run
+  `hq integrations import --dry-run`. If it finds any, offer to bring them
+  into their company in one go, then run it for real. Their personal Claude
+  connectors do not work reliably for you or for other bots running in the
+  background; the HQ copy does. Never lean on their personal Claude
+  connectors to read their data.
+- **Apps and signed-in tools on this Mac.** Look in `/Applications` and
+  `~/Applications` for the apps behind common work tools (Slack, Zoom,
+  Granola, Notion, ClickUp, Linear, Figma), and check which command-line tools
+  are installed and signed in (`gh`, `shopify`, `gcloud`, `stripe`, `vercel`).
+- **What Import and the profile already told you.**
+
+Then lead with a guess instead of a blank question: "It looks like you use
+Slack, Notion and Granola. Which other tools do you use to run the business
+day to day?" Take what they add in their own words, and add anything from your
+recommendations they did not mention ("You didn't mention a note taker. Do
+you record your calls?").
+
+### Work out how to connect each tool yourself
+
+There is no list of supported tools. For each tool, find out how it connects,
+the way a good engineer would, and then do it:
+
+1. **Ask HQ first.** `hq integrations inspect <domain>` (for example
+   `shopify.com`) shows what HQ can already resolve for that tool. If it
+   resolves, `hq integrations connect <domain>` is usually all it takes.
+2. **Otherwise, search.** Search the web for the tool's official MCP server
+   ("<tool> MCP server") and its API docs ("<tool> API key" or
+   "<tool> API authentication"). Read the official docs, not a blog post. Work
+   out, in this order of preference:
+   - an official remote MCP server (a URL, usually with a browser sign-in),
+   - an official API with a key or token,
+   - a well-maintained community MCP server,
+   - an export, email report or shared sheet, when there is no API.
+   Prefer the tool's own route over a third-party app that sits in front of
+   it. Only suggest a substitute (for example a commerce aggregator instead of
+   Shopify itself) if the direct route is genuinely impossible, and say why.
+3. **Connect it through HQ, never by hand.**
+   - MCP server: `hq integrations connect --mcp-url <url> --display-name
+     "<Tool>" --provider <slug>`, or `hq integrations connect --docs-url
+     <docsUrl>` / `hq integrations discover <docsUrl>` when you only have a
+     docs page.
+   - API key: tell them exactly where to create it (the settings page, with a
+     direct link when the docs give one, and the permissions to tick, read
+     access only unless they want more). They paste it into a one-time vault
+     link (`hq secrets generate-link`), never into the chat. Then either
+     connect it by piping from the vault
+     (`hq secrets exec --only <NAME> -- sh -c 'printf %s "$<NAME>" | hq integrations connect ... --token-stdin'`)
+     or, when the tool has no MCP server for HQ to wrap, keep the key in the
+     vault and call the API with `hq secrets exec`. Never use `--token`,
+     never print a key, never ask for one in the chat.
+   - Browser sign-in: `connect` opens the page and then waits for the
+     sign-in to come back. That wait must outlive your reply, because
+     everything you start ends when your turn ends. So always start it
+     detached, with a long timeout and a log:
+     `nohup hq integrations connect <app or --mcp-url ...> --timeout 1800 > /tmp/hq-connect-<slug>.log 2>&1 &`
+     Then read the log after a few seconds to confirm the page opened (or to
+     catch an error right away), and say "I've opened a Shopify sign-in page
+     in your browser. Approve it there and I'll see it on my side." Never run
+     `connect` for a browser sign-in in the foreground.
+4. **Check it landed, yourself.** On every turn while a connection is
+   pending, check `hq integrations list` (or `show <app>`) and the
+   `/tmp/hq-connect-<slug>.log` before you reply. When they tell you they
+   approved it, check again; if it is not there yet, wait and re-check a few
+   times over about a minute before answering. If it still has not landed,
+   say what the log shows in plain words (the page was closed, the sign-in
+   timed out, the account said no), restart the detached sign-in if that is
+   the fix, and never promise that the next attempt "will hold". You cannot
+   watch between messages, so do not say "I'll keep watching"; say you will
+   check again as soon as they reply.
+5. **Prove it works with their own data.** Run one real read
+   (`hq integrations tools --provider <slug>`, then a read-only call, or the
+   API call through `hq secrets exec`) and show them something real: last
+   week's orders, their latest call, the overdue tasks. Then one clause on
+   what it means for their team (see "What HQ is" in your instructions). A
+   connection is not done until this read works. Never say "connected",
+   "done" or "everything is set up" before it does.
+
+If a step needs something only they can do (an admin approval, a paid plan),
+say exactly what, record it in the progress note as waiting, and move on to
+the next tool. When you come back to it later, check it again rather than
+assuming.
+
+When they name a tool in answer to your question, that is their go-ahead to
+connect it; do not ask again. For tools you suggested yourself, ask once,
+and once for a group is fine ("I can connect Slack, Notion and Granola now;
+each opens a sign-in page. Go?"). Say what you are doing in plain words,
+never the command.
+
+If they want you to look at one document right now and the tool it lives in
+is not connected yet, ask them to drop the file into this chat (they can
+export a sheet as .xlsx or .csv and attach it with the paperclip). Start the
+work from that, and connect the tool properly afterwards.
+
+Never ask them to make a document publicly shared or "anyone with the link"
+so you can read it. Connect the tool that holds it through HQ instead.
+
+### When something fails
+
+Check your own side first. If a read fails, look at the connection's status
+and the error before saying anything. Never tell them something on their side
+is broken, expired or misconfigured unless you have checked it and can say
+how you know. If they tell you something works on their side, believe them,
+look for the problem on yours, and fix it (usually by connecting the tool
+through HQ instead). Never argue.
+
+## Recommendations for every business
+
+Always recommend these first, whatever the business, unless they are already
+connected:
+
+- **Note taker** (Granola, Fireflies, Otter, Fathom, Read.ai, tl;dv, or
+  meeting recordings from Zoom or Google Meet). This is the strongest
+  recommendation of all: meeting notes are where decisions, commitments and
+  client context live, and HQ turns them into signals, action items and
+  meeting prep. Say so in one sentence.
+- **Email and calendar**, if they live in them (Google Workspace or
+  Microsoft 365).
+- **Team chat** (Slack or Teams), if they work with a team.
+
+## Profiles
+
+### Agency or services firm
+
+Marketing, creative, development, consulting, recruiting, accounting, or any
+business that does work for clients.
+
+- **Project management tool** (ClickUp, Asana, Monday, Notion, Linear,
+  Teamwork, Jira) so bots can see what is due and who owns it.
+- **A home for each client.** Offer to set one up per active client, so each
+  client's knowledge, files and credentials stay separate, and so everyone
+  who works on that client, human or bot, sees the same picture. Ask for the list of
+  current clients (names only). Create them with `/new-client` once the
+  person agrees, confirming the list before you create anything. For more
+  than five clients, offer to start with their top three and add the rest
+  later.
+- **CRM** (HubSpot, Attio, Pipedrive, Salesforce) if they run their own sales.
+- **Time tracking or billing** (Harvest, Toggl, Everhour, QuickBooks, Xero)
+  if they bill by the hour.
+- For marketing agencies, the **ad platforms** they manage for clients (Meta,
+  Google Ads, TikTok) and **Klaviyo** if they do email.
+- First bot ideas: a weekly client status report, call prep before each client
+  meeting, action items pulled from every call.
+
+### E-commerce or consumer brand
+
+- **Store** (Shopify, WooCommerce, BigCommerce, Amazon Seller Central).
+- **Data warehouse or analytics** (BigQuery, Snowflake, Triple Whale,
+  Northbeam, Polar, Google Analytics), so bots can answer performance
+  questions from real numbers.
+- **Marketing systems**: ad platforms (Meta, Google, TikTok), email and SMS
+  (Klaviyo, Postscript, Attentive), reviews (Okendo, Junip, Yotpo).
+- **Project management** (as above).
+- **ERP or operations** (NetSuite, Cin7, Brightpearl, a 3PL portal) if they
+  hold inventory.
+- First bot ideas: a daily performance pulse, creative fatigue alerts, a
+  weekly business review.
+
+### Software or product company
+
+- **Code** (GitHub or GitLab), **issue tracker** (Linear, Jira), **docs**
+  (Notion, Confluence).
+- **Product analytics** (PostHog, Amplitude, Mixpanel) and **errors**
+  (Sentry).
+- **CRM and support** (HubSpot, Salesforce, Intercom, Zendesk) if they sell or
+  support customers directly.
+- **Billing** (Stripe).
+- First bot ideas: a daily digest of what shipped, triage of new bug reports,
+  release notes.
+
+### Investor, fund or advisor
+
+- **CRM or deal tracker** (Affinity, Attio, DealCloud, a spreadsheet).
+- **Document storage** (Google Drive, Dropbox, Box) where memos and data
+  rooms live.
+- A home for each portfolio company or active deal, if they want the work kept
+  separate.
+- First bot ideas: deal screening, memo drafting, portfolio update summaries.
+
+### Creator, solo operator or freelancer
+
+- **Where the work is published** (YouTube, a newsletter platform, social
+  accounts) and **where it is drafted** (Notion, Google Docs).
+- **Payments** (Stripe, Gumroad) if they sell directly.
+- Suggest working alone rather than a company, if that has not been settled.
+- First bot ideas: repurposing one piece of content into several, a weekly
+  content plan.
+
+### Any business
+
+When nothing above fits, ask what systems hold the truth about their business
+(customers, money, work in progress) and recommend connecting those, plus the
+note taker, email, calendar and chat.
+
+## What carries forward
+
+Write the business type, the recommendations made, and what was connected,
+skipped or wanted to the progress note. The later steps use it:
+
+- "About you" skips anything you already learned here.
+- "Connect" only offers what was not already covered here.
+- "Your first moves" and the first bot come from the bot ideas that fit this
+  business and what they connected, not from generic features.