- Lisa Integration Test
- Apply Lisa templates to a downstream project and verify it works end-to-end. If anything breaks, fix the upstream templates in Lisa and retry until the project passes all checks.
- This must be run FROM the Lisa repository directory.
- Prerequisites
- Running from the Lisa repo (has
- src/core/lisa.ts
- )
- The target project has Lisa applied (has
- .lisa-manifest
- )
- The target project's working directory is clean (no uncommitted changes)
- Instructions
- Step 1: Validate Environment
- Confirm running from Lisa by checking for
- src/core/lisa.ts
- Extract project path from
- $ARGUMENTS
- . If not provided, ask the user.
- Validate the project path exists and has
- .lisa-manifest
- Check the project's working directory is clean:
- git -C
status --porcelain - If dirty, tell the user and stop: "The project has uncommitted changes. Please commit or stash them first."
- Step 2: Record Baseline
- Before applying Lisa, record the project's current state:
- Read
/.lisa-manifest - to note the current Lisa version
- Run
- git -C
log --oneline -1 - to note the current HEAD
- Note the project's branch and whether there's an open PR:
- git -C
branch --show-current - Step 3: Apply Lisa
- Run from the Lisa directory:
- bun run dev
- <
- project-path
- >
- If Lisa fails, report the error and stop.
- Step 4: Check What Changed
- Run
- git -C
status --short - to see what Lisa modified.
- If nothing changed, report "Lisa applied cleanly with no changes" and stop.
- Step 5: Verify the Project
- Run the project's verification commands in order. Stop at the first failure:
- Typecheck
- :
- cd
&& bun run typecheck - (or
- npm run typecheck
- based on package manager)
- Lint
- :
- cd
&& bun run lint - (or equivalent)
- Test
- :
- cd
&& bun run test - (or equivalent)
- Determine the package manager by checking which lockfile exists:
- bun.lockb
- → bun
- pnpm-lock.yaml
- → pnpm
- yarn.lock
- → yarn
- package-lock.json
- → npm
- Step 6: Handle Failures
- If any verification step fails:
- Diagnose
- Analyze the error output to determine root cause
Determine fix location
:
If the fix belongs in Lisa templates (the upstream change broke something), fix it in Lisa and go to Step 6a
If the fix belongs in the project's
.local.
files (project-specific override needed), fix it in the project and go to Step 6b
Report
what failed and what you're fixing
Step 6a: Fix Upstream in Lisa
Make the fix in the Lisa template files
Run Lisa's own checks:
bun run typecheck && bun run lint && bun run test
If Lisa's checks pass, go back to
Step 3
(re-apply Lisa to the project)
If Lisa's checks fail, fix those too, then retry
Step 6b: Fix in Project Local Files
Make the fix in the project's local override files (e.g.,
tsconfig.local.json
,
eslint.config.local.ts
,
jest.config.local.ts
)
Go to
Step 5
(re-verify the project)
Step 7: Commit and Push
Once all verification passes:
Stage all changes in the project:
git -C
add Commit with message: chore: apply Lisa templates Push to the project's remote If upstream Lisa changes were made, commit and push those too Step 8: Report Results Output a summary:
Lisa Integration Test: PASSED
Project:
Changes Applied
Verification
- Typecheck: PASSED
- Lint: PASSED
- Tests: PASSED
Upstream Fixes (if any)
Commits
chore: apply Lisa templates fix: (if upstream fixes were needed) Important Notes Never skip verification — the whole point is proving it works empirically Fix upstream when possible — if Lisa broke something, fix the template, not the project Use local overrides for project-specific needs — tsconfig.local.json , eslint.config.local.ts , etc. Retry loop is bounded — if you've tried 3 fix-and-retry cycles without success, stop and report the situation to the user Preserve project conventions — check the project's commit message style before committing