@codyswann/lisa 2.200.0 → 2.202.0

package/README.md

@@ -1,6 +1,6 @@
 # Lisa
 
-Lisa is governance-as-code for AI-assisted software development. It makes one set of standards, workflows, and quality gates apply identically whether the work is done by a human, by an AI agent on a laptop, or by an automated job in CI — and it distributes those standards to every project as a versioned dependency.
+Lisa turns a repository into a set of **software factories** — agent-operated production lines (Research → Plan → Implement → Verify) that build, verify, and ship software with as few humans as possible. Underneath the factories, Lisa is governance-as-code for AI-assisted software development: one set of standards, workflows, and quality gates applies identically whether the work is done by a human, by an AI agent on a laptop, or by a scheduled job — distributed to every project as a versioned dependency, and to every major coding agent platform (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) from one source.
 
 > **How to read this README**
 >
@@ -11,17 +11,29 @@ Lisa is governance-as-code for AI-assisted software development. It makes one se
 
 ## What Lisa is
 
-Lisa wears three faces from a single package:
+Lisa wears four faces from a single package:
 
+- **A factory operator.** Scheduled intake agents watch queues of ready work, adversarially gate what enters the pipeline, and run each item through Research → Plan → Implement → Verify without a human in the loop.
 - **A standards engine.** It applies a curated set of configs, CI workflows, git hooks, and project rules into a target repository and keeps them current as the package updates.
-- **An operating system for coding agents.** It ships the skills, commands, agent roles, rules, and hooks that define *how* an AI agent investigates, builds, reviews, ships, and verifies work — and it delivers that same content to several different agent runtimes from one source.
+- **An operating system for coding agents.** It ships the skills, commands, agent roles, rules, and hooks that define *how* an AI agent investigates, builds, reviews, ships, and verifies work — and it delivers that same content to every supported agent runtime from one source.
 - **A configuration library.** Projects can consume Lisa's linting, testing, and TypeScript presets directly, per technology stack, without adopting the rest.
 
-All three are versioned together, so "how we build software here" upgrades by bumping one dependency.
+All four are versioned together, so "how we build software here" upgrades by bumping one dependency.
 
 > **Prompt for your coding agent**
 > "Give me a one-paragraph tour of this repository's top-level layout: where the apply/template engine lives, where the agent plugin content is authored, and where the shared config presets are exported. Read the source and cite paths."
 
+## The factory model
+
+Lisa's purpose is to run four **factories** in your project — production lines operated by agents, not people — so that **non-technical people can create scalable software** by describing outcomes while the factories supply the engineering discipline. **Research** creates PRDs. **Plan** turns a PRD into ordered work units. **Implement** turns work units into quality software — tests, code, UI, APIs, infrastructure. **Verify** issues a go/no-go by using the software the way a human would, and files any failures straight back into Implement as build-ready tickets, so the loop heals itself.
+
+Humans don't work inside a factory. Handoff happens outside, at the **gates**: agents, humans, and automations submit inputs, and an intake agent adversarially evaluates each one — is it high-quality and unambiguous, and does the factory have the tooling *and provable access to that tooling* to execute it? The intake agent tries to resolve gaps itself first; what it genuinely can't resolve, it rejects and raises to a human rather than guessing.
+
+Three loops keep the pipeline fed without anyone asking: **QA** explores the product like a first-time user and files bugs, **Product Planning** ideates PRDs, and **Monitoring** audits observability signals and files regressions. Everything runs on the coding agent's native scheduler, and by default the loops' outputs enter the gates pickup-ready — the adversarial intake is the quality control, not a human triager. Executed properly, end users have zero direct contact with coding agents: they see the tracker, the PRDs, and the shipped software.
+
+> **Prompt for your coding agent**
+> "Explain how this project's factory pipeline is wired right now: which automations exist and on what cadence, what each gate checks before admitting work, and where a human is still required. Read the installed automations and intake skills — don't guess."
+
 ## Core principles
 
 These are the durable ideas. Everything concrete descends from them.
@@ -79,12 +91,12 @@ The supported stacks, setup flags, and exact invocation evolve as the project gr
 
 ## The work lifecycle
 
-Lisa organizes a piece of work as a pipeline of specialized agent roles. Conceptually it moves through five stages:
+Lisa organizes a piece of work as a pipeline of specialized agent roles — the factories, seen from inside. Conceptually a work item moves through five stages:
 
