@codyswann/lisa 4.26.5 → 4.27.1

package/plugins/lisa-agy/skills/lisa-implement/SKILL.md

@@ -346,6 +346,16 @@ Before shutting down the team, execute the Verify flow:
 4. Record Implement usage on the originating work artifact via `lisa-usage-accounting` so the work item (or other implementation-owned artifact) gains a direct `lisa-implement` usage entry in the canonical `## Lisa Usage` section. If the parent / child graph is already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise still write the direct entry, and if runtime usage is unavailable, use `source: unavailable` with nullable token/cost fields instead of skipping the row.
 5. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
 6. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not
+6a. **Review the branch locally BEFORE opening the pull request, every time.** Invoke `lisa-review-local` over the branch diff, triage what it finds under the `convergent-review` rule (same contract as any other reviewer — fix what is valid, refute what is not, on the record), and commit the fixes. Only then proceed to step 7.
+
+    **Unconditional, not a fallback.** Do not gate this on whether a third-party reviewer is available, rate limited, or skipped. Measured on this repository, 47 of the last 60 merged pull requests carried a review context reporting `SUCCESS` while having read nothing — 29 rate limited, 16 skipped because the vendor does not auto-review public repositories, one skipped on size. A rule that fires only when the vendor is absent has to detect four distinct vacuity strings correctly, forever, and still leaves the vendor being *present but wrong* unguarded. Reviewing always needs no detection at all and makes the third-party review **additive**: its findings still arrive at step 8 and are handled there exactly as today.
+
+    **Before the pull request, not after it.** Auto-merge is armed at submit time, so the pull request can merge the moment CI goes green — a review that starts after step 7 is racing a latch that is already set. Running here has nothing to race.
+
+    **A local review is a weaker claim than an independent one, and the report must say so.** The agents reviewing the branch are the same team that wrote it. Record the outcome as *self-reviewed* — never as *reviewed* — and never describe it as satisfying the third-party review check, which is ruleset-required and can only be posted by that vendor's app. Collapsing the two would be the same vacuous-success failure this step exists to remove, one level up.
+
+    **If no subagent delegation is available in this runtime**, say so explicitly in the completion summary and proceed — but record that no local review was possible. "Could not review" must never be reported as "reviewed and found nothing"; an unavailable check is not a passing one.
+
 7. Open a pull request with auto-merge on via `lisa-git-submit-pr`, targeting the **base branch resolved from the ticket's environment** (`target_branch=<base>`, per the branch step above), and including the mandatory work-item ref so the PR can be linked natively to the source issue.
 7a. Confirm two-way linkage before treating PR submission as complete: the PR body/title/branch must reference the work item, and the work item must have either a verified native PR link or the single managed `[lisa-pr-link]` comment. Establish that comment with `node scripts/lisa-work-item.mjs backlink --ref <work_item_ref> --pr-url <url>` rather than posting it by hand — it is idempotent, and it is the same file that enforces the check, so producer and consumer cannot drift.
 8. PR Watch Loop: Drive the PR to merge via the `drive-pr-to-merge` skill — the single source of truth for clearing every blocker (auto-merge with direct-merge fallback, `BEHIND` re-sync, conflict resolution, failing-check fixes, human + bot review-comment handling with thread resolution, stale `CHANGES_REQUESTED` dismissal, and post-merge ancestry verification). `git-submit-pr` already invokes it; if you reach this step with a PR already open, invoke `drive-pr-to-merge` directly with the PR number. For a large review backlog you may fan the code-fix work out to the agent team, but `drive-pr-to-merge` owns the loop and the terminal conditions — do not re-implement them.

package/plugins/lisa-agy/skills/lisa-linear-access/SKILL.md

