@cat-factory/app 0.222.0 → 0.224.0

package/app/components/inputGate/InputGateNotice.vue

@@ -64,6 +64,10 @@ const ISSUE_KEYS = {
     title: 'inputGate.issue.success_criteria_missing.title',
     hint: 'inputGate.issue.success_criteria_missing.hint',
   },
+  required_field_missing: {
+    title: 'inputGate.issue.required_field_missing.title',
+    hint: 'inputGate.issue.required_field_missing.hint',
+  },
 } as const satisfies Record<InputGateIssueCode, { title: string; hint: string }>
 
 /**
@@ -87,16 +91,30 @@ const TONE_COPY: Record<InputGateTone, { title: string; body: string }> = {
 }
 const copy = computed(() => TONE_COPY[props.tone])
 
+/**
+ * The interpolation a finding's copy is rendered with. Only `required_field_missing` carries a
+ * `field`, and its copy is the one line that cannot be written without knowing which input is
+ * missing: a deployment registers its own task types, so the platform has no vocabulary for
+ * "the incident's severity" and names the field instead. The label is deployment-supplied
+ * English, exactly as a custom agent kind's is.
+ *
+ * A finding whose `field` is somehow absent still renders: the copy falls back to naming no
+ * field rather than printing `undefined` into a sentence a human is meant to act on.
+ */
+function issueValues(issue: InputGateIssue): Record<string, string> {
+  return { field: issue.field?.label ?? t('inputGate.issue.required_field_missing.unnamedField') }
+}
+
 /** A finding's translated title, falling back to the generic line for a retired code. */
