@codyswann/lisa 4.33.6 → 4.33.8

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

@@ -1005,28 +1005,40 @@ is no normalized `is blocked by` field. Read the bundle, then extract blockers p
 - **Linear**: inspect the native issue **relations** from Linear MCP `get_issue` and select
   blocker relations.
 
-Then classify each blocker:
-
-- **Closed, or shipped to any environment** → **cleared**. A blocker is cleared at **any**
-  env-staged `done` role — not only the production terminal. The `done` role is configured
-  per-env as a `{dev, staging, production}` map (`config-resolution`), so `On Dev`, `On Stg`,
-  **and** production `Done` all mean the blocker's code is merged and deployed to ≥1 environment.
-  A post-build `review` role (e.g. `Code Review`) is likewise cleared — the change exists and is
-  in flight. An `is blocked by` link is a **development** dependency: it is satisfied once the
-  blocker's code is in trunk; it must NOT wait for the blocker to reach production. (This matches
-  the intake-path dependency-hold gate in `lisa-intake-explain`, which already treats
-  `code-review` / `on-dev` / `on-stg` / `done` as cleared — repair-intake must not be stricter.
-  In an env-staged workflow where `Done` means "in production", a strict production-terminal
-  check strands every dependent forever behind a blocker that is already merged and sitting at
-  `On Stg` / `On Dev`.)
-- **Open** in a pre-merge role (`ready` / `claimed` / unknown — code not yet in trunk) → **still
-  blocking**.
-- **Inaccessible** (deleted, cross-org, permission denied) → **still blocking**, unless the item
-  body or a newer human comment explicitly states the dependency is resolved.
+Then classify each blocker **by containment, per the `blocker-containment` rule** — cite that
+slug for the full contract; do not restate its resolution steps or its fail-closed table here.
+
+The one question is whether the blocker's code is on the branch **this item** will be built from:
+resolve this item's base branch from its `## Target Backend Environment` through
+`.lisa.config.json` `deploy.branches` (`derived-branch-plan`, `config-resolution` — never by
+reading a rendered `Branch Plan`), resolve the blocker's merge commit through the vendor access
+layer, and test ancestry against the remote.
+
+- **Contained** — every merged PR on the blocker is an ancestor of this item's base branch →
+  **cleared**.
+- **Not contained**, or containment **not computable** for any reason the rule enumerates (no
+  linked PR, PR not merged, blocker inaccessible, base branch underivable or absent from the
+  remote, ancestry query errored) → **still blocking**, with the rule's reason key in the run
+  record.
+- **Ships no code** — the blocker is closed as completed, positively declares
+  `Target Backend Environment: None — no runtime behavior change`, and has no merged PR →
+  **cleared** under the rule's carve-out. This is a positive determination, never an absence:
+  "no PR found" is `no-pr` and stays blocking.
+- **Human override** — an explicit human statement on this item that the dependency is satisfied
+  clears it and outranks a failed containment check. Name it in the run record.
+
+**A lifecycle status name is never the test.** `done`, `on-stg`, `on-dev` and `code-review` are
+labels that correlate with containment in a single-trunk workflow and come apart from it in a
+promotion workflow, where `main` is the trailing branch — a blocker at `On Stg` is on `staging`
+and absent from `main`, and a blocker in `Code Review` is merged to nothing. Containment gets
+both the loose and the strict failure right at once: a blocker merged into the branch this item
+builds from clears **immediately**, with no wait for production, so a dependent is never stranded
+behind work already merged where it needs it.
 
 Only re-dispatch when **every** parsed blocker is cleared. When in doubt, stay blocked — a
-false-negative (left blocked) is cheap; a false-positive (re-dispatched into a real blocker)
-wastes a build cycle.
+false-negative (left blocked) costs one cycle and is visible; a false-positive is **invisible**,
+because the item moves to `ready`, which looks exactly like a repair that worked, and the failure
+surfaces days later as work begun before its dependency existed.
 
 ### Class B — validation / quality-gate self-block
 

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

@@ -46,7 +46,7 @@ If relevant code IS found, proceed to Phase 2.
 
 From the context bundle, evaluate relationships before analyzing this ticket in isolation:
 
