@codyswann/lisa 2.187.2 → 2.187.3

package/plugins/src/base/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/src/base/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/src/base/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.

package/plugins/src/base/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/src/base/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: