@codyswann/lisa 2.187.1 → 2.187.3

package/package.json

@@ -93,7 +93,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.187.1",
+  "version": "2.187.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.187.1",
+  "version": "2.187.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.187.1",
+  "version": "2.187.3",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -53,7 +53,7 @@ Resolve build labels from `.lisa.config.json` `github.labels.build.*` (defaults:
 
 If `github-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the author:
 
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + `gh`/tracker search, don't fabricate it), a Validation Journey **draft** via `github-add-journey`, and a recommended Target Backend Environment — from the issue's own content (title, body, screenshots, design links, repro steps) plus the codebase. Write it into the body via `github-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the author's prose), then re-run `github-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + `gh`/tracker search, don't fabricate it), a Validation Journey **draft** via `github-add-journey`, and Target Backend Environment — from the issue's own content (title, body, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the body via `github-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the author's prose), then re-run `github-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Relabel: remove the `claimed` label, add the `blocked` label **and** the `human_needed` marker label. Even after the agent drafted what it could, a pre-flight gate failure bounces the issue back to its author because it still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision — so the marker tells a human scanning the board which blocked issues are waiting on them. The marker is additive to `blocked`, not a replacement. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
    ```bash
    _read_cfg() { local lv gv; lv=$(jq -r "$1 // empty" .lisa.config.local.json 2>/dev/null); gv=$(jq -r "$1 // empty" .lisa.config.json 2>/dev/null); echo "${lv:-${gv}}"; }
@@ -150,3 +150,4 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 - Never create or materially edit an issue by calling `gh issue create` / `gh issue edit` directly — always delegate to `github-write-issue` (or, from a vendor-neutral caller, `tracker-write`) so relationships, Gherkin criteria, and metadata gates are enforced.
 - If sign-in credentials are in the issue body, extract and pass them to the flow. If the issue touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
 - If the issue has a `## Validation Journey` section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the body.
+- For bug issues, the reported environment named in the issue body or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

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

@@ -48,7 +48,7 @@ Use the `jira-verify` skill to check the ticket against organizational standards
 **Gating behavior — this is the one place auto-transitioning is allowed:**
 
 If `jira-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the reporter:
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + JQL search, don't fabricate it), a Validation Journey **draft** via `jira-add-journey`, and a recommended Target Backend Environment — from the ticket's own content (title, description, screenshots, design links, repro steps) plus the codebase. Write it into the description via `jira-write-ticket` as clearly-labeled assumptions/recommendations (never overwrite the reporter's prose), then re-run `jira-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + JQL search, don't fabricate it), a Validation Journey **draft** via `jira-add-journey`, and Target Backend Environment — from the ticket's own content (title, description, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the description via `jira-write-ticket` as clearly-labeled assumptions/recommendations (never overwrite the reporter's prose), then re-run `jira-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Transition the ticket status to the configured `blocked` status (typically `Blocked` — read from `.lisa.config.json` `jira.workflow.blocked` if present, otherwise the project's standard blocked status). Use `mcp__atlassian__transitionJiraIssue` or equivalent.
 3. **Add the `human_needed` marker label.** Even after the agent drafted what it could, a pre-flight gate failure bounces the ticket back to its reporter because the ticket still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision. Add the configured label (`jira.labels.human_needed`, default `Human Needed`) to the ticket's `labels` field via `mcp__atlassian__editJiraIssue` — a lightweight metadata update permitted under this same gate exception. This is additive to (not a replacement for) the `blocked` status, so a human scanning the board sees at a glance which blocked tickets are waiting on them. If the label does not exist in the project, record that and proceed — the marker is best-effort. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
 4. Reassign the ticket to the **Reporter** (the human who filed it — not the Creator field, which may be a bot/integration).
@@ -130,3 +130,4 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 - 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.
 - If the ticket has a Validation Journey section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the description (for FE work, that's the deployed backend QA reported against).
+- For bug tickets, the reported environment named in the description or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

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

@@ -50,7 +50,7 @@ Use the `linear-verify` skill to check the item against organizational standards
 Resolve build labels from `.lisa.config.json` `linear.labels.build.*` (defaults: `status:ready` / `status:in-progress` / `status:code-review`); resolve the `blocked` label from the same section (`linear.labels.build.blocked`, default `status:blocked`) and the `human_needed` marker label from the same section (`linear.labels.build.human_needed`, default `human-needed`).
 
 If `linear-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the creator:
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + Linear search, don't fabricate it), a Validation Journey **draft** via `linear-add-journey`, and a recommended Target Backend Environment — from the item's own content (title, description, screenshots, design links, repro steps) plus the codebase. Write it into the description via `linear-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the creator's prose), then re-run `linear-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + Linear search, don't fabricate it), a Validation Journey **draft** via `linear-add-journey`, and Target Backend Environment — from the item's own content (title, description, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the description via `linear-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the creator's prose), then re-run `linear-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Update labels via `lisa:linear-access operation: save-issue`: remove the current build label, add the configured `blocked` label **and** the configured `human_needed` marker label. (Create either label via `create_issue_label` if needed.) Even after the agent drafted what it could, a pre-flight gate failure bounces the item back to its creator because it still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision — so the marker tells a human scanning the board which blocked items are waiting on them. The marker is additive to `blocked`, not a replacement. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
 3. Reassign the item to the **Issue creator** (the human who filed it — Linear's `creator` field).
 4. Post the **confirmation comment** from the `pre-flight-autofill` rule via `lisa:linear-access operation: save-comment`, **not** a bare remediation checklist: disclose it is a Claude draft, give one line per drafted section naming the key assumption made, list any remaining human-only item as a specific question with a recommended default, and close with *"review the drafted sections, correct anything wrong, then flip back to Ready and it builds — or reply with corrections."* Prefix with `[{repo}]`.
@@ -133,3 +133,4 @@ The label transitions ARE the canonical signal. The native `state` field stays a
 - Never create or materially edit an item by calling MCP write tools directly — always delegate to `linear-write-issue` so relationships, Gherkin criteria, and metadata gates are enforced. Two explicit exceptions are permitted: (1) the Step 2 pre-flight failure path (when `linear-verify` returns `FAIL`) may call `lisa:linear-access operation: save-issue` and `lisa:linear-access operation: save-comment` directly to set `status:blocked`, add the configured `human_needed` marker label, and reassign to the creator — this narrow exception is already granted by the rule above; (2) the Step 3 triage path may call `lisa:linear-access operation: save-comment` to post triage findings and `lisa:linear-access operation: save-issue` to add the `claude-triaged-{repo}` label — these are lightweight metadata updates that do not create or materially edit ticket content and therefore do not need to route through `linear-write-issue`.
 - If sign-in credentials are in the item, extract and pass them to the flow. If the item touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
 - If the item has a Validation Journey section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the description.
+- For bug items, the reported environment named in the description or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

package/plugins/lisa/rules/eager/config-resolution.md

@@ -25,4 +25,15 @@ Project tracker (`jira` / `github` / `linear`) is read from `.lisa.config.json`
 
 `repo:<name>` is the canonical label for which repo a work item belongs to. Resolve current-repo identity in this priority order: `.lisa.config.local.json` `repo` → `.lisa.config.json` `repo` → `.lisa.config.json` `github.repo` → `basename -s .git "$(git remote get-url origin)"`. If none resolve, stop with a clear error.
 
+## Env → base branch
+
+For implementation work, map the work item's `## Target Backend Environment` to
+the PR base branch through `.lisa.config.json` `deploy.branches`. For bugs, a
+reported environment extracted from the description/reproduction steps wins over
+an autofill default. If a reported environment is absent from `deploy.branches`,
+stop and report the missing mapping instead of silently falling back to the
+default or integration branch. A non-integration environment bug is fixed,
+merged, and verified on that environment branch first, then forward
+cherry-picked down to the integration branch via a linked follow-up.
+
 Full reference: [reference/config-resolution.md](../reference/config-resolution.md).

