@codyswann/lisa 2.129.7 → 2.130.0

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

@@ -43,6 +43,9 @@ fi
       "review":  "Code Review",
       "blocked": "Blocked",
       "done":    { "dev": "On Dev", "staging": "On Stg", "production": "Done" }
+    },
+    "labels": {
+      "human_needed": "Human Needed"
     }
   },
   "confluence": {
@@ -78,6 +81,7 @@ fi
         "ready":   "status:ready",
         "claimed": "status:in-progress",
         "blocked": "status:blocked",
+        "human_needed": "human-needed",
         "done":    { "dev": "status:on-dev", "staging": "status:on-stg", "production": "status:done" }
       },
       "prd": {
@@ -108,6 +112,7 @@ fi
         "claimed": "status:in-progress",
         "review":  "status:code-review",
         "blocked": "status:blocked",
+        "human_needed": "human-needed",
         "done":    { "dev": "status:on-dev", "staging": "status:on-stg", "production": "status:done" }
       },
       "prd": {
@@ -274,6 +279,26 @@ Every lifecycle skill operates on a fixed set of **roles** (`ready`, `claimed`,
 
 `blocked` is what every vendor agent flips to when triage finds unresolved ambiguities or the build path is blocked by something the agent can't resolve. Different from `claimed` because it explicitly signals "human attention required."
 
+#### Build markers (additive labels, not lifecycle roles)
+
+A **marker** is an additive label applied *alongside* a lifecycle role, not a state the item transitions *to*. Markers carry no rollup or transition semantics — they annotate an item that is already in some role. The build lifecycle defines one marker:
+
+| Marker | What it means | JIRA default | GitHub/Linear default |
+|---|---|---|---|
+| `human_needed` | Applied with `blocked` when the block genuinely requires something **no agent and no automated retry can supply** — credentials, access/permissions, a product or scoping decision, or required ticket quality only the human reporter can add. | `Human Needed` (label) | `human-needed` (label) |
+
+Resolution keys:
+
+- JIRA: `jira.labels.human_needed` (default `Human Needed`). Applied as a JIRA **label** — not a workflow status — because an item holds exactly one status but any number of labels. The `blocked` status still drives the lifecycle; `human_needed` is the additive marker on top of it.
+- GitHub: `github.labels.build.human_needed` (default `human-needed`). Added next to the `blocked` label.
+- Linear: `linear.labels.build.human_needed` (default `human-needed`). Added next to the `blocked` label.
+
+**When to apply it.** Apply `human_needed` only when a human must act before the item can move — the pre-flight gate failures that bounce a ticket back to its reporter (missing credentials, missing acceptance criteria / validation journey, missing parent/epic, an ambiguous product or scoping decision) are exactly this case.
+
+**When NOT to apply it.** Do **not** apply `human_needed` to a block that an automated cycle can clear on its own: a block whose `is blocked by` dependency is another tracked ticket that will build and close (for example a `repair-intake`-filed build-ready fix ticket for an unmergeable PR or a failed deploy), or any block waiting only on a retry. Those self-heal; flagging them for a human is noise. If such an item already carries a stale `human_needed` marker, clear it when the block becomes auto-recoverable.
+
+The marker is **best-effort and additive**: it never replaces the `blocked` role and never gates a transition. A project that does not define the label name inherits the defaults above; a project that does not want the marker at all can leave the label absent in its tracker, in which case the add is a no-op the agent records and moves on.
+
 **PRD lifecycle** (specifications):
 
 | Role | What it means | Notion default | Confluence/GitHub/Linear default |

package/plugins/lisa-copilot/scripts/plugin-sync-explain.mjs

@@ -528,6 +528,7 @@ function gitEnv(root) {
   const env = { ...process.env };
   delete env.GIT_DIR;
   delete env.GIT_WORK_TREE;
+  delete env.GIT_INDEX_FILE;
   if (root) {
     const gitDir = linkedWorktreeGitDir(root);
     if (gitDir) {

package/plugins/lisa-copilot/skills/repair-intake/SKILL.md

@@ -174,6 +174,11 @@ rule — never hardcode status/label strings. The relevant repair roles:
 | PRD | Linear | `linear.labels.prd.in_review` (`prd-in-review`) | `linear.labels.prd.blocked` (`prd-blocked`) | `linear.labels.prd.shipped` (`prd-shipped`) |
 | PRD | Confluence | `confluence.parents.in_review` (page id) | `confluence.parents.blocked` (page id) | `confluence.parents.shipped` (page id) |
 
+In addition to the lifecycle roles above, the build lifecycle defines the **`human_needed` marker** — an additive label (`jira.labels.human_needed` / `github.labels.build.human_needed` / `linear.labels.build.human_needed`, default `Human Needed` / `human-needed`) that rides alongside `blocked` when the block needs human-only input no agent or retry can supply (see `config-resolution` "Build markers"). repair-intake's interaction with the marker is asymmetric and is the whole point of the distinction below:
+
+- The blocks repair-intake **itself writes** are the auto-recoverable kind — it files a build-ready fix ticket and moves the item `blocked` *blocked by that ticket*, expecting the next cycle to self-heal. Those are **not** `human_needed`; if such an item arrives already carrying a stale `human_needed` marker, repair-intake **clears** it (the block is no longer waiting on a human).
+- The blocks the **vendor agent** writes when repair-intake re-dispatches it (its pre-flight gate) carry `human_needed` already — the agent owns that marker. repair-intake leaves it in place.
+
 Resolve with the standard role-read pattern (local overrides global, default fallback):
 
 ```bash
@@ -292,7 +297,12 @@ the vendor build-intake runs**, skipping the claim transition (the item is alrea
    unresolvable, fail loudly — never guess). repair-intake owns this transition because it is
    standing in for the scanner that never got to finish it.
 3. **On a surfaced blocker** (agent reports it cannot proceed), leave/move the item to `blocked`
-   with a `[lisa-repair-intake]` note (see Loop prevention).
+   with a `[lisa-repair-intake]` note (see Loop prevention). When the surfaced blocker is something
+   **only a human can supply** (credentials, access/permissions, a product or scoping decision), the
+   item also carries the `human_needed` marker — the vendor agent's pre-flight gate applies it; if
+   repair-intake makes the block transition itself for such a reason, it adds the marker too. (A
+   block that another tracked ticket or retry will clear is *not* human-needed — that is the
+   auto-recoverable fix-ticket path above.)
 
 > Do **not** reset stalled in-progress items to `ready`. Reset throws away state, makes a
 > partially-built item look freshly human-approved to the next `lisa:intake` claim, and forces a
@@ -364,7 +374,11 @@ recent check/commit activity would already have been caught as `active` by the s
    for "PR is mergeable / deploy is green."
 2. **Transition the stalled item `claimed → blocked`** and add an **`is blocked by`** link to the
    new fix ticket (vendor-native: JIRA issue link `is blocked by`; GitHub/Linear `Blocked by:` line
-   + label). Post a `[lisa-repair-intake]` note naming what it is blocked by and why.
+   + label). Post a `[lisa-repair-intake]` note naming what it is blocked by and why. This block is
+   **auto-recoverable** — the fix ticket will build and close on its own — so do **not** add the
+   `human_needed` marker, and if the item already carries a stale `human_needed` label, remove it
+   here (it is no longer waiting on a human). The `human_needed` marker is reserved for blocks a
+   human must clear; this one a later cycle clears automatically.
 3. **Record it** as a repair write. Do **not** dispatch the vendor agent for this item this cycle.
 
 The item now sits in `blocked`; once the fix ticket reaches a terminal state, the **Build
@@ -614,6 +628,10 @@ It MAY:
 
 - Apply the build scanner's post-agent `claimed → done` on a successful resume (it is finishing
   the scanner's interrupted job), and move a dependency-cleared build item `blocked → claimed`.
+- Manage the `human_needed` marker on build blocks: leave it where the vendor agent set it (a
+  human-only pre-flight block), and **clear** it from an item it moves to an auto-recoverable
+  `blocked` (blocked by a build-ready fix ticket) — that block self-heals and is not waiting on a
+  human.
 - Move a re-validated PRD `in_review`/`blocked → ticketed` (PASS) or `→ blocked` (FAIL), exactly
   as the PRD intake does.
 - Close / complete / resolve build items that already carry the true terminal `done` role but are

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cursor/agents/github-agent.md

@@ -49,15 +49,17 @@ Use the `github-verify` skill to check the issue against organizational standard
 
 **Gating behavior — this is the one place auto-relabeling is allowed:**
 
-Resolve build labels from `.lisa.config.json` `github.labels.build.*` (defaults: `status:ready` / `status:in-progress` / env-keyed `status:on-*`); resolve the `blocked` label from the same section (`github.labels.build.blocked`, default `status:blocked`).
+Resolve build labels from `.lisa.config.json` `github.labels.build.*` (defaults: `status:ready` / `status:in-progress` / env-keyed `status:on-*`); resolve the `blocked` label from the same section (`github.labels.build.blocked`, default `status:blocked`) and the `human_needed` marker label from the same section (`github.labels.build.human_needed`, default `human-needed`).
 
 If `github-verify` returns `FAIL` on any of the above, do NOT continue:
 
-1. Relabel: remove the `claimed` label, add the `blocked` label.
+1. Relabel: remove the `claimed` label, add the `blocked` label **and** the `human_needed` marker label. A pre-flight gate failure bounces the issue back to its author precisely because it needs something **no agent and no automated retry can supply** — credentials, access, a product/scoping decision, or required issue quality only the human can add — 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
    CLAIMED=$(jq -r '.github.labels.build.claimed // "status:in-progress"' .lisa.config.json)
    BLOCKED=$(jq -r '.github.labels.build.blocked // "status:blocked"' .lisa.config.json)
-   gh issue edit <num> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$BLOCKED"
+   HUMAN_NEEDED=$(jq -r '.github.labels.build.human_needed // "human-needed"' .lisa.config.json)
+   gh label create "$HUMAN_NEEDED" --color D93F0B --description "Blocked on human-only input (credentials / access / decision)" --repo <org>/<repo> 2>/dev/null || true
+   gh issue edit <num> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$BLOCKED" --add-label "$HUMAN_NEEDED"
    ```
 2. Reassign the issue back to its **author** (the original reporter — `author.login` from `gh issue view --json author`). Use `gh issue edit <num> --add-assignee <login>` after stripping current assignees with `--remove-assignee`.
 3. Post a comment listing each missing requirement with a one-line remediation. Prefix with `[<repo>]`:
@@ -141,7 +143,7 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 
 ## Rules
 
-- Never auto-relabel build labels, with one explicit exception: when `github-verify` returns FAIL for the pre-flight gate (Step 2), relabel to the configured `blocked` label and reassign to the original author. The build-intake owner transitions a successful issue from `claimed` directly to the configured `done` label after PR evidence is posted.
+- Never auto-relabel build labels, with one explicit exception: when `github-verify` returns FAIL for the pre-flight gate (Step 2), relabel to the configured `blocked` label, add the configured `human_needed` marker label (`github.labels.build.human_needed`, default `human-needed`), and reassign to the original author. The build-intake owner transitions a successful issue from `claimed` directly to the configured `done` label after PR evidence is posted.
 - Always read the full issue graph via `github-read-issue` before determining intent — don't rely on the `type:` label alone.
 - 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.

package/plugins/lisa-cursor/agents/jira-agent.md

@@ -49,9 +49,10 @@ Use the `jira-verify` skill to check the ticket against organizational standards
 
 If `jira-verify` returns `FAIL` on any of the above, do NOT continue:
 1. 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.
-2. Reassign the ticket to the **Reporter** (the human who filed it — not the Creator field, which may be a bot/integration).
-3. Post a comment using `mcp__atlassian__addCommentToJiraIssue` listing each missing requirement with a one-line remediation. Prefix with `[{repo}]`.
-4. Stop. Do not run triage, do not delegate to a flow, do not start work.
+2. **Add the `human_needed` marker label.** A pre-flight gate failure bounces the ticket back to its reporter precisely because it needs something **no agent and no automated retry can supply** — credentials, access, a product/scoping decision, or required ticket quality only the human can add. 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.)
+3. Reassign the ticket to the **Reporter** (the human who filed it — not the Creator field, which may be a bot/integration).
+4. Post a comment using `mcp__atlassian__addCommentToJiraIssue` listing each missing requirement with a one-line remediation. Prefix with `[{repo}]`.
+5. Stop. Do not run triage, do not delegate to a flow, do not start work.
 
 **Exception — single-repo scope is split, not blocked.** A single-repo-scope FAIL is the one gate failure the agent fixes rather than bounces to the reporter: a cross-repo work unit is a decomposition error the agent owns (S10 is `product_relevant: false`), not a product question. Instead of blocking, run the **work-time split procedure** in the `repo-scope-split` rule — narrow this ticket to one repo, create a sibling per additional repo cloning its metadata, link the producer→consumer dependency (`Blocks` / `is blocked by`), comment on the original, then re-run `jira-verify` on the original and every new sibling. Block (per the path above) only if the split is ambiguous (see "When to block instead of split"). If single-repo scope was the only FAIL and the split succeeded, proceed to Step 3 once every resulting ticket passes.
 
@@ -122,7 +123,7 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 
 ## Rules
 
-- Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
+- Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status, add the configured `human_needed` marker label (`jira.labels.human_needed`, default `Human Needed`), and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
 - Always read the full ticket graph via `jira-read-ticket` before determining intent — don't rely on ticket type alone
 - 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.

package/plugins/lisa-cursor/agents/linear-agent.md

@@ -47,10 +47,10 @@ Use the `linear-verify` skill to check the item against organizational standards
 
 **Gating behavior — this is the one place auto-transitioning is allowed:**
 
-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`).
+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:
-1. Update labels via `mcp__linear-server__save_issue`: remove the current build label, add the configured `blocked` label. (Create the `blocked` label via `create_issue_label` if needed.)
+1. Update labels via `mcp__linear-server__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.) A pre-flight gate failure bounces the item back to its creator precisely because it needs something **no agent and no automated retry can supply** — credentials, access, a product/scoping decision, or required item quality only the human can add — 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.)
 2. Reassign the item to the **Issue creator** (the human who filed it — Linear's `creator` field).
 3. Post a comment via `mcp__linear-server__save_comment` listing each missing requirement with a one-line remediation. Prefix with `[{repo}]`.
 4. Stop. Do not run triage, do not delegate to a flow, do not start work.
@@ -127,8 +127,8 @@ The label transitions ARE the canonical signal. The native `state` field stays a
 
 ## Rules
 
-- Never auto-transition the native Linear `state`, with one explicit exception: when `linear-verify` returns `FAIL` for the pre-flight gate (Step 2), update labels to the configured `blocked` label and reassign to the creator. Every other status change remains a label-driven suggestion.
+- Never auto-transition the native Linear `state`, with one explicit exception: when `linear-verify` returns `FAIL` for the pre-flight gate (Step 2), update labels to the configured `blocked` label, add the configured `human_needed` marker label (`linear.labels.build.human_needed`, default `human-needed`), and reassign to the creator. Every other status change remains a label-driven suggestion.
 - Always read the full item graph via `linear-read-issue` before determining intent — don't rely on type labels alone.
-- 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 `mcp__linear-server__save_issue` and `mcp__linear-server__save_comment` directly to set `status:blocked` and reassign to the creator — this narrow exception is already granted by the rule above; (2) the Step 3 triage path may call `mcp__linear-server__save_comment` to post triage findings and `mcp__linear-server__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`.
+- 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 `mcp__linear-server__save_issue` and `mcp__linear-server__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 `mcp__linear-server__save_comment` to post triage findings and `mcp__linear-server__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.

package/plugins/lisa-cursor/rules/config-resolution-reference.mdc

@@ -48,6 +48,9 @@ fi
       "review":  "Code Review",
       "blocked": "Blocked",
       "done":    { "dev": "On Dev", "staging": "On Stg", "production": "Done" }
+    },
+    "labels": {
+      "human_needed": "Human Needed"
     }
   },
   "confluence": {
@@ -83,6 +86,7 @@ fi
         "ready":   "status:ready",
         "claimed": "status:in-progress",
         "blocked": "status:blocked",
+        "human_needed": "human-needed",
         "done":    { "dev": "status:on-dev", "staging": "status:on-stg", "production": "status:done" }
       },
       "prd": {
@@ -113,6 +117,7 @@ fi
         "claimed": "status:in-progress",
         "review":  "status:code-review",
         "blocked": "status:blocked",
+        "human_needed": "human-needed",
         "done":    { "dev": "status:on-dev", "staging": "status:on-stg", "production": "status:done" }
       },
       "prd": {
@@ -279,6 +284,26 @@ Every lifecycle skill operates on a fixed set of **roles** (`ready`, `claimed`,
 
 `blocked` is what every vendor agent flips to when triage finds unresolved ambiguities or the build path is blocked by something the agent can't resolve. Different from `claimed` because it explicitly signals "human attention required."
 
+#### Build markers (additive labels, not lifecycle roles)
+
+A **marker** is an additive label applied *alongside* a lifecycle role, not a state the item transitions *to*. Markers carry no rollup or transition semantics — they annotate an item that is already in some role. The build lifecycle defines one marker:
+
+| Marker | What it means | JIRA default | GitHub/Linear default |
+|---|---|---|---|
+| `human_needed` | Applied with `blocked` when the block genuinely requires something **no agent and no automated retry can supply** — credentials, access/permissions, a product or scoping decision, or required ticket quality only the human reporter can add. | `Human Needed` (label) | `human-needed` (label) |
+
+Resolution keys:
+
+- JIRA: `jira.labels.human_needed` (default `Human Needed`). Applied as a JIRA **label** — not a workflow status — because an item holds exactly one status but any number of labels. The `blocked` status still drives the lifecycle; `human_needed` is the additive marker on top of it.
+- GitHub: `github.labels.build.human_needed` (default `human-needed`). Added next to the `blocked` label.
+- Linear: `linear.labels.build.human_needed` (default `human-needed`). Added next to the `blocked` label.
+
+**When to apply it.** Apply `human_needed` only when a human must act before the item can move — the pre-flight gate failures that bounce a ticket back to its reporter (missing credentials, missing acceptance criteria / validation journey, missing parent/epic, an ambiguous product or scoping decision) are exactly this case.
+
+**When NOT to apply it.** Do **not** apply `human_needed` to a block that an automated cycle can clear on its own: a block whose `is blocked by` dependency is another tracked ticket that will build and close (for example a `repair-intake`-filed build-ready fix ticket for an unmergeable PR or a failed deploy), or any block waiting only on a retry. Those self-heal; flagging them for a human is noise. If such an item already carries a stale `human_needed` marker, clear it when the block becomes auto-recoverable.
+
+The marker is **best-effort and additive**: it never replaces the `blocked` role and never gates a transition. A project that does not define the label name inherits the defaults above; a project that does not want the marker at all can leave the label absent in its tracker, in which case the add is a no-op the agent records and moves on.
+
 **PRD lifecycle** (specifications):
 
 | Role | What it means | Notion default | Confluence/GitHub/Linear default |

package/plugins/lisa-cursor/scripts/plugin-sync-explain.mjs

@@ -528,6 +528,7 @@ function gitEnv(root) {
   const env = { ...process.env };
   delete env.GIT_DIR;
   delete env.GIT_WORK_TREE;
+  delete env.GIT_INDEX_FILE;
   if (root) {
     const gitDir = linkedWorktreeGitDir(root);
     if (gitDir) {

package/plugins/lisa-cursor/skills/repair-intake/SKILL.md

@@ -174,6 +174,11 @@ rule — never hardcode status/label strings. The relevant repair roles:
 | PRD | Linear | `linear.labels.prd.in_review` (`prd-in-review`) | `linear.labels.prd.blocked` (`prd-blocked`) | `linear.labels.prd.shipped` (`prd-shipped`) |
 | PRD | Confluence | `confluence.parents.in_review` (page id) | `confluence.parents.blocked` (page id) | `confluence.parents.shipped` (page id) |
 
+In addition to the lifecycle roles above, the build lifecycle defines the **`human_needed` marker** — an additive label (`jira.labels.human_needed` / `github.labels.build.human_needed` / `linear.labels.build.human_needed`, default `Human Needed` / `human-needed`) that rides alongside `blocked` when the block needs human-only input no agent or retry can supply (see `config-resolution` "Build markers"). repair-intake's interaction with the marker is asymmetric and is the whole point of the distinction below:
+
+- The blocks repair-intake **itself writes** are the auto-recoverable kind — it files a build-ready fix ticket and moves the item `blocked` *blocked by that ticket*, expecting the next cycle to self-heal. Those are **not** `human_needed`; if such an item arrives already carrying a stale `human_needed` marker, repair-intake **clears** it (the block is no longer waiting on a human).
+- The blocks the **vendor agent** writes when repair-intake re-dispatches it (its pre-flight gate) carry `human_needed` already — the agent owns that marker. repair-intake leaves it in place.
+
 Resolve with the standard role-read pattern (local overrides global, default fallback):
 
 ```bash
@@ -292,7 +297,12 @@ the vendor build-intake runs**, skipping the claim transition (the item is alrea
    unresolvable, fail loudly — never guess). repair-intake owns this transition because it is
    standing in for the scanner that never got to finish it.
 3. **On a surfaced blocker** (agent reports it cannot proceed), leave/move the item to `blocked`
-   with a `[lisa-repair-intake]` note (see Loop prevention).
+   with a `[lisa-repair-intake]` note (see Loop prevention). When the surfaced blocker is something
+   **only a human can supply** (credentials, access/permissions, a product or scoping decision), the
+   item also carries the `human_needed` marker — the vendor agent's pre-flight gate applies it; if
+   repair-intake makes the block transition itself for such a reason, it adds the marker too. (A
+   block that another tracked ticket or retry will clear is *not* human-needed — that is the
+   auto-recoverable fix-ticket path above.)
 
 > Do **not** reset stalled in-progress items to `ready`. Reset throws away state, makes a
 > partially-built item look freshly human-approved to the next `lisa:intake` claim, and forces a
@@ -364,7 +374,11 @@ recent check/commit activity would already have been caught as `active` by the s
    for "PR is mergeable / deploy is green."
 2. **Transition the stalled item `claimed → blocked`** and add an **`is blocked by`** link to the
    new fix ticket (vendor-native: JIRA issue link `is blocked by`; GitHub/Linear `Blocked by:` line
-   + label). Post a `[lisa-repair-intake]` note naming what it is blocked by and why.
+   + label). Post a `[lisa-repair-intake]` note naming what it is blocked by and why. This block is
+   **auto-recoverable** — the fix ticket will build and close on its own — so do **not** add the
+   `human_needed` marker, and if the item already carries a stale `human_needed` label, remove it
+   here (it is no longer waiting on a human). The `human_needed` marker is reserved for blocks a
+   human must clear; this one a later cycle clears automatically.
 3. **Record it** as a repair write. Do **not** dispatch the vendor agent for this item this cycle.
 
 The item now sits in `blocked`; once the fix ticket reaches a terminal state, the **Build
@@ -614,6 +628,10 @@ It MAY:
 
 - Apply the build scanner's post-agent `claimed → done` on a successful resume (it is finishing
   the scanner's interrupted job), and move a dependency-cleared build item `blocked → claimed`.
+- Manage the `human_needed` marker on build blocks: leave it where the vendor agent set it (a
+  human-only pre-flight block), and **clear** it from an item it moves to an auto-recoverable
+  `blocked` (blocked by a build-ready fix ticket) — that block self-heals and is not waiting on a
+  human.
 - Move a re-validated PRD `in_review`/`blocked → ticketed` (PASS) or `→ blocked` (FAIL), exactly
   as the PRD intake does.
 - Close / complete / resolve build items that already carry the true terminal `done` role but are

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.129.7",
+  "version": "2.130.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.129.7",
+  "version": "2.130.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": "2.129.7",
+  "version": "2.130.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": "2.129.7",
+  "version": "2.130.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": "2.129.7",
+  "version": "2.130.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": "2.129.7",
+  "version": "2.130.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"