@zackbart/connecta 0.38.0 → 0.39.0

package/documentation/meta-tools.md

@@ -49,7 +49,12 @@ write tools from `search_tools` results and describe, and refuses every write
 call. Connector `readOnly` applies the same restriction on every endpoint; effective read-only is endpoint OR connector. Neither setting changes connector visibility or read grants. Guides
 (`queryAnalysis.guideSummary`, `skills`, `connecta.skill`, skill
 `resources/read`) are documentation and may name tools the endpoint refuses. The four tools with structured-only success results
-advertise `outputSchema`. The two direct-call tools omit it because their default
+advertise `outputSchema`. `search_tools`'s schema defines its typed failure,
+including every authorization-handoff field, once under `$defs.failure`;
+`catalogErrors[]` references it through `allOf` with `connector` required, and
+`queryAnalysis.catalogError` references it directly. The schema declares no
+`$schema`, and validators for drafts 4, 7, 2019-09 and 2020-12 accept the same
+pages. The two direct-call tools omit it because their default
 mode returns native `content`. Default-mode successes declare
 `_meta["dev.connecta/format"]: "json" | "text"`; value mode places the value in
 `data` and declares `format` in its complete result envelope.
@@ -134,16 +139,25 @@ Live connector probing is not a fourth: the operator pages and `/health` own it.
 
 ## Discovery context
 
-The deployment-derived `execute_code` description carries a live connector
-inventory before any catalog search — registry order, each canonical id, and a
-distinct configured title, with no second name minted for programs. Titles
-normalize whitespace and cap at 48 UTF-8 bytes, the complete line caps at 256,
-entries stay whole, and a truncated line ends with the exact `+N more` count, so
-account and environment hints cannot eat the inventory. It reads only the
-configured registry: no catalog load, no credential probe, no capability, and no
-replacement for canonical discovery or addressing. Program search results carry
-the same bounded `connectorTitle` per tool, so choosing an account or
-environment costs no provider read. The inventory does not probe live access.
+The deployment-derived `execute_code` description carries a connector
+inventory before any catalog search — registry order and each canonical id,
+with no second name minted for programs. An entry adds the configured title
+only when it says more than the id: a title whose words the id already spells,
+such as `Google Calendar` for `google_calendar`, is dropped. Titles normalize
+whitespace and cap at 48 UTF-8 bytes. A connector with a guide says how to
+fetch it: `read first: skills({name:"connector:<id>"})` for a required guide,
+`guide: skills({name:"connector:<id>"})` otherwise. For example:
+`Connectors: crm (Customer CRM; read first: skills({name:"connector:crm"})), tickets.`
+
+The complete line caps at 1,024 UTF-8 bytes, which names every connector of a
+typical deployment. Past the cap, detail degrades before names do: titles are
+dropped first, then optional guide pointers. Only when bare ids and required
+guide pointers still exceed it do whole entries give way, in registry order, to
+an exact `+N more` count. The inventory reads only the configured registry: no
+catalog load, no credential probe, no live status, no capability, and no
+replacement for canonical discovery or addressing. Search pages carry the same
+bounded title once per connector in `connectors[<id>].title`, so choosing an
+account or environment costs no provider read.
 
 Read-only lookup belongs in `connecta.search` inside the program; top-level
 `search_tools` stays for explicit catalog inspection and approval-required
@@ -171,6 +185,56 @@ read/write filter. On `approvalRequired` searches the returned discovery tool
 is still a read. Hidden tools, missing grants and read-only restrictions remain
 in force. Browsing does not consult operation vocabulary.
 
