@codyswann/lisa 2.116.2 → 2.118.0

package/plugins/lisa/rules/eager/wiki-knowledge-source.md

@@ -0,0 +1,16 @@
+# Wiki as Knowledge Source (load-bearing)
+
+If the project has an LLM Wiki (a `wiki/` directory with `index.md`), treat it as the canonical source of durable project knowledge.
+
+Before researching background, conventions, ownership, architecture, glossary, or "how/why does X work here":
+
+1. **Consult the wiki first.** Start from `wiki/index.md` or use the wiki query skill (`/lisa-wiki-query`).
+2. **Use what the wiki says** as the authoritative answer when it covers the question — do not re-derive it from raw sources.
+3. **Fall back to primary sources** (code, tickets, commit history, external docs) only when the wiki is silent, ambiguous, or contradicted by what you observe.
+4. **Surface gaps.** If the wiki is wrong, stale, or missing knowledge that belongs there, flag it — and where the workflow supports it, capture the correction via `/lisa-wiki-ingest`.
+
+The wiki documents knowledge; it does NOT override executable behavior. When wiki and running code disagree about what the system does, trust the code and treat the wiki as out of date.
+
+If the project has no `wiki/`, this rule does not apply.
+
+Full prose: [reference/wiki-knowledge-source.md](../reference/wiki-knowledge-source.md).

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.116.2",
+  "version": "2.118.0",
   "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.116.2",
+  "version": "2.118.0",
   "description": "Expo and 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.116.2",
+  "version": "2.118.0",
   "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.116.2",
+  "version": "2.118.0",
   "description": "Harper/Fabric-specific Lisa 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.116.2",
+  "version": "2.118.0",
   "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.116.2",
+  "version": "2.118.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.116.2",
+  "version": "2.118.0",
   "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.116.2",
+  "version": "2.118.0",
   "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-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.116.2",
+  "version": "2.118.0",
   "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.116.2",
+  "version": "2.118.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop 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.116.2",
+  "version": "2.118.0",
   "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.116.2",
+  "version": "2.118.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.116.2",
+  "version": "2.118.0",
   "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.116.2",
+  "version": "2.118.0",
   "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/scripts/ensure-gitignore.mjs

