@remits/remits-cli 0.1.87 → 0.1.90

package/README.md

@@ -29,10 +29,10 @@ git add -A
 git commit -m "sync passing changes"
 git push
 remits-cli components sync
-remits-cli components sync --branch feature_forked --dry-run
-remits-cli components sync --branch feature_forked --force-tombstones
+remits-cli components sync --branch feature_branch --dry-run
+remits-cli components sync --branch feature_branch --force-tombstones
 remits-cli token --path page/my-embeddable
-remits-cli token --path page/my-embeddable --variant-branch feature_forked
+remits-cli token --path page/my-embeddable --variant-branch feature_branch
 remits-cli data-mode
 remits-cli data-mode set prod
 remits-cli sessions list
@@ -66,7 +66,7 @@ remits-cli install --skills --overwrite true
 - `components commit` is a convenience wrapper that performs local git commit/push, then `components sync`, then local `git fetch`/`git pull --ff-only`.
 - `components sync` returns the post-sync branch SHA produced by the platform. `components commit` verifies that `origin/<branch>` and local `HEAD` both match that exact SHA after the final pull.
 - `components push` is deprecated and currently behaves the same as `components stage`.
-- `accountId` resolution for CLI commands: explicit `--account-id` flag wins, then the current repo's `account-info.json`, then the active session. For `remits-cli tool` calls the server applies a further precedence — explicit `--account-id` > `input.accountId` > session/repo default — so a tool can execute against a different account than the surrounding repo.
+- `accountId` resolution for CLI commands: explicit `--account-id` flag wins, then the current repo's `account-info.json` (`resolution.accountId`, then the short-lived `repoContext.accountInfoAccountId`, then the legacy top-level id — legacy files are rooted at the hierarchy ROOT, so their top-level `id` may be an ancestor), then the active session. For `remits-cli tool` calls the server applies a further precedence — explicit `--account-id` > `input.accountId` > session/repo default — so a tool can execute against a different account than the surrounding repo.
 - Auth sessions are stored per `accountId + dataMode + baseUrl`, so the same account can stay authenticated against both localhost and production without overwriting the other session.
 - `--base-url` and `--data-mode` are independent. `--base-url` chooses the Remits host (`http://localhost:8080` vs deployed prod), while `--data-mode` chooses the data segment on that host (`test` vs `prod`). Do not assume `--data-mode prod` means the deployed prod host, or that `--data-mode test` means localhost.
 - `remits-cli start` scans the machine for `account-info.json` files and rebuilds `~/.remits-cli/account-repos.json` before bringing up the background service.

package/index.js

@@ -268,6 +268,19 @@ function printResolvedBaseUrl(baseUrl) {
   console.log('Base URL:', normalizeBaseUrl(baseUrl || DEFAULT_BASE_URL));
 }
 
