@codyswann/lisa 4.10.5 → 4.10.6

package/plugins/lisa-agy/skills/lisa-jira-evidence/SKILL.md

@@ -35,7 +35,10 @@ Upload captured evidence and generated templates to GitHub PR description and JI
 ## Prerequisites
 
 - `JIRA_API_TOKEN` environment variable set
-- `jira-cli` configured (`~/.config/.jira/.config.yml`) — server and login are read from there
+- a jira-cli config — `.lisa/jira-cli/.config.yml` if the `setup-jira-cli`
+  SessionStart hook wrote one, otherwise `~/.config/.jira/.config.yml`. `server`
+  and `login` are read from whichever is used, and the fallback is announced on
+  stderr rather than taken silently.
 - `gh` CLI authenticated
 - Evidence directory containing:
   - `NN-name.txt` or `NN-name.json` text evidence files (e.g., `01-health-check.json`)
@@ -66,7 +69,7 @@ bash .claude/skills/jira-evidence/scripts/post-evidence.sh PROJ-123 ./evidence 4
 
 ## What It Does
 
-1. **Read JIRA config** — Reads `~/.config/.jira/.config.yml` to obtain `server` and `login` dynamically
+1. **Read JIRA config** — Resolves the jira-cli config (`$PROJECT_DIR/.lisa/jira-cli/.config.yml` first, then `~/.config/.jira/.config.yml`, announcing the fallback) and reads `server` and `login` from it dynamically — no hardcoded values. Exits 1 naming both paths when neither exists. The same resolved path is then passed to `jira issue move` as `--config`, so the CLI cannot end up on a different config than the one this script parsed.
 2. **Upload to GitHub `pr-assets` release** — Uploads evidence files via `gh release upload --clobber`
 3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body
 4. **Post JIRA comment** — Posts `comment.txt` as a new comment (wiki markup with code blocks)
@@ -97,4 +100,4 @@ gh release create pr-assets --title "PR Assets" --notes "CDN for PR evidence"
 
 ### JIRA API returns 403
 
-Ensure `JIRA_API_TOKEN` is set and `login` in `~/.config/.jira/.config.yml` matches your Atlassian account email.
+Ensure `JIRA_API_TOKEN` is set and `login` in the resolved jira-cli config (`.lisa/jira-cli/.config.yml`, else `~/.config/.jira/.config.yml`) matches your Atlassian account email.

package/plugins/lisa-agy/skills/lisa-jira-evidence/scripts/post-evidence.sh

@@ -6,7 +6,11 @@
 #
 # Prerequisites:
 #   - JIRA_API_TOKEN env var set
-#   - jira-cli configured (~/.config/.jira/.config.yml)
+#   - a jira-cli config, resolved in this order (see "CONFIG RESOLUTION" below):
+#       1. ${PROJECT_DIR}/.lisa/jira-cli/.config.yml  (written by the
+#          setup-jira-cli SessionStart hook from the JIRA_* environment)
+#       2. ~/.config/.jira/.config.yml                (a developer's own
+#          `jira init` config; announced on stderr when it is used)
 #   - gh CLI authenticated
 #
 # What it does:
@@ -23,9 +27,50 @@ TICKET_ID="${1:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
 EVIDENCE_DIR="${2:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
 PR_NUMBER="${3:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
 
-JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
-if [[ ! -f "$JIRA_CONFIG" ]]; then
-  echo "ERROR: jira-cli config not found at $JIRA_CONFIG — run 'jira init' first" >&2
+# ─────────────────────────────────────────────────────────────────────────────
+# CONFIG RESOLUTION
+#
+# The setup-jira-cli SessionStart hook writes ${PROJECT_DIR}/.lisa/jira-cli/
+# .config.yml. Nothing read it — this script looked only at the developer's own
+# ~/.config/.jira/.config.yml and exited 1 telling the operator to run
+# `jira init`, so on a headless JIRA project the hook was an inert control.
+# See CodySwannGT/lisa#2767.
+#
+# PROJECT_DIR is resolved with the same rule as the hook that writes the file,
+# deliberately character-for-character: CLAUDE_PROJECT_DIR (the harness's own
+# declaration of the root, inert on harnesses that never set it), then the git
+# toplevel, then pwd. A session launched from a subdirectory otherwise reads a
+# directory it never wrote — the #2768 defect, on the read side.
+#
+# Nothing here writes to ~/.config/.jira. That file is a developer's personal
+# jira-cli state; it is read as a fallback and never created or modified.
+#
+# NOTE: the `.lisa.config.json` reads in Step 5 below are still resolved from
+# the process working directory. That is pre-existing and out of scope here.
+# ─────────────────────────────────────────────────────────────────────────────
+PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
+if [[ -z "${PROJECT_DIR}" || ! -d "${PROJECT_DIR}" ]]; then
+  PROJECT_DIR="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
+fi
+PROJECT_JIRA_CONFIG="${PROJECT_DIR}/.lisa/jira-cli/.config.yml"
+HOME_JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
+
+if [[ -f "$PROJECT_JIRA_CONFIG" ]]; then
+  JIRA_CONFIG="$PROJECT_JIRA_CONFIG"
+elif [[ -f "$HOME_JIRA_CONFIG" ]]; then
+  # Announced, never silent. A silent fall-through to the developer's own file
+  # is precisely how the Lisa-written config stayed unconsumed without anyone
+  # noticing, and on a headless runner there is no such file to fall back to.
+  echo "NOTE: no Lisa-written jira-cli config at $PROJECT_JIRA_CONFIG" >&2
+  echo "      falling back to the developer config at $HOME_JIRA_CONFIG" >&2
+  JIRA_CONFIG="$HOME_JIRA_CONFIG"
+else
+  echo "ERROR: jira-cli config not found." >&2
+  echo "  Lisa-written config (expected): $PROJECT_JIRA_CONFIG" >&2
+  echo "  developer config (fallback):    $HOME_JIRA_CONFIG" >&2
+  echo "  Fix: export JIRA_SERVER, JIRA_LOGIN (and JIRA_INSTALLATION," >&2
+  echo "  JIRA_PROJECT) and start a new session so the setup-jira-cli hook" >&2
+  echo "  writes the project config — or run 'jira init' locally." >&2
   exit 1
 fi
 JIRA_SERVER=$(grep '^server:' "$JIRA_CONFIG" | awk '{print $2}')
@@ -169,7 +214,13 @@ fi
 echo ""
 if [ -n "$REVIEW" ]; then
   echo "==> Moving $TICKET_ID to $REVIEW..."
-  jira issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
+  # --config pins jira-cli to the same file this script parsed above.
+  # jira-cli resolves --config > JIRA_CONFIG_FILE > ~/.config/.jira/
+  # .config.yml, and a --config path that does not exist fails closed
+  # rather than falling back (measured against jira-cli v1.7.0). The flag
+  # needs no environment export, so this works identically on every
+  # harness — see the harness note in the setup-jira-cli hook.
+  jira --config "$JIRA_CONFIG" issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
 else
   echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
 fi

package/plugins/lisa-agy/skills/lisa-jira-journey/SKILL.md

@@ -20,7 +20,8 @@ Parse a JIRA ticket's Validation Journey, execute the verification steps using t
 ## Prerequisites
 
 - `JIRA_API_TOKEN` environment variable set
-- `jira-cli` configured (`~/.config/.jira/.config.yml`)
+- `jira-cli` configured — `.lisa/jira-cli/.config.yml` (written by the
+  `setup-jira-cli` SessionStart hook) or `~/.config/.jira/.config.yml`
 - `gh` CLI authenticated
 - Appropriate services running for the verification type (dev server, database, etc.)
 

package/plugins/lisa-agy/skills/lisa-jira-read-ticket/scripts/download-attachment.sh

@@ -19,6 +19,13 @@
 #   JIRA_LOGIN      - login email
 #   JIRA_API_TOKEN  - API token (https://id.atlassian.com/manage-profile/security/api-tokens)
 #
+#   JIRA_SERVER and JIRA_LOGIN each fall back to a jira-cli config when unset:
+#   ${PROJECT_DIR}/.lisa/jira-cli/.config.yml (written by the setup-jira-cli
+#   SessionStart hook) first, then ${HOME}/.config/.jira/.config.yml, with the
+#   fallback announced on stderr. When BOTH env vars are set, no config file is
+#   opened at all. JIRA_API_TOKEN has no config fallback — it is a secret and
+#   is never written to the jira-cli config.
+#
 # Exit codes:
 #   0  success
 #   1  download failed (HTTP error)
@@ -34,12 +41,54 @@ fi
 ID_OR_URL="$1"
 OUTPUT_PATH="$2"
 
