@codyswann/lisa 2.173.1 → 2.173.3

package/package.json

@@ -91,7 +91,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/agents/jira-agent.md

@@ -107,7 +107,7 @@ Use the `jira-sync` skill to update the ticket at these milestones:
 Use the `jira-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a JIRA comment
-- Transition the ticket to Code Review
+- Transition the ticket to the configured `jira.workflow.review` status **only if it is set**; if `review` is unconfigured, leave the ticket in `claimed` (do not transition).
 
 ### 8. Suggest Status Transition
 
@@ -116,7 +116,7 @@ Based on the milestone, suggest (but don't auto-transition). Status role names a
 | Milestone | Suggested role | Default status |
 |-----------|----------------|----------------|
 | Plan created | `claimed` | `In Progress` |
-| PR ready | (review-equivalent — project's code-review status) | `In Review` |
+| PR ready | (review-equivalent — project's review status) | the configured `jira.workflow.review` status, or **no transition** when `review` is unconfigured |
 | PR merged | `done` (env-aware) | `Done` (or env-keyed variant per `jira.workflow.done`) |
 
 Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved status name to the human; do not auto-transition.
@@ -124,6 +124,7 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 ## Rules
 
 - Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status, add the configured `human_needed` marker label (`jira.labels.human_needed`, default `Human Needed`), and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
+- Any transition is config-bound: never invent transitions; a transition may target only a status named in `config.jira.workflow`. Don't guess from the live workflow. The evidence-time review hop (Step 7) follows this rule too — it is config-bound, optional, and skipped when `jira.workflow.review` is absent (the ticket stays in `claimed`).
 - Always read the full ticket graph via `jira-read-ticket` before determining intent — don't rely on ticket type alone
 - Never create or materially edit a ticket by calling MCP write tools directly — always delegate to `jira-write-ticket` so relationships, Gherkin criteria, and metadata gates are enforced
 - If sign-in credentials are in the ticket, extract and pass them to the flow. If the ticket touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

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

@@ -1,16 +1,16 @@
 ---
 name: jira-evidence
-description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured code-review status. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
 ---
 
 # JIRA Evidence Posting
 
 ## Workflow resolution
 
-The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`), falling back to `Code Review`. JIRA does not have a separate `review` role in the canonical config schema (the build lifecycle stays in `claimed` until `done`); this skill uses the project's actual post-build review status when one exists. If the configured status is not a valid transition from the ticket's current state, log a warning and skip the transition — the human will handle it.
+The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`). `review` is optional; when unset, the ticket stays in `claimed` until `done` and this skill skips the transition. Never transition to a status that is not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
 
 ```bash
-REVIEW="Code Review"
+REVIEW=""
 if [ -f .lisa.config.json ]; then
   _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
   [ -n "$_cfg" ] && REVIEW="$_cfg"

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

@@ -14,7 +14,8 @@
 #   2. Updates the GitHub PR description with evidence/comment.md
 #   3. Uploads image evidence as JIRA attachments
 #   4. Posts/updates the JIRA comment with evidence/comment.txt
-#   5. Moves the JIRA ticket to "Code Review"
+#   5. Moves the JIRA ticket to the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
 
 set -euo pipefail
 
@@ -152,10 +153,26 @@ else
   echo "$RESP" | grep -v "HTTP_CODE:" | head -3
 fi
 
-# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+# ── Step 5: Move ticket to the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
 echo ""
-echo "==> Moving $TICKET_ID to Code Review..."
-jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+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
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
 
 echo ""
 echo "==> Done!"

package/plugins/lisa/skills/jira-sync/SKILL.md

