@codyswann/lisa 4.54.13 → 4.55.0

package/plugins/lisa-rails-cursor/rules/rails-conventions.mdc

@@ -1,181 +1,28 @@
 ---
-description: "Rails Coding Conventions"
+description: "Rails Coding Conventions (load-bearing)"
 alwaysApply: true
 ---
 
-# Rails Coding Conventions
-
-This rule enforces Rails-specific coding standards for consistency, maintainability, and performance.
-
-## Fat Models, Skinny Controllers
-
-Controllers handle HTTP concerns only. Business logic belongs in models or service objects.
-
-```ruby
-# Correct — controller delegates to model
-class OrdersController < ApplicationController
-  def create
-    @order = Order.place(order_params, current_user)
-    redirect_to @order
-  end
-end
-
-# Wrong — business logic in controller
-class OrdersController < ApplicationController
-  def create
-    @order = Order.new(order_params)
-    @order.user = current_user
-    @order.total = @order.line_items.sum(&:price)
-    @order.apply_discount(current_user.discount_rate)
-    @order.save!
-    OrderMailer.confirmation(@order).deliver_later
-    redirect_to @order
-  end
-end
-```
-
-## Service Objects
-
-Extract complex business logic into service objects when a model method would be too large or spans multiple models.
-
-```ruby
-# app/services/order_placement_service.rb
-class OrderPlacementService
-  def initialize(user:, params:)
-    @user = user
-    @params = params
-  end
-
-  def call
-    order = Order.new(@params)
-    order.user = @user
-    order.calculate_total
-    order.save!
-    OrderMailer.confirmation(order).deliver_later
-    order
-  end
-end
-```
-
-## Concerns
-
-Use concerns to share behavior across models or controllers. Keep concerns focused on a single responsibility.
-
-```ruby
-# app/models/concerns/searchable.rb
-module Searchable
-  extend ActiveSupport::Concern
-
-  included do
-    scope :search, ->(query) { where("name ILIKE ?", "%#{query}%") }
-  end
-end
-```
-
-## ActiveRecord Patterns
-
-### Scopes over class methods for chainable queries
-
-```ruby
-# Correct — scope
-scope :active, -> { where(active: true) }
-scope :recent, -> { order(created_at: :desc) }
-
-# Wrong — class method for simple query
-def self.active
-  where(active: true)
-end
-```
-
-### Validations
-
-```ruby
-# Use built-in validators
-validates :email, presence: true, uniqueness: true, format: { with: URI::MailTo::EMAIL_REGEXP }
-validates :age, numericality: { greater_than: 0 }
-```
-
-### Callbacks — use sparingly
-
-Prefer explicit service objects over callbacks for complex side effects. Callbacks are acceptable for simple data normalization.
-
-```ruby
-# Acceptable — simple normalization
-before_validation :normalize_email
-
-private
-
-def normalize_email
-  self.email = email&.downcase&.strip
-end
-```
-
-## N+1 Query Prevention
-
-Always use `includes`, `preload`, or `eager_load` to prevent N+1 queries. The Bullet gem is included to detect these in development.
-
-```ruby
-# Correct — eager loading
-@posts = Post.includes(:author, :comments).where(published: true)
-
-# Wrong — N+1 query
-@posts = Post.where(published: true)
-@posts.each { |post| post.author.name } # N+1!
-```
-
-## Strong Parameters
-
-Always use strong parameters in controllers. Never use `permit!`.
-
-```ruby
-# Correct
-def order_params
-  params.require(:order).permit(:product_id, :quantity, :notes)
-end
-
-# Wrong — permits everything
-def order_params
-  params.require(:order).permit!
-end
-```
-
-## Database Migrations
-
-- Use `strong_migrations` gem constraints (included via Gemfile.lisa)
-- Never modify `db/schema.rb` directly
-- Always add indexes for foreign keys and commonly queried columns
-- Use `change` method when the migration is reversible; use `up`/`down` when it is not
-
-```ruby
-class AddIndexToOrdersUserId < ActiveRecord::Migration[7.2]
-  def change
-    add_index :orders, :user_id
-  end
-end
-```
-
-## Testing with RSpec
-
-- Use `let` and `let!` for test setup
-- Use `described_class` instead of repeating the class name
-- Use `factory_bot` for test data, not fixtures
-- Use `shoulda-matchers` for model validation tests
-- Keep tests focused — one assertion concept per example
-
-```ruby
-RSpec.describe Order, type: :model do
-  describe "validations" do
-    it { is_expected.to validate_presence_of(:user) }
-    it { is_expected.to validate_numericality_of(:total).is_greater_than(0) }
-  end
-
-  describe ".recent" do
-    it "returns orders in descending creation order" do
-      old_order = create(:order, created_at: 1.day.ago)
-      new_order = create(:order, created_at: 1.hour.ago)
-
-      expect(described_class.recent).to eq([new_order, old_order])
-    end
-  end
-end
-```
+# Rails Coding Conventions (load-bearing)
+
+Rails-specific standards for this project. The head below is what changes
+behaviour in a session that never asks for it; the worked examples for every
+point live in the reference body.
+
+## Mandatory
+
+1. **Fat models, skinny controllers.** Controllers handle HTTP concerns only.
+   Business logic belongs in a model or a service object under `app/services/`.
+2. **Strong parameters always, `permit!` never.** Enumerate the permitted keys.
+3. **No N+1 queries.** Use `includes` / `preload` / `eager_load` on any
+   association you iterate. Bullet is installed to catch the ones you miss.
+4. **Never edit `db/schema.rb` by hand.** Change it through a migration, honour
+   the `strong_migrations` constraints, and index every foreign key and
+   commonly-queried column.
+5. **Scopes, not class methods,** for chainable queries. Prefer built-in
+   validators; keep callbacks to simple normalization and push complex side
+   effects into a service object.
+6. **RSpec with `factory_bot` and `shoulda-matchers`,** not fixtures. Use
+   `described_class` and keep one assertion concept per example.
+
+Full prose and Ruby examples: [reference/rails-conventions.md](rails-conventions-reference.mdc).

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.54.13",
+  "version": "4.55.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/materialized-artifacts.json

@@ -8,6 +8,7 @@
   "all/copy-overwrite/scripts/lisa-hooks/block-managed-file-edits.sh",
   "all/copy-overwrite/scripts/lisa-hooks/block-no-verify.sh",
   "all/copy-overwrite/scripts/lisa-hooks/block-shell-json-parsing.sh",
+  "all/copy-overwrite/scripts/lisa-hooks/guard-dedupe.bash",
   "all/copy-overwrite/scripts/lisa-hooks/parity-safety-net-heredoc.py",
   "all/copy-overwrite/scripts/lisa-hooks/parity-safety-net.sh",
   "all/copy-overwrite/scripts/lisa-hooks/sonar-secrets.sh",

package/plugins/src/base/.claude-plugin/plugin.json

@@ -108,6 +108,15 @@
           }
         ]
       },
+      {
+        "matcher": "Bash|Edit|Write|Read|Task|Grep|Glob",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/operational-hazards.sh --hook"
+          }
+        ]
+      },
       {
         "matcher": "EnterWorktree",
         "hooks": [
@@ -258,6 +267,15 @@
           }
         ]
       },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/operational-hazards.sh --session-start"
+          }
+        ]
+      },
       {
         "matcher": "",
         "hooks": [
@@ -331,6 +349,15 @@
           }
         ]
       },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/operational-hazards.sh --session-start"
+          }
+        ]
+      },
       {
         "matcher": "",
         "hooks": [

package/plugins/src/base/agents/linear-prd-intake.md

@@ -1,6 +1,6 @@
 ---
 name: linear-prd-intake
-description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims projects carrying the configured `ready` PRD label (relabels to the configured `in_review` label), validates each through the dry-run pipeline, and routes to the configured `blocked` label (with clarifying comments on a sentinel feedback issue) or `ticketed` label (with destination tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
+description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims projects carrying the configured `ready` PRD label (relabels to the configured `in_review` label), validates each through the dry-run pipeline, and routes to the configured `blocked` label (with clarifying comments on the project) or `ticketed` label (with destination tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
 skills:
   - linear-prd-intake
   - linear-to-tracker
@@ -15,9 +15,9 @@ skills:
 
 You are a PRD intake agent. Your single job is to run one intake cycle against the Linear scope (a workspace or a team) given to you, then report what happened.
 
-This agent is the Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. The behavior is identical apart from the source-of-truth tool surface and one structural difference (clarifying comments land on a sentinel feedback issue under each project, not on the project page itself, because Linear's MCP doesn't expose project-level comments). If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent.
+This agent is the Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. The behavior is identical apart from the source-of-truth tool surface: clarifying comments land on the project itself, exactly as they do on a Notion or Confluence page. (They used to land on a fabricated per-project "sentinel" issue, justified by the Linear MCP not exposing project-level comments. That premise was wrong about the substrate — `commentCreate(input: { projectId, body })` and `Project.comments` have always existed, and the access layer's precedence contract puts GraphQL ahead of the MCP. The gap was in the wrapper, and it is closed; see "Legacy sentinel feedback issues" in the skill for what happens to the ones already created.) If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent.
 
-PRD label role names (`ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `verified`, `sentinel`) are resolved from `.lisa.config.json` `linear.labels.prd.*` by the `linear-prd-intake` skill. The defaults match the legacy hardcoded names (`prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped`, `prd-verified`, `prd-intake-feedback`). The full PRD lifecycle is `draft → ready → in_review → blocked | ticketed → shipped → verified`; this agent only ever drives `ready → in_review → blocked | ticketed`. The `shipped` rollup is owned by the intake skill's rollup phase, and `verified` is set by `/lisa:verify-prd` after empirical PRD-level acceptance — never by this agent.
+PRD label role names (`ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `verified`, and the legacy read-only `sentinel`) are resolved from `.lisa.config.json` `linear.labels.prd.*` by the `linear-prd-intake` skill. The defaults match the legacy hardcoded names (`prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped`, `prd-verified`, `prd-intake-feedback`). The full PRD lifecycle is `draft → ready → in_review → blocked | ticketed → shipped → verified`; this agent only ever drives `ready → in_review → blocked | ticketed`. The `shipped` rollup is owned by the intake skill's rollup phase, and `verified` is set by `/lisa:verify-prd` after empirical PRD-level acceptance — never by this agent.
 
 ## Confirmation policy
 
@@ -29,11 +29,11 @@ Once you have a workspace or team scope, RUN. Do not ask the caller whether to p
 
 The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a Linear workspace URL, a team URL, a bare team key, or the literal token `linear` (which falls back to `linear.workspace` in `.lisa.config.json`). You do not pick the scope yourself.
 
-If no scope is provided, stop and ask. Never run intake against a default or guessed scope — the side effects (label changes, sentinel-issue creation, JIRA tickets created) are too high to act without an explicit target.
+If no scope is provided, stop and ask. Never run intake against a default or guessed scope — the side effects (label changes, project comments, JIRA tickets created) are too high to act without an explicit target.
 
 ### 2. Run the intake skill
 
-Invoke the `linear-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, sentinel feedback issue management, summary. Do not duplicate that logic here.
+Invoke the `linear-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, summary. Do not duplicate that logic here.
 
 Treat the skill's output as the source of truth (e.g. `ticketed: 3 / blocked: 1 / errors: 0`).
 
@@ -49,7 +49,7 @@ If the cycle errored before processing any PRDs (e.g. workspace unreachable, mis
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any PRDs ended in the `blocked` label, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the sentinel feedback issue (and on specific sub-issues for anchored failures) are the channel; the caller decides whether to ping anyone.
+After a successful cycle, if any PRDs ended in the `blocked` label, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the project (and on specific sub-issues for anchored failures) are the channel; the caller decides whether to ping anyone.
 
 When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
@@ -60,7 +60,7 @@ If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that
 - **Never run a cycle without an explicit scope.** Side effects are too high to default.
 - **Never modify the lifecycle**: only `ready → in_review → blocked|ticketed`. Never touch the `draft`, `shipped`, or `verified` labels (`shipped` is owned by the intake rollup phase; `verified` is owned by `/lisa:verify-prd`). Never invent new labels.
 - **Never write destination tickets directly.** All writes go through the skill chain (intake → linear-to-tracker → tracker-write).
-- **Never edit a project's description or any attached Linear document.** Communication with product happens only via comments — on specific sub-issues for anchored failures, on the sentinel feedback issue otherwise.
-- **Never close, archive, or repurpose the sentinel feedback issue.** It is reused across cycles; its longevity is the audit trail.
+- **Never edit a project's description or any attached Linear document.** Communication with product happens only via comments — on specific sub-issues for anchored failures, on the project itself otherwise.
+- **Never fabricate an issue to hold a comment.** The project takes comments directly. Legacy sentinel issues from earlier cycles are left exactly as they are — not closed, not archived, not repurposed, not posted to — and the rollup excludes them so they stop holding their projects open.
 - **Never start a second cycle while one is in flight against the same scope.** Serial execution; the scheduling layer is responsible for not double-firing.
 - **Stop and surface failures rather than retry-loop.** If `linear-to-tracker` returns an error, the skill records it under `Errors` in the summary; pass that through.

package/plugins/src/base/hooks/block-blind-automerge.sh

@@ -162,6 +162,27 @@ set -euo pipefail
 
 input="$(cat)"
 
+# Evaluate once per tool call when this guard is registered on both channels.
+#
+# Lisa reaches an agent through the repository dispatcher AND the plugin
+# manifest, and where both are live the harness runs this guard twice for one
+# tool call. `guard-dedupe.bash` short-circuits the second run ONLY when a
+# byte-identical copy already ALLOWED this exact payload on this exact tool
+# call; a differing vintage, a refusal, and a host with one channel all
+# evaluate exactly as before. Nothing is de-registered by it
+# (CodySwannGT/lisa#3814).
+#
+# Absent library means no dedupe, which is the pre-existing behaviour, so an
+# older channel copy that predates it is unaffected.
+lisa_guard_hook_dir="${BASH_SOURCE[0]%/*}"
+lisa_guard_dedupe_lib="$lisa_guard_hook_dir/guard-dedupe.bash"
+if [ -r "$lisa_guard_dedupe_lib" ]; then
+  # shellcheck source=guard-dedupe.bash
+  . "$lisa_guard_dedupe_lib"
+  trap 'lisa_guard_dedupe_record $?' EXIT
+  lisa_guard_dedupe block-blind-automerge "$input"
+fi
+
 # Both interpreters are probed BEFORE use, and a missing one is ANNOUNCED
 # rather than swallowed. Under `set -e` an absent jq would abort with 127, and
 # Claude Code treats any non-2 exit as a non-blocking hook error — so the guard
@@ -244,9 +265,41 @@ PULL_REQUEST_ID_PATTERN = re.compile(
 NODE_ID_PATTERN = re.compile(r"^[A-Za-z0-9_=-]+$")
 
 # The probe that resolves a node id to the same fields `gh pr view` returns.
+#
+# `statusCheckRollup` is in here because the RE-TARGET path needs it and this
+# is the only probe a GraphQL `updatePullRequest` can use. Without it
+# `failing_check_names` read an absent key, found no failing check, and the
+# guard announced the re-target as the sanctioned green-PR batching case —
+# for a pull request that might be failing every check it has. The porcelain
+# path asked the right question and the API path could not, so the identical
+# act was guarded through `gh pr edit --base` and waved through as GraphQL:
+# a bypass that needs no permission, only a different spelling.
+#
+# The nodes are reshaped by `--jq` below into the flat list `gh pr view
+# --json statusCheckRollup` returns, so one reader serves both probes.
 NODE_QUERY = (
     "query($id:ID!){node(id:$id){... on PullRequest"
-    "{number url reviewDecision state baseRefName}}}"
+    "{number url reviewDecision state baseRefName "
+    "commits(last:1){nodes{commit{statusCheckRollup{contexts(first:100){nodes{"
+    "__typename ... on CheckRun{name conclusion} "
+    "... on StatusContext{context state}"
+    "}}}}}}}}}"
+)
+
+# Reshape the envelope into the porcelain's shape: unwrap `.data.node`, hoist
+# the last commit's rollup contexts to a top-level `statusCheckRollup` list,
+# and drop the `commits` scaffolding that carried it.
+# `has("commits")` rather than an unconditional default, and the distinction is
+# the point: a node that CARRIES the scaffolding and no contexts is a PR with no
+# checks, which is genuinely not failing and gets an empty list. A node without
+# the scaffolding is a probe that never asked, and it must leave the key absent
+# so the re-target path can tell the two apart instead of reading both as green.
+NODE_JQ = (
+    "if .data.node == null then null else .data.node as $n "
+    "| if ($n | has(\"commits\")) then ($n | del(.commits)) "
+    "+ {statusCheckRollup: "
+    "((($n.commits.nodes[0].commit.statusCheckRollup.contexts.nodes)) // [])} "
+    "else $n end end"
 )
 
 # What a probe spec asks for. `view` and `node` differ only in how the PR is
@@ -725,7 +778,7 @@ def probe_args(kind, subject, repo_args, fields):
             "gh", "api", "graphql",
             "-f", "query=" + NODE_QUERY,
             "-f", "id=" + subject,
-            "--jq", ".data.node",
+            "--jq", NODE_JQ,
         ]
     args = ["gh", "pr", "view"]
     if subject is not None:
@@ -966,6 +1019,20 @@ Do one of these instead:
   - leave the PR on its covered base and merge it there.
 """
 
+RETARGET_CHECKS_UNREADABLE = """Blocked: re-targeting %s onto "%s" cannot be judged, because this guard could
+not read the pull request's checks.
+
+That ref has ZERO required status checks, so the one thing standing between the
+move and a permission-free gate bypass is whether the PR is currently failing —
+and the probe returned no `statusCheckRollup` at all. An absent rollup is not an
+empty one. Reporting the move as the sanctioned green-PR batching case here
+would be a verdict about a question that was never asked.
+
+Re-target through `gh pr edit --base` instead, which reads the checks, or fix
+the probe. Do not report the PR as batched until something has actually looked.
+"""
+
+
 UNCOVERED_RETARGET_NOTICE = (
     "block-blind-automerge: %s is being re-targeted onto \"%s\", a ref with ZERO "
     "required status checks; its gates will run but cannot block a merge\n"
@@ -1036,6 +1103,18 @@ for act, kind, subject, repo_args, target_ref in acts:
         # nothing can block it", which holds whatever base it came from.
         if not base_is_uncovered(payload, repo_args, target_ref):
             continue
+        # Fails CLOSED, and only here. Everywhere else in this file an
+        # unanswerable question degrades and continues, because the guard being
+        # unable to run must not become the reason a command is refused. This
+        # branch is different: the base has already been confirmed to have zero
+        # required checks, so an empty `failing` list is the whole basis for
+        # allowing the move, and an ABSENT rollup produces the identical empty
+        # list. Passing on it would be a measurement that could not fail.
+        if not isinstance(payload.get("statusCheckRollup"), list):
+            sys.stderr.write(
+                RETARGET_CHECKS_UNREADABLE % (pr_name(payload), target_ref)
+            )
+            sys.exit(1)
         failing = failing_check_names(payload)
         if not failing:
             # A green PR moving onto a stack base is the sanctioned batching

package/plugins/src/base/hooks/block-direct-issue-create.agy.sh

@@ -8,19 +8,44 @@
 # block-direct-issue-create.sh beside it (same delegation pattern as
 # block-instruction-file-edits.agy.sh).
 #
-# SCOPE GAP, recorded rather than silently dropped (AGENTS.md). This used to
-# read "no scope gap here: the canonical guard is Bash-only by construction, and
-# `run_command` is exactly the surface it needs." That stopped being true in
-# CodySwannGT/lisa#3753: the canonical guard now covers a SECOND substrate —
-# structured tool payloads, where a creation arrives as named fields rather than
-# as a command line — because the filing contract was enforced on the shell and
-# unenforced on every tool call beside it.
+# THE SECOND SUBSTRATE (CodySwannGT/lisa#3785). CodySwannGT/lisa#3753 taught the
+# canonical guard that a creation also arrives as NAMED FIELDS rather than as a
+# command line. This adapter used to forward `run_command` and nothing else, and
+# the registration matched `run_command` only, so on agy that substrate was
+# unenforced — refused entry twice over, exactly as it was on Claude before
+# CodySwannGT/lisa#3753. Widening one without the other changes nothing.
 #
-# This adapter forwards `run_command` and nothing else, so on agy that second
-# substrate is still uncovered. Closing it needs agy's own tool-call envelope
-# (which tool names its creation surface, and where the arguments land), and
-# that is a different piece of work from translating one protocol. The shell
-# surface agy does expose receives the whole guard, exactly as before.
+# agy's envelope was CAPTURED, not guessed — a probe plugin registered with an
+# empty matcher, driven through `agy --dangerously-skip-permissions -p`, on
+# agy 1.1.3:
+#
+#   {"toolCall":{"name":"call_mcp_tool","args":{
+#      "ServerName":"probe-tracker","ToolName":"create_issue",
+#      "Arguments":{"title":"envelope probe","body":"capture"},
+#      "toolAction":"...","toolSummary":"..."}}}
+#
+# Two things about it decide the translation below, and both would have been got
+# wrong by a plausible guess:
+#
+#   - EVERY MCP call arrives under the single tool name `call_mcp_tool`. The
+#     server and tool the model actually asked for live in `ServerName` /
+#     `ToolName`, so forwarding agy's outer name verbatim hands the canonical
+#     guard a name carrying no tracker noun, and its shape gate ALLOWS the lot.
+#     Measured before this change: forwarding `call_mcp_tool` raw ALLOWED an
+#     undeclared `create_issue`. So the adapter reassembles the name into the
+#     `mcp__<server>__<tool>` spelling the canonical guard already classifies on
+#     Claude — one vocabulary, one classifier.
+#   - The arguments land under `Arguments`, not inline beside the metadata, so
+#     `toolAction` / `toolSummary` — agy's own prose about the call — stay OUT
+#     of the payload the declaration is read from. Passing them would let a
+#     summary sentence mentioning the ready role answer for the filing.
+#
+# Every other tool is forwarded generically (`{tool_name, tool_input}`) rather
+# than allowed here. The canonical guard owns the question of what counts as a
+# creation; an adapter that pre-filtered would be a second copy of that policy,
+# and the first native creation tool agy adds would arrive on the wrong side of
+# it. The cost is one extra `bash` + `jq` per non-shell tool call, which is what
+# the canonical guard's subprocess-free shape gate exists to keep cheap.
 #
 # Fail-open on missing runtimes: a missed refusal costs one under-declared
 # ticket, and `lisa-repair-intake` already sweeps for exactly that. Failing
@@ -47,15 +72,38 @@ input="$(cat 2>/dev/null || true)"
 command -v jq >/dev/null 2>&1 || allow
 
 tool_name="$(printf '%s' "$input" | jq -r '.toolCall.name // empty' 2>/dev/null || true)"
-[ "$tool_name" != "run_command" ] && allow
-command_str="$(printf '%s' "$input" | jq -r '.toolCall.args.CommandLine // empty' 2>/dev/null || true)"
-[ -z "$command_str" ] && allow
+[ -z "$tool_name" ] && allow
+
+canonical_input=""
+if [ "$tool_name" = "run_command" ]; then
+  # The shell substrate, byte-identical to what it was before the second
+  # substrate arrived. Its verdicts are the control for this change.
+  command_str="$(printf '%s' "$input" | jq -r '.toolCall.args.CommandLine // empty' 2>/dev/null || true)"
+  [ -z "$command_str" ] && allow
+  canonical_input="$(jq -cn --arg command "$command_str" '{tool_name:"Bash",tool_input:{command:$command}}')"
+elif [ "$tool_name" = "call_mcp_tool" ]; then
+  # A missing ServerName or ToolName is a payload this adapter cannot name, and
+  # naming is the whole of its job here. It hands the canonical guard the
+  # unspellable name rather than inventing a plausible one, so the guard's own
+  # fail-closed arm decides — never this adapter.
+  canonical_input="$(
+    printf '%s' "$input" |
+      jq -c '(.toolCall.args // {}) as $a
+        | {tool_name: ("mcp__" + ($a.ServerName // "?") + "__" + ($a.ToolName // "?")),
+           tool_input: ($a.Arguments // {})}' 2>/dev/null || true
+  )"
+else
+  canonical_input="$(
+    printf '%s' "$input" |
+      jq -c '{tool_name: .toolCall.name, tool_input: (.toolCall.args // {})}' 2>/dev/null || true
+  )"
+fi
+[ -z "$canonical_input" ] && allow
 
 hook_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 canonical_hook="$hook_dir/block-direct-issue-create.sh"
 [ -r "$canonical_hook" ] || allow
 
-canonical_input="$(jq -cn --arg command "$command_str" '{tool_name:"Bash",tool_input:{command:$command}}')"
 canonical_output=""
 canonical_status=0
 if canonical_output="$(printf '%s' "$canonical_input" | /bin/bash "$canonical_hook" 2>&1)"; then