@jam-mcp/server 1.1.0 → 1.3.0

package/dist/application/apply-create-issue.js

@@ -0,0 +1,187 @@
+import { JamError, toJamError } from "../domain/errors.js";
+import { canonicalizePlainText } from "../domain/adf.js";
+import { assertSchemaUnchanged } from "../policy/create-policy.js";
+import { projectKeyOf } from "../policy/write-policy.js";
+import { readIssue } from "./plan-write.js";
+/**
+ * Create the issue a plan describes, then go and look at what was created.
+ *
+ * The same three-step shape as every other apply, with one substitution.
+ * Updating an existing issue re-reads that issue and compares its revision;
+ * there is no issue to re-read here, so what gets checked instead is the
+ * premise the plan was built on - the project's create schema. That is
+ * creation's concurrency boundary.
+ *
+ *  1. Re-derive the schema and check the plan's premises still hold. If the
+ *     issue type went away, or a required field JAM cannot fill appeared, or a
+ *     resolved value is no longer offered, nothing is sent.
+ *  2. POST the create exactly once. No retry, ever - see below.
+ *  3. Read the new issue by the key Jira returned, and check it says what the
+ *     plan intended. A 201 with a key is Jira accepting a request, not
+ *     evidence that the issue exists as described.
+ */
+export async function applyCreateIssue(deps, plan) {
+    if (plan.mutation.kind !== "create") {
+        throw new JamError("CONFIG_INVALID", "A create-issue plan must carry a create mutation.");
+    }
+    await revalidateSchema(deps, plan);
+    const created = await create(deps, plan);
+    const after = await verify(deps, plan, created.key);
+    deps.writePlans.consume(plan.planId);
+    return {
+        status: "applied",
+        issue: created.key,
+        operation: plan.operation,
+        before: plan.before,
+        after,
+        verified: true,
+    };
+}
+/**
+ * Ask Jira for the create schema again, and check the plan still stands.
+ *
+ * Deliberately not a comparison of the two metadata documents. The question is
+ * not "is the schema identical" - on an active project it rarely is - but "are
+ * this plan's premises still true". See assertSchemaUnchanged.
+ */
+async function revalidateSchema(deps, plan) {
+    const { projectKey, schemaRequirements } = plan;
+    const issueTypes = await deps.jiraCreateMetadata.getIssueTypes(projectKey);
+    const fields = await deps.jiraCreateMetadata.getCreateFields(projectKey, schemaRequirements.issueTypeId);
+    assertSchemaUnchanged(schemaRequirements, issueTypes, fields, intendedInput(plan));
+}
+/**
+ * The create request as an input again, for re-running the required-field gate.
+ *
+ * Derived from `intendedAfter` rather than kept as a second copy of the
+ * request: one record of what this plan intends, read two ways.
+ */
+function intendedInput(plan) {
+    const after = plan.intendedAfter;
+    return {
+        issueType: plan.schemaRequirements.issueTypeName,
+        summary: String(after["summary"] ?? ""),
+        ...(after["description"] !== undefined ? { description: String(after["description"]) } : {}),
+        ...(after["priority"] !== undefined ? { priority: String(after["priority"]) } : {}),
+        ...(Array.isArray(after["labels"]) ? { labels: after["labels"] } : {}),
+        ...(Array.isArray(after["components"]) ? { components: after["components"] } : {}),
+    };
+}
+/**
+ * Send the create, once.
+ *
+ * There is no retry here and there must not be one. This is the sharpest
+ * version of the rule the whole write plane follows: a create that fails
+ * ambiguously may already have produced an issue, and resending it produces a
+ * second one - on someone's board, in someone's sprint, with a key nobody is
+ * holding. So an ambiguous failure becomes JAM_WRITE_UNCERTAIN and says what
+ * to do about it: look in the project, do not send it again.
+ */
+async function create(deps, plan) {
+    if (plan.mutation.kind !== "create") {
+        throw new JamError("CONFIG_INVALID", "A create-issue plan must carry a create mutation.");
+    }
+    try {
+        return await deps.jiraWrite.createIssue(plan.mutation.fields);
+    }
+    catch (err) {
+        const jamError = toJamError(err);
+        if (!isAmbiguous(jamError))
+            throw jamError;
+        throw new JamError("JAM_WRITE_UNCERTAIN", `JAM could not tell whether the issue was created in ${plan.projectKey}: ${jamError.message} Look in the project to find out - do not retry this write, which could create a second issue.`, { project: plan.projectKey, operation: plan.operation, cause: jamError.code });
+    }
+}
+/**
+ * A failure that says nothing about whether Jira acted.
+ *
+ * A 403 or a 400 is a decision Jira made and did not act on. A dropped
+ * connection or a 5xx is not: the request may have been processed before the
+ * answer went missing. JAM_WRITE_UNCERTAIN raised inside the adapter - Jira
+ * accepted a create but named no issue - is ambiguous by construction and
+ * passes through unchanged.
+ */
+function isAmbiguous(err) {
+    return (err.code === "JIRA_UNAVAILABLE" ||
+        err.code === "RATE_LIMITED" ||
+        err.code === "JAM_WRITE_UNCERTAIN");
+}
+/**
+ * Read the created issue and check it is the one the plan described.
+ *
+ * Every field in `intendedAfter` is checked, because `intendedAfter` is also
+ * what the plan receipt promised `verification.expects` would show. A field
+ * the receipt names and the check skips is worse than one it never named: it
+ * reports `verified: true` about something nobody looked at.
+ *
+ * Only the fields the create contract lets a caller ask for are in there.
+ * Jira fills in a great deal on its own - reporter, created, status, whatever
+ * a project's automation adds - and none of that was requested, so requiring
+ * it to match something would be inventing an expectation nobody stated.
+ */
+async function verify(deps, plan, issueKey) {
+    // Where the issue landed is part of what was intended. The workspace binding
+    // is the whole of JAM's write scope, so a key from another project coming
+    // back from a create is the one outcome that must never be reported as the
+    // create that was planned.
+    const createdProject = projectKeyOf(issueKey);
+    if (createdProject !== plan.projectKey) {
+        throw verificationFailed(plan, issueKey, { project: plan.projectKey }, { project: createdProject ?? issueKey });
+    }
+    const { issue } = await readIssue(deps, issueKey);
+    const observed = {};
+    for (const field of Object.keys(plan.intendedAfter)) {
+        observed[field] = observedValue(issue, field);
+    }
+    for (const [field, expected] of Object.entries(plan.intendedAfter)) {
+        if (!sameValue(observed[field], expected)) {
+            throw verificationFailed(plan, issueKey, plan.intendedAfter, observed);
+        }
+    }
+    return observed;
+}
+/**
+ * The created issue's value for one requested field.
+ *
+ * The description is canonicalized on the way out, the same way the plan
+ * canonicalized what was asked for. Jira stores a document and renders it back
+ * as text, so the two are never byte-identical - and a comparison that failed
+ * on Jira's own formatting would be reporting a problem that is not there.
+ */
+function observedValue(issue, field) {
+    switch (field) {
+        case "issueType":
+            return issue.issueType;
+        case "summary":
+            return issue.summary;
+        case "description":
+            return issue.description === undefined
+                ? undefined
+                : canonicalizePlainText(issue.description);
+        case "priority":
+            return issue.priority;
+        case "labels":
+            return issue.labels;
+        case "components":
+            return issue.components;
+        default:
+            return undefined;
+    }
+}
+/**
+ * The issue exists. Say so, and say not to make another one.
+ *
+ * This is the failure an agent is most likely to answer by trying again, and
+ * trying again is the one thing that turns a wrong issue into two wrong
+ * issues.
+ */
+function verificationFailed(plan, issueKey, expected, observed) {
+    return new JamError("JAM_WRITE_VERIFICATION_FAILED", `Jira created ${issueKey}, but a direct read does not show what the plan intended. A workflow rule or a project automation may have altered the issue as it was created. The issue exists - look at it and fix it there, or delete it. Do not create another one.`, { issueKey, operation: plan.operation, expected, observed });
+}
+function sameValue(observed, expected) {
+    if (Array.isArray(expected) || Array.isArray(observed)) {
+        const a = Array.isArray(observed) ? [...observed].map(String).sort() : [];
+        const b = Array.isArray(expected) ? [...expected].map(String).sort() : [];
+        return a.length === b.length && a.every((value, i) => value === b[i]);
+    }
+    return observed === expected;
+}

