@codyswann/lisa 2.255.0 → 2.256.1

package/plugins/src/base/scripts/automation-status-run-history.mjs

@@ -0,0 +1,185 @@
+#!/usr/bin/env node
+/**
+ * Shared read-only run-history projection for `/lisa:automation-status`.
+ *
+ * The durable run-outcome substrate (RBC-3, `automation-run-record.mjs`) stores
+ * one bounded JSONL file per registered loop under `.lisa/automations/runs/`.
+ * This module turns that substrate — plus the checked-in per-loop runbook
+ * (`automation-runbook-contract`) — into the per-item display fields both
+ * runtime adapters attach to their status rows, so the Codex and Claude
+ * adapters never diverge on how the contract, last outcome, and bounded history
+ * are rendered.
+ *
+ * STRICTLY READ-ONLY: it stats the runbook and reads the run-record file. It
+ * never creates the runs directory, a runbook, or a run record — a status read
+ * must leave the fleet byte-identical.
+ */
+
+import fs from "node:fs/promises";
+import path from "node:path";
+
+import {
+  automationRunRecordPath,
+  readAutomationRunRecords,
+} from "./automation-run-record.mjs";
+
+/**
+ * Inline history cap: the newest N outcomes are listed, the remainder is only
+ * counted. A bounded view of an already-bounded file, with the trim stated in
+ * the output rather than applied silently.
+ */
+export const AUTOMATION_RUN_HISTORY_DISPLAY_LIMIT = 5;
+
+/** The recorded outcome that signals a loop could not finish its own work. */
+export const RECOVERY_REQUIRED_OUTCOME = "recovery-required";
+
+/**
+ * How many trailing `recovery-required` runs in a row flip a loop to `FAILING`.
+ * The RBC-5 acceptance criteria pin "last three runs" as the escalation
+ * trigger; that wins over the ticket prose's looser "five in a row" pattern.
+ */
+export const RECOVERY_REQUIRED_ESCALATION_THRESHOLD = 3;
+
+const RUNBOOK_NOT_SCAFFOLDED_LINE =
+  "not scaffolded — run /lisa:setup-automations";
+const NO_RECORDED_RUNS_LINE = "no recorded runs yet";
+
+/**
+ * @typedef {{
+ *   readonly ts: string
+ *   readonly outcome: string
+ *   readonly summary: string
+ * }} AutomationLastOutcome
+ *
+ * @typedef {{
+ *   readonly runbook: string
+ *   readonly lastOutcome?: AutomationLastOutcome
+ *   readonly outcomeHistory: readonly string[]
+ *   readonly olderRecordCount: number
+ *   readonly recoveryRequiredStreak: number
+ *   readonly recoverySummaries: readonly string[]
+ *   readonly skippedCorruptLines: number
+ * }} AutomationRunDisplay
+ */
+
+/**
+ * Resolve the read-only run-history display fields for one registered loop.
+ *
+ * @param {{
+ *   readonly projectRoot?: string
+ *   readonly loopId: string
+ *   readonly runbookPath?: string
+ * }} input
+ * @returns {Promise<AutomationRunDisplay>}
+ */
+export async function resolveAutomationRunDisplay(input) {
+  const projectRoot = path.resolve(input.projectRoot ?? process.cwd());
+  const runbook = await resolveRunbookLine(projectRoot, input.runbookPath);
+  const { records, skippedCorruptLines } = await readAutomationRunRecords(
+    automationRunRecordPath(projectRoot, input.loopId)
+  );
+
+  const newestFirst = records.toReversed();
+  const latest = records.at(-1);
+  const lastOutcome = latest
+    ? { ts: latest.ts, outcome: latest.outcome, summary: latest.summary }
+    : undefined;
+  const outcomeHistory = newestFirst
+    .slice(0, AUTOMATION_RUN_HISTORY_DISPLAY_LIMIT)
+    .map(record => record.outcome);
+  const olderRecordCount = Math.max(
+    0,
+    records.length - AUTOMATION_RUN_HISTORY_DISPLAY_LIMIT
+  );
+  const trailingRecovery = collectTrailingRecoveryRuns(records);
+
+  return {
+    runbook,
+    lastOutcome,
+    outcomeHistory,
+    olderRecordCount,
+    recoveryRequiredStreak: trailingRecovery.length,
+    recoverySummaries: trailingRecovery.map(record => record.summary),
+    skippedCorruptLines,
+  };
+}
+
+/**
+ * Force a `FAILING` verdict when a loop has recorded three or more consecutive
+ * `recovery-required` runs — the fleet-health signal the scheduler surface
+ * cannot see on its own. Returns a run-signal-shaped escalation, or null when
+ * the streak is below the threshold.
+ *
+ * @param {AutomationRunDisplay | undefined} runDisplay
+ * @returns {{ readonly status: "FAILING", readonly summary: string, readonly remediation: string } | null}
+ */
+export function resolveRecoveryEscalation(runDisplay) {
+  if (
+    !runDisplay ||
+    runDisplay.recoveryRequiredStreak < RECOVERY_REQUIRED_ESCALATION_THRESHOLD
+  ) {
+    return null;
+  }
+
+  // Number the citations rather than joining on a delimiter: recorded summaries
+  // carry their own `;` and `.`, so a `; `-separated list is ambiguous. `(1) …
+  // (2) …` stays legible no matter what punctuation a summary contains.
+  const citations = runDisplay.recoverySummaries
+    .map((summary, index) => `(${index + 1}) ${summary}`)
+    .join(" ");
+  return {
+    status: "FAILING",
+    summary: `the last ${runDisplay.recoveryRequiredStreak} recorded runs all required recovery`,
+    remediation: `Repeated recovery-required runs — ${citations} Inspect the loop's runbook and the cited runs, fix the recurring failure, then let the next scheduled run confirm recovery.`,
+  };
+}
+
+/**
+ * @param {string} projectRoot
+ * @param {string | undefined} runbookPath
+ * @returns {Promise<string>}
+ */
+async function resolveRunbookLine(projectRoot, runbookPath) {
+  if (!runbookPath) {
+    return RUNBOOK_NOT_SCAFFOLDED_LINE;
+  }
+  const scaffolded = await runbookIsScaffolded(
+    path.join(projectRoot, runbookPath)
+  );
+  return scaffolded ? runbookPath : RUNBOOK_NOT_SCAFFOLDED_LINE;
+}
+
+/**
+ * Read-only existence check for a checked-in runbook. Any stat failure — the
+ * file is absent, unreadable, or not a regular file — degrades to "not
+ * scaffolded" so the status read never implies health it could not confirm and
+ * never throws mid-report.
+ *
+ * @param {string} runbookAbsolutePath
+ * @returns {Promise<boolean>}
+ */
+async function runbookIsScaffolded(runbookAbsolutePath) {
+  try {
+    const stat = await fs.stat(runbookAbsolutePath);
+    return stat.isFile();
+  } catch {
+    return false;
+  }
+}
+
+/**
+ * @param {readonly import("./automation-run-record.mjs").AutomationRunRecord[]} records
+ * @returns {readonly import("./automation-run-record.mjs").AutomationRunRecord[]} trailing recovery-required runs, newest first
+ */
+function collectTrailingRecoveryRuns(records) {
+  const trailing = [];
+  for (let index = records.length - 1; index >= 0; index -= 1) {
+    if (records[index].outcome !== RECOVERY_REQUIRED_OUTCOME) {
+      break;
+    }
+    trailing.push(records[index]);
+  }
+  return trailing;
+}
+
+export { RUNBOOK_NOT_SCAFFOLDED_LINE, NO_RECORDED_RUNS_LINE };

