@jam-mcp/server 1.3.1 → 1.4.0

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.4.0",
   "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.4.0",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "yaml": "^2.9.0",
     "zod": "^4.4.3"

package/dist/adapters/jira-cloud/jira-edit-metadata.adapter.d.ts

@@ -1,25 +0,0 @@
-import type { EditFieldMetadata } from "../../domain/write.js";
-import type { CredentialPort } from "../../ports/credentials.port.js";
-import type { JiraEditMetadataPort } from "../../ports/jira-edit-metadata.port.js";
-/**
- * Jira Cloud REST v3 edit metadata for one issue.
- *
- * `GET /rest/api/3/issue/{key}/editmeta`, `retry: false`. Its answer decides
- * whether a mutation may proceed and what shape it takes, so a
- * retried-and-stale answer is worse than a failure - the same argument that
- * keeps `getTransitions`, the create metadata calls and the assignability
- * check on the non-retrying side.
- *
- * Jira keys the response by field id, and describes each field with a `schema`
- * and a list of `operations`. Both travel, because both are what the decision
- * is made in; the rest of the document does not.
- *
- * Anything JAM cannot read is dropped rather than half-understood. A field
- * that survives here with the wrong shape would be a field JAM claims to
- * understand well enough to write.
- */
-export declare class JiraCloudEditMetadataAdapter implements JiraEditMetadataPort {
-    private readonly client;
-    constructor(credentials: CredentialPort, fetchImpl?: typeof fetch);
-    getEditableFields(issueKey: string): Promise<EditFieldMetadata[]>;
-}

package/dist/adapters/jira-cloud/jira-edit-metadata.adapter.js

@@ -1,84 +0,0 @@
-import { JiraClient } from "./jira-client.js";
-/**
- * Jira Cloud REST v3 edit metadata for one issue.
- *
- * `GET /rest/api/3/issue/{key}/editmeta`, `retry: false`. Its answer decides
- * whether a mutation may proceed and what shape it takes, so a
- * retried-and-stale answer is worse than a failure - the same argument that
- * keeps `getTransitions`, the create metadata calls and the assignability
- * check on the non-retrying side.
- *
- * Jira keys the response by field id, and describes each field with a `schema`
- * and a list of `operations`. Both travel, because both are what the decision
- * is made in; the rest of the document does not.
- *
- * Anything JAM cannot read is dropped rather than half-understood. A field
- * that survives here with the wrong shape would be a field JAM claims to
- * understand well enough to write.
- */
-export class JiraCloudEditMetadataAdapter {
-    client;
-    constructor(credentials, fetchImpl) {
-        this.client = fetchImpl ? new JiraClient(credentials, fetchImpl) : new JiraClient(credentials);
-    }
-    async getEditableFields(issueKey) {
-        const { data } = await this.client.request({
-            path: `rest/api/3/issue/${encodeURIComponent(issueKey)}/editmeta`,
-            retry: false,
-        });
-        const fields = data?.fields;
-        if (!fields || typeof fields !== "object")
-            return [];
-        return Object.entries(fields)
-            .map(([id, raw]) => toEditField(id, raw))
-            .filter((f) => f !== undefined);
-    }
-}
-function toEditField(id, raw) {
-    if (!raw || typeof raw !== "object")
-        return undefined;
-    // A field with no schema type is a field JAM cannot classify, and an
-    // unclassifiable field is one it must not decide it can write.
-    const type = typeof raw.schema?.type === "string" ? raw.schema.type : undefined;
-    if (!type)
-        return undefined;
-    const allowed = toOptions(raw.allowedValues);
-    return {
-        id,
-        name: typeof raw.name === "string" ? raw.name : id,
-        required: raw.required === true,
-        operations: Array.isArray(raw.operations)
-            ? raw.operations.filter((op) => typeof op === "string")
-            : [],
-        schema: {
-            type,
-            ...(typeof raw.schema?.items === "string" ? { items: raw.schema.items } : {}),
-            ...(typeof raw.schema?.custom === "string" ? { custom: raw.schema.custom } : {}),
-            ...(typeof raw.schema?.customId === "number" ? { customId: raw.schema.customId } : {}),
-        },
-        ...(allowed ? { allowedValues: allowed } : {}),
-    };
-}
-/**
- * The options Jira offers, when it constrains the field at all.
- *
- * Absent and empty mean different things and stay apart: absent is "Jira did
- * not constrain this", empty is "Jira constrains it and offers nothing". The
- * first permits a free value, the second permits none.
- *
- * Jira labels an option `value` on a select and `name` on some other pickers.
- * Both are read; an option with neither an id nor a label is dropped, because
- * it can be neither chosen nor recognised afterwards.
- */
-function toOptions(raw) {
-    if (!Array.isArray(raw))
-        return undefined;
-    return raw
-        .map((entry) => {
-        const o = entry;
-        const id = typeof o?.id === "string" ? o.id : typeof o?.id === "number" ? String(o.id) : undefined;
-        const label = typeof o?.value === "string" ? o.value : typeof o?.name === "string" ? o.name : undefined;
-        return id && label ? { id, label } : undefined;
-    })
-        .filter((o) => o !== undefined);
-}