package/plugins/lisa/rules/eager/pre-flight-autofill.md

@@ -21,8 +21,13 @@ information was already on the ticket; only the structure was missing).
   Gherkin Acceptance Criteria (one scenario per fix), expected-vs-actual +
   environment, Repository, Relationship Search (actually run the git+tracker
   search — don't fabricate "none found"), Validation Journey **draft** (via the
-  vendor `*-add-journey` skill), Target Backend Environment (recommend a default
-  from `deploy.branches`/config).
+  vendor `*-add-journey` skill), Target Backend Environment. For bugs, parse the
+  reported environment from the item body/reproduction steps before recommending
+  any default: bare environment names (`dev`, `staging`, `prod`, `production`)
+  and environment-bearing URLs (for example `staging.<domain>`, `gql.staging.*`,
+  `dev.<domain>`) are authoritative. Only recommend the configured default when
+  no environment is discoverable anywhere in the work item, and record that as
+  an assumption.
 - **Tier B — irreducibly human:** real credentials/access that exist nowhere on
   the item or in repo test-user docs; a genuine product/scoping decision with no
   defensible default. Still propose a recommended default where one exists; ask

package/plugins/lisa/rules/reference/config-resolution.md

@@ -212,6 +212,33 @@ Declares **where this repo's LLM Wiki lives** so the query/ingest skills can res
 
 `scripts/ensure-wiki.mjs` is the single resolver (`node scripts/ensure-wiki.mjs --json` → `{mode, wikiRoot, …}`). **LOCAL** mode (no `url`) is a no-op that resolves the wiki root in precedence order `wiki.source.path` → `wikiRoot` in `wiki/lisa-wiki.config.json` → `wiki`; **REMOTE** mode (`url` set) clones-if-missing, fast-forwards when stale, and is offline-tolerant (proceeds with the existing mirror and warns rather than blocking). Callers (`lisa-wiki-query`, `lisa-wiki-ingest`) invoke it as step 0 and never hardcode `wiki/`; the freshness guarantee is the tool's, not the caller's.
 
