@codyswann/lisa 3.14.4 → 3.14.6

package/plugins/lisa-agy/skills/lisa-github-build-intake/SKILL.md

@@ -168,6 +168,60 @@ gh label list --repo <org>/<repo> --json name \
 
 If none of the configured role labels exist on the repo → label convention not adopted, surface a setup error and exit. If the role labels exist but none are `$READY` on any open issue matching the resolved assignee filter (or any open issue when the filter is empty) → genuinely empty queue, exit cleanly with `"No GitHub issues labeled $READY. Nothing to do."`
 
+#### 2b. Lifecycle-label trust resolution (bot-authored labels are not signals)
+
+**A `status:*` label is only a lifecycle signal if a trustworthy actor applied it.** Third-party GitHub Apps write labels through the same API humans do, and at least one — `coderabbitai[bot]` — stamps `status:*` on issues seconds after filing. Measured on CodySwannGT/lisa#2460–#2540: seven of eight bot-applied lifecycle labels landed 26–118s after creation. Those labels are guesses wearing the costume of the intake contract, and they break the queue in **both** directions:
+
+- a bot-applied **`$CLAIMED`** makes an unworked issue look like somebody's active work, so no cycle picks it up and no human re-examines it (#2470 sat unworked for a day this way);
+- a bot-applied **`$READY`** puts an issue into the build queue that no human ever flipped ready (#2538), inverting the gate the ready role exists to be.
+
+Before treating any candidate's lifecycle labels as meaningful, resolve which ones are trustworthy:
+
+```bash
+TRUST_DIR=$(mktemp -d)
+trap 'rm -rf "$TRUST_DIR"' EXIT
+
+gh api "repos/<org>/<repo>/issues/<n>" > "$TRUST_DIR/issue.json"
+
+# --paginate emits ONE ARRAY PER PAGE. Reading `$t[0]` would pass only page one,
+# silently dropping later label events — the newest of which is exactly the
+# application this classifier keys on. --slurp + `add` flattens all pages.
+gh api "repos/<org>/<repo>/issues/<n>/timeline?per_page=100" --paginate --slurp \
+  > "$TRUST_DIR/pages.json"
+jq 'add // []' "$TRUST_DIR/pages.json" > "$TRUST_DIR/timeline.json"
+
+# Resolve config the SAME way `read_role` does: the local file overrides the
+# global one key by key. Reading only `.lisa.config.json` would resolve a stale
+# terminal `done` label for any project that overrides it locally, and
+# `lisa-repair-intake` WRITES on the drift direction that mistake produces.
+# Both files are optional — a missing one must not abort the cycle.
+jq -s '(.[0] // {}) * (.[1] // {})' \
+  <(cat .lisa.config.json 2>/dev/null || echo '{}') \
+  <(cat .lisa.config.local.json 2>/dev/null || echo '{}') \
+  > "$TRUST_DIR/config.json"
+
+jq -n --slurpfile i "$TRUST_DIR/issue.json" \
+      --slurpfile t "$TRUST_DIR/timeline.json" \
+      --slurpfile c "$TRUST_DIR/config.json" \
+      '{issue: $i[0], timeline: $t[0], config: $c[0]}' \
+  > "$TRUST_DIR/input.json"
+
+node "${CLAUDE_PLUGIN_ROOT}/scripts/lifecycle-label-trust.mjs" < "$TRUST_DIR/input.json"
+```
+
+The temp directory is **per invocation**. Fixed `/tmp/lisa-*.json` paths let two concurrent intake cycles interleave one issue's metadata with another's timeline, which yields a confident verdict about an item that was never examined.
+
+The classifier returns `trusted`, `untrusted`, `unknownProvenance`, and a per-label `evaluated` list carrying the actor and the latency behind each decision. **Use `trusted` wherever this skill would otherwise read the raw label set**, and specifically:
+
+- a candidate whose `$READY` is **untrusted** is **not claimable** — skip it and leave it for a human to flip genuinely ready; report it in the summary rather than dispatching it;
+- a candidate whose `$CLAIMED` is **untrusted** is **not claimed** — if its `$READY` is trusted it stays a normal candidate, exactly as if the bot label were absent.
+
+**Never unlabel to correct this.** The bot re-applies its label on each subsequent review event, so reverting produces a label-flap loop that is worse than the defect. The guard is that intake stops *believing* the label; it writes nothing. Distrust is idempotent and cannot race.
+
+A label whose provenance cannot be established (applied at creation, which GitHub records no `labeled` event for) is trusted but listed in `unknownProvenance` — failing closed there would ignore the human `status:ready` that opens the queue. Report that list; do not silently drop it.
+
+Lifecycle membership is decided by the **`status:` prefix**, never by a pinned member list. The live family has drifted 7 → 6 members, and a literal set breaks silently: an unrecognised member simply fails to match, so the guard would report clean on exactly the case it stopped covering.
+
 ### Phase 3 — Process the first eligible ready issue
 
 #### 3a.0 Repo-scope gate (claim only current-repo issues)

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

@@ -560,6 +560,101 @@ native-open / active / unresolved:
 4. Post a compact `[lisa-repair-intake]` note only when the native close-out changed state or when
    an actionable setup error must be surfaced. Do not spam already-closed terminal items.
 
+### Lifecycle label contradicts native state — walk BOTH directions
+
+A lifecycle label can lie in two ways, and historically only one of them had an owner:
+
+| label | native state | owned by |
+|---|---|---|
+| terminal `done` role | still open / active | the `Build terminal-open` section above |
+| non-terminal role (`ready`, `claimed`, `blocked`, or any other `status:` member) | closed / completed | **nothing, until now** |
+
+A pass that walks one direction leaves the other accumulating silently. Measured on the Linear TUN
+board: **TUN-556 and TUN-503 both carry a terminal `status:done` while still natively open in
+`On Dev`** — invisible to intake and indistinguishable from handled, exactly like a bot-applied
+`status:in-progress` on GitHub.
+
+Resolve both directions in one pass with the shipped detector, which always reports
+`directionsWalked` covering both, so a "clean" verdict is an assertion that both were examined.
+
+**Build the classifier input inside this cycle. Never consume a temp file another skill wrote.**
+repair-intake runs as its own cycle, so borrowing `lisa-github-build-intake`'s scratch file fails
+two ways: absent, the redirect fails and `set -e` aborts the whole cycle; stale from an earlier run
+on a *different* item, the resolver classifies that other item and this section reports `drifts: []`
+while `directionsWalked` still claims both directions were walked. That is precisely the
+silent-clean verdict this section promises cannot happen.
+
+```bash
+TRUST_DIR=$(mktemp -d)
+trap 'rm -rf "$TRUST_DIR"' EXIT
+
+gh api "repos/<org>/<repo>/issues/<n>" > "$TRUST_DIR/issue.json"
+
+# --paginate emits ONE ARRAY PER PAGE; --slurp + `add` flattens all of them so a
+# label event on page two is not silently dropped.
+gh api "repos/<org>/<repo>/issues/<n>/timeline?per_page=100" --paginate --slurp \
+  > "$TRUST_DIR/pages.json"
+jq 'add // []' "$TRUST_DIR/pages.json" > "$TRUST_DIR/timeline.json"
+
+# Same resolution `read_role` uses: local overrides global, both optional.
+# Resolving a stale terminal `done` here would make the true terminal label look
+# like `open-label-closed-state` — and that direction WRITES.
+jq -s '(.[0] // {}) * (.[1] // {})' \
+  <(cat .lisa.config.json 2>/dev/null || echo '{}') \
+  <(cat .lisa.config.local.json 2>/dev/null || echo '{}') \
+  > "$TRUST_DIR/config.json"
+
+jq -n --slurpfile i "$TRUST_DIR/issue.json" \
+      --slurpfile t "$TRUST_DIR/timeline.json" \
+      --slurpfile c "$TRUST_DIR/config.json" \
+      '{issue: $i[0], timeline: $t[0], config: $c[0]}' \
+  > "$TRUST_DIR/input.json"
+
+node "${CLAUDE_PLUGIN_ROOT}/scripts/lifecycle-label-trust.mjs" < "$TRUST_DIR/input.json"
+```
+
+**Untrusted labels are excluded from `drifts` before any repair runs** — the classifier does this
+itself, so repair must **never act on a label the classifier refused to believe**. Without it, a
+bot-applied label on a natively closed item would be advanced to the terminal `done` role by the
+`open-label-closed-state` repair, laundering the exact input the guard rejected into a real write.
+The `excluded` array reports what was held back; surface it, do not repair it.
+
+1. **`terminal-label-open-state`** → hand to the `Build terminal-open → native close` section above.
+   Do not restate its rules; the terminality test lives there (intermediate env rungs like
+   `status:on-dev` / `status:on-stg` are **not** terminal).
+2. **`open-label-closed-state`** → the previously unowned direction. The item is natively closed or
+   completed while still wearing a non-terminal lifecycle role. Advance the label to the env-resolved
+   terminal `done` role and post one idempotent `[lisa-repair-intake]` note. This is a write on
+   **Lisa's own** lifecycle surface, not a contest with another writer.
+   Apply the leaf/container check from the **Lifecycle ownership guard** section *before* this
+   branch: repair-intake owns container repair, so a natively-closed `ready` **leaf** is skipped
+   here and left to the build lane rather than claimed by this pass.
+3. **Vendor caveat — Linear.** On Linear the lifecycle surface is the native workflow **state**, not a
+   `status:*` label (see `config-resolution`). A `status:*` label there is leftover cruft that no
+   repair direction reads, which is precisely why TUN-556 and TUN-503 rotted. Treat Linear's native
+   state as authoritative and remove the contradicting stale label; never move the state to match a
+   label.
+
+Membership in the lifecycle namespace is decided by the **`status:` prefix**, never a pinned member
+list — the live family has drifted 7 → 6 members, and a literal set fails silently by simply not
+matching the member it stopped covering.
+
+### Bot-authored lifecycle label → distrust, never revert (read-only)
+
+`status:*` labels written by a **bot** actor within the plausibility window of the item's creation are
+not lifecycle signals — see `lisa-github-build-intake` Phase 2b for the measurement and the
+classifier. Report them here so an operator can see how much of the board is wearing a label nobody
+chose:
+
+- list each item alongside the untrusted label, the bot login, and the latency, from the classifier's
+  `untrusted` array;
+- list `unknownProvenance` labels separately — trusted, but unattributable;
+- **do not unlabel and do not relabel.** The bot re-applies on each subsequent review event, so a
+  reverting reconciler produces a label-flap loop that is worse than the defect. Repair happens by
+  intake declining to *believe* the label, which is idempotent and writes nothing.
+
+This class is deliberately **read-only** and never counts toward the repair cap's actionable work.
+
 ### Build parent rollup reconciliation (intermediate-env or terminal close-out)
 
 For each parent/container item (an Epic, a Linear Project, or any item — of any type — with open child work),

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.14.4",
+  "version": "3.14.6",
   "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": "3.14.4",
+  "version": "3.14.6",
   "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": "3.14.4",
+  "version": "3.14.6",
   "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": "3.14.4",
+  "version": "3.14.6",
   "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": "3.14.4",
+  "version": "3.14.6",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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