@codyswann/lisa 2.256.0 → 2.257.0

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 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.
+1. **Best-effort autofill (before blocking).** Run `pre-flight-autofill` for every work item. Preserve a human bare configured key or `Confirmed: <env>`; automation writes `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` otherwise. Human confirmation replaces the annotation with the bare key or `Confirmed: <env>`. For a legacy bare value, use managed draft markers and current ticket content only; provider edit history is not required. A marker proves automation and requires re-annotation; otherwise unknown provenance plus conflicting evidence stops for confirmation. Resolve one exact `deploy.branches` key from the human-authored title, body, and reproduction steps or URL hostname; exclude the complete `Target Backend Environment` section and other machine-authored metadata/draft blocks so annotations cannot become evidence. A reported bug environment is an example, not a restriction. Evidence supersedes only `Assumption:`. Normalize `prod` ↔ `production` only when exactly one is configured; no other aliases exist. Conflicts stop; never infer from arbitrary branch text, URL paths/query strings, or substrings. Write through `github-write-issue`, never overwrite human prose, then re-run `github-verify`.
 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}}"; }
@@ -152,4 +152,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 no environment can be found anywhere in the ticket, fall back to the configured default branch and record that assumption. If the reported environment is present but missing from `deploy.branches`, or its mapped branch is absent on the remote, stop and report the missing environment/branch mapping 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.
+- The environment handoff for every work item uses the same durable grammar: human bare configured key or `Confirmed: <env>`; automated `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` otherwise. Human confirmation replaces an automated annotation with the bare key or `Confirmed: <env>`. For legacy bare values, managed draft markers and current ticket content decide provenance; provider edit history is not required. A marker proves automation; otherwise unknown provenance plus conflicting evidence stops for confirmation. Human-confirmed wins, then validated `Inferred:`; otherwise one exact `deploy.branches` key from the human-authored title, body, and reproduction steps or URL hostname drives the implementation base branch. Exclude the complete `Target Backend Environment` section and other machine-authored metadata/draft blocks so annotations cannot become evidence. Evidence supersedes only `Assumption:`. Normalize `prod` ↔ `production` only when exactly one is configured; no other aliases exist. Conflicts stop. Never infer from arbitrary branch text, URL paths/query strings, or substrings. With no signal, use the remote default and record the applicable assumption without blocking on a non-unique reverse-map. Require any selected mapping and remote branch. A reported bug environment is an example of the all-work-type rule. Non-integration fixes still require the linked forward cherry-pick.

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 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.
+1. **Best-effort autofill (before blocking).** Run `pre-flight-autofill` for every work item. Preserve a human bare configured key or `Confirmed: <env>`; automation writes `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` otherwise. Human confirmation replaces the annotation with the bare key or `Confirmed: <env>`. For a legacy bare value, use managed draft markers and current ticket content only; provider edit history is not required. A marker proves automation and requires re-annotation; otherwise unknown provenance plus conflicting evidence stops for confirmation. Resolve one exact `deploy.branches` key from the human-authored title, body, and reproduction steps or URL hostname; exclude the complete `Target Backend Environment` section and other machine-authored metadata/draft blocks so annotations cannot become evidence. A reported bug environment is an example, not a restriction. Evidence supersedes only `Assumption:`. Normalize `prod` ↔ `production` only when exactly one is configured; no other aliases exist. Conflicts stop; never infer from arbitrary branch text, URL paths/query strings, or substrings. Write through `jira-write-ticket`, never overwrite human prose, then re-run `jira-verify`.
 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).
@@ -132,4 +132,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 no environment can be found anywhere in the ticket, fall back to the configured default branch and record that assumption. If the reported environment is present but missing from `deploy.branches`, or its mapped branch is absent on the remote, stop and report the missing environment/branch mapping 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.
+- The environment handoff for every work item uses the same durable grammar: human bare configured key or `Confirmed: <env>`; automated `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` otherwise. Human confirmation replaces an automated annotation with the bare key or `Confirmed: <env>`. For legacy bare values, managed draft markers and current ticket content decide provenance; provider edit history is not required. A marker proves automation; otherwise unknown provenance plus conflicting evidence stops for confirmation. Human-confirmed wins, then validated `Inferred:`; otherwise one exact `deploy.branches` key from the human-authored title, body, and reproduction steps or URL hostname drives the implementation base branch. Exclude the complete `Target Backend Environment` section and other machine-authored metadata/draft blocks so annotations cannot become evidence. Evidence supersedes only `Assumption:`. Normalize `prod` ↔ `production` only when exactly one is configured; no other aliases exist. Conflicts stop. Never infer from arbitrary branch text, URL paths/query strings, or substrings. With no signal, use the remote default and record the applicable assumption without blocking on a non-unique reverse-map. Require any selected mapping and remote branch. A reported bug environment is an example of the all-work-type rule. Non-integration fixes still require the linked forward cherry-pick.