package/plugins/src/base/skills/lisa-automation-status/SKILL.md

@@ -53,8 +53,13 @@ For each expected automation, report:
 4. Any detected drift in name, cadence, command shape, or queue arguments.
 5. Any available recent-run health signal such as stale last-run timing or repeated failure status.
 6. A concise remediation hint when attention is needed.
+7. Where the loop's checked-in runbook lives (`automation-runbook-contract`), or `not scaffolded — run /lisa:setup-automations` when it is absent.
+8. How the last recorded run ended — its outcome, one-line summary, and timestamp — or `no recorded runs yet` when the loop has never recorded one.
+9. A bounded run history: the five most recent outcomes newest first, plus a count of how many older records exist when the file holds more.
 
-Emit an overall grouped fleet verdict such as `HEALTHY`, `ATTENTION_NEEDED`, or `PARTIAL_SUPPORT`, plus the runtime surface inspected.
+The last-run and history facts come from the durable run-outcome substrate recorded by each loop (the RBC-3 records under `.lisa/automations/runs/<loop-id>.jsonl`, read through `readAutomationRunRecords`). That directory is local scheduler state, not project knowledge — read it, never write it.
+
+Emit an overall grouped fleet verdict such as `HEALTHY`, `ATTENTION_NEEDED`, or `PARTIAL_SUPPORT`, plus the runtime surface inspected. **Repeated recovery is a fleet-health signal the scheduler cannot see**: when a loop's last three or more consecutive recorded runs are all `recovery-required`, report that loop `FAILING` — and therefore the overall verdict `ATTENTION_NEEDED` — even when its scheduler entry itself looks healthy, and point the remediation at the recorded run summaries.
 
 ## Operator usage
 
@@ -89,7 +94,7 @@ Status-specific remediation guidance:
 - `MISSING`: tell the operator which job is absent and recommend rerunning `/lisa:setup-automations` or recreating the missing job with the expected cadence and command.
 - `DRIFTED`: show the expected versus observed cadence/command mismatch and recommend aligning the scheduler entry with Lisa's current setup contract, usually by rerunning `/lisa:setup-automations`.
 - `STALE`: explain that the job exists but has not run recently enough for its cadence. Recommend inspecting the runtime's recent-run history or failure logs before changing queue state.