-1. **Understand** — investigate the codebase and the problem, produce a spec or PRD.
-2. **Plan** — decompose the spec into ordered work items in your tracker.
-3. **Build** — take one item from spec to a merged PR: a team of agents implements, reviews, and ships it.
-4. **Prove** — deploy, verify the behavior in the target environment with real evidence, and turn a passing manual check into a regression test.
+1. **Understand** *(the Research factory)* — investigate the codebase and the problem, produce a spec or PRD.
+2. **Plan** *(the Plan factory)* — decompose the spec into ordered work items in your tracker.
+3. **Build** *(the Implement factory)* — take one item from spec to a merged PR: a team of agents implements, reviews, and ships it.
+4. **Prove** *(the Verify factory)* — deploy, verify the behavior in the target environment with real evidence, and turn a passing manual check into a regression test.
 5. **Learn** — after shipping, mine the work for edge cases and friction and fold accepted learnings back into the standards.
 
 Most people invoke only the first stages explicitly; the rest run as nested sub-flows. The same logic runs whether you trigger it by hand or a scheduled job triggers it unattended.
@@ -94,7 +106,7 @@ Most people invoke only the first stages explicitly; the rest run as nested sub-
 
 ### Unattended and batch work
 
-Lisa can watch a queue of ready work and dispatch each item through the lifecycle on its own, which is what makes it usable as a scheduled operator. It can also recover queues that are stuck and report whether the automation fleet is healthy.
+Lisa can watch a queue of ready work and dispatch each item through the lifecycle on its own, which is what makes it usable as a scheduled operator. A standard automation fleet covers the pipeline movers (PRD intake, ticket intake, queue repair) and the three feeding loops (exploratory QA, product ideation, observability monitoring); Lisa can also recover queues that are stuck and report whether the fleet is healthy.
 
 > **Prompt for your coding agent**
 > "Which commands let this Lisa scan a work queue, dispatch ready items, repair stuck ones, and report on scheduled-automation health? Show me how I'd point one at my queue and what it expects in configuration."

package/package.json

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

package/plugins/lisa/.codex-plugin/skills/lisa-automation-status/SKILL.md

@@ -23,6 +23,7 @@ Inspect only the Lisa automation fleet for the current project:
 - `intake-tickets`
 - `exploratory-bugs` when the current stack supports `exploratory-qa`
 - `exploratory-prds`
+- `monitor`
 
 Resolve the expected project identifier, fleet naming prefix, queue arguments, cadence, and stack-support rules from the same contract used by `setup-automations` and `tear-down-automations`. Do **not** invent a second source of truth for fleet naming or queue resolution.
 

package/plugins/lisa/.codex-plugin/skills/lisa-doctor/SKILL.md

@@ -291,6 +291,62 @@ without turning the base doctor into a second `lisa-wiki-doctor`.
    - Never require a wiki plugin surface when `wiki/` is absent.
    - Never let wiki-specific checks downgrade unrelated non-wiki repositories.
 