package/dist/application/apply-write.js

@@ -1,6 +1,8 @@
 import { JamError, toJamError } from "../domain/errors.js";
 import { readModeAfterWrite } from "../policy/consistency-policy.js";
+import { assertAssignable } from "../policy/assignee-policy.js";
 import { assertUnchanged } from "../policy/write-policy.js";
+import { applyCreateIssue } from "./apply-create-issue.js";
 import { readIssue } from "./plan-write.js";
 /**
  * Execute a plan JAM made, then go and look at what happened.
@@ -28,8 +30,18 @@ export async function applyWritePlan(deps, request) {
     if (readModeAfterWrite() !== "direct") {
         throw new JamError("CONFIG_INVALID", "Write confirmation must use a direct issue read.");
     }
+    // Creation follows the same three steps with a different first one: there is
+    // no issue to re-read, so what gets re-checked is the create schema the plan
+    // was built on. Both paths still end in a direct read of a real issue.
+    if (plan.kind === "create-issue")
+        return applyCreateIssue(deps, plan);
     const current = await readIssue(deps, plan.issueKey);
-    assertUnchanged(plan.issueKey, plan.baseUpdated, current.updated);
+    assertUnchanged(plan.issueKey, plan.baseUpdated, current.issue.updated);
+    // Whatever the plan depends on that the revision check cannot see, checked
+    // again here. For an assignment that is the target's permission to hold this
+    // issue: it can be revoked between planning and applying, and a plan that
+    // was valid is not the same as a plan that is still valid.
+    await revalidate(deps, plan);
     const outcome = await mutate(deps, plan);
     const after = await verify(deps, plan);
     deps.writePlans.consume(plan.planId);
@@ -43,6 +55,18 @@ export async function applyWritePlan(deps, request) {
         ...(outcome.commentId ? { commentId: outcome.commentId } : {}),
     };
 }
+/**
+ * Re-derive the premises the revision check does not cover.
+ *
+ * Only `assignee.update` has any: the rest are fully described by the issue's
+ * own state, which `assertUnchanged` already compared.
+ */
+async function revalidate(deps, plan) {
+    if (plan.mutation.kind !== "assignee")
+        return;
+    const target = plan.intendedAfter["assignee"];
+    assertAssignable(plan.issueKey, target, await deps.jiraAssignees.isAssignable(plan.issueKey, plan.mutation.accountId));
+}
 /**
  * Send the mutation, once.
  *
@@ -65,6 +89,14 @@ async function mutate(deps, plan) {
             case "transition":
                 await deps.jiraWrite.transitionIssue(plan.issueKey, plan.mutation.transitionId);
                 return {};
+            case "assignee":
+                await deps.jiraWrite.assignIssue(plan.issueKey, plan.mutation.accountId);
+                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
+                // than a silent fall-through that writes nothing and reports success.
+                throw new JamError("CONFIG_INVALID", "A create mutation cannot be applied through the existing-issue path.");
         }
     }
     catch (err) {
@@ -92,12 +124,31 @@ function isAmbiguous(err) {
  * ours.
  */
 async function verify(deps, plan) {
-    const issue = await readIssue(deps, plan.issueKey);
+    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
+        // name, so a name comparison would accept the wrong person's assignment as
+        // proof of the right one's - which is the entire reason resolution went to
+        // the trouble of producing an identity.
+        const expected = plan.intendedAfter["assignee"];
+        const observed = snapshot.assigneeAccountId
+            ? { accountId: snapshot.assigneeAccountId, displayName: issue.assignee ?? "" }
+            : null;
+        if (snapshot.assigneeAccountId !== expected.accountId) {
+            throw verificationFailed(plan, { assignee: expected }, { assignee: observed });
+        }
+        return { assignee: { accountId: expected.accountId, displayName: issue.assignee ?? expected.displayName } };
+    }
     if (plan.mutation.kind === "comment") {
-        const { comments } = await deps.jira.getIssues({
-            keys: [plan.issueKey],
+        // Direct issue GET again, not the bulk endpoint: this is post-write
+        // confirmation, and ConsistencyPolicy makes no exception for the read that
+        // happens to want the comment field.
+        const { issue: withComments } = await deps.jira.getIssue({
+            key: plan.issueKey,
             fields: ["summary", "status", "comment", "updated"],
-        }).then((r) => ({ comments: r.issues[0]?.comments ?? [] }));
+        });
+        const comments = withComments?.comments ?? [];
         const wanted = plan.mutation.text.trim();
         const found = comments.some((c) => c.body.trim() === wanted);
         if (!found) {

package/dist/application/plan-create-issue.d.ts

@@ -0,0 +1,44 @@
+import type { JamDeps } from "../deps.js";
+import type { CreateIssueInput, CreateIssueWritePlan, WritePlanReceipt } from "../domain/write.js";
+export type PlanCreateIssueRequest = {
+    input: Record<string, unknown>;
+};
+/**
+ * Work out whether an issue can be created here, and describe the one JAM
+ * would create.
+ *
+ * Reads only - the create metadata endpoints answer questions about a
+ * project's configuration and change nothing. The order is the point:
+ *
+ *  1. Validate the request against JAM's own contract. Anything refusable
+ *     without asking Jira is refused before a round trip is spent on it.
+ *  2. Ask Jira which issue types this account can create here, and resolve the
+ *     requested one against that list. An id is never derived from a name.
+ *  3. Ask Jira what that issue type's create screen requires, and refuse now if
+ *     it requires something JAM cannot express. A create JAM knows Jira will
+ *     reject is not sent.
+ *  4. Resolve every constrained value against Jira's own allowed list.
+ *
+ * What comes out is a plan that records not just the intended issue but the
+ * premises it rests on, so apply can check they still hold.
+ *
+ * The target project is never a parameter. It is the project this workspace is
+ * bound to, which is what the user consented to when they set JAM up; taking
+ * it from the caller would make the binding advisory.
+ */
+export declare function planCreateIssue(deps: JamDeps, request: PlanCreateIssueRequest): Promise<{
+    plan: CreateIssueWritePlan;
+    receipt: WritePlanReceipt;
+}>;
+/** The project this workspace is bound to, or a refusal that says so. */
+export declare function configuredProject(deps: JamDeps): string;
+/**
+ * Check the request against the create contract, and normalize it.
+ *
+ * Pure: no Jira, no state. `key` is not accepted here at all - there is no
+ * issue to name - and neither is `project`, which comes from the binding.
+ * Anything outside CREATABLE_FIELDS is rejected rather than ignored: silently
+ * dropping a field an agent asked for would create an issue that is not the
+ * one it described.
+ */
+export declare function validateCreateInput(raw: Record<string, unknown>): CreateIssueInput;

package/dist/application/plan-create-issue.js

@@ -0,0 +1,188 @@
+import { JamError } from "../domain/errors.js";
+import { CREATABLE_FIELDS } from "../domain/write.js";
+import { assertRequiredFieldsSupported, CREATE_FIELD_IDS, resolveAllowedValue, resolveIssueType, } from "../policy/create-policy.js";
+import { PLAN_TTL_MS } from "../policy/write-policy.js";
+import { canonicalizePlainText, textToAdf } from "../domain/adf.js";
+/**
+ * Work out whether an issue can be created here, and describe the one JAM
+ * would create.
+ *
+ * Reads only - the create metadata endpoints answer questions about a
+ * project's configuration and change nothing. The order is the point:
+ *
+ *  1. Validate the request against JAM's own contract. Anything refusable
+ *     without asking Jira is refused before a round trip is spent on it.
+ *  2. Ask Jira which issue types this account can create here, and resolve the
+ *     requested one against that list. An id is never derived from a name.
+ *  3. Ask Jira what that issue type's create screen requires, and refuse now if
+ *     it requires something JAM cannot express. A create JAM knows Jira will
+ *     reject is not sent.
+ *  4. Resolve every constrained value against Jira's own allowed list.
+ *
+ * What comes out is a plan that records not just the intended issue but the
+ * premises it rests on, so apply can check they still hold.
+ *
+ * The target project is never a parameter. It is the project this workspace is
+ * bound to, which is what the user consented to when they set JAM up; taking
+ * it from the caller would make the binding advisory.
+ */
+export async function planCreateIssue(deps, request) {
+    const projectKey = configuredProject(deps);
+    const input = validateCreateInput(request.input);
+    const issueTypes = await deps.jiraCreateMetadata.getIssueTypes(projectKey);
+    const issueType = resolveIssueType(input.issueType, issueTypes);
+    const fields = await deps.jiraCreateMetadata.getCreateFields(projectKey, issueType.id);
+    const requiredFieldIds = assertRequiredFieldsSupported(fields, input);
+    const byId = new Map(fields.map((f) => [f.id, f]));
+    const resolvedValues = [];
+    // Only the constrained fields go through resolution. Summary and description
+    // are free text, and labels are a Jira-wide vocabulary rather than a
+    // per-project one, so there is no list to resolve them against.
+    let priority;
+    if (input.priority !== undefined) {
+        const resolved = resolveAllowedValue(byId.get(CREATE_FIELD_IDS.priority), input.priority, "priority");
+        priority = resolved.resolved;
+        resolvedValues.push({ fieldId: CREATE_FIELD_IDS.priority, ...resolved });
+    }
+    let components;
+    if (input.components !== undefined) {
+        const field = byId.get(CREATE_FIELD_IDS.components);
+        components = input.components.map((name) => {
+            const resolved = resolveAllowedValue(field, name, "component");
+            resolvedValues.push({ fieldId: CREATE_FIELD_IDS.components, ...resolved });
+            return resolved.resolved;
+        });
+    }
+    const intendedAfter = {
+        issueType: issueType.name,
+        summary: input.summary,
+        // Canonical, not the raw string. `intendedAfter` is also what
+        // `verification.expects` promises a direct read will show, and a direct
+        // read shows the text as Jira renders it back - so promising the caller's
+        // exact bytes would be promising something no read can ever produce.
+        ...(input.description !== undefined
+            ? { description: canonicalizePlainText(input.description) }
+            : {}),
+        ...(priority !== undefined ? { priority } : {}),
+        ...(input.labels !== undefined ? { labels: input.labels } : {}),
+        ...(components !== undefined ? { components } : {}),
+    };
+    const createdAt = new Date();
+    const plan = deps.writePlans.create({
+        kind: "create-issue",
+        projectKey,
+        operation: "issue.create",
+        before: { issue: null },
+        intendedAfter,
+        schemaRequirements: {
+            issueTypeId: issueType.id,
+            issueTypeName: issueType.name,
+            requiredFieldIds,
+            resolvedValues,
+        },
+        createdAt: createdAt.toISOString(),
+        expiresAt: new Date(createdAt.getTime() + PLAN_TTL_MS).toISOString(),
+        mutation: {
+            kind: "create",
+            fields: toJiraCreateFields(projectKey, issueType.id, input, { priority, components }),
+        },
+    });
+    return {
+        plan,
+        receipt: {
+            status: "planned",
+            planId: plan.planId,
+            operation: plan.operation,
+            project: plan.projectKey,
+            before: plan.before,
+            intendedAfter: plan.intendedAfter,
+            expiresAt: plan.expiresAt,
+            verification: { method: "direct-issue-read", expects: plan.intendedAfter },
+        },
+    };
+}
+/** The project this workspace is bound to, or a refusal that says so. */
+export function configuredProject(deps) {
+    const configured = deps.config.project.key.trim().toUpperCase();
+    if (!configured) {
+        throw new JamError("JAM_SETUP_REQUIRED", "No Jira project is configured for this workspace, so JAM does not know where an issue would be created.");
+    }
+    return configured;
+}
+/**
+ * Check the request against the create contract, and normalize it.
+ *
+ * Pure: no Jira, no state. `key` is not accepted here at all - there is no
+ * issue to name - and neither is `project`, which comes from the binding.
+ * Anything outside CREATABLE_FIELDS is rejected rather than ignored: silently
+ * dropping a field an agent asked for would create an issue that is not the
+ * one it described.
+ */
+export function validateCreateInput(raw) {
+    const unknown = Object.keys(raw).filter((key) => raw[key] !== undefined && !CREATABLE_FIELDS.includes(key));
+    if (unknown.length > 0) {
+        throw new JamError("JAM_WRITE_FIELD_NOT_ALLOWED", `issue.create cannot set ${unknown.join(", ")}. Supported: ${CREATABLE_FIELDS.join(", ")}.`, { rejected: unknown, supported: [...CREATABLE_FIELDS] });
+    }
+    const issueType = requiredText(raw["issueType"], "issueType");
+    const summary = requiredText(raw["summary"], "summary");
+    const input = { issueType, summary };
+    if (raw["description"] !== undefined) {
+        // Plain text, never ADF. A caller-supplied document tree would mean
+        // panels, mentions and embeds arriving through a field that reads like
+        // prose - the same argument that keeps comment.add on plain text.
+        if (typeof raw["description"] !== "string") {
+            throw notAllowed("issue.create needs `input.description` to be plain text.");
+        }
+        // An all-whitespace description is not a description. Accepting one would
+        // mean promising to verify text that renders to nothing, which no read can
+        // confirm - so it is refused here rather than becoming an unverifiable
+        // create later.
+        if (canonicalizePlainText(raw["description"]).length === 0) {
+            throw notAllowed("issue.create needs `input.description` to be non-empty when it is set.");
+        }
+        input.description = raw["description"];
+    }
+    if (raw["priority"] !== undefined) {
+        input.priority = requiredText(raw["priority"], "priority");
+    }
+    if (raw["labels"] !== undefined) {
+        input.labels = stringArray(raw["labels"], "labels");
+    }
+    if (raw["components"] !== undefined) {
+        input.components = stringArray(raw["components"], "components");
+    }
+    return input;
+}
+function requiredText(value, field) {
+    if (typeof value !== "string" || value.trim().length === 0) {
+        throw notAllowed(`issue.create needs non-empty \`input.${field}\`.`);
+    }
+    return value.trim();
+}
+function stringArray(value, field) {
+    if (!Array.isArray(value) || value.some((entry) => typeof entry !== "string")) {
+        throw notAllowed(`issue.create needs \`input.${field}\` to be an array of strings.`);
+    }
+    return value;
+}
+function notAllowed(message) {
+    return new JamError("JAM_WRITE_OPERATION_NOT_ALLOWED", message, { operation: "issue.create" });
+}
+/** Whitelisted values to the shapes Jira's create API expects. */
+function toJiraCreateFields(projectKey, issueTypeId, input, resolved) {
+    const fields = {
+        project: { key: projectKey },
+        issuetype: { id: issueTypeId },
+        summary: input.summary,
+    };
+    if (input.description !== undefined)
+        fields["description"] = textToAdf(input.description);
+    if (resolved.priority !== undefined)
+        fields["priority"] = { name: resolved.priority };
+    if (input.labels !== undefined)
+        fields["labels"] = input.labels;
+    if (resolved.components !== undefined) {
+        fields["components"] = resolved.components.map((name) => ({ name }));
+    }
+    return fields;
+}

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

@@ -2,7 +2,8 @@ import type { JamDeps } from "../deps.js";
 import type { FullIssueContext } from "../domain/context.js";
 import type { WritePlan, WritePlanReceipt } from "../domain/write.js";
 export type PlanWriteRequest = {
-    key: string;
+    /** Absent for `issue.create`, which names a project rather than an issue. */
+    key?: string;
     operation: string;
     input: Record<string, unknown>;
 };
@@ -26,7 +27,18 @@ export declare function planWrite(deps: JamDeps, request: PlanWriteRequest): Pro
 /**
  * The issue as Jira has it, read directly by key.
  *
- * A direct read, never a search: ConsistencyPolicy requires it for anything
- * that decides a write, and a JQL result can lag behind the issue it describes.
+ * `getIssue`, not `getIssues`: ConsistencyPolicy requires a direct issue GET
+ * for anything that decides or confirms a write, and the bulk endpoint is not
+ * one. A JQL result can lag behind the issue it describes; a bulk fetch is
+ * free to answer from a different path than the single-issue endpoint. Neither
+ * difference matters for ordinary reads, and both matter here.
+ *
+ * The one read every write goes through - the pre-write conflict check, the
+ * post-write confirmation, and the post-create confirmation.
  */
-export declare function readIssue(deps: JamDeps, issueKey: string): Promise<FullIssueContext>;
+export type IssueSnapshot = {
+    issue: FullIssueContext;
+    /** Identity of the current assignee, which `issue.assignee` cannot supply. */
+    assigneeAccountId?: string;
+};
+export declare function readIssue(deps: JamDeps, issueKey: string): Promise<IssueSnapshot>;