@codyswann/lisa 2.48.0 → 2.50.0

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -168,7 +168,9 @@ Probe with `mcp__linear-server__list_issue_labels` (scoped to the team). For eac
 
 #### 3b. PRD-lifecycle labels — PROJECT labels (only if Linear is the PRD source)
 
-Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `mcp__linear-server__create_project_label`. These are a **separate label kind** from issue labels — creating an issue label of the same name will NOT work for the PRD flow.
+Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `mcp__linear-server__create_project_label`. This probe-then-create is find-or-create per label: a label already present is reused untouched, so re-running never duplicates `prd-*`. These are a **separate label kind** from issue labels — creating an issue label of the same name will NOT work for the PRD flow.
+
+`prd-verified` is the terminal lifecycle state after `prd-shipped` (the `verified` role from config-resolution, #591): `/lisa:verify-prd` transitions a Linear PRD project into it once the shipped product has been empirically verified against the PRD. Scaffold it through the same find-or-create path as every other `prd-*` row.
 
 | Role | Default | Kind |
 |------|---------|------|
@@ -178,6 +180,7 @@ Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `m
 | `blocked` | `prd-blocked` | project label |
 | `ticketed` | `prd-ticketed` | project label |
 | `shipped` | `prd-shipped` | project label |
+| `verified` | `prd-verified` | project label |
 | `sentinel` | `prd-intake-feedback` | **issue** label (marks the sentinel feedback issue — create via `create_issue_label`) |
 
 #### 3c. Handle name collisions / renames
@@ -230,7 +233,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
 [ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
 ```
 
-Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`, including the terminal `prd-verified`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

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

@@ -259,9 +259,11 @@ STATUS_PROP=$(jq -r '.properties | to_entries[] | select(.value.type == "status"
 STATUS_VALUES=$(jq -r --arg p "$STATUS_PROP" '.properties[$p] | (.status.options // .select.options) | .[].name' <<<"$DB_SCHEMA")
 ```
 
-For each lisa role (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`), check if its default name (`Draft`, `Ready`, etc.) appears in `$STATUS_VALUES`. If a role's default is missing but a similar-looking value exists, prompt the user to map it via `AskUserQuestion`. If a role has no plausible match, prompt to either create the value in Notion or accept that the lifecycle stage is unrepresented.
+For each lisa role (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `verified`), check if its default name (`Draft`, `Ready`, etc.; `Verified` for `verified`) appears in `$STATUS_VALUES`. If a role's default is missing but a similar-looking value exists, prompt the user to map it via `AskUserQuestion`. If a role has no plausible match, prompt to either create the value in Notion or accept that the lifecycle stage is unrepresented. This find-or-create-or-accept path is idempotent per role: a value already present (default or mapped) is reused untouched, so re-running never duplicates a status option.
 
-Collect overrides as a partial values map. Only write keys that differ from defaults.
+`verified` is the terminal lifecycle state after `shipped` (the `verified` role from the `config-resolution` rule, #591): `/lisa:verify-prd` transitions a Notion PRD into it once the shipped product has been empirically verified against the PRD. Notion models the PRD lifecycle as `Status` (or `select`) property options rather than labels, so `verified` is mapped or created through the exact same path as every other role above — and, like them, persisted to `notion.values.verified` when the workspace uses a non-default option name.
+
+Collect overrides as a partial values map. Only write keys that differ from defaults — `verified` included, so a non-default `Verified` option name lands in `notion.values.verified`.
 
 ### Step 7 — Write `.lisa.config.json`
 
@@ -298,7 +300,7 @@ jq -e '.notion.workspaceId and .notion.prdDatabaseId' .lisa.config.json >/dev/nu
 echo "Token validated (${#TOKEN} chars). Workspace: $ME_WORKSPACE. Database: $DATABASE_ID."
 ```
 
-Report success with the resolved workspace, database, status property name, and value overrides (if any). Direct the user to `/lisa:intake` to test.
+Report success with the resolved workspace, database, status property name, and value overrides (if any), confirming all lifecycle roles — including the terminal `verified` — were detected, mapped, or flagged for creation. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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.48.0",
+  "version": "2.50.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/src/base/skills/setup-linear/SKILL.md

@@ -168,7 +168,9 @@ Probe with `mcp__linear-server__list_issue_labels` (scoped to the team). For eac
 
 #### 3b. PRD-lifecycle labels — PROJECT labels (only if Linear is the PRD source)
 
-Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `mcp__linear-server__create_project_label`. These are a **separate label kind** from issue labels — creating an issue label of the same name will NOT work for the PRD flow.
+Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `mcp__linear-server__create_project_label`. This probe-then-create is find-or-create per label: a label already present is reused untouched, so re-running never duplicates `prd-*`. These are a **separate label kind** from issue labels — creating an issue label of the same name will NOT work for the PRD flow.
+
+`prd-verified` is the terminal lifecycle state after `prd-shipped` (the `verified` role from config-resolution, #591): `/lisa:verify-prd` transitions a Linear PRD project into it once the shipped product has been empirically verified against the PRD. Scaffold it through the same find-or-create path as every other `prd-*` row.
 
 | Role | Default | Kind |
 |------|---------|------|
@@ -178,6 +180,7 @@ Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `m
 | `blocked` | `prd-blocked` | project label |
 | `ticketed` | `prd-ticketed` | project label |
 | `shipped` | `prd-shipped` | project label |
+| `verified` | `prd-verified` | project label |
 | `sentinel` | `prd-intake-feedback` | **issue** label (marks the sentinel feedback issue — create via `create_issue_label`) |
 
 #### 3c. Handle name collisions / renames
@@ -230,7 +233,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
 [ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
 ```
 
-Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`, including the terminal `prd-verified`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

package/plugins/src/base/skills/setup-notion/SKILL.md

@@ -259,9 +259,11 @@ STATUS_PROP=$(jq -r '.properties | to_entries[] | select(.value.type == "status"
 STATUS_VALUES=$(jq -r --arg p "$STATUS_PROP" '.properties[$p] | (.status.options // .select.options) | .[].name' <<<"$DB_SCHEMA")
 ```
 
-For each lisa role (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`), check if its default name (`Draft`, `Ready`, etc.) appears in `$STATUS_VALUES`. If a role's default is missing but a similar-looking value exists, prompt the user to map it via `AskUserQuestion`. If a role has no plausible match, prompt to either create the value in Notion or accept that the lifecycle stage is unrepresented.
+For each lisa role (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `verified`), check if its default name (`Draft`, `Ready`, etc.; `Verified` for `verified`) appears in `$STATUS_VALUES`. If a role's default is missing but a similar-looking value exists, prompt the user to map it via `AskUserQuestion`. If a role has no plausible match, prompt to either create the value in Notion or accept that the lifecycle stage is unrepresented. This find-or-create-or-accept path is idempotent per role: a value already present (default or mapped) is reused untouched, so re-running never duplicates a status option.
 
-Collect overrides as a partial values map. Only write keys that differ from defaults.
+`verified` is the terminal lifecycle state after `shipped` (the `verified` role from the `config-resolution` rule, #591): `/lisa:verify-prd` transitions a Notion PRD into it once the shipped product has been empirically verified against the PRD. Notion models the PRD lifecycle as `Status` (or `select`) property options rather than labels, so `verified` is mapped or created through the exact same path as every other role above — and, like them, persisted to `notion.values.verified` when the workspace uses a non-default option name.
+
+Collect overrides as a partial values map. Only write keys that differ from defaults — `verified` included, so a non-default `Verified` option name lands in `notion.values.verified`.
 
 ### Step 7 — Write `.lisa.config.json`
 
@@ -298,7 +300,7 @@ jq -e '.notion.workspaceId and .notion.prdDatabaseId' .lisa.config.json >/dev/nu
 echo "Token validated (${#TOKEN} chars). Workspace: $ME_WORKSPACE. Database: $DATABASE_ID."
 ```
 
-Report success with the resolved workspace, database, status property name, and value overrides (if any). Direct the user to `/lisa:intake` to test.
+Report success with the resolved workspace, database, status property name, and value overrides (if any), confirming all lifecycle roles — including the terminal `verified` — were detected, mapped, or flagged for creation. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

package/typescript/copy-contents/.husky/commit-msg

@@ -83,13 +83,17 @@ fi
 
 echo "🤖 Checking for AI co-authorship..."
 
-if ! echo "$COMMIT_MSG" | grep -q "Co-Authored-By:.*Claude"; then
+# Accept attribution from any supported coding agent (Claude or Codex),
+# case-insensitively. Claude Code emits "Co-Authored-By: Claude"; the Codex CLI
+# emits "Co-authored-by: Codex <noreply@openai.com>".
+if ! echo "$COMMIT_MSG" | grep -Eiq "Co-authored-by:.*(Claude|Codex)"; then
   echo ""
   echo "❌ Commit message must include AI co-authorship!"
   echo ""
-  echo "All commits must include a Co-Authored-By line for Claude."
+  echo "All commits must include a Co-authored-by line for a coding agent (Claude or Codex)."
   echo ""
   echo "If you're using Claude Code, use the /git:commit command"
+  echo "If you're using Codex, enable commit_attribution in .codex/config.toml"
   echo ""
   exit 1
 fi