@@ -0,0 +1,131 @@
+#!/usr/bin/env node
+/**
+ * ensure-gitignore.mjs — merge the lisa-wiki gitignore block into the project's
+ * `.gitignore`, idempotently. Dependency-free.
+ *
+ * The block is delimited by `# BEGIN: AI GUARDRAILS WIKI` and
+ * `# END: AI GUARDRAILS WIKI` markers (see templates/wrapper-gitignore.txt).
+ * Behavior matches the base lisa plugin's copy-contents strategy
+ * (src/strategies/copy-contents.ts):
+ *
+ *   - If the file is missing, create it with just the block.
+ *   - If the block markers exist, replace the block in place.
+ *   - If the markers don't exist, append the block to the end (preserving a
+ *     trailing newline).
+ *
+ * Patterns outside the marker block are NEVER touched. Re-running produces no
+ * spurious diff once the file is in sync.
+ *
+ * Usage: node ensure-gitignore.mjs [--cwd <project-dir>] [--dry-run]
+ *   default cwd: process.cwd()
+ *   --dry-run    prints the proposed merge result to stdout instead of writing
+ *
+ * Exit code 0 = ok (file was created, updated, or already in sync).
+ * Exit code 1 = error (e.g. template missing).
+ */
+import fs from "node:fs";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+const BEGIN_MARKER = "# BEGIN: AI GUARDRAILS WIKI";
+const END_MARKER = "# END: AI GUARDRAILS WIKI";
+
+function fail(msg) {
+  console.error(`✗ ${msg}`);
+  process.exit(1);
+}
+
+const scriptDir = path.dirname(fileURLToPath(import.meta.url));
+const pluginRoot = path.dirname(scriptDir);
+const templatePath = path.join(
+  pluginRoot,
+  "templates",
+  "wrapper-gitignore.txt"
+);
+
+const argv = process.argv.slice(2);
+const cwdIndex = argv.indexOf("--cwd");
+const projectDir =
+  cwdIndex !== -1 && argv[cwdIndex + 1]
+    ? path.resolve(argv[cwdIndex + 1])
+    : process.cwd();
+const dryRun = argv.includes("--dry-run");
+
+if (!fs.existsSync(templatePath)) {
+  fail(`template not found: ${templatePath}`);
+}
+
+const templateRaw = fs.readFileSync(templatePath, "utf8");
+const block = extractBlock(templateRaw);
+if (!block) {
+  fail(
+    `template at ${templatePath} does not contain the expected marker pair (${BEGIN_MARKER} / ${END_MARKER})`
+  );
+}
+
+const gitignorePath = path.join(projectDir, ".gitignore");
+const existing = fs.existsSync(gitignorePath)
+  ? fs.readFileSync(gitignorePath, "utf8")
+  : null;
+
+const merged = mergeBlock(existing, block);
+
+if (existing !== null && merged === existing) {
+  console.log(`✓ .gitignore already in sync (${gitignorePath})`);
+  process.exit(0);
+}
+
+if (dryRun) {
+  process.stdout.write(merged);
+  process.exit(0);
+}
+
+fs.writeFileSync(gitignorePath, merged);
+const verb = existing === null ? "created" : "updated";
+console.log(`✓ ${verb} ${gitignorePath}`);
+process.exit(0);
+
+/**
+ * Pull the block (markers included) out of arbitrary text. Returns null when
+ * the marker pair is missing or out of order.
+ */
+function extractBlock(text) {
+  const startIdx = text.indexOf(BEGIN_MARKER);
+  if (startIdx === -1) return null;
+  const endStart = text.indexOf(END_MARKER, startIdx + BEGIN_MARKER.length);
+  if (endStart === -1) return null;
+  const endIdx = endStart + END_MARKER.length;
+  return text.slice(startIdx, endIdx);
+}
+
+/**
+ * Merge a freshly-rendered block into the destination file content.
+ *   - existing === null → return the block alone (file will be created)
+ *   - existing has the markers → replace the block in place
+ *   - existing lacks the markers → append the block at the end
+ * Always normalizes to exactly one trailing newline.
+ */
+function mergeBlock(existing, freshBlock) {
+  if (existing === null) {
+    return `${freshBlock.trimEnd()}\n`;
+  }
+
+  const startIdx = existing.indexOf(BEGIN_MARKER);
+  if (startIdx !== -1) {
+    const endStart = existing.indexOf(
+      END_MARKER,
+      startIdx + BEGIN_MARKER.length
+    );
+    if (endStart !== -1) {
+      const endIdx = endStart + END_MARKER.length;
+      const before = existing.slice(0, startIdx);
+      const after = existing.slice(endIdx);
+      const trimmedAfter = after.startsWith("\n") ? after : `\n${after}`;
+      return `${before}${freshBlock.trimEnd()}${trimmedAfter}`;
+    }
+  }
+
+  // No marker pair in the destination — append.
+  const base = existing.endsWith("\n") ? existing : `${existing}\n`;
+  return `${base}\n${freshBlock.trimEnd()}\n`;
+}

package/plugins/lisa-wiki/skills/lisa-wiki-setup/SKILL.md

@@ -30,13 +30,22 @@ never overwrites human-authored content.
 3. **Contract.** Render `wiki/schema/llm-wiki-contract.md` from the plugin templates + config via
    `scripts/render-contract.mjs`, stamping the `kernelVersion`. This snapshot keeps the wiki
    self-describing without the plugin installed.
-4. **Pointers.** Ensure `AGENTS.md` / `CLAUDE.md` point at the contract + plugin (thin pointers only).
-5. **Staff.** For each `config.staff[]` entry (the standard roster by default), generate the role's
+4. **Gitignore.** Merge the lisa-wiki gitignore block into the project's `.gitignore` via
+   `scripts/ensure-gitignore.mjs`. The block (delimited by `# BEGIN: AI GUARDRAILS WIKI` /
+   `# END: AI GUARDRAILS WIKI`) covers transient per-session worktrees and Lisa backup snapshots
+   (`.claude/worktrees/`, `.codex/worktrees/`, `.lisabak/`). Idempotent: re-running produces no
+   diff once the block is present. The block coexists with the base lisa plugin's
+   `# BEGIN: AI GUARDRAILS` block — both can be installed without overwriting each other because
+   the copy-contents strategy keys on the marker suffix. Wiki-wrapper repos (mode `wrapper` /
+   `standalone`) typically don't enable the base lisa plugin, so this step is the only path by
+   which they get the worktree-ignore patterns.
+5. **Pointers.** Ensure `AGENTS.md` / `CLAUDE.md` point at the contract + plugin (thin pointers only).
+6. **Staff.** For each `config.staff[]` entry (the standard roster by default), generate the role's
    `wiki/staff/<role>.md` page and its dual-runtime subagents by delegating to `lisa-wiki-add-role`
    (running the subagents is out of scope).