+When a matched operation's call is fully determined, the first page also
+carries it in `readyCalls`, so a program can call it without operation search or
+details:
+
+```json
+{
+  "readyCalls": [
+    {
+      "address": "notes.notes_api_read",
+      "args": { "path": "/v1/notes" },
+      "classification": "read",
+      "summary": "List notes"
+    }
+  ]
+}
+```
+
+Pass `args` unchanged to `connecta.call(address, args)` or `call_tool`. An
+operation is fully determined only when it is a reviewed read served by the
+hatch's `_api_read` tool itself (no named tool), uses GET, the read tool's
+default method, and declares no path template, required parameter or required
+body. Anything needing an id, a method choice or an argument the agent must
+fill in stays behind `_api_search` and `_api_details`. Ready calls pass the same
+endpoint, connector read-only, safety, hidden-tool and grant checks as the
+vocabulary match, through a visible read tool in the caller's view. They are
+computed offline from the construction-time index, read no account data, and
+start no authorization.
+
+A ready call must also be what the query names. Each path segment, and the
+operationId without its action and version words, is one whole resource name:
+`event_destinations` is the name "event destination", never "event". Every
+query word other than an action (`list`, `get`, `count`, `show`, `create`,
+`update`, `delete` and their vocabulary aliases) must belong to a resource name
+whose words the query states in order, with singular/plural normalization and
+the provider's declared synonyms. Version segments such as `v1` never count, and
+a summary may supply only actions. A query with no object word gets no ready
+call. Ready calls are omitted entirely when the top result is an exact tool name
+or address, or a complete match on an authored tool, not the hatch's own search
+or read tool, whose name adds nothing to the query: each of its name words is an
+action or a query word, up to plural/singular and declared synonyms. For
+example, `list teams` returns `list_teams` and no ready call, even when other
+operations mention teams in their summaries, while `list projects` still offers
+`/v10/projects` beside `list_project_env_vars`, whose name adds `env` and `vars`.
+Each hatch offers only its top-ranked operation: a last path segment naming the
+resource first, then the fewest resource words the query did not ask for, then
+the shortest path. A connector offers at most one ready call and a page at most
+three, in connector order. Later pages carry none. A ready
+call keeps its read tool's `guideRequired` and `guideRequiredReasons`, and its
+connector appears in `connectors`.
+
 Vocabulary is bounded: queries at most 200 characters and eight terms; each
 hatch caches at most 8,192 rows and 2,097,152 characters, with at most 1,024
 characters per row and 128 query intersections. Longer queries and vocabulary
@@ -281,9 +345,11 @@ guide's first meaningful body paragraph. `required: true` is reserved for
 generic API wrappers and cross-operation conventions a complete downstream
 schema cannot express.
 
-Search and describe results carry a `guide: "connector:<id>"` pointer and a
-`guideSummary`. A matching tool also carries `guideRequired: true` and
-`guideRequiredReasons` when Connecta can prove review is necessary:
+Describe results carry a `guide: "connector:<id>"` pointer and a
+`guideSummary`; a search page carries both once per connector in
+`connectors[<id>]`. A matching tool row or description also carries
+`guideRequired: true` and `guideRequiredReasons` when Connecta can prove review
+is necessary:
 
 | Reason               | Raised by                            | Survives exact schema expansion                          |
 | -------------------- | ------------------------------------ | -------------------------------------------------------- |
@@ -297,8 +363,17 @@ is merely told to fetch the guide first, for any reason listed. Otherwise the
 bounded summary decides — connector-specific sequencing, units, pagination,
 aliases, and generic API conventions still need the guide when they affect the
 task, while a complete and unambiguous one-read schema proceeds directly. Guide
-lookup always uses an exact name returned by `skills({})`, search, or describe;
-callers never manufacture `connector:<id>` from an unmarked connector.
+lookup uses an exact name returned by `skills({})`, search, describe, or the
+`execute_code` inventory; callers never manufacture `connector:<id>` from an
+unmarked connector. A bare connector id, such as `skills({ name: "crm" })` or
+`connecta.skill("crm")`, also serves that connector's guide. Built-in skill
+names stay reserved: `usage` and `investigate` always fetch the built-in skill,
+even when a connector has that id, whose guide stays at `connector:usage` or
+`connector:investigate`. A bare id naming a connector without a guide fails with
+`Connector "<id>" has no usage guide.`; any other unknown name fails as an
+unknown skill. Names containing `:`, including URIs, never fall back to a bare
+id. MCP `skills/get` resolves names the same way; `resources/read` accepts only
+document URIs.
 
 A connector-scoped lexical miss keeps that connector's guide metadata under
 `queryAnalysis`. This matters for generic wrappers whose broad tool name
@@ -307,12 +382,29 @@ disappearing with the zero-tool page.
 
 Two built-in skills are byte-identical across deployments. `usage` is fetched
 only for missing guidance or program repair, and owns program selection detail, examples, runtime
-differences, and repair guidance; `investigate` is on-demand guidance for
-purchase verification, experiment checks, and customer or deployment
-investigations — shared guidance, not a saved workflow and not a source of
-deployment-specific ids. The always-loaded instructions and tool definitions keep
+differences, and repair guidance; `investigate` is domain-neutral on-demand
+guidance for an investigation that spans several services — shared guidance,
+not a saved workflow and not a source of deployment-specific ids. `skills`
+lists it; the `execute_code` description does not advertise it. The always-loaded instructions and tool definitions keep
 route selection, the fail-closed boundary, and the minimum guest syntax, so a
 client that never fetches a skill can still write a valid first program.