@@ -67,7 +67,7 @@ Based on the milestone, suggest (but don't automatically perform) a status trans
 | Milestone | Suggested Status |
 |-----------|-----------------|
 | Plan created | "In Progress" |
-| PR ready | "In Review" |
+| PR ready | configured `jira.workflow.review` status, or no transition when unconfigured |
 | PR merged | "Done" |
 
 ### Step 5: Parent Status Rollup (`--rollup`)

package/plugins/lisa/skills/tracker-evidence/SKILL.md

@@ -47,6 +47,6 @@ The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issue
    - **Feature/UX completion:** state plainly which acceptance criteria each screenshot covers, and call out any deferred or out-of-scope surface explicitly so QA/PM doesn't have to infer.
 6. **"What would help me confirm" (bug) / "How to QA" (feature) section.** Concrete actionable retest steps with the exact selection criteria (e.g., "pick a record whose Status column shows `—`, not `Processing` or `Pending Review`").
 7. **Explicit invitation to be corrected.** End with a line like *"If any of the steps I listed are different from what you expected / actually did, please tell me explicitly which step I got wrong."* Non-optional — small differences (which record, which device, exact tap order, expected behavior) change everything, and naming the door open short-circuits ticket bounce-loops.
-8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to Awaiting QA for feature; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
+8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to the configured review status when one exists, otherwise leave it in `claimed`; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
 
 **Why this format:** It (a) gives the reporter a frame-by-frame they can compare against, (b) avoids the JIRA image-collapse failure mode while still working everywhere else, (c) names the most plausible discrepancies up front so the loop short-circuits, (d) explicitly opens the door to being corrected so tickets don't bounce on assumed alignment. The same mechanics that resolve a stuck bug ticket also give QA an unambiguous handoff for a freshly-built feature.

package/plugins/lisa-agy/agents/jira-agent.md

@@ -107,7 +107,7 @@ Use the `jira-sync` skill to update the ticket at these milestones:
 Use the `jira-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a JIRA comment
-- Transition the ticket to Code Review
+- Transition the ticket to the configured `jira.workflow.review` status **only if it is set**; if `review` is unconfigured, leave the ticket in `claimed` (do not transition).
 
 ### 8. Suggest Status Transition
 
@@ -116,7 +116,7 @@ Based on the milestone, suggest (but don't auto-transition). Status role names a
 | Milestone | Suggested role | Default status |
 |-----------|----------------|----------------|
 | Plan created | `claimed` | `In Progress` |
-| PR ready | (review-equivalent — project's code-review status) | `In Review` |
+| PR ready | (review-equivalent — project's review status) | the configured `jira.workflow.review` status, or **no transition** when `review` is unconfigured |
 | PR merged | `done` (env-aware) | `Done` (or env-keyed variant per `jira.workflow.done`) |
 
 Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved status name to the human; do not auto-transition.
@@ -124,6 +124,7 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 ## Rules
 
 - Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status, add the configured `human_needed` marker label (`jira.labels.human_needed`, default `Human Needed`), and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
+- Any transition is config-bound: never invent transitions; a transition may target only a status named in `config.jira.workflow`. Don't guess from the live workflow. The evidence-time review hop (Step 7) follows this rule too — it is config-bound, optional, and skipped when `jira.workflow.review` is absent (the ticket stays in `claimed`).
 - Always read the full ticket graph via `jira-read-ticket` before determining intent — don't rely on ticket type alone
 - Never create or materially edit a ticket by calling MCP write tools directly — always delegate to `jira-write-ticket` so relationships, Gherkin criteria, and metadata gates are enforced
 - If sign-in credentials are in the ticket, extract and pass them to the flow. If the ticket touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

package/plugins/lisa-agy/plugin.json

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

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

@@ -1,16 +1,16 @@
 ---
 name: jira-evidence
-description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured code-review status. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
 ---
 
 # JIRA Evidence Posting
 
 ## Workflow resolution
 
-The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`), falling back to `Code Review`. JIRA does not have a separate `review` role in the canonical config schema (the build lifecycle stays in `claimed` until `done`); this skill uses the project's actual post-build review status when one exists. If the configured status is not a valid transition from the ticket's current state, log a warning and skip the transition — the human will handle it.
+The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`). `review` is optional; when unset, the ticket stays in `claimed` until `done` and this skill skips the transition. Never transition to a status that is not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
 
 ```bash
-REVIEW="Code Review"
+REVIEW=""
 if [ -f .lisa.config.json ]; then
   _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
   [ -n "$_cfg" ] && REVIEW="$_cfg"

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

@@ -14,7 +14,8 @@
 #   2. Updates the GitHub PR description with evidence/comment.md
 #   3. Uploads image evidence as JIRA attachments
 #   4. Posts/updates the JIRA comment with evidence/comment.txt
-#   5. Moves the JIRA ticket to "Code Review"
+#   5. Moves the JIRA ticket to the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
 
 set -euo pipefail
 
@@ -152,10 +153,26 @@ else
   echo "$RESP" | grep -v "HTTP_CODE:" | head -3
 fi
 
-# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+# ── Step 5: Move ticket to the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
 echo ""