package/plugins/lisa-copilot/agents/linear-agent.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 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.
+1. **Best-effort autofill (before blocking).** Run `pre-flight-autofill` for every work item. Preserve a human bare configured key or `Confirmed: <env>`; automation writes `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` otherwise. Human confirmation replaces the annotation with the bare key or `Confirmed: <env>`. For a legacy bare value, use managed draft markers and current ticket content only; provider edit history is not required. A marker proves automation and requires re-annotation; otherwise unknown provenance plus conflicting evidence stops for confirmation. Resolve one exact `deploy.branches` key from the human-authored title, body, and reproduction steps or URL hostname; exclude the complete `Target Backend Environment` section and other machine-authored metadata/draft blocks so annotations cannot become evidence. A reported bug environment is an example, not a restriction. Evidence supersedes only `Assumption:`. Normalize `prod` ↔ `production` only when exactly one is configured; no other aliases exist. Conflicts stop; never infer from arbitrary branch text, URL paths/query strings, or substrings. Write through `linear-write-issue`, never overwrite human prose, then re-run `linear-verify`.
 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}]`.
@@ -135,4 +135,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 no environment can be found anywhere in the item, fall back to the configured default branch and record that assumption. If the reported environment is present but missing from `deploy.branches`, or its mapped branch is absent on the remote, stop and report the missing environment/branch mapping 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.
+- The environment handoff for every work item uses the same durable grammar: human bare configured key or `Confirmed: <env>`; automated `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` otherwise. Human confirmation replaces an automated annotation with the bare key or `Confirmed: <env>`. For legacy bare values, managed draft markers and current ticket content decide provenance; provider edit history is not required. A marker proves automation; otherwise unknown provenance plus conflicting evidence stops for confirmation. Human-confirmed wins, then validated `Inferred:`; otherwise one exact `deploy.branches` key from the human-authored title, body, and reproduction steps or URL hostname drives the implementation base branch. Exclude the complete `Target Backend Environment` section and other machine-authored metadata/draft blocks so annotations cannot become evidence. Evidence supersedes only `Assumption:`. Normalize `prod` ↔ `production` only when exactly one is configured; no other aliases exist. Conflicts stop. Never infer from arbitrary branch text, URL paths/query strings, or substrings. With no signal, use the remote default and record the applicable assumption without blocking on a non-unique reverse-map. Require any selected mapping and remote branch. A reported bug environment is an example of the all-work-type rule. Non-integration fixes still require the linked forward cherry-pick.

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

@@ -48,13 +48,32 @@ empirical evidence only—native Playwright/Cypress/Maestro remains the regressi
 
 ## 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.
+The `## Target Backend Environment` grammar is durable: human-confirmed values
+are a bare configured key or `Confirmed: <env>`; automation writes either
+`Inferred: <env> — evidence: <title|body|reproduction|hostname>` or
+`Assumption: <env> — remote default branch <branch>`. When no unique environment
+maps to the default branch, use `Assumption: remote default branch <branch>`.
+Human confirmation replaces an automated annotation with a bare key or
+`Confirmed: <env>`. For legacy bare values, use managed draft markers and current
+ticket content only; provider edit history is not required. A marker proves
+automation and requires re-annotation; otherwise unknown provenance with
+conflicting evidence stops for confirmation.
+
+Resolution order is human-confirmed value; validated `Inferred:` evidence; then
+one unambiguous signal from the human-authored title, body, and reproduction
+steps or a URL hostname. Exclude the complete `Target Backend Environment`
+section and other machine-authored metadata/draft blocks from the scan so an
+annotation cannot validate or conflict with itself. Evidence supersedes only an
+`Assumption:`. A signal must be an exact
+`deploy.branches` key as a complete token/hostname label. The sole normalization
+is `prod` ↔ `production` when exactly one is configured; no other aliases exist.
+Conflicting signals stop. Never infer from arbitrary branch text, URL paths or
+query strings, or substrings. With no signals, use the remote default branch and
+record an assumption: include `<env>` only for a unique reverse-map, otherwise
+use the branch-only form without inventing an environment or blocking. Require
+any selected environment mapping and its remote branch to exist.
+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-copilot/rules/eager/pre-flight-autofill.md

@@ -21,13 +21,27 @@ 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. 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 repo's remote default branch when
-  no environment is discoverable anywhere in the work item, and record that as
-  an assumption.
+  vendor `*-add-journey` skill), Target Backend Environment. Preserve a bare
+  configured key or `Confirmed: <env>` as human-confirmed. Automation writes
+  `Inferred: <env> — evidence: <title|body|reproduction|hostname>` or
+  `Assumption: <env> — remote default branch <branch>`. Without a unique
+  reverse-map use `Assumption: remote default branch <branch>`; human confirmation
+  replaces the annotation with a bare key or `Confirmed: <env>`. For legacy bare
+  values, use managed draft markers and current ticket content only; provider
+  edit history is not required. A marker proves automation and requires
+  re-annotation; otherwise unknown provenance plus conflicting evidence stops.
+  Human-confirmed wins, then validated `Inferred:`
+  evidence. Otherwise use one unambiguous exact `deploy.branches` key from the
+  title, body, and reproduction steps or a URL hostname, excluding the complete
+  `Target Backend Environment` section and other machine-authored metadata/draft
+  blocks so annotations cannot become evidence. Evidence supersedes only
+  `Assumption:`. Normalize only built-in
+  `prod` ↔ `production` when exactly one is configured; no other aliases exist.
+  Never infer from arbitrary branch text, URL paths/query strings, or substrings.
+  Conflicting signals **stop** autofill. With no environment signal, use the
+  remote default and record the applicable `Assumption:` form; a non-unique
+  reverse-map alone never blocks. Require any selected mapping and remote branch.
+  Never overwrite human prose.
 - **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-copilot/rules/eager/rejection-detection.md

