@codyswann/lisa 2.341.0 → 2.341.2

package/plugins/src/base/skills/lisa-debrief-apply/SKILL.md

@@ -18,7 +18,7 @@ A path or URL to a Debrief triage document produced by `lisa-debrief`. The docum
 
 1. **Verify the doc exists and parses.** If the file cannot be read or the expected sections are missing, stop and report — do not guess.
 2. **Confirm dispositions exist.** If every row is unmarked, stop and ask the human to triage first. A pristine doc is a no-op, not an error to silently swallow.
-3. **Identify the destination map.** Read the project's `.lisa.config.json` (or stack defaults) for: edge-case checklist file (default: `plugins/src/base/rules/intent-routing.md`'s Edge Case Brainstorm sub-flow), the committed learnings ledger path (resolve it — never hardcode — via `resolveProjectLearningsFile` from `@codyswann/lisa/learnings`: the `learnings.file` override, else the default `.lisa/PROJECT_LEARNINGS.md`), tracker for new tickets. The three knowledge categories (recurring gotcha, process friction, convention drift) all land in the ledger now; machine-local auto-memory and `PROJECT_RULES.md` / `CLAUDE.md` are no longer knowledge destinations (see [Ledger persistence](#ledger-persistence-knowledge-categories)).
+3. **Identify the destination map.** Read the project's `.lisa.config.json` (or stack defaults) for: edge-case checklist file (default: `plugins/src/base/rules/intent-routing.md`'s Edge Case Brainstorm sub-flow), the committed learnings ledger path (resolve it — never hardcode — via `resolveProjectLearningsFile` from `@codyswann/lisa/learnings`: the `learnings.file` override, else the default `.lisa/PROJECT_LEARNINGS.md`), tracker for new tickets. The three knowledge categories (recurring gotcha, process friction, convention drift) all land in the ledger now; machine-local auto-memory and `PROJECT_RULES.md` / `AGENTS.md` are no longer knowledge destinations (see [Ledger persistence](#ledger-persistence-knowledge-categories)).
 
 ## Routing rules
 
@@ -34,6 +34,7 @@ For every row marked **Accept**:
 | Decomposition infidelity | Upstream Lisa repo | File an upstream Lisa issue per the "Filing upstream" procedure in `lisa-rework-triage`, citing the PRD text vs. the distorted ticket AC and naming the gate that passed it. |
 | PRD defect | Source PRD | Comment on the PRD via the `lisa-prd-backlink` lineage quoting the defective requirement and the failure it missed; flag for product review. Never silently edit the spec. |
 | Missing tool access | Configured tracker | Create a provisioning ticket via `lisa-tracker-write` (`issue_type: Task`, `type:tooling`) describing the missing tool/credential/environment and which flow needs it. |
+| Uncategorized | **No route — requires reclassification** | `Uncategorized` records that the synthesizer could not fit the finding to a category; it is not itself a destination. Do NOT guess a route and do NOT silently skip the row. Leave the row unapplied, mark it `[!] Needs reclassification — <the synthesizer's "why no category fit" note>`, and list it under its own heading in the run summary so the human can retag it to one of the eight and re-run `apply`. A row that stays `Uncategorized` across runs is a signal the category set itself is missing a case — worth an upstream Lisa issue, not a forced fit. |
 
 For every row marked **Reject** or **Defer**: no action. Defer is a no-op for `apply` but worth surfacing in the run summary — the human may want to revisit at the next debrief.
 
@@ -60,13 +61,13 @@ For each such Accepted row:
    - `first_learned` = `last_confirmed` = today (ISO date; on consolidation keep the superseded entry's earliest `first_learned`).
    - `confidence` = **`high`**. A human marking the row **Accept** is corroboration — an independent human judgement that the learning is real — so a debrief-accepted entry starts higher than the learner's single-occurrence auto-capture (which defaults to `low`). The writer re-asserts the entry and token budgets; an over-budget failure means consolidate harder or drop, never truncate by hand.
 
-**Machine-local memory is no longer a knowledge destination.** Auto-memory (`project_*.md`, `MEMORY.md`) remains available only for the assistant's *personal* collaboration notes — it is invisible to cloud runs and to teammates, so it can never hold shared project knowledge. **`CLAUDE.md` is human-authored** agent operating instruction and `PROJECT_RULES.md` is durable human-authored guidance; `apply` never writes to any of the three for these categories.
+**Machine-local memory is no longer a knowledge destination.** Auto-memory (`project_*.md`, `MEMORY.md`) remains available only for the assistant's *personal* collaboration notes — it is invisible to cloud runs and to teammates, so it can never hold shared project knowledge. **`AGENTS.md` is human-authored** agent operating instruction — it is the source of truth, and `CLAUDE.md` is only a one-line `@AGENTS.md` pointer — and `PROJECT_RULES.md` is durable human-authored guidance; `apply` never writes to any of the three for these categories.
 
 ## Idempotency
 
 `apply` is safe to re-run. Each Accepted row carries an evidence link that doubles as a fingerprint. Before writing, check whether the destination already cites that fingerprint:
 
-- **Knowledge categories (gotcha, friction, drift) → ledger.** Parse the ledger once with `parseLearningsFile` from `@codyswann/lisa/learnings` and scan the entries' `provenance` for the row's evidence link. If any entry's provenance already contains it, the row is already persisted — skip the write. This replaces the old scattered-file greps (memory files, `PROJECT_RULES.md`, `CLAUDE.md`): provenance in the single governed ledger is now the one fingerprint surface.
+- **Knowledge categories (gotcha, friction, drift) → ledger.** Parse the ledger once with `parseLearningsFile` from `@codyswann/lisa/learnings` and scan the entries' `provenance` for the row's evidence link. If any entry's provenance already contains it, the row is already persisted — skip the write. This replaces the old scattered-file greps (memory files, `PROJECT_RULES.md`, `AGENTS.md`): provenance in the single governed ledger is now the one fingerprint surface.
 - **Other categories** keep their existing destination check (the tracker for the ticket marker, the PRD for the defect comment, `intent-routing.md` for the edge-case citation).
 
 If the fingerprint is already present, skip the write and note the row as `already-applied` in the run summary. This lets the human triage a doc incrementally (mark a few, run apply, mark more, run apply again) without producing duplicates.
@@ -92,6 +93,8 @@ Applied <n> learnings:
   <n> missing tool access → <tracker> (<key1>, ...)
 Skipped:
   <n> rejected, <n> deferred, <n> already-applied
+Needs reclassification:
+  <n> uncategorized (retag to one of the eight categories and re-run apply)
 Failed:
   <n> (see <path> for details)
 Triage doc updated in place: <path>

package/plugins/src/base/skills/lisa-implement/SKILL.md

@@ -336,9 +336,10 @@ Before shutting down the team, execute the Verify flow:
 9. Merge the PR, then refresh the ticket-side backlink with `lisa-tracker-sync <work_item_ref> pr-merged pr_url=<url> merge_sha=<sha> tracker_provider=<provider>`.
 10. Monitor the deploy action that triggers automatically from the successful merge
 11. If deploy fails, create a task for the agent team to fix the failure, open a new PR and then go back to step 7
-12. Remote verification: `verification-specialist` verifies in target environment (same checks as local verification, but on remote), and refreshes the verdict (step 2a) to reflect the remote result.
-13. `ops-specialist`: post-deploy health check, monitor for errors in first minutes
+12. Remote verification: `verification-specialist` verifies in target environment (same checks as local verification, but on remote), and refreshes the verdict (step 2a) to reflect the remote result. Resolve credentials through the `verification-lifecycle` lookup order before declaring any missing. If they remain genuinely unavailable, do not complete on artifact-only evidence: post a tracker comment naming every credential source checked and what could not be verified as a result, transition the work item to the configured blocked state, and apply the configured `needs-human` / `human-review` label (creating it when the tracker supports label creation and it is missing). The comment is what makes the escalation auditable — a label alone records that something stopped, not what was tried or why. Evidence must explicitly distinguish `verified empirically` from `artifact-only / verification deferred`.
+13. `ops-specialist`: post-deploy health check via `lisa-monitor <env> --report-only`, monitor for errors in first minutes. `--report-only` is REQUIRED: it keeps the post-deploy check a pure health/audit report so monitor's standalone ticket-filing never fires inside this flow.
 14. If remote verification fails, create a task for the agent team to find out why it failed, fix it and return to step 5. **Bound this loop**: after a small number of full fix→deploy→reverify cycles without reaching a passing remote verdict (treat ~3 as the ceiling unless the work item states otherwise), stop retrying — file a build-ready fix ticket, write the verdict with `status: "blocked"` and the diagnosis, and move the work item to blocked rather than looping indefinitely. The completion gate releases on a `blocked` verdict, so the flow ends with a recorded outcome instead of a silent spin or a self-declared success.
-15. After true terminal completion — required merge/deploy/verification passed, usage/evidence and two-way PR linkage are recorded, and the work item is terminal — run `node scripts/lisa-work-item.mjs clear` and verify the worktree has no current binding. Do not clear on an interruption or blocked outcome; preserving the binding is what keeps resumed work attributable.
+15. **Post evidence to the originating work item** via `lisa-tracker-evidence` (vendor-neutral; dispatches to `lisa-jira-evidence`, `lisa-github-evidence`, or `lisa-linear-evidence` per `.lisa.config.json` `tracker`), including the list of codified tests added on this branch. **If the work is UI-visible** (any verification step ran in a browser, or the change touches a user-facing surface), author `evidence/comment.md` per the **UI Evidence Checklist** in `lisa-tracker-evidence` — numbered live-session steps, one screenshot per step captured through the interactive browser controller and uploaded to the GitHub `pr-assets` release as plain URLs, and an explicit invitation to be corrected. This step is what makes the proof visible to a non-technical operator standing at the gate; a terminal work item with no posted evidence is an incomplete flow, not a finished one.
+16. After true terminal completion — required merge/deploy/verification passed, usage/evidence and two-way PR linkage are recorded, and the work item is terminal — run `node scripts/lisa-work-item.mjs clear` and verify the worktree has no current binding. Do not clear on an interruption or blocked outcome; preserving the binding is what keeps resumed work attributable.
 
 **Ticket status transitions throughout this flow are config-bound** per the **Tracker status vocabulary** section of the `config-resolution` rule: whoever performs the tracker write — the lead included, in runtimes where the tracker MCP is lead-only — may only target statuses named in the configured workflow map (`claimed`, `blocked`, env-keyed `done`, and `review`/`qa` when configured). Never adopt a status discovered from the tracker's live workflow; a lifecycle stage with no configured status gets a comment, not a transition.

package/plugins/src/base/skills/lisa-setup-remote-env/SKILL.md

@@ -236,6 +236,41 @@ What the detector produces is a proposal with `<pin>`, `<release url>` and `<sha
 
 The other objections stay true and stay unfixed: most tooling has no credential and most credentials imply no tool, so notes are one signal among four and the weakest of them. They are read *after* npm scripts and MCP servers, and a note alone should be the least persuasive reason to add anything.
 
+## One command, four surfaces
+
+`lisa environment <surface> --tenant=<name>` configures one surface for one
+tenant. The only difference between them is whether Lisa can execute there:
+
+| Surface | What happens | Materializes |
+| --- | --- | --- |
+| `local` | runs here: stores the bootstrap, materializes, installs AWS profiles | on request |
+| `container` | emits an image definition and a `docker run` line | at container start |
+| `claude-web` | emits text for the environment dialog | at setup **and** session start |
+| `codex-cloud` | emits text for the environment settings | at setup |
+
+None of it needs a checkout, which is the point: the surfaces most in need of
+configuration are the ones with no repository attached.
+
+`--tenant` is required on `local` because that path **writes**. Every namespace
+is a directory under `$XDG_CONFIG_HOME`, so resolving the wrong one puts one
+tenant's credentials where another tenant's sessions read — and on a machine
+serving several, the two would share a store. The named tenant also outranks any
+`.lisa.config.json` in the working directory: someone who typed `--tenant=acme`
+means acme, whichever repository they happen to be standing in.
+
+Re-running `environment local` is how a token is **rotated**. It is not an
+installer, so it does not reinstall agents to replace one credential; it reports
+that a bootstrap is already stored and leaves it alone unless `--rotate` says
+otherwise.
+
+`workstation` remains the separate question — what binaries does this machine
+have — with no tenant and no credentials.
+
+`remote-env --emit=<surface>` still works, and is the older spelling of the same
+thing. It named the machinery rather than the task: from a laptop it reads as
+"prepare the remote environment I am currently in", which is the opposite of
+configuring a cloud environment.
+
 ## Provisioning tiers
 
 Preference order, falling back:

package/plugins/src/base/skills/lisa-verify/SKILL.md

@@ -38,8 +38,8 @@ Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via
 1. **Pre-flight: codification gate** — confirm that every passing local empirical verification on this branch was codified as a regression test (the Implement flow's codify step). If any verification has no committed test and no allowed skip reason (PR / Documentation / Deploy / Investigate-Only), invoke `codify-verification` now and amend the PR before shipping. For frontend work the gate is dual-runner: a Playwright spec AND, when the project supports Maestro (`.maestro/`, `maestro:test` script, or Maestro CI workflow), a Maestro flow for the same journey — a missing runner needs a recorded absence or a linked build-ready follow-up ticket, never a silent skip. A change cannot ship until its verifications are guarded.
 2. **Commit** any pending changes via `lisa-git-commit`
 3. **Push and PR** via `lisa-git-submit-pr`
-4. **Review loop** — handle CodeRabbit / human review comments via `lisa-pull-request-review`
-5. **Merge** when CI is green
+4. **PR Watch Loop** — drive the PR to MERGED via `lisa-drive-pr-to-merge`, 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 (it invokes `lisa-pull-request-review` itself), stale `CHANGES_REQUESTED` dismissal, and post-merge ancestry verification. Do not re-implement the loop or its terminal conditions.
+5. **Merge** — owned by `lisa-drive-pr-to-merge`, including the auto-merge race and zero-deploy-run checks
 6. **Remote verification** — invoke the `lisa-monitor` skill against the target environment **in report-only mode** (`lisa-monitor <env> --report-only`) to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined). `--report-only` is required here: it keeps the post-deploy check a pure health/audit report and prevents monitor's standalone ticket-filing from creating issues during a verify run. If remote verification surfaces a behavioral gap that the existing codified tests do not guard, invoke `codify-verification` to add coverage and open a follow-up PR.
    - When the Validation Journey is DOM-web, the target is an allowed non-production environment with mutation policy `full`, and `lisa kane probe` succeeds, verification may invoke `lisa-kane-browser`. Import the local evidence pack into Lisa's evidence flow; the Test Manager URL is secondary. Kane does not replace the pre-flight Playwright/Maestro codification gate.
    - When remote verification needs credentials, follow the shared `verification-lifecycle` credential lookup order before declaring them missing: project e2e / Playwright config and fixtures first, then `.lisa.config.local.json` / environment variables, then documented ticket credentials such as a `Sign-in Required` section.