-echo "==> Moving $TICKET_ID to Code Review..."
-jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+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
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
 
 echo ""
 echo "==> Done!"

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

@@ -67,7 +67,7 @@ Based on the milestone, suggest (but don't automatically perform) a status trans
 | Milestone | Suggested Status |
 |-----------|-----------------|
 | Plan created | "In Progress" |
-| PR ready | "In Review" |
+| PR ready | configured `jira.workflow.review` status, or no transition when unconfigured |
 | PR merged | "Done" |
 
 ### Step 5: Parent Status Rollup (`--rollup`)

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

@@ -47,6 +47,6 @@ The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issue
    - **Feature/UX completion:** state plainly which acceptance criteria each screenshot covers, and call out any deferred or out-of-scope surface explicitly so QA/PM doesn't have to infer.
 6. **"What would help me confirm" (bug) / "How to QA" (feature) section.** Concrete actionable retest steps with the exact selection criteria (e.g., "pick a record whose Status column shows `—`, not `Processing` or `Pending Review`").
 7. **Explicit invitation to be corrected.** End with a line like *"If any of the steps I listed are different from what you expected / actually did, please tell me explicitly which step I got wrong."* Non-optional — small differences (which record, which device, exact tap order, expected behavior) change everything, and naming the door open short-circuits ticket bounce-loops.
-8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to Awaiting QA for feature; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
+8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to the configured review status when one exists, otherwise leave it in `claimed`; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
 
 **Why this format:** It (a) gives the reporter a frame-by-frame they can compare against, (b) avoids the JIRA image-collapse failure mode while still working everywhere else, (c) names the most plausible discrepancies up front so the loop short-circuits, (d) explicitly opens the door to being corrected so tickets don't bounce on assumed alignment. The same mechanics that resolve a stuck bug ticket also give QA an unambiguous handoff for a freshly-built feature.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "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": "2.173.1",
+  "version": "2.173.3",
   "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": "2.173.1",
+  "version": "2.173.3",
   "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": "2.173.1",
+  "version": "2.173.3",
   "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": "2.173.1",
+  "version": "2.173.3",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/agents/jira-agent.agent.md

@@ -107,7 +107,7 @@ Use the `jira-sync` skill to update the ticket at these milestones:
 Use the `jira-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a JIRA comment
-- Transition the ticket to Code Review
+- Transition the ticket to the configured `jira.workflow.review` status **only if it is set**; if `review` is unconfigured, leave the ticket in `claimed` (do not transition).
 
 ### 8. Suggest Status Transition
 
@@ -116,7 +116,7 @@ Based on the milestone, suggest (but don't auto-transition). Status role names a
 | Milestone | Suggested role | Default status |
 |-----------|----------------|----------------|
 | Plan created | `claimed` | `In Progress` |
-| PR ready | (review-equivalent — project's code-review status) | `In Review` |
+| PR ready | (review-equivalent — project's review status) | the configured `jira.workflow.review` status, or **no transition** when `review` is unconfigured |
 | PR merged | `done` (env-aware) | `Done` (or env-keyed variant per `jira.workflow.done`) |
 
 Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved status name to the human; do not auto-transition.
@@ -124,6 +124,7 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 ## Rules
 
 - Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status, add the configured `human_needed` marker label (`jira.labels.human_needed`, default `Human Needed`), and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
+- Any transition is config-bound: never invent transitions; a transition may target only a status named in `config.jira.workflow`. Don't guess from the live workflow. The evidence-time review hop (Step 7) follows this rule too — it is config-bound, optional, and skipped when `jira.workflow.review` is absent (the ticket stays in `claimed`).
 - Always read the full ticket graph via `jira-read-ticket` before determining intent — don't rely on ticket type alone
 - Never create or materially edit a ticket by calling MCP write tools directly — always delegate to `jira-write-ticket` so relationships, Gherkin criteria, and metadata gates are enforced
 - If sign-in credentials are in the ticket, extract and pass them to the flow. If the ticket touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

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

@@ -1,16 +1,16 @@
 ---
 name: jira-evidence
-description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured code-review status. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
 ---
 
 # JIRA Evidence Posting
 
 ## Workflow resolution
 
-The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`), falling back to `Code Review`. JIRA does not have a separate `review` role in the canonical config schema (the build lifecycle stays in `claimed` until `done`); this skill uses the project's actual post-build review status when one exists. If the configured status is not a valid transition from the ticket's current state, log a warning and skip the transition — the human will handle it.
+The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`). `review` is optional; when unset, the ticket stays in `claimed` until `done` and this skill skips the transition. Never transition to a status that is not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
 
 ```bash