+### Upstream Lisa change-history diagnosis
+
+A failing or warning check has two possible causes: the project drifted, or **Lisa itself changed
+upstream** since this project last updated. Doctor must distinguish them instead of blaming the
+project by default. Whenever findings need explanation — and always before proposing repairs —
+pull Lisa's own git history and read what actually changed:
+
+1. **Resolve the version window.** Determine the project's installed Lisa version (the
+   `@codyswann/lisa` entry in `package.json`/lockfile, or the plugin version stamp on the active
+   runtime) and the latest published version (`npm view @codyswann/lisa version`, or the update
+   check's cached result).
+2. **Pull the upstream history for that window** (read-only; no clone required when `gh` is
+   available):
+
+   ```bash
+   gh api "repos/CodySwannGT/lisa/compare/v<installed>...v<latest>" \
+     --paginate --slurp \
+     --jq '{total_commits: .[0].total_commits, files: [.[0].files[]?.filename], commits: [.[].commits[]? | .commit.message | split("\n")[0]]}'
+   ```
+
+   `--paginate` fetches every page of commits, and `--slurp` gathers those pages into a single
+   array before `--jq` runs — without `--slurp`, `--jq` applies per page and prints one JSON object
+   per page instead of one merged result. `total_commits` and `files` only need the first page
+   (files are capped at 300 and not repeated on later pages); `commits` flattens across all pages.
+
+   The compare endpoint paginates commits (250 without `--paginate`) and only lists changed files
+   on the first page, capped at 300 total — a large version window can silently drop commits or
+   files. If `total_commits` or the file count looks truncated, re-run with the
+   `application/vnd.github.diff` accept header (`gh api ... -H "Accept: application/vnd.github.diff"`)
+   to pull the full patch text, or fall back to the shallow-clone `git log` below. When completeness
+   still can't be established, say so in the finding and mark it `WARN` rather than attributing
+   drift with unverified confidence.
+
+   Fallbacks, in order: `gh api repos/CodySwannGT/lisa/commits?path=<template-path>` for a
+   path-scoped view — note this endpoint has no way to bound results to the `v<installed>..v<latest>`
+   window, so treat its output as best-effort context only, not authoritative attribution; a shallow
+   clone (`git clone --filter=blob:none --no-checkout` then `git log v<installed>..v<latest> --
+   <paths>`), which *is* bounded to the window and should be preferred for definitive attribution; or
+   the local marketplace/plugin cache checkout when the runtime has one. If none are reachable, or
+   only the unbounded path-scoped fallback is reachable, report the gap as a `WARN`-level
+   observability note — never fail the audit because history was unavailable or incomplete.
+3. **Scope the reading to what the finding touches.** Filter the commit list to the paths that
+   generate the failing surface: the detected stacks' template dirs (`typescript/`, `expo/`, …),
+   `plugins/src/base/` for skills/hooks/rules, `scripts/` for governance scripts, and the shipped
+   config factories (`src/configs/`). A finding about a lint rule failure reads the lint-config
+   commits, not the whole log.
+4. **Attribute the finding.** When the upstream history shows Lisa changed the contract (a
+   tightened lint rule, a renamed check context, a new required config key), say so in `Observed:`
+   with the commit subject/version, and let `Remediation:` point at the sanctioned adoption path
+   (e.g. `lisa update` + re-apply, a documented config opt-out) rather than hand-editing managed
+   files. When history shows no relevant upstream change, the project drifted — remediate on the
+   project side.
+
+This history pull is part of doctor's read-only contract: it reads Lisa's repository, never writes
+to it, and repair suggestions stay suggestions.
+
 ## Output contract
 
 The final report must:

package/plugins/lisa/.codex-plugin/skills/lisa-github-validate-issue/SKILL.md

@@ -96,6 +96,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | F2 Parent sub-issue exists and is the right type | `structural` | false |
 | F3 Linked issues exist | `structural` | false |
 | F4 Required labels populated | `structural` | false |
+| F5 Required external access provable | `technical` | true |
 
 Category values are the same fixed set as `lisa-jira-validate-ticket`:
 
@@ -257,6 +258,31 @@ For each entry in `links`, run `gh issue view <number> --repo <link-org>/<link-r
 
 Per `Phase 5` of `lisa-github-write-issue`, every issue MUST carry: `type:<issue_type>`, `status:<status>`, `priority:<priority>`. If any are missing from the spec / live issue, FAIL with the missing label name.
 
+#### F5 — Required external access provable
+
+The factory-gate rule: an input must not enter the pipeline unless the current runtime can actually
+reach every external surface the work requires. Enumerate the surfaces this issue depends on:
+
+- artifact links in the body (documents, designs, dashboards, spreadsheets, recordings),
+- systems named by the description, acceptance criteria, or Validation Journey ("read the CloudWatch
+  alarms", "pull the copy from the Google Doc", "check the Sentry issues"),
+- tooling the work plainly implies (a deploy target, a database, a third-party API).
+
+For each surface, prove **read** access from the current runtime with the cheapest read-only probe
+through the sanctioned access layer: the matching MCP tool or `lisa-*-access` skill, CLI auth
+(`aws sts get-caller-identity`, `gh auth status`, vendor equivalents), or an authenticated fetch of
+the linked artifact. Attempt to resolve a gap before failing — an alternate substrate, a configured
+access layer, a keychain credential — mirroring the intake agent's discover-first duty.
+
+- `PASS` — every required surface is provably readable.
+- `N/A` — the issue needs nothing beyond the repository and the tracker itself.
+- `FAIL` — a required surface is unreachable after the resolution attempt. Name the exact surface
+  and what was probed. Intake callers must route this to `blocked` + human escalation with the
+  missing access spelled out — an input the factory cannot execute never enters the factory.
+
+Probes are read-only and bounded (seconds, not minutes, per surface); never mutate the external
+system, and never invent or ask for credentials inline.
+
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's an issue ref, fetch via `gh issue view --json` and derive the spec fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (native sub-issues plus body task-list / `Blocked by #<n>` parentage, resolved as in `lisa-github-read-issue`) so S15 can classify the issue. Otherwise parse the YAML spec.
@@ -294,6 +320,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] F2 Parent sub-issue exists and is the right type — <one-line reason>
 - [PASS|FAIL|N/A] F3 Linked issues exist — <one-line reason>
 - [PASS|FAIL|N/A] F4 Required labels populated — <one-line reason>
+- [PASS|FAIL|N/A] F5 Required external access provable — <one-line reason>
 
 ### Verdict: PASS | FAIL
 ### Failures: <count>
