@codyswann/lisa 1.91.1 → 1.93.0

package/package.json

@@ -78,7 +78,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.91.1",
+  "version": "1.93.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": "1.91.1",
+  "version": "1.93.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/skills/jira-create/SKILL.md

@@ -81,6 +81,34 @@ h3. Assertions
 4. **Assertions are testable statements** — "Health check returns 200 with status ok" not "API works"
 5. **Prerequisites include environment setup** — Database connection, env vars, running services
 
+## Source Artifact Preservation
+
+If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+
+Rules:
+
+1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
+2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
+3. **Stories inherit by domain**: frontend stories get `ui-design` + `ux-flow` + `reference`; backend gets `data` + `reference`; infra gets `ops` + `reference`. When ambiguous, err on the side of inclusion.
+4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
+5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+
+When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+
+**Classification disambiguation** (applied during extraction):
+- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
+- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
+- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+
+**Source precedence** (must be recorded on every ticket carrying design artifacts):
+- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
+- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
+- Flow and interaction (navigation, transitions, state changes) come from **prototypes** (`ux-flow`).
+- API / data shape comes from **`data` artifacts**.
+- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+
+**Existing-component reuse** (applies to every UI-touching ticket): the story description must instruct the implementer to locate the closest existing component in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+
 ## Issue Requirements
 
 Each issue must clearly communicate to:

package/plugins/lisa/skills/jira-write-ticket/SKILL.md

@@ -124,6 +124,28 @@ Identify and attach:
 - Confluence pages (design docs, RFCs, runbooks)
 - Dashboards (Grafana, Datadog, Sentry issue)
 - Incident tickets (PagerDuty, Statuspage)
+- **Source artifacts from the originating PRD / parent epic**: Figma files, Lovable prototypes, Loom walkthroughs, design mockups, example payloads, Google Docs/Slides, collaborative whiteboards. If this ticket has a parent epic, enumerate the epic's remote links and inherit the ones whose domain matches this ticket's scope (UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit generic `reference` links). Never assume a developer will walk up to the epic to find design context — attach it here.
+
+Domain disambiguation (applied on inheritance):
+- Figma URL with `/proto/` in path or `starting-point-node-id=` in query → `ux-flow`; otherwise `ui-design`.
+- Lovable output → always `ux-flow`; its code/styling is not authoritative.
+- Loom / annotated screenshot → `ux-flow`.
+- Bare screenshot → `ui-design`.
+
+If the ticket was generated from a PRD (by `notion-to-jira` or similar) and the parent epic has no source artifacts, surface that as a smell and ask whether artifacts were missed during extraction before proceeding.
+
+### 4d. Source Precedence (must appear on the ticket)
+
+When a ticket carries both design artifacts and a description, different sources are authoritative for different questions. Record this precedence explicitly in the ticket description (under Technical Approach or a dedicated `## Source Precedence` subsection) so the implementer doesn't silently reconcile conflicts:
+
+- **Business rules** (required fields, validation, permissions, data constraints, edge cases) → the **description / PRD body** wins.
+- **Visual treatment** (layout, spacing, typography, color, iconography) → **mocks (`ui-design`)** win.
+- **Flow and interaction** (navigation, transitions, state changes, timing, empty/error/loading states) → **prototypes (`ux-flow`)** win.
+- **API / data shape** → **`data` artifacts** win.
+
+Cross-axis conflicts (mock shows a field the PRD doesn't mention; prototype shows a flow the PRD contradicts; two Figma links disagree) must be raised as BLOCKER items in an `## Open Questions` section on the ticket — never silently reconciled.
+
+For UI-touching tickets, additionally include the reuse expectation: "Before implementing, identify the closest existing component in the codebase. Prefer reuse even if the mock specifies different styling; raise design-vs-code divergence as a discussion item here rather than pixel-matching from scratch."
 
 Use Jira's web UI or `mcp__atlassian__editJiraIssue` to set the `Development` field / remote links where supported.
 

package/plugins/lisa/skills/notion-to-jira/SKILL.md

@@ -53,6 +53,76 @@ Do not retrieve credentials from repository files or local agent settings.
    - Engineering comments (prefixed with "Engineering:" or wrench emoji) that identify technical constraints
    - Cross-PRD dependencies (references to other features or shared infrastructure)
 
+### Phase 1.5: Extract Source Artifacts
+
+PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, Confluence pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.
+
+1. **Scan the PRD main page, all Epic sub-pages, and every fetched comment thread** for:
+   - URLs to design/prototype tools (Figma, FigJam, Figma Make, Lovable, Framer, Penpot)
+   - URLs to recording/walkthrough tools (Loom, YouTube, Vimeo, Descript)
+   - URLs to collaborative docs (Google Docs/Slides/Sheets, Confluence, Notion peer pages)
+   - URLs to code sandboxes (CodeSandbox, StackBlitz, Replit, GitHub permalinks/gists)
+   - URLs to diagramming tools (Miro, Mural, Excalidraw, Mermaid Live, draw.io, Lucid)
+   - URLs to data/observability tools (Grafana, Datadog, Sentry, Metabase, Looker)
+   - Embedded images and file attachments on the page itself
+   - Fenced code blocks with example data (JSON, SQL, GraphQL, cURL request/response)
+
+2. **Classify each artifact by domain**. The split matters — each domain is the source of truth for different implementation decisions:
+
+   | Domain | What it defines | Examples |
+   |--------|-----------------|----------|
+   | `ui-design` (mocks) | **Visual treatment only** — layout, spacing, typography, color, iconography | Figma design frames, Framer static frames, bare screenshots, mockup PNGs |
+   | `ux-flow` (prototypes) | **Interaction and flow only** — navigation, transitions, state changes, timing, empty/error/loading states | Lovable output, Loom walkthroughs, Figma prototype links, annotated screenshots, Miro/Mural flow diagrams, user journey maps |
+   | `data` | Request/response shape, schema constraints | Example JSON, SQL schemas, GraphQL snippets, API contracts |
+   | `ops` | Deployment/runtime context | Runbooks, dashboards, Terraform refs, deployment diagrams |
+   | `reference` | Cross-cutting context | Confluence, Notion peer pages, Google Docs, related PRDs |
+
+3. **Apply disambiguation rules** when an artifact could fit multiple domains. These rules exist because agents consistently misclassify Figma and Lovable artifacts, which are the two most common sources of dropped context.
+
+   - **Figma URL**: classify as `ux-flow` if the URL is a prototype share link — it contains `/proto/`, or has `starting-point-node-id=` in the query, or the sharing context labels it "prototype" / "play mode". Otherwise classify as `ui-design`. Never assume.
+   - **Lovable output**: always `ux-flow`. Lovable ships working code, but its code, styling, and any embedded business rules are NOT authoritative. Treat Lovable strictly as a UX/flow reference. Implementation uses existing project components; business rules come from the PRD description, not from Lovable.
+   - **Screenshot with annotations** (arrows between frames, flow labels, numbered steps): `ux-flow`. A bare unannotated screenshot: `ui-design`. A side-by-side gallery of state variants (empty/error/loading): `ui-design` with state variants noted.
+   - **Loom / video walkthrough**: `ux-flow` in the vast majority of cases. The rare exception — a video that's only a static-frame design review with no interaction — is still `ux-flow` for routing purposes (both UX and UI stories benefit from it).
+   - **Figma file with both design frames and a prototype**: emit two entries — one `ui-design` for the file, one `ux-flow` for the prototype URL — so both propagate correctly.
+
+4. **Build an `artifacts` map** keyed by domain. Each entry: `{ url, title, domain, source_page, source_page_url, classification_reason }`. The `classification_reason` makes disambiguation auditable ("Figma URL contains `/proto/` → ux-flow"). The `source_page` lets you trace each reference back to where it appeared in the PRD.
+
+5. **Surface coverage smells** — incomplete artifact sets are a common root cause of implementation drift:
+   - **Zero artifacts** on a non-trivial PRD: almost always an extraction bug, not a design decision. Say so explicitly.
+   - **Prototype but no mock** (`ux-flow` present, `ui-design` absent): flag "missing UI mocks". UI will have to be inferred from prototype frames — note that prototype styling is typically placeholder and must NOT be treated as visual source of truth. Record the smell on the epic.
+   - **Mocks but no prototype** (`ui-design` present, `ux-flow` absent): flag "missing UX prototype". UX will have to be inferred from static mock states (empty/error/loading/hover) — any flow that isn't explicitly depicted in the mocks must be raised as a BLOCKER with recommendation + alternatives, not silently invented.
+   - **Lovable output without a description covering business rules**: flag "business rules missing". Lovable's embedded logic is not authoritative; the PRD description must explicitly state required fields, validation, permissions, and edge cases.
+
+### Phase 1.6: Source Precedence & Conflict Resolution
+
+Different artifact domains answer different questions. When they disagree, silent reconciliation is a known failure mode — these rules must be encoded on the tickets and respected during implementation.
+
+**Authoritative source by question**:
+
+| Question | Authoritative source |
+|----------|---------------------|
+| Does this field exist? Is it required? Who can see/edit it? What validation applies? What are the edge cases, permission rules, data constraints? | **Description / PRD body** (business rules) |
+| What does it look like — layout, spacing, typography, color, iconography? | **Mocks (`ui-design`)** |
+| How does it flow — navigation, transitions, state changes, timing, empty/error/loading states? | **Prototypes (`ux-flow`)** |
+| Where does the data come from, what shape is it, what are the API contracts? | **`data` artifacts** |
+
+**Cross-axis conflicts must be surfaced, not reconciled silently**:
+
+- Mock shows a field the description doesn't mention → BLOCKER on the story: "Figma shows field `X` not in PRD; confirm it exists, and if so add business rules (required/optional, validation)."
+- Description mandates behavior the prototype contradicts → BLOCKER: "PRD says Y, prototype shows Z; which is correct?"
+- Prototype shows a flow the mocks don't cover (e.g., an error state) → Note on the story: "Error state flow from prototype; no mock exists for the error UI. Use existing error component or request mock."
+- Multiple artifacts of the same domain disagree (e.g., two Figma links showing different layouts) → BLOCKER: list both, ask which is current.
+
+Record every conflict on the ticket description under a `## Open Questions` subsection so the developer picking up the ticket sees it before writing code.
+
+**Existing-component reuse (applies to `ui-design` consumers)**:
+
+Mocks define *visual intent*, not *implementation shortcut*. Before a developer builds UI from a mock, they must search the codebase for the closest-matching existing component. Encode this expectation on every UI-touching story:
+
+- Story description includes: "Before implementing, identify the closest existing component in the codebase. Prefer reuse even if the Figma mock specifies different styling — flag the design-vs-code divergence as a discussion point on this ticket rather than pixel-matching Figma from scratch."
+- If no existing component fits, building a new one is an explicit decision that must be recorded in the ticket (with rationale) before implementation.
+- Lovable-generated components are never the reuse target — always use the project's own components.
+
 ### Phase 2: Codebase Research (if needed)
 
 If the session doesn't already have codebase context, explore the repos to understand what exists.
@@ -72,9 +142,12 @@ Create one Epic per PRD epic using the JIRA project key from config. Each Epic d
 - Key decisions from comments (with attribution)
 - Blockers and open questions
 - Dependencies on other epics or PRDs
+- A **Source Artifacts** section listing every artifact extracted in Phase 1.5 (grouped by domain)
 
 Use `contentFormat: "markdown"` for all descriptions.
 
+**Attach every artifact from Phase 1.5 as an Epic remote link** — regardless of domain. The epic is the canonical hub, and anyone working on the epic or its descendants must be able to reach the full set from one place. No filtering at the epic level.
+
 ### Phase 4: Create Stories
 
 For each Epic, create Stories:
@@ -91,9 +164,21 @@ Each story description should include:
 - Acceptance criteria (from functional requirements)
 - Technical notes from engineering comments
 - Blockers with recommendation + alternatives (if any)
+- A **Source Artifacts** section listing the artifacts inherited from the epic that match this story's scope (see propagation rules below)
 
 Set `parent` to the Epic key to link stories to their epic.
 
+**Inherit domain-matching artifacts as story remote links**. For each story, attach the Phase 1.5 artifacts whose domain matches the story's scope:
+
+| Story type | Inherits domains |
+|------------|------------------|
+| Frontend / UI | `ui-design`, `ux-flow`, `reference` |
+| Backend / API / data model | `data`, `reference` |
+| Infrastructure | `ops`, `reference` |
+| Mixed / setup ("X.0") | All domains |
+
+When classification is ambiguous, err on the side of inclusion — a developer can ignore a link, but they can't inherit one that wasn't attached. Classification mistakes are caught by the preservation gate in Phase 5.5 and by the human reviewing the final report.
+
 ### Phase 5: Create Sub-tasks
 
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency.
@@ -111,6 +196,25 @@ Use the test user credentials from config for all verification plans.
 
 Set `parent` to the Story key. Use `issueTypeName: "Sub-task"`.
 
+Sub-tasks inherit their parent story's artifacts by reference (the parent link). Do not re-attach the same remote links on every sub-task — that creates noise. The only exception is when a sub-task depends on an artifact that the parent story doesn't (e.g., a sub-task spec'd from a specific Figma frame that the broader story doesn't cite) — in that case, attach the specific artifact directly.
+
+### Phase 5.5: Artifact Preservation Gate
+
+Before reporting, verify that every artifact extracted in Phase 1.5 is reachable from the created tickets. This gate exists because silent artifact loss is the failure mode this skill is designed to prevent.
+
+1. Pull the remote links of every epic and story created in this run (via the JIRA API).
+2. Build a preservation matrix: `artifact URL → [ticket keys that reference it]`.
+3. For every artifact from Phase 1.5:
+   - It MUST appear on the epic it belongs to (no exceptions).
+   - It SHOULD appear on at least one story whose scope matches its domain (except `reference`-domain artifacts, which may be epic-only if no story is domain-matched).
+4. If any artifact has zero references anywhere, or is missing from its epic, FAIL LOUDLY:
+   - List each dropped artifact with its domain, title, and source page.
+   - State why it was dropped (domain classification error, propagation skipped, attach failure).
+   - Ask the human to confirm the drop or point at the right epic/story, then re-attach before continuing.
+5. If classification seems misrouted (e.g., a Figma link ended up on a backend story and nowhere else), surface the misroute and offer to re-propagate.
+
+Do NOT skip this gate. If every artifact is preserved, print the matrix compactly and proceed to Phase 6.
+
 ### Phase 6: Report Results
 
 After all tickets are created, present a summary table to the user:
@@ -118,6 +222,7 @@ After all tickets are created, present a summary table to the user:
 - All Stories grouped by Epic
 - All Sub-tasks grouped by Story with repo tags
 - Repo distribution (how many tasks per repo)
+- **Artifact Preservation Matrix** — one row per artifact showing which epic/stories reference it
 - Blockers list with recommendations and alternatives
 - Cross-PRD dependencies
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.91.1",
+  "version": "1.93.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "1.91.1",
+  "version": "1.93.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/skills/jira-create/SKILL.md

@@ -87,6 +87,34 @@ h3. Assertions
 6. **Prerequisites include feature flags** — If the feature is behind a PostHog flag, name it explicitly
 7. **Auth steps included when needed** — If the journey requires login, include the test credentials in Prerequisites
 
+## Source Artifact Preservation
+
+If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+
+Rules:
+
+1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
+2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
+3. **Stories inherit by domain**: frontend/Expo stories get `ui-design` + `ux-flow` + `reference`; backend gets `data` + `reference`; infra gets `ops` + `reference`. When ambiguous, err on the side of inclusion.
+4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
+5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+
+When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+
+**Classification disambiguation** (applied during extraction):
+- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
+- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
+- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+
+**Source precedence** (must be recorded on every ticket carrying design artifacts):
+- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
+- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
+- Flow and interaction (navigation, transitions, state changes, empty/error/loading states) come from **prototypes** (`ux-flow`).
+- API / data shape comes from **`data` artifacts**.
+- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+
+**Existing-component reuse** (applies to every UI-touching ticket — especially relevant for Expo/React Native with its established component library): the story description must instruct the implementer to locate the closest existing component in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+
 ## Issue Requirements
 
 Each issue must clearly communicate to:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "1.91.1",
+  "version": "1.93.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.91.1",
+  "version": "1.93.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/skills/jira-create/SKILL.md

@@ -27,6 +27,34 @@ Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all
 **Feature Flags**: All features behind flags with lifecycle plan
 **Cleanup**: Remove temporary code, scripts, dev configs
 
+## Source Artifact Preservation
+
+If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+
+Rules:
+
+1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
+2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
+3. **Stories inherit by domain**: frontend/view stories get `ui-design` + `ux-flow` + `reference`; backend/model/controller stories get `data` + `reference`; infra stories get `ops` + `reference`. When ambiguous, err on the side of inclusion.
+4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
+5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+
+When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+
+**Classification disambiguation** (applied during extraction):
+- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
+- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
+- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+
+**Source precedence** (must be recorded on every ticket carrying design artifacts):
+- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
+- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
+- Flow and interaction (navigation, transitions, state changes, empty/error/loading states) come from **prototypes** (`ux-flow`).
+- API / data shape comes from **`data` artifacts**.
+- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+
+**Existing-component reuse** (applies to every view/partial-touching ticket): the story description must instruct the implementer to locate the closest existing view partial or ViewComponent in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+
 ## Issue Requirements
 
 Each issue must clearly communicate to:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "1.91.1",
+  "version": "1.93.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/skills/jira-create/SKILL.md

@@ -81,6 +81,34 @@ h3. Assertions
 4. **Assertions are testable statements** — "Health check returns 200 with status ok" not "API works"
 5. **Prerequisites include environment setup** — Database connection, env vars, running services
 
+## Source Artifact Preservation
+
+If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+
+Rules:
+
+1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
+2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
+3. **Stories inherit by domain**: frontend stories get `ui-design` + `ux-flow` + `reference`; backend gets `data` + `reference`; infra gets `ops` + `reference`. When ambiguous, err on the side of inclusion.
+4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
+5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+
+When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+
+**Classification disambiguation** (applied during extraction):
+- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
+- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
+- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+
+**Source precedence** (must be recorded on every ticket carrying design artifacts):
+- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
+- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
+- Flow and interaction (navigation, transitions, state changes) come from **prototypes** (`ux-flow`).
+- API / data shape comes from **`data` artifacts**.
+- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+
+**Existing-component reuse** (applies to every UI-touching ticket): the story description must instruct the implementer to locate the closest existing component in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+
 ## Issue Requirements
 
 Each issue must clearly communicate to:

package/plugins/src/base/skills/jira-write-ticket/SKILL.md

@@ -124,6 +124,28 @@ Identify and attach:
 - Confluence pages (design docs, RFCs, runbooks)
 - Dashboards (Grafana, Datadog, Sentry issue)
 - Incident tickets (PagerDuty, Statuspage)
+- **Source artifacts from the originating PRD / parent epic**: Figma files, Lovable prototypes, Loom walkthroughs, design mockups, example payloads, Google Docs/Slides, collaborative whiteboards. If this ticket has a parent epic, enumerate the epic's remote links and inherit the ones whose domain matches this ticket's scope (UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit generic `reference` links). Never assume a developer will walk up to the epic to find design context — attach it here.
+
+Domain disambiguation (applied on inheritance):
+- Figma URL with `/proto/` in path or `starting-point-node-id=` in query → `ux-flow`; otherwise `ui-design`.
+- Lovable output → always `ux-flow`; its code/styling is not authoritative.
+- Loom / annotated screenshot → `ux-flow`.
+- Bare screenshot → `ui-design`.
+
+If the ticket was generated from a PRD (by `notion-to-jira` or similar) and the parent epic has no source artifacts, surface that as a smell and ask whether artifacts were missed during extraction before proceeding.
+
+### 4d. Source Precedence (must appear on the ticket)
+
+When a ticket carries both design artifacts and a description, different sources are authoritative for different questions. Record this precedence explicitly in the ticket description (under Technical Approach or a dedicated `## Source Precedence` subsection) so the implementer doesn't silently reconcile conflicts:
+
+- **Business rules** (required fields, validation, permissions, data constraints, edge cases) → the **description / PRD body** wins.
+- **Visual treatment** (layout, spacing, typography, color, iconography) → **mocks (`ui-design`)** win.
+- **Flow and interaction** (navigation, transitions, state changes, timing, empty/error/loading states) → **prototypes (`ux-flow`)** win.
+- **API / data shape** → **`data` artifacts** win.
+
+Cross-axis conflicts (mock shows a field the PRD doesn't mention; prototype shows a flow the PRD contradicts; two Figma links disagree) must be raised as BLOCKER items in an `## Open Questions` section on the ticket — never silently reconciled.
+
+For UI-touching tickets, additionally include the reuse expectation: "Before implementing, identify the closest existing component in the codebase. Prefer reuse even if the mock specifies different styling; raise design-vs-code divergence as a discussion item here rather than pixel-matching from scratch."
 
 Use Jira's web UI or `mcp__atlassian__editJiraIssue` to set the `Development` field / remote links where supported.
 

package/plugins/src/base/skills/notion-to-jira/SKILL.md

@@ -53,6 +53,76 @@ Do not retrieve credentials from repository files or local agent settings.
    - Engineering comments (prefixed with "Engineering:" or wrench emoji) that identify technical constraints
    - Cross-PRD dependencies (references to other features or shared infrastructure)
 
+### Phase 1.5: Extract Source Artifacts
+
+PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, Confluence pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.
+
+1. **Scan the PRD main page, all Epic sub-pages, and every fetched comment thread** for:
+   - URLs to design/prototype tools (Figma, FigJam, Figma Make, Lovable, Framer, Penpot)
+   - URLs to recording/walkthrough tools (Loom, YouTube, Vimeo, Descript)
+   - URLs to collaborative docs (Google Docs/Slides/Sheets, Confluence, Notion peer pages)
+   - URLs to code sandboxes (CodeSandbox, StackBlitz, Replit, GitHub permalinks/gists)
+   - URLs to diagramming tools (Miro, Mural, Excalidraw, Mermaid Live, draw.io, Lucid)
+   - URLs to data/observability tools (Grafana, Datadog, Sentry, Metabase, Looker)
+   - Embedded images and file attachments on the page itself
+   - Fenced code blocks with example data (JSON, SQL, GraphQL, cURL request/response)
+
+2. **Classify each artifact by domain**. The split matters — each domain is the source of truth for different implementation decisions:
+
+   | Domain | What it defines | Examples |
+   |--------|-----------------|----------|
+   | `ui-design` (mocks) | **Visual treatment only** — layout, spacing, typography, color, iconography | Figma design frames, Framer static frames, bare screenshots, mockup PNGs |
+   | `ux-flow` (prototypes) | **Interaction and flow only** — navigation, transitions, state changes, timing, empty/error/loading states | Lovable output, Loom walkthroughs, Figma prototype links, annotated screenshots, Miro/Mural flow diagrams, user journey maps |
+   | `data` | Request/response shape, schema constraints | Example JSON, SQL schemas, GraphQL snippets, API contracts |
+   | `ops` | Deployment/runtime context | Runbooks, dashboards, Terraform refs, deployment diagrams |
+   | `reference` | Cross-cutting context | Confluence, Notion peer pages, Google Docs, related PRDs |
+
+3. **Apply disambiguation rules** when an artifact could fit multiple domains. These rules exist because agents consistently misclassify Figma and Lovable artifacts, which are the two most common sources of dropped context.
+
+   - **Figma URL**: classify as `ux-flow` if the URL is a prototype share link — it contains `/proto/`, or has `starting-point-node-id=` in the query, or the sharing context labels it "prototype" / "play mode". Otherwise classify as `ui-design`. Never assume.
+   - **Lovable output**: always `ux-flow`. Lovable ships working code, but its code, styling, and any embedded business rules are NOT authoritative. Treat Lovable strictly as a UX/flow reference. Implementation uses existing project components; business rules come from the PRD description, not from Lovable.
+   - **Screenshot with annotations** (arrows between frames, flow labels, numbered steps): `ux-flow`. A bare unannotated screenshot: `ui-design`. A side-by-side gallery of state variants (empty/error/loading): `ui-design` with state variants noted.
+   - **Loom / video walkthrough**: `ux-flow` in the vast majority of cases. The rare exception — a video that's only a static-frame design review with no interaction — is still `ux-flow` for routing purposes (both UX and UI stories benefit from it).
+   - **Figma file with both design frames and a prototype**: emit two entries — one `ui-design` for the file, one `ux-flow` for the prototype URL — so both propagate correctly.
+
+4. **Build an `artifacts` map** keyed by domain. Each entry: `{ url, title, domain, source_page, source_page_url, classification_reason }`. The `classification_reason` makes disambiguation auditable ("Figma URL contains `/proto/` → ux-flow"). The `source_page` lets you trace each reference back to where it appeared in the PRD.
+
+5. **Surface coverage smells** — incomplete artifact sets are a common root cause of implementation drift:
+   - **Zero artifacts** on a non-trivial PRD: almost always an extraction bug, not a design decision. Say so explicitly.
+   - **Prototype but no mock** (`ux-flow` present, `ui-design` absent): flag "missing UI mocks". UI will have to be inferred from prototype frames — note that prototype styling is typically placeholder and must NOT be treated as visual source of truth. Record the smell on the epic.
+   - **Mocks but no prototype** (`ui-design` present, `ux-flow` absent): flag "missing UX prototype". UX will have to be inferred from static mock states (empty/error/loading/hover) — any flow that isn't explicitly depicted in the mocks must be raised as a BLOCKER with recommendation + alternatives, not silently invented.
+   - **Lovable output without a description covering business rules**: flag "business rules missing". Lovable's embedded logic is not authoritative; the PRD description must explicitly state required fields, validation, permissions, and edge cases.
+
+### Phase 1.6: Source Precedence & Conflict Resolution
+
+Different artifact domains answer different questions. When they disagree, silent reconciliation is a known failure mode — these rules must be encoded on the tickets and respected during implementation.
+
+**Authoritative source by question**:
+
+| Question | Authoritative source |
+|----------|---------------------|
+| Does this field exist? Is it required? Who can see/edit it? What validation applies? What are the edge cases, permission rules, data constraints? | **Description / PRD body** (business rules) |
+| What does it look like — layout, spacing, typography, color, iconography? | **Mocks (`ui-design`)** |
+| How does it flow — navigation, transitions, state changes, timing, empty/error/loading states? | **Prototypes (`ux-flow`)** |
+| Where does the data come from, what shape is it, what are the API contracts? | **`data` artifacts** |
+
+**Cross-axis conflicts must be surfaced, not reconciled silently**:
+
+- Mock shows a field the description doesn't mention → BLOCKER on the story: "Figma shows field `X` not in PRD; confirm it exists, and if so add business rules (required/optional, validation)."
+- Description mandates behavior the prototype contradicts → BLOCKER: "PRD says Y, prototype shows Z; which is correct?"
+- Prototype shows a flow the mocks don't cover (e.g., an error state) → Note on the story: "Error state flow from prototype; no mock exists for the error UI. Use existing error component or request mock."
+- Multiple artifacts of the same domain disagree (e.g., two Figma links showing different layouts) → BLOCKER: list both, ask which is current.
+
+Record every conflict on the ticket description under a `## Open Questions` subsection so the developer picking up the ticket sees it before writing code.
+
+**Existing-component reuse (applies to `ui-design` consumers)**:
+
+Mocks define *visual intent*, not *implementation shortcut*. Before a developer builds UI from a mock, they must search the codebase for the closest-matching existing component. Encode this expectation on every UI-touching story:
+
+- Story description includes: "Before implementing, identify the closest existing component in the codebase. Prefer reuse even if the Figma mock specifies different styling — flag the design-vs-code divergence as a discussion point on this ticket rather than pixel-matching Figma from scratch."
+- If no existing component fits, building a new one is an explicit decision that must be recorded in the ticket (with rationale) before implementation.
+- Lovable-generated components are never the reuse target — always use the project's own components.
+
 ### Phase 2: Codebase Research (if needed)
 
 If the session doesn't already have codebase context, explore the repos to understand what exists.
@@ -72,9 +142,12 @@ Create one Epic per PRD epic using the JIRA project key from config. Each Epic d
 - Key decisions from comments (with attribution)
 - Blockers and open questions
 - Dependencies on other epics or PRDs
+- A **Source Artifacts** section listing every artifact extracted in Phase 1.5 (grouped by domain)
 
 Use `contentFormat: "markdown"` for all descriptions.
 
+**Attach every artifact from Phase 1.5 as an Epic remote link** — regardless of domain. The epic is the canonical hub, and anyone working on the epic or its descendants must be able to reach the full set from one place. No filtering at the epic level.
+
 ### Phase 4: Create Stories
 
 For each Epic, create Stories:
@@ -91,9 +164,21 @@ Each story description should include:
 - Acceptance criteria (from functional requirements)
 - Technical notes from engineering comments
 - Blockers with recommendation + alternatives (if any)
+- A **Source Artifacts** section listing the artifacts inherited from the epic that match this story's scope (see propagation rules below)
 
 Set `parent` to the Epic key to link stories to their epic.
 
+**Inherit domain-matching artifacts as story remote links**. For each story, attach the Phase 1.5 artifacts whose domain matches the story's scope:
+
+| Story type | Inherits domains |
+|------------|------------------|
+| Frontend / UI | `ui-design`, `ux-flow`, `reference` |
+| Backend / API / data model | `data`, `reference` |
+| Infrastructure | `ops`, `reference` |
+| Mixed / setup ("X.0") | All domains |
+
+When classification is ambiguous, err on the side of inclusion — a developer can ignore a link, but they can't inherit one that wasn't attached. Classification mistakes are caught by the preservation gate in Phase 5.5 and by the human reviewing the final report.
+
 ### Phase 5: Create Sub-tasks
 
 Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency.
@@ -111,6 +196,25 @@ Use the test user credentials from config for all verification plans.
 
 Set `parent` to the Story key. Use `issueTypeName: "Sub-task"`.
 
+Sub-tasks inherit their parent story's artifacts by reference (the parent link). Do not re-attach the same remote links on every sub-task — that creates noise. The only exception is when a sub-task depends on an artifact that the parent story doesn't (e.g., a sub-task spec'd from a specific Figma frame that the broader story doesn't cite) — in that case, attach the specific artifact directly.
+
+### Phase 5.5: Artifact Preservation Gate
+
+Before reporting, verify that every artifact extracted in Phase 1.5 is reachable from the created tickets. This gate exists because silent artifact loss is the failure mode this skill is designed to prevent.
+
+1. Pull the remote links of every epic and story created in this run (via the JIRA API).
+2. Build a preservation matrix: `artifact URL → [ticket keys that reference it]`.
+3. For every artifact from Phase 1.5:
+   - It MUST appear on the epic it belongs to (no exceptions).
+   - It SHOULD appear on at least one story whose scope matches its domain (except `reference`-domain artifacts, which may be epic-only if no story is domain-matched).
+4. If any artifact has zero references anywhere, or is missing from its epic, FAIL LOUDLY:
+   - List each dropped artifact with its domain, title, and source page.
+   - State why it was dropped (domain classification error, propagation skipped, attach failure).
+   - Ask the human to confirm the drop or point at the right epic/story, then re-attach before continuing.
+5. If classification seems misrouted (e.g., a Figma link ended up on a backend story and nowhere else), surface the misroute and offer to re-propagate.
+
+Do NOT skip this gate. If every artifact is preserved, print the matrix compactly and proceed to Phase 6.
+
 ### Phase 6: Report Results
 
 After all tickets are created, present a summary table to the user:
@@ -118,6 +222,7 @@ After all tickets are created, present a summary table to the user:
 - All Stories grouped by Epic
 - All Sub-tasks grouped by Story with repo tags
 - Repo distribution (how many tasks per repo)
+- **Artifact Preservation Matrix** — one row per artifact showing which epic/stories reference it
 - Blockers list with recommendations and alternatives
 - Cross-PRD dependencies
 

package/plugins/src/expo/skills/jira-create/SKILL.md

@@ -87,6 +87,34 @@ h3. Assertions
 6. **Prerequisites include feature flags** — If the feature is behind a PostHog flag, name it explicitly
 7. **Auth steps included when needed** — If the journey requires login, include the test credentials in Prerequisites
 
+## Source Artifact Preservation
+
+If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+
+Rules:
+
+1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
+2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
+3. **Stories inherit by domain**: frontend/Expo stories get `ui-design` + `ux-flow` + `reference`; backend gets `data` + `reference`; infra gets `ops` + `reference`. When ambiguous, err on the side of inclusion.
+4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
+5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+
+When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+
+**Classification disambiguation** (applied during extraction):
+- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
+- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
+- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+
+**Source precedence** (must be recorded on every ticket carrying design artifacts):
+- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
+- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
+- Flow and interaction (navigation, transitions, state changes, empty/error/loading states) come from **prototypes** (`ux-flow`).
+- API / data shape comes from **`data` artifacts**.
+- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+
+**Existing-component reuse** (applies to every UI-touching ticket — especially relevant for Expo/React Native with its established component library): the story description must instruct the implementer to locate the closest existing component in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+
 ## Issue Requirements
 
 Each issue must clearly communicate to:

package/plugins/src/rails/skills/jira-create/SKILL.md

@@ -27,6 +27,34 @@ Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all
 **Feature Flags**: All features behind flags with lifecycle plan
 **Cleanup**: Remove temporary code, scripts, dev configs
 
+## Source Artifact Preservation
+
+If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+
+Rules:
+
+1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
+2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
+3. **Stories inherit by domain**: frontend/view stories get `ui-design` + `ux-flow` + `reference`; backend/model/controller stories get `data` + `reference`; infra stories get `ops` + `reference`. When ambiguous, err on the side of inclusion.
+4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
+5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+
+When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+
+**Classification disambiguation** (applied during extraction):
+- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
+- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
+- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+
+**Source precedence** (must be recorded on every ticket carrying design artifacts):
+- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
+- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
+- Flow and interaction (navigation, transitions, state changes, empty/error/loading states) come from **prototypes** (`ux-flow`).
+- API / data shape comes from **`data` artifacts**.
+- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+
+**Existing-component reuse** (applies to every view/partial-touching ticket): the story description must instruct the implementer to locate the closest existing view partial or ViewComponent in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+
 ## Issue Requirements
 
 Each issue must clearly communicate to:

package/typescript/copy-contents/.husky/pre-push

@@ -272,6 +272,20 @@ fi
 #   fi
 # fi
 
+# Project-specific extension slot (see .husky/pre-push.local).
+# This hook sources pre-push.local if present so per-project checks
+# (e.g., app-boot verification, schema validation) survive Lisa template
+# updates without editing the governance block above.
+if [ -f .husky/pre-push.local ]; then
+  echo "🔌 Running project-specific pre-push checks (.husky/pre-push.local)..."
+  # shellcheck source=/dev/null
+  . .husky/pre-push.local
+  if [ $? -ne 0 ]; then
+    echo "❌ Project-specific pre-push checks failed."
+    exit 1
+  fi
+fi
+
 exit 0
 
 # END: AI GUARDRAILS

package/typescript/copy-overwrite/audit.ignore.config.json

@@ -117,6 +117,26 @@
       "id": "GHSA-fvcv-3m26-pcqx",
       "package": "axios",
       "reason": "Cloud metadata exfiltration requires attacker-controlled outbound request header values. Keep this exclusion only if axios request headers are never sourced from untrusted input."
+    },
+    {
+      "id": "GHSA-2v35-w6hq-6mfw",
+      "package": "@xmldom/xmldom",
+      "reason": "Uncontrolled recursion in XML serialization leading to DoS. Transitive via expo > @expo/config-plugins > @expo/plist; only serializes developer-authored plist files at build/prebuild time, no runtime code path parses or serializes attacker-controlled XML."
+    },
+    {
+      "id": "GHSA-f6ww-3ggp-fr8h",
+      "package": "@xmldom/xmldom",
+      "reason": "XML injection via unvalidated DocumentType serialization. Transitive via expo > @expo/config-plugins > @expo/plist; only serializes developer-authored plist files at build/prebuild time, no runtime code path serializes attacker-controlled XML."
+    },
+    {
+      "id": "GHSA-x6wf-f3px-wcqx",
+      "package": "@xmldom/xmldom",
+      "reason": "XML node injection via unvalidated processing instruction serialization. Transitive via expo > @expo/config-plugins > @expo/plist; only serializes developer-authored plist files at build/prebuild time, no runtime code path serializes attacker-controlled XML."
+    },
+    {
+      "id": "GHSA-j759-j44w-7fr8",
+      "package": "@xmldom/xmldom",
+      "reason": "XML node injection via unvalidated comment serialization. Transitive via expo > @expo/config-plugins > @expo/plist; only serializes developer-authored plist files at build/prebuild time, no runtime code path serializes attacker-controlled XML."
     }
   ]
 }

package/typescript/create-only/.husky/pre-push.local

@@ -0,0 +1,17 @@
+# Project-specific pre-push checks
+#
+# This file is sourced by .husky/pre-push after Lisa's governance block.
+# Add commands here that are unique to this project — Lisa will never
+# overwrite or delete this file on future template updates.
+#
+# The file runs as a sourced POSIX script. Any non-zero exit aborts the push.
+#
+# Examples:
+#   # NestJS AppModule + GraphQL schema boot verification
+#   $RUNNER verify:boot || exit 1
+#
+#   # Project-specific migration lint
+#   $RUNNER migrations:check || exit 1
+#
+# $RUNNER is set by the parent hook based on the detected package manager
+# (bun run / yarn run / npm run).