@lanes-sh/link 0.7.1 → 0.8.0

package/README.md

@@ -51,12 +51,14 @@ middle of your data.
 
 ## Quickstart
 
-Needs [Bun](https://bun.com) 1.3.11+. Nothing else — no account anywhere.
+Needs [Bun](https://bun.com) 1.3.11+, and a Lanes sign-in.
 
 ```console
 $ bun install -g @lanes-sh/link                # puts `lanes` on your PATH
-$ lanes link profile add personal --target local
-$ lanes link start --profile personal --target local
+$ lanes auth login                             # opens a browser once
+$ lanes link profile add personal --workspace local
+$ lanes link profile members add --me --profile personal --workspace local
+$ lanes link start --profile personal --workspace local
 ok    serving http://127.0.0.1:7337/mcp
       profiles: personal
 ```
@@ -64,7 +66,7 @@ ok    serving http://127.0.0.1:7337/mcp
 Then, in another shell:
 
 ```console
-$ lanes link mcp add --profile personal --target local                           # every agent installed; or name one: claude, codex
+$ lanes link mcp add --profile personal --workspace local     # every agent installed; or name one: claude, codex
 ok    registered lanes-link with Claude Code (user scope)
 ok    registered lanes-link with Codex
 ```
@@ -73,14 +75,22 @@ Your agents can now use it. Memory, tasks, files, skills, and the vault hold you
 rather than an account, so they are already there — nothing to connect, no credentials, no browser.
 Mail and calendar are the next step. **[Full quickstart →](https://lanes.sh/docs/link/quickstart)**
 
+**Why the sign-in.** A profile declares who may consume it, and there is nothing to check that
+against if the endpoint has no idea who is asking. That is a real dependency for a self-hostable
+tool and worth stating plainly; what it is not is a dependency per request. The network is needed
+to sign in and to refresh, and a machine offline for a day keeps serving. `lanes link token
+show` still mints a static token for CI, which has no browser to sign in with.
+
 ## In the Lanes desktop app
 
 Prefer not to use a terminal? The [Lanes desktop app](https://lanes.sh/desktop) drives this CLI from
-a settings page. **Settings → Integrations → Lanes Link** installs it, holds the profile and target
-every command runs against, connects your accounts, starts and stops the endpoint, and registers it
-with Claude Code or Codex.
+a settings page. **Settings → Integrations → Lanes Link** installs it, holds the profile and
+workspace every command runs against, starts and stops the endpoint, and registers it with Claude
+Code or Codex. From 0.8.0 your connections, profiles and audit log are on the
+[Lanes dashboard](https://lanes.sh/dashboard/link) instead, which reads your endpoint directly over
+loopback: run `lanes link pair` once to let it.
 
-![The Lanes Link page in the Lanes desktop app: the CLI status card and its version, the target and profile selectors, the endpoint row with its running state, and the list of connected accounts.](docs/images/lanes-link-desktop.png)
+![The Lanes Link page in the Lanes desktop app: the CLI status card and its version, the workspace and profile selectors, the endpoint row with its running state, and the list of connected accounts.](docs/images/lanes-link-desktop.png)
 
 It runs the commands above rather than reimplementing them, so consent and the token stay here where
 they belong, and an endpoint set up in the app is the same one you get from a shell. Available from
@@ -183,7 +193,7 @@ the whole inventory by connector and credential type:
 
 The same code, the same config, in all three. Only the storage adapters change.
 
-| | **Local** | **Your own cloud** | **Lanes Cloud** |
+| | **Local** | **Self-Hosted** | **Lanes Cloud** |
 |---|---|---|---|
 | Runs on | your machine | your GCP project, on Cloud Run | managed for you |
 | Needs | Bun, nothing else | a Google Cloud billing account | — |
@@ -191,7 +201,7 @@ The same code, the same config, in all three. Only the storage adapters change.
 | Reachable from | that machine | anywhere, including your phone | anywhere |
 | Status | ready | ready | **coming soon** |
 
-**Local** is the fastest way to start, and where most people stay. **Your own cloud** is what you
+**Local** is the fastest way to start, and where most people stay. **Self-Hosted** is what you
 want if you need to reach it from claude.ai, ChatGPT, or a phone — `lanes link deploy` creates the
 project, the bucket, the service account, and the revision on its first run. **Lanes Cloud** is the
 managed version; because it is the same data model, a workspace you build today moves across rather

package/instructions/agents/lanes-link-scout.md

@@ -67,8 +67,8 @@ to every future session.
 stops a write is policy on the endpoint:
 
 ```console
-$ lanes link policy deny memory.write --profile <name> --target <name>
-$ lanes link policy list --profile <name> --target <name>
+$ lanes link policy deny memory.write --connection memory.main --profile <name> --workspace <name>
+$ lanes link policy list --profile <name> --workspace <name>
 ```
 
 If you are running against a profile that grants writes, that is the owner's

package/instructions/skills/lanes-link/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lanes-link
-description: Use when the user refers to their own accounts, knowledge, procedures, or secrets through Lanes Link — "check my mail", "what do I know about X", "remember this", "which profile am I in" — or asks to connect, register, or set up their Lanes Link MCP server with this agent. Also covers operating the workspace from a shell — adding or removing a profile, checking what a target serves, deploying an endpoint or recovering a lost deployment — and what to do when a Lanes Link call is refused, or when the endpoint is not running.
+description: Use when the user refers to their own accounts, knowledge, procedures, or secrets through Lanes Link — "check my mail", "what do I know about X", "remember this", "which profile am I in" — or asks to connect, register, or set up their Lanes Link MCP server with this agent. Also covers operating the workspace from a shell — signing in, adding a connection, granting it to a profile, adding or removing a profile, deciding who may consume one, deploying an endpoint or recovering a lost deployment — and what to do when a Lanes Link call is refused, or when the endpoint is not running.
 ---
 
 # Lanes Link
@@ -8,42 +8,63 @@ description: Use when the user refers to their own accounts, knowledge, procedur
 A self-hostable gateway to one person's own context: the accounts they have
 connected, the knowledge they have accumulated, the procedures they have
 written down, and their secrets. One endpoint serves every profile in a
-workspace under one token, and each call names which profile it means.
+workspace, and each call names which profile it means.
 
 The endpoint describes its own live state when you connect — which profiles
-exist, what is reachable in each. This file is the part that does not change:
-how to behave with it.
+exist, what is reachable in each — and serves the long form of this at
+`lanes://instructions`. This file is the part that does not change: how to
+behave with it.
+
+## Three words, and they changed in 0.8.0
+
+A **connection** is one authorised account, and it belongs to the **workspace**.
+A **profile** is a selection: which connections it includes, what it allows on
+each, and who may consume it.
+
+That ordering is the change. A connection used to live inside one profile, so
+reaching the same mailbox from two of them meant authorising it twice, and every
+account of a provider within a profile was governed identically. Now the account
+is authorised once and each profile decides what it may do with it, which is what
+makes "read this mailbox, write that calendar" something a person can write down.
+
+**"Target" is gone.** It named the thing a workspace already was. `--workspace`
+is the flag; `--target` still works for one minor and warns.
 
 ## Profiles are a boundary, not a setting
 
 Every tool takes `profile` and `connection`. Profiles are how someone keeps work
-and personal apart; they share no database and no credential store.
+and personal apart; a connection they do not grant is not visible in one at all.
 
 **Ask which profile is meant when it is ambiguous. Do not default to whichever
 is listed first.** Quietly picking one crosses the line the profile exists to
 draw. There is no "current profile" to switch — the choice is made per call, and
-`lanes link profile list --target <name>` shows what exists *in that target*. A
-profile lives in exactly one, so `personal` on `local` and `personal` on `cloud`
-are two profiles that share a name rather than one profile in two places.
-
-**What a command must be told is never inferred — but it is not always both.**
-Nothing resolves from an environment variable or a config default, so a command
-missing what it needs refuses rather than acting somewhere else. Passing a flag a
+`lanes link profile list --workspace <name>` shows what exists *in that
+workspace*. A profile lives in exactly one, so `personal` on `local` and
+`personal` on `cloud` are two profiles that share a name rather than one profile
+in two places.
+
+**What a command must be told is never inferred from a profile — but the
+workspace may have a default.** `lanes set-workspace <name>` writes one, every
+command that uses it echoes the name it resolved, and the commands where being
+wrong is expensive refuse it and demand the flag: `deploy`, `sync`,
+`secrets push`, `profile remove`, `disconnect`, `token rotate`. Passing a flag a
 command does not read is refused too, which makes "add both to be safe" its own
 failure. Four levels:
 
-- **Neither.** `lanes link target list`, `lanes link mcp list`,
-  `lanes link version`.
-- **`--target` alone.** `lanes link profile list`, `lanes link profile add`,
-  `lanes link profile remove`, `lanes link target show`. A profile lives inside
-  one target's workspace, so listing or creating one names which workspace.
-- **`--target`, with the profiles derived from it.** `lanes link status`,
-  `lanes link deploy` and `lanes link sync targets` act on one endpoint serving
-  every profile that declares that target. `--profile` is accepted and *narrows*
+- **Neither.** `lanes link workspace list`, `lanes link mcp list`,
+  `lanes link version`, `lanes link mcp install-instructions`.
+- **`--workspace` alone.** `lanes link profile list`, `lanes link profile add`,
+  `lanes link profile remove`, `lanes link workspace show`,
+  `lanes link connection list`. A connection and a profile both live inside one
+  workspace, so listing or creating either names which.
+- **`--workspace`, with the profiles derived from it.** `lanes link status`,
+  `lanes link deploy` and `lanes link sync workspaces` act on one endpoint
+  serving every profile in that workspace. `--profile` is accepted and *narrows*
   the answer; it does not choose the subject.
 - **Both.** Everything acting on one account, and everything reaching the
   owner's own stores: `lanes link connect`, `lanes link token rotate`,
-  `lanes link secrets set`, `lanes link policy allow`, `lanes link memory list`,
+  `lanes link secrets set`, `lanes link policy allow`, `lanes link grant add`,
+  `lanes link profile members`, `lanes link memory list`,
   `lanes link tasks list`, `lanes link assets list`, `lanes link mcp add`.
 
 `lanes link profile add` and `lanes link profile remove` **reject** `--profile`.
@@ -53,9 +74,12 @@ disagree with it.
 When you write a command out for the owner, fill in what that command needs or
 leave it as `<name>` for them to complete — never drop a required one.
 
-A `connection` names an account within that profile. One profile may hold
-several of the same kind, and naming a connection belonging to a *different*
-profile is refused rather than guessed at.
+A `connection` names an account the profile grants. One profile may grant
+several of the same kind and govern each differently, so `gmail.work` may be
+readable where `gmail.personal` is writable. Naming a connection the profile does
+not grant is refused rather than guessed at, and a connection it does not grant
+is absent from the enum entirely: if you cannot see it there, it was not
+withheld by accident.
 
 ## Which store a thing goes in
 
@@ -90,7 +114,7 @@ try more than one wording before deciding it is not there.
 Writing is a separate grant, and it should be. What you write is served back to
 every later session, including to a different agent, so **write when you are
 asked to remember something, not as a habit.** The owner reaches the same
-entries with `lanes link memory list --profile <name> --target <name>` and a text editor.
+entries with `lanes link memory list --profile <name> --workspace <name>` and a text editor.
 
 ## Tasks have a status, so finish them rather than deleting them
 
@@ -116,7 +140,7 @@ being suggested again next week. Remove is for something recorded by mistake.
 Do not mute a task on your own initiative. It means "stop telling me about
 this", which is the owner's judgement, not yours.
 
-They manage these with `lanes link tasks list --profile <name> --target <name>`.
+They manage these with `lanes link tasks list --profile <name> --workspace <name>`.
 
 ## Assets are files kept by name
 
@@ -131,11 +155,11 @@ no form of a read that hands you a PDF, and a megabyte of base64 in the
 conversation would not help you if there were.
 
 To attach a stored file to something you are sending, ask the owner to run
-`lanes link attach <file> --profile <name> --target <name> --connection <provider>.<account>`,
+`lanes link attach <file> --profile <name> --workspace <name> --connection <provider>.<account>`,
 which prints a handle the send tools take. An asset's own store is not reachable
 from a mailbox's, deliberately.
 
-They manage these with `lanes link assets list --profile <name> --target <name>`.
+They manage these with `lanes link assets list --profile <name> --workspace <name>`.
 
 ## Skills are theirs, not yours
 
@@ -145,7 +169,7 @@ cannot read a skill's body; that is deliberate, not a gap to work around.
 
 So when a task has a skill for it, **say the skill exists and let them invoke
 it** rather than improvising your own version of their procedure. They manage
-these with `lanes link skills list --profile <name> --target <name>` and `lanes link skills show <skill> --profile <name> --target <name>`.
+these with `lanes link skills list --profile <name> --workspace <name>` and `lanes link skills show <skill> --profile <name> --workspace <name>`.
 
 ## Vault values are credentials
 
@@ -171,7 +195,7 @@ crossing is the specific mistake this exists to prevent.
 
 If the tool is not there, the profile has declared nothing. Ask rather than
 inventing something; they add one with `lanes link identity add <kind> <value> --profile <profile>
---target <target>` — both flags, because neither has a fallback.
+--workspace <name>` — both flags, because neither has a fallback.
 Nothing you can call writes here, deliberately.
 
 ## Who you are writing *to* is declared as well
@@ -228,7 +252,7 @@ its content.
 
 **If the endpoint is not on the same machine as the file**, `path` names the
 *server's* filesystem rather than theirs, and will not find it. Ask them to run
-`lanes link attach <file> --profile <name> --target <name> --connection <provider>.<account>`, which prints a
+`lanes link attach <file> --profile <name> --workspace <name> --connection <provider>.<account>`, which prints a
 handle to use instead.
 
 **`draft_only: true`** saves instead of sending, where they should see it before
@@ -248,9 +272,9 @@ granted, and retrying will not reveal it. A call that *is* refused was refused b
 policy on purpose.
 
 Report it plainly and let the owner decide whether to widen the grant —
-`lanes link policy list --profile <name> --target <name>` shows the rules, `lanes link policy allow <capability> --profile <name> --target <name>`
+`lanes link policy list --profile <name> --workspace <name>` shows the rules, `lanes link policy allow <capability> --connection <provider>.<id> --profile <name> --workspace <name>`
 changes them, and that is their call, not yours. **Do not look for another route
-to the same data.** Every call is audited either way; `lanes link audit tail --profile <name> --target <name>`
+to the same data.** Every call is audited either way; `lanes link audit tail --profile <name> --workspace <name>`
 shows what was attempted, refusals included.
 
 ## Setting something up
@@ -267,6 +291,21 @@ one is missing, it was switched off with a `deny`, which is their decision; do n
 offer to connect it. What setup is for is accounts: mail, calendar, files,
 issues.
 
+**Connecting authorises once; a grant is what a second profile needs.**
+`lanes link connect <provider> --profile <name> --workspace <name>` authorises
+the account into the workspace *and* grants it to the profile you named. Reaching
+the same account from another profile is then a grant rather than a second
+consent screen, which is the point of connections belonging to the workspace:
+
+```
+lanes link grant add gmail.<id> --profile work --workspace local
+lanes link policy allow gmail.users.messages.list --connection gmail.<id> --profile work --workspace local
+```
+
+`lanes link connection list --workspace <name>` shows every connection with the
+profiles that grant it, which is the answer when an owner says an account they
+connected is not showing up somewhere.
+
 **Take the command from `setup_provider`; never compose one yourself.** It carries
 the right profile and, where the provider stores a credential per account, the
 `--id` it needs. A command you assembled is one the owner pastes and watches fail.
@@ -276,9 +315,9 @@ credential — those are `lanes link` in a terminal, deliberately. What you can
 know exactly what to hand over, and say what it will ask for before they start.
 
 If you have a shell, you can run it yourself for anything that does *not* need a
-browser: `lanes link setup plan <provider> --profile <name> --target <name> --json` lists what to store,
-`lanes link secrets set <ref> --profile <name> --target <name>` takes the value on stdin, and
-`lanes link connect <provider> --profile <name> --target <name> --id <id> --non-interactive --json` finishes.
+browser: `lanes link setup plan <provider> --profile <name> --workspace <name> --json` lists what to store,
+`lanes link secrets set <ref> --profile <name> --workspace <name>` takes the value on stdin, and
+`lanes link connect <provider> --profile <name> --workspace <name> --id <id> --non-interactive --json` finishes.
 Anything with a browser sign-in belongs to whoever owns the account — give them
 the line.
 
@@ -286,7 +325,7 @@ the line.
 it needs, print the scopes and let the owner add the flag. Deciding that is theirs.
 
 **A new connection is served at once; the tools you were handed are not.**
-Connecting publishes the config to wherever that target's endpoint reads it and
+Connecting publishes the config to wherever that workspace's endpoint reads it and
 asks the endpoint to re-read it, so a `setup_overview` straight after connecting
 *does* show the account. What has not changed is the set of tools this session
 was given when it connected — the endpoint does not announce that its tools
@@ -302,15 +341,15 @@ endpoint restarted before the new token opens anything.
 
 If you have a shell, the commands that only *read* are yours to run without
 asking: `lanes link status`, `lanes link check`, `lanes link plan`,
-`lanes link doctor`, `lanes link profile list`, `lanes link target list`,
-`lanes link target show`, `lanes link tools`, `lanes link config show` and
+`lanes link doctor`, `lanes link profile list`, `lanes link workspace list`,
+`lanes link workspace show`, `lanes link tools`, `lanes link config show` and
 `lanes link audit tail`. None writes config, opens a browser, or costs anything,
 and running one beats asking the owner to paste its output back. Give each what
 its own level requires — they are not all the same, and the four levels are at
 the top of this file.
 
 **A command that writes runs `--dry-run` first, where it has one.** Show what it
-reported and wait for an answer. `lanes link deploy`, `lanes link sync targets`,
+reported and wait for an answer. `lanes link deploy`, `lanes link sync workspaces`,
 `lanes link profile remove`, `lanes link secrets push` and `lanes link mcp add`
 all take it. For a write with no dry run — `lanes link token rotate`,
 `lanes link policy allow`, `lanes link secrets set` — say in one sentence what it
@@ -320,27 +359,63 @@ whoever owns the account, as above.
 **`--json` is not everywhere.** It parses on every command and is read by only
 some, so one that ignores it prints its ordinary output and gives you nothing to
 key on — do not treat the absence of JSON as a failure. `status`, `doctor`,
-`tools`, `outputs`, `sync targets`, `target list`, `target show`, `profile list`,
+`tools`, `outputs`, `sync workspaces`, `workspace list`, `workspace show`, `profile list`,
 `connect` and `setup plan` implement it. `deploy`, `check`, `plan`,
 `config show`, `audit tail` and every `mcp` subcommand do not.
 
 **A profile is created and removed, never switched.** `lanes link profile add
-<name> --target <name>` writes a new one *into that target's workspace* — one
-target, not a list, because a profile lives in exactly one.
-`lanes link profile remove <name> --target <name>` takes `--dry-run` and then
+<name> --workspace <name>` writes a new one *into that workspace* — one
+workspace, not a list, because a profile lives in exactly one.
+`lanes link profile remove <name> --workspace <name>` takes `--dry-run` and then
 `--yes`, and removes the profile itself along with its stores: the file is in
 that workspace, so there is nowhere left for it to survive. Neither reads
 `--profile`; both name the profile positionally.
 
-There is no current profile and no default target. `lanes link profile default`
-and `lanes link target use` are gone and now refuse with an explanation — if you
+There is no current profile. There *is* a default workspace, written by
+`lanes set-workspace`, echoed by every command that uses it and refused by every
+command that publishes or destroys. The two commands that used to pin a
+profile or a workspace are gone and refuse with an explanation — if you
 meet one of those refusals, it is not a broken install, and there is no
 replacement to find. The choice is made per command, on purpose.
 
+## Signing in, and who may consume a profile
+
+Every human caller signs in with Lanes, on a local endpoint as much as a deployed
+one. `lanes auth login` opens a browser once; `lanes auth status` says who this
+machine is and when the session lapses. The network is needed to sign in and to
+refresh, not per call, so a machine offline for a day keeps serving.
+
+`lanes link start` refuses without a session, and names the command.
+
+A profile declares who may consume it, and **empty means nobody**:
+
+```
+lanes link profile members add --me --profile assistant --workspace local
+lanes link profile members list --profile assistant --workspace local
+```
+
+That list is a selection from the Lanes workspace rather than a second list
+beside it, so `members list` shows both who may consume this profile and who is
+in the workspace and could be given it. Somebody with an unaccepted invitation
+has no subject yet, so they are listed, marked, and refused; the answer there is
+for them to accept, not for anyone to invent a subject.
+
+Removing somebody does not end a session they already hold: membership is read
+when a token is minted. Rotating the endpoint token closes that
+window now, and it names both flags: `lanes link token rotate --profile <name>
+--workspace <name>`.
+
+**A client is not given a token any more.** `lanes link mcp add` registers the
+bare URL, and the client discovers the endpoint, sends its owner to sign in, and
+comes back with a token of its own. The static token is for CI, which has no
+browser, and `--headless` is what writes it into a registration. If you are
+writing a registration command for somebody, do not add an `Authorization`
+header: it is no longer how a client connects.
+
 ## Deploying, and what it decides
 
 `lanes link deploy` builds an image and rolls a revision. Its subject is a
-**target**, and the profiles behind it are every profile *in* that target's
+**workspace**, and the profiles behind it are every profile *in* that
 workspace, so one deploy serves all of them — there is no per-profile deploy to
 run and no reason to loop over them.
 
@@ -352,9 +427,9 @@ avoidable.
 Two things it refuses to guess, and both are the owner's to answer:
 
 - **Whose bearer token opens the endpoint.** One token reaches every profile
-  behind that target, so this decides who gets in. With several candidates and
+  behind that workspace, so this decides who gets in. With several candidates and
   nothing recorded, it refuses and prints the command that names one.
-- **A first deploy.** A target that does not exist yet has no workspace to derive
+- **A first deploy.** A workspace that does not exist yet has nothing to derive
   a set from, so `--profile` is required there. It may be repeated, and the first
   one named is the primary.
 
@@ -368,13 +443,13 @@ connected and not how a config change lands; both of those publish themselves.
 
 ## When a machine has lost track of a deployment
 
-A workspace holds a *pointer* to each target it does not itself hold, and a
+A workspace holds a *pointer* to each workspace it does not itself hold, and a
 machine can lose one — a new laptop, a reinstall, a workspace file restored from
 something older. The endpoint is still serving; what went missing is the line
 saying where it lives. The symptom is a `lanes link status` that reports nothing
-for a target you know is up.
+for a workspace you know is up.
 
-`lanes link sync targets` adopts it. `--discover` looks for a deployment the
+`lanes link sync workspaces` adopts it. `--discover` looks for a deployment the
 workspace has no pointer to, `--from <location>` names one directly, and
 `--dry-run` reports what it would write without writing it. Run the dry run and
 show it.
@@ -386,10 +461,10 @@ existed in two copies that could disagree, and there is one copy now.
 
 ## Registering it, and re-registering it
 
-`lanes link mcp add --profile <name> --target <name>` runs each harness's own registration command and installs
+`lanes link mcp add --profile <name> --workspace <name>` runs each harness's own registration command and installs
 this skill where that harness keeps them. With no argument it does every harness
 installed; name one (`claude`, `codex`) to be specific. Run it again after
-`lanes link token rotate --profile <name> --target <name>` — add `--force`, since Claude Code stores the token as
+`lanes link token rotate --profile <name> --workspace <name>` — add `--force`, since Claude Code stores the token as
 a value rather than a command.
 
 **Never paste the token.** There is a right way and a wrong way, and the
@@ -398,7 +473,7 @@ difference matters:
 ```bash
 # RIGHT — the token goes from the CLI to the harness. You never see it.
 claude mcp add --transport http lanes-link http://127.0.0.1:7337/mcp \
-  --header "Authorization: Bearer $(lanes link token show --raw --profile <name> --target <name>)"
+  --header "Authorization: Bearer $(lanes link token show --raw --profile <name> --workspace <name>)"
 
 # WRONG — the token is now in your context, and in the transcript, forever.
 lanes link token show --show          # then copying the value into the command
@@ -406,12 +481,12 @@ lanes link token show --show          # then copying the value into the command
 
 The token reaches every account of every profile the endpoint serves. Use the
 substitution form. If you have already printed one by accident, say so and offer
-`lanes link token rotate --profile <name> --target <name>`.
+`lanes link token rotate --profile <name> --workspace <name>`.
 
-Prefer `lanes link mcp add --profile <name> --target <name>` to writing the command yourself: it checks the
+Prefer `lanes link mcp add --profile <name> --workspace <name>` to writing the command yourself: it checks the
 endpoint is reachable, refuses to silently shadow an existing registration, and
 cannot mistype the token. For a harness it does not know, take the command from
-`lanes link outputs --profile <name> --target <name>` rather than writing it blind — that command checks whether
+`lanes link outputs --profile <name> --workspace <name>` rather than writing it blind — that command checks whether
 `lanes` resolves on this machine and prints a longer working form if it does
 not, where guessing gives you an empty substitution, a `Bearer ` header, and a
 401 that reads as a bad token.
@@ -420,7 +495,7 @@ If you register Codex, tell the user to export the token — Codex stores only t
 variable name, so nothing works until it is set:
 
 ```bash
-export LANES_LINK_TOKEN="$(lanes link token show --raw --profile <name> --target <name>)"
+export LANES_LINK_TOKEN="$(lanes link token show --raw --profile <name> --workspace <name>)"
 ```
 
 One registration covers every profile. Do not add one per profile; they share a
@@ -433,12 +508,12 @@ copy means the rules you are reading are not the ones that shipped.
 
 Claude Desktop cannot be handed a URL, so it spawns the endpoint over stdio
 instead. That one is named in the client's own config file rather than registered
-by a command, as `lanes link mcp stdio --profile <name> --target <name>`; both
+by a command, as `lanes link mcp stdio --profile <name> --workspace <name>`; both
 flags are required, and nothing may be written to stdout.
 
 ## When it is not running
 
-`lanes link start --profile <name> --target <name>` runs in the foreground and
+`lanes link start --profile <name> --workspace <name>` runs in the foreground and
 serves until stopped. Tell the
 user the command rather than backgrounding it silently on their behalf.
 Registration works while it is down — the harness simply cannot reach it yet,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lanes-sh/link",
-  "version": "0.7.1",
+  "version": "0.8.0",
   "description": "A self-hostable MCP gateway for all your connections, memory, tasks, files, and secrets",
   "license": "Apache-2.0",
   "homepage": "https://lanes.sh/link",
@@ -61,6 +61,7 @@
     "#audit": "./src/audit/index.ts",
     "#audit/*": "./src/audit/*",
     "#auth": "./src/auth/index.ts",
+    "#auth/*": "./src/auth/*",
     "#cli/*": "./src/cli/*",
     "#connectivity": "./src/connectivity/index.ts",
     "#connectivity/*": "./src/connectivity/*",

package/src/audit/index.ts

@@ -58,11 +58,18 @@ export interface AuditEvent {
   readonly principal: string;
 
   /**
-   * The MCP `clientInfo` name, when the caller supplied one.
+   * The MCP `clientInfo` name, when the caller repeated it on the request.
    *
    * OBSERVABILITY ONLY. This is self-reported by the client and is never
    * consulted for authorization — it exists so you can see which agent made a
    * call, not to decide what that agent may do.
+   *
+   * "On the request" is load-bearing and was wrong for this field's whole life:
+   * it claimed to hold the `clientInfo` name and read an `x-mcp-client` header
+   * that no MCP client sends, so it was empty on every event ever written. The
+   * name arrives in the request envelope now (`mcp/client-info.ts`). A client
+   * that announces itself only at `initialize` and never repeats it is still
+   * anonymous here, which is the honest answer rather than one inferred.
    */
   readonly clientLabel?: string;
 

package/src/auth/index.ts

@@ -28,13 +28,61 @@ import type { SecretRef, SecretStore } from '#secrets';
 export interface Principal {
   readonly id: string;
   readonly profile: string;
-  readonly kind: 'owner';
+  readonly kind: 'owner' | 'member' | 'machine';
+  /**
+   * Every profile this caller may reach, or `undefined` for "all of them".
+   *
+   * `undefined` is the machine token and the stdio pipe: neither is a person,
+   * both reach the whole workspace, and saying so explicitly is better than
+   * enumerating a list that would then need keeping in step. A `member` always
+   * carries a list, because the list *is* the delegation (ADR-060).
+   */
+  readonly profiles?: readonly string[] | undefined;
 }
 
 export function ownerPrincipal(profile: string): Principal {
   return { id: `${profile}:owner`, profile, kind: 'owner' };
 }
 
+/**
+ * A person, and the profiles whose `members:` name them.
+ *
+ * `profile` carries the one this call is acting within, which is what the audit
+ * log records and what policy is evaluated against. `profiles` is the whole set
+ * they may choose from, and `mayReach` is the check — kept here rather than in
+ * the dispatcher so discovery and enforcement cannot answer it differently,
+ * which is the same rule `allowedConnections` follows on the capability axis.
+ */
+export function memberPrincipal(
+  subject: string,
+  profile: string,
+  profiles: readonly string[],
+): Principal {
+  return { id: subject, profile, kind: 'member', profiles };
+}
+
+/**
+ * The same caller, acting within a different profile.
+ *
+ * An endpoint serves several profiles and a principal is built once, from the
+ * primary — so the profile on it is where the *connection* was opened, not
+ * where this call is going. Every dispatch has to say which, because
+ * `principal.profile` is what the audit event records and what `mayReach` is
+ * checked against; without this the log attributes a member's call to a profile
+ * they may never have been able to reach.
+ *
+ * It does not widen anything. `profiles` carries over untouched, so a name this
+ * caller may not reach is still refused — one step later, by the check below.
+ */
+export function forProfile(principal: Principal, profile: string): Principal {
+  return principal.profile === profile ? principal : { ...principal, profile };
+}
+
+/** Whether this caller may act within the named profile. */
+export function mayReach(principal: Principal, profile: string): boolean {
+  return principal.profiles === undefined || principal.profiles.includes(profile);
+}
+
 export type AuthOutcome =
   | { readonly ok: true; readonly principal: Principal }
   | { readonly ok: false; readonly reason: 'missing' | 'malformed' | 'invalid' | 'not_configured' };
@@ -215,7 +263,15 @@ export {
   type ChallengeError,
   type ResourceIdentity,
 } from './oauth/metadata.ts';
-export { OAuthServer, pkceChallengeFor, type AuthorizeRequest, type OAuthResult } from './oauth/server.ts';
+export {
+  OAuthServer,
+  pkceChallengeFor,
+  type EndpointIdentity,
+  type Federation,
+  type OAuthResult,
+} from './oauth/server.ts';
+export { AssertionVerifier, type Assertion } from './lanes/assertion.ts';
+export { lanesFederation, DEFAULT_WEB_URL, type FederationOptions } from './lanes/federation.ts';
 export { matchesRegistered } from './oauth/redirects.ts';
 export { OAuthStore, hashToken, randomToken } from './oauth/store.ts';
 export { OidcVerifier, type OidcVerifierOptions, type VerifiedSubject } from './oidc.ts';