-# Resolve credentials: prefer env, fall back to jira-cli config for server/login.
-JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
-if [[ -z "${JIRA_SERVER:-}" && -f "$JIRA_CONFIG" ]]; then
+# ─────────────────────────────────────────────────────────────────────────────
+# Resolve credentials: prefer env, fall back to a jira-cli config for
+# server/login.
+#
+# The env-first arm is load-bearing and unchanged: a headless environment that
+# exports JIRA_SERVER and JIRA_LOGIN never opens a config file at all. The
+# resolution below is therefore gated on actually needing it.
+#
+# What changed (CodySwannGT/lisa#2767): the fallback looked only at the
+# developer's own ~/.config/.jira/.config.yml. The setup-jira-cli SessionStart
+# hook writes ${PROJECT_DIR}/.lisa/jira-cli/.config.yml, which nothing read —
+# so on a headless JIRA project with the JIRA_* vars absent, the file Lisa had
+# just written was ignored and this script exited 2. The Lisa-written config is
+# now preferred, with the developer config kept as an announced fallback.
+#
+# PROJECT_DIR uses the same rule as the hook that writes the file:
+# CLAUDE_PROJECT_DIR, then the git toplevel, then pwd. Resolving from the
+# process working directory instead would reintroduce #2768 on the read side.
+#
+# Nothing here writes to ~/.config/.jira — it is read, never created.
+# ─────────────────────────────────────────────────────────────────────────────
+JIRA_CONFIG=""
+if [[ -z "${JIRA_SERVER:-}" || -z "${JIRA_LOGIN:-}" ]]; then
+  PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
+  if [[ -z "${PROJECT_DIR}" || ! -d "${PROJECT_DIR}" ]]; then
+    PROJECT_DIR="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
+  fi
+  PROJECT_JIRA_CONFIG="${PROJECT_DIR}/.lisa/jira-cli/.config.yml"
+  HOME_JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
+
+  if [[ -f "$PROJECT_JIRA_CONFIG" ]]; then
+    JIRA_CONFIG="$PROJECT_JIRA_CONFIG"
+  elif [[ -f "$HOME_JIRA_CONFIG" ]]; then
+    # Announced, never silent — a quiet fall-through to the developer's own
+    # file is how the Lisa-written config stayed unconsumed unnoticed.
+    echo "NOTE: no Lisa-written jira-cli config at $PROJECT_JIRA_CONFIG" >&2
+    echo "      falling back to the developer config at $HOME_JIRA_CONFIG" >&2
+    JIRA_CONFIG="$HOME_JIRA_CONFIG"
+  else
+    echo "NOTE: no jira-cli config at $PROJECT_JIRA_CONFIG" >&2
+    echo "      or $HOME_JIRA_CONFIG; relying on the environment alone." >&2
+  fi
+fi
+
+if [[ -z "${JIRA_SERVER:-}" && -n "$JIRA_CONFIG" ]]; then
   JIRA_SERVER=$(grep '^server:' "$JIRA_CONFIG" | awk '{print $2}')
 fi
-if [[ -z "${JIRA_LOGIN:-}" && -f "$JIRA_CONFIG" ]]; then
+if [[ -z "${JIRA_LOGIN:-}" && -n "$JIRA_CONFIG" ]]; then
   JIRA_LOGIN=$(grep '^login:' "$JIRA_CONFIG" | awk '{print $2}')
 fi
 

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.10.5",
+  "version": "4.10.6",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.10.5",
+  "version": "4.10.6",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.10.5",
+  "version": "4.10.6",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.10.5",
+  "version": "4.10.6",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.10.5",
+  "version": "4.10.6",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.10.5",
+  "version": "4.10.6",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/hooks/setup-jira-cli.sh

@@ -44,6 +44,56 @@ cat >/dev/null 2>&1 || true
 # one resolution rule, allowed to drift, is what produced the Codex half of
 # this defect in the first place.
 # ---------------------------------------------------------------------------