+
+The server instructions state the complete routing rule once. Some clients
+drop server instructions, so each tool description stays sufficient for its own
+correct use without restating that rule: `call_tool` names its scope (one
+known-address read) and points other read work to `execute_code`;
+`search_tools` names its scope (catalog inspection, or finding a write) and
+points read work into a program; `execute_code` opens with the terse
+three-route lead (`One known read: call_tool. One known write:
+call_destructive_tool. Everything else: execute_code.`, or the read-only
+two-route form). The `usage` skill points to those two sources instead of
+repeating them.
+
+Tool descriptions and output schemas carry deployment configuration only: the
+connector inventory, budgets, the endpoint's read-only setting, and whether any
+visible connector has a guide. No catalog outcome, call, authorization state,
+or other live status reaches `tools/list` or the instructions, so the
+always-loaded surface stays byte-stable for a client's prompt cache.
 The instructions are the same on every endpoint except one addition: at
 `/mcp/<pool>` and `/agent/<pool>`, a pool that sets a
 [`description`](./auth.md#pools) has it appended after `This endpoint: `, so
@@ -618,7 +710,7 @@ a fixed warning without storage error prose. Never repeat a write to recover out
 page. Select tool rows from `page.tools`.
 With the same schema format, schema-key option, and scoped registry, both paths
 return identical data. Top-level search omits schemas unless requested; programs
-default to JSON schemas and schema-key metadata.
+default to TypeScript signatures and schema-key metadata.
 
 ```json
 {
@@ -627,12 +719,12 @@ default to JSON schemas and schema-key metadata.
     {
       "name": "get_ticket",
       "address": "tickets.get_ticket",
-      "connectorTitle": "Tickets",
       "classification": "read",
       "schemaFormat": "json",
       "inputSchema": { "type": "object", "properties": { "id": { "type": "string" } }, "required": ["id"] }
     }
   ],
+  "connectors": { "tickets": { "title": "Tickets", "guide": "connector:tickets", "guideSummary": "Ticket ids and states." } },
   "total": 1,
   "offset": 0,
   "limit": 8,
@@ -652,8 +744,26 @@ and connector id, never connector-supplied error text. Other failures retain
 `retryAfterMs`. A scoped search also keeps its bounded failure subset under
 `queryAnalysis.catalogError` for clients that already use it.
 
-Tool rows carry the address, configured display title when present, guide and
-guide summary when available, and stored classification. Requested schemas have
+An unscoped search gives each connector at most 5 seconds (or
+`discovery.probeTimeoutMs` when shorter) and ends within a 9-second discovery
+budget. A connector that recently timed out or failed slowly is skipped for up
+to 60 seconds: its entry keeps the recorded code with `retryable: true`,
+`retryAfterMs`, and the message `Connector "X" was skipped because its catalog
+lookup failed recently (CODE). Search with connector "X" to try it now.` A
+scoped search always probes. Records are kept per owner, admitted endpoint and
+described connector configuration. A healthy connector whose catalog always
+takes more than 5 seconds can stay out of unscoped search; search it with
+`connector`, or let any longer-deadline operation warm its complete catalog.
+See [Discovery health](./architecture.md#storage-credentials-and-connectors).
+
+Tool rows carry the address, stored classification, and tool-specific
+`guideRequired` and `guideRequiredReasons`. Facts shared by every row of one
+connector appear once per page in `connectors`, keyed by the connector id that
+prefixes each row's address: the configured display `title` when present and
+`guide` and `guideSummary` when the connector has a guide. The map names only
+connectors with a row or ready call on this page and is omitted when none has
+such facts.
+Requested schemas have
 `schemaFormat: "json"` for JSON Schema values or `schemaFormat: "text"` for
 compact schema strings and TypeScript signatures. Compact schemas are text;
 `inputSchema.properties` is meaningful only in JSON mode. Pagination counts
@@ -666,7 +776,19 @@ rare domain terms above ubiquitous action terms. Exact tool names and canonical
 addresses rank first, so `get_issue` beats `get_issue_status` even when a
 connector is named `issue`. Exact configured connector IDs, full display titles,
 and recognized service names rank next. Complete lexical matches then precede
-partial matches, with score and catalog order breaking ties.
+partial matches. Within a tier, a query whose first word outside connector names
+is `list`, `get`, `find`, `search`, `show`, `read`, `fetch`, or `count` ranks
+read rows before write rows; writes stay on the page. Score and catalog order
+break the remaining ties.
+
+A maintained provider may declare `searchSynonyms`: groups of single lowercase
+words its users and its vendor use for the same record, such as `household`
+and `family` for Church Community Builder. A query word then matches that
+provider's tools and operation vocabulary through any word in its group, as an
+ordinary whole-token match ranked below the word itself. Synonyms never widen
+another connector's matches. Church Community Builder declares
+`person`/`individual` and `household`/`family`; Granola declares
+`meeting`/`note`.
 An exact connector ID or title query browses that connector's tools, even when
 individual tool names or descriptions mention that identity. Connector identity
 terms that never occur in its tools need not be repeated in every tool description.
@@ -1027,28 +1149,77 @@ A remote MCP tool's advertised `inputSchema` is checked in the shared invocation
 path before admission and provider dispatch, so a mismatch is the non-retryable
 `invalid_args` identically on `call_tool`, `call_destructive_tool`,
 generated-code failures, and rejected promises. The error names the connector and
-operation and carries `validation.issues`: JSON Pointer `path`, schema-keyword
-`code`, and expected shape, with submitted values never copied into a finding. At
-most three are returned, and `validation.truncated` says when more exist — the
-same three-item bound describe's nearby-address list uses.
+operation and carries one recovery envelope, `validation`:
+
+```json
+{
+  "issues": [
+    { "path": "/limit", "expected": "at least 5", "received": "4" },
+    { "path": "/mode", "expected": "one of \"fast\", \"safe\"", "received": "string" },
+    { "path": "/<key>", "expected": "one of the accepted keys: mode, limit" }
+  ],
+  "acceptedKeys": ["mode", "limit"],
+  "example": { "mode": "fast", "limit": 5 }
+}
+```
+
+Every finding is listed, and the message repeats them, so one corrected call
+fixes them all.
+
+A refusal contains only names and literals the published schema declares at
+non-sensitive positions, numbers allowed by the bound rule below, and fixed
+placeholder text. It never contains a submitted string or object key, in the
+message, a finding, `acceptedKeys` or the example. A position is sensitive when
+it or an ancestor is `writeOnly`; a named tool's input schema marks each request
+secret that way. API hatch findings name only the operation contract's
+properties and enum members, as `*_api_details` publishes them.
+
+- `path` is a JSON Pointer naming declared properties and array indices. The
+  first key the schema does not declare (a misspelled argument, a map key)
+  reads `<key>` and ends the path, e.g. `/headers/<key>`.
+- `expected` states the constraint that failed, then every other constraint
+  the position declares: bounds, property and item counts, `multipleOf`,
+  `pattern`, `format`, `uniqueItems`, enum members, `dependentRequired`
+  (`string (required with tags)`). A sensitive position never renders an enum,
+  `const` or pattern literal. Each position gets one finding.
+- `received` is the submitted JSON type, `missing`, or, for a numeric bound at
+  a non-sensitive position of a named tool, the submitted number.
+
+At most eight findings are returned, each field clipped (path and expected 256
+characters, received 64), and `truncated: true` says something was omitted or
+clipped.
+
+`example` is one valid call synthesized from the published schema and checked
+against the same validator. It never copies a submitted value, and a sensitive
+position never renders a schema literal (`enum`, `const`, `default`,
+`examples`). Complex or unsatisfiable schemas get `exampleUnavailable` instead.
+Synthesis detects recursive references and shares a 128-node work budget.
+Invocation uses only this schema example, never a connector's copy of the
+call, unless the connector states `exampleUnavailable`. API hatches
+(`*_api_read`, `*_api_write`) always do: their generic schema says nothing
+about an operation's arguments, so the reason points to the operation's
+`*_api_details`.
+
+`acceptedKeys` names the tool's top-level arguments. `conditionalRequirements`
+lists known `dependentRequired` and `dependentSchemas` requirements by
+property name; `if`/`then`/`else` conditions are schema subtrees and are not
+rendered. The envelope has a 4 KiB budget:
+optional detail, then the example, then trailing findings are dropped whole,
+with `truncated: true`. A `repair` object a custom connector passes contributes
+its received types and schema facts. A custom connector's own findings must
+follow the same rule. Operator records contain only checked failure facts,
+never findings or examples.
 
 `nextAction` points to discovery scoped to the same connector and tool name when
 the compact schema is needed, routed like any other miss: a program to
 `connecta.search`, a top-level call to `search_tools`. `retry` says to correct
-the listed arguments and reissue the original operation. Which keyword a finding
-names, and what the local validator declines to evaluate, is
-[code mode](./code-mode.md#errors)'s `E8`.
-
-`repair` adds agent-only detail from that tool's published schema: accepted
-keys, received JSON types, enum values, numeric/length/item bounds, and known
-conditional requirements such as `dependentRequired` and `if`/`then`/`else`.
-Its `example` is synthesized without submitted values and checked against the
-same validator. Complex or unsatisfiable schemas get `exampleUnavailable`
-rather than an invalid example. Synthesis detects recursive references and
-shares a 128-node work budget. Alternative branches do not emit dependency
-advice unless the branch condition is known. Repair detail has a 4 KiB budget; oversized
-detail is withheld whole with `truncated: true`. Operator records still contain
-only checked failure facts, never findings or examples.
+the listed arguments and reissue the original operation. What the local
+validator declines to evaluate is [code mode](./code-mode.md#errors)'s `E8`.
+
+Earlier releases returned `validation.issues[].code` (the schema keyword)
+and a separate `repair` object. Both are gone from responses; a custom
+connector may still pass `code` and `repair` to `ConnectorCallError`, which
+folds `repair` into `validation`.
 
 Unknown-address errors list `configuredConnectors` from the current endpoint's
 scoped registry, including an empty list when none are accessible. They never
@@ -1146,7 +1317,9 @@ its code and message for diagnostics but is `retryable: false` with
 a program's `writes.unknown`. An HTTP refusal of the call's own write stays
 known only under the refusal rules above and a complete ledger proving the
 refusal covers the whole call; its recovery advice and program accounting both
-report failure. Partial or unknown ledgers remain conservative. An auth failure after entering a write with
+report failure. A `remoteMcp()` write answered with a 4xx (other than 401, 403,
+408 or 429) whose body is not a JSON-RPC error is unknown, never a refusal: a
+gateway may have answered after the server acted. Partial or unknown ledgers remain conservative. An auth failure after entering a write with
 no call-owned dispatch reports an unknown outcome and requires reconciliation,
 including credential refusals, static-OAuth refresh failures, and `remoteMcp()`
 connect or initialize 401s before `tools/call`. A non-auth refusal before
@@ -1311,7 +1484,7 @@ window, a native `tools/list` carries a 300-second private cache hint, against
 an hour on meta endpoints. This hint does not guarantee that a host refreshes
 its cached annotations; the stale-approval race is accepted on writable pools.
 
-**Listing.** `tools/list` is one page with no cursor (Eve 0.86 reads only the
+**Listing.** `tools/list` is one page with no cursor (Eve 0.90 reads only the
 first page). A pool listing more than 1,000 tools fails `tools/list` with a
 JSON-RPC error asking the operator to narrow the pool; nothing is silently
 dropped. A connector whose catalog cannot load is left out of that listing
@@ -1328,7 +1501,8 @@ never repeat a write; page a truncated result as its notice says. A pool
 **Recovery.** Repair and validation fields retain the exact constraint details.
 Discovery `nextAction` points to the host's tool search (`host: "search"`), with
 only a `query` argument. Retry actions and retry text name the native tool,
-never a meta wrapper. Auth actions carry `authorizationUrl` or `operatorUrl`;
+never a meta wrapper; a program on a native pool sees the same native wording
+in a failure it catches. An unknown name is reported as sent. Auth actions carry `authorizationUrl` or `operatorUrl`;
 give the returned URL and instructions to the user or operator. Capable modern
 clients may resume native auth and downstream form/URL input with the same
 wire name, arguments and returned `requestState`. Changed names, targets or

package/documentation/migration-0.33.md

@@ -40,6 +40,10 @@ the sections in order, then [verify](#verify).
 | `DELETE /ui/credentials/<id>` on an empty slot answering 204                          | 409 `{ "problem": "credential_required" }`                                                                                              |
 | The `agent_not_maintainer` denial reason                                              | Removed; agents are refused at human endpoints before admission                                                                         |
 
+This guide records the 0.33 migration. Current versions require every pool to
+list only people or only agents. If a 0.33 deployment combined them, follow
+[Split mixed pools](./pool-membership-upgrade.md) as well.
+
 ## Maintainers and pool members
 
 0.32 combined an identity resolver, a top-level `grant`, and pool `grant`
@@ -349,4 +353,4 @@ pools: {
    absent: search finds none of their tools and a call fails
    `unknown_address`. The same holds in any pool without an owner, even one
    that lists a Workspace connector with a subject mapping.
-6. Confirm each `<agent>-<user>` pool lists no other person in `members`.
+6. Confirm each `<agent>-<user>` pool lists only the agent in `members` (the current construction rule).

package/documentation/migration-0.34.md

@@ -39,7 +39,9 @@ If an agent needs to act as Alice, put that access in her personal pool and set
 to use. Confirm the pool's tools and members before adding an owner. Follow
 [the agent pool layout](./auth.md#organizing-an-agents-pools) for the full
 configuration. People in the same pool, agents in owned pools and connectors
-with a fixed `subject` address keep their behavior.
+with a fixed `subject` address keep their behavior. Current versions also
+require each pool to list only people or only agents; see
+[Split mixed pools](./pool-membership-upgrade.md).
 
 ## Optional settings and development tooling
 

package/documentation/operator-tests.md

@@ -24,7 +24,7 @@ committed through the deployment's own store, so the contract's `agents` and
 last seen are fixed. The restricted state is the member fixture from
 `test/fixtures/operator-contract-v2.ts`, and the endpoint and matrix variants
 use its maintainer fixture, which covers every runs-as kind and agent pools,
-with `test/fixtures/operator-console.ts` crowding the team pool so its avatar
+with `test/fixtures/operator-console.ts` crowding the people-only team pool so its avatar
 stack collapses to "+3".
 Collections use their corresponding browser types. Real contract serialization,
 member projection and secret withholding are exercised through

package/documentation/operator-ui.md

@@ -113,6 +113,12 @@ Pool endpoint rows show the effective surface (`meta` or `native`) and whether
 code is on. These are read-only facts from deployment configuration; change
 `surface` and `executeCode` in deployment code.
 
+Plain `/mcp` is routed by sign-in: the `/mcp` row and matrix column show the
+whole catalog maintainers receive, and a pool row shows what its people
+receive at both `/mcp/<pool>` and, when they belong to no other pool, plain
+`/mcp`. A note above the rows says so. People in several pools appear in
+`config.peopleInSeveralPools`; plain `/mcp` refuses them.
+
 One row each for `/mcp` and every pool: the path, a read-only pill on a
 read-only endpoint, a copyable URL, who can use it, its connectors as colored
 monograms (four, then "+N"), its tool count over a read and write bar, and a
@@ -121,7 +127,9 @@ Setup button.
 - Who can use it is `root.maintainers` on `/mcp` and the pool's `members`
   elsewhere, as an avatar stack named on hover and to screen readers (label,
   raw id when the label is null, or agent name). Four show, then a "+N"
-  button. A pool with agent members labels its two URLs People and Agents.
+  button. A pool lists only people or only agents. An agent pool's row
+  still shows two URLs labeled People and Agents; the People URL
+  (`/mcp/<pool>`) admits no one, because the pool has no people.
 - Expanding a row lists everyone by name, then each connector with what it
   runs as and its tools, write tools amber with a pencil. Runs-as comes from
   the endpoint's matrix cell: "Shared · saved <date>", "Shared · connected
@@ -194,8 +202,9 @@ tabs:
   annotation badges (Destructive, Open world), filtered by search and All,
   Read and Write. A tool opens its schema in a side drawer.
 - **Connection.** An Authentication card (mode, OAuth client mechanism, who
-  manages it, OAuth actions, and the credential card with masked last four,
-  field states, and Replace, Test and Remove); a Diagnostics card of tiles
+  manages it, the last verification, OAuth actions, and the credential card
+  with masked last four, field states, and Replace, Test and Remove); a
+  Diagnostics card of tiles
   (catalog age and last call) with a fix prompt beside each
   problem; and a Configuration card. Its badges name the kind (Remote MCP,
   HTTP API or Custom), provider, auth scope, endpoint host and usage guide.
@@ -340,10 +349,12 @@ connections**, has no tabs; its heading shows the signed-in email when the
 sign-in exposes one (Clerk's primary email), and its top bar shows branding and
 an **Account** button with Sign out or Change token. It lists:
 
-- **Your endpoints**: one card per admitted `/mcp/<pool>` URL with a copy button
-  and **Client setup**. For example, Bob in pool `team` copies
-  `https://connecta.example.com/mcp/team` into an MCP client and authenticates
-  as Bob.
+- **Your endpoints**: one card per address with a copy button and **Client
+  setup**. A member of exactly one pool sees one card for plain `/mcp`, named
+  after the pool it serves; a member of several pools sees one
+  `/mcp/<pool>` card per pool. For example, Bob, only in pool `team`, copies
+  `https://connecta.example.com/mcp` into an MCP client and authenticates as
+  Bob.
 - **Your accounts**: the personal connectors in their pools, each with a
   monogram, tool count, one status badge in an aligned column, and only the
   controls its `manage.actions` lists. A saved credential that no longer fits
@@ -415,7 +426,8 @@ without this capability contribute an unconfirmed count of zero. For example,
 The maintainer view carries:
 
 - `config`, the construction-time `describeConfig()` snapshot, including
-  `maintainers` and each pool's `members`, and `configSources`, which labels
+  `maintainers`, each pool's `members`, `peopleInSeveralPools` (non-maintainer
+  people plain `/mcp` refuses because they are in several pools), and `configSources`, which labels
   each serialized leaf as `default` or `config` from option presence rather
   than equality with the default. Factory descriptions carry relative
   `optionSources` paths so resolved module and transport defaults retain their