+### Env → base branch
+
+Implementation flows resolve their PR base from the work item's
+`## Target Backend Environment` in the forward direction of `deploy.branches`.
+For example, `{ "staging": "staging", "production": "main" }` means a staging
+work item starts from `origin/staging` and opens its PR against `staging`. This
+is the reverse/inverse of the env-keyed `done` inference that derives an
+environment from a merged PR's base branch.
+
+For bug work, the reported environment is authoritative. `pre-flight-autofill`
+must parse environment mentions from the description/body and reproduction
+steps, including bare names (`dev`, `staging`, `prod`, `production`) and
+environment-bearing URLs (`staging.<domain>`, `gql.staging.*`,
+`dev.<domain>`). A parsed reported environment wins over any generic autofill
+default. If no environment is named anywhere, the flow may fall back to the
+remote default branch and record that assumption on the work item.
+
+If the reported environment is not present in `deploy.branches`, stop and report
+the missing mapping. Do not silently default to the integration branch.
+
+For non-integration environment bugs, definition of done is two-step:
+
+1. Fix, merge, deploy, and verify on the reported environment branch first.
+2. Forward cherry-pick the verified fix down to the integration branch, usually
+   via a linked follow-up PR or work item, so the next promotion does not
+   regress the fix.
+
 ### Vendor sections
 
 Each vendor section is **conditionally required**: required only when that vendor is referenced as `tracker`, as `source`, or by an explicit invocation. Skills validate their own required keys at entry and stop with a clear error if missing — never invent values.
@@ -369,7 +396,7 @@ documented defaults, so existing projects need no config change.
 
 | Key | Required | Default | Notes |
 |-----|----------|---------|-------|
-| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
+| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may sit after its last state-changing transition into the in-progress role, or after the last human / PR-side forward-progress activity, before repair-intake treats it as stalled and resumes it. Automation self-comments and Lisa audit notes do not reset this clock. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
 | `intake.repair.maxCandidates` | no | `100` | Upper bound on how many stuck items repair-intake enumerates while searching for the first actionable one. Bounds scan cost. Overridable per-run via `max_candidates=<n>`. |
 
 ### Monitor audit config (`monitor`)

package/plugins/lisa/rules/reference/pre-flight-autofill.md

@@ -49,9 +49,14 @@ spec.
 - **Validation Journey (draft)** — run the vendor `*-add-journey` skill to draft
   the click-path, markers, and viewports from the reproduction steps. This is a
   draft for human approval, not the final ratified contract.
-- **Target Backend Environment** — recommend a default from `deploy.branches` /
-  config (the backend the FE points at for verification) and state it as a
-  recommendation.
+- **Target Backend Environment** — for bugs, first parse the reported
+  environment from the title, description/body, screenshots captions, links, and
+  reproduction steps. Bare words such as `dev`, `staging`, `prod`, and
+  `production` count, as do environment-bearing URLs such as
+  `staging.<domain>`, `gql.staging.*`, and `dev.<domain>`. That reported
+  environment is authoritative for the draft. Only recommend a configured
+  default from `deploy.branches` / config when no environment is discoverable
+  anywhere in the work item, and record the default as an explicit assumption.
 
 **Tier B — irreducibly human (cannot invent — but still propose a default):**
 

package/plugins/lisa/scripts/automation-status-expected-fleet.mjs

@@ -263,9 +263,10 @@ function resolveRepairQueueArgument(config, source, tracker) {
     return "github intake_mode=both";
   }
 