@@ -82,9 +82,43 @@ All GraphQL calls use:
 # or AWS has no path to the key at all — the ladder stopped at rung one, which
 # is also what left `/lisa:setup:linear` reading an OS keychain directly with
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
-read_linear_key() {
+read_linear_key() {  # $1=workspace slug; defaults to $WORKSPACE read from config
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
+  # Per-workspace rung, matching `atlassian-access` and `notion-access` — and
+  # matching what `setup-linear` has always told the reader to export. This
+  # copy lacked it, so a key set the documented way validated during setup (the
+  # setup skill reads it) and was then ignored by every real Linear call, which
+  # silently fell through to whatever other credential it found. Nothing
+  # errored; the operation just ran as a different identity. The rung is also
+  # load-bearing headlessly: `analyze-claude-remote` reports Linear's env as
+  # `LINEAR_API_KEY` "or per-account `LINEAR_API_KEY_<ws-slug>`", and
+  # `generate-claude-remote-build-script` emits that suffixed name into cloud
+  # routine env templates — so a routine provisioned from those skills had no
+  # reachable key at all.
+  #
+  # An unset variable changes nothing: an empty workspace skips the rung
+  # entirely and the ladder below runs exactly as it did before.
+  local ws="${1:-${WORKSPACE:-}}"
+  if [ -n "$ws" ]; then
+    local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+    # Constrain the slug before it reaches `${!varname}`. Indirect expansion
+    # evaluates an array subscript, so a workspace carrying `[$(...)]` would
+    # RUN that command here — and `tr` above only folds case and dashes, it
+    # strips nothing. The slug's source is `.lisa.config.json`, which is
+    # repository-controlled input: exactly what this ladder already refuses to
+    # trust when it picks resolvers. A real workspace slug is lowercase
+    # alphanumerics and underscores, so anything else is not a slug we should
+    # be expanding — skip the rung and fall through rather than guessing.
+    case "$slug" in
+      ""|*[!a-z0-9_]*) ;;
+      *)
+        local varname="LINEAR_API_KEY_${slug}"
+        [ -n "${!varname:-}" ] && { echo "${!varname}"; return; }
+        ;;
+    esac
+  fi
+
   # The ladder is ordered across trusted machine-managed substrates and ends at
   # the installed package. Checkout-local paths are deliberately absent: a
   # familiar generated destination is still repository-controlled executable