@@ -313,7 +340,7 @@ The verdict is `PASS` if every applicable gate is `PASS`. Any `FAIL` makes the v
 
 Same shape and meaning as `lisa-jira-validate-ticket` so downstream PRD-intake skills (Notion, Confluence, Linear, GitHub) can format comments uniformly:
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F4`).
+- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem the caller should fix without bothering product.
 - **what**: plain-language, product-readable.

package/plugins/lisa/.codex-plugin/skills/lisa-jira-validate-ticket/SKILL.md

@@ -93,6 +93,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | F2 Epic parent exists and is an Epic | `structural` | false |
 | F3 Linked tickets exist | `structural` | false |
 | F4 Required custom fields populated | `structural` | false |
+| F5 Required external access provable | `technical` | true |
 
 Category values are drawn from this fixed set:
 
@@ -246,6 +247,31 @@ For each entry in `links`, invoke `lisa-atlassian-access` `operation: read-ticke
 
 Use the same project-issue-type-metadata lookup from F1 (via `lisa-atlassian-access`) to learn required custom fields for the issue type. Any required custom field not provided in the spec: FAIL.
 
+#### F5 — Required external access provable
+
+The factory-gate rule: an input must not enter the pipeline unless the current runtime can actually
+reach every external surface the work requires. Enumerate the surfaces this item depends on:
+
+- artifact links in the body (documents, designs, dashboards, spreadsheets, recordings),
+- systems named by the description, acceptance criteria, or Validation Journey ("read the CloudWatch
+  alarms", "pull the copy from the Google Doc", "check the Sentry issues"),
+- tooling the work plainly implies (a deploy target, a database, a third-party API).
+
+For each surface, prove **read** access from the current runtime with the cheapest read-only probe
+through the sanctioned access layer: the matching MCP tool or `lisa-*-access` skill, CLI auth
+(`aws sts get-caller-identity`, `gh auth status`, vendor equivalents), or an authenticated fetch of
+the linked artifact. Attempt to resolve a gap before failing — an alternate substrate, a configured
+access layer, a keychain credential — mirroring the intake agent's discover-first duty.
+
+- `PASS` — every required surface is provably readable.
+- `N/A` — the item needs nothing beyond the repository and the tracker itself.
+- `FAIL` — a required surface is unreachable after the resolution attempt. Name the exact surface
+  and what was probed. Intake callers must route this to `blocked` + human escalation with the
+  missing access spelled out — an input the factory cannot execute never enters the factory.
+
+Probes are read-only and bounded (seconds, not minutes, per surface); never mutate the external
+system, and never invent or ask for credentials inline.
+
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's a ticket key, fetch the ticket via `lisa-atlassian-access` `operation: read-ticket` and derive the spec from the fetched fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-tasks plus `is blocked by` parentage, resolved as in `lisa-jira-read-ticket`) so S15 can classify the ticket. When the fetched description is ADF, walk the document tree and extract section headings from ADF `heading` nodes, then collect the text between heading nodes for section-specific gates. If the fetched description is a single paragraph containing literal Markdown/wiki heading markers, treat that as a formatting failure rather than accepting substring matches. Otherwise parse the YAML spec.
@@ -283,6 +309,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] F2 Epic parent exists and is an Epic — <one-line reason>
 - [PASS|FAIL|N/A] F3 Linked tickets exist — <one-line reason>
 - [PASS|FAIL|N/A] F4 Required custom fields populated — <one-line reason>
+- [PASS|FAIL|N/A] F5 Required external access provable — <one-line reason>
 
 ### Verdict: PASS | FAIL
 ### Failures: <count>