-- `FAILING`: surface the failure signal directly and recommend checking the latest runtime error plus the affected queue command (`/lisa:intake`, `/lisa:repair-intake`, or exploratory job) after the scheduler issue is resolved.
+- `FAILING`: surface the failure signal directly and recommend checking the latest runtime error plus the affected queue command (`/lisa:intake`, `/lisa:repair-intake`, or exploratory job) after the scheduler issue is resolved. A loop also reports `FAILING` when its last three or more consecutive recorded runs are all `recovery-required` — even with a healthy scheduler entry — in which case cite the recorded run summaries and point the operator at the loop's runbook.
 - `UNSUPPORTED`: explain why the job is intentionally absent and say that no remediation is required unless the project stack or runtime support changed.
 
 Render the report in grouped sections using the shared `scripts/automation-status-report.mjs` contract:
@@ -104,10 +109,13 @@ Generated at: <ISO timestamp>
 - <STATUS> <automation-id>: <summary>
   Expected: <cadence> -> <command>
   Observed: <what the runtime exposed>
+  Runbook: <.lisa/automations/<loop-id>.runbook.md, or "not scaffolded — run /lisa:setup-automations">
+  Last run: <outcome> — <summary> (<ts>), or "no recorded runs yet"
+  History: <outcome>, <outcome>, … (newest first); … and <N> older records
   Remediation: <next step when attention is needed>
 ```
 
-Keep observable runtime facts separate from remediation guidance so operators can distinguish drift, unsupported jobs, and actual failures quickly.
+The Runbook, Last run, and History lines are observable facts and sit between Observed and Remediation. Keep observable runtime facts separate from remediation guidance so operators can distinguish drift, unsupported jobs, and actual failures quickly.
 
 ## Rules
 

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

package/plugins/src/base/skills/lisa-jira-write-ticket/SKILL.md

@@ -35,7 +35,7 @@ Required fields (stop and ask if missing — do not invent values):
 | Priority | CREATE | Default to project default if unstated |
 | Acceptance criteria | Story, Task, Bug, Sub-task, Improvement | Gherkin — see Phase 3 |
 | Validation Journey | Runtime-behavior changes | Delegate to `/jira-add-journey` |
-| Target backend environment | Runtime-behavior changes | `dev` / `staging` / `prod`; recorded in description (Phase 3). Skip only for doc/config/type-only tickets. |
+| 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 | Tickets that touch authenticated surfaces | Name the account (or source — 1Password item, env var, seeded fixture) and role; recorded in description (Phase 3). Omit when sign-in is not required. |
 | Single-repo scope | Bug, Task, Sub-task, Improvement | These leaf work units MUST cover one repo only. If the work crosses repos, split it before creating. Epic / Spike / Story may span repos. |
 | Source Requirement | PRD-sourced tickets (`prd_source` provided) | `h2. Source Requirement` with PRD link + verbatim requirement quote(s) — see Phase 3; enforced at every level, sub-tasks included |
@@ -83,11 +83,14 @@ h2. Out of Scope
 [Explicit list of what this ticket does NOT cover. Forces scope discipline.]
 
 h2. Target Backend Environment
-[Required when the ticket changes runtime behavior. One of: dev / staging / prod.
- This is the environment QA/product reported against and the backend the
- implementer points their local stack at during verification before CI/CD.
- Backend-only tickets state the deployed env they target. Skip section
- entirely for doc-only, config-only, or type-only tickets.]
+[Required when the ticket 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 tickets.]
 
 h2. Sign-in Required
 [Include this section ONLY if the work touches authenticated surfaces.

package/plugins/src/base/skills/lisa-linear-validate-issue/SKILL.md

@@ -160,7 +160,7 @@ A **build-ready leaf work unit** that is not part of an Epic context stands alon
 
 #### S8 — Target Backend Environment
 
-When `runtime_behavior_change = true`, description 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 description 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/src/base/skills/lisa-linear-write-issue/SKILL.md

@@ -57,7 +57,7 @@ Required fields (stop and ask if missing — never invent values):
 | Priority | CREATE | Native Linear priority: 0=No priority, 1=Urgent, 2=High, 3=Medium, 4=Low |
 | Acceptance criteria | Story, Task, Bug, Sub-task, Improvement | Gherkin — see Phase 3 |
 | Validation Journey | Runtime-behavior changes | Delegate to `/linear-add-journey` |
-| Target backend environment | Runtime-behavior changes | `dev` / `staging` / `prod`; recorded in description (Phase 3). Skip only for doc/config/type-only items. |
+| 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 | Items that touch authenticated surfaces | Name the account (or source — 1Password item, env var, seeded fixture) and role; recorded in description. Omit when sign-in is not required. |
 | Single-repo scope | Bug, Task, Sub-task | These types MUST cover one repo only. If the work crosses repos, split it before creating. Epic / Spike / Story may span repos. |
 | 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. |
@@ -103,8 +103,14 @@ Linear descriptions are markdown (NOT Jira wiki markup — no `h2.` headings, us
 [Explicit list of what this item does NOT cover. Forces scope discipline.]
 
 ## Target Backend Environment
-[Required when the item changes runtime behavior. One of: dev / staging / prod.
- Skip section entirely for doc-only, config-only, or type-only items.]
+[Required when the item 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 items.]
 
 ## Sign-in Required
 [Include this section ONLY if the work touches authenticated surfaces.