-REVIEW="Code Review"
+REVIEW=""
 if [ -f .lisa.config.json ]; then
   _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
   [ -n "$_cfg" ] && REVIEW="$_cfg"

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

@@ -14,7 +14,8 @@
 #   2. Updates the GitHub PR description with evidence/comment.md
 #   3. Uploads image evidence as JIRA attachments
 #   4. Posts/updates the JIRA comment with evidence/comment.txt
-#   5. Moves the JIRA ticket to "Code Review"
+#   5. Moves the JIRA ticket to the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
 
 set -euo pipefail
 
@@ -152,10 +153,26 @@ else
   echo "$RESP" | grep -v "HTTP_CODE:" | head -3
 fi
 
-# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+# ── Step 5: Move ticket to the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
 echo ""
-echo "==> Moving $TICKET_ID to Code Review..."
-jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+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
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
 
 echo ""
 echo "==> Done!"

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

@@ -67,7 +67,7 @@ Based on the milestone, suggest (but don't automatically perform) a status trans
 | Milestone | Suggested Status |
 |-----------|-----------------|
 | Plan created | "In Progress" |
-| PR ready | "In Review" |
+| PR ready | configured `jira.workflow.review` status, or no transition when unconfigured |
 | PR merged | "Done" |
 
 ### Step 5: Parent Status Rollup (`--rollup`)

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

@@ -47,6 +47,6 @@ The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issue
    - **Feature/UX completion:** state plainly which acceptance criteria each screenshot covers, and call out any deferred or out-of-scope surface explicitly so QA/PM doesn't have to infer.
 6. **"What would help me confirm" (bug) / "How to QA" (feature) section.** Concrete actionable retest steps with the exact selection criteria (e.g., "pick a record whose Status column shows `—`, not `Processing` or `Pending Review`").
 7. **Explicit invitation to be corrected.** End with a line like *"If any of the steps I listed are different from what you expected / actually did, please tell me explicitly which step I got wrong."* Non-optional — small differences (which record, which device, exact tap order, expected behavior) change everything, and naming the door open short-circuits ticket bounce-loops.
-8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to Awaiting QA for feature; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
+8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to the configured review status when one exists, otherwise leave it in `claimed`; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
 
 **Why this format:** It (a) gives the reporter a frame-by-frame they can compare against, (b) avoids the JIRA image-collapse failure mode while still working everywhere else, (c) names the most plausible discrepancies up front so the loop short-circuits, (d) explicitly opens the door to being corrected so tickets don't bounce on assumed alignment. The same mechanics that resolve a stuck bug ticket also give QA an unambiguous handoff for a freshly-built feature.

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

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

package/plugins/lisa-cursor/agents/jira-agent.md

@@ -107,7 +107,7 @@ Use the `jira-sync` skill to update the ticket at these milestones:
 Use the `jira-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a JIRA comment
-- Transition the ticket to Code Review
+- Transition the ticket to the configured `jira.workflow.review` status **only if it is set**; if `review` is unconfigured, leave the ticket in `claimed` (do not transition).
 
 ### 8. Suggest Status Transition
 
@@ -116,7 +116,7 @@ Based on the milestone, suggest (but don't auto-transition). Status role names a
 | Milestone | Suggested role | Default status |
 |-----------|----------------|----------------|
 | Plan created | `claimed` | `In Progress` |
-| PR ready | (review-equivalent — project's code-review status) | `In Review` |
+| PR ready | (review-equivalent — project's review status) | the configured `jira.workflow.review` status, or **no transition** when `review` is unconfigured |
 | PR merged | `done` (env-aware) | `Done` (or env-keyed variant per `jira.workflow.done`) |
 
 Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved status name to the human; do not auto-transition.
@@ -124,6 +124,7 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 ## Rules
 
 - Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status, add the configured `human_needed` marker label (`jira.labels.human_needed`, default `Human Needed`), and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
+- Any transition is config-bound: never invent transitions; a transition may target only a status named in `config.jira.workflow`. Don't guess from the live workflow. The evidence-time review hop (Step 7) follows this rule too — it is config-bound, optional, and skipped when `jira.workflow.review` is absent (the ticket stays in `claimed`).
 - Always read the full ticket graph via `jira-read-ticket` before determining intent — don't rely on ticket type alone
 - Never create or materially edit a ticket by calling MCP write tools directly — always delegate to `jira-write-ticket` so relationships, Gherkin criteria, and metadata gates are enforced
 - If sign-in credentials are in the ticket, extract and pass them to the flow. If the ticket touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

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

@@ -1,16 +1,16 @@
 ---
 name: jira-evidence
-description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured code-review status. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
 ---
 
 # JIRA Evidence Posting
 
 ## Workflow resolution
 
-The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`), falling back to `Code Review`. JIRA does not have a separate `review` role in the canonical config schema (the build lifecycle stays in `claimed` until `done`); this skill uses the project's actual post-build review status when one exists. If the configured status is not a valid transition from the ticket's current state, log a warning and skip the transition — the human will handle it.
+The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`). `review` is optional; when unset, the ticket stays in `claimed` until `done` and this skill skips the transition. Never transition to a status that is not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
 
 ```bash