package/dist/policy/custom-field-policy.d.ts

@@ -1,93 +0,0 @@
-import type { ProjectConfig } from "../config/schema.js";
-import type { CustomFieldKind, CustomFieldRequirements, CustomFieldUpdateInput, CustomFieldValueView, EditFieldMetadata, EditFieldOption } from "../domain/write.js";
-/**
- * What JAM will write to a custom field, and everything that has to be true
- * first.
- *
- * Three separate permissions have to line up, and none of them implies
- * another:
- *
- *  1. **The team said so.** The field's exact id is in the project's whitelist
- *     with `writable: true`. Being readable is not being writable - reading a
- *     field and letting an agent change it are different decisions, and a
- *     config written before JAM could write must not start granting writes
- *     because JAM learned how.
- *  2. **Jira allows it here and now.** The field is on this issue's edit
- *     screen for this account, and Jira lists `set` among its operations.
- *     Asked, never modelled: applicability depends on project, issue type,
- *     field contexts, screens and permissions, and JAM does not carry a copy
- *     of any of that.
- *  3. **JAM knows the shape.** The field's type is one of four families whose
- *     wire form JAM can produce from a plain value and compare afterwards.
- *     Anything else is refused rather than posted to find out.
- */
-type WritableField = {
-    id: string;
-    name: string;
-};
-/**
- * Which configured field this selector names.
- *
- * The id is the identity; the name is an alias for people. Resolution is exact
- * on either - no substring, no fuzz - because the alternative is an agent's
- * approximate word choosing which field on somebody's board gets rewritten.
- *
- * Only `writable: true` entries are candidates, including for the refusal
- * message: naming a read-only field as an alternative would suggest it is one
- * selector away from being written.
- */
-export declare function resolveWritableField(config: ProjectConfig, requested: string): WritableField;
-/**
- * The field as Jira currently offers it on this issue, or a refusal.
- *
- * Absent from the edit metadata and present-but-not-settable are different
- * situations with the same answer for the caller, so they share a code and
- * differ in the detail: one means the field is not on this screen, the other
- * that Jira will not let this account set it.
- */
-export declare function assertEditable(issueKey: string, field: WritableField, metadata: EditFieldMetadata[]): EditFieldMetadata;
-/**
- * Which of the four families this field belongs to, if any.
- *
- * Classified from Jira's own `schema`, which is the vocabulary Jira answers
- * in. The implementation key (`schema.custom`) deliberately does not decide
- * it: there are hundreds of them, they are app-specific, and a field's wire
- * shape follows its type rather than its plugin.
- *
- * Anything unclassified is refused. Posting an unknown type to see what
- * happens would use a Jira 400 as schema discovery, and on the occasions it
- * did not 400 it would write something nobody described.
- */
-export declare function classifyKind(field: EditFieldMetadata): CustomFieldKind;
-/**
- * The value, checked against the family and turned into what Jira expects.
- *
- * Types are never coerced. `"5"` is not `5`: a caller that meant a number can
- * say so, and silently converting would make JAM's idea of the value differ
- * from the caller's in exactly the cases where it matters.
- *
- * Nothing here clears a field. Empty strings, empty arrays and null are
- * refused rather than treated as "unset" - removing a value is a different
- * intent from setting one, and it is not in this version.
- */
-export declare function resolveCustomFieldValue(field: EditFieldMetadata, kind: CustomFieldKind, input: CustomFieldUpdateInput): {
-    jiraValue: unknown;
-    view: CustomFieldValueView;
-    resolvedOptions?: EditFieldOption[];
-};
-/**
- * Do this plan's premises still hold?
- *
- * Semantic, like the create schema check and for the same reason: comparing
- * whole metadata documents would invalidate every outstanding plan whenever an
- * unrelated field appeared on the screen. What is compared is what the plan
- * actually rested on - the field is still settable, still the same family,
- * still the same schema, and every option it chose is still offered under the
- * same label.
- *
- * A renamed option is treated as a changed one. The id is the identity, but a
- * label is what the plan showed a human before they agreed to it, and "Backend"
- * becoming "Platform" is a different statement about the issue.
- */
-export declare function assertCustomFieldUnchanged(issueKey: string, requirements: CustomFieldRequirements, metadata: EditFieldMetadata[]): void;
-export {};