@@ -37,4 +37,15 @@ An artifact this flow produced is **never** a rejection-reflection trigger, no m
 
 On `rejection-reclaim` only, before re-implementing: read the rejection evidence (comments after the backward transition, review threads on the rejected PR) through the access layers, assemble **one** candidate learning with the rejection linked as provenance, and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate as a comment that carries a **visible prose line** plus the marker (a bare marker renders as an empty comment bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` followed by `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. **Marker-dedupe** on `<issue>-<backward-transition-timestamp>`: re-claiming twice produces no duplicate. Unreadable/absent evidence → proceed without a candidate, never block.
 
-Full contract (classification table, per-vendor bindings, reflection & evidence handoff): [reference/rejection-detection.md](../reference/rejection-detection.md).
+## Proposal rejection memory (proposal-side — orthogonal to the reclaim path above)
+
+A **loop-proposed** item that a human **closed as _not planned_** is a durable decline. Every *proposing* loop (`lisa-exploratory-qa`, `lisa-project-ideation`, `lisa-monitor`, `lisa-repair-intake`; `lisa-learnings-audit` is the shipped precedent) MUST consult it **before filing a candidate**. This is orthogonal to the `rejection-reclaim` path above — that classification and its reflection are untouched. The memory lives in the **tracker, not a new state file**.
+
+- **Signal:** the prior item is closed *not planned* (GitHub `stateReason == "not_planned"`; the JIRA/Linear equivalent resolved via `config-resolution` — never hardcode). The GitHub compare is **case-insensitive** — raw `gh --json stateReason` returns `NOT_PLANNED` UPPERCASE, so normalize to lowercase (or read via `lisa-github-read-issue`) before comparing, never string-match raw `gh` JSON. Closed as **completed** is NOT a decline — a recurrence after a completed fix is a regression and may file.
+- **Marker:** `<!-- [<loop-marker>] key=<candidate-key> -->`, key computed deterministically `printf '%s' "$normalized" | shasum -a 256 | cut -c1-12`. Search **open AND closed** items for the marker before filing (body-enumeration fallback on search-index lag); **match on the marker, never the title.**
+- **Rule:** a hit on a closed-**not-planned** item **suppresses** the proposal. Re-file **only** with evidence postdating the decline, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
+- **Operator footer:** every loop-filed proposal ticket MUST carry, as visible prose, `To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression.` — so the operator knows which close-reason produces which outcome.
+- **Outcomes:** an all-suppressed cycle ends `nothing-needed` naming the **suppression count**; a memory check that cannot read the tracker ends `recovery-required`, never a silent `nothing-needed` (e.g. `Tracker unreachable during the decline check — restore credentials; nothing was filed this run.`).
+- **Concurrency:** search-then-write = convergence, not mutual exclusion — a transient duplicate is closed by the next run; no cross-run lock.
+
+Full contract (classification table, per-vendor bindings, reflection & evidence handoff, Proposal rejection memory): [reference/rejection-detection.md](../reference/rejection-detection.md).

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

@@ -217,23 +217,47 @@ Declares **where this repo's LLM Wiki lives** so the query/ingest skills can res
 
 ### Env → base branch
 
-Implementation flows resolve their PR base from the work item's
-`## Target Backend Environment` in the forward direction of `deploy.branches`.
+Implementation flows resolve their PR base from the work item's environment
+evidence 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.
+The field grammar records provenance durably: human-confirmed values are a bare
+configured key or `Confirmed: <env>`; automated evidence is
+`Inferred: <env> — evidence: <title|body|reproduction|hostname>`; an automated
+fallback is `Assumption: <env> — remote default branch <branch>`. Human
+fallback without a unique reverse-map is
+`Assumption: remote default branch <branch>`. Human
+confirmation replaces an automated annotation with a bare key or
+`Confirmed: <env>`.
+
+For legacy bare values created before this grammar, use managed draft markers
+and current ticket content only; provider edit history is neither required nor
+assumed. A managed marker proves automation and requires rewriting to
+`Inferred:` or `Assumption:`. Without one, provenance remains unknown, so the
+bare value is usable only if no conflicting evidence exists; a conflict stops
+for confirmation.
+
+Resolve it in this order: human-confirmed wins; validated `Inferred:` evidence
+is next; otherwise accept one unambiguous exact `deploy.branches` key from the
+human-authored title, body, and reproduction steps or a URL hostname. Exclude
+the entire `Target Backend Environment` section and all other machine-authored
+metadata/draft blocks from the evidence scan, so annotations never validate or
+conflict with themselves. Evidence supersedes only
+an `Assumption:`. Treat the reported bug environment as an example of this
+all-work-type evidence rule, not a special case. Normalize only built-in
+`prod` ↔ `production` when exactly one is configured; no other aliases exist.
+Never infer from arbitrary branch text, URL paths/query strings, or substrings.
+Multiple conflicting signals stop. With no signals, use the remote default
+branch and record an assumption: include the environment only for a unique
+reverse-map; otherwise use the branch-only form without inventing an environment
+or blocking solely on the reverse-map.
+
+Every selected environment must have a unique `deploy.branches` mapping and its
+mapped branch must exist on the remote. If either validation fails, stop and
+report it. Do not silently default to the integration branch.
 
 For non-integration environment bugs, definition of done is two-step:
 
@@ -504,10 +528,25 @@ If a project's terminal state is the same regardless of env, set `done` to a str
 
 `deploy.branches` is also read in the **forward** direction by the build flow (`lisa-implement`): the environment a work item targets determines the branch the work is built on and the branch the PR opens against.
 
-1. **Resolve the work item's target environment** — its `## Target Backend Environment` field.
-2. **If no environment is named**, use the **remote default branch** (`gh repo view --json defaultBranchRef`, or `origin/HEAD`) and record that default-branch assumption.
-3. **If a reported environment exists**, map env → base branch via `deploy.branches` (e.g. `staging → staging`, `production → main`). A reported env absent from `deploy.branches`, or a mapped branch missing from the remote, must stop and report the exact missing environment-to-branch mapping; never guess and never silently fall back.
-4. **Before any code is written**, `lisa-implement` fetches and **rebases the working branch onto `origin/<base>`, resolving conflicts**, so implementation builds on the latest target-environment code. **The PR then opens against that same base branch** (`target_branch=<base>` to `lisa-git-submit-pr`).
+The durable field forms are: bare configured key or `Confirmed: <env>` for a
+human-confirmed value; `Inferred: <env> — evidence: <title|body|reproduction|hostname>`
+for automation-backed evidence; and
+`Assumption: <env> — remote default branch <branch>` for a generic fallback.
+When the remote default has no unique environment reverse-map, the valid form is
+`Assumption: remote default branch <branch>`.
+Human confirmation replaces the automated annotation with a bare key or
+`Confirmed: <env>`.
+
+For a legacy bare value, use managed draft markers and current ticket content
+only; do not require provider edit history. A marker proves automation and
+requires re-annotation; otherwise unknown provenance plus conflicting evidence
+stops for confirmation.
+
+1. **Resolve provenance first.** Human-confirmed wins, then validated `Inferred:` evidence. Otherwise search the human-authored title, body, and reproduction steps or URL hostname for one unambiguous exact `deploy.branches` key. Exclude the complete `Target Backend Environment` section and other machine-authored metadata/draft blocks from the scan so annotations cannot become evidence. Evidence supersedes only an `Assumption:`.
+2. **Normalize narrowly.** Normalize built-in `prod` ↔ `production` only when exactly one of those keys is configured. No other aliases exist. Never infer from arbitrary branch text, URL paths/query strings, or substrings.
+3. **Handle absence and conflict explicitly.** Multiple conflicting signals stop. With no signals, use the remote default branch (`gh repo view --json defaultBranchRef`, or `origin/HEAD`) and record the env-bearing assumption only for a unique reverse-map; otherwise use the branch-only assumption without inventing an environment or blocking.
+4. **Validate the destination.** The selected exact configured key must map uniquely and the mapped remote branch must exist; otherwise stop without guessing or falling back.
+5. **Before any code is written**, `lisa-implement` fetches and **rebases the working branch onto `origin/<base>`, resolving conflicts**, then opens the PR against that same base (`target_branch=<base>`).
 
 This is the exact inverse of the env-keyed `done` "Branch inference" above: `done` derives the env *from* the PR base branch (reverse); the build flow derives the base branch *from* the env (forward). Both use the one `deploy.branches` map, so the branch a PR targets and the `done` status it earns always agree.
 

package/plugins/lisa-copilot/rules/reference/observability-audit.md

@@ -94,7 +94,11 @@ A manual re-run next week must not duplicate last week's tickets. Mirror the `re
    - Anomaly: `sha1("<source>:<stable-signature>:<CURRENT_REPO>")` (12 hex chars). `stable-signature` is the Sentry issue short-id (or culprit), the CloudWatch alarm name, or `errorType@location` — something that survives between runs, **never** the human title or occurrence count.
    - Gap: the literal `gap:<dimension>:<CURRENT_REPO>` (a dimension is missing-or-not; no hash needed).
 2. **Sentinel in the body.** Embed `<!-- lisa:monitor-finding: <fingerprint> -->` in every filed ticket.
-3. **Search before create** (this IS gate S13). Before filing, search the tracker for the fingerprint string. The search **MUST include closed/resolved tickets** (`gh issue list --search <fp> --state all` for GitHub; JQL with no status filter for JIRA; all states for Linear) — otherwise a just-closed match is invisible and the backoff below can't fire. If an **open** ticket carries the fingerprint → skip (optionally link). If a ticket carrying it was closed **within the recently-resolved backoff window** (`monitor.backoffHours`, default **24h** — matching the 24h Sentry event window; this is **not** the 2h `intake.repair.staleAfterHours`) → skip, to avoid re-filing a just-fixed regression before its signal has drained. Only file when no live or recently-resolved match exists.
+3. **Search before create** (this IS gate S13). Before filing, search the tracker for the fingerprint string. The search **MUST include closed/resolved tickets** (`gh issue list --search <fp> --state all` for GitHub; JQL with no status filter for JIRA; all states for Linear) — otherwise a just-closed match is invisible and the backoff and decline checks below can't fire. If an **open** ticket carries the fingerprint → skip (optionally link). Otherwise classify a closed match by **how** it closed:
+   - **Closed as _not planned_ — a permanent decline** (`rejection-detection` **Proposal rejection memory**). GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear (never a hardcoded lane string). This is a durable human "no", not a time-boxed guard: **suppress the finding regardless of age**, and re-file only with evidence that **postdates the decline**. The new ticket MUST carry BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and the human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`). This layers *on top of* the backoff below — a not_planned close outlives any window.
+   - **Closed as _completed_ within the recently-resolved backoff window** (`monitor.backoffHours`, default **24h** — matching the 24h Sentry event window; this is **not** the 2h `intake.repair.staleAfterHours`) → skip, to avoid re-filing a just-fixed regression before its signal has drained. A completed close **older** than the window is not a decline — a genuine recurrence is a regression and may file.
+
+   Only file when no live match, no recently-resolved completed match, and no prior not_planned decline exists.
 
 ## The cap
 

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

@@ -49,14 +49,29 @@ 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** — 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 the repo's
-  remote default branch when no environment is discoverable anywhere in the
-  work item, and record the default as an explicit assumption.
+- **Target Backend Environment** — preserve a bare configured key or
+  `Confirmed: <env>` as human-confirmed. Automated evidence must write
+  `Inferred: <env> — evidence: <title|body|reproduction|hostname>`; a generic
+  fallback must write `Assumption: <env> — remote default branch <branch>`.
+  If the default branch has no unique environment reverse-map, instead write
+  `Assumption: remote default branch <branch>` without inventing an environment.
+  Human confirmation replaces an automated annotation with a bare key or
+  `Confirmed: <env>`. For legacy bare values, use managed draft markers and
+  current ticket content only; provider edit history is not required. A marker
+  proves automation and requires re-annotation; otherwise unknown provenance
+  plus conflicting evidence stops for confirmation. A human-confirmed value wins, followed by validated
+  `Inferred:` evidence. Otherwise inspect the title, body, and reproduction
+  steps or a URL hostname for one unambiguous exact `deploy.branches` key,
+  excluding the complete `Target Backend Environment` section and all other
+  machine-authored metadata/draft blocks so annotations cannot become evidence.
+  Clear evidence supersedes only an `Assumption:` value. The sole normalization
+  is `prod` ↔ `production` when exactly one key is configured; no other aliases
+  exist. Never infer from arbitrary branch text, URL paths or query strings, or
+  substrings. Multiple conflicting signals **stop** autofill. With no
+  environment signal, use the remote default and record the applicable
+  `Assumption:` form; a missing/ambiguous reverse-map alone never blocks.
+  Require any selected environment mapping and remote branch. Never overwrite
+  human prose.
 
 **Tier B — irreducibly human (cannot invent — but still propose a default):**
 

package/plugins/lisa-copilot/rules/reference/rejection-detection.md

@@ -101,3 +101,64 @@ Mining a learning is not enough — if the agent then rebuilds the same rejected
 - **The evidence summary** names: what was rejected, why (the defect the QA comment named), and the specific approach the rejection named as wrong.
 - **The plan must reckon with it.** On a `rejection-reclaim`, the re-implementation plan MUST explicitly address the rejection evidence and MUST NOT re-propose the specific approach the rejection named as wrong.
 - **Absence never blocks.** If the rejection evidence is unreadable or absent, the agent still implements the item — degraded, not stopped.
+
+## Proposal rejection memory (a loop-proposed item closed as *not planned*)
+
+Everything above is **claim-time** memory — a work item that was bounced *backward* through the lanes. This section is its orthogonal twin: **proposal-time** memory — an item a **loop itself proposed** that a human then **closed as _not planned_**. The two never touch. The `rejection-reclaim` classification, its reflection path, and its evidence handoff above are **unchanged**; this section adds a second, independent contract that every *proposing* loop consults **before it files a candidate**.
+
+The most corrosive failure of an unattended fleet is nagging: a human declines a proposal and the loop cheerfully files it again next cycle, until operators stop reading the tracker. The cure is to make a decline durable. The memory lives in the **tracker, not a new state file** — a closed-as-not-planned proposal *is* the record of the human's "no", matched by a stable marker key. This generalizes `lisa-learnings-audit`'s already-shipped idempotency discipline to every proposing loop: `lisa-exploratory-qa`, `lisa-project-ideation`, `lisa-monitor`, and `lisa-repair-intake` cite this section; the gardener (`lisa-learnings-audit`) is the shipped precedent it was modeled on, not a second implementation.
+
+### Rejection signal — "not planned", resolved from config
+
+A proposal is **declined** when its prior item is **closed as _not planned_**:
+
+- **GitHub** — `stateReason == "not_planned"` (surfaced by `lisa-github-read-issue`, which renders `State: closed (not_planned)`). **The comparison is case-insensitive:** raw `gh issue view --json stateReason` returns the value UPPERCASE (`NOT_PLANNED` / `COMPLETED`), so a literal string-compare against `not_planned` on raw `gh` output would false-negative a genuine decline. Normalize the value to lowercase before comparing, or consume it through `lisa-github-read-issue`'s already-lowercased rendering — never string-match raw `gh` JSON directly.
+- **JIRA / Linear** — the configured *not-planned* equivalent resolved per the `config-resolution` rule (a JIRA won't-do resolution, a Linear canceled state), **never a hardcoded lane string** — exactly as the claim-time lane names above always come from `.lisa.config.json`, never a literal.
+
+**Closed as _completed_ is NOT a decline.** A completed fix whose underlying problem later recurs is a **regression**, and the loop **may file** it — the recurrence is genuinely new work, not a re-proposal of the declined thing. Only *not planned* is the durable "no".
+
+### Marker discipline — deterministic key, open AND closed search
+
+Every loop-proposed item carries a **visible prose line** plus a marker (a bare HTML marker renders as an empty comment bubble):
+
+```
+<!-- [<loop-marker>] key=<candidate-key> -->
+```
+
+`<loop-marker>` is the proposing loop's own marker (`[lisa-exploratory-qa]`, `[lisa-project-ideation]`, `lisa:monitor-finding`, `[lisa-repair-intake]`, `[lisa-gardener]`). `<candidate-key>` is computed **deterministically — never estimated by the model** (the gardener's exact formula):
+
+1. **Normalize** the candidate's stable identity (surface + symptom, idea key, or finding signature): trim, collapse every internal whitespace run to a single space, lowercase.
+2. **Hash** in Bash: `printf '%s' "$normalized" | shasum -a 256 | cut -c1-12`.
+
+The same candidate therefore always produces the same key across runs, regardless of which session computes it. **Before filing anything, every loop searches the tracker for that marker across open AND closed items** — keyed on the stable prefix first, the hash as disambiguation only — plus a **body-enumeration fallback for search-index lag** (`gh issue list --state all --json number,body` and grep the bodies; `gh search issues` already covers open and closed by default — `--state all` is NOT a valid `gh search` flag). **Match on the marker, never the title.**
+
+### Operator footer — teach the close-reason where the operator reads it
+
+The whole mechanism hinges on a distinction the operator cannot see unless we say it: closing a proposal **Not planned** silences it for good, while closing it **Completed** leaves the door open to a regression re-file. So every loop-filed proposal ticket MUST carry this footer verbatim as its own visible prose line (not only the HTML marker), so the human at the gate knows exactly which close-reason produces which outcome:
+
+> To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression.
+
+This footer is **required on every proposing loop's filed ticket** (`lisa-exploratory-qa`, `lisa-monitor`, `lisa-project-ideation`, `lisa-learnings-audit`, and any other loop that files a proposal). It is what makes the tracker-as-memory legible to a non-technical operator — the close-button becomes a documented control, not a guess.
+
+### The rule
+
+A marker hit on a **closed-as-not-planned** item **suppresses the proposal** — regardless of title similarity. Re-proposal is permitted **only** with evidence that **postdates the decline**, and the re-filed item MUST carry BOTH of the following:
+
+1. **A machine token** for the dedupe/audit trail — generalizing the gardener's wording:
+
+   > declined `<decline-date>`; recurred `<recurrence-date>` in `<recurrence-ref>`
+
+2. **A human acknowledgment sentence** in plain prose, so re-raising reads as a respectful return to an answered question rather than a machine nagging:
+
+   > You declined this on `<decline-date>`. It has recurred (`<recurrence-date>`, `<recurrence-ref>`), so we're raising it once more for your review.
+
+Naming the decline date, the recurrence date, and the recurrence reference in both forms is what turns "raising it again" into an auditable, evidence-backed, operator-legible act rather than nagging. A marker hit on a closed-as-**completed** item is not a decline — it falls under the regression path above.
+
+### Interaction with run outcomes
+
+- **Every candidate suppressed** — a cycle whose only candidates were each suppressed by a prior decline terminates **`nothing-needed`**, and its one-line summary **names the suppression count** (e.g. `Explored 4 personas; 2 candidates suppressed by a prior decline — nothing new to propose.`). Respecting a decline is thereby *visible* in the run record — never indistinguishable from finding nothing.
+- **Tracker unreadable during the memory check** — if the open-and-closed marker search cannot run (tracker unreachable, credentials revoked, the substrate broken), the loop terminates **`recovery-required`**, **never** a silent `nothing-needed`. A memory check that could not run is a broken loop, not a quiet one — this is the exact failure mode the contract exists to exclude, so "I saw no candidates" must never be conflated with "I could not look". The one-line summary names the broken check and the fix in operator language, e.g. `Tracker unreachable during the decline check — restore credentials; nothing was filed this run.`
+
+### Concurrency honesty
+
+The search-then-write here is **not** an atomic claim: two truly concurrent runs can each miss the other's in-flight proposal and file a transient duplicate. It therefore guarantees **convergence, not mutual exclusion** — the duplicate is found and closed by the next run's marker search, and because the key is a stable content hash, a duplicate never multiplies. State this rather than implying a lock; a cross-run locking protocol would be disproportionate to the risk.

package/plugins/lisa-copilot/skills/lisa-exploratory-qa/SKILL.md

@@ -74,7 +74,15 @@ Each finding is a flat leaf, so `build_ready` applies directly — pass it expli
 
 ### Idempotency — don't spam duplicates
 
-Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for an **open** ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the `<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`). If one exists, reference/update it instead; only create when none exists. **Match by the marker, never by title.** A *closed* prior ticket does not suppress a new one — a recurrence after a fix is a genuine regression.
+Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for a ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the `<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`). Per the `rejection-detection` rule's **Proposal rejection memory** section, that marker search MUST cover **open AND closed** tickets (with a body-enumeration fallback on search-index lag), and **match by the marker, never by title.** Then split on how any prior ticket closed:
+
+- **Open** ticket carrying the marker → reference/update it instead; do not create a second.
+- **Closed as _completed_** → does **not** suppress. A recurrence after a fix is a genuine **regression**, so file the finding.
+- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
+
+Every filed finding ticket MUST end with the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it:
+
+> To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression.
 
 ## Output
 
@@ -94,13 +102,13 @@ and records it, so a quiet run and a broken run are never mistaken for each othe
 | This cycle's exit path | Run outcome |
 |---|---|
 | Findings filed — one or more `Bug` / `Improvement` tickets created or referenced (§6) | `candidate-proposed` |
-| Clean pass — explored the personas and surfaces, nothing worth filing | `nothing-needed` |
-| Tracker unconfigured — the §1 stop path; findings cannot be filed | `recovery-required` |
+| Clean pass — explored the personas and surfaces, nothing worth filing — **or** every candidate was suppressed by a prior decline (`rejection-detection` **Proposal rejection memory**): the summary MUST name the suppression count | `nothing-needed` |
+| Tracker unconfigured — the §1 stop path; findings cannot be filed — **or** the open-and-closed rejection-memory marker search could not run (tracker unreachable / credentials revoked): a memory check that could not run is a broken loop, never a silent `nothing-needed` | `recovery-required` |
 | A degradation that still let the pass explore (e.g. Kane unavailable, one persona unreachable) | the outcome it actually reached above, with the summary **leading with the degradation** — degradation never mints a seventh token |
 
 Record **exactly one** outcome per invocation through the run-record CLI, naming this loop's runbook
 (the `--summary` is the operator-readable one-liner in the contract's exemplar voice — plain,
-specific, actionable, e.g. `Explored 4 personas; nothing confusing to file.` for `nothing-needed`):
+specific, actionable, e.g. `Explored 4 personas; nothing confusing to file.` — or, when a decline suppressed the only candidates, `Explored 4 personas; 2 candidates suppressed by a prior decline — nothing new to propose.` — for `nothing-needed`; and for a `recovery-required` from an unreadable decline check, `Tracker unreachable during the decline check — restore credentials; nothing was filed this run.`):
 
 ```bash
 node "${CLAUDE_PLUGIN_ROOT}/scripts/automation-run-record.mjs" \

package/plugins/lisa-copilot/skills/lisa-github-validate-issue/SKILL.md

@@ -154,7 +154,7 @@ When `issue_type ∉ {Bug, Epic}`, `parent_ref` must be set — **except for a b
 
 #### S8 — Target Backend Environment
 
-When `runtime_behavior_change = true`, body must contain `## Target Backend Environment` with one of `dev`, `staging`, `prod`. Skipped for doc-only / config-only / type-only / Epic.
+When `runtime_behavior_change = true`, the body must contain `## Target Backend Environment`. Read accepted environments from the exact configured keys of `.lisa.config.json` `deploy.branches`, never from a hardcoded list. Accept a human-confirmed bare exact configured key or `Confirmed: <env>`, automated `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, automated `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` when no unique reverse-map exists. Human confirmation replaces an automated annotation with the bare key or `Confirmed: <env>`. For legacy bare values, use managed draft markers and current ticket content only; provider edit history is not required. A marker proves automation and requires re-annotation; otherwise unknown provenance plus conflicting evidence fails for confirmation. Validate the annotation shape/source and remote-default branch; validate `<env>` as an exact configured key whenever present. A valid branch-only assumption must not fail solely because its reverse-map is absent or ambiguous. Normalize built-in `prod` ↔ `production` only when exactly one of those keys is configured. No other aliases are valid. Skipped for doc-only / config-only / type-only / Epic.
 
 #### S9 — Sign-in Required
 

package/plugins/lisa-copilot/skills/lisa-github-write-issue/SKILL.md

@@ -38,7 +38,7 @@ Resolve `<ORG>` and `<REPO>` from the ref or from `.lisa.config.json`.
 | Priority | CREATE | Label `priority:<low|medium|high|critical>`. |
 | Acceptance criteria | Story, Task, Bug, Sub-task, Improvement | Gherkin in `## Acceptance Criteria` — see Phase 3. |
 | Validation Journey | Runtime-behavior changes | Delegate to `/github-add-journey`. |
-| Target backend environment | Runtime-behavior changes | Recorded under `## Target Backend Environment`. Skip only for doc / config / type-only. |
+| Target backend environment | Runtime-behavior changes | For every work type, use an exact `deploy.branches` key when an environment is known. Human: bare key or `Confirmed: <env>`. Automation: `Inferred: <env> — evidence: <title\|body\|reproduction\|hostname>`, `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` otherwise. Human confirmation replaces an automated annotation with the bare key or `Confirmed: <env>`. |
 | Sign-in account / credentials | Authenticated-surface tickets | Recorded under `## Sign-in Required`. |
 | Repository | Bug, Task, Sub-task | GitHub Issues live in exactly one repo by definition — record the repo name under `## Repository`, and reject any AC bullet that references a different repo. |
 | Source Requirement | PRD-sourced issues (`prd_source` provided) | `## Source Requirement` with PRD link + verbatim requirement quote(s) — see Phase 3; enforced at every level, sub-issues included. |
@@ -91,8 +91,14 @@ Scenario: <name>
 [Explicit list of what this issue does NOT cover. Forces scope discipline.]
 
 ## Target Backend Environment
-[Required when the issue changes runtime behavior. One of: dev / staging / prod.
- Skip section entirely for doc-only, config-only, or type-only issues.]
+[Required when the issue changes runtime behavior. Use an exact
+ `deploy.branches` key. A human-confirmed value is a bare key or
+ `Confirmed: <env>`. An automated evidence write is
+ `Inferred: <env> — evidence: <title|body|reproduction|hostname>`; an automated
+ generic default is `Assumption: <env> — remote default branch <branch>`.
+ Without a unique reverse-map use `Assumption: remote default branch <branch>`.
+ Human confirmation replaces the automated annotation with a bare key or
+ `Confirmed: <env>`. Skip only for doc/config/type-only issues.]
 
 ## Sign-in Required
 [Include this section ONLY if the work touches authenticated surfaces.

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

@@ -84,8 +84,12 @@ 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). 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`), and record that fallback assumption in the plan/tracker artifact before proceeding. 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.
+1. **Resolve the target environment with durable provenance.** The `## Target Backend Environment` value has this exact grammar: a human-confirmed value is either a bare configured key or `Confirmed: <env>`; automated evidence writes `Inferred: <env> — evidence: <title|body|reproduction|hostname>`; an automated fallback writes `Assumption: <env> — remote default branch <branch>` when the branch maps uniquely, or `Assumption: remote default branch <branch>` when it does not. Human confirmation replaces an automated annotation with the bare configured key or `Confirmed: <env>`. For a legacy bare value created before this grammar, use managed draft markers and current ticket content only — provider edit history is not required or assumed. A managed marker proves automation and requires rewriting to `Inferred:` or `Assumption:`; without a marker provenance is unknown, so the value may be used only when no conflicting evidence exists, and a conflict **stops for confirmation**.
+   - A human-confirmed value wins. Otherwise a validated `Inferred:` value is next.
+   - Otherwise inspect the human-authored title, body, and reproduction steps for exactly one unambiguous signal: an exact `deploy.branches` key as a complete token, or that key as a complete label in a URL hostname (`staging.<domain>`, `gql.staging.*`). Exclude the entire `Target Backend Environment` section and all other machine-authored metadata/draft blocks from this evidence scan so an `Inferred:` or `Assumption:` annotation can never validate or conflict with itself. Clear evidence may supersede only an `Assumption:` value, never a human-confirmed value.
+   - The only normalization is built-in `prod` ↔ `production`, and only when exactly one of those keys exists in `deploy.branches`; normalize to that configured key. No other aliases exist.
+   - Never infer from arbitrary branch text, URL paths or query strings, or substrings inside other words or hostname labels. Multiple conflicting signals after normalization **stop** the flow. If there are no signals, resolve the remote default branch (`gh repo view --json defaultBranchRef -q .defaultBranchRef.name`, or `git remote set-head origin -a` then `origin/HEAD`). When it reverse-maps uniquely, write the env-bearing `Assumption:` form; when the reverse-map is not unique, write the branch-only form and continue on the remote default without inventing an environment or blocking solely for that ambiguity. Record the fallback assumption in the plan/tracker artifact.
+2. **Map the resolved environment to a base branch** through `.lisa.config.json` `deploy.branches` — the forward direction of the env-keyed `done` resolution. The selected exact configured key must map uniquely, and the mapped branch must exist on the remote. A missing/ambiguous mapping or remote branch **stops** the flow; never guess or silently fall back.
 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.

package/plugins/lisa-copilot/skills/lisa-jira-validate-ticket/SKILL.md

@@ -155,7 +155,7 @@ When `issue_type ∉ {Bug, Epic}`, `parent_key` must be set — **except for a b
 
 #### S8 — Target Backend Environment
 
-When `runtime_behavior_change = true`, description must contain a `Target Backend Environment` section (`h2.` / `##` in proposed text, or an ADF heading in live JIRA) with one of `dev`, `staging`, `prod`. Skipped for doc-only / config-only / type-only / Epic.
+When `runtime_behavior_change = true`, the description must contain a `Target Backend Environment` section (`h2.` / `##` in proposed text, or an ADF heading in live JIRA). Read accepted environments from the exact configured keys of `.lisa.config.json` `deploy.branches`, never from a hardcoded list. Accept a human-confirmed bare exact configured key or `Confirmed: <env>`, automated `Inferred: <env> — evidence: <title|body|reproduction|hostname>`, automated `Assumption: <env> — remote default branch <branch>` for a unique reverse-map, or `Assumption: remote default branch <branch>` when no unique reverse-map exists. Human confirmation replaces an automated annotation with the bare key or `Confirmed: <env>`. For legacy bare values, use managed draft markers and current ticket content only; provider edit history is not required. A marker proves automation and requires re-annotation; otherwise unknown provenance plus conflicting evidence fails for confirmation. Validate the annotation shape/source and remote-default branch; validate `<env>` as an exact configured key whenever present. A valid branch-only assumption must not fail solely because its reverse-map is absent or ambiguous. Normalize built-in `prod` ↔ `production` only when exactly one of those keys is configured. No other aliases are valid. Skipped for doc-only / config-only / type-only / Epic.
 
 #### S9 — Sign-in Required