@codyswann/lisa 2.199.0 → 2.200.0

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.199.0",
+  "version": "2.200.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-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.199.0",
+  "version": "2.200.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.199.0",
+  "version": "2.200.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-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.199.0",
+  "version": "2.200.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.199.0",
+  "version": "2.200.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.199.0",
+  "version": "2.200.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/ui/README.md

@@ -0,0 +1,180 @@
+# Lisa Console (UI prototype)
+
+A self-contained, zero-build prototype of the Lisa settings console. It catalogs
+every configuration surface Lisa exposes to host projects and presents it as a
+navigable, editable-looking settings UI.
+
+**Prototype scope:** every control is interactive (toggles, selects, inputs,
+tabs, dirty-state tracking, save bar), but edits are not persisted — "Save"
+only clears the in-memory dirty state. Reading real values IS wired up: see
+`lisa ui` below.
+
+## Run it
+
+The real entrypoint is the CLI, which populates and syncs the project's
+`.lisa.config.json` first (see `lisa sync`), then serves the console with the
+merged live config injected — controls whose config key exists show the
+project's actual values:
+
+```bash
+lisa ui [path] [--port 4780] [--no-sync]
+```
+
+The page is also fully standalone (no build step, no dependencies) — without
+live config it falls back to Lisa's shipped defaults:
+
+```bash
+open ui/index.html
+```
+
+## Config sync (`lisa sync`)
+
+`lisa sync [path] [--dry-run] [--json]` makes `.lisa.config.json` (with the
+gitignored `.lisa.config.local.json` overlay) the source of truth for every
+setting in `src/sync/registry.ts`:
+
+- **Populate** — a completely missing config value is absorbed from its
+  mirrored artifact file when one exists (e.g. `vitest.thresholds.json`),
+  otherwise filled with Lisa's built-in default. Vendor sections are only
+  populated when the project uses that vendor.
+- **Sync** — config values are written back into every mirrored artifact file
+  that exists on disk (config wins). Sync never scaffolds an artifact file
+  into a stack that doesn't use it.
+- **Provenance** — pure-default populations are recorded under
+  `_lisaSync.populated`, so when a later Lisa version changes a default, sync
+  can update values that are *still the default* while never touching values
+  a human chose.
+- **Required keys** (`tracker`, `jira.project`, `github.org`, …) can't be
+  invented; sync reports them (exit code 1) and points at the setup skill.
+
+Mirrored artifacts today: `vitest.thresholds.json` / `jest.thresholds.json`
+(`quality.testCoverage`), `eslint.thresholds.json` (`quality.lintBudgets`),
+`mutation.gate.json` (`quality.mutation.gate`), and the `thresholds` key of
+`stryker.conf.json` (`quality.mutation.strykerThresholds`).
+
+**Provider-neutral monitoring keys.** The observability audit spans Sentry,
+AWS CloudWatch Alarms, AWS X-Ray, and future providers, so
+`monitor.thresholds` uses vendor-free names: `minEvents24h` (default **1**)
+and `faultRatePct` replace the legacy `sentryMinEvents24h` /
+`xrayFaultRatePct`. The Monitoring section shows which providers are
+connected (detected from credentials and instrumentation, not configured by
+hand). The runtime `lisa-monitor` skill still reads the legacy keys —
+renaming them in `config-resolution.md` and the skill is a tracked
+follow-up.
+
+## Starter provenance & sync (planned — documented, not wired)
+
+The **Starter templates** section of the console documents this contract; no
+engine exists yet. A project records which starter repo(s) it was generated
+from (`lisa setup-project` already knows them — `src/cli/starters.ts`) and
+stays connected to them in both directions:
+
+```jsonc
+"starter": {
+  "templates": [
+    {
+      "repo": "CodySwannGT/expostarter",   // origin starter
+      "ref": "main",                        // ref compared on each sync
+      "lastSync": { "sha": "8c1f2ab", "at": "2026-07-01" },
+      "paths": ["**"]                       // optional glob scope
+    }
+  ],
+  "sync": {
+    "auto": false,                          // scheduled sync via a lisa-auto cron
+    "strategy": "pull-request",             // or "direct-when-clean"
+    "upstreamProposals": true,              // open issues in the starter repo
+    "proposalLabel": "starter-upstream-proposal"
+  }
+}
+```
+
+**Downstream sync (starter → project).** A sync diffs the starter's tracked
+ref since `lastSync.sha` and applies the changes to the host project,
+respecting Lisa template semantics (create-only files the project now owns
+are never clobbered; a `paths` scope limits what applies). Clean applications
+land per `strategy`; conflicts always open a PR. `lastSync` is updated after
+every successful run. Multiple templates are supported — e.g. an app starter
+plus an infrastructure starter, each with its own path scope.
+
+**Upstreaming (project → starter).** During a sync (or a standalone scan),
+Lisa looks for *generic* additions the host project made — shared utilities,
+dependency/security bumps, CI workflow fixes, config hardening with no
+project-specific identifiers — and opens an issue in the starter repo,
+labeled `proposalLabel`, containing detailed instructions on what was changed
+and how to apply it to the starter. Anything referencing project names,
+product features, secrets, or business logic is never proposed.
+
+When the engine lands, `starter.*` should join the `lisa sync` registry so
+the section above governs it like every other setting.
+
+## Health (planned — documented, not wired)
+
+The **Health** section answers two questions with different lifecycles:
+
+**Is Lisa on the latest version?** — always-on status. Lisa's CLI already
+checks npm on every invocation; the console surfaces the result permanently
+as the top-bar chip (green dot `up to date`, amber when behind) and in the
+Health section's version card. When behind, `lisa update` prints (or runs
+with `--yes`) the package-manager update command.
+
+**Is the project completely in band?** — on-demand scan behind the
+"Run health check" button (plus an optional scheduled cadence via
+`health.schedule` that files a ticket when drift is found). "In band" means
+every Lisa-managed surface matches what the installed Lisa version would
+emit. The check is a mix of deterministic and agentic verification,
+packaged as one skill (working name `/lisa:health`) so the console button,
+the cron, and the CLI share a single implementation:
+
+- **Deterministic layer** (fast, exact — reuses what exists today):
+  `lisa doctor`, template diffing for copy-overwrite/managed-block files,
+  `package.json` governance (force/defaults/merge conformance),
+  `lisa sync --dry-run` (config fully populated, artifacts in sync), git
+  hooks installed and unmodified, plugins enabled and version-current, CI
+  workflow drift vs the stack template, rulesets present.
+- **Agentic layer** (judges what a diff can't): whether local overrides
+  (`eslint.config.local.ts`, grandfathered globs) still serve their original
+  purpose, whether detected drift looks intentional or accidental, whether
+  skipped CI jobs and disabled gates have a recorded justification.
+
+Results render as a per-check table (pass / warn / fail, with the layer that
+produced each finding), and the last full check's date + verdict stays
+visible in the section.
+
+## What it catalogs
+
+| Section | Source of truth in this repo |
+| --- | --- |
+| Setup checklist (install → sync → tracker/PRD → repo governance → secrets → automations) | `lisa apply`, `lisa sync`, `/lisa:setup:*` skills |
+| Health (version status + planned in-band scan) | `lisa doctor`, `lisa sync --dry-run`, planned `/lisa:health` skill |
+| Core workflow (the delivery-loop slash commands and their automations) | `plugins/src/base/commands/lisa/`, `plugins/src/base/skills/` |
+| Starter templates (provenance + planned two-way sync) | `src/cli/starters.ts`, planned `starter.*` config |
+| General (`harness`, `tracker`, `source`, `repo`, package manager) | `src/core/config.ts`, `plugins/src/base/rules/reference/config-resolution.md` |
+| Project types (8 stacks + template strategies) | `src/detection/`, `src/strategies/`, `<stack>/` template dirs |
+| Coding agents (claude/codex/cursor/agy/copilot/opencode/fleet) | `src/core/lisa.ts`, `scripts/generate-*-plugin-artifacts.mjs` |
+| Work tracker (JIRA / GitHub Issues / Linear) | `config-resolution.md`, `lisa-setup-*` skills |
+| PRD source (Notion / Confluence / Linear / GitHub) | `config-resolution.md`, `lisa-setup-*` skills |
+| Deploy & environments (`deploy.*`, `github.environments`) | `scripts/lisa-github-environments.sh` |
+| Automations (intake/repair/exploratory crons) | `lisa-setup-automations` skill |
+| Intake & monitoring thresholds | `.lisa.config.json` `intake.*` / `monitor.*` |
+| Linting (custom plugins, budgets, oxlint, ast-grep) | `eslint-plugin-*/`, `src/configs/eslint/`, `sgconfig.yml` |
+| Testing & coverage (runners, floors, mutation gates) | `src/configs/{vitest,jest}/`, `*.thresholds.json` |
+| Git hooks (Husky / Lefthook) | `typescript/copy-contents/.husky/`, `rails/copy-overwrite/lefthook.yml` |
+| CI quality gates (quality.yml jobs + inputs) | `.github/workflows/quality.yml` |
+| Verification & QA (exploration mutation policy, ZAP) | `lisa-use-the-product` skill |
+| GitHub repository (settings, rulesets, labels, secrets) | `scripts/lisa-github-repo-setup.sh`, `all/github-rulesets/` |
+| Plugins & MCP (Lisa + curated third-party + servers) | `.claude/settings.json`, `plugins/src/` |
+| Advanced (wiki source, usage pricing, Play Store) | `config-resolution.md` |
+
+Values shown are Lisa's real defaults (as of the version in the top bar), with
+a fictional demo project (`acme/acme-app`, typescript + expo, JIRA + Notion)
+supplying example identifiers.
+
+## Implementation notes
+
+- Single `index.html`: inline CSS (token-based light/dark theming with a
+  manual toggle) and vanilla JS. The catalog lives in a declarative `DATA`
+  structure at the top of the script; rendering is generic per block type
+  (`card`/`rows`, `table`, `tabs`, `stacks`, `hooks`, `flow`, `tiles`,
+  `callout`), so adding a setting is a data edit, not a DOM edit.
+- Search box filters rows/cards within the active section.
+- URL hash routes to a section (e.g. `ui/index.html#linting`).