@@ -488,7 +500,9 @@ The maintainer view carries:
 The member view is exactly that member's projection: `config`,
 `configSources` and `root` are `null`, `live.connectors`, `agents` and
 `matrix` are empty, and `live.activity` is `"forbidden"`. `pools` lists only
-their pools, each with `owner: null` and `members: []`. `connectors` lists
+their pools, each with `owner: null` and `members: []`. With exactly one pool,
+its `humanPath` is `/mcp`, the address that serves them that pool, and the
+member's catalog reads carry that pool as plain `/mcp` would. `connectors` lists
 each connector in those pools with its title, the member's pools that serve
 it, its auth scope, the tools those pools grant with their classification,
 `connection` (their own partition's state and problem code for a personal
@@ -556,6 +570,58 @@ the config snapshot, and never treats a `per_caller` overlay as an error.
 complete classified tools with input/output schemas, registration path, catalog
 age, and activity-derived last-call facts under the reader's disclosure policy.
 A failed or timed-out connector releases its own scope; siblings finish independently.
+The status and catalog observation has its own deadline: 8 seconds, or
+`discovery.probeTimeoutMs` when that is shorter, in which case the whole row
+uses that one deadline. The 8-second value is fixed, not configured; agent
+discovery keeps the full `discovery.probeTimeoutMs`. When the deadline ends
+first, the downstream read is aborted and the row returns `status: "error"`
+with `problem: "connector_timeout"` in the row and its overlay. The row still
+carries its credential card and auth permissions, so a slow connector's slot
+stays manageable. Any other failure keeps `connector_unavailable`. The
+connector renders as **Not responding**, with fixed copy, a fix prompt and
+Refresh.
+**Stored status.** Each live `GET /ui/connectors/:id` records one status
+observation for that connector and viewer partition before it answers: its
+state, problem code, tool count and observation time. Authored static catalogs
+such as `api()` connectors are recorded too, since their status still checks
+auth. The record lives in the `connector-health:v1:` family under the same
+owner partition as the catalog cache (principal, subject, caller identity and
+pool, endpoint, described configuration and package version), so a personal
+connector's observation is one person's. It also carries the catalog
+generation read before the probe, through the request's read memo that the
+catalog listing reuses. It holds no tools, schemas, status prose or
+credential facts. It expires 120 seconds after it was observed, and lapses at
+once when a credential change, OAuth connect or disconnect, or invalidation
+rotates the generation. A read that ends at the row's own deadline, including
+a configured `discovery.probeTimeoutMs` shorter than 8 seconds, records
+`connector_timeout` before it answers. An observation is written only while
+the caller is still waiting: a request its caller has already left starts no
+write. A write that has started is never raced against a deadline or
+detached, because a storage write cannot be withdrawn once sent. The request,
+whether it times out or its caller leaves meanwhile, settles only after that
+write does, bounded by the storage layer like every other awaited write, so
+nothing commits after the request ends.
+
+`GET /ui/connectors/:id?observation=stored` answers from a current observation
+without probing the downstream. The row and overlay carry `observedAgeMs`, the
+stored `status`, `problem` and `toolCount`, and `tools: []`; the tools stay in
+the catalog cache. The credential card, drift, permissions and any
+authorization link are computed fresh on every request. Without a current
+observation the route does the live read and records it, with no
+`observedAgeMs`. Nothing is refreshed after the response: no deferred work and
+no `ctx.waitUntil`.
+
+The browser asks each connector for its stored observation on the page load
+that follows admission, and fixes the observation time once as each stored
+row lands. The list card and the connector page mark a stored row the same
+way, "Stored status, checked … ago", with an age that keeps counting, and
+show its tools as awaiting the live read rather than as none. The browser then
+sends one plain live read per stored row, through the same queue of eight
+detail reads. A stored `connector_timeout` row is not read again on its own;
+its mark says to Refresh, and it waits for Refresh like a live timeout.
+Refresh, a single connector's read, recovery retries and OAuth polls always
+read live.
+
 The summary and each detail carry `viewerKey` for the principal admitted to that
 request. The browser publishes the detail and overlay atomically only when that
 key matches admission. A changed viewer key, including an Access switch between
@@ -568,7 +634,7 @@ screen. The first answer for the new viewer triggers readmission, which clears
 everything retained.
 Config observations never
 overwrite a completed detail row. Each connector opens at most one live observation
-per page load; the summary `/ui/data` performs no downstream probes.
+per page load, after its stored read; the summary `/ui/data` performs no downstream probes.
 
 `GET /ui/api/config?connector=<id>` narrows the same contract to one connector
 before status and catalog probes. For a maintainer, config, provenance, live
@@ -628,8 +694,23 @@ bounded at 2, 2, 4 and 8 seconds; a later focus return can try again after backo
 
 Connector Refresh, focus recovery and mutation follow-ups read only affected
 connectors. Focus probes unhealthy rows, never healthy siblings. All detail reads
-share a four-request limit and coalesce per connector. Failures retry only their
+in one tab share an eight-request limit and coalesce per connector, so a page of
+up to eight connectors loads in one round. The limit is fixed, not configured.
+It bounds how many connectors one tab waits on at once; a tab still reads each
+connector once per load, so the limit adds no requests to any one connector.
+Detail reads do not consume `admission.requests` permits, which govern `/mcp`
+only. They still share isolate CPU and memory, D1, and downstream account quotas
+with agent traffic; each tab adds up to eight concurrent downstream reads, and
+several connectors on one vendor account share that vendor's rate limit. Over HTTP/1.1 the browser itself allows about six
+connections per origin.
+Failures retry only their
 connector with the same bounded backoff; recovery never replays a mutation.
+A `connector_timeout` row is parked instead. It spends its automatic retry
+budget, and focus and visibility returns skip it. Only Refresh, a full refresh
+or a mutation follow-up reads it again, so an outage holds a detail slot once
+per explicit request, never repeatedly. An OAuth start's consent-return poll is
+the exception: a timeout during its 30-second window keeps polling, and success
+still stops it.
 Mutations cancel affected reads and advance their publication fence both at
 dispatch and on settlement, including failure. Follow-ups require an observation
 started after settlement, so a Refresh or retry started during the write cannot
@@ -638,9 +719,21 @@ while identity and full refresh revisions fence the complete view. An explicit
 OAuth start polls only that connector every two seconds for up to 30 seconds.
 Concurrent authorizations retain independent cancellation and publication. Success,
 failed reads, disconnect, navigation, unmount and identity reset stop the matching
-poll. Recovery never starts authorization. A scoped result cannot confirm identity,
+poll; a `connector_timeout` result does not. Recovery never starts authorization. A scoped result cannot confirm identity,
 role, token slots or any other deployment-wide admission fact.
 
+A credential connector's `/ui/data` and `/ui/connectors/<id>` row carries
+`verification: { outcome, observedAt }` when a record of the stored save
+exists (see [last verification](./auth.md#test-then-save-and-last-verification)).
+The auth facts show it as **Last verified**: Verified, Saved without a test,
+Rejected, Missing permission, Service unreachable, Test timed out or Test
+failed, with its time. A maintainer's credential form on a testable connector
+saves through **Test and save** (`verify: "test"`). A failed test leaves the
+form open with fixed copy for its failure class, and adds **Save without
+testing**, a save without `verify`. Test shows the same per-class copy and reloads
+the connector so its last verification updates. The member page's
+credential form saves without a test and offers Test once a value is stored.
+
 Unreadable credential metadata uses `configured: null`, including named fields,
 and renders as unavailable with a retry prompt. It does not claim that the slot
 is empty. Overview, Endpoints, Connectors, connector