-6. **README.** Apply the chosen README mode (ingest the old README first; `rich` keeps install/usage +
+7. **README.** Apply the chosen README mode (ingest the old README first; `rich` keeps install/usage +
    adds the onboarding line; `stub` is the minimal pointer; `preserve` leaves it).
-7. **Verify.** Run `lisa-wiki-doctor` and report the verdict + any blocking items.
+8. **Verify.** Run `lisa-wiki-doctor` and report the verdict + any blocking items.
 
 ## Standard roster
 The default operating team seeded into `config.staff[]` for every new wiki (Chief of Staff plus six

package/plugins/lisa-wiki/templates/wrapper-gitignore.txt

@@ -0,0 +1,19 @@
+# BEGIN: AI GUARDRAILS WIKI
+# Managed by the lisa-wiki kernel. Do not edit between these markers — re-run
+# /lisa-wiki:setup (or the equivalent script) to update. Patterns outside the
+# block are preserved untouched. The "WIKI" suffix lets this block coexist
+# with the base lisa plugin's "# BEGIN: AI GUARDRAILS" block when both are
+# installed (the copy-contents strategy keys on the marker suffix).
+
+# Claude Code per-session git worktrees. Each Claude session that needs an
+# isolated working copy spawns one under .claude/worktrees/ (via
+# `git worktree add`). They are transient, large (often hundreds of MB each),
+# and per-developer; they must never be committed.
+/.claude/worktrees/
+
+# Codex CLI per-session worktrees (Codex equivalent of the above).
+/.codex/worktrees/
+
+# Lisa backup snapshots (created by `lisa` runs).
+/.lisabak/
+# END: AI GUARDRAILS WIKI

package/plugins/src/base/hooks/inject-rules.sh

@@ -1,12 +1,23 @@
 #!/usr/bin/env bash
-# Reads all .md files from the plugin's rules/ directory and injects them
+# Reads all .md files from the plugin's rules/eager/ directory and injects them
 # into the session context via additionalContext.
 # Used by SessionStart and SubagentStart hooks.
+#
+# The split between eager and reference rules is documented in
+# rules/eager/00-bootstrap.md (or the equivalent README). Reference bodies
+# under rules/reference/ are installed alongside but loaded only when the
+# eager breadcrumb points to them.
 set -euo pipefail
 
-RULES_DIR="${CLAUDE_PLUGIN_ROOT}/rules"
+RULES_DIR="${CLAUDE_PLUGIN_ROOT}/rules/eager"
 
-# Bail silently if no rules directory
+# Backward compatibility: if the eager subdir is absent (older Lisa install),
+# fall back to the flat rules/ directory so a partial upgrade still ships rules.
+if [ ! -d "$RULES_DIR" ]; then
+  RULES_DIR="${CLAUDE_PLUGIN_ROOT}/rules"
+fi
+
+# Bail silently if no rules directory at all
 [ -d "$RULES_DIR" ] || exit 0
 
 CONTEXT=""

package/plugins/src/base/rules/eager/base-rules.md

@@ -0,0 +1,70 @@
+# Base Rules (load-bearing)
+
+These are mandatory disciplines that apply to every session. Full prose, JIRA dev-status query, ADF templates, etc. live in [reference/base-rules.md](../reference/base-rules.md).
+
+## Requirement Verification
+
+Treat every request as potentially underspecified. Before starting any work:
+
+1. Identify ambiguities that would prevent completion. If any exist, stop and ask.
+2. Identify open questions whose answers would change your approach. If any exist, stop and ask.
+3. Define how you will empirically verify the work is complete by USING the resulting software, not just running tests. If you cannot define this, stop and ask.
+4. If a request contradicts existing code/architecture/conventions, raise the contradiction and confirm intent before proceeding.
+
+Do not begin work if there are blockers, ambiguities, access requirements, or unanswered questions. Identify these before starting, not during implementation.
+
+## Code Quality
+
+- Atomic commits with conventional commit messages.
+- Document the **why**, not the what.
+- Add new imports and their first usage in the same edit (the lint-on-edit hook strips unused imports).
+- Delete old code completely when replacing it. No deprecation comments unless asked.
+- Fix bugs at root cause. Never work around them or assume a failure is "pre-existing."
+- Test empirically. Never assume test expectations before observing actual behavior.
+
+## Git Discipline
+
+- **Never use `--no-verify`** or bypass any git hook.
+- **Never bypass branch protection** — no `--admin`, `--force`, no merging a PR with failing CI. "Green in CI" is the definition of done.
+- Never commit directly to environment branches (`dev`, `staging`, `main`).
+- Prefix `git push` with `GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5"`.
+- When opening a PR, watch it. Fix every failing check and every valid bot review comment. Resolve threads. Loop until merged.
+- After merging into an environment branch, watch the deploy. If it fails, fix it and open a new PR.
+- **Promotion PRs** (env→env) MUST use `gh pr merge --merge` (regular merge commit), NEVER squash. Squashing strips `[skip ci]` markers and breaks promotion detection. Feature PRs also use `--merge`.
+- Always include the PR URL when referencing a PR.
+
+## Testing Discipline
+
+- Never skip or disable tests. Never add skip directives without explicit instruction.
+- Never lower coverage thresholds to pass a hook — raise coverage instead.
+
+## JIRA Discipline
+
+- Read **all** comments on a ticket, not just the description.
+- When clarifying, comment via ADF and @mention the Reporter.
+- Establish issue link relationships (`blocks`, `is blocked by`, `relates to`) — search git history AND Jira before declaring "no related work."
+- Single-repo invariant: Bug/Task/Sub-task MUST be single-repo. Epic/Story/Spike MAY span repos. Cross-repo leaves are split per the `repo-scope-split` rule.
+- Pre-flight gate: BLOCK + reassign-to-Reporter if a ticket is missing target backend env, sign-in credentials, Gherkin acceptance criteria, epic parent (non-bug/non-epic), or relationship discovery evidence.
+
+## Pace
+
+Never rush. A fast wrong answer is worse than a slow correct one. Surface difficulty to the user instead of compressing the work.
+
+## NEVER
+
+- Modify this file directly.
+- Touch files inside `node_modules`, `.venv`, `vendor`, `target`.
+- Delete anything untracked, or anything outside this project.
+- Create placeholders, TODOs, versioned copies (`V2`, `processNew`, `handleOld`).
+- Write migration code unless explicitly requested.
+- Update CHANGELOG yourself.
+
+## ASK FIRST
+
+- Before adding a lint/formatter suppression (`eslint-disable`, `biome-ignore`, `noqa`, etc.).
+- Before adding a type-check suppression (`ts-ignore`, `ts-expect-error`, `# type: ignore`).
+- Lint suppression in test files is OK without asking only when comprehensive coverage genuinely requires it.
+
+## Multi-Repository Awareness
+
+If you see imports that don't resolve, API calls without a contract, shared libs not present, env vars naming foreign services, stack traces pointing out-of-repo, or ticket references to other components — stop guessing. Identify the repo, add it to the session, or ask.

package/plugins/src/base/rules/eager/coding-philosophy.md

@@ -0,0 +1,27 @@
+# Coding Philosophy (load-bearing)
+
+When writing or modifying code, follow these principles. Examples, hook structure templates, and anti-pattern catalogs live in [reference/coding-philosophy.md](../reference/coding-philosophy.md).
+
+## Principle priority
+
+**KISS is the tiebreaker.** When principles conflict, choose the simpler solution.
+
+1. **YAGNI** — Don't build features, abstractions, or flexibility you don't need right now. Solve today's problem.
+2. **KISS** — Choose the simpler option.
+3. **DRY** — Extract only when (a) the same logic appears 3+ times, (b) the abstraction is simpler than the duplication, and (c) the extracted code has a clear single purpose.
+4. **SOLID** — Apply pragmatically. Split a function only when it does 2+ unrelated things AND splitting reduces complexity. Use composition over inheritance.
+
+## Mandatory practices
+
+- **Immutability first.** Never mutate. Spread/clone to create new references.
+- **TDD is mandatory.** Write the failing test BEFORE the implementation. Red → Green → Refactor.
+- **Function structure order**: (1) variables & derived state, (2) side effects, (3) return. Never interleave.
+- **Functional transformations.** Prefer `map`/`filter`/`reduce` over imperative loops with mutation.
+- **Clean deletion.** When replacing code, delete the old version completely. No `V2`/`Old`/`New` suffixes, no `@deprecated` comments, no migration shims unless explicitly requested. Trust git history.
+
+## What NOT to write
+
+- Comments that explain WHAT the code does (well-named identifiers do that).
+- Error handling, fallbacks, or validation for scenarios that can't happen.
+- Backwards-compatibility shims, feature flags, or unused `_var` renames when you can just change the code.
+- Half-finished implementations, placeholders, or TODOs.

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

@@ -0,0 +1,28 @@
+# Config Resolution (load-bearing)
+
+Lisa configuration lives in `.lisa.config.json` (committed) and `.lisa.config.local.json` (gitignored, per-developer). The local file wins where they overlap. Developer-specific identity (`atlassian.email`, etc.) MUST live in the local file, never committed.
+
+## Atlassian access — assistant-level rule
+
+When the user asks about Atlassian (Jira / Confluence) connection state, or you are about to run a Jira/Confluence operation, and `acli` is installed:
+
+1. Run `acli auth status` and read the active `Site:`.
+2. Read `atlassian.site` from `.lisa.config.json` (and `atlassian.email` from `.lisa.config.local.json` if present).
+3. **If the active site does not match config, do NOT report "not connected." Run:**
+   ```sh
+   acli auth switch --site "$ATLASSIAN_SITE" --email "$ATLASSIAN_EMAIL"
+   ```
+   acli supports multiple authenticated profiles; the switch is fast and non-interactive when a profile already exists.
+4. Only after the switch fails (no matching profile) should you report not-connected and suggest `/lisa:setup:atlassian` to add one.
+
+This applies before declaring connection state, before running any `acli jira *` / `acli confluence *` command, and before falling back to the Atlassian MCP or curl substrates. Identity mismatch is treated as silent-misroute risk, not as a hard not-connected.
+
+## Tracker selection
+
+Project tracker (`jira` / `github` / `linear`) is read from `.lisa.config.json` `tracker`. Vendor-neutral skills MUST dispatch through the configured tracker, never infer it from arguments. Missing `tracker` → stop and instruct the user to run the matching `/lisa:setup:*` skill.
+
+## Repo identity
+
+`repo:<name>` is the canonical label for which repo a work item belongs to. Resolve current-repo identity in this priority order: `.lisa.config.local.json` `repo` → `.lisa.config.json` `repo` → `.lisa.config.json` `github.repo` → `basename -s .git "$(git remote get-url origin)"`. If none resolve, stop with a clear error.
+
+Full reference: [reference/config-resolution.md](../reference/config-resolution.md).

package/plugins/src/base/rules/eager/documentation-source-paths.md

@@ -0,0 +1,13 @@
+# Documentation Source Paths (load-bearing)
+
+Do not treat `docs/`, `research/`, `transcripts/`, or other source-material directories as disposable duplicates just because a project also has a `wiki/`. They may be ingestion inputs, executable fixtures, runtime inputs, or historical evidence.
+
+Before moving, absorbing, or deleting documentation-like paths:
+
+1. Classify each path: durable wiki content, reader-safe source note, executable test fixture, runtime scratch/input, generated output, or obsolete.
+2. Use `rg` to find every code, test, script, config, README, rule, skill, agent, and wiki reference to the path.
+3. Preserve executable fixtures and runtime inputs OUTSIDE the wiki — they are project behavior, not documentation.
+4. When absorbing into `wiki/`, update source notes, indexes, logs, README links, rule references, and runtime defaults that pointed at the old path.
+5. Delete a path only AFTER references are updated and verification proves the project no longer reads it.
+
+Full context (Lisa-wiki specifics, `wiki/sources/` evidence layout): [reference/documentation-source-paths.md](../reference/documentation-source-paths.md).

package/plugins/src/base/rules/eager/empirical-inquiry.md

@@ -0,0 +1,22 @@
+# Empirical Inquiry — Test, Don't Guess (load-bearing)
+
+When a decision depends on a fact you are not certain of — how a tool, API, harness, runtime, or dependency actually behaves — **find out empirically before you act.** Run the smallest experiment that settles the question, observe the real result, and proceed from what you observed.
+
+Do not reason your way to a confident-sounding answer from documentation, prior assumption, or training knowledge when the real system is right there and a quick probe would tell you the truth.
+
+## How to apply
+
+1. **State the uncertain fact** explicitly, so you know what the experiment must resolve.
+2. **Run the cheapest probe** that produces real evidence — a single command, a one-shot subagent, a tiny script, a direct API call against a scratch input.
+3. **Report the raw result** (verbatim output or error), then your conclusion. Distinguish observation from inference.
+4. **Encode the verified fact**, and when non-obvious or contradicting docs, record WHY so the next agent inherits the finding.
+
+## Forbidden
+
+- Presenting a guess, recollection, or doc summary as established fact when it was cheap to verify and you did not.
+- "Should work" / "probably" / "the docs say" as the basis for a load-bearing decision an experiment could have settled.
+- Skipping the probe because the answer "seems obvious" — those are exactly the ones that quietly drift from reality.
+
+This is the inquiry counterpart to the `verification` rule (which proves completed work behaves correctly). Both reject "it looks correct" as evidence.
+
+Full prose: [reference/empirical-inquiry.md](../reference/empirical-inquiry.md).

package/plugins/src/base/rules/eager/intent-routing.md

@@ -0,0 +1,18 @@
+# Intent Routing (load-bearing)
+
+**On the first user message of a session**, before responding to the substance of the request, before running any tool, before asking any clarifying question:
+
+1. **Classify the flow.** One of: Research, Plan, Implement (Build/Fix/Improve/Investigate-Only), Verify, Monitor, Intake, Debrief, or No flow. If a slash command was invoked, the flow is already determined.
+2. **Echo the chosen flow** with a one-sentence justification. Example:
+   > **Flow: Implement/Fix** — bug report with reproduction steps.
+3. **Echo orchestration mode in the same message.** One of:
+   > **Orchestration: agent team** — Research, Plan, Implement, Intake, Debrief, and any flow that invokes Review.
+   > **Orchestration: single agent** — Verify (standalone), Monitor (standalone), product-walkthrough standalone, debrief-apply, one-off diagnostic sessions.
+4. **Check the readiness gate.** If gate fails interactively, ask for what's missing with recommended answers; do not start work. Headless/`-p` sessions infer from available context instead of blocking.
+5. **Cascade rule.** If you are already inside an agent team (a TeamCreate succeeded earlier this session, or you were spawned into a team context), do **not** create a second team. Add specialists through the existing lead. On Claude, teams are flat — message the lead with teammate + assignment. On Codex, use `multi_agent_v1.spawn_agent`.
+
+Once a flow is established, **do not re-classify** on later messages, even if a follow-up looks vague ("now run the tests", "thanks"). Subsequent messages inherit the established flow unless the user explicitly changes scope.
+
+Skipping classification or orchestration echo leads to unstructured responses that bypass readiness gates.
+
+Full reference (flow definitions, readiness gates, orchestration matrix, sub-flows): [reference/intent-routing.md](../reference/intent-routing.md).

package/plugins/src/base/rules/eager/leaf-only-lifecycle.md

@@ -0,0 +1,39 @@
+# Leaf-Only Build-Ready Invariant (load-bearing)
+
+**Build-ready means a directly implementable leaf work unit.** Containers never carry build-ready.
+
+A leaf is structurally defined: **no child work** AND a leaf-typed item (Bug, Task, Sub-task, Improvement). A container is a parent with children — Epic, Story, Spike, or any item that has acquired sub-items.
+
+## Invariant
+
+- **At decomposition/write time** — only leaves receive the `ready` role. Parent containers are created in their non-ready state.
+- **At validate time** — `*-validate-*` FAILs any container carrying the build-ready role.
+- **At claim time** — build-intake claims leaves only. A container with a stale build-ready role is rolled up or safe-blocked, NEVER implemented.
+
+## Childless-parent exception
+
+A container *type* with no children is structurally a leaf — and may be build-ready iff its type is itself a leaf type:
+
+- **Task or Bug with no children** → leaf → may be build-ready.
+- **Epic, Story, or Spike with no children** → still NOT build-ready. These are coordination containers by design; an empty one is incomplete decomposition. Repair: decompose into leaves, or reclassify to a leaf type.
+
+## Parent state rollup (priority order, first match wins)
+
+1. Any leaf is **blocked** → parent rolls up to **blocked / attention-needed**.
+2. Else any leaf is **claimed or in review** → parent is **in-progress**.
+3. Else all required leaves are **terminal (`done`)** → parent reaches the configured rollup terminal (env-keyed `done`).
+4. Else (leaves exist but none started) → parent unchanged.
+
+**Blocked dominates.** Optional/won't-do children do not hold a parent open. Rollup is recursive — bottom-up. The parent never carries `ready`.
+
+## Terminal native closure
+
+When a leaf reaches the true terminal `done` (the production / final-env value), also finalize via the tracker's native completion mechanism:
+
+- **GitHub** — `gh issue close <n> --reason completed` after the terminal label.
+- **Linear** — move workflow `state` to the team's Done.
+- **JIRA** — transition to terminal Done/Resolved/Closed; verify `statusCategory = Done`.
+
+Intermediate env-keyed states (`status:on-dev`, `On Stg`, etc.) remain open. Idempotent — if already closed, report and continue.
+
+Full vendor mechanics + the state machine in prose: [reference/leaf-only-lifecycle.md](../reference/leaf-only-lifecycle.md).

package/plugins/src/base/rules/eager/prd-lifecycle-rollup.md

@@ -0,0 +1,31 @@
+# PRD Lifecycle Rollup & Generated-Top-Level-Work Contract (load-bearing)
+
+The vendor-neutral source of truth for how a PRD owns the work it generated and how its lifecycle rolls up to `shipped`. Companion to `leaf-only-lifecycle` (which governs build-lifecycle of leaves); this rule governs PRD lifecycle and rollup from generated top-level children.
+
+## Generated top-level work (the contract)
+
+A PRD owns the work units it created **at the top of the hierarchy** — the Epic(s) and any top-level Story it created directly. It does NOT own descendants (Sub-tasks, Stories under an Epic, leaves under a top-level unit) — those are owned by their top-level parent and roll up via `leaf-only-lifecycle`.
+
+Leaf Sub-tasks are **never** direct children of a PRD when a top-level Epic/Story hierarchy exists.
+
+## How each vendor records the PRD→child link
+
+**Native hierarchy first**, machine-readable fallback section always written:
+
+- **GitHub Issues** — native sub-issues when source and tracker are the same repo + supports sub-issues.
+- **Linear** — `parentId` or generated Project grouping where the PRD also lives in Linear.
+- **JIRA** — Epic link / parent field, or documented issue-link type.
+- **Confluence / Notion** — no native issue hierarchy; the documented `## Tickets` / `## Generated Work` section IS the source of truth.
+- **Cross-vendor** (e.g. Notion PRD → JIRA tracker) — always documented section in the PRD source.
+
+The documented `## Tickets` section is ALWAYS written (additive to native links) so the generated set is readable without parsing comments.
+
+## Rollup transition
+
+PRD rolls from `ticketed` to `shipped` when every required generated top-level child is terminal. The PRD remains open for `/lisa:verify-prd` after `shipped` — verified PASS performs native closure (archive/close/transition), verified FAIL re-opens to `ticketed` with build-ready fix tickets (never `blocked`).
+
+## Idempotency dedupe key
+
+Re-runs of intake/backlink must dedupe by child-ref identity (e.g. `owner/repo#number` for GitHub, Linear issue UUID, JIRA key) — never by URL string, which varies by formatting.
+
+Full vendor matrix, predicate definitions, non-goals: [reference/prd-lifecycle-rollup.md](../reference/prd-lifecycle-rollup.md).