+// A tool's OWN verdict, which is separate from whether the call was dispatched. Only an explicit
+// failure signal counts: tools legitimately return strings, arrays, and maps with no `success` key.
+// Used as a fallback when the platform build predates the envelope's `toolSuccess`.
+function toolResultFailed(result) {
+  if (!result || typeof result !== 'object' || Array.isArray(result)) return false;
+  return result.success === false || result.is_error === true;
+}
+
+function toolResultMessage(result) {
+  if (!toolResultFailed(result)) return null;
+  return result.message || result.error || 'The tool returned an error';
+}
+
 function readConfig() {
   if (!fs.existsSync(CONFIG_FILE)) {
     return {};
@@ -477,7 +490,21 @@ function loadAccountId(cwd) {
     throw new Error('account-info.json not found in current directory');
   }
   const data = JSON.parse(fs.readFileSync(file, 'utf8'));
-  return Number(data.id || data.accountId || (data.account && data.account.id));
+  return Number(accountIdFromAccountInfo(data));
+}
+
+// `resolution.accountId` is the account the export DESCRIBES, and the only key that is unambiguous in
+// every shape: a legacy account-info.json is rooted at the hierarchy ROOT, so its top-level `id` is an
+// ancestor, not this repo's account. `repoContext` is a short-lived earlier name for the same fact and is
+// still read so checkouts written during that window keep resolving.
+function accountIdFromAccountInfo(info) {
+  return (info && (
+    (info.resolution && info.resolution.accountId) ||
+    (info.repoContext && info.repoContext.accountInfoAccountId) ||
+    info.id ||
+    info.accountId ||
+    (info.account && info.account.id)
+  )) || null;
 }
 
 function loadAccountInfo(cwd) {
@@ -512,14 +539,23 @@ function buildAccountRepoEntryFromInfo(info, directory, source = 'discovered') {
   if (!info || typeof info !== 'object') {
     return null;
   }
-  const accountId = Number(info.id || info.accountId || (info.account && info.account.id));
+  const accountId = Number(accountIdFromAccountInfo(info));
   if (!Number.isFinite(accountId) || accountId <= 0) {
     return null;
   }
   return {
     accountId,
-    name: info.name || info.accountName || (info.account && info.account.name) || '',
-    type: info.type || info.accountType || (info.account && info.account.type) || null,
+    name: (info.resolution && info.resolution.accountName) ||
+      (info.repoContext && info.repoContext.accountInfoAccountName) ||
+      info.name ||
+      info.accountName ||
+      (info.account && info.account.name) ||
+      '',
+    type: (info.resolution && info.resolution.type) ||
+      info.type ||
+      info.accountType ||
+      (info.account && info.account.type) ||
+      null,
     platformAccountId: info.platformAccountId || (info.platform && info.platform.id) || null,
     directory: path.resolve(directory),
     accountInfoPath: path.join(path.resolve(directory), 'account-info.json'),
@@ -2462,7 +2498,12 @@ async function toolCommand(flags) {
     if (data.threadGroupingId) console.log('Thread grouping ID:', data.threadGroupingId);
     console.log('Session log:', sessionJsonlFile(cwd));
     console.log('Tool response file:', statusResponse.responseFile);
-    if (data.status === 'failed') process.exitCode = 1;
+    // A completed run can still carry a tool-level refusal — see toolResultFailed.
+    const polledFailed = data.toolSuccess === false || toolResultFailed(data.result);
+    if (polledFailed) {
+      console.log('Tool error:', data.toolMessage || toolResultMessage(data.result));
+    }
+    if (data.status === 'failed' || polledFailed) process.exitCode = 1;
     return;
   }
 
@@ -2484,9 +2525,19 @@ async function toolCommand(flags) {
     throw new Error(data.message || 'Tool execution failed');
   }
 
+  // `data.success` only means the tool was found and DISPATCHED. A tool that ran and refused (unmet
+  // precondition, rejected enum value, validation failure) still comes back 200 with its own
+  // success:false, and printing "Tool call succeeded" for that has caused agents to report work as
+  // done that never happened. Prefer the server's hoisted verdict; fall back to introspecting the
+  // result so this still works against an older platform build.
+  const toolFailed = data.toolSuccess === false || toolResultFailed(data.result);
+  const toolFailureMessage = data.toolMessage || toolResultMessage(data.result);
+
   printSessionResolutionWarning(sessionContext);
   printResolvedBaseUrl(baseUrl);
-  console.log(asyncMode ? 'Tool call started.' : 'Tool call succeeded.');
+  console.log(asyncMode ? 'Tool call started.'
+    : (toolFailed ? 'Tool call FAILED — the tool ran and returned an error.' : 'Tool call succeeded.'));
+  if (toolFailed && toolFailureMessage) console.log('Tool error:', toolFailureMessage);
   console.log('Call ID:', callId);
   console.log('Data mode:', data.dataMode || dataMode);
   if (data.variantBranch || variantBranch) console.log('Variant branch:', data.variantBranch || variantBranch);
@@ -2500,6 +2551,9 @@ async function toolCommand(flags) {
   console.log('Session log:', sessionJsonlFile(cwd));
   console.log('Tool response file:', response.responseFile);
 
+  // Non-zero exit so scripted/agent callers that check status notice the refusal too.
+  if (toolFailed) process.exitCode = 1;
+
   if (asyncMode && waitForAsync) {
     const finalStatus = await waitForToolStatus(api, cwd, {
       token: session.token,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remits/remits-cli",
-  "version": "0.1.87",
+  "version": "0.1.90",
   "description": "Local CLI for auth, component sync, and live test execution against Remits",
   "license": "MIT",
   "private": false,

package/skills/remits-cli/SKILL.md

@@ -7,119 +7,120 @@ description: Use remits-cli for fast branch-scoped component staging, test execu
 
 ## Table of Contents
 
-- Line 126: Account Targeting Model
-- Line 133: Account types
-- Line 148: How accounts connect (and why it changes what runs)
-- Line 178: Users are a separate model — don't reason about them as a tree
-- Line 191: Reading the shape
-- Line 207: Repo selection rules
-- Line 219: Component Integrity Rules: Repo ↔ Database Reconciliation (read before any sync/commit)
-- Line 225: How the platform reconciles the repo into the database (the mechanism you must understand)
-- Line 280: The surfaces and their intended behavior
-- Line 304: Intended workflows
-- Line 323: Pre-sync safety check (confirm ALL before `components sync` or `components commit`)
-- Line 336: If something looks wrong — stop, don't paper over
-- Line 360: Required Local Index Reads
-- Line 394: Big Picture: How remits-cli State Is Organized
-- Line 424: Support Ticket Mental Model
-- Line 460: Efficiency Rules
-- Line 472: Account Repository Index
-- Line 497: Two Workflows
-- Line 504: Test Mode vs Prod Mode
-- Line 536: Platform Mental Model: Front Stage vs Back Stage
-- Line 543: Documents vs Records
-- Line 553: HTTP Audits
-- Line 607: Record `content` / Context Mental Model
-- Line 627: Provenance Fields
-- Line 645: Why Persisted Context Looks Different From Runtime Context
-- Line 666: Investigation Rule for Record Context
-- Line 681: AI Request Response Records
-- Line 688: AI Session Groupings
-- Line 707: Correlation Keys
-- Line 713: Node Reference Table
-- Line 723: Repository vs External Context
-- Line 730: Getting Started
-- Line 732: Authentication
-- Line 745: Host vs Data Mode
-- Line 764: Tool Execution Lifecycle
-- Line 818: Data Mode
-- Line 828: Development Workflow
-- Line 830: The Golden Rule: Writing Code Is Not Finishing the Job
-- Line 842: Avoid Brittle Front-Stage Intelligence
-- Line 855: The Development Fast Loop
-- Line 859: Step 1: Understand the Request
-- Line 874: Step 2: Make the Change
-- Line 877: Step 3: Stage to Platform
-- Line 892: Step 4: Verify the Change
-- Line 955: Step 5: Iterate If Needed
-- Line 965: Step 6: Update Documentation
-- Line 975: Step 7: Commit and Durable Sync
-- Line 1013: Step 8: Close the Ticket
-- Line 1028: User Confirmation Preferences
-- Line 1038: Component Resolution: Staging Cache vs DB (which "version" actually runs)
-- Line 1044: The three source layers + the compile cache
-- Line 1067: Staging cache key format
-- Line 1082: How the platform picks staged vs DB (the compile signature)
-- Line 1104: When staged overrides apply
-- Line 1128: Diagnosing which version is in play
-- Line 1149: Stage / commit / clear with the MCP tools
-- Line 1173: Stale after sync / commit (the in-memory compile cache)
-- Line 1183: Account Resolution: how a request travels the account graph
-- Line 1276: Branched Component Variants (per-account component overrides)
-- Line 1284: The model (three moving parts)
-- Line 1351: Which world does your working tree resolve? (read this before you run anything)
-- Line 1383: Two levers, two different questions
-- Line 1397: The SDLC is identical on a variant branch
-- Line 1421: Promotion: getting the branch back into trunk
-- Line 1463: Verifying as the subscriber
-- Line 1482: Agents (Utility) on a variant branch
-- Line 1494: Danger profile on a variant branch (different, not absent)
-- Line 1522: Inspecting branches and drift
-- Line 1554: Diagnosing a variant
-- Line 1561: Production Support Workflow
-- Line 1569: Investigation Strategy
-- Line 1599: Presenting Findings
-- Line 1607: Verifying a Production Issue Fix
-- Line 1620: Tool Reference
-- Line 1622: Execute a Tool
-- Line 1651: `mcp_account_view`
-- Line 1680: `mcp_firestore_search`
-- Line 1718: `mcp_object_activity`
-- Line 1727: `mcp_record_listing`
-- Line 1752: `mcp_record_view`
-- Line 1765: `mcp_ai_session_search`
-- Line 1801: `mcp_run_action`
-- Line 1845: `mcp_run_agent`
-- Line 1881: `mcp_system_logs`
-- Line 1904: `mcp_component_view`
-- Line 1927: `mcp_component_grep`
-- Line 1940: `mcp_support_ticket`
-- Line 1989: `mcp_run_test`
-- Line 1998: `mcp_component_edit`
-- Line 2013: `mcp_component_create`
-- Line 2027: `mcp_component_commit`
-- Line 2035: `mcp_component_branches`
-- Line 2054: `mcp_cache`
-- Line 2066: `mcp_sql_query`
-- Line 2101: `mcp_index_search`
-- Line 2121: `mcp_get_guide`
-- Line 2133: `mcp_test_fixture`
-- Line 2146: `mcp_embeddable_test_url`
-- Line 2158: `mcp_playwright_replay`
-- Line 2173: `mcp_jvm_spike_triage`
-- Line 2186: `mcp_support_ticket_queue`
-- Line 2203: Multi-Session Support
-- Line 2223: Persistent Service, Control Center, and Agent Dispatch
-- Line 2232: Starting the Service
-- Line 2258: Control Center
-- Line 2273: Agent Dispatch
-- Line 2294: Configuring the Preferred Agent
-- Line 2305: Local State Files
-- Line 2353: Command Reference
-- Line 2395: Troubleshooting
-- Line 2436: When Something Doesn't Work as Expected
-- Line 2447: Back-Stage Escalation Workflow (platform defect/limitation)
-- Line 2456: Escalation Bundle (tooling/operational issue)
+- Line 127: Account Targeting Model
+- Line 134: Account types
+- Line 149: How accounts connect (and why it changes what runs)
+- Line 179: Users are a separate model — don't reason about them as a tree
+- Line 192: Reading the shape
+- Line 218: Repo selection rules
+- Line 230: Component Integrity Rules: Repo ↔ Database Reconciliation (read before any sync/commit)
+- Line 236: How the platform reconciles the repo into the database (the mechanism you must understand)
+- Line 298: The surfaces and their intended behavior
+- Line 322: Intended workflows
+- Line 343: Pre-sync safety check (confirm ALL before `components sync` or `components commit`)
+- Line 356: If something looks wrong — stop, don't paper over
+- Line 380: Required Local Index Reads
+- Line 414: Big Picture: How remits-cli State Is Organized
+- Line 444: Support Ticket Mental Model
+- Line 480: Efficiency Rules
+- Line 492: Account Repository Index
+- Line 517: Two Workflows
+- Line 524: Test Mode vs Prod Mode
+- Line 556: Platform Mental Model: Front Stage vs Back Stage
+- Line 563: Documents vs Records
+- Line 573: HTTP Audits
+- Line 627: Record `content` / Context Mental Model
+- Line 647: Provenance Fields
+- Line 665: Why Persisted Context Looks Different From Runtime Context
+- Line 686: Investigation Rule for Record Context
+- Line 701: AI Request Response Records
+- Line 708: AI Session Groupings
+- Line 727: Correlation Keys
+- Line 733: Node Reference Table
+- Line 743: Repository vs External Context
+- Line 750: Getting Started
+- Line 752: Authentication
+- Line 765: Host vs Data Mode
+- Line 784: Tool Execution Lifecycle
+- Line 838: Data Mode
+- Line 848: Development Workflow
+- Line 850: The Golden Rule: Writing Code Is Not Finishing the Job
+- Line 862: Avoid Brittle Front-Stage Intelligence
+- Line 875: The Development Fast Loop
+- Line 879: Step 1: Understand the Request
+- Line 894: Step 2: Make the Change
+- Line 932: Step 3: Stage to Platform
+- Line 947: Step 4: Verify the Change
+- Line 1012: Step 5: Iterate If Needed
+- Line 1022: Step 6: Update Documentation
+- Line 1034: Step 7: Commit and Durable Sync
+- Line 1072: Step 8: Close the Ticket
+- Line 1087: User Confirmation Preferences
+- Line 1097: Component Resolution: Staging Cache vs DB (which "version" actually runs)
+- Line 1103: The three source layers + the compile cache
+- Line 1126: Staging cache key format
+- Line 1141: How the platform picks staged vs DB (the compile signature)
+- Line 1163: When staged overrides apply
+- Line 1187: Diagnosing which version is in play
+- Line 1208: Stage / commit / clear with the MCP tools
+- Line 1232: Stale after sync / commit (the in-memory compile cache)
+- Line 1242: Account Resolution: how a request travels the account graph
+- Line 1335: Branched Component Variants (per-account component overrides)
+- Line 1343: The model (three moving parts)
+- Line 1410: Which world does your working tree resolve? (read this before you run anything)
+- Line 1476: Two levers, two different questions
+- Line 1490: The SDLC is identical on a variant branch
+- Line 1515: Promotion: getting the branch back into trunk
+- Line 1557: Verifying as the subscriber
+- Line 1576: Agents (Utility) on a variant branch
+- Line 1588: Danger profile on a variant branch (different, not absent)
+- Line 1616: Inspecting branches and drift
+- Line 1648: Diagnosing a variant
+- Line 1655: Production Support Workflow
+- Line 1663: Investigation Strategy
+- Line 1693: Presenting Findings
+- Line 1701: Verifying a Production Issue Fix
+- Line 1714: Tool Reference
+- Line 1716: Execute a Tool
+- Line 1745: `mcp_account_view`
+- Line 1777: `mcp_account_user_admin`
+- Line 1812: `mcp_firestore_search`
+- Line 1850: `mcp_object_activity`
+- Line 1859: `mcp_record_listing`
+- Line 1884: `mcp_record_view`
+- Line 1897: `mcp_ai_session_search`
+- Line 1933: `mcp_run_action`
+- Line 1977: `mcp_run_agent`
+- Line 2013: `mcp_system_logs`
+- Line 2036: `mcp_component_view`
+- Line 2059: `mcp_component_grep`
+- Line 2072: `mcp_support_ticket`
+- Line 2121: `mcp_run_test`
+- Line 2130: `mcp_component_edit`
+- Line 2145: `mcp_component_create`
+- Line 2159: `mcp_component_commit`
+- Line 2167: `mcp_component_branches`
+- Line 2186: `mcp_cache`
+- Line 2198: `mcp_sql_query`
+- Line 2233: `mcp_index_search`
+- Line 2253: `mcp_get_guide`
+- Line 2265: `mcp_test_fixture`
+- Line 2278: `mcp_embeddable_test_url`
+- Line 2290: `mcp_playwright_replay`
+- Line 2305: `mcp_jvm_spike_triage`
+- Line 2318: `mcp_support_ticket_queue`
+- Line 2335: Multi-Session Support
+- Line 2355: Persistent Service, Control Center, and Agent Dispatch
+- Line 2364: Starting the Service
+- Line 2390: Control Center
+- Line 2405: Agent Dispatch
+- Line 2426: Configuring the Preferred Agent
+- Line 2437: Local State Files
+- Line 2485: Command Reference
+- Line 2527: Troubleshooting
+- Line 2569: When Something Doesn't Work as Expected
+- Line 2580: Back-Stage Escalation Workflow (platform defect/limitation)
+- Line 2589: Escalation Bundle (tooling/operational issue)
 
 `remits-cli` is the brainstem for both **development** and **production support**. You might run it inside an account repository (where `account-info.json` and `/components` already exist) or from outside any repo when a user needs help on another account. Your users are business professionals — they think in terms of what they can see in a browser.
 
@@ -156,7 +157,7 @@ An account is linked upward in two ways, and they coexist:
 
 - **The primary parent** — one per account. The overwhelming majority of accounts have only this.
 - **Membership edges** — extra links letting the *same account* be reached through **more than one** parent
-  (a customer in two product lines; a forked deployment reaching the same owner).
+  (a customer in two product lines; a branch deployment reaching the same owner).
 
 Any link can independently carry three things. They are **orthogonal** — never infer one from another:
 
@@ -190,17 +191,27 @@ this user see the wrong data?") use `mcp_sql_query` against `user` / `user_accou
 
 ### Reading the shape
 
-`account-info.json` / `mcp_account_view` carry a `resolution` block. Read it in this order:
+`account-info.json` / `mcp_account_view` carry a `resolution` block — the ONE place these facts appear
+(nothing in it is repeated elsewhere in the file). Read it in this order:
 
+- **`role`** + **`summary`** — `OWNER` (resolves its own component trunk: the files here ARE its components)
+  or `SUBSCRIBER` (resolves ANOTHER account's components with a variant branch applied). `summary` says it
+  in one sentence, naming the owner. Read this before you touch anything.
+- **`accountId`** — the account described. In a repo export the top-level `id` is the same account; in a
+  legacy export it is the hierarchy ROOT, so prefer `resolution.accountId`.
 - **`type`** — decide repo/ownership per the table above.
 - **`resolvedDatabaseName`** vs **`databaseName`** — the namespace actually in effect vs the account's own
   override. Check this first when documents are "missing".
 - **`relationships`** — every link upward, primary first, each with its own `branchName` / `databaseName` /
   `domainName`. **This is where you see that an account has two parents, and which link carries what.**
-- **`componentBranch`** (+ `componentBranchOwnerAccountId`) — the component-variant branch this account
-  subscribes to, if any. Present only when subscribed.
+- **`componentBranch`** (+ `componentOwnerAccountId` / `componentOwnerAccountName`) — the component-variant
+  branch in effect for this resolution and who owns it. A `SUBSCRIBER` with no `componentBranch` subscribes
+  through an edge that nothing anchored this resolution to (multi-parent, no path named) — `summary` says so.
 - **`branchName`** — the account **repo's** trunk sync branch. Not a component-variant branch. Do not confuse
   these two.
+- **`parents`** / **`children`** — the anchored ancestor chain and a DIRECT-child summary with counts (repo
+  exports only; the default `mcp_account_view` shape carries the full tree instead). The deep tree is a
+  lookup — `mcp_account_user_admin` with `action:'hierarchy'` and a `depth` — never a committed artifact.
 - **`componentBranches`** (top level) — variant branches this account **owns**, with drift and subscriber
   counts. Check it before editing a shared component.
 
@@ -906,6 +917,7 @@ summary: One-line statement of what this component is for.
 description: |
   Longer technical description with line-number references to the key logic.
 path: /page/merchant-portal        # Readers and Embeddables only
+injectionType: DIRECT              # Embeddables only: DIRECT or IFRAME
 category: default
 auxiliary: false                   # `true` means the sync SKIPS the file entirely — see Auxiliary
 mermaid: |
@@ -1124,7 +1136,7 @@ account:<accountId>:cli:<cliUserId>:components:<branch>:<family>:name:<normalize
 component's OWN type enum such as `ObjectType`/`RuleType`, or absent — **never** the family), `hash`,
 `updatedAt`, the staged content field(s) (`source`/`prompt`/`html`/`javascript`/`schema`/
 `inputSchema`/`previewData`), and `.meta.yml` metadata fields such as `description`, `summary`, `mermaid`,
-`path`, `category`, and Schema flags (`enableTrigger`, `enableFullText`, `enableRAG`, `enableRevisions`,
+`path`, Embeddable `injectionType`, `category`, and Schema flags (`enableTrigger`, `enableFullText`, `enableRAG`, `enableRevisions`,
 `enableBigQuerySync`, `enableRules`, `anchor`, `auxiliary`).
 
 ### How the platform picks staged vs DB (the compile signature)
@@ -1256,8 +1268,8 @@ edge's *child* as the execution account **and** the edge's *parent* as the branc
 makes that edge's branch variants apply. An account-level host resolves the account with **no** anchor
 (today's behavior). Edge wins, then the account's own host, so removing an edge degrades cleanly instead
 of taking the hostname offline. Hosts are stored as bare lowercase hostnames; a full URL is normalized on
-the way in. This is what lets a forked/branch deployment get its own domain without a separate account
-tree — `forked.example.com` and `app.example.com` can serve the same owner's components, one overlaid
+the way in. This is what lets a branch deployment get its own domain without a separate account
+tree — `branch.example.com` and `app.example.com` can serve the same owner's components, one overlaid
 with a branch.
 
 **Two traversals, deliberately different.** Confusing them is the usual source of wrong conclusions:
@@ -1333,14 +1345,14 @@ resolve.
 
 1. **The origin account owns the component and the branch.** Say platform account 1 owns
    `Extract Invoice` (Action 50). Its repo `remits-<name>` has trunk branch `main` and a second git branch
-   `feature_forked`.
-2. **A `ComponentVariant` row is the overlay.** Committing on `feature_forked` stores rows owned by
-   **account 1**, on branch `feature_forked`, for the components whose content **differs from trunk**. A git
+   `feature_branch`.
+2. **A `ComponentVariant` row is the overlay.** Committing on `feature_branch` stores rows owned by
+   **account 1**, on branch `feature_branch`, for the components whose content **differs from trunk**. A git
    branch physically contains every file; only the *differing* ones become variants. That is computed at
    sync time — you never declare it.
 3. **A child account subscribes via its relationship edge.** Account 101's `AccountRelationship` edge
-   carries `branchName = 'feature_forked'`. Resolution then walks 101's inheritance chain and applies
-   account 1's `feature_forked` overlays.
+   carries `branchName = 'feature_branch'`. Resolution then walks 101's inheritance chain and applies
+   account 1's `feature_branch` overlays.
 
 Consequences worth internalizing:
 
@@ -1358,8 +1370,14 @@ Consequences worth internalizing:
   only subscribe an account reachable from one you already have access to.
   - **`--subscribe` sets the branch on an edge that must already exist — it cannot create one.** If the
     account has no relationship edge to the owner you will get *"Account N has no relationship edge to
-    subscribe; add a membership edge first"*. Creating a membership edge is an **admin** operation (the
-    account page), not a CLI one.
+    subscribe; add a membership edge first"*. Create it with
+    `mcp_account_user_admin` `action:'edge_add'` (`targetAccountId` = the child, `parentAccountId` = the
+    owner), which also accepts `branchName` so you can create and subscribe in one call. The admin account
+    page does the same thing.
+    - **Many older accounts have no relationship row at all.** The edge table was introduced after the fact
+      and never backfilled, so an account whose parent link is only `Account.parentId` resolves fine but has
+      nothing for `--subscribe` to attach to. `mcp_account_user_admin` `action:'reparent'` with the account's
+      *current* parent is the one-call repair: it creates the missing primary edge and changes nothing else.
   - **When the account has several parents, say which edge you mean:**
     `--subscribe <accountId> --parent-account <ownerId>`. Without it the CLI picks the edge to the owner
     whose branch you are managing, then falls back to the account's primary edge — which may not be the
@@ -1389,7 +1407,7 @@ changes validation and where the subscriber's documents physically land. Treat s
 same care as a trunk schema change.
 
 **What a branch may override.** A variant speaks the same `.meta.yml` vocabulary trunk does — `name`,
-`description`, `summary`, `mermaid`, `category`, `type`, `path`, `collectionName`, `job`, `model`,
+`description`, `summary`, `mermaid`, `category`, `type`, `path`, `injectionType`, `collectionName`, `job`, `model`,
 `agentTimeout`, `mcp`, `cli`, `global`, `purpose`, `auxiliary`, plus Schema flags (`enableTrigger`,
 `enableFullText`, `enableRAG`, `enableRevisions`, `enableBigQuerySync`, `enableRules`, `anchor`) — and the
 component's content files. Keys outside that set are ignored, deliberately: trunk cannot express them either,
@@ -1404,7 +1422,7 @@ the loop. The rule turns entirely on **trunk vs non-trunk**:
 | Working tree | Staging scope | A run resolves | `components sync`/`commit` writes |
 |---|---|---|---|
 | **trunk** (`main`, or whatever `account-info.json` says) | that branch | trunk + **each account's subscribed** variant branch (production semantics) | the **live component rows** — full reconcile, creates/updates/**deletes** |
-| **any other branch** (`feature_forked`) | that branch | trunk + **`feature_forked`** overlays | **`ComponentVariant` overlays on that branch only** — never touches trunk rows |
+| **any other branch** (`feature_branch`) | that branch | trunk + **`feature_branch`** overlays | **`ComponentVariant` overlays on that branch only** — never touches trunk rows |
 
 **The precedence trap that costs the most time:** `variantBranch` OUTRANKS every account's subscription. So
 running a Test suite that asserts *production* semantics from a **variant checkout** pins every account in
@@ -1421,9 +1439,9 @@ remits-cli components status
 ```
 
 ```
-Working tree: VARIANT BRANCH "feature_forked"  (trunk is "main")
-  runs resolve:   trunk + the 'feature_forked' variant overlays
-  commit writes:  ComponentVariant overlays on 'feature_forked' (never touches trunk rows)
+Working tree: VARIANT BRANCH "feature_branch"  (trunk is "main")
+  runs resolve:   trunk + the 'feature_branch' variant overlays
+  commit writes:  ComponentVariant overlays on 'feature_branch' (never touches trunk rows)
   variants stored on this branch: 3
   subscribing accounts: 101 (Acme Child)
 ```
@@ -1432,8 +1450,30 @@ Working tree: VARIANT BRANCH "feature_forked"  (trunk is "main")
 is still the OWNER's component repo: files under `components/` overlay that owner's trunk component ids, and
 `components sync` writes `ComponentVariant` rows owned by that parent account. But if the checkout was synced
 from a subscribing account reached through an `AccountRelationship` edge, the branch's `account-info.json`
-is intentionally refreshed from the subscriber's resolved account information. That is what lets a forked
-checkout answer "who am I acting as?" while preserving "who owns these component variants?"
+is intentionally rooted at that subscriber and refreshed from the subscriber's resolved account information.
+That is what lets a branch checkout answer "who am I acting as?" while preserving "who owns these component
+variants?"
+
+Read the `resolution` block before acting from any checkout — it is the ONE place account-info states this
+(nothing in it is repeated elsewhere in the file):
+
+- `resolution.role` — `OWNER` for a trunk/owner export, `SUBSCRIBER` for an account reached through an
+  `AccountRelationship` branch edge. `resolution.summary` says the same thing in one sentence.
+- `resolution.accountId` — the account the local checkout should be treated as. **This, not the top-level
+  `id`, is the key to read**: an `account-info.json` predating this shape is rooted at the hierarchy root.
+- `resolution.componentOwnerAccountId` — the account whose trunk component ids the files overlay and whose
+  `ComponentVariant` rows sync writes. Equals `resolution.accountId` for an `OWNER`.
+- `resolution.componentBranch` / `resolution.scopeAccountId` — the branch and the path anchor that made this
+  subscriber resolution possible.
+- `resolution.parents` / `resolution.children` / `resolution.relationships` — the account graph, stated once
+  and compactly. The full descendant tree is a lookup (`mcp_account_user_admin`, `mcp_account_view`), not a
+  committed artifact.
+
+**One branch, one `account-info.json`.** There is exactly one git branch, so when a branch has MORE THAN ONE
+subscriber the refresh is skipped (the sync result says so under `accountInfo.skipped`/`reason`) and the file
+keeps describing the owner — which is at least true for all of them. Otherwise each subscriber's sync would
+rewrite the file as its own and hand the other subscriber's agent a file naming the wrong account. Overlay
+ownership is unaffected either way: variants always belong to the owner account.
 
 Consequence: if a variant checkout's `account-info.json` is stale and still names the owner, run the first
 repair sync with an explicit subscriber target, for example `remits-cli components sync --account-id 101`.
@@ -1459,13 +1499,13 @@ Both work on `remits-cli test run` and `remits-cli token`; `--variant-branch` al
 The loop does not change shape — `edit → stage → verify → commit`:
 
 ```bash
-git checkout feature_forked          # or: git checkout -b feature_forked
+git checkout feature_branch          # or: git checkout -b feature_branch
 # edit components/actions/50_ExtractInvoice.groovy   (KEEP the trunk id)
 remits-cli components stage          # Redis, scoped to this branch — same as always
-remits-cli test run --test "Invoice Tests"          # resolves the feature_forked world
+remits-cli test run --test "Invoice Tests"          # resolves the feature_branch world
 remits-cli test run --test "Invoice Tests" --as-account 101   # ...as the real subscriber
 # promote:
-git add -A && git commit -m "..." && git push origin feature_forked
+git add -A && git commit -m "..." && git push origin feature_branch
 remits-cli components sync --dry-run # inspect overrides/additions/tombstones without writes
 remits-cli components sync           # writes ComponentVariant overlays ONLY
 ```
@@ -1486,12 +1526,12 @@ by a **trunk** sync — the platform does not merge anything for you.
 
 ```bash
 # 1. merge the branch into trunk (review the diff FIRST - see the deletion hazard below)
-git checkout main && git merge feature_forked && git push origin main
+git checkout main && git merge feature_branch && git push origin main
 # 2. trunk sync: creates real rows for new_* files, assigns ids, RENAMES those files on trunk
 remits-cli components sync
 git pull --ff-only origin main
 # 3. bring trunk back into the branch so the two stop diverging
-git checkout feature_forked && git merge origin/main && git push origin feature_forked
+git checkout feature_branch && git merge origin/main && git push origin feature_branch
 remits-cli components sync                        # reconciles the branch's overlays
 ```
 
@@ -1584,9 +1624,9 @@ The analogous hazard is different and you must still respect it:
 
 ```bash
 remits-cli components branches                                  # branches with variants, counts, drift
-remits-cli components branch feature_forked                     # overridden / added / removed + subscribers
-remits-cli components branch feature_forked --diff 50 --component-type action
-remits-cli components branch feature_forked --subscribers
+remits-cli components branch feature_branch                     # overridden / added / removed + subscribers
+remits-cli components branch feature_branch --diff 50 --component-type action
+remits-cli components branch feature_branch --subscribers
 ```
 
 **Drift is the number to watch.** Each variant records the trunk content hash at the moment it was cut
@@ -1688,6 +1728,23 @@ remits-cli tool --name "mcp_firestore_search" --input '{"accountId": 37, "collec
 
 Response saved to `./.remits-cli/tool-responses/<callId>.json`. Read the file to see results.
 
+**"Tool call succeeded" means DISPATCHED, not that the tool did what you asked.** A tool that runs
+and refuses — an unmet precondition, a rejected enum value, a failed validation — returns HTTP 200
+with its own `success: false` inside `result`. The CLI now prints `Tool call FAILED — the tool ran
+and returned an error.` plus a `Tool error:` line and exits non-zero, and the response envelope
+carries `toolSuccess` / `toolMessage`. **For any MUTATING call, confirm the tool's own verdict before
+reporting the work as done** — do not grep the terminal output for "succeeded":
+
+```bash
+F=$(remits-cli tool --name mcp_support_ticket --input "$(cat payload.json)" --data-mode prod 2>&1 \
+    | grep -o '[^ ]*tool-responses/[a-f0-9-]*\.json' | tail -1)
+python3 -c "import json;r=json.load(open('$F'))['result'];print(r.get('success'), r.get('message'))"
+```
+
+Build non-trivial JSON into a file (e.g. with `python3 -c 'json.dumps(...)'`) and pass it as
+`--input "$(cat payload.json)"`. Long inline single-quoted JSON intermittently produces no response
+file at all.
+
 For long-running Action/Agent runners, use the tool's own async mode (`executionMode:"async"`), which returns
 the `actionRunId`/`agentRunId` (and, for agents, `sessionId`) immediately:
 
@@ -1715,11 +1772,14 @@ Returns complete account structure — schemas, components, relationships.
 Also returns two blocks that explain how the account RESOLVES, which is what you need before comparing
 its behavior against component source:
 
-- `resolution` — `databaseName` (the account's own override, often null) vs `resolvedDatabaseName` (the
-  storage namespace actually in effect), `branchName` (the repo sync branch), `domainName` vs
-  `resolvedDomainName` (the custom host in effect, which differs when reached through an edge host),
-  `editMode`, and — when the account subscribes to a component branch — `componentBranch` plus
-  `componentBranchOwnerAccountId`.
+- `resolution` — `role` (`OWNER` = resolves its own component trunk, `SUBSCRIBER` = resolves another
+  account's components through a branch edge) and a one-sentence `summary`; `accountId` (the account
+  described — the top level of this shape is the hierarchy ROOT, so do not read identity from there);
+  `databaseName` (the account's own override, often null) vs `resolvedDatabaseName` (the storage namespace
+  actually in effect); `branchName` (the repo sync branch) and `lastRepoSync`; `domainName` vs
+  `resolvedDomainName` (the custom host in effect, which differs when reached through an edge host);
+  `editMode`; and — when a component branch is in effect — `componentBranch` plus `componentOwnerAccountId`
+  / `componentOwnerAccountName`.
 - `resolution.relationships` — **every structural link upward**, primary first: `parentAccountId` /
   `parentAccountName` / `parentAccountCode` / `parentAccountType`, `primary` (true for the one link that
   mirrors the account's primary parent), `active`, and the three independent link-scoped properties
@@ -1731,13 +1791,99 @@ its behavior against component source:
 - `componentBranches` — the variant branches this account OWNS, with override/add/remove, subscriber, and
   drift counts. Same summary the owner's `account-info.json` carries.
 
-Note: this tool does **not** return users. For user/access questions use `mcp_sql_query` (`user`,
-`user_account`).
+Note: this tool does **not** return users, and it returns EVERYTHING about one account. For users, for the
+deep account tree, or for small account/user updates, use `mcp_account_user_admin`.
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
 | `accountId` | yes | Account ID |
 
+### `mcp_account_user_admin`
+The account-graph and user surface: the middle ground between `account-info.json` (which states structure
+compactly, because it is read into your context every session) and `mcp_account_view` (everything about one
+account).
+
+- `action: 'hierarchy'` (default) — the descendant tree trimmed to `depth` (1-10, default 2; nodes cut off
+  are marked `truncated` and still report their child count) and/or the anchored ancestor chain plus every
+  edge (`direction: 'down'|'up'|'both'`). **This is how you get the deep tree account-info.json omits.**
+- `action: 'account'` — one account's `resolution` block plus masked configuration fields, without paying
+  for the component inventory.
+- `action: 'users'` — an account's users at a hierarchy `scope` (`self`/`children`/`parents`/`hierarchy`),
+  optional `email` substring filter. Extension fields are omitted here on purpose: they are stored **per
+  account** and these users are bound to their own.
+- `action: 'user'` — one user (`userId` or `email`) with roles, account memberships, and extension fields
+  **correctly scoped to the requested account**. It never grants membership as a side effect of a read, and
+  tells you when the fields shown belong to a different account.
+- `action: 'account_update'` — write Account-schema configuration `fields`, and/or `name`/`status`
+  (`ACTIVE`/`ON_HOLD`/`PENDING`).
+- `action: 'user_update'` — write User-schema `fields` under the named account (refused unless the user is a
+  member or you pass `addAccount: true`, because the write would otherwise land on another account), plus
+  `name`/`enabled` and membership add/remove.
+
+**Building an account hierarchy** (the structural writes — this is how a coding agent provisions accounts
+without a browser):
+
+- `action: 'account_create'` — create a child under `parentAccountId`, with its **primary relationship edge**,
+  applying `type` / `databaseName` / `domainName` / `code` / `repositoryNameOverride` / `branchName` /
+  `editMode` / … **at birth**. That ordering matters: the storage namespace is resolved from those properties,
+  and the parent's cascaded schema fields are written into it during creation. Idempotent — an existing
+  same-name account under that parent comes back with `reusedExisting: true`, unchanged.
+- `action: 'account_structure'` — change those properties on an existing account.
+- `action: 'edge_add'` / `'edge_update'` / `'edge_remove'` — manage a membership `AccountRelationship` edge to
+  `parentAccountId`, including the three independent edge properties `branchName` (which component code runs),
+  `databaseName` (branch-scoped namespace — stored, but inert until segment inheritance is enabled) and
+  `domainName` (which host reaches the account through that edge). Cycles, self-edges, and removing the primary
+  edge are all refused.
+- `action: 'reparent'` — move the account's **primary** edge (and `Account.parentId`) to `parentAccountId`.
+
+> **The namespace guard.** An account's storage namespace resolves as
+> `databaseName ?: platform.code ?: code`, and `Account.setName` **regenerates `code`** — so renaming an
+> account whose namespace falls through to its own code silently repoints its storage. Any write that would
+> move the resolved namespace is **refused** unless you pass `confirmSegmentChange: true`, and the refusal
+> names both namespaces. To rename without moving storage, pin `code` to the old value in the same call.
+>
+> The namespace follows the **path**: the nearest `databaseName` walking up from the account — its own
+> first, then the edge it was reached through, then the same two questions at each account above — falling
+> back to the nearest `PLATFORM` ancestor's `code`. So a namespace set anywhere above is inherited by
+> everything below it until a nearer account or edge overrides it, and an edge answer is path-specific (the
+> same account reached through a different parent can resolve a different namespace).
+
+Every write supports `dryRun: true`, which reports each `from -> to` without writing. Not here by design:
+component-branch subscription reporting and drift (`mcp_component_branches` — though `edge_add`/`edge_update`
+set the branch directly), and account/user **deletion** (admin only, so the destructive-teardown contract
+applies).
+
+**Provisioning recipe** — a new product account under a platform, running its own component branch, with
+client accounts beneath it:
+
+```
+1. mcp_account_user_admin  action:'account_create'   parentAccountId:<platform>  name:'Adyen'
+                           type:'PLATFORM'|'PRODUCT'  [databaseName:'...']
+2. git branch + push in the OWNER's repo, then `remits-cli components sync` from that checkout
+   (non-trunk => writes ComponentVariant overlays only)
+3. mcp_account_user_admin  action:'edge_update'  targetAccountId:<new>  parentAccountId:<platform>
+                           branchName:'<branch>'          # or mcp_component_branches action:'subscribe'
+4. mcp_account_user_admin  action:'account_create'  parentAccountId:<new>  name:'<business unit>'
+                           type:'CLIENT'                  # inherits the branch automatically
+```
+
+> **Put the branch on the account's PRIMARY edge.** Component inheritance follows the *anchored* path, which
+> for an account with a `parentId` is its primary chain. An account that has both a primary edge and a
+> *membership* edge carrying the branch resolves **trunk** by default — the membership edge is never
+> anchored unless a request names it (`--as-account`, `--variant-branch`, or the edge's own host). Descendants
+> then inherit the branch down that primary chain automatically, which is what makes step 4 free.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `action` | no | `hierarchy` (default), `account`, `users`, `user`, `account_update`, `user_update` |
+| `accountId` / `targetAccountId` | no | Account to act on; `targetAccountId` targets another account without moving tool resolution |
+| `depth` / `direction` | no | `hierarchy` only |
+| `scope` | no | `users` only |
+| `userId` / `email` | no | Identify the user (`user`, `user_update`); `email` is a filter for `users` |
+| `fields` / `name` / `status` / `enabled` | no | The update payload |
+| `addAccount` / `removeAccount` | no | Membership changes for `user_update` |
+| `dryRun` | no | Report the change without writing |
+
 ### `mcp_firestore_search`
 Query Firestore documents.
 
@@ -2013,10 +2159,10 @@ Create and manage the full lifecycle of account-relative `support_tickets`.
 | `affectedComponent` | no | Component or platform area affected (`create`) |
 | `implementationAccountId` / `implementationAccountName` | no | Owning `PLATFORM`/`PRODUCT` account when the ticket concerns shared implementation (e.g. a back-stage platform fix) |
 | `stepsToReproduce` / `acceptanceCriteria` / `tags` | no | Extra `create` fields for defect/enhancement tickets |
-| `assignee` | no | Required for `accept` |
-| `status` | no | Required for `update_status`. Valid values: `in_progress`, `pending_review` |
+| `assignee` | no | Required for `accept`. The agent's own name by convention — `claude`, `codex`, `gemini` |
+| `status` | no | Required for `update_status`. Valid values: `in_progress`, `pending_review`. **The ticket must be `accept`ed first** — otherwise the call is rejected with *"Ticket must be accepted before updating status"* |
 | `resolution` | no | Required for `complete` |
-| `category` / `summary` / `details` / `findings` / `nextStep` | no | Worklog fields for `record_progress` (`category` + `summary` required) |
+| `category` / `summary` / `details` / `findings` / `nextStep` | no | Worklog fields for `record_progress` (`category` + `summary` required). `category` is a **fixed enum** — `triage`, `investigation`, `reproduction`, `fix`, `verification`, `handoff`, `other` — and any other value fails the whole call. `findings` is a **list of strings**, not a paragraph |
 | `artifactType` / `artifactLabel` / `contentBase64` / `gcsPath` / `url` | no | Evidence fields for `add_artifact` (screenshot/trace/log/test_result/link) |
 | `notes` | no | Optional lifecycle note stored with the ticket activity |
 | `attachmentIndex` | no | Zero-based index of the attachment to download. Used with `get_attachment`. |
@@ -2031,13 +2177,24 @@ Create and manage the full lifecycle of account-relative `support_tickets`.
 
 This keeps file retrieval self-contained — no separate download endpoint is needed.
 
-**Recommended flow:**
-1. `read` with the ticket's `accountId` — check ticket state and any attachments
-2. `accept` with the ticket's `accountId`
+**Recommended flow** — `accountId` is optional throughout; `ticketId` resolves the owning account:
+1. `read` — check ticket state and any attachments
+2. **`accept`** (with `assignee`) — this is a **hard precondition for `update_status`**, not just etiquette
 3. `get_attachment` if attachments are present and relevant to the investigation
-4. `update_status` with the ticket's `accountId`
-5. investigate/fix/verify on the owning ticket account or its implementation account as appropriate
-6. `complete` or `release` with the ticket's `accountId`
+4. `update_status` — `in_progress` while working, `pending_review` when the fix is done but not yet deployed
+5. `record_progress` as you go — one `investigation` entry for the root cause, one `verification` entry for the proof
+6. investigate/fix/verify on the owning ticket account or its implementation account as appropriate
+7. `complete` (with `resolution`) or `release` if handing off
+
+**Check each mutation actually landed.** Every action above is a write that can be refused while the
+CLI still reports the *call* as fine — see "Execute a Tool" for why, and read `result.success` from
+the response file. A silent no-op here means telling the user a ticket moved when it did not.
+
+**Duplicates are common.** The same defect is often filed twice — once against the `CLIENT`/subscriber
+account where it was observed and once against the owning `PLATFORM`/`PRODUCT` account. Before
+starting, check `mcp_support_ticket_queue` for the same subject or affected component. Close the
+duplicate with a `resolution` naming the ticket that carries the real work, rather than investigating
+it twice.
 
 **Automation rule:** If a ticket is involved, you should usually:
 - `read` at the start
@@ -2471,7 +2628,8 @@ For tests specifically:
 | Long-running tool times out | For `mcp_run_action`/`mcp_run_agent`, use the tool's own `executionMode:"async"` and poll with a `controlAction:"status"` call (see "Tool Execution Lifecycle"). For other long tools without their own async, use `remits-cli tool --async true` and poll `remits-cli tool status --call-id <callId>`. `--timeout-ms` only adjusts the per-request HTTP timeout; it is not a substitute for async. |
 | Need to continue tracking a long Action or Agent after terminal disconnect | Read `./.remits-cli/tool-responses/<callId>.json` for the returned `actionRunId`/`agentRunId`/`sessionId`/`threadGroupingId`. Re-poll the run with a `controlAction:"status"` call carrying that `actionRunId`/`agentRunId`, or inspect the agent session via `mcp_ai_session_search` with the `sessionId`. |
 | Staged change has no effect in a live (non-CLI) run | Staged overrides resolve only under a CLI TestMode (`branchName`+`cliUserId`). Live webhooks and other non-CLI runtime paths still use the DB (trunk, or the account's subscribed variant). `commit` to make it durable. See "Component Resolution". |
-| Need to know an account's shape (type, parents, namespace, branch) | `mcp_account_view` → read `resolution` (`type`, `resolvedDatabaseName`, `relationships`, `componentBranch`) and top-level `componentBranches`. Never infer structure from the account's name. |
+| Need to know an account's shape (role, type, parents, namespace, branch) | Read `resolution` — from the repo's `account-info.json`, or `mcp_account_user_admin` `action:'account'` (cheap), or `mcp_account_view` (full inventory): `role`/`summary`, `type`, `resolvedDatabaseName`, `relationships`, `componentBranch`, plus top-level `componentBranches`. Never infer structure from the account's name. |
+| Need the account tree below an account, or its users | `mcp_account_user_admin` (`action:'hierarchy'` with a `depth`, or `action:'users'`). `account-info.json` deliberately carries only direct children plus counts. |
 | An account has two parents and you don't know which one a run used | `resolution.relationships` lists every link with its own `branchName`/`databaseName`/`domainName`. A membership-only account with several edges resolves **trunk and inherits nothing** until a path is named (`--as-account`, `--variant-branch`, or an edge host) — that is by design, not a bug. |
 | Documents missing / written to the wrong place | Compare `resolution.databaseName` (the account's own override) with `resolution.resolvedDatabaseName` (what is actually in effect), and check for a `databaseName` on one of the `relationships` edges. Data does not inherit; components do. |
 | A custom hostname resolves to an unexpected account | Compare `resolution.domainName` with `resolvedDomainName` and the edge `domainName`s. An **edge** host wins over the account's own host and additionally supplies the path travelled (which is what makes that edge's branch variants apply). |