-- **Open blockers (`is blocked by`)**: if any blocker is not `Done` or its linked PR is not merged, raise an ambiguity: "Blocker {KEY} is not shipped — work cannot meaningfully start." This is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
+- **Open blockers (`is blocked by`)**: clear-check each blocker **by containment, per the `blocker-containment` rule** — cite that slug for the full contract rather than restating it. A blocker is satisfied when its merged PRs are ancestors of the branch this ticket will be built from (resolved from this ticket's `## Target Backend Environment` through `.lisa.config.json` `deploy.branches`, never from a rendered `Branch Plan`), or when the rule's narrow no-code carve-out or human override applies. **`Done` is not the test** — a state name holds in a single-trunk workflow and comes apart in a promotion workflow, and requiring the production terminal strands every dependent behind work already merged where this ticket needs it. This is the same predicate the `DUPLICATE_ALREADY_FIXED` bullet below already requires ("present on the relevant base branch… never from a name/label match alone"), applied here too. For a blocker that is not contained, or where containment is not computable, raise an ambiguity naming the rule's reason key: "Blocker {KEY} is not on {BRANCH} ({REASON}) — work cannot meaningfully start." That is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
 - **Epic siblings in progress**: if a sibling under the same epic is `In Progress` / `In Review` with a different assignee and overlapping scope, raise it as an edge case in Phase 4 ("Duplicate-work risk with {KEY}").
 - **`duplicates` / `is duplicated by` links**:
   - If this ticket is a duplicate of an open canonical ticket whose fix is not yet merged into the base branch, verdict is `BLOCKED` with the recommendation to close as duplicate manually rather than implement.

package/typescript/copy-overwrite/.github/GITHUB_ACTIONS.md

@@ -45,6 +45,8 @@ For full functionality, configure the following secrets:
 |--------|---------|--------------|
 | `EXPO_TOKEN` | EAS builds and updates | Mobile deployment |
 | `SENTRY_AUTH_TOKEN` | Error tracking | Release monitoring |
+| `SENTRY_ORG` | Sentry organization slug | Release monitoring |
+| `SENTRY_PROJECT` | Sentry project slug | Release monitoring |
 | `SONAR_TOKEN` | Code quality analysis | Security scanning |
 | `SNYK_TOKEN` | Vulnerability scanning | Security scanning |
 
@@ -535,8 +537,6 @@ Variables are non-sensitive configuration values. Set them in **Settings** > **S
 | `JIRA_BASE_URL` | Jira instance base URL (enables Jira triage workflow) | `https://company.atlassian.net` |
 | `JIRA_USER_EMAIL` | Email associated with the Jira API token | `user@company.com` |
 | `JIRA_PROJECT_KEY` | Jira project key for ticket queries | `PROJ` |
-| `SENTRY_ORG` | Sentry organization slug | `my-company` |
-| `SENTRY_PROJECT` | Sentry project slug | `frontend-app` |
 
 ## External Service Setup
 

package/typescript/deletions.json

@@ -52,5 +52,12 @@
     ".github/workflows/reusable-claude-nightly-test-improvement-rails.yml",
     ".github/workflows/required-checks-drift.yml"
   ],
-  "keep": []
+  "keep": [],
+  "force": {
+    ".github/workflows/auto-update-pr-branches.yml": "Removed fleet-wide (CodySwannGT/lisa#3590): it force-updated PR branches with the workflow's own github.token, and GitHub will not start runs from such a push, so required checks went ABSENT at head and pull requests silently stopped becoming mergeable. An edited copy does the same damage, so this removal overrides workflow ownership.",
+    ".github/workflows/auto-update-pr-branches-dispatch.yml": "Removed fleet-wide (CodySwannGT/lisa#3590): it force-updated PR branches with the workflow's own github.token, and GitHub will not start runs from such a push, so required checks went ABSENT at head and pull requests silently stopped becoming mergeable. An edited copy does the same damage, so this removal overrides workflow ownership.",
+    ".github/workflows/reusable-auto-update-pr-branches.yml": "Removed fleet-wide (CodySwannGT/lisa#3590): it force-updated PR branches with the workflow's own github.token, and GitHub will not start runs from such a push, so required checks went ABSENT at head and pull requests silently stopped becoming mergeable. An edited copy does the same damage, so this removal overrides workflow ownership.",
+    ".github/workflows/reusable-auto-update-pr-branches-dispatch.yml": "Removed fleet-wide (CodySwannGT/lisa#3590): it force-updated PR branches with the workflow's own github.token, and GitHub will not start runs from such a push, so required checks went ABSENT at head and pull requests silently stopped becoming mergeable. An edited copy does the same damage, so this removal overrides workflow ownership.",
+    ".github/workflows/required-checks-drift.yml": "Removed fleet-wide (CodySwannGT/lisa#3599): it read the live ruleset over the GitHub API, which needs administration:read and therefore a personal access token held in a permanent repository secret. An edited copy still asks for that token, so this removal overrides workflow ownership."
+  }
 }