@@ -132,9 +166,10 @@ linear_graphql() {
   local query="$1"
   local variables="${2:-{}}"
   local key
-  key=$(read_linear_key) || {
-    echo "Error: no Linear API key. Set LINEAR_API_KEY, or store it as" >&2
-    echo "LINEAR_API_KEY in this project's secrets provider." >&2
+  key=$(read_linear_key "${WORKSPACE:-}") || {
+    echo "Error: no Linear API key. Set LINEAR_API_KEY (or the per-workspace" >&2
+    echo "LINEAR_API_KEY_<slug>), or store it as LINEAR_API_KEY in this" >&2
+    echo "project's secrets provider." >&2
     return 1
   }
   jq -n --arg query "$query" --argjson variables "$variables" \

package/plugins/lisa-agy/skills/lisa-setup-remote-aws/SKILL.md

@@ -30,14 +30,45 @@ Install the vendor-neutral AWS bootstrap into the current repository.
    `.github/workflows/copilot-setup-steps.yml`; and it always writes
    `docs/remote-agent-aws.md`.
 4. Run `bash -n scripts/remote-agent-aws-setup.sh`.
-5. Never write or request the actual bootstrap bundle in repository files. Tell
+5. Confirm the operator knows which project component the profiles will carry.
+   The script resolves it from `LISA_AWS_PROFILE_NAMESPACE`, then the bundle's
+   `namespace`, then `<owner>-<repository>` from the git origin remote, and
+   refuses to write anything when none resolves. Set the variable explicitly
+   whenever the setup hook runs outside a checkout.
+6. Never write or request the actual bootstrap bundle in repository files. Tell
    the operator where to obtain it and where to put it — see **Where the bundle
    lives** below. Pass `--secret-name` when the source names it something other
    than `remote-agent-credentials`, so the generated runbook contains the exact
    retrieval command.
-6. Report the external step that remains: configure that one secret in the
+7. Report the external step that remains: configure that one secret in the
    remote environment and launch a smoke session.
 
+## Profile naming and readiness
+
+Every profile the script writes is scoped `<project>-agent-<stage>`, and the
+private source profile is `<project>-agent-bootstrap`. Bare stage names state a
+stage but not an owner, so on a workstation carrying more than one organisation
+two bundles declaring the same stages overwrite each other in the shared
+`~/.aws/config` — silently, because nothing about the surviving profile is
+malformed. The name is the only place the owner can be recorded.
+
+`default` cannot be namespaced. The script claims it only when nothing else
+owns it, and otherwise stops and names the current owner;
+`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes it over deliberately.
+
+Readiness is an account check, not a liveness check. `sts:GetCallerIdentity`
+succeeding proves the credentials work, not that they reached the intended
+account — a check that ignores the returned value passes on any credential that
+authenticates anywhere. The script compares the returned account id against the
+account named in the role ARN it configured and refuses to report ready on a
+mismatch, quoting both. Do not substitute a hand-run `get-caller-identity` for
+the script's own exit status.
+
+Workstations bootstrapped under the previous unnamespaced convention keep their
+old profiles. They are reported by name on every run and removed only when
+`LISA_AWS_PRUNE_LEGACY_PROFILES=1` is passed, so the migration is explicit in
+both directions.
+
 ## Where the bundle lives
 
 `LISA_AWS_BOOTSTRAP_JSON` is **just another secret**, and it belongs wherever

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

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

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

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

package/plugins/lisa-copilot/scripts/install-remote-agent-aws.mjs

@@ -313,14 +313,32 @@ Generated for: \`${platform}\`.
 
 ## Implementation
 
-The bootstrap bundle defines the available profile names. \`dev\` is the
-default when present. Select another account explicitly, for example:
+Profiles are named \`<project>-agent-<stage>\`, not bare \`dev\` or
+\`production\`. The bundle supplies the stage; the project component comes from
+\`LISA_AWS_PROFILE_NAMESPACE\`, then the bundle's \`namespace\`, then
+\`<owner>-<repository>\` from this checkout's git origin. Select an account
+explicitly, for example:
 
 \`\`\`bash
-aws --profile staging sts get-caller-identity
-aws --profile production cloudformation describe-stacks
+aws --profile <project>-agent-staging sts get-caller-identity
+aws --profile <project>-agent-production cloudformation describe-stacks
 \`\`\`
 
+The setup line prints the exact names it wrote; use those.
+
+A bare stage name states a stage but not an owner. Two organisations' bundles
+declaring the same stages write the same names into the same shared
+\`~/.aws/config\`, the last bootstrap silently wins, and every later command
+runs in the other tenant's account while reporting success. Nothing about the
+resulting profile is malformed, so no check on the profile can catch it — only
+a name carrying the owner prevents it.
+
+\`default\` is the one name that cannot be namespaced. The setup script writes
+it for this project only when nothing else already owns it; if another Lisa
+project or the operator's own configuration holds it, the script stops and says
+so rather than repointing every unqualified \`aws\` command. Pass
+\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take it over deliberately.
+
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.
 
@@ -340,8 +358,36 @@ this project requires a named source profile to read the emission; \`shared\` is
 not an implicit requirement.
 
 Store that exact output as the masked secret \`LISA_AWS_BOOTSTRAP_JSON\` on each
-remote-agent platform. Run the setup command and require its live
-\`sts:GetCallerIdentity\` check to pass before considering the platform ready.
+remote-agent platform, then run the setup command.
+
+## Readiness
+
+\`sts:GetCallerIdentity\` succeeding proves only that the credentials work. It
+does not prove they reached the intended account, and a check that never looks
+at what the call returned passes on any credential that authenticates —
+including one that authenticates into somebody else's account.
+
+The setup script therefore compares the returned account id against the account
+named in the role ARN it just configured, and refuses to report ready on a
+mismatch, quoting both ids. A bundle may also declare \`expectedAccountId\` per
+stage; a declared id that disagrees with its own role ARN fails before anything
+is written. \`LISA_AWS_EXPECTED_ACCOUNT_ID\` states the same expectation from
+outside the bundle, and \`LISA_AWS_VERIFY_ALL_PROFILES=1\` proves every stage
+rather than only the default.
+
+Treat the setup command's own exit status as the readiness gate. Do not
+substitute a hand-run \`aws sts get-caller-identity\`: it answers "do these
+credentials work", which is not the question.
+
+## Migration
+
+Workstations bootstrapped before profiles were namespaced still carry the old
+bare names. The setup script detects them — by the retired
+\`lisa-remote-agent-bootstrap\` source profile, so an operator's own \`dev\` is
+never mistaken for one of ours — and names them on stderr on every run. They are
+left in place, because deleting a profile somebody may still be using is its own
+silent surprise. Re-run with \`LISA_AWS_PRUNE_LEGACY_PROFILES=1\` to delete the
+ones Lisa wrote; it reports exactly what it removed.
 
 ## Notes