@codyswann/lisa 3.14.3 → 3.14.5

package/expo/create-only/.github/workflows/maestro-e2e.yml

@@ -71,11 +71,15 @@ on:
 
 permissions:
   contents: read
-  # Read-only, and only this run's own job list. It is what
-  # `serialize_platform_legs` below needs to know when the iOS leg has
-  # finished — a called workflow cannot hold a permission the caller did not
-  # grant, so dropping this line turns that input into a red job rather than a
-  # silent no-op. Harmless when the input is off.
+  # Read-only, and only this run's own job list. It is granted HERE, in the
+  # caller, because that is the only place it can safely be granted: a called
+  # workflow that DECLARES a scope its caller did not grant is a
+  # `startup_failure` for the whole run. So this line plus the forwarded
+  # LEG_ORDER_TOKEN secret below are what let `serialize_platform_legs` read
+  # when the iOS leg finished.
+  #
+  # Drop this line and nothing breaks — the ordering job reports the gap and
+  # lets the Android leg start. You lose the ordering, not the suite.
   actions: read
 
 # Keyed on the ENVIRONMENT this suite drives, not on the ref. Every run of this
@@ -126,10 +130,19 @@ jobs:
       # other's session, so the loser hits a sign-in screen mid-suite and fails
       # an assertion that has nothing wrong with it. This runs iOS first, then
       # Android. It is ordering, not gating: a FAILING iOS leg still releases
-      # Android, so turning it on never narrows what gets tested. Requires the
-      # `actions: read` permission above. Leave it off if your legs use
-      # per-platform accounts — the concurrency is free coverage in that case.
+      # Android, so turning it on never narrows what gets tested. Needs the
+      # `actions: read` permission above AND the LEG_ORDER_TOKEN secret below;
+      # without either it reports the gap and runs the legs concurrently rather
+      # than failing. Leave it off if your legs use per-platform accounts — the
+      # concurrency is free coverage in that case. The cost when on is the suite
+      # taking iOS PLUS Android instead of the slower of the two.
       # serialize_platform_legs: true
     secrets:
       EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
       MAESTRO_SECRET_ENV: ${{ secrets.MAESTRO_SECRET_ENV }}
+      # Only read when serialize_platform_legs is true. A forwarded secret
+      # carries THIS workflow's token and therefore THIS workflow's
+      # `actions: read` — which is why the scope can be granted above without
+      # the reusable workflow having to declare it and startup-fail every caller
+      # that grants less. Harmless to pass when the input is off.
+      LEG_ORDER_TOKEN: ${{ secrets.GITHUB_TOKEN }}

package/package.json

@@ -125,7 +125,7 @@
     }
   },
   "name": "@codyswann/lisa",
-  "version": "3.14.3",
+  "version": "3.14.5",
   "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": "3.14.3",
+  "version": "3.14.5",
   "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": "3.14.3",
+  "version": "3.14.5",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/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/.codex-plugin/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),