@@ -301,7 +328,7 @@ The verdict is `PASS` if and only if every applicable gate is `PASS`. Any `FAIL`
 
 ### Failure-detail fields
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F4`).
+- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table above. Callers use this to label or filter comments — `product-clarity`, `acceptance-criteria`, `design-ux`, `scope`, `dependency`, `data`, `technical`, or `structural`.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem (e.g., the agent built a malformed spec, an issue type is invalid in the project) and the caller should fix it without bothering the product team. `true` means the PRD needs product input to resolve.
 - **what**: plain-language description of the issue. No gate IDs, no JIRA jargon, no engineering shorthand. A product owner reading this on a Notion comment should understand what is unclear and why.

package/plugins/lisa/.codex-plugin/skills/lisa-linear-validate-issue/SKILL.md

@@ -94,6 +94,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | F2 Project parent exists and is in same team | `structural` | false |
 | F3 Linked items exist | `structural` | false |
 | F4 Required labels exist (or can be created) | `structural` | false |
+| F5 Required external access provable | `technical` | true |
 
 Category values are the same fixed set as `lisa-jira-validate-ticket`:
 
@@ -253,6 +254,31 @@ For each entry in `relations`, call `lisa-linear-access operation: get-issue` to
 
 For each label referenced (`status:*`, `component:<name>`, `prd-*`), confirm via `lisa-linear-access operation: list-issue-labels` (or `lisa-linear-access operation: list-project-labels` for Project labels) that it exists OR is creatable. Linear labels are team-scoped or workspace-scoped; flag if the requested scope is wrong.
 
+#### F5 — Required external access provable
+
+The factory-gate rule: an input must not enter the pipeline unless the current runtime can actually
+reach every external surface the work requires. Enumerate the surfaces this item depends on:
+
+- artifact links in the body (documents, designs, dashboards, spreadsheets, recordings),
+- systems named by the description, acceptance criteria, or Validation Journey ("read the CloudWatch
+  alarms", "pull the copy from the Google Doc", "check the Sentry issues"),
+- tooling the work plainly implies (a deploy target, a database, a third-party API).
+
+For each surface, prove **read** access from the current runtime with the cheapest read-only probe
+through the sanctioned access layer: the matching MCP tool or `lisa-*-access` skill, CLI auth
+(`aws sts get-caller-identity`, `gh auth status`, vendor equivalents), or an authenticated fetch of
+the linked artifact. Attempt to resolve a gap before failing — an alternate substrate, a configured
+access layer, a keychain credential — mirroring the intake agent's discover-first duty.
+
+- `PASS` — every required surface is provably readable.
+- `N/A` — the item needs nothing beyond the repository and the tracker itself.
+- `FAIL` — a required surface is unreachable after the resolution attempt. Name the exact surface
+  and what was probed. Intake callers must route this to `blocked` + human escalation with the
+  missing access spelled out — an input the factory cannot execute never enters the factory.
+
+Probes are read-only and bounded (seconds, not minutes, per surface); never mutate the external
+system, and never invent or ask for credentials inline.
+
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's an identifier, fetch the item and derive the spec from the fetched fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-issues, project-member issues, plus `blocked_by` parentage, resolved as in `lisa-linear-read-issue`) so S15 can classify the item. Otherwise parse the YAML spec.
@@ -290,6 +316,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] F2 Project parent exists and is in same team — <one-line reason>
 - [PASS|FAIL|N/A] F3 Linked items exist — <one-line reason>
 - [PASS|FAIL|N/A] F4 Required labels exist (or can be created) — <one-line reason>
+- [PASS|FAIL|N/A] F5 Required external access provable — <one-line reason>
 
 ### Verdict: PASS | FAIL
 ### Failures: <count>

package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/SKILL.md

@@ -28,18 +28,20 @@ create them; invoke the runtime's automation tool with the spec below.
 
 ## Parameters
 
-- `auto-start-prds` (default **false**) — passed as `prd_ready` to the **exploratory-prds**
+- `auto-start-prds` (default **true**) — passed as `prd_ready` to the **exploratory-prds**
   automation. `true` → ideated PRDs are created `prd-ready` (auto-picked-up by PRD intake); `false` →
   created as drafts for human review. When `true`, `/lisa:project-ideation` still checks the configured
   PRD queue before writing: existing `prd-ready`, `prd-in-review`, `prd-blocked`, unresolved
   `prd-ticketed`, or unresolved source-reader pressure can intentionally turn the automation cycle into
   a blocked/idle outcome instead of creating another ready PRD.
-- `auto-start-tickets` (default **false**) — passed as `ready` to the **exploratory-bugs**
+- `auto-start-tickets` (default **true**) — passed as `ready` to the **exploratory-bugs**
   automation. `true` → filed bug/usability tickets are created build-ready (auto-picked-up by ticket
   intake); `false` → created in the backlog for human triage.
 
-Defaults match the underlying skills — nothing auto-starts unless explicitly opted in. The two flags
-affect **only** the two exploratory automations.
+The defaults are autonomous by design — the factory model wants inputs flowing through the gates
+without a human between the loops and the pipeline. Pass `false` explicitly to opt a project into
+human triage. The two flags affect **only** the two exploratory automations; the intake gates'
+adversarial validation remains the quality control either way.
 
 ## The automations to create
 
@@ -62,6 +64,7 @@ report the exact conflicting path(s).
 | **intake-tickets** | `/lisa:intake <build queue>` (e.g. `github intake_mode=build`) | every **10 minutes** |
 | **exploratory-bugs** | `/lisa-<stack>:exploratory-qa ready=<auto-start-tickets>` | **once a day** |
 | **exploratory-prds** | `/lisa:project-ideation prd_ready=<auto-start-prds>` | **once a day** |
+| **monitor** | `/lisa:monitor` | **once a day** |
 
 For a Codex `rrule`: every 60 min → `FREQ=HOURLY;INTERVAL=1`; every 10 min →
 `FREQ=MINUTELY;INTERVAL=10`; once a day → `FREQ=DAILY;INTERVAL=1`.
@@ -92,6 +95,11 @@ place (same names) rather than creating duplicates.
 - **exploratory-bugs** is created only when the project ships an `exploratory-qa` command (the
   `expo` / `rails` / `harper-fabric` stacks). If the project has no `lisa-exploratory-qa` skill/command, skip that
   automation and note it — do not invent a command that doesn't exist.
+- **monitor** is created unconditionally: `/lisa:monitor` resolves the connected observability
+  providers itself and reports gaps (per its `monitor.gapTiers` config) rather than failing when a
+  provider is absent, so an unconnected project gets gap findings instead of a broken automation.
+  Its findings become tracker tickets, feeding the pipeline at the build gate like every other
+  input.
 - If the runtime has no native scheduler, or the intake queues can't be resolved from config, stop
   and report what's missing rather than guessing.
 - For Codex, if the durable checkout cannot be created, fetched, or verified as a non-bare Git work

package/plugins/lisa/.codex-plugin/skills/lisa-tear-down-automations/SKILL.md

@@ -21,9 +21,9 @@ removes them with its **native** scheduling mechanism.
 
 ## Scope (remove only what setup created)
 
-- Remove the five automations `/setup-automations` creates for the current project, matched by the
+- Remove the six automations `/setup-automations` creates for the current project, matched by the
   stable `lisa-auto-<project>-` name prefix: `intake-repair`, `intake-prd`, `intake-tickets`,
-  `exploratory-bugs`, `exploratory-prds`.
+  `exploratory-bugs`, `exploratory-prds`, `monitor`.
 - **Never** remove automations for a different project, or any non-Lisa automation (e.g. unrelated
   crawlers/ingestors). Match strictly on the `lisa-auto-<project>-` prefix for THIS project; when in
   doubt about an automation's ownership, leave it and report it rather than deleting it.

package/plugins/lisa/rules/eager/factory-model.md

@@ -0,0 +1,36 @@
+# The Factory Model (load-bearing)
+
+This project runs as a set of **software factories** — agent-operated production lines with as few
+humans as possible. You are factory machinery, not a chat assistant. Four factories: **Research**
+(creates PRDs) → **Plan** (PRDs → work units) → **Implement** (work units → quality software) →
+**Verify** (go/no-go by using the software like a human; failures become build-ready tickets that
+flow straight back into Implement).
+
+The rules that follow from this:
+
+1. **Humans are not inside the factories.** Never pause mid-flow to ask a human whether to proceed.
+   All handoff happens at the **gates** — the ready-role flips (`prd-ready`, `status:ready`) plus
+   intake's adversarial validation.
+2. **The gate is adversarial.** An input enters a factory only when it is high-quality,
+   unambiguous, and the factory has the tooling *and provable access to that tooling* to execute it
+   (validator gate F5). Try to discover the answers to gaps first; what you genuinely cannot
+   resolve, reject to `blocked` and raise to a human with the exact missing thing named.
+3. **Everything runs on schedule.** The intake, QA, Product Planning, and Monitoring loops run as
+   native automations (Claude Routines / Codex Automations). Every flow must therefore work
+   headless: no interactive prompts, idempotent re-runs, clean exits on empty queues.
+4. **Quality is enforced, not requested.** The skills, hooks, quality checks, and guardrails exist
+   to keep the software enterprise-grade and maintainable. Never weaken a gate to get work through
+   it — fix the work.
+5. **Write outward for a non-technical operator.** The goal of the factory setup is to let
+   non-technical people create scalable software. Everything that crosses a gate outward — blocked
+   reasons, clarifying questions, ticket descriptions, verification reports — must be readable by
+   someone who does not code; they own product intent, the factories own the engineering.
+6. **Every supported coding agent is a first-class operator.** Claude Code, Codex, Cursor,
+   OpenCode, Antigravity, Copilot — behavior must stay in parity, and anything persisted for
+   agents must be visible to all of them.
+
+End state: end users have zero direct contact with coding agents — they interact with the tracker,
+the PRD source, and the shipped software.
+
+Full reference (factory ↔ Lisa surface mapping, loop details, human exterior gates):
+[reference/factory-model.md](../reference/factory-model.md).

package/plugins/lisa/rules/reference/factory-model.md

@@ -0,0 +1,87 @@
+# The Factory Model
+
+Lisa's purpose is to run **software factories** in the host project: agent-operated production
+lines that research, plan, implement, and verify software with as few humans as possible. This
+reference maps the model onto the concrete Lisa surfaces so agents act on it rather than around it.
+
+## Who this is for
+
+The goal of the factory setup is to let **non-technical people create scalable, enterprise-grade
+software** by describing outcomes; the factories supply the engineering discipline. This lowers the
+floor without capping the ceiling — engineers get leverage from the same machinery — and it is why
+the validation gates carry product-readable failure text (`product_relevant`, plain-language
+`what`/`recommendation` fields): the person standing at the gate does not read stack traces. Every
+outward-facing artifact an agent produces (blocked reasons, clarifying questions, tickets,
+verification reports, console copy) is written for that operator.
+
+## The four factories
+
+| Factory | Creates | Lisa surface | Gate (input signal) |
+|---|---|---|---|
+| **Research** | PRDs | `/lisa:research`, `/lisa:project-ideation` | Prompts and ideation are the main entry points |
+| **Plan** | Work units (epics, stories, tickets, tasks) | `/lisa:plan` → the `*-to-tracker` pipeline | PRD flipped to `prd-ready`, claimed by PRD intake |
+| **Implement** | Quality software (tests, code, UI, APIs, infrastructure) | `/lisa:implement` → build flows | Work unit flipped to `status:ready`, claimed by build intake |
+| **Verify** | A go/no-go decision | `/lisa:verify-prd` (PRD level), `/lisa:verify` (change level) | Shipped PRD rolled up by intake |
+
+Verify's no-go path is deliberate: failures re-open the PRD as `ticketed` with **build-ready** fix
+tickets that flow straight back into Implement — never `blocked`. The loop is self-healing.
+
+## The gates
+
+Handoff happens **outside** the factories. Agents, humans, and automations submit inputs; the
+intake agent (`/lisa:intake`, the `*-prd-intake` / `*-build-intake` agents) adversarially evaluates
+each one:
+
+- **Quality**: the validation gates (three-audience description, Gherkin acceptance criteria,
+  Validation Journey, structure, scope).
+- **Executability**: the factory must have the tooling *and provable read access to that tooling*
+  for everything the input requires — linked documents, dashboards, cloud resources, third-party
+  APIs (validator gate **F5 — Required external access provable**). An input the factory cannot
+  execute never enters the factory.
+- **Discover-first duty**: intake tries to resolve gaps itself (alternate substrates, configured
+  access layers, searching for the missing context). What it genuinely cannot resolve it rejects —
+  `blocked` plus a human-needed marker, with clarifying questions or the exact missing access named.
+
+## The loops
+
+Three schedules feed the pipeline continuously, created by `/lisa:setup-automations` on the
+runtime's native scheduler (Claude Routines, Codex Automations):
+
+| Loop | Automation | Feeds | Cadence |
+|---|---|---|---|
+| QA | `exploratory-bugs` (`/lisa:exploratory-qa`) | Implement gate (bug tickets) | daily |
+| Product Planning | `exploratory-prds` (`/lisa:project-ideation`) | Research/Plan gate (PRDs) | daily |
+| Monitoring | `monitor` (`/lisa:monitor`) | Implement gate (regression tickets) | daily |
+
+Plus the pipeline movers: `intake-prd` (hourly), `intake-tickets` (every 10 minutes),
+`intake-repair` (hourly). **Autonomy is the default**: `auto-start-prds` and `auto-start-tickets`
+default to `true`, so loop outputs enter the gates pickup-ready and the adversarial intake is the
+quality control. Projects opt into human triage by passing `false`.
+
+## Where humans stand
+
+Humans act only at explicit exterior gates:
+
+- flipping a draft they chose to hold back to `prd-ready` / `status:ready`,
+- approving protected deployments (`github.environments.require_approval`),
+- reviewing low-confidence learning PRs (auto-merge off),
+- answering what intake rejected and raised.
+
+Inside a flow, never pause to ask a human whether to proceed — the invocation was the authorization.
+Headless discipline follows: no interactive prompts, idempotent re-runs, clean exits on empty
+queues, and loud, specific failures when something is genuinely blocking.
+
+## Quality and parity
+
+Everything else Lisa installs — skills, hooks, quality checks, guardrails, CI gates, rulesets —
+exists to enforce enterprise-grade quality and verification standards that keep the software
+maintainable. Never weaken a gate to get work through it; fix the work, or raise the
+risk-acceptance decision to a human.
+
+Every supported coding agent is a first-class factory operator: Claude Code, Codex, Cursor,
+OpenCode, Antigravity (agy), Copilot. Behavior stays in parity across them, and anything persisted
+for agents (rules, learnings, configuration) must be visible to all of them from a single source of
+truth.
+
+End state: end users have zero direct contact with coding agents. They interact with the tracker,
+the PRD source, and the shipped software — the factories do the rest.

package/plugins/lisa/skills/lisa-automation-status/SKILL.md

@@ -23,6 +23,7 @@ Inspect only the Lisa automation fleet for the current project:
 - `intake-tickets`
 - `exploratory-bugs` when the current stack supports `exploratory-qa`
 - `exploratory-prds`
+- `monitor`
 
 Resolve the expected project identifier, fleet naming prefix, queue arguments, cadence, and stack-support rules from the same contract used by `setup-automations` and `tear-down-automations`. Do **not** invent a second source of truth for fleet naming or queue resolution.
 

package/plugins/lisa/skills/lisa-doctor/SKILL.md

@@ -291,6 +291,62 @@ without turning the base doctor into a second `lisa-wiki-doctor`.
    - Never require a wiki plugin surface when `wiki/` is absent.
    - Never let wiki-specific checks downgrade unrelated non-wiki repositories.
 
+### Upstream Lisa change-history diagnosis
+
+A failing or warning check has two possible causes: the project drifted, or **Lisa itself changed
+upstream** since this project last updated. Doctor must distinguish them instead of blaming the
+project by default. Whenever findings need explanation — and always before proposing repairs —
+pull Lisa's own git history and read what actually changed:
+
+1. **Resolve the version window.** Determine the project's installed Lisa version (the
+   `@codyswann/lisa` entry in `package.json`/lockfile, or the plugin version stamp on the active
+   runtime) and the latest published version (`npm view @codyswann/lisa version`, or the update
+   check's cached result).
+2. **Pull the upstream history for that window** (read-only; no clone required when `gh` is
+   available):
+
+   ```bash
+   gh api "repos/CodySwannGT/lisa/compare/v<installed>...v<latest>" \
+     --paginate --slurp \
+     --jq '{total_commits: .[0].total_commits, files: [.[0].files[]?.filename], commits: [.[].commits[]? | .commit.message | split("\n")[0]]}'
+   ```
+
+   `--paginate` fetches every page of commits, and `--slurp` gathers those pages into a single
+   array before `--jq` runs — without `--slurp`, `--jq` applies per page and prints one JSON object
+   per page instead of one merged result. `total_commits` and `files` only need the first page
+   (files are capped at 300 and not repeated on later pages); `commits` flattens across all pages.
+
+   The compare endpoint paginates commits (250 without `--paginate`) and only lists changed files
+   on the first page, capped at 300 total — a large version window can silently drop commits or
+   files. If `total_commits` or the file count looks truncated, re-run with the
+   `application/vnd.github.diff` accept header (`gh api ... -H "Accept: application/vnd.github.diff"`)
+   to pull the full patch text, or fall back to the shallow-clone `git log` below. When completeness
+   still can't be established, say so in the finding and mark it `WARN` rather than attributing
+   drift with unverified confidence.
+
+   Fallbacks, in order: `gh api repos/CodySwannGT/lisa/commits?path=<template-path>` for a
+   path-scoped view — note this endpoint has no way to bound results to the `v<installed>..v<latest>`
+   window, so treat its output as best-effort context only, not authoritative attribution; a shallow
+   clone (`git clone --filter=blob:none --no-checkout` then `git log v<installed>..v<latest> --
+   <paths>`), which *is* bounded to the window and should be preferred for definitive attribution; or
+   the local marketplace/plugin cache checkout when the runtime has one. If none are reachable, or
+   only the unbounded path-scoped fallback is reachable, report the gap as a `WARN`-level
+   observability note — never fail the audit because history was unavailable or incomplete.
+3. **Scope the reading to what the finding touches.** Filter the commit list to the paths that
+   generate the failing surface: the detected stacks' template dirs (`typescript/`, `expo/`, …),
+   `plugins/src/base/` for skills/hooks/rules, `scripts/` for governance scripts, and the shipped
+   config factories (`src/configs/`). A finding about a lint rule failure reads the lint-config
+   commits, not the whole log.
+4. **Attribute the finding.** When the upstream history shows Lisa changed the contract (a
+   tightened lint rule, a renamed check context, a new required config key), say so in `Observed:`
+   with the commit subject/version, and let `Remediation:` point at the sanctioned adoption path
+   (e.g. `lisa update` + re-apply, a documented config opt-out) rather than hand-editing managed
+   files. When history shows no relevant upstream change, the project drifted — remediate on the
+   project side.
+
+This history pull is part of doctor's read-only contract: it reads Lisa's repository, never writes
+to it, and repair suggestions stay suggestions.
+
 ## Output contract
 
 The final report must: