@jam-mcp/server 1.3.1 → 1.3.2

package/README.md

@@ -74,10 +74,10 @@ auth login   Store Jira credentials in this user's OS secret store
 runtime      Show or change which JAM build this machine runs
 ```
 
-Written out, that is `npx --yes @jam-mcp/launcher@1.3.1 doctor`, or just `jam
+Written out, that is `npx --yes @jam-mcp/launcher@1.3.2 doctor`, or just `jam
 doctor` if you took the launcher's optional global install. Starting from
 nothing — no install, no runtime chosen yet — use
-`npx --yes @jam-mcp/bootstrap@1.3.1 init` instead.
+`npx --yes @jam-mcp/bootstrap@1.3.2 init` instead.
 
 Credentials come from the process environment or this user's OS secret store —
 never from a repository file — and never appear in logs, telemetry, or tool

package/dist/adapters/jira-cloud/jira-read.adapter.js

@@ -45,21 +45,11 @@ export class JiraCloudReadAdapter {
         // Read straight off the raw payload rather than through the mapper: the
         // mapper's job is the shape the read tools see, and this identity is only
         // for the write plane. Raw DTOs still stop here.
-        const raw = data.fields;
-        const assignee = raw?.["assignee"];
+        const assignee = data.fields?.assignee;
         const accountId = typeof assignee?.accountId === "string" ? assignee.accountId : undefined;
-        // Only the ids that were asked for, and only when some were: a caller that
-        // did not request a custom field gets no entry rather than an empty object
-        // it has to tell apart from a field that is genuinely unset.
-        const customFieldValues = {};
-        for (const field of req.fields) {
-            if (field.startsWith("customfield_"))
-                customFieldValues[field] = raw?.[field] ?? null;
-        }
         return {
             issue: mapIssueWithMeta(data, this.config).issue,
             ...(accountId ? { assigneeAccountId: accountId } : {}),
-            ...(Object.keys(customFieldValues).length > 0 ? { customFieldValues } : {}),
             responseBytes: bytes,
         };
     }

package/dist/application/apply-write.js

@@ -1,10 +1,9 @@
 import { JamError, toJamError } from "../domain/errors.js";
 import { readModeAfterWrite } from "../policy/consistency-policy.js";
 import { assertAssignable } from "../policy/assignee-policy.js";
-import { assertCustomFieldUnchanged } from "../policy/custom-field-policy.js";
 import { assertUnchanged } from "../policy/write-policy.js";
 import { applyCreateIssue } from "./apply-create-issue.js";