-  throw new Error(
-    `Unable to resolve a single repair-intake queue for tracker=${String(tracker)} and source=${String(source)} without guessing.`
-  );
+  const buildQueue = resolveBuildQueueArgument(config, tracker);
+  return buildQueue.includes("intake_mode=")
+    ? buildQueue
+    : `${buildQueue} intake_mode=build`;
 }
 
 /**

package/plugins/lisa/skills/implement/SKILL.md

@@ -70,15 +70,15 @@ Using the general-purpose agent in Team Lead session, Determine the name of this
 
 Using the general-purpose agent in Team Lead session, **determine the base branch from the ticket's target environment, then sync the working branch onto the latest of it before any work** — so implementation always builds on current target-environment code:
 
-1. **Resolve the target environment** from the resolved work item — its `## Target Backend Environment` section (the field the `*-write-*` / `*-add-journey` skills record).
-2. **Map the environment to a base branch** via `.lisa.config.json` `deploy.branches` (e.g. `staging → staging`, `production → main`) — the forward direction of the same map the env-keyed `done` resolution uses in reverse (see the `config-resolution` rule). If the work item names **no** environment, the base branch is the **remote default branch** (`gh repo view --json defaultBranchRef -q .defaultBranchRef.name`, or `git remote set-head origin -a` then read `origin/HEAD`). If the named environment is absent from `deploy.branches`, or its branch does not exist on the remote, **stop and report** — never guess a base.
+1. **Resolve the target environment** from the resolved work item — its `## Target Backend Environment` section (the field the `*-write-*` / `*-add-journey` skills record). For bug work, the environment named in the report is authoritative: if the title/body/reproduction steps mention bare env names (`dev`, `staging`, `prod`, `production`) or env-bearing URLs (`staging.<domain>`, `gql.staging.*`, `dev.<domain>`), that reported environment wins over a generic autofill default.
+2. **Map the environment to a base branch** via `.lisa.config.json` `deploy.branches` (e.g. `staging → staging`, `production → main`) — the forward direction of the same map the env-keyed `done` resolution uses in reverse (see the `config-resolution` rule). If the work item names **no** environment, the base branch is the **remote default branch** (`gh repo view --json defaultBranchRef -q .defaultBranchRef.name`, or `git remote set-head origin -a` then read `origin/HEAD`). If the reported environment is absent from `deploy.branches`, or its branch does not exist on the remote, **stop and report** — never guess a base and never silently fall back to the default/integration branch.
 3. **Establish the feature branch off the latest base, conflict-free:**
    - `git fetch origin`.
    - Already on a feature branch with an **open PR** → reuse it. If the PR's base ≠ the resolved base branch, surface the mismatch and re-target only with confirmation — the ticket's environment is the source of truth.
    - Already on a feature branch with **no open PR** → reuse it; its PR base will be the resolved base branch (do not ask the human — the environment determines it).
    - On an **environment / default branch** → check out a feature branch named for this plan (with the work-item ref prefix, per the linkage rules below) **from `origin/<base>`**.
    - **Rebase the feature branch onto `origin/<base>` and resolve any merge conflicts BEFORE starting work.** If the conflicts cannot be resolved cleanly and safely, create a fix task for the agent team (with the conflicting file list and current merge state) and resolve it before implementation begins — never start work on stale or conflicted code.
-4. **The PR targets the resolved base branch** — carry it as `target_branch=<base>` into `lisa:git-submit-pr` (Verify flow). `git-submit-pr` already chooses a closing keyword when the base is the production/default branch and a non-closing reference for a non-terminal environment branch.
+4. **The PR targets the resolved base branch** — carry it as `target_branch=<base>` into `lisa:git-submit-pr` (Verify flow). `git-submit-pr` already chooses a closing keyword when the base is the production/default branch and a non-closing reference for a non-terminal environment branch. For a bug fixed on a non-integration environment branch, the current flow is not done until the fix is merged and verified there, then forward cherry-picked down to the integration branch via a linked follow-up.
 
 When the request came from a tracker work item, preserve its native identifier for development linkage:
 

package/plugins/lisa/skills/repair-intake/SKILL.md

@@ -80,7 +80,7 @@ lifecycle state with provider-native closure and rollup state.
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
+| `stale_after` | How long since the last state-changing transition into the in-progress role, or since the last human / PR-side forward-progress activity, before an in-progress item counts as stalled. Automation self-comments do not reset this clock. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -228,9 +228,19 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa:at
 
 ## Staleness model
 
-An in-progress item (build `claimed`, PRD `in_review`) is **stalled** only if it shows no
-observable activity newer than the `stale_after` threshold. `blocked` items are NOT gated on
-staleness — their repairability is judged on current blocker/answer state, not elapsed time.
+An in-progress item (build `claimed`, PRD `in_review`) is **stalled** when the last
+state-changing transition into the in-progress role, or the last human / PR-side forward-progress
+activity after that transition, is older than the `stale_after` threshold. `blocked` items are NOT
+gated on staleness — their repairability is judged on current blocker/answer state, not elapsed
+time.
+
+Automation self-comments are not forward progress and must not reset the staleness clock. Status
+comments like `[claude-build-intake] PR remains open...`, `[codex-build-intake] Follow-up pushed...`,
+or `[lisa-repair-intake] ...` may be useful audit notes, but they cannot make a claimed item fresh
+forever. If a provider exposes a changelog/history surface, prefer the timestamp of the last
+transition into the claimed/In-Progress role over the item's generic `updated` timestamp. When the
+history surface is unavailable, ignore comments whose author/marker clearly belongs to Lisa or its
+automation agents, and use the newest human comment/edit or PR-side progress event instead.
 
 A build `claimed` leaf whose linked PR has **already merged** (`state == MERGED`) is likewise NOT
 gated on staleness. A merged PR is a settled terminal state, not in-flight work: the only thing
@@ -254,17 +264,24 @@ decision tree step 0, and the dedicated high-confidence ordering bucket).
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
 
-### Activity signal (most-recent-wins, portable across vendors)
+### Activity signal (state-change first, portable across vendors)
 
-Compute the item's newest activity timestamp from the highest-priority signal the vendor
+Compute the item's newest eligible activity timestamp from the highest-priority signal the vendor
 exposes, and compare it to `now - stale_after`:
 
-1. Provider-native item `updatedAt` / `last_edited_time` / `updated`.
-2. Latest lifecycle/progress **comment** on the item (and, for Linear PRDs, the sentinel
-   feedback issue).
-3. For build items, latest **PR activity** on the linked PR: newest commit, review, check-run,
+1. Provider-native status/label **transition** time into the in-progress role, when the provider
+   exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
+   Linear state/label history, Notion/Confluence page move/status history).
+2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
+   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+   `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
+   `[lisa-repair-intake]`.
+3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
+   review, check-run,
    or PR comment.
-4. Status/label **transition** time, when the provider exposes it cleanly.
+4. Provider-native item `updatedAt` / `last_edited_time` / `updated` only when the provider cannot
+   expose transition/comment authorship and the timestamp is not known to be driven by automation
+   self-comments.
 
 If ANY of these is newer than the threshold, the item is **active** → record it as `active` and
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For

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

@@ -53,7 +53,7 @@ Resolve build labels from `.lisa.config.json` `github.labels.build.*` (defaults:
 
 If `github-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the author:
 
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + `gh`/tracker search, don't fabricate it), a Validation Journey **draft** via `github-add-journey`, and a recommended Target Backend Environment — from the issue's own content (title, body, screenshots, design links, repro steps) plus the codebase. Write it into the body via `github-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the author's prose), then re-run `github-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + `gh`/tracker search, don't fabricate it), a Validation Journey **draft** via `github-add-journey`, and Target Backend Environment — from the issue's own content (title, body, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the body via `github-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the author's prose), then re-run `github-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Relabel: remove the `claimed` label, add the `blocked` label **and** the `human_needed` marker label. Even after the agent drafted what it could, a pre-flight gate failure bounces the issue back to its author because it still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision — so the marker tells a human scanning the board which blocked issues are waiting on them. The marker is additive to `blocked`, not a replacement. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
    ```bash
    _read_cfg() { local lv gv; lv=$(jq -r "$1 // empty" .lisa.config.local.json 2>/dev/null); gv=$(jq -r "$1 // empty" .lisa.config.json 2>/dev/null); echo "${lv:-${gv}}"; }
@@ -150,3 +150,4 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 - Never create or materially edit an issue by calling `gh issue create` / `gh issue edit` directly — always delegate to `github-write-issue` (or, from a vendor-neutral caller, `tracker-write`) so relationships, Gherkin criteria, and metadata gates are enforced.
 - If sign-in credentials are in the issue body, extract and pass them to the flow. If the issue touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
 - If the issue has a `## Validation Journey` section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the body.
+- For bug issues, the reported environment named in the issue body or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

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

@@ -48,7 +48,7 @@ Use the `jira-verify` skill to check the ticket against organizational standards
 **Gating behavior — this is the one place auto-transitioning is allowed:**
 
 If `jira-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the reporter:
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + JQL search, don't fabricate it), a Validation Journey **draft** via `jira-add-journey`, and a recommended Target Backend Environment — from the ticket's own content (title, description, screenshots, design links, repro steps) plus the codebase. Write it into the description via `jira-write-ticket` as clearly-labeled assumptions/recommendations (never overwrite the reporter's prose), then re-run `jira-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + JQL search, don't fabricate it), a Validation Journey **draft** via `jira-add-journey`, and Target Backend Environment — from the ticket's own content (title, description, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the description via `jira-write-ticket` as clearly-labeled assumptions/recommendations (never overwrite the reporter's prose), then re-run `jira-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Transition the ticket status to the configured `blocked` status (typically `Blocked` — read from `.lisa.config.json` `jira.workflow.blocked` if present, otherwise the project's standard blocked status). Use `mcp__atlassian__transitionJiraIssue` or equivalent.
 3. **Add the `human_needed` marker label.** Even after the agent drafted what it could, a pre-flight gate failure bounces the ticket back to its reporter because the ticket still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision. Add the configured label (`jira.labels.human_needed`, default `Human Needed`) to the ticket's `labels` field via `mcp__atlassian__editJiraIssue` — a lightweight metadata update permitted under this same gate exception. This is additive to (not a replacement for) the `blocked` status, so a human scanning the board sees at a glance which blocked tickets are waiting on them. If the label does not exist in the project, record that and proceed — the marker is best-effort. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
 4. Reassign the ticket to the **Reporter** (the human who filed it — not the Creator field, which may be a bot/integration).
@@ -130,3 +130,4 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 - 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.
 - If the ticket has a Validation Journey section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the description (for FE work, that's the deployed backend QA reported against).
+- For bug tickets, the reported environment named in the description or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

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

@@ -50,7 +50,7 @@ Use the `linear-verify` skill to check the item against organizational standards
 Resolve build labels from `.lisa.config.json` `linear.labels.build.*` (defaults: `status:ready` / `status:in-progress` / `status:code-review`); resolve the `blocked` label from the same section (`linear.labels.build.blocked`, default `status:blocked`) and the `human_needed` marker label from the same section (`linear.labels.build.human_needed`, default `human-needed`).
 
 If `linear-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the creator:
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + Linear search, don't fabricate it), a Validation Journey **draft** via `linear-add-journey`, and a recommended Target Backend Environment — from the item's own content (title, description, screenshots, design links, repro steps) plus the codebase. Write it into the description via `linear-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the creator's prose), then re-run `linear-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + Linear search, don't fabricate it), a Validation Journey **draft** via `linear-add-journey`, and Target Backend Environment — from the item's own content (title, description, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the description via `linear-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the creator's prose), then re-run `linear-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Update labels via `lisa:linear-access operation: save-issue`: remove the current build label, add the configured `blocked` label **and** the configured `human_needed` marker label. (Create either label via `create_issue_label` if needed.) Even after the agent drafted what it could, a pre-flight gate failure bounces the item back to its creator because it still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision — so the marker tells a human scanning the board which blocked items are waiting on them. The marker is additive to `blocked`, not a replacement. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
 3. Reassign the item to the **Issue creator** (the human who filed it — Linear's `creator` field).
 4. Post the **confirmation comment** from the `pre-flight-autofill` rule via `lisa:linear-access operation: save-comment`, **not** a bare remediation checklist: disclose it is a Claude draft, give one line per drafted section naming the key assumption made, list any remaining human-only item as a specific question with a recommended default, and close with *"review the drafted sections, correct anything wrong, then flip back to Ready and it builds — or reply with corrections."* Prefix with `[{repo}]`.
@@ -133,3 +133,4 @@ The label transitions ARE the canonical signal. The native `state` field stays a
 - Never create or materially edit an item by calling MCP write tools directly — always delegate to `linear-write-issue` so relationships, Gherkin criteria, and metadata gates are enforced. Two explicit exceptions are permitted: (1) the Step 2 pre-flight failure path (when `linear-verify` returns `FAIL`) may call `lisa:linear-access operation: save-issue` and `lisa:linear-access operation: save-comment` directly to set `status:blocked`, add the configured `human_needed` marker label, and reassign to the creator — this narrow exception is already granted by the rule above; (2) the Step 3 triage path may call `lisa:linear-access operation: save-comment` to post triage findings and `lisa:linear-access operation: save-issue` to add the `claude-triaged-{repo}` label — these are lightweight metadata updates that do not create or materially edit ticket content and therefore do not need to route through `linear-write-issue`.
 - If sign-in credentials are in the item, extract and pass them to the flow. If the item touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
 - If the item has a Validation Journey section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the description.
+- For bug items, the reported environment named in the description or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/scripts/automation-status-expected-fleet.mjs

@@ -263,9 +263,10 @@ function resolveRepairQueueArgument(config, source, tracker) {
     return "github intake_mode=both";
   }
 
-  throw new Error(
-    `Unable to resolve a single repair-intake queue for tracker=${String(tracker)} and source=${String(source)} without guessing.`
-  );
+  const buildQueue = resolveBuildQueueArgument(config, tracker);
+  return buildQueue.includes("intake_mode=")
+    ? buildQueue
+    : `${buildQueue} intake_mode=build`;
 }
 
 /**

package/plugins/lisa-agy/skills/implement/SKILL.md

@@ -70,15 +70,15 @@ Using the general-purpose agent in Team Lead session, Determine the name of this
 
 Using the general-purpose agent in Team Lead session, **determine the base branch from the ticket's target environment, then sync the working branch onto the latest of it before any work** — so implementation always builds on current target-environment code:
 
-1. **Resolve the target environment** from the resolved work item — its `## Target Backend Environment` section (the field the `*-write-*` / `*-add-journey` skills record).
-2. **Map the environment to a base branch** via `.lisa.config.json` `deploy.branches` (e.g. `staging → staging`, `production → main`) — the forward direction of the same map the env-keyed `done` resolution uses in reverse (see the `config-resolution` rule). If the work item names **no** environment, the base branch is the **remote default branch** (`gh repo view --json defaultBranchRef -q .defaultBranchRef.name`, or `git remote set-head origin -a` then read `origin/HEAD`). If the named environment is absent from `deploy.branches`, or its branch does not exist on the remote, **stop and report** — never guess a base.
+1. **Resolve the target environment** from the resolved work item — its `## Target Backend Environment` section (the field the `*-write-*` / `*-add-journey` skills record). For bug work, the environment named in the report is authoritative: if the title/body/reproduction steps mention bare env names (`dev`, `staging`, `prod`, `production`) or env-bearing URLs (`staging.<domain>`, `gql.staging.*`, `dev.<domain>`), that reported environment wins over a generic autofill default.
+2. **Map the environment to a base branch** via `.lisa.config.json` `deploy.branches` (e.g. `staging → staging`, `production → main`) — the forward direction of the same map the env-keyed `done` resolution uses in reverse (see the `config-resolution` rule). If the work item names **no** environment, the base branch is the **remote default branch** (`gh repo view --json defaultBranchRef -q .defaultBranchRef.name`, or `git remote set-head origin -a` then read `origin/HEAD`). If the reported environment is absent from `deploy.branches`, or its branch does not exist on the remote, **stop and report** — never guess a base and never silently fall back to the default/integration branch.
 3. **Establish the feature branch off the latest base, conflict-free:**
    - `git fetch origin`.
    - Already on a feature branch with an **open PR** → reuse it. If the PR's base ≠ the resolved base branch, surface the mismatch and re-target only with confirmation — the ticket's environment is the source of truth.
    - Already on a feature branch with **no open PR** → reuse it; its PR base will be the resolved base branch (do not ask the human — the environment determines it).
    - On an **environment / default branch** → check out a feature branch named for this plan (with the work-item ref prefix, per the linkage rules below) **from `origin/<base>`**.
    - **Rebase the feature branch onto `origin/<base>` and resolve any merge conflicts BEFORE starting work.** If the conflicts cannot be resolved cleanly and safely, create a fix task for the agent team (with the conflicting file list and current merge state) and resolve it before implementation begins — never start work on stale or conflicted code.
-4. **The PR targets the resolved base branch** — carry it as `target_branch=<base>` into `lisa:git-submit-pr` (Verify flow). `git-submit-pr` already chooses a closing keyword when the base is the production/default branch and a non-closing reference for a non-terminal environment branch.
+4. **The PR targets the resolved base branch** — carry it as `target_branch=<base>` into `lisa:git-submit-pr` (Verify flow). `git-submit-pr` already chooses a closing keyword when the base is the production/default branch and a non-closing reference for a non-terminal environment branch. For a bug fixed on a non-integration environment branch, the current flow is not done until the fix is merged and verified there, then forward cherry-picked down to the integration branch via a linked follow-up.
 
 When the request came from a tracker work item, preserve its native identifier for development linkage:
 

package/plugins/lisa-agy/skills/repair-intake/SKILL.md

@@ -80,7 +80,7 @@ lifecycle state with provider-native closure and rollup state.
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
+| `stale_after` | How long since the last state-changing transition into the in-progress role, or since the last human / PR-side forward-progress activity, before an in-progress item counts as stalled. Automation self-comments do not reset this clock. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -228,9 +228,19 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa:at
 
 ## Staleness model
 
-An in-progress item (build `claimed`, PRD `in_review`) is **stalled** only if it shows no
-observable activity newer than the `stale_after` threshold. `blocked` items are NOT gated on
-staleness — their repairability is judged on current blocker/answer state, not elapsed time.
+An in-progress item (build `claimed`, PRD `in_review`) is **stalled** when the last
+state-changing transition into the in-progress role, or the last human / PR-side forward-progress
+activity after that transition, is older than the `stale_after` threshold. `blocked` items are NOT
+gated on staleness — their repairability is judged on current blocker/answer state, not elapsed
+time.
+
+Automation self-comments are not forward progress and must not reset the staleness clock. Status
+comments like `[claude-build-intake] PR remains open...`, `[codex-build-intake] Follow-up pushed...`,
+or `[lisa-repair-intake] ...` may be useful audit notes, but they cannot make a claimed item fresh
+forever. If a provider exposes a changelog/history surface, prefer the timestamp of the last
+transition into the claimed/In-Progress role over the item's generic `updated` timestamp. When the
+history surface is unavailable, ignore comments whose author/marker clearly belongs to Lisa or its
+automation agents, and use the newest human comment/edit or PR-side progress event instead.
 
 A build `claimed` leaf whose linked PR has **already merged** (`state == MERGED`) is likewise NOT
 gated on staleness. A merged PR is a settled terminal state, not in-flight work: the only thing
@@ -254,17 +264,24 @@ decision tree step 0, and the dedicated high-confidence ordering bucket).
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
 
-### Activity signal (most-recent-wins, portable across vendors)
+### Activity signal (state-change first, portable across vendors)
 
-Compute the item's newest activity timestamp from the highest-priority signal the vendor
+Compute the item's newest eligible activity timestamp from the highest-priority signal the vendor
 exposes, and compare it to `now - stale_after`:
 
-1. Provider-native item `updatedAt` / `last_edited_time` / `updated`.
-2. Latest lifecycle/progress **comment** on the item (and, for Linear PRDs, the sentinel
-   feedback issue).
-3. For build items, latest **PR activity** on the linked PR: newest commit, review, check-run,
+1. Provider-native status/label **transition** time into the in-progress role, when the provider
+   exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
+   Linear state/label history, Notion/Confluence page move/status history).
+2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
+   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+   `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
+   `[lisa-repair-intake]`.
+3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
+   review, check-run,
    or PR comment.
-4. Status/label **transition** time, when the provider exposes it cleanly.
+4. Provider-native item `updatedAt` / `last_edited_time` / `updated` only when the provider cannot
+   expose transition/comment authorship and the timestamp is not known to be driven by automation
+   self-comments.
 
 If ANY of these is newer than the threshold, the item is **active** → record it as `active` and
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.187.1",
+  "version": "2.187.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.187.1",
+  "version": "2.187.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.187.1",
+  "version": "2.187.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.187.1",
+  "version": "2.187.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.187.1",
+  "version": "2.187.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.187.1",
+  "version": "2.187.3",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

@@ -53,7 +53,7 @@ Resolve build labels from `.lisa.config.json` `github.labels.build.*` (defaults:
 
 If `github-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the author:
 
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + `gh`/tracker search, don't fabricate it), a Validation Journey **draft** via `github-add-journey`, and a recommended Target Backend Environment — from the issue's own content (title, body, screenshots, design links, repro steps) plus the codebase. Write it into the body via `github-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the author's prose), then re-run `github-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + `gh`/tracker search, don't fabricate it), a Validation Journey **draft** via `github-add-journey`, and Target Backend Environment — from the issue's own content (title, body, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the body via `github-write-issue` as clearly-labeled assumptions/recommendations (never overwrite the author's prose), then re-run `github-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Relabel: remove the `claimed` label, add the `blocked` label **and** the `human_needed` marker label. Even after the agent drafted what it could, a pre-flight gate failure bounces the issue back to its author because it still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision — so the marker tells a human scanning the board which blocked issues are waiting on them. The marker is additive to `blocked`, not a replacement. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
    ```bash
    _read_cfg() { local lv gv; lv=$(jq -r "$1 // empty" .lisa.config.local.json 2>/dev/null); gv=$(jq -r "$1 // empty" .lisa.config.json 2>/dev/null); echo "${lv:-${gv}}"; }
@@ -150,3 +150,4 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 - Never create or materially edit an issue by calling `gh issue create` / `gh issue edit` directly — always delegate to `github-write-issue` (or, from a vendor-neutral caller, `tracker-write`) so relationships, Gherkin criteria, and metadata gates are enforced.
 - If sign-in credentials are in the issue body, extract and pass them to the flow. If the issue touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
 - If the issue has a `## Validation Journey` section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the body.
+- For bug issues, the reported environment named in the issue body or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.

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

@@ -48,7 +48,7 @@ Use the `jira-verify` skill to check the ticket against organizational standards
 **Gating behavior — this is the one place auto-transitioning is allowed:**
 
 If `jira-verify` returns `FAIL` on any of the above, do NOT continue to build. **Draft the missing spec content first, then block for confirmation** — never bounce a raw "go write all this" checklist back to the reporter:
-1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + JQL search, don't fabricate it), a Validation Journey **draft** via `jira-add-journey`, and a recommended Target Backend Environment — from the ticket's own content (title, description, screenshots, design links, repro steps) plus the codebase. Write it into the description via `jira-write-ticket` as clearly-labeled assumptions/recommendations (never overwrite the reporter's prose), then re-run `jira-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
+1. **Best-effort autofill (before blocking).** Run the **draft-then-block procedure** in the `pre-flight-autofill` rule: draft every *authorable* missing section — Technical Approach, Out of Scope, Gherkin acceptance criteria, expected-vs-actual, Repository, Relationship Search (run the git + JQL search, don't fabricate it), a Validation Journey **draft** via `jira-add-journey`, and Target Backend Environment — from the ticket's own content (title, description, screenshots, design links, repro steps) plus the codebase. For bugs, parse the reported environment from bare env names and env-bearing URLs before recommending any default; the reported environment wins. Write it into the description via `jira-write-ticket` as clearly-labeled assumptions/recommendations (never overwrite the reporter's prose), then re-run `jira-verify`. Whatever the agent could author is now structured spec; only genuinely human-only inputs remain.
 2. Transition the ticket status to the configured `blocked` status (typically `Blocked` — read from `.lisa.config.json` `jira.workflow.blocked` if present, otherwise the project's standard blocked status). Use `mcp__atlassian__transitionJiraIssue` or equivalent.
 3. **Add the `human_needed` marker label.** Even after the agent drafted what it could, a pre-flight gate failure bounces the ticket back to its reporter because the ticket still needs a human to **confirm the drafted assumptions** or supply something no agent can invent — real missing credentials, access, or an irreducible product/scoping decision. Add the configured label (`jira.labels.human_needed`, default `Human Needed`) to the ticket's `labels` field via `mcp__atlassian__editJiraIssue` — a lightweight metadata update permitted under this same gate exception. This is additive to (not a replacement for) the `blocked` status, so a human scanning the board sees at a glance which blocked tickets are waiting on them. If the label does not exist in the project, record that and proceed — the marker is best-effort. (See the `config-resolution` rule's "Build markers" for when the marker applies and when it must NOT.)
 4. Reassign the ticket to the **Reporter** (the human who filed it — not the Creator field, which may be a bot/integration).
@@ -130,3 +130,4 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 - 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.
 - If the ticket has a Validation Journey section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the description (for FE work, that's the deployed backend QA reported against).
+- For bug tickets, the reported environment named in the description or reproduction steps drives the implementation base branch via `deploy.branches`; if the mapping is missing, stop instead of defaulting. A non-integration environment fix must be merged and verified on that environment branch, then forward cherry-picked down to the integration branch through a linked follow-up.