-function issueTitle(code: InputGateIssueCode): string {
-  const key = ISSUE_KEYS[code]?.title
-  return key && te(key) ? t(key) : t('inputGate.issue.unknown.title')
+function issueTitle(issue: InputGateIssue): string {
+  const key = ISSUE_KEYS[issue.code]?.title
+  return key && te(key) ? t(key, issueValues(issue)) : t('inputGate.issue.unknown.title')
 }
 
 /** A finding's translated remedy hint, on the same fallback. */
-function issueHint(code: InputGateIssueCode): string {
-  const key = ISSUE_KEYS[code]?.hint
-  return key && te(key) ? t(key) : t('inputGate.issue.unknown.hint')
+function issueHint(issue: InputGateIssue): string {
+  const key = ISSUE_KEYS[issue.code]?.hint
+  return key && te(key) ? t(key, issueValues(issue)) : t('inputGate.issue.unknown.hint')
 }
 
 async function resolve(choice: 'recheck' | 'proceed') {
@@ -126,7 +144,11 @@ async function resolve(choice: 'recheck' | 'proceed') {
         <p v-if="!compact" class="text-muted mt-0.5 text-xs">{{ t(copy.body) }}</p>
 
         <ul class="mt-2 space-y-1.5">
-          <li v-for="issue in issues" :key="issue.code" class="flex items-start gap-2 text-xs">
+          <li
+            v-for="issue in issues"
+            :key="`${issue.code}:${issue.field?.key ?? ''}`"
+            class="flex items-start gap-2 text-xs"
+          >
             <UBadge
               :color="issue.severity === 'blocking' ? 'warning' : 'neutral'"
               variant="subtle"
@@ -139,8 +161,8 @@ async function resolve(choice: 'recheck' | 'proceed') {
               }}
             </UBadge>
             <span class="min-w-0">
-              <span class="font-medium">{{ issueTitle(issue.code) }}</span>
-              <span class="text-muted">, {{ issueHint(issue.code) }}</span>
+              <span class="font-medium">{{ issueTitle(issue) }}</span>
+              <span class="text-muted">, {{ issueHint(issue) }}</span>
             </span>
           </li>
         </ul>

package/app/components/panels/inspector/TaskTypeFields.vue

@@ -0,0 +1,115 @@
+<script setup lang="ts">
+// The answers to a CUSTOM task type's own declared fields, editable after creation.
+//
+// Why it exists: the create form is not the only door a task arrives through (the public API, an
+// initiative spawn, a tracker import), and a type's declaration can get STRICTER after a task
+// already exists. The pre-dispatch input gate judges the declaration as it stands now, so it
+// parks runs whose task predates the requirement. Without this panel that park had exactly one
+// exit, a human waiving the gate: `recheck` would re-read the same unanswered bag forever, and
+// the remedy the notice names ("fill it in on the task") would be one nothing offered.
+//
+// Renders through the SAME `DescriptorFields` component the create form uses, against the SAME
+// declaration, validated by the SAME shared rule. A field the form would have hidden by its
+// `showWhen` is hidden here too, so the two doors cannot show a person different questions.
+import { computed, ref, watch } from 'vue'
+import type { DescriptorFieldValues } from '@cat-factory/contracts'
+import { sanitizeDescriptorFields, validateDescriptorFields } from '@cat-factory/contracts'
+import type { Block } from '~/types/domain'
+import DescriptorFields from '~/components/common/DescriptorFields.vue'
+import InspectorSection from '~/components/panels/inspector/InspectorSection.vue'
+
+const props = defineProps<{ block: Block }>()
+
+const board = useBoardStore()
+const taskTypes = useTaskTypesStore()
+const { t } = useI18n()
+
+/** The registered type this task is, or undefined for a built-in / unregistered one. */
+const descriptor = computed(() =>
+  props.block.taskType
+    ? taskTypes.customTaskTypes.find((tt) => tt.taskType === props.block.taskType)
+    : undefined,
+)
+
+/**
+ * The fields to render. A type carrying a bespoke `formPanel` owns its whole bag, so its
+ * descriptor fields are not what was collected and editing them here would write values its own
+ * form never offered. That is the same stand-down the create door and the input gate take, and
+ * all three have to agree or "the declaration" would mean three different things.
+ */
+const fields = computed(() => (descriptor.value?.formPanel ? [] : (descriptor.value?.fields ?? [])))
+
+const stored = computed<DescriptorFieldValues>(() => props.block.taskTypeFields?.custom ?? {})
+
+// Local edit buffer, re-seeded whenever the stored bag changes underneath (a live board push, or
+// switching blocks). Editing writes on commit rather than per keystroke, so a half-typed answer
+// never reaches the row the gate reads.
+const draft = ref<DescriptorFieldValues>({ ...stored.value })
+watch(stored, (next) => {
+  draft.value = { ...next }
+})
+
+/**
+ * The same check the server runs, so the button reflects an invalid form rather than the save
+ * failing with a 422. Shared from contracts precisely so the two cannot drift.
+ */
+const problems = computed(() => validateDescriptorFields(fields.value, draft.value))
+
+const dirty = computed(
+  () =>
+    JSON.stringify(sanitizeDescriptorFields(fields.value, draft.value)) !==
+    JSON.stringify(stored.value),
+)
+
+const saving = ref(false)
+
+async function save() {
+  if (problems.value.length || !dirty.value) return
+  saving.value = true
+  try {
+    await board.updateBlock(props.block.id, {
+      customTaskTypeFields: sanitizeDescriptorFields(fields.value, draft.value),
+    })
+  } finally {
+    saving.value = false
+  }
+}
+
+function revert() {
+  draft.value = { ...stored.value }
+}
+</script>
+
+<template>
+  <InspectorSection
+    v-if="fields.length"
+    :title="t('inspector.taskTypeFields.title')"
+    :hint="t('inspector.taskTypeFields.hint')"
+    icon="i-lucide-clipboard-list"
+    :count="fields.length"
+  >
+    <DescriptorFields v-model="draft" :fields="fields" testid-prefix="task-type-field" />
+    <div v-if="dirty" class="mt-2 flex items-center gap-2">
+      <UButton
+        size="xs"
+        color="primary"
+        variant="soft"
+        :loading="saving"
+        :disabled="problems.length > 0"
+        data-testid="task-type-fields-save"
+        @click="save"
+      >
+        {{ t('inspector.taskTypeFields.save') }}
+      </UButton>
+      <UButton
+        size="xs"
+        color="neutral"
+        variant="ghost"
+        data-testid="task-type-fields-revert"
+        @click="revert"
+      >
+        {{ t('inspector.taskTypeFields.revert') }}
+      </UButton>
+    </div>
+  </InspectorSection>
+</template>

package/app/components/provisioning/ProvisioningLogsDrawer.vue

@@ -88,6 +88,7 @@ onBeforeUnmount(() => {
 const OPERATION_LABEL = computed<Record<ProvisioningOperation, string>>(() => ({
   provision: t('provisioning.operation.provision'),
   teardown: t('provisioning.operation.teardown'),
+  'teardown-verify': t('provisioning.operation.teardown-verify'),
   status: t('provisioning.operation.status'),
   dispatch: t('provisioning.operation.dispatch'),
   release: t('provisioning.operation.release'),

package/app/components/settings/CapabilityCredentialsPanel.vue

@@ -16,6 +16,7 @@
 import { computed, onMounted, reactive, ref } from 'vue'
 import type { CapabilityCredentialStatus } from '~/types/capabilityCredentials'
 import SecretInput from '~/components/common/SecretInput.vue'
+import ToolServerChecklist from '~/components/settings/ToolServerChecklist.vue'
 
 const { t, d } = useI18n()
 const store = useCapabilityCredentialsStore()
@@ -63,6 +64,19 @@ onMounted(async () => {
   }
 })
 
+// The tool-server inventory that renders above the checklist. Its own read (and its own failure
+// report, for the same reason): the two surfaces answer different questions off different endpoints,
+// so one failing must not blank the other. Both resolve the same 403, so this is only reached by a
+// caller the backend has already admitted.
+const toolServers = useToolServersStore()
+onMounted(async () => {
+  try {
+    await toolServers.load()
+  } catch (e) {
+    present(e, 'settings.toolServers.toast.loadFailed')
+  }
+})
+
 async function saveKey(key: string) {
   const value = (drafts[key] ?? '').trim()
   if (!value) return
@@ -99,6 +113,11 @@ async function removeKey(key: string) {
 
 <template>
   <div class="space-y-4" data-testid="capability-credentials-panel">
+    <!-- The servers FIRST, because they are what the keys below authenticate: a bare list of
+         variable names does not tell an operator which of them matters, and the Test button is the
+         only thing on either surface that can say whether the value they typed works. -->
+    <ToolServerChecklist />
+
     <p class="text-sm text-slate-400">
       {{ t('settings.capabilityCredentials.intro') }}
     </p>

package/app/components/settings/InfrastructureWindow.vue

@@ -15,10 +15,11 @@
 //   - "Package registries" — the private npm registries a checkout installs from (formerly an
 //     Integrations-hub row). What a container can resolve its dependencies from is part of the
 //     execution environment, not an optional external system a workspace links in.
-//   - "Capability credentials" — the sealed per-workspace values behind the secrets a registered
-//     tool server (MCP) or generative binary integration declares. What an agent's tools
-//     authenticate as belongs beside where those agents run, and it is `secrets.manage`-only, so
-//     the tab is HIDDEN rather than disabled for anyone without that permission.
+//   - "Capability credentials" — the deployment's tool servers (MCP) with a Test button each, above
+//     the sealed per-workspace values behind the secrets a registered tool server or generative
+//     binary integration declares. What an agent's tools authenticate as belongs beside where those
+//     agents run, and it is `secrets.manage`-only (the READ included, since both halves name the
+//     deployment's credential keys), so the tab is HIDDEN rather than disabled for anyone else.
 // Local-specific affordances render inline, gated on `auth.localMode?.enabled`. A tab whose
 // backend integration is disabled (503) simply doesn't render.
 import { computed, ref, watch } from 'vue'
@@ -43,6 +44,7 @@ const store = useProviderConnectionsStore()
 const auth = useAuthStore()
 const packageRegistries = usePackageRegistriesStore()
 const capabilityCredentials = useCapabilityCredentialsStore()
+const toolServers = useToolServersStore()
 const { canManageSecrets } = useWorkspaceAccess()
 
 const open = computed({
@@ -93,7 +95,14 @@ const tabs = computed(() =>
     // the backend gates the read too), and `hasSurface` hides a tab with nothing in it — the
     // panel is a checklist projected from the deployment's registered capabilities, so a build
     // that registers none has no credential to type.
-    capabilityCredentials: canManageSecrets.value && capabilityCredentials.hasSurface,
+    //
+    // EITHER surface earns the tab. A tool server that declares no credential has nothing on the
+    // checklist, and gating the tab on the checklist alone would leave the one server an operator
+    // most wants to test unreachable — while a credential whose capability is a generative
+    // integration has no tool-server row. Two questions, one tab, and neither is a subset of the
+    // other.
+    capabilityCredentials:
+      canManageSecrets.value && (capabilityCredentials.hasSurface || toolServers.hasSurface),
   }).map((value) => ({
     value,
     label: TAB_LABELS.value[value],
@@ -121,7 +130,10 @@ watch(
     // window must still open), reported by the panel, which can only do that once its tab exists.
     // Not probed at all without the permission — the backend would refuse it, and asking would
     // put a 403 in every member's console on every open.
-    if (canManageSecrets.value) void capabilityCredentials.ensureLoaded().catch(() => {})
+    if (canManageSecrets.value) {
+      void capabilityCredentials.ensureLoaded().catch(() => {})
+      void toolServers.ensureLoaded().catch(() => {})
+    }
     activeTab.value = openInfrastructureTab(tabValues.value, ui.infrastructureTab)
   },
   { immediate: true },

package/app/components/settings/ToolServerChecklist.vue

@@ -0,0 +1,264 @@
+<script setup lang="ts">
+// Tool servers (MCP) — the deployment's registered servers, and a Test button that speaks the
+// protocol to one.
+//
+// It sits ABOVE the credential checklist in the same tab, because it is what the credentials on that
+// list are FOR: the checklist answers "which keys does this deployment want", and this answers "and
+// does the server they authenticate actually work". Both are `secrets.manage`-only, which is why the
+// tab is hidden rather than disabled for anyone else.
+//
+// A row states four independent reasons a declared server may never reach a run — no kind declares
+// it, no harness can serve its transport, its credentials do not resolve, the endpoint is dead — and
+// each is rendered rather than implied. Before this panel the first two lived in a boot log and the
+// deployment's own source, and the last two were only visible by starting a run and reading the
+// agent's prompt.
+import { computed, ref } from 'vue'
+import type {
+  ToolServerNotProbeableReason,
+  ToolServerProbeStatus,
+  ToolServerTransport,
+  ToolServerView,
+} from '~/types/toolServers'
+
+const { t } = useI18n()
+const store = useToolServersStore()
+const { present } = usePipelineErrorToast()
+
+// Which failure DETAILS are expanded, by server id. Collapsed by default: the translated status line
+// is what an operator acts on, and the raw backend prose is a disclosure behind it (never the
+// primary description) per the i18n rule.
+const expanded = ref<Record<string, boolean>>({})
+
+// Exhaustive Records over the wire vocabularies, so a member added in `@cat-factory/contracts` fails
+// to compile here until it has translated copy. The sanctioned guard for an enum-keyed lookup the
+// typed-message-key check cannot see.
+const TRANSPORT_LABELS = computed<Record<ToolServerTransport, string>>(() => ({
+  stdio: t('settings.toolServers.transport.stdio'),
+  http: t('settings.toolServers.transport.http'),
+}))
+const STATUS_LABELS = computed<Record<ToolServerProbeStatus, string>>(() => ({
+  ok: t('settings.toolServers.status.ok'),
+  credentials_missing: t('settings.toolServers.status.credentialsMissing'),
+  credential_refused: t('settings.toolServers.status.credentialRefused'),
+  unreachable: t('settings.toolServers.status.unreachable'),
+  http_error: t('settings.toolServers.status.httpError'),
+  protocol_error: t('settings.toolServers.status.protocolError'),
+  not_probeable: t('settings.toolServers.status.notProbeable'),
+}))
+const NOT_PROBEABLE_LABELS = computed<Record<ToolServerNotProbeableReason, string>>(() => ({
+  stdio_transport: t('settings.toolServers.notProbeable.stdio'),
+  container_local_url: t('settings.toolServers.notProbeable.containerLocal'),
+  url_not_allowed: t('settings.toolServers.notProbeable.urlNotAllowed'),
+}))
+
+const servers = computed<ToolServerView[]>(() => store.view?.servers ?? [])
+
+function resultFor(id: string) {
+  return store.results[id]
+}
+
+/** Success is the only green; every other verdict names something for the operator to fix. */
+function statusColor(status: ToolServerProbeStatus): 'success' | 'warning' | 'error' {
+  if (status === 'ok') return 'success'
+  return status === 'not_probeable' ? 'warning' : 'error'
+}
+
+async function runProbe(id: string) {
+  try {
+    await store.probe(id)
+  } catch (e) {
+    // A THROWN failure is not a verdict — a 404 for a server the deployment has since dropped, or a
+    // transient 5xx. Presented through the shared status-class funnel rather than stored as a
+    // result, so the row does not claim the probe answered.
+    present(e, 'settings.toolServers.toast.probeFailed')
+  }
+}
+</script>
+
+<template>
+  <section v-if="servers.length" class="space-y-3" data-testid="tool-servers-section">
+    <div>
+      <h3 class="text-sm font-semibold text-slate-200">
+        {{ t('settings.toolServers.heading') }}
+      </h3>
+      <p class="text-xs text-slate-400">{{ t('settings.toolServers.intro') }}</p>
+    </div>
+
+    <article
+      v-for="server in servers"
+      :key="server.id"
+      class="space-y-2 rounded-lg border border-slate-700 p-3"
+      :data-testid="`tool-server-${server.id}`"
+    >
+      <div class="flex flex-wrap items-center gap-2">
+        <span class="text-sm font-medium text-slate-200">{{ server.label }}</span>
+        <UBadge color="neutral" variant="soft" size="sm">
+          {{ TRANSPORT_LABELS[server.transport] }}
+        </UBadge>
+        <code class="font-mono text-[11px] text-slate-500">{{ server.id }}</code>
+      </div>
+
+      <p class="truncate font-mono text-[11px] text-slate-500" :title="server.target">
+        {{ server.target }}
+      </p>
+      <p v-if="server.guidance" class="text-xs text-slate-400">{{ server.guidance }}</p>
+
+      <!-- Which agents get it. An EMPTY list is a registration attached to nothing: it never reaches
+           a dispatch, so the credentials it asks for are keys an operator fills in for no run. Said
+           out loud, because no other surface in the platform can see that state. -->
+      <p v-if="server.declaredBy.length" class="text-[11px] text-slate-400">
+        {{ t('settings.toolServers.declaredBy', { kinds: server.declaredBy.join(', ') }) }}
+      </p>
+      <p v-else class="text-[11px] text-amber-400" :data-testid="`tool-server-orphan-${server.id}`">
+        {{ t('settings.toolServers.declaredByNone') }}
+      </p>
+
+      <!-- Which harnesses could serve it. EMPTY means the declaration can never run anywhere (an
+           `http` server narrowed to Codex, whose MCP client is stdio-only): it is never dropped FOR
+           A REASON on any run, so no prompt and no log line ever mentions it. -->
+      <p v-if="server.servableHarnesses.length" class="text-[11px] text-slate-400">
+        {{
+          t('settings.toolServers.servableHarnesses', {
+            harnesses: server.servableHarnesses.join(', '),
+          })
+        }}
+      </p>
+      <p v-else class="text-[11px] text-amber-400">
+        {{ t('settings.toolServers.servableHarnessesNone') }}
+      </p>
+
+      <p v-if="server.allowedTools?.length" class="text-[11px] text-slate-400">
+        {{ t('settings.toolServers.allowedTools', { tools: server.allowedTools.join(', ') }) }}
+      </p>
+      <p v-if="server.credentials.length" class="text-[11px] text-slate-400">
+        {{
+          t('settings.toolServers.credentials', {
+            keys: server.credentials.map((c) => c.key).join(', '),
+          })
+        }}
+      </p>
+
+      <div class="flex flex-wrap items-center gap-2 pt-1">
+        <UButton
+          v-if="server.probeable"
+          size="xs"
+          variant="subtle"
+          icon="i-lucide-plug"
+          :loading="store.probing === server.id"
+          :disabled="store.probing !== null"
+          :data-testid="`tool-server-test-${server.id}`"
+          @click="runProbe(server.id)"
+        >
+          {{ t('settings.toolServers.test') }}
+        </UButton>
+        <!-- Not a disabled button: nothing the operator can do here makes it clickable, so the row
+             states the reason instead. Each reason needs a different response — nothing to fix,
+             verify it from a run, or change the declaration. -->
+        <p
+          v-else-if="server.notProbeableReason"
+          class="text-[11px] text-slate-500"
+          :data-testid="`tool-server-unprobeable-${server.id}`"
+        >
+          {{ NOT_PROBEABLE_LABELS[server.notProbeableReason] }}
+        </p>
+      </div>
+
+      <div
+        v-if="resultFor(server.id)"
+        class="space-y-1 rounded-md border border-slate-800 bg-slate-900/40 p-2"
+        :data-testid="`tool-server-result-${server.id}`"
+      >
+        <div class="flex flex-wrap items-center gap-2">
+          <UBadge
+            :color="statusColor(resultFor(server.id)!.status)"
+            variant="soft"
+            size="sm"
+            :data-testid="`tool-server-status-${server.id}`"
+          >
+            {{ STATUS_LABELS[resultFor(server.id)!.status] }}
+          </UBadge>
+          <span v-if="resultFor(server.id)!.httpStatus" class="text-[11px] text-slate-400">
+            {{ t('settings.toolServers.httpStatus', { status: resultFor(server.id)!.httpStatus }) }}
+          </span>
+        </div>
+
+        <p v-if="resultFor(server.id)!.status === 'ok'" class="text-[11px] text-slate-300">
+          {{
+            t('settings.toolServers.okDetail', {
+              name: resultFor(server.id)!.serverName || server.id,
+              version: resultFor(server.id)!.serverVersion || '?',
+              protocol: resultFor(server.id)!.protocolVersion ?? '?',
+              count: resultFor(server.id)!.toolCount ?? 0,
+            })
+          }}
+        </p>
+        <!-- A count off a truncated read is a FLOOR, not a total, and the difference decides whether
+             the allowedTools verdict below means anything. -->
+        <p v-if="resultFor(server.id)!.toolsComplete === false" class="text-[11px] text-slate-500">
+          {{ t('settings.toolServers.toolsIncomplete') }}
+        </p>
+
+        <!-- The reconciliation nothing else in the platform can do: a well-formed tool name that
+             matches nothing narrows the CLI's allow-list to a dead pattern while the prompt keeps
+             advertising the tool. Withheld entirely when the tool list was a prefix. -->
+        <p
+          v-if="resultFor(server.id)!.allowedTools?.unmatched?.length"
+          class="text-[11px] text-amber-400"
+          :data-testid="`tool-server-unmatched-${server.id}`"
+        >
+          {{
+            t('settings.toolServers.unmatchedTools', {
+              tools: resultFor(server.id)!.allowedTools!.unmatched.join(', '),
+            })
+          }}
+        </p>
+        <p
+          v-else-if="resultFor(server.id)!.allowedTools?.checked === false"
+          class="text-[11px] text-slate-500"
+        >
+          {{ t('settings.toolServers.allowedToolsUnchecked') }}
+        </p>
+
+        <p
+          v-if="resultFor(server.id)!.unresolvedCredentials?.length"
+          class="text-[11px] text-amber-400"
+        >
+          {{
+            t('settings.toolServers.unresolvedCredentials', {
+              keys: resultFor(server.id)!.unresolvedCredentials!.join(', '),
+            })
+          }}
+        </p>
+        <p v-if="resultFor(server.id)!.refusedCredentials?.length" class="text-[11px] text-red-400">
+          {{
+            t('settings.toolServers.refusedCredentials', {
+              keys: resultFor(server.id)!.refusedCredentials!.join(', '),
+            })
+          }}
+        </p>
+
+        <!-- Raw backend prose is DETAIL behind a disclosure, never the primary description. It is
+             already scrubbed through `redactSecrets` at the emit site. -->
+        <template v-if="resultFor(server.id)!.error">
+          <UButton
+            size="xs"
+            variant="link"
+            class="px-0"
+            :data-testid="`tool-server-details-${server.id}`"
+            @click="expanded[server.id] = !expanded[server.id]"
+          >
+            {{
+              expanded[server.id]
+                ? t('settings.toolServers.hideDetails')
+                : t('settings.toolServers.showDetails')
+            }}
+          </UButton>
+          <pre
+            v-if="expanded[server.id]"
+            class="overflow-x-auto rounded bg-slate-950 p-2 font-mono text-[10px] text-slate-400"
+            >{{ resultFor(server.id)!.error }}</pre>
+        </template>
+      </div>
+    </article>
+  </section>
+</template>

package/app/composables/api/toolServers.ts

@@ -0,0 +1,21 @@
+import { listToolServersContract, probeToolServerContract } from '@cat-factory/contracts'
+import type { ApiContext } from './context'
+
+/**
+ * Per-workspace tool-server (MCP) operability: the inventory of what this deployment declared, and
+ * a probe that speaks the protocol to one of them.
+ *
+ * `secrets.manage`-gated end to end, the READ included — the inventory names the credential keys the
+ * deployment's capabilities want and the endpoints those credentials are sent to. The probe is a
+ * POST because it SPENDS an outbound request under the deployment's own credential, so it must not
+ * be safe to retry from a cache or a prefetch. See ToolServerController.
+ */
+export function toolServersApi({ send, ws }: ApiContext) {
+  return {
+    listToolServers: (workspaceId: string) =>
+      send(listToolServersContract, { pathPrefix: ws(workspaceId) }),
+
+    probeToolServer: (workspaceId: string, id: string) =>
+      send(probeToolServerContract, { pathPrefix: ws(workspaceId), pathParams: { id } }),
+  }
+}

package/app/composables/useApi.ts

@@ -33,6 +33,7 @@ import { modelsApi } from './api/models'
 import { notificationsApi } from './api/notifications'
 import { packageRegistriesApi } from './api/packageRegistries'
 import { capabilityCredentialsApi } from './api/capabilityCredentials'
+import { toolServersApi } from './api/toolServers'
 import { preflightsApi } from './api/preflights'
 import { presetsApi } from './api/presets'
 import { publicApiKeysApi } from './api/publicApiKeys'
@@ -156,6 +157,7 @@ export function useApi() {
     ...testSecretsApi(ctx),
     ...packageRegistriesApi(ctx),
     ...capabilityCredentialsApi(ctx),
+    ...toolServersApi(ctx),
     ...previewApi(ctx),
     ...environmentsApi(ctx),
     ...recurringApi(ctx),

package/app/modular/panels/inspector.logic.spec.ts

@@ -97,6 +97,11 @@ describe('inspector panel group', () => {
       'task-dependencies',
       'task-run-settings',
       'task-agent-config',
+      // The custom type's own declared fields sit with the other task INPUTS (what the task is),
+      // not under run settings (how it runs). It is gated on being a task alone: the panel hides
+      // itself unless the type is one this deployment registered with descriptor fields, which
+      // the spec here cannot see and should not try to.
+      'task-type-fields',
       'task-structure',
     ])
   })

package/app/modular/panels/inspector.logic.ts

@@ -45,6 +45,7 @@ export const INSPECTOR_PANEL_IDS = [
   'task-dependencies',
   'task-run-settings',
   'task-agent-config',
+  'task-type-fields',
   'task-structure',
   // service / module body
   'container-summary',
@@ -134,6 +135,11 @@ export const INSPECTOR_PANEL_SPECS: readonly InspectorPanelSpec[] = [
   { id: 'task-dependencies', order: 60, when: isTask },
   { id: 'task-run-settings', order: 70, when: isTask },
   { id: 'task-agent-config', order: 80, when: isTask },
+  // The answers to a CUSTOM task type's declared fields. Gated on being a task alone; the panel
+  // itself hides unless the task's type is one this deployment registered WITH descriptor fields,
+  // which is the only case there is anything to edit. It sits beside the other task inputs rather
+  // than under Run settings: these are what the task IS, not how it runs.
+  { id: 'task-type-fields', order: 85, when: isTask },
   { id: 'task-structure', order: 90, when: isTask },
   { id: 'container-summary', order: 110, when: isContainer },
   { id: 'frontend-config', order: 120, when: (b) => isFrame(b) && b.type === 'frontend' },

package/app/modular/panels/inspector.ts

@@ -21,6 +21,7 @@ import TaskEstimateBadge from '~/components/panels/inspector/TaskEstimateBadge.v
 import TaskDependencies from '~/components/panels/inspector/TaskDependencies.vue'
 import TaskRunSettings from '~/components/panels/inspector/TaskRunSettings.vue'
 import TaskAgentConfig from '~/components/panels/inspector/TaskAgentConfig.vue'
+import TaskTypeFields from '~/components/panels/inspector/TaskTypeFields.vue'
 import TaskStructure from '~/components/panels/inspector/TaskStructure.vue'
 import ContainerSummary from '~/components/panels/inspector/ContainerSummary.vue'
 import FrontendConfig from '~/components/panels/inspector/FrontendConfig.vue'
@@ -75,6 +76,7 @@ const COMPONENTS: Record<InspectorPanelId, Component> = {
   'task-dependencies': TaskDependencies,
   'task-run-settings': TaskRunSettings,
   'task-agent-config': TaskAgentConfig,
+  'task-type-fields': TaskTypeFields,
   'task-structure': TaskStructure,
   'container-summary': ContainerSummary,
   'frontend-config': FrontendConfig,