+
+# ---------------------------------------------------------------------------
+# WHO READS WHAT THIS WRITES — and why no per-harness env export is needed.
+#
+# `${PROJECT_DIR}/.lisa/jira-cli/.config.yml` had NO reader at all until
+# CodySwannGT/lisa#2767: the hook wrote a file, every consumer looked at
+# `${HOME}/.config/.jira/.config.yml` instead, and the hook was therefore an
+# inert control that reported success while feeding nothing. It now has three
+# consumers, all Lisa-owned:
+#
+#   * lisa-jira-evidence/scripts/post-evidence.sh — greps `server:`/`login:`
+#     out of this YAML, then passes `--config <path>` to `jira issue move`.
+#   * lisa-jira-read-ticket/scripts/download-attachment.sh — greps the same two
+#     keys, but ONLY when JIRA_SERVER/JIRA_LOGIN are unset. Env still wins; a
+#     headless runner with those exported never opens this file.
+#   * SKILL prose (lisa-jira-add-journey, base-rules) — types
+#     `jira --config .lisa/jira-cli/.config.yml issue view <KEY>`.
+#
+# #2767 framed the blocking question as "can a SessionStart hook export an
+# environment variable into the agent's later tool invocations, and does that
+# differ per harness?" That question is MOOT for every consumer above, because
+# none of them needs an export:
+#
+#   - Two of the three parse this YAML themselves, in Lisa-owned shell.
+#   - The one real jira-cli invocation passes `--config`, an ARGUMENT. It
+#     crosses no process boundary, so it behaves identically on Claude Code,
+#     Codex, Cursor, Copilot, OpenCode and Antigravity. There is no per-harness
+#     capability to record because no harness capability is used.
+#
+# The only surface where an export could still have mattered is a freehand
+# `jira ...` an agent types from SKILL prose. That is compensated at the same
+# rung rather than dropped: the prose types `--config` too. `JIRA_CONFIG_FILE`
+# is deliberately exported NOWHERE in Lisa — an unexported variable is another
+# inert control, and the flag makes the export unnecessary.
+#
+# jira-cli's own resolution order, MEASURED against v1.7.0 (darwin/arm64)
+# rather than taken from its README:
+#
+#   1. `--config`/`-c <path>`               (highest; accepted either before or
+#                                            after the subcommand)
+#   2. `JIRA_CONFIG_FILE=<path>`
+#   3. `${HOME}/.config/.jira/.config.yml`  (default)
+#
+# A path named by (1) or (2) that does not exist FAILS CLOSED: jira-cli prints
+# "Missing configuration file." and exits 1 — it does NOT fall back to (3).
+# That is what makes passing `--config` safe rather than a silent no-op.
+#
+# This hook never writes to `${HOME}/.config/.jira`. That is a developer's
+# personal jira-cli state; consumers read it as an ANNOUNCED fallback only.
+# ---------------------------------------------------------------------------
 PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
 if [[ -z "${PROJECT_DIR}" || ! -d "${PROJECT_DIR}" ]]; then
   PROJECT_DIR="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"

package/plugins/lisa-copilot/rules/reference/base-rules.md

@@ -70,7 +70,7 @@ Testing Discipline:
 JIRA Discipline:
 - If working on a JIRA issue, make sure the branch you're working on references and is added to the JIRA issue.
 - If working on a JIRA issue, update the issue as you work through it. For example, if working on a Bug Triage, update the issue with your questions/feedback/suggestions.
-- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or `jira issue view <TICKET_ID> --comments 100` to fetch them.
+- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or `jira --config .lisa/jira-cli/.config.yml issue view <TICKET_ID> --comments 100` to fetch them (the `--config` pins jira-cli to the config the `setup-jira-cli` hook wrote; drop it to use the machine's own `~/.config/.jira/.config.yml`).
 - When requesting clarification on a JIRA issue, post the question as a comment using ADF (Atlassian Document Format) and @mention the Reporter so they receive a notification.
 - When creating JIRA tickets, establish issue link relationships (e.g. "is blocked by", "blocks", "relates to", "is duplicated by") between tickets that have dependencies or logical connections. Do not leave related tickets unlinked. Relationship discovery is mandatory on every create and update — search BOTH the local git history (`git log --all --grep=<keyword>`, `git log -- <path>`) AND Jira (JQL by component, keyword, label, epic siblings) before declaring "no related work." Record the searches you ran and their outcomes in the description (or a comment) so a reviewer can see the search was real.
 - Ticket scope by type: Bug, Task, and Sub-task tickets MUST be single-repo (one work unit, one repo). Epic, Spike, and Story tickets MAY span multiple repos. If a Bug/Task/Sub-task crosses repos, split it per the `repo-scope-split` rule — at PRD-decomposition time via `task-decomposition` step 1.5 (parent Story + per-repo children); at work-time (an existing ticket an agent is about to implement) via the work-time split procedure (narrow the original to one repo, spin off a sibling per additional repo cloning its metadata, link the producer→consumer dependency, then proceed). A cross-repo work unit is a decomposition error the agent fixes by splitting, not a reason to bounce the ticket to the reporter.

package/plugins/lisa-copilot/skills/lisa-jira-add-journey/SKILL.md

@@ -16,7 +16,12 @@ Read an existing JIRA ticket, analyze the change type, and generate a Validation
 ## Prerequisites
 
 - `JIRA_API_TOKEN` environment variable set
-- `jira-cli` configured (`~/.config/.jira/.config.yml`)
+- `jira-cli` configured. Prefer the config Lisa writes at
+  `.lisa/jira-cli/.config.yml` (the `setup-jira-cli` SessionStart hook writes it
+  from `JIRA_SERVER` / `JIRA_LOGIN` / `JIRA_PROJECT` on a project whose
+  `tracker` is `jira`), and pass it explicitly with `--config`. A developer's
+  own `~/.config/.jira/.config.yml` still works as jira-cli's default when no
+  `--config` is given.
 
 ## Workflow
 
@@ -25,9 +30,18 @@ Read an existing JIRA ticket, analyze the change type, and generate a Validation
 Use the Atlassian MCP or jira-cli to read the full ticket details:
 
 ```bash
-jira issue view <TICKET_ID>
+# Run from the project root. --config pins jira-cli to the file Lisa's
+# setup-jira-cli hook wrote, instead of the machine's own ~/.config/.jira.
+# jira-cli resolves --config > JIRA_CONFIG_FILE > ~/.config/.jira/.config.yml,
+# and a --config path that does not exist fails closed with "Missing
+# configuration file." rather than silently using the default.
+jira --config .lisa/jira-cli/.config.yml issue view <TICKET_ID>
 ```
 
+If `.lisa/jira-cli/.config.yml` does not exist, drop `--config` to fall back to
+the machine's own jira-cli config — but say so in your report rather than
+letting the Lisa-written config go quietly unused.
+
 Extract: title, description, acceptance criteria, components, labels, linked tickets.
 
 ### Step 2: Check for Existing Journey

package/plugins/lisa-copilot/skills/lisa-jira-evidence/SKILL.md

@@ -35,7 +35,10 @@ Upload captured evidence and generated templates to GitHub PR description and JI
 ## Prerequisites
 
 - `JIRA_API_TOKEN` environment variable set
-- `jira-cli` configured (`~/.config/.jira/.config.yml`) — server and login are read from there
+- a jira-cli config — `.lisa/jira-cli/.config.yml` if the `setup-jira-cli`
+  SessionStart hook wrote one, otherwise `~/.config/.jira/.config.yml`. `server`
+  and `login` are read from whichever is used, and the fallback is announced on
+  stderr rather than taken silently.
 - `gh` CLI authenticated
 - Evidence directory containing:
   - `NN-name.txt` or `NN-name.json` text evidence files (e.g., `01-health-check.json`)
@@ -66,7 +69,7 @@ bash .claude/skills/jira-evidence/scripts/post-evidence.sh PROJ-123 ./evidence 4
 
 ## What It Does
 
-1. **Read JIRA config** — Reads `~/.config/.jira/.config.yml` to obtain `server` and `login` dynamically
+1. **Read JIRA config** — Resolves the jira-cli config (`$PROJECT_DIR/.lisa/jira-cli/.config.yml` first, then `~/.config/.jira/.config.yml`, announcing the fallback) and reads `server` and `login` from it dynamically — no hardcoded values. Exits 1 naming both paths when neither exists. The same resolved path is then passed to `jira issue move` as `--config`, so the CLI cannot end up on a different config than the one this script parsed.
 2. **Upload to GitHub `pr-assets` release** — Uploads evidence files via `gh release upload --clobber`
 3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body
 4. **Post JIRA comment** — Posts `comment.txt` as a new comment (wiki markup with code blocks)
@@ -97,4 +100,4 @@ gh release create pr-assets --title "PR Assets" --notes "CDN for PR evidence"
 
 ### JIRA API returns 403
 
-Ensure `JIRA_API_TOKEN` is set and `login` in `~/.config/.jira/.config.yml` matches your Atlassian account email.
+Ensure `JIRA_API_TOKEN` is set and `login` in the resolved jira-cli config (`.lisa/jira-cli/.config.yml`, else `~/.config/.jira/.config.yml`) matches your Atlassian account email.

package/plugins/lisa-copilot/skills/lisa-jira-evidence/scripts/post-evidence.sh

@@ -6,7 +6,11 @@
 #
 # Prerequisites:
 #   - JIRA_API_TOKEN env var set
-#   - jira-cli configured (~/.config/.jira/.config.yml)
+#   - a jira-cli config, resolved in this order (see "CONFIG RESOLUTION" below):
+#       1. ${PROJECT_DIR}/.lisa/jira-cli/.config.yml  (written by the
+#          setup-jira-cli SessionStart hook from the JIRA_* environment)
+#       2. ~/.config/.jira/.config.yml                (a developer's own
+#          `jira init` config; announced on stderr when it is used)
 #   - gh CLI authenticated
 #
 # What it does:
@@ -23,9 +27,50 @@ TICKET_ID="${1:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
 EVIDENCE_DIR="${2:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
 PR_NUMBER="${3:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
 
-JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
-if [[ ! -f "$JIRA_CONFIG" ]]; then
-  echo "ERROR: jira-cli config not found at $JIRA_CONFIG — run 'jira init' first" >&2
+# ─────────────────────────────────────────────────────────────────────────────
+# CONFIG RESOLUTION
+#
+# The setup-jira-cli SessionStart hook writes ${PROJECT_DIR}/.lisa/jira-cli/
+# .config.yml. Nothing read it — this script looked only at the developer's own
+# ~/.config/.jira/.config.yml and exited 1 telling the operator to run
+# `jira init`, so on a headless JIRA project the hook was an inert control.
+# See CodySwannGT/lisa#2767.
+#
+# PROJECT_DIR is resolved with the same rule as the hook that writes the file,
+# deliberately character-for-character: CLAUDE_PROJECT_DIR (the harness's own
+# declaration of the root, inert on harnesses that never set it), then the git
+# toplevel, then pwd. A session launched from a subdirectory otherwise reads a
+# directory it never wrote — the #2768 defect, on the read side.
+#
+# Nothing here writes to ~/.config/.jira. That file is a developer's personal
+# jira-cli state; it is read as a fallback and never created or modified.
+#
+# NOTE: the `.lisa.config.json` reads in Step 5 below are still resolved from
+# the process working directory. That is pre-existing and out of scope here.
+# ─────────────────────────────────────────────────────────────────────────────
+PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
+if [[ -z "${PROJECT_DIR}" || ! -d "${PROJECT_DIR}" ]]; then
+  PROJECT_DIR="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
+fi
+PROJECT_JIRA_CONFIG="${PROJECT_DIR}/.lisa/jira-cli/.config.yml"
+HOME_JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
+
+if [[ -f "$PROJECT_JIRA_CONFIG" ]]; then
+  JIRA_CONFIG="$PROJECT_JIRA_CONFIG"
+elif [[ -f "$HOME_JIRA_CONFIG" ]]; then
+  # Announced, never silent. A silent fall-through to the developer's own file
+  # is precisely how the Lisa-written config stayed unconsumed without anyone
+  # noticing, and on a headless runner there is no such file to fall back to.
+  echo "NOTE: no Lisa-written jira-cli config at $PROJECT_JIRA_CONFIG" >&2
+  echo "      falling back to the developer config at $HOME_JIRA_CONFIG" >&2
+  JIRA_CONFIG="$HOME_JIRA_CONFIG"
+else
+  echo "ERROR: jira-cli config not found." >&2
+  echo "  Lisa-written config (expected): $PROJECT_JIRA_CONFIG" >&2
+  echo "  developer config (fallback):    $HOME_JIRA_CONFIG" >&2
+  echo "  Fix: export JIRA_SERVER, JIRA_LOGIN (and JIRA_INSTALLATION," >&2
+  echo "  JIRA_PROJECT) and start a new session so the setup-jira-cli hook" >&2
+  echo "  writes the project config — or run 'jira init' locally." >&2
   exit 1
 fi
 JIRA_SERVER=$(grep '^server:' "$JIRA_CONFIG" | awk '{print $2}')
@@ -169,7 +214,13 @@ fi
 echo ""
 if [ -n "$REVIEW" ]; then
   echo "==> Moving $TICKET_ID to $REVIEW..."
-  jira issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
+  # --config pins jira-cli to the same file this script parsed above.
+  # jira-cli resolves --config > JIRA_CONFIG_FILE > ~/.config/.jira/
+  # .config.yml, and a --config path that does not exist fails closed
+  # rather than falling back (measured against jira-cli v1.7.0). The flag
+  # needs no environment export, so this works identically on every
+  # harness — see the harness note in the setup-jira-cli hook.
+  jira --config "$JIRA_CONFIG" issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
 else
   echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
 fi

package/plugins/lisa-copilot/skills/lisa-jira-journey/SKILL.md

@@ -20,7 +20,8 @@ Parse a JIRA ticket's Validation Journey, execute the verification steps using t
 ## Prerequisites
 
 - `JIRA_API_TOKEN` environment variable set
-- `jira-cli` configured (`~/.config/.jira/.config.yml`)
+- `jira-cli` configured — `.lisa/jira-cli/.config.yml` (written by the
+  `setup-jira-cli` SessionStart hook) or `~/.config/.jira/.config.yml`
 - `gh` CLI authenticated
 - Appropriate services running for the verification type (dev server, database, etc.)
 

package/plugins/lisa-copilot/skills/lisa-jira-read-ticket/scripts/download-attachment.sh

@@ -19,6 +19,13 @@
 #   JIRA_LOGIN      - login email
 #   JIRA_API_TOKEN  - API token (https://id.atlassian.com/manage-profile/security/api-tokens)
 #
+#   JIRA_SERVER and JIRA_LOGIN each fall back to a jira-cli config when unset:
+#   ${PROJECT_DIR}/.lisa/jira-cli/.config.yml (written by the setup-jira-cli
+#   SessionStart hook) first, then ${HOME}/.config/.jira/.config.yml, with the
+#   fallback announced on stderr. When BOTH env vars are set, no config file is
+#   opened at all. JIRA_API_TOKEN has no config fallback — it is a secret and
+#   is never written to the jira-cli config.
+#
 # Exit codes:
 #   0  success
 #   1  download failed (HTTP error)
@@ -34,12 +41,54 @@ fi
 ID_OR_URL="$1"
 OUTPUT_PATH="$2"
 
-# Resolve credentials: prefer env, fall back to jira-cli config for server/login.
-JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
-if [[ -z "${JIRA_SERVER:-}" && -f "$JIRA_CONFIG" ]]; then
+# ─────────────────────────────────────────────────────────────────────────────
+# Resolve credentials: prefer env, fall back to a jira-cli config for
+# server/login.
+#
+# The env-first arm is load-bearing and unchanged: a headless environment that
+# exports JIRA_SERVER and JIRA_LOGIN never opens a config file at all. The
+# resolution below is therefore gated on actually needing it.
+#
+# What changed (CodySwannGT/lisa#2767): the fallback looked only at the
+# developer's own ~/.config/.jira/.config.yml. The setup-jira-cli SessionStart
+# hook writes ${PROJECT_DIR}/.lisa/jira-cli/.config.yml, which nothing read —
+# so on a headless JIRA project with the JIRA_* vars absent, the file Lisa had
+# just written was ignored and this script exited 2. The Lisa-written config is
+# now preferred, with the developer config kept as an announced fallback.
+#
+# PROJECT_DIR uses the same rule as the hook that writes the file:
+# CLAUDE_PROJECT_DIR, then the git toplevel, then pwd. Resolving from the
+# process working directory instead would reintroduce #2768 on the read side.
+#
+# Nothing here writes to ~/.config/.jira — it is read, never created.
+# ─────────────────────────────────────────────────────────────────────────────
+JIRA_CONFIG=""
+if [[ -z "${JIRA_SERVER:-}" || -z "${JIRA_LOGIN:-}" ]]; then
+  PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
+  if [[ -z "${PROJECT_DIR}" || ! -d "${PROJECT_DIR}" ]]; then
+    PROJECT_DIR="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
+  fi
+  PROJECT_JIRA_CONFIG="${PROJECT_DIR}/.lisa/jira-cli/.config.yml"
+  HOME_JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
+
+  if [[ -f "$PROJECT_JIRA_CONFIG" ]]; then
+    JIRA_CONFIG="$PROJECT_JIRA_CONFIG"
+  elif [[ -f "$HOME_JIRA_CONFIG" ]]; then
+    # Announced, never silent — a quiet fall-through to the developer's own
+    # file is how the Lisa-written config stayed unconsumed unnoticed.
+    echo "NOTE: no Lisa-written jira-cli config at $PROJECT_JIRA_CONFIG" >&2
+    echo "      falling back to the developer config at $HOME_JIRA_CONFIG" >&2
+    JIRA_CONFIG="$HOME_JIRA_CONFIG"
+  else
+    echo "NOTE: no jira-cli config at $PROJECT_JIRA_CONFIG" >&2
+    echo "      or $HOME_JIRA_CONFIG; relying on the environment alone." >&2
+  fi
+fi
+
+if [[ -z "${JIRA_SERVER:-}" && -n "$JIRA_CONFIG" ]]; then
   JIRA_SERVER=$(grep '^server:' "$JIRA_CONFIG" | awk '{print $2}')
 fi
-if [[ -z "${JIRA_LOGIN:-}" && -f "$JIRA_CONFIG" ]]; then
+if [[ -z "${JIRA_LOGIN:-}" && -n "$JIRA_CONFIG" ]]; then
   JIRA_LOGIN=$(grep '^login:' "$JIRA_CONFIG" | awk '{print $2}')
 fi
 

package/plugins/lisa-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.10.5",
+  "version": "4.10.6",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cursor/hooks/setup-jira-cli.sh

@@ -44,6 +44,56 @@ cat >/dev/null 2>&1 || true
 # one resolution rule, allowed to drift, is what produced the Codex half of
 # this defect in the first place.
 # ---------------------------------------------------------------------------
+
+# ---------------------------------------------------------------------------
+# WHO READS WHAT THIS WRITES — and why no per-harness env export is needed.
+#
+# `${PROJECT_DIR}/.lisa/jira-cli/.config.yml` had NO reader at all until
+# CodySwannGT/lisa#2767: the hook wrote a file, every consumer looked at
+# `${HOME}/.config/.jira/.config.yml` instead, and the hook was therefore an
+# inert control that reported success while feeding nothing. It now has three
+# consumers, all Lisa-owned:
+#
+#   * lisa-jira-evidence/scripts/post-evidence.sh — greps `server:`/`login:`
+#     out of this YAML, then passes `--config <path>` to `jira issue move`.
+#   * lisa-jira-read-ticket/scripts/download-attachment.sh — greps the same two
+#     keys, but ONLY when JIRA_SERVER/JIRA_LOGIN are unset. Env still wins; a
+#     headless runner with those exported never opens this file.
+#   * SKILL prose (lisa-jira-add-journey, base-rules) — types
+#     `jira --config .lisa/jira-cli/.config.yml issue view <KEY>`.
+#
+# #2767 framed the blocking question as "can a SessionStart hook export an
+# environment variable into the agent's later tool invocations, and does that
+# differ per harness?" That question is MOOT for every consumer above, because
+# none of them needs an export:
+#
+#   - Two of the three parse this YAML themselves, in Lisa-owned shell.
+#   - The one real jira-cli invocation passes `--config`, an ARGUMENT. It
+#     crosses no process boundary, so it behaves identically on Claude Code,
+#     Codex, Cursor, Copilot, OpenCode and Antigravity. There is no per-harness
+#     capability to record because no harness capability is used.
+#
+# The only surface where an export could still have mattered is a freehand
+# `jira ...` an agent types from SKILL prose. That is compensated at the same
+# rung rather than dropped: the prose types `--config` too. `JIRA_CONFIG_FILE`
+# is deliberately exported NOWHERE in Lisa — an unexported variable is another
+# inert control, and the flag makes the export unnecessary.
+#
+# jira-cli's own resolution order, MEASURED against v1.7.0 (darwin/arm64)
+# rather than taken from its README:
+#
+#   1. `--config`/`-c <path>`               (highest; accepted either before or
+#                                            after the subcommand)
+#   2. `JIRA_CONFIG_FILE=<path>`
+#   3. `${HOME}/.config/.jira/.config.yml`  (default)
+#
+# A path named by (1) or (2) that does not exist FAILS CLOSED: jira-cli prints
+# "Missing configuration file." and exits 1 — it does NOT fall back to (3).
+# That is what makes passing `--config` safe rather than a silent no-op.
+#
+# This hook never writes to `${HOME}/.config/.jira`. That is a developer's
+# personal jira-cli state; consumers read it as an ANNOUNCED fallback only.
+# ---------------------------------------------------------------------------
 PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
 if [[ -z "${PROJECT_DIR}" || ! -d "${PROJECT_DIR}" ]]; then
   PROJECT_DIR="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"

package/plugins/lisa-cursor/rules/base-rules-reference.mdc

@@ -75,7 +75,7 @@ Testing Discipline:
 JIRA Discipline:
 - If working on a JIRA issue, make sure the branch you're working on references and is added to the JIRA issue.
 - If working on a JIRA issue, update the issue as you work through it. For example, if working on a Bug Triage, update the issue with your questions/feedback/suggestions.
-- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or `jira issue view <TICKET_ID> --comments 100` to fetch them.
+- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or `jira --config .lisa/jira-cli/.config.yml issue view <TICKET_ID> --comments 100` to fetch them (the `--config` pins jira-cli to the config the `setup-jira-cli` hook wrote; drop it to use the machine's own `~/.config/.jira/.config.yml`).
 - When requesting clarification on a JIRA issue, post the question as a comment using ADF (Atlassian Document Format) and @mention the Reporter so they receive a notification.
 - When creating JIRA tickets, establish issue link relationships (e.g. "is blocked by", "blocks", "relates to", "is duplicated by") between tickets that have dependencies or logical connections. Do not leave related tickets unlinked. Relationship discovery is mandatory on every create and update — search BOTH the local git history (`git log --all --grep=<keyword>`, `git log -- <path>`) AND Jira (JQL by component, keyword, label, epic siblings) before declaring "no related work." Record the searches you ran and their outcomes in the description (or a comment) so a reviewer can see the search was real.
 - Ticket scope by type: Bug, Task, and Sub-task tickets MUST be single-repo (one work unit, one repo). Epic, Spike, and Story tickets MAY span multiple repos. If a Bug/Task/Sub-task crosses repos, split it per the `repo-scope-split` rule — at PRD-decomposition time via `task-decomposition` step 1.5 (parent Story + per-repo children); at work-time (an existing ticket an agent is about to implement) via the work-time split procedure (narrow the original to one repo, spin off a sibling per additional repo cloning its metadata, link the producer→consumer dependency, then proceed). A cross-repo work unit is a decomposition error the agent fixes by splitting, not a reason to bounce the ticket to the reporter.