-REVIEW="Code Review"
+REVIEW=""
 if [ -f .lisa.config.json ]; then
   _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
   [ -n "$_cfg" ] && REVIEW="$_cfg"

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

@@ -14,7 +14,8 @@
 #   2. Updates the GitHub PR description with evidence/comment.md
 #   3. Uploads image evidence as JIRA attachments
 #   4. Posts/updates the JIRA comment with evidence/comment.txt
-#   5. Moves the JIRA ticket to "Code Review"
+#   5. Moves the JIRA ticket to the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
 
 set -euo pipefail
 
@@ -152,10 +153,26 @@ else
   echo "$RESP" | grep -v "HTTP_CODE:" | head -3
 fi
 
-# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+# ── Step 5: Move ticket to the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
 echo ""
-echo "==> Moving $TICKET_ID to Code Review..."
-jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+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
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
 
 echo ""
 echo "==> Done!"

package/plugins/lisa-cursor/skills/jira-sync/SKILL.md

@@ -67,7 +67,7 @@ Based on the milestone, suggest (but don't automatically perform) a status trans
 | Milestone | Suggested Status |
 |-----------|-----------------|
 | Plan created | "In Progress" |
-| PR ready | "In Review" |
+| PR ready | configured `jira.workflow.review` status, or no transition when unconfigured |
 | PR merged | "Done" |
 
 ### Step 5: Parent Status Rollup (`--rollup`)

package/plugins/lisa-cursor/skills/tracker-evidence/SKILL.md

@@ -47,6 +47,6 @@ The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issue
    - **Feature/UX completion:** state plainly which acceptance criteria each screenshot covers, and call out any deferred or out-of-scope surface explicitly so QA/PM doesn't have to infer.
 6. **"What would help me confirm" (bug) / "How to QA" (feature) section.** Concrete actionable retest steps with the exact selection criteria (e.g., "pick a record whose Status column shows `—`, not `Processing` or `Pending Review`").
 7. **Explicit invitation to be corrected.** End with a line like *"If any of the steps I listed are different from what you expected / actually did, please tell me explicitly which step I got wrong."* Non-optional — small differences (which record, which device, exact tap order, expected behavior) change everything, and naming the door open short-circuits ticket bounce-loops.
-8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to Awaiting QA for feature; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
+8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to the configured review status when one exists, otherwise leave it in `claimed`; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
 
 **Why this format:** It (a) gives the reporter a frame-by-frame they can compare against, (b) avoids the JIRA image-collapse failure mode while still working everywhere else, (c) names the most plausible discrepancies up front so the loop short-circuits, (d) explicitly opens the door to being corrected so tickets don't bounce on assumed alignment. The same mechanics that resolve a stuck bug ticket also give QA an unambiguous handoff for a freshly-built feature.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/commands/exploratory-qa.md

@@ -1,7 +1,7 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user in a real browser or browser automation session, clicking/typing/selecting through visible controls to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-expo:exploratory-qa skill to experience the app like a brand-new first-time user — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). For automated Playwright coverage gaps, use /lisa-expo:e2e-coverage-gaps. $ARGUMENTS
+Use the /lisa-expo:exploratory-qa skill to experience the app like a brand-new first-time user in a real browser or browser automation session — landing cold on the home page, clicking/typing/selecting through visible controls, and verifying resulting UI state across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated Playwright coverage gaps, use /lisa-expo:e2e-coverage-gaps. $ARGUMENTS