ticketlens 0.38.49 → 0.38.51

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ticketlens",
-  "version": "0.38.49",
+  "version": "0.38.51",
   "description": "Jira CLI for developers — fetch ticket context, triage your queue, and stop tab-switching. Zero dependencies, all local.",
   "type": "module",
   "bin": {

package/skills/jtb/SKILL.md

@@ -1,4 +1,4 @@
-<!-- jtb-skill-version: 0.43.0 -->
+<!-- jtb-skill-version: 0.43.1 -->
 ---
 name: jtb
 description: Fetch a Jira ticket's full context (description, comments, linked issues, code references) and assemble a structured TicketBrief for implementation planning. Use when user types /jtb, mentions a Jira ticket key, or wants to plan work from a Jira ticket.
@@ -424,6 +424,8 @@ ticketlens assign PROD-1234 --to=me                          # assign to yoursel
 ticketlens duplicates PROD-1234                               # find likely duplicates — read-only
 ticketlens link PROD-1234 PROD-5678                            # list valid link types — read-only
 ticketlens link PROD-1234 PROD-5678 --type="Duplicate" --confirm  # execute the link
+# Jira's list shows the real resulting sentence per type (e.g. "Blocks — PROD-1234 blocks PROD-5678")
+# so direction is never a guess — GitHub/Linear show just the type name (single relation, no ambiguity)
 ticketlens update PROD-1234 --title="Fix login on mobile"     # update title/description/labels/priority
 ticketlens update PROD-1234 --add-labels=urgent --remove-labels=stale
 ticketlens create --project=PROD --type="Task" --summary="Fix login on mobile"  # create a new ticket

package/skills/jtb/scripts/lib/adapters/jira-adapter.mjs

@@ -109,19 +109,26 @@ export function createJiraAdapter(conn, { fetcher = globalThis.fetch } = {}) {
     /**
      * Always fetched fresh — link type names are per-instance customizable
      * in Jira, same "never trust a stale list" principle as getTransitions.
-     * Returns just names (matches GitHub/Linear's plain-string shape) so
-     * runTicketLinkList can render any tracker's list uniformly.
+     * Returns name+inward+outward (backlog #31), not just the bare name:
+     * a bare name forces the caller to guess which end gets which phrase,
+     * which is exactly what produced 5 recurring "direction inverted"
+     * reports despite linkTo()'s own outward/inward mapping being correct
+     * and tested. GitHub/Linear keep returning plain strings — single
+     * relation type, no phrase ambiguity there.
      */
     async getLinkTypes(opts = {}) {
       const types = await getIssueLinkTypes({ ...base, ...opts });
-      return types.map(t => t.name);
+      return types.map(t => ({ name: t.name, inward: t.inward, outward: t.outward }));
     },
 
     /**
      * Always re-fetches link types fresh and resolves `typeName` against
      * them before executing — a caller can never blind-POST a stale or
      * guessed type name, same principle as transition().
-     * sourceKey is the outwardIssue, targetKey is the inwardIssue — direction matters.
+     * sourceKey ends up performing the type's outward verb onto targetKey
+     * (e.g. "sourceKey duplicates targetKey") — see postIssueLink's own
+     * doc comment in jira-client.mjs for why its POST body's field names
+     * don't map the way you'd guess from Jira's GET-response convention.
      */
     async linkTo(sourceKey, targetKey, typeName, opts = {}) {
       const types = await getIssueLinkTypes({ ...base, ...opts });

package/skills/jtb/scripts/lib/api-utils.mjs

@@ -3,7 +3,7 @@
  * Centralised here to avoid triplicating the regex and warning logic.
  */
 
-export const DEFAULT_API_BASE = 'https://api.ticketlens.app';
+export const DEFAULT_API_BASE = 'http://api.ticketlens.test';
 export const DEFAULT_SITE_BASE = 'https://ticketlens.app';
 
 // Matches localhost, 127.0.0.1, and any hostname ending in .test or .local,

package/skills/jtb/scripts/lib/jira-client.mjs

@@ -544,10 +544,20 @@ export async function getIssueLinkTypes(opts = {}) {
 }
 
 /**
- * Creates a link between two issues. `sourceKey` is the outwardIssue (the
- * subject of the type's outward verb, e.g. "Duplicates"), `targetKey` is
- * the inwardIssue — direction matters and is the caller's responsibility
- * to get right (ticket-command.mjs documents the convention).
+ * Creates a link between two issues so `sourceKey` performs the type's
+ * outward verb onto `targetKey` (e.g. "sourceKey duplicates targetKey").
+ *
+ * The POST body's `outwardIssue`/`inwardIssue` keys are the REVERSE of what
+ * you'd expect from the GET /issue response's self-referential convention
+ * (where an issue's OWN `issuelinks` entry uses `outwardIssue` to mean "I am
+ * the outward/performing side") — sending `outwardIssue: sourceKey` there
+ * produces the OPPOSITE real relationship. Live-verified against two real
+ * Jira Cloud instances, cross-checked from both linked issues' own GET
+ * responses, reproduced twice independently (Blocks and Duplicate types,
+ * both argument orders) — not a guess, not doc-derived. This is backlog
+ * #31's actual root cause: every prior "direction inverted" report was
+ * real, and no unit test caught it because mocked HTTP calls can only
+ * assert the request shape, never Jira's real interpretation of it.
  */
 export async function postIssueLink(sourceKey, targetKey, typeName, opts = {}) {
   const { env = process.env, fetcher = globalThis.fetch, lookup = defaultLookupFor(fetcher), apiVersion = 2, timeoutMs = 10_000, allowPrivateIp = false } = opts;
@@ -558,7 +568,7 @@ export async function postIssueLink(sourceKey, targetKey, typeName, opts = {}) {
   const fetchOpts = {
     method: 'POST',
     headers: { ...buildAuthHeader(env), 'Content-Type': 'application/json' },
-    body: JSON.stringify({ type: { name: typeName }, outwardIssue: { key: sourceKey }, inwardIssue: { key: targetKey } }),
+    body: JSON.stringify({ type: { name: typeName }, outwardIssue: { key: targetKey }, inwardIssue: { key: sourceKey } }),
   };
   if (timeoutMs) fetchOpts.signal = AbortSignal.timeout(timeoutMs);
 

package/skills/jtb/scripts/lib/ticket-command.mjs

@@ -577,7 +577,7 @@ export async function runTicketDuplicates(cmdArgs, {
  *
  * @param {string[]} cmdArgs - [sourceKey, targetKey]
  * @param {boolean} [cliHints] - see runTicketTransitionList's cliHints doc
- * @returns {Promise<{ ok: boolean, types?: string[] }>}
+ * @returns {Promise<{ ok: boolean, types?: (string|{name: string, inward: string, outward: string})[] }>}
  */
 export async function runTicketLinkList(cmdArgs, {
   configDir = DEFAULT_CONFIG_DIR,
@@ -607,7 +607,14 @@ export async function runTicketLinkList(cmdArgs, {
       return { ok: true, types: [] };
     }
     stream.write(`  Available link types for ${s.brand(s.bold(sourceKey))} → ${s.brand(s.bold(targetKey))} (${adapter.type}):\n\n`);
-    for (const t of types) stream.write(`    ${s.brand('●')} ${t}\n`);
+    for (const t of types) {
+      // Backlog #31: a bare type name (e.g. "Blocks") hides which end gets
+      // which phrase — show the real resulting sentence so the caller
+      // doesn't have to guess direction. GitHub/Linear still hand back
+      // plain strings (no inward/outward phrase pair to show).
+      const line = typeof t === 'string' ? t : `${t.name} — ${sourceKey} ${t.outward ?? t.name} ${targetKey}`;
+      stream.write(`    ${s.brand('●')} ${line}\n`);
+    }
     stream.write('\n');
     if (adapter.type === 'github') {
       stream.write(`  Note: GitHub has no generic link relationship — linking will CLOSE ${sourceKey} as a duplicate of ${targetKey}.\n`);