@codyswann/lisa 2.187.1 → 2.187.2

package/package.json

@@ -93,7 +93,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

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

@@ -369,7 +369,7 @@ documented defaults, so existing projects need no config change.
 
 | Key | Required | Default | Notes |
 |-----|----------|---------|-------|
-| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
+| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may sit after its last state-changing transition into the in-progress role, or after the last human / PR-side forward-progress activity, before repair-intake treats it as stalled and resumes it. Automation self-comments and Lisa audit notes do not reset this clock. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
 | `intake.repair.maxCandidates` | no | `100` | Upper bound on how many stuck items repair-intake enumerates while searching for the first actionable one. Bounds scan cost. Overridable per-run via `max_candidates=<n>`. |
 
 ### Monitor audit config (`monitor`)

package/plugins/lisa/scripts/automation-status-expected-fleet.mjs

@@ -263,9 +263,10 @@ function resolveRepairQueueArgument(config, source, tracker) {
     return "github intake_mode=both";
   }
 
-  throw new Error(
-    `Unable to resolve a single repair-intake queue for tracker=${String(tracker)} and source=${String(source)} without guessing.`
-  );
+  const buildQueue = resolveBuildQueueArgument(config, tracker);
+  return buildQueue.includes("intake_mode=")
+    ? buildQueue
+    : `${buildQueue} intake_mode=build`;
 }
 
 /**

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

@@ -80,7 +80,7 @@ lifecycle state with provider-native closure and rollup state.
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
+| `stale_after` | How long since the last state-changing transition into the in-progress role, or since the last human / PR-side forward-progress activity, before an in-progress item counts as stalled. Automation self-comments do not reset this clock. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -228,9 +228,19 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa:at
 
 ## Staleness model
 
-An in-progress item (build `claimed`, PRD `in_review`) is **stalled** only if it shows no
-observable activity newer than the `stale_after` threshold. `blocked` items are NOT gated on
-staleness — their repairability is judged on current blocker/answer state, not elapsed time.
+An in-progress item (build `claimed`, PRD `in_review`) is **stalled** when the last
+state-changing transition into the in-progress role, or the last human / PR-side forward-progress
+activity after that transition, is older than the `stale_after` threshold. `blocked` items are NOT
+gated on staleness — their repairability is judged on current blocker/answer state, not elapsed
+time.
+
+Automation self-comments are not forward progress and must not reset the staleness clock. Status
+comments like `[claude-build-intake] PR remains open...`, `[codex-build-intake] Follow-up pushed...`,
+or `[lisa-repair-intake] ...` may be useful audit notes, but they cannot make a claimed item fresh
+forever. If a provider exposes a changelog/history surface, prefer the timestamp of the last
+transition into the claimed/In-Progress role over the item's generic `updated` timestamp. When the
+history surface is unavailable, ignore comments whose author/marker clearly belongs to Lisa or its
+automation agents, and use the newest human comment/edit or PR-side progress event instead.
 
 A build `claimed` leaf whose linked PR has **already merged** (`state == MERGED`) is likewise NOT
 gated on staleness. A merged PR is a settled terminal state, not in-flight work: the only thing
@@ -254,17 +264,24 @@ decision tree step 0, and the dedicated high-confidence ordering bucket).
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
 
-### Activity signal (most-recent-wins, portable across vendors)
+### Activity signal (state-change first, portable across vendors)
 
-Compute the item's newest activity timestamp from the highest-priority signal the vendor
+Compute the item's newest eligible activity timestamp from the highest-priority signal the vendor
 exposes, and compare it to `now - stale_after`:
 
-1. Provider-native item `updatedAt` / `last_edited_time` / `updated`.
-2. Latest lifecycle/progress **comment** on the item (and, for Linear PRDs, the sentinel
-   feedback issue).
-3. For build items, latest **PR activity** on the linked PR: newest commit, review, check-run,
+1. Provider-native status/label **transition** time into the in-progress role, when the provider
+   exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
+   Linear state/label history, Notion/Confluence page move/status history).
+2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
+   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+   `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
+   `[lisa-repair-intake]`.
+3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
+   review, check-run,
    or PR comment.
-4. Status/label **transition** time, when the provider exposes it cleanly.
+4. Provider-native item `updatedAt` / `last_edited_time` / `updated` only when the provider cannot
+   expose transition/comment authorship and the timestamp is not known to be driven by automation
+   self-comments.
 
 If ANY of these is newer than the threshold, the item is **active** → record it as `active` and
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/scripts/automation-status-expected-fleet.mjs

@@ -263,9 +263,10 @@ function resolveRepairQueueArgument(config, source, tracker) {
     return "github intake_mode=both";
   }
 
-  throw new Error(
-    `Unable to resolve a single repair-intake queue for tracker=${String(tracker)} and source=${String(source)} without guessing.`
-  );
+  const buildQueue = resolveBuildQueueArgument(config, tracker);
+  return buildQueue.includes("intake_mode=")
+    ? buildQueue
+    : `${buildQueue} intake_mode=build`;
 }
 
 /**

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

@@ -80,7 +80,7 @@ lifecycle state with provider-native closure and rollup state.
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
+| `stale_after` | How long since the last state-changing transition into the in-progress role, or since the last human / PR-side forward-progress activity, before an in-progress item counts as stalled. Automation self-comments do not reset this clock. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -228,9 +228,19 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa:at
 
 ## Staleness model
 
-An in-progress item (build `claimed`, PRD `in_review`) is **stalled** only if it shows no
-observable activity newer than the `stale_after` threshold. `blocked` items are NOT gated on
-staleness — their repairability is judged on current blocker/answer state, not elapsed time.
+An in-progress item (build `claimed`, PRD `in_review`) is **stalled** when the last
+state-changing transition into the in-progress role, or the last human / PR-side forward-progress
+activity after that transition, is older than the `stale_after` threshold. `blocked` items are NOT
+gated on staleness — their repairability is judged on current blocker/answer state, not elapsed
+time.
+
+Automation self-comments are not forward progress and must not reset the staleness clock. Status
+comments like `[claude-build-intake] PR remains open...`, `[codex-build-intake] Follow-up pushed...`,
+or `[lisa-repair-intake] ...` may be useful audit notes, but they cannot make a claimed item fresh
+forever. If a provider exposes a changelog/history surface, prefer the timestamp of the last
+transition into the claimed/In-Progress role over the item's generic `updated` timestamp. When the
+history surface is unavailable, ignore comments whose author/marker clearly belongs to Lisa or its
+automation agents, and use the newest human comment/edit or PR-side progress event instead.
 
 A build `claimed` leaf whose linked PR has **already merged** (`state == MERGED`) is likewise NOT
 gated on staleness. A merged PR is a settled terminal state, not in-flight work: the only thing
@@ -254,17 +264,24 @@ decision tree step 0, and the dedicated high-confidence ordering bucket).
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
 
-### Activity signal (most-recent-wins, portable across vendors)
+### Activity signal (state-change first, portable across vendors)
 
-Compute the item's newest activity timestamp from the highest-priority signal the vendor
+Compute the item's newest eligible activity timestamp from the highest-priority signal the vendor
 exposes, and compare it to `now - stale_after`:
 
-1. Provider-native item `updatedAt` / `last_edited_time` / `updated`.
-2. Latest lifecycle/progress **comment** on the item (and, for Linear PRDs, the sentinel
-   feedback issue).
-3. For build items, latest **PR activity** on the linked PR: newest commit, review, check-run,
+1. Provider-native status/label **transition** time into the in-progress role, when the provider
+   exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
+   Linear state/label history, Notion/Confluence page move/status history).
+2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
+   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+   `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
+   `[lisa-repair-intake]`.
+3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
+   review, check-run,
    or PR comment.
-4. Status/label **transition** time, when the provider exposes it cleanly.
+4. Provider-native item `updatedAt` / `last_edited_time` / `updated` only when the provider cannot
+   expose transition/comment authorship and the timestamp is not known to be driven by automation
+   self-comments.
 
 If ANY of these is newer than the threshold, the item is **active** → record it as `active` and
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -369,7 +369,7 @@ documented defaults, so existing projects need no config change.
 
 | Key | Required | Default | Notes |
 |-----|----------|---------|-------|
-| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
+| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may sit after its last state-changing transition into the in-progress role, or after the last human / PR-side forward-progress activity, before repair-intake treats it as stalled and resumes it. Automation self-comments and Lisa audit notes do not reset this clock. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
 | `intake.repair.maxCandidates` | no | `100` | Upper bound on how many stuck items repair-intake enumerates while searching for the first actionable one. Bounds scan cost. Overridable per-run via `max_candidates=<n>`. |
 
 ### Monitor audit config (`monitor`)

package/plugins/lisa-copilot/scripts/automation-status-expected-fleet.mjs

@@ -263,9 +263,10 @@ function resolveRepairQueueArgument(config, source, tracker) {
     return "github intake_mode=both";
   }
 
-  throw new Error(
-    `Unable to resolve a single repair-intake queue for tracker=${String(tracker)} and source=${String(source)} without guessing.`
-  );
+  const buildQueue = resolveBuildQueueArgument(config, tracker);
+  return buildQueue.includes("intake_mode=")
+    ? buildQueue
+    : `${buildQueue} intake_mode=build`;
 }
 
 /**

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

@@ -80,7 +80,7 @@ lifecycle state with provider-native closure and rollup state.
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
+| `stale_after` | How long since the last state-changing transition into the in-progress role, or since the last human / PR-side forward-progress activity, before an in-progress item counts as stalled. Automation self-comments do not reset this clock. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -228,9 +228,19 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa:at
 
 ## Staleness model
 
-An in-progress item (build `claimed`, PRD `in_review`) is **stalled** only if it shows no
-observable activity newer than the `stale_after` threshold. `blocked` items are NOT gated on
-staleness — their repairability is judged on current blocker/answer state, not elapsed time.
+An in-progress item (build `claimed`, PRD `in_review`) is **stalled** when the last
+state-changing transition into the in-progress role, or the last human / PR-side forward-progress
+activity after that transition, is older than the `stale_after` threshold. `blocked` items are NOT
+gated on staleness — their repairability is judged on current blocker/answer state, not elapsed
+time.
+
+Automation self-comments are not forward progress and must not reset the staleness clock. Status
+comments like `[claude-build-intake] PR remains open...`, `[codex-build-intake] Follow-up pushed...`,
+or `[lisa-repair-intake] ...` may be useful audit notes, but they cannot make a claimed item fresh
+forever. If a provider exposes a changelog/history surface, prefer the timestamp of the last
+transition into the claimed/In-Progress role over the item's generic `updated` timestamp. When the
+history surface is unavailable, ignore comments whose author/marker clearly belongs to Lisa or its
+automation agents, and use the newest human comment/edit or PR-side progress event instead.
 
 A build `claimed` leaf whose linked PR has **already merged** (`state == MERGED`) is likewise NOT
 gated on staleness. A merged PR is a settled terminal state, not in-flight work: the only thing
@@ -254,17 +264,24 @@ decision tree step 0, and the dedicated high-confidence ordering bucket).
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
 
-### Activity signal (most-recent-wins, portable across vendors)
+### Activity signal (state-change first, portable across vendors)
 
-Compute the item's newest activity timestamp from the highest-priority signal the vendor
+Compute the item's newest eligible activity timestamp from the highest-priority signal the vendor
 exposes, and compare it to `now - stale_after`:
 
-1. Provider-native item `updatedAt` / `last_edited_time` / `updated`.
-2. Latest lifecycle/progress **comment** on the item (and, for Linear PRDs, the sentinel
-   feedback issue).
-3. For build items, latest **PR activity** on the linked PR: newest commit, review, check-run,
+1. Provider-native status/label **transition** time into the in-progress role, when the provider
+   exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
+   Linear state/label history, Notion/Confluence page move/status history).
+2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
+   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+   `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
+   `[lisa-repair-intake]`.
+3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
+   review, check-run,
    or PR comment.
-4. Status/label **transition** time, when the provider exposes it cleanly.
+4. Provider-native item `updatedAt` / `last_edited_time` / `updated` only when the provider cannot
+   expose transition/comment authorship and the timestamp is not known to be driven by automation
+   self-comments.
 
 If ANY of these is newer than the threshold, the item is **active** → record it as `active` and
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For

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

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

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

@@ -374,7 +374,7 @@ documented defaults, so existing projects need no config change.
 
 | Key | Required | Default | Notes |
 |-----|----------|---------|-------|
-| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
+| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may sit after its last state-changing transition into the in-progress role, or after the last human / PR-side forward-progress activity, before repair-intake treats it as stalled and resumes it. Automation self-comments and Lisa audit notes do not reset this clock. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
 | `intake.repair.maxCandidates` | no | `100` | Upper bound on how many stuck items repair-intake enumerates while searching for the first actionable one. Bounds scan cost. Overridable per-run via `max_candidates=<n>`. |
 
 ### Monitor audit config (`monitor`)

package/plugins/lisa-cursor/scripts/automation-status-expected-fleet.mjs

@@ -263,9 +263,10 @@ function resolveRepairQueueArgument(config, source, tracker) {
     return "github intake_mode=both";
   }
 
-  throw new Error(
-    `Unable to resolve a single repair-intake queue for tracker=${String(tracker)} and source=${String(source)} without guessing.`
-  );
+  const buildQueue = resolveBuildQueueArgument(config, tracker);
+  return buildQueue.includes("intake_mode=")
+    ? buildQueue
+    : `${buildQueue} intake_mode=build`;
 }
 
 /**

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

@@ -80,7 +80,7 @@ lifecycle state with provider-native closure and rollup state.
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
+| `stale_after` | How long since the last state-changing transition into the in-progress role, or since the last human / PR-side forward-progress activity, before an in-progress item counts as stalled. Automation self-comments do not reset this clock. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -228,9 +228,19 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa:at
 
 ## Staleness model
 
-An in-progress item (build `claimed`, PRD `in_review`) is **stalled** only if it shows no
-observable activity newer than the `stale_after` threshold. `blocked` items are NOT gated on
-staleness — their repairability is judged on current blocker/answer state, not elapsed time.
+An in-progress item (build `claimed`, PRD `in_review`) is **stalled** when the last
+state-changing transition into the in-progress role, or the last human / PR-side forward-progress
+activity after that transition, is older than the `stale_after` threshold. `blocked` items are NOT
+gated on staleness — their repairability is judged on current blocker/answer state, not elapsed
+time.
+
+Automation self-comments are not forward progress and must not reset the staleness clock. Status
+comments like `[claude-build-intake] PR remains open...`, `[codex-build-intake] Follow-up pushed...`,
+or `[lisa-repair-intake] ...` may be useful audit notes, but they cannot make a claimed item fresh
+forever. If a provider exposes a changelog/history surface, prefer the timestamp of the last
+transition into the claimed/In-Progress role over the item's generic `updated` timestamp. When the
+history surface is unavailable, ignore comments whose author/marker clearly belongs to Lisa or its
+automation agents, and use the newest human comment/edit or PR-side progress event instead.
 
 A build `claimed` leaf whose linked PR has **already merged** (`state == MERGED`) is likewise NOT
 gated on staleness. A merged PR is a settled terminal state, not in-flight work: the only thing
@@ -254,17 +264,24 @@ decision tree step 0, and the dedicated high-confidence ordering bucket).
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
 
-### Activity signal (most-recent-wins, portable across vendors)
+### Activity signal (state-change first, portable across vendors)
 
-Compute the item's newest activity timestamp from the highest-priority signal the vendor
+Compute the item's newest eligible activity timestamp from the highest-priority signal the vendor
 exposes, and compare it to `now - stale_after`:
 
-1. Provider-native item `updatedAt` / `last_edited_time` / `updated`.
-2. Latest lifecycle/progress **comment** on the item (and, for Linear PRDs, the sentinel
-   feedback issue).
-3. For build items, latest **PR activity** on the linked PR: newest commit, review, check-run,
+1. Provider-native status/label **transition** time into the in-progress role, when the provider
+   exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
+   Linear state/label history, Notion/Confluence page move/status history).
+2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
+   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+   `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
+   `[lisa-repair-intake]`.
+3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
+   review, check-run,
    or PR comment.
-4. Status/label **transition** time, when the provider exposes it cleanly.
+4. Provider-native item `updatedAt` / `last_edited_time` / `updated` only when the provider cannot
+   expose transition/comment authorship and the timestamp is not known to be driven by automation
+   self-comments.
 
 If ANY of these is newer than the threshold, the item is **active** → record it as `active` and
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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-phaser/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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.187.1",
+  "version": "2.187.2",
   "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": "2.187.1",
+  "version": "2.187.2",
   "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": "2.187.1",
+  "version": "2.187.2",
   "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": "2.187.1",
+  "version": "2.187.2",
   "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": "2.187.1",
+  "version": "2.187.2",
   "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": "2.187.1",
+  "version": "2.187.2",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/reference/config-resolution.md

@@ -369,7 +369,7 @@ documented defaults, so existing projects need no config change.
 
 | Key | Required | Default | Notes |
 |-----|----------|---------|-------|
-| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
+| `intake.repair.staleAfterHours` | no | `2` | How long an in-progress item (build `claimed`, PRD `in_review`) may sit after its last state-changing transition into the in-progress role, or after the last human / PR-side forward-progress activity, before repair-intake treats it as stalled and resumes it. Automation self-comments and Lisa audit notes do not reset this clock. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
 | `intake.repair.maxCandidates` | no | `100` | Upper bound on how many stuck items repair-intake enumerates while searching for the first actionable one. Bounds scan cost. Overridable per-run via `max_candidates=<n>`. |
 
 ### Monitor audit config (`monitor`)

package/plugins/src/base/scripts/automation-status-expected-fleet.mjs

@@ -263,9 +263,10 @@ function resolveRepairQueueArgument(config, source, tracker) {
     return "github intake_mode=both";
   }
 
-  throw new Error(
-    `Unable to resolve a single repair-intake queue for tracker=${String(tracker)} and source=${String(source)} without guessing.`
-  );
+  const buildQueue = resolveBuildQueueArgument(config, tracker);
+  return buildQueue.includes("intake_mode=")
+    ? buildQueue
+    : `${buildQueue} intake_mode=build`;
 }
 
 /**

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

@@ -80,7 +80,7 @@ lifecycle state with provider-native closure and rollup state.
 |-------|---------|---------|
 | `<queue>` | Same queue identifier `lisa:intake` accepts (see Source dispatch). Required. | — |
 | `intake_mode` | `prd` \| `build` \| `both`. Only meaningful for a GitHub `org/repo` (or bare `github`) that hosts both PRD and build label namespaces. `both` is unique to repair — a repair sweep usefully covers both lifecycles in one schedule. Absent → `both` when both namespaces exist, else whichever lifecycle exists. | `both` for dual GitHub queues; otherwise infer |
-| `stale_after` | How long with no observable activity before an in-progress item counts as stalled. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
+| `stale_after` | How long since the last state-changing transition into the in-progress role, or since the last human / PR-side forward-progress activity, before an in-progress item counts as stalled. Automation self-comments do not reset this clock. Accepts `24h`, `90m`, `2d`, or `0` (treat any in-progress item as stalled — manual recovery, also the only way to resume work on a provider that exposes no reliable timestamp). Overrides config. | `2h` |
 | `max_candidates` | Cap on how many stuck/close-out candidates to enumerate and evaluate. Repair every materially actionable candidate within this bounded set, then stop. Overrides config. | `100` |
 | `force` | `true` bypasses the loop-prevention backoff window (so a manual re-run re-attempts items even if their fingerprint is unchanged). It does **not** change the staleness rule — use `stale_after=0` for that. | `false` |
 
@@ -228,9 +228,19 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa:at
 
 ## Staleness model
 
-An in-progress item (build `claimed`, PRD `in_review`) is **stalled** only if it shows no
-observable activity newer than the `stale_after` threshold. `blocked` items are NOT gated on
-staleness — their repairability is judged on current blocker/answer state, not elapsed time.
+An in-progress item (build `claimed`, PRD `in_review`) is **stalled** when the last
+state-changing transition into the in-progress role, or the last human / PR-side forward-progress
+activity after that transition, is older than the `stale_after` threshold. `blocked` items are NOT
+gated on staleness — their repairability is judged on current blocker/answer state, not elapsed
+time.
+
+Automation self-comments are not forward progress and must not reset the staleness clock. Status
+comments like `[claude-build-intake] PR remains open...`, `[codex-build-intake] Follow-up pushed...`,
+or `[lisa-repair-intake] ...` may be useful audit notes, but they cannot make a claimed item fresh
+forever. If a provider exposes a changelog/history surface, prefer the timestamp of the last
+transition into the claimed/In-Progress role over the item's generic `updated` timestamp. When the
+history surface is unavailable, ignore comments whose author/marker clearly belongs to Lisa or its
+automation agents, and use the newest human comment/edit or PR-side progress event instead.
 
 A build `claimed` leaf whose linked PR has **already merged** (`state == MERGED`) is likewise NOT
 gated on staleness. A merged PR is a settled terminal state, not in-flight work: the only thing
@@ -254,17 +264,24 @@ decision tree step 0, and the dedicated high-confidence ordering bucket).
 `stale_after=0` means "treat any in-progress item as stalled" — a manual full-recovery lever,
 and the only way to resume work on a provider that exposes no reliable activity timestamp.
 
-### Activity signal (most-recent-wins, portable across vendors)
+### Activity signal (state-change first, portable across vendors)
 
-Compute the item's newest activity timestamp from the highest-priority signal the vendor
+Compute the item's newest eligible activity timestamp from the highest-priority signal the vendor
 exposes, and compare it to `now - stale_after`:
 
-1. Provider-native item `updatedAt` / `last_edited_time` / `updated`.
-2. Latest lifecycle/progress **comment** on the item (and, for Linear PRDs, the sentinel
-   feedback issue).
-3. For build items, latest **PR activity** on the linked PR: newest commit, review, check-run,
+1. Provider-native status/label **transition** time into the in-progress role, when the provider
+   exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
+   Linear state/label history, Notion/Confluence page move/status history).
+2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
+   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+   `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
+   `[lisa-repair-intake]`.
+3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
+   review, check-run,
    or PR comment.
-4. Status/label **transition** time, when the provider exposes it cleanly.
+4. Provider-native item `updatedAt` / `last_edited_time` / `updated` only when the provider cannot
+   expose transition/comment authorship and the timestamp is not known to be driven by automation
+   self-comments.
 
 If ANY of these is newer than the threshold, the item is **active** → record it as `active` and
 skip it (read-only). For build `claimed`, an open PR with recent commits/checks is active. For