-import { currentCustomFieldView, readIssue } from "./plan-write.js";
+import { readIssue } from "./plan-write.js";
 /**
  * Execute a plan JAM made, then go and look at what happened.
  *
@@ -63,18 +62,10 @@ export async function applyWritePlan(deps, request) {
  * own state, which `assertUnchanged` already compared.
  */
 async function revalidate(deps, plan) {
-    if (plan.mutation.kind === "assignee") {
-        const target = plan.intendedAfter["assignee"];
-        assertAssignable(plan.issueKey, target, await deps.jiraAssignees.isAssignable(plan.issueKey, plan.mutation.accountId));
+    if (plan.mutation.kind !== "assignee")
         return;
-    }
-    if (plan.mutation.kind === "custom-field" && plan.customFieldRequirements) {
-        // A field can be taken off a screen, lose its `set` operation, change type
-        // or have an option renamed without the issue's own revision moving, so
-        // `assertUnchanged` cannot see any of it. These are the premises the plan
-        // actually rested on, re-derived.
-        assertCustomFieldUnchanged(plan.issueKey, plan.customFieldRequirements, await deps.jiraEditMetadata.getEditableFields(plan.issueKey));
-    }
+    const target = plan.intendedAfter["assignee"];
+    assertAssignable(plan.issueKey, target, await deps.jiraAssignees.isAssignable(plan.issueKey, plan.mutation.accountId));
 }
 /**
  * Send the mutation, once.
@@ -101,14 +92,6 @@ async function mutate(deps, plan) {
             case "assignee":
                 await deps.jiraWrite.assignIssue(plan.issueKey, plan.mutation.accountId);
                 return {};
-            case "custom-field":
-                // The ordinary issue edit endpoint. A custom field is a field; what
-                // made it need its own operation was deciding whether it may be
-                // written and in what shape, and that is already settled here.
-                await deps.jiraWrite.updateIssue(plan.issueKey, {
-                    [plan.mutation.fieldId]: plan.mutation.value,
-                });
-                return {};
             case "create":
                 // Unreachable: a create plan is routed to applyCreateIssue above. The
                 // case exists so adding a mutation kind is a compile error here rather
@@ -141,7 +124,7 @@ function isAmbiguous(err) {
  * ours.
  */
 async function verify(deps, plan) {
-    const snapshot = await readIssue(deps, plan.issueKey, plan.mutation.kind === "custom-field" ? [plan.mutation.fieldId] : []);
+    const snapshot = await readIssue(deps, plan.issueKey);
     const issue = snapshot.issue;
     if (plan.mutation.kind === "assignee") {
         // On the accountId, never on the display name. Two people can share a
@@ -173,15 +156,6 @@ async function verify(deps, plan) {
         }
         return { comments: comments.length, commentAdded: wanted };
     }
-    if (plan.mutation.kind === "custom-field" && plan.customFieldRequirements) {
-        const requirements = plan.customFieldRequirements;
-        const expected = plan.intendedAfter["customField"];
-        const observedValue = currentCustomFieldView({ id: requirements.fieldId, name: requirements.fieldName }, requirements.kind, snapshot.customFieldValues?.[requirements.fieldId]);
-        if (!sameCustomFieldValue(requirements.kind, expected.value, observedValue.value)) {
-            throw verificationFailed(plan, { customField: expected }, { customField: observedValue });
-        }
-        return { customField: observedValue };
-    }
     const observed = observedFor(plan, issue);
     for (const [field, expected] of Object.entries(plan.intendedAfter)) {
         if (!sameValue(observed[field], expected)) {
@@ -215,27 +189,6 @@ function observedFor(plan, issue) {
     }
     return observed;
 }
-/**
- * Did the field end up holding what was planned?
- *
- * Options are compared on their ids, never on their labels - an option is
- * identified by its id, and a label is what a person reads. For a multi-select
- * the comparison is set-wise: Jira is free to return the same selection in a
- * different order, and that is not a different selection.
- */
-function sameCustomFieldValue(kind, expected, observed) {
-    if (kind === "multi-option") {
-        const ids = (v) => (Array.isArray(v) ? v.map((o) => o.id) : []).sort();
-        const a = ids(expected);
-        const b = ids(observed);
-        return a.length === b.length && a.every((id, i) => id === b[i]);
-    }
-    if (kind === "single-option") {
-        const id = (v) => v && typeof v === "object" && !Array.isArray(v) ? v.id : undefined;
-        return id(expected) === id(observed);
-    }
-    return expected === observed;
-}
 function sameValue(observed, expected) {
     if (Array.isArray(expected) || Array.isArray(observed)) {
         const a = Array.isArray(observed) ? [...observed].map(String).sort() : [];

package/dist/application/plan-write.d.ts

@@ -1,6 +1,6 @@
 import type { JamDeps } from "../deps.js";
 import type { FullIssueContext } from "../domain/context.js";
-import type { CustomFieldKind, CustomFieldValueView, WritePlan, WritePlanReceipt } from "../domain/write.js";
+import type { WritePlan, WritePlanReceipt } from "../domain/write.js";
 export type PlanWriteRequest = {
     /** Absent for `issue.create`, which names a project rather than an issue. */
     key?: string;
@@ -40,18 +40,5 @@ export type IssueSnapshot = {
     issue: FullIssueContext;
     /** Identity of the current assignee, which `issue.assignee` cannot supply. */
     assigneeAccountId?: string;
-    /** Raw values for any custom field ids that were asked for. */
-    customFieldValues?: Record<string, unknown>;
 };
-export declare function readIssue(deps: JamDeps, issueKey: string, extraFields?: string[]): Promise<IssueSnapshot>;
-/**
- * What the field holds now, in the shape a receipt shows.
- *
- * Jira stores an option as an object and a scalar as itself; a person reading
- * `before` wants the same canonical form they will see in `intendedAfter`, so
- * they can compare the two rather than a payload against a summary.
- */
-export declare function currentCustomFieldView(field: {
-    id: string;
-    name: string;
-}, kind: CustomFieldKind, raw: unknown): CustomFieldValueView;
+export declare function readIssue(deps: JamDeps, issueKey: string): Promise<IssueSnapshot>;

package/dist/application/plan-write.js

@@ -1,7 +1,6 @@
 import { JamError } from "../domain/errors.js";
 import { assertExistingIssueOperation, assertFieldsAllowed, assertOperationAllowed, assertWriteScope, PLAN_TTL_MS, resolveTransition, } from "../policy/write-policy.js";
 import { assertAssignable, assertNotAlreadyAssigned, exactMatches, resolveAssignee, } from "../policy/assignee-policy.js";
-import { assertEditable, classifyKind, resolveCustomFieldValue, resolveWritableField, } from "../policy/custom-field-policy.js";
 import { planCreateIssue } from "./plan-create-issue.js";
 /**
  * Work out whether a requested change is currently possible, and describe it.
@@ -32,15 +31,9 @@ export async function planWrite(deps, request) {
     // does not write should get that answer, not a round trip and then that
     // answer.
     const input = validateInput(operation, request.input);
-    // Which custom field the whitelist says this is, settled before the read so
-    // the read can fetch its current value in the same request. A selector the
-    // team never opted in costs no Jira call at all.
-    const targetField = operation === "custom-field.update"
-        ? resolveWritableField(deps.config, input.field)
-        : undefined;
-    const snapshot = await readIssue(deps, issueKey, targetField ? [targetField.id] : []);
+    const snapshot = await readIssue(deps, issueKey);
     const issue = snapshot.issue;
-    const { before, intendedAfter, mutation, transition, baseAssigneeAccountId, customFieldRequirements } = await describe(deps, operation, issueKey, snapshot, input, targetField);
+    const { before, intendedAfter, mutation, transition, baseAssigneeAccountId } = await describe(deps, operation, issueKey, snapshot, input);
     const createdAt = new Date();
     const plan = deps.writePlans.create({
         kind: "existing-issue",
@@ -54,7 +47,6 @@ export async function planWrite(deps, request) {
         expiresAt: new Date(createdAt.getTime() + PLAN_TTL_MS).toISOString(),
         ...(transition ? { transition } : {}),
         ...(baseAssigneeAccountId ? { baseAssigneeAccountId } : {}),
-        ...(customFieldRequirements ? { customFieldRequirements } : {}),
         mutation,
     });
     return {
@@ -71,8 +63,8 @@ export async function planWrite(deps, request) {
         },
     };
 }
-export async function readIssue(deps, issueKey, extraFields = []) {
-    const { issue: found, assigneeAccountId, customFieldValues } = await deps.jira.getIssue({
+export async function readIssue(deps, issueKey) {
+    const { issue: found, assigneeAccountId } = await deps.jira.getIssue({
         key: issueKey,
         // `issuetype` and `description` are here for creation's verification step,
         // which has to confirm the issue Jira made is the one that was asked for.
@@ -89,33 +81,13 @@ export async function readIssue(deps, issueKey, extraFields = []) {
             "labels",
             "components",
             "updated",
-            // A custom field is only read when one is being written, and then only
-            // that one - so a custom-field update still costs a single direct GET
-            // rather than a second read for the field it is about to change.
-            ...extraFields.filter((f) => !BASE_WRITE_FIELDS.has(f)),
         ],
     });
     if (!found) {
         throw new JamError("ISSUE_NOT_FOUND", `Jira has no issue ${issueKey}, or it is not visible to this account.`, { issueKey });
     }
-    return {
-        issue: found,
-        ...(assigneeAccountId ? { assigneeAccountId } : {}),
-        ...(customFieldValues ? { customFieldValues } : {}),
-    };
+    return { issue: found, ...(assigneeAccountId ? { assigneeAccountId } : {}) };
 }
-/** Requested on every write-plane read, so an extra field is never a duplicate. */
-const BASE_WRITE_FIELDS = new Set([
-    "summary",
-    "status",
-    "issuetype",
-    "description",
-    "assignee",
-    "priority",
-    "labels",
-    "components",
-    "updated",
-]);
 /**
  * The issue an existing-issue operation names, or a refusal that says why.
  *
@@ -156,30 +128,6 @@ function validateInput(operation, raw) {
             }
             return { status: status.trim() };
         }
-        case "custom-field.update": {
-            // Anything outside this operation's own two keys is refused rather than
-            // ignored. Silently dropping a key an agent supplied is how a caller
-            // ends up with a write that is not the one it described - and the shared
-            // input object means another operation's key is a plausible mistake.
-            const extra = Object.keys(raw).filter((k) => raw[k] !== undefined && k !== "field" && k !== "value");
-            if (extra.length > 0) {
-                throw new JamError("JAM_WRITE_FIELD_NOT_ALLOWED", `custom-field.update takes only \`field\` and \`value\`. Remove: ${extra.join(", ")}.`, { operation, rejected: extra });
-            }
-            const { field, value } = raw;
-            if (typeof field !== "string" || field.trim().length === 0) {
-                throw new JamError("JAM_WRITE_OPERATION_NOT_ALLOWED", "custom-field.update needs non-empty `input.field` - a configured custom field id or name.", { operation });
-            }
-            // The value's family is checked against Jira's schema later; what is
-            // checked here is that it is a shape the contract admits at all. An
-            // object, a boolean or a null never reaches the type policy.
-            const isString = typeof value === "string";
-            const isNumber = typeof value === "number";
-            const isStringArray = Array.isArray(value) && value.every((v) => typeof v === "string");
-            if (!isString && !isNumber && !isStringArray) {
-                throw new JamError("JAM_WRITE_OPERATION_NOT_ALLOWED", "custom-field.update needs `input.value` to be a string, a number, or an array of strings.", { operation, received: Array.isArray(value) ? "array" : typeof value });
-            }
-            return { field: field.trim(), value };
-        }
         case "assignee.update": {
             const assignee = raw.assignee;
             if (typeof assignee !== "string" || assignee.trim().length === 0) {
@@ -189,7 +137,7 @@ function validateInput(operation, raw) {
         }
     }
 }
-async function describe(deps, operation, issueKey, snapshot, input, targetField) {
+async function describe(deps, operation, issueKey, snapshot, input) {
     const issue = snapshot.issue;
     switch (operation) {
         case "comment.add": {
@@ -230,31 +178,6 @@ async function describe(deps, operation, issueKey, snapshot, input, targetField)
                 transition,
             };
         }
-        case "custom-field.update": {
-            const field = targetField;
-            const requested = input;
-            // Jira decides what is editable here and now, and in what shape. JAM
-            // does not model project contexts, screens or permissions - it asks the
-            // one endpoint that answers all three at once for this issue.
-            const metadata = await deps.jiraEditMetadata.getEditableFields(issueKey);
-            const editable = assertEditable(issueKey, field, metadata);
-            const kind = classifyKind(editable);
-            const { jiraValue, view, resolvedOptions } = resolveCustomFieldValue(editable, kind, requested);
-            return {
-                before: {
-                    customField: currentCustomFieldView(field, kind, snapshot.customFieldValues?.[field.id]),
-                },
-                intendedAfter: { customField: view },
-                mutation: { kind: "custom-field", fieldId: field.id, value: jiraValue },
-                customFieldRequirements: {
-                    fieldId: field.id,
-                    fieldName: field.name,
-                    kind,
-                    schema: editable.schema,
-                    ...(resolvedOptions ? { resolvedOptions } : {}),
-                },
-            };
-        }
         case "assignee.update": {
             const { assignee: requested } = input;
             // Ask Jira who this is, and decide from what it says. The requested
@@ -317,31 +240,6 @@ function currentValue(issue, field) {
             return undefined;
     }
 }
-/**
- * What the field holds now, in the shape a receipt shows.
- *
- * Jira stores an option as an object and a scalar as itself; a person reading
- * `before` wants the same canonical form they will see in `intendedAfter`, so
- * they can compare the two rather than a payload against a summary.
- */
-export function currentCustomFieldView(field, kind, raw) {
-    const named = { id: field.id, name: field.name };
-    if (kind === "multi-option") {
-        return { ...named, value: Array.isArray(raw) ? raw.map(toOptionView) : [] };
-    }
-    if (kind === "single-option") {
-        return { ...named, value: raw == null ? null : toOptionView(raw) };
-    }
-    if (raw == null)
-        return { ...named, value: null };
-    return { ...named, value: kind === "number" ? Number(raw) : String(raw) };
-}
-function toOptionView(raw) {
-    const o = raw;
-    const id = typeof o?.id === "string" ? o.id : typeof o?.id === "number" ? String(o.id) : "";
-    const label = typeof o?.value === "string" ? o.value : typeof o?.name === "string" ? o.name : String(raw);
-    return { id, label };
-}
 /** Whitelisted values to the shapes Jira's field API expects. */
 function toJiraFields(input) {
     const fields = {};

package/dist/bootstrap/mcp-config-merger.d.ts

@@ -13,7 +13,7 @@ import { LAUNCHER_PACKAGE_SPEC } from "@jam-mcp/launcher";
 export { LAUNCHER_PACKAGE_SPEC };
 export declare const JAM_MCP_ENTRY: {
     readonly command: "npx";
-    readonly args: readonly ["--yes", "@jam-mcp/launcher@1.3.1", "serve"];
+    readonly args: readonly ["--yes", "@jam-mcp/launcher@1.3.2", "serve"];
 };
 /**
  * Recognise wiring from before the launcher existed: a hard-coded path to one

package/dist/config/schema.d.ts

@@ -19,7 +19,6 @@ export declare const ProjectConfigSchema: z.ZodObject<{
     customFields: z.ZodDefault<z.ZodArray<z.ZodObject<{
         id: z.ZodString;
         name: z.ZodString;
-        writable: z.ZodDefault<z.ZodBoolean>;
     }, z.core.$strip>>>;
     output: z.ZodPrefault<z.ZodObject<{
         searchTokens: z.ZodDefault<z.ZodNumber>;

package/dist/config/schema.js

@@ -1,23 +1,4 @@
 import { z } from "zod";
-/** Values that appear more than once, each named once. */
-function duplicates(values) {
-    const seen = new Set();
-    const repeated = new Set();
-    for (const value of values) {
-        if (seen.has(value))
-            repeated.add(value);
-        seen.add(value);
-    }
-    return [...repeated];
-}
-function report(ctx, repeated, what) {
-    for (const value of repeated) {
-        ctx.addIssue({
-            code: "custom",
-            message: `duplicate custom field ${what} "${value}" - a selector must name one field`,
-        });
-    }
-}
 /**
  * `.jira-agent/project.yaml` - per-project policy only.
  * Credentials are never stored here; they come from the CredentialPort.
@@ -60,28 +41,13 @@ export const ProjectConfigSchema = z.object({
     /**
      * Whitelisted project-specific custom fields, surfaced at CONTEXT level and up.
      * `id` is the Jira field id (customfield_10011); `name` is what the agent sees.
-     *
-     * `writable` is a second, separate consent. Reading a field and letting an
-     * agent change it are different decisions, and a config written when JAM
-     * could only read must not start granting writes because JAM learned how.
-     * So it defaults to false: every whitelist that predates this is read-only,
-     * and a team opts a field in by saying so.
      */
     customFields: z
         .array(z.object({
         id: z.string().regex(/^customfield_\d+$/),
         name: z.string().min(1),
-        writable: z.boolean().default(false),
     }))
-        .default([])
-        .superRefine((fields, ctx) => {
-        // Ambiguity in a whitelist is worse than an omission: `custom-field.update`
-        // resolves a selector against these entries, and two rows answering to
-        // the same selector would make which field gets written a matter of
-        // ordering.
-        report(ctx, duplicates(fields.map((f) => f.id.toLowerCase())), "id");
-        report(ctx, duplicates(fields.filter((f) => f.writable).map((f) => f.name.trim().toLowerCase())), "writable name");
-    }),
+        .default([]),
     output: z
         .object({
         /** Rough token ceilings per level. Enforced by OutputBudgetPolicy. */

package/dist/deps.d.ts

@@ -6,7 +6,6 @@ import type { CredentialPort } from "./ports/credentials.port.js";
 import type { JiraReadPort } from "./ports/jira-read.port.js";
 import type { JiraAssigneeResolutionPort } from "./ports/jira-assignee-resolution.port.js";
 import type { JiraCreateMetadataPort } from "./ports/jira-create-metadata.port.js";
-import type { JiraEditMetadataPort } from "./ports/jira-edit-metadata.port.js";
 import type { JiraWritePort } from "./ports/jira-write.port.js";
 import { WritePlanStore } from "./application/write-plan-store.js";
 import type { TelemetryPort } from "./ports/telemetry.port.js";
@@ -37,12 +36,6 @@ export type JamDeps = {
      * it mutates nothing.
      */
     jiraAssignees: JiraAssigneeResolutionPort;
-    /**
-     * What Jira will let this account change on one issue. A fifth read-shaped
-     * port, for the same reason as the third and fourth: it mutates nothing, and
-     * it answers a question about a configuration rather than about an issue.
-     */
-    jiraEditMetadata: JiraEditMetadataPort;
     /**
      * Plans awaiting apply. Lives for the life of this server process - see
      * WritePlanStore for why it is not persisted.
@@ -62,8 +55,6 @@ export type BuildDepsOptions = {
     jiraCreateMetadata?: JiraCreateMetadataPort;
     /** Injected by tests so user resolution never reaches a real directory. */
     jiraAssignees?: JiraAssigneeResolutionPort;
-    /** Injected by tests so edit metadata comes from a fixture, not a site. */
-    jiraEditMetadata?: JiraEditMetadataPort;
     /** Injected by tests to bypass the real process/registry credential lookup. */
     credentials?: CredentialPort;
     /**

package/dist/deps.js

@@ -43,11 +43,6 @@ export async function buildDeps(options = {}) {
         const { JiraCloudAssigneeResolutionAdapter } = await import("./adapters/jira-cloud/jira-assignee-resolution.adapter.js");
         jiraAssignees = new JiraCloudAssigneeResolutionAdapter(credentials);
     }
-    let jiraEditMetadata = options.jiraEditMetadata;
-    if (!jiraEditMetadata) {
-        const { JiraCloudEditMetadataAdapter } = await import("./adapters/jira-cloud/jira-edit-metadata.adapter.js");
-        jiraEditMetadata = new JiraCloudEditMetadataAdapter(credentials);
-    }
     return {
         config: resolved.config,
         configPath: resolved.configPath,
@@ -56,7 +51,6 @@ export async function buildDeps(options = {}) {
         jiraWrite,
         jiraCreateMetadata,
         jiraAssignees,
-        jiraEditMetadata,
         writePlans: new WritePlanStore(),
         cache: new NoopCache(),
         telemetry,

package/dist/domain/errors.d.ts

@@ -5,7 +5,7 @@
  * is mapped onto one of these codes so the agent (and `jam doctor`) can reason
  * about failures without parsing vendor-specific payloads.
  */
-export declare const JAM_ERROR_CODES: readonly ["JIRA_AUTH_FAILED", "JIRA_PERMISSION_DENIED", "JQL_INVALID", "ISSUE_NOT_FOUND", "RATE_LIMITED", "CONTEXT_TOO_LARGE", "PARTIAL_RESULT", "CONFIG_INVALID", "JIRA_UNAVAILABLE", "JAM_SETUP_REQUIRED", "JAM_BINDINGS_UNREADABLE", "JAM_WRITE_SCOPE_VIOLATION", "JAM_WRITE_OPERATION_NOT_ALLOWED", "JAM_WRITE_FIELD_NOT_ALLOWED", "JAM_WRITE_TRANSITION_NOT_AVAILABLE", "JAM_WRITE_ISSUE_TYPE_NOT_AVAILABLE", "JAM_WRITE_REQUIRED_FIELD_UNSUPPORTED", "JAM_WRITE_VALUE_NOT_ALLOWED", "JAM_WRITE_SCHEMA_CHANGED", "JAM_WRITE_ASSIGNEE_NOT_FOUND", "JAM_WRITE_ASSIGNEE_AMBIGUOUS", "JAM_WRITE_ASSIGNEE_NOT_ASSIGNABLE", "JAM_WRITE_ASSIGNEE_ALREADY_SET", "JAM_WRITE_CUSTOM_FIELD_NOT_EDITABLE", "JAM_WRITE_CUSTOM_FIELD_TYPE_UNSUPPORTED", "JAM_WRITE_PLAN_NOT_FOUND", "JAM_WRITE_PLAN_EXPIRED", "JAM_WRITE_CONFLICT", "JAM_WRITE_VERIFICATION_FAILED", "JAM_WRITE_UNCERTAIN"];
+export declare const JAM_ERROR_CODES: readonly ["JIRA_AUTH_FAILED", "JIRA_PERMISSION_DENIED", "JQL_INVALID", "ISSUE_NOT_FOUND", "RATE_LIMITED", "CONTEXT_TOO_LARGE", "PARTIAL_RESULT", "CONFIG_INVALID", "JIRA_UNAVAILABLE", "JAM_SETUP_REQUIRED", "JAM_BINDINGS_UNREADABLE", "JAM_WRITE_SCOPE_VIOLATION", "JAM_WRITE_OPERATION_NOT_ALLOWED", "JAM_WRITE_FIELD_NOT_ALLOWED", "JAM_WRITE_TRANSITION_NOT_AVAILABLE", "JAM_WRITE_ISSUE_TYPE_NOT_AVAILABLE", "JAM_WRITE_REQUIRED_FIELD_UNSUPPORTED", "JAM_WRITE_VALUE_NOT_ALLOWED", "JAM_WRITE_SCHEMA_CHANGED", "JAM_WRITE_ASSIGNEE_NOT_FOUND", "JAM_WRITE_ASSIGNEE_AMBIGUOUS", "JAM_WRITE_ASSIGNEE_NOT_ASSIGNABLE", "JAM_WRITE_ASSIGNEE_ALREADY_SET", "JAM_WRITE_PLAN_NOT_FOUND", "JAM_WRITE_PLAN_EXPIRED", "JAM_WRITE_CONFLICT", "JAM_WRITE_VERIFICATION_FAILED", "JAM_WRITE_UNCERTAIN"];
 export type JamErrorCode = (typeof JAM_ERROR_CODES)[number];
 export type JamErrorPayload = {
     error: {

package/dist/domain/errors.js

@@ -42,12 +42,6 @@ export const JAM_ERROR_CODES = [
     "JAM_WRITE_ASSIGNEE_AMBIGUOUS",
     "JAM_WRITE_ASSIGNEE_NOT_ASSIGNABLE",
     "JAM_WRITE_ASSIGNEE_ALREADY_SET",
-    // Custom fields. Three permissions have to line up and none implies another,
-    // so a refusal says which one is missing: the team never opted this field in,
-    // Jira will not let it be set on this issue, or JAM does not know the type
-    // well enough to write it. Each points somewhere different.
-    "JAM_WRITE_CUSTOM_FIELD_NOT_EDITABLE",
-    "JAM_WRITE_CUSTOM_FIELD_TYPE_UNSUPPORTED",
     "JAM_WRITE_PLAN_NOT_FOUND",
     "JAM_WRITE_PLAN_EXPIRED",
     "JAM_WRITE_CONFLICT",

package/dist/domain/write.d.ts

@@ -20,9 +20,9 @@
  * layer: these name an issue, creation names a project; these compare a
  * revision to detect a conflict, creation has no revision to compare.
  */
-export declare const EXISTING_ISSUE_OPERATIONS: readonly ["comment.add", "field.update", "status.transition", "assignee.update", "custom-field.update"];
+export declare const EXISTING_ISSUE_OPERATIONS: readonly ["comment.add", "field.update", "status.transition", "assignee.update"];
 /** The operations the public MCP surface accepts. Nothing else is reachable. */
-export declare const WRITE_OPERATIONS: readonly ["comment.add", "field.update", "status.transition", "assignee.update", "custom-field.update", "issue.create"];
+export declare const WRITE_OPERATIONS: readonly ["comment.add", "field.update", "status.transition", "assignee.update", "issue.create"];
 export type ExistingIssueOperation = (typeof EXISTING_ISSUE_OPERATIONS)[number];
 export type WriteOperation = (typeof WRITE_OPERATIONS)[number];
 /**
@@ -93,7 +93,7 @@ export type CreateIssueInput = {
     labels?: string[];
     components?: string[];
 };
-export type WriteInput = CommentAddInput | FieldUpdateInput | StatusTransitionInput | AssigneeUpdateInput | CustomFieldUpdateInput | CreateIssueInput;
+export type WriteInput = CommentAddInput | FieldUpdateInput | StatusTransitionInput | AssigneeUpdateInput | CreateIssueInput;
 /** An issue type as Jira offers it for one project, right now. */
 export type CreateIssueType = {
     id: string;
@@ -143,93 +143,6 @@ export type CreateSchemaRequirements = {
         resolved: string;
     }[];
 };
-/**
- * One field on an issue's edit screen, as Jira describes it.
- *
- * Normalized at the adapter: `operations` and `schema` come straight from
- * Jira's own vocabulary because they are the vocabulary the decision is made
- * in, but nothing else of the raw document travels.
- */
-export type EditFieldMetadata = {
-    /** Jira's field id, e.g. `customfield_10021`. */
-    id: string;
-    name: string;
-    required: boolean;
-    /** What Jira says can be done to this field: `set`, `add`, `remove`, ... */
-    operations: string[];
-    schema: {
-        type: string;
-        /** Element type, for `type: "array"`. */
-        items?: string;
-        /** The custom field's implementation key, when it is a custom field. */
-        custom?: string;
-        customId?: number;
-    };
-    /** Present only where Jira constrains the value. Absent is not empty. */
-    allowedValues?: EditFieldOption[];
-};
-/**
- * One option Jira offers for a constrained field.
- *
- * `id` is the identity and `label` is what a person reads - the same split as
- * a user's accountId and display name, and for the same reason: an option can
- * be renamed without becoming a different option, and two options could carry
- * the same label.
- */
-export type EditFieldOption = {
-    id: string;
-    label: string;
-};
-/**
- * The custom field value families JAM can write.
- *
- * Narrow on purpose. Each of these has an unambiguous wire shape that JAM can
- * produce from a plain caller value and compare after the fact. Everything
- * else - dates needing a timezone policy, rich text needing ADF, user and
- * group pickers needing identity resolution, app-owned fields with private
- * semantics - is refused rather than guessed at.
- */
-export declare const CUSTOM_FIELD_KINDS: readonly ["text", "number", "single-option", "multi-option"];
-export type CustomFieldKind = (typeof CUSTOM_FIELD_KINDS)[number];
-export type CustomFieldUpdateInput = {
-    /** A configured field id, or a configured writable field name. */
-    field: string;
-    value: string | number | string[];
-};
-/**
- * What a custom-field plan depends on, recorded so apply can check it again.
- *
- * The issue's revision does not cover any of this: a field can be taken off a
- * screen, lose its `set` operation, change type, or have an option renamed
- * without the issue itself being touched. So these premises are frozen
- * alongside `baseUpdated`, and re-derived before the write.
- */
-export type CustomFieldRequirements = {
-    fieldId: string;
-    fieldName: string;
-    kind: CustomFieldKind;
-    schema: {
-        type: string;
-        items?: string;
-        custom?: string;
-    };
-    /** Options resolved from Jira's allowed list, for the option kinds. */
-    resolvedOptions?: EditFieldOption[];
-};
-/** A custom field value as a receipt shows it - reviewable, not a Jira payload. */
-export type CustomFieldValueView = {
-    id: string;
-    name: string;
-    value: string | number | null;
-} | {
-    id: string;
-    name: string;
-    value: EditFieldOption | null;
-} | {
-    id: string;
-    name: string;
-    value: EditFieldOption[];
-};
 /** A transition as Jira currently offers it for one issue. */
 export type JiraTransition = {
     id: string;
@@ -275,11 +188,6 @@ export type ExistingIssueWritePlan = WritePlanCommon & {
      * `undefined` means the issue was unassigned.
      */
     baseAssigneeAccountId?: string;
-    /**
-     * What this plan assumed about a custom field's configuration. Present only
-     * for `custom-field.update`; apply re-derives each premise before writing.
-     */
-    customFieldRequirements?: CustomFieldRequirements;
 };
 /**
  * A plan to create an issue that does not exist yet.
@@ -314,10 +222,6 @@ export type WriteMutation = {
 } | {
     kind: "assignee";
     accountId: string;
-} | {
-    kind: "custom-field";
-    fieldId: string;
-    value: unknown;
 } | {
     kind: "create";
     fields: Record<string, unknown>;

package/dist/domain/write.js

@@ -25,7 +25,6 @@ export const EXISTING_ISSUE_OPERATIONS = [
     "field.update",
     "status.transition",
     "assignee.update",
-    "custom-field.update",
 ];
 /** The operations the public MCP surface accepts. Nothing else is reachable. */
 export const WRITE_OPERATIONS = [...EXISTING_ISSUE_OPERATIONS, "issue.create"];
@@ -56,16 +55,6 @@ export const CREATABLE_FIELDS = [
     "labels",
     "components",
 ];
-/**
- * The custom field value families JAM can write.
- *
- * Narrow on purpose. Each of these has an unambiguous wire shape that JAM can
- * produce from a plain caller value and compare after the fact. Everything
- * else - dates needing a timezone policy, rich text needing ADF, user and
- * group pickers needing identity resolution, app-owned fields with private
- * semantics - is refused rather than guessed at.
- */
-export const CUSTOM_FIELD_KINDS = ["text", "number", "single-option", "multi-option"];
 export function isWriteOperation(value) {
     return WRITE_OPERATIONS.includes(value);
 }

package/dist/mcp/tools/jira-write-plan.tool.js

@@ -11,7 +11,6 @@ Operations on an issue that already exists - these need \`key\`:
 - field.update       input: { "summary"?, "priority"?, "labels"?, "components"? }
 - status.transition  input: { "status": "Done" }     JAM asks Jira which transitions exist and matches yours
 - assignee.update    input: { "assignee": "..." }     a display name or an accountId; JAM resolves it against Jira's own directory
-- custom-field.update input: { "field": "...", "value": ... }  one custom field the project opted in
 
 Creating an issue - no \`key\`, because there is no issue yet:
 - issue.create       input: { "issueType": "Task", "summary": "...", "description"?, "priority"?, "labels"?, "components"? }
@@ -20,8 +19,6 @@ issue.create goes into the project this workspace is bound to; the project is no
 
 assignee.update never sends the name you pass. JAM searches Jira's user directory, and assigns only when exactly one user matches your string exactly - an exact display name (case-insensitive) or an accountId. A partial match is Jira reporting a similarity, not identifying a person, so several matches or none come back as a refusal with the candidates attached: name one exactly, or pass their accountId. JAM also checks Jira offers that person as an assignee for this issue, before planning and again before writing, and confirms the result by accountId rather than by name. Unassigning, and setting an assignee while creating, are not in this version.
 
-custom-field.update changes one custom field, and only one a team has opted in: the field's exact id must carry "writable: true" in the project's .jira-agent/project.yaml. Being readable does not make a field writable. "field" is that id or its configured name, matched exactly - no partial matches. JAM then asks Jira's edit metadata whether the field is settable on this issue for this account, and what type it is. Supported types are single-line text (string), number, single-select (string naming an option) and multi-select (array of strings). Anything else - dates, rich text, user or group pickers, app-owned fields - is refused rather than attempted. Types are not converted: "5" is not 5. Options are matched exactly against what Jira offers and written by option id. Clearing a field is not supported, so an empty string or an empty array is refused.
-
 Writes are limited to the Jira project this workspace is bound to; a key from another project is refused rather than attempted.
 
 The plan records what the issue looked like when it was made, and expires. If the issue changes in the meantime, jira_write_apply refuses with JAM_WRITE_CONFLICT - re-plan against the new state rather than forcing the old one through.
@@ -63,15 +60,6 @@ export function registerJiraWritePlan(server, deps) {
                     .min(1)
                     .optional()
                     .describe("assignee.update: who to assign, as an exact display name or an accountId. Not settable through field.update."),
-                field: z
-                    .string()
-                    .min(1)
-                    .optional()
-                    .describe("custom-field.update: the custom field, as its Jira id (customfield_10016) or its configured name. Must be writable in this project's config."),
-                value: z
-                    .union([z.string(), z.number(), z.array(z.string())])
-                    .optional()
-                    .describe("custom-field.update: the value. A string for text, a number for numeric, a string naming an option for single-select, an array of strings for multi-select."),
                 issueType: z
                     .string()
                     .min(1)

package/dist/ports/jira-read.port.d.ts

@@ -38,16 +38,6 @@ export type GetIssueResult = {
      * Absent when the issue is unassigned, or when the field was not requested.
      */
     assigneeAccountId?: string;
-    /**
-     * Raw custom field values, keyed by field id, exactly as Jira returned them.
-     *
-     * Here rather than on the issue for the same reason as the accountId: only
-     * the write plane needs it. `FullIssueContext.customFields` is the mapped,
-     * whitelisted view the read tools show; verifying a write needs the value in
-     * the form Jira stores it, option ids included, before anything shortens it
-     * to something a person reads.
-     */
-    customFieldValues?: Record<string, unknown>;
     responseBytes: number;
 };
 export type GetIssuesResult = {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jam-mcp/server",
-  "version": "1.3.1",
+  "version": "1.3.2",
   "description": "JAM (Jira Agent MCP) - agent-facing Jira access layer: MCP server, setup core, and CLI",
   "keywords": [
     "jira",
@@ -41,7 +41,7 @@
     "test:watch": "vitest"
   },
   "dependencies": {
-    "@jam-mcp/launcher": "1.3.1",
+    "@jam-mcp/launcher": "1.3.2",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "yaml": "^2.9.0",
     "zod": "^4.4.3"