generatesaas 0.7.0 → 0.8.0

package/dist/skill/content/SKILL.md

@@ -1,6 +1,7 @@
 ---
-name: generatesaas-update
-description: Update GenerateSaaS project to latest boilerplate version. Handles version checks, file classification, generates an update plan for user review, and applies changes while preserving user customizations.
+name: update
+description: Update GenerateSaaS project to latest boilerplate version. Interactive process that classifies files, analyzes dependencies, and applies changes while preserving user customizations — with the user in control of every decision.
+disable-model-invocation: true
 ---
 
 # GenerateSaaS Update
@@ -9,12 +10,55 @@ Update your project to the latest GenerateSaaS boilerplate version while preserv
 
 ## Core Principles
 
-1. **User changes always come first** — Every update must preserve the user's functionality, business logic, and intentional modifications. If an upstream change conflicts with something the user built, the user's version wins.
-2. **Never break user code** — If applying an upstream change would break the user's customizations or doesn't make sense in the context of their modifications, skip it and document why.
-3. **Plan before acting** — Generate a full update plan. The user reviews and approves before anything is applied.
-4. **Track everything** — Every change is tracked in a checklist. Mark items as completed, skipped, or failed so the user knows exactly what happened.
+1. **User decides everything** — Present clear information and options. Never make decisions that affect user code without explicit approval. Every meaningful change requires the user's input.
+2. **Never break user code** — If an upstream change conflicts with user modifications, present the situation and let the user choose. When in doubt, keep the user's version and explain what was skipped.
+3. **Full transparency** — For every change, explain: what changed upstream, why it changed, and how it affects the user's code. The user should always know exactly what is happening.
+4. **Track everything** — Every change is tracked in a checklist. Mark items as completed, skipped, or failed with clear reasons.
 
-## Workflow
+## Workflow Overview
+
+```
+Step 0: Pre-flight safety checks
+Step 1: Prepare update data (script)
+Step 2: Present changelog to user
+Step 3: Classify files (script)
+Step 4: Analyze dependencies
+Step 5: Present update plan — user chooses interaction mode
+Step 6: Apply safe auto-updates (script)
+Step 7: Review modified files with user — one by one
+Step 8: Post-update validation
+Step 9: Complete update (script)
+```
+
+---
+
+### Step 0: Pre-flight
+
+Before starting the update:
+
+1. **Check git status.** Run `git status`. If there are ANY uncommitted changes (staged, unstaged, or untracked files in tracked directories), **STOP immediately**. Do NOT proceed with the update. Tell the user:
+
+> You have uncommitted changes. The update cannot proceed until your working tree is clean — this ensures you have a safe rollback point if anything needs to be reverted.
+>
+> **What would you like to do?**
+> 1. **I'll handle it myself** — Stop the update so you can commit, stash, or discard changes on your own terms, then re-run the update
+> 2. **Help me commit** — I'll help you create a commit with your current changes, then we continue
+
+**NEVER** commit, stash, reset, or alter git state without the user's explicit choice. The user may have intentionally reverted work or have changes they don't want committed. Wait for their decision.
+
+If the user chooses option 2, assist them with the commit (show them what will be committed, let them write the message or approve yours), then verify the working tree is clean before continuing.
+
+If the user chooses option 1, stop completely. Do not continue the update.
+
+2. **Check for incomplete previous update.** Look for an existing plan file at `.generatesaas/updates/update-*-to-*.md`. If one exists, a previous update was started but not completed. Tell the user:
+
+> It looks like a previous update was started but not completed. The plan file shows progress from a prior attempt.
+>
+> **What would you like to do?**
+> 1. **Start fresh** — Discard the old plan and begin the update from scratch
+> 2. **Stop** — Let me review what happened before continuing
+
+If starting fresh, delete the old plan file. Note: files that were auto-applied in the previous attempt may now have V2 content but template-hashes.json still has V1 hashes — these will be correctly classified as "modified" (since they differ from the V1 template hash) and the AI will see they match the staging file, making them trivial merges.
 
 ### Step 1: Prepare Update Data
 
@@ -22,18 +66,25 @@ Update your project to the latest GenerateSaaS boilerplate version while preserv
 node __SKILL_ROOT__/generatesaas-update/scripts/prepare-update.js
 ```
 
-Reads the staged update from `.generatesaas/staging/` and computes local diffs. Creates:
+Creates:
 - `references/changelog.md` — what changed and why
-- `references/diffs/*.diff` — unified diffs for each modified file
+- `references/diffs/*.diff` — unified diffs for each changed file
 - `references/update-manifest.json` — lists of added, modified, and removed files
 
-### Step 2: Review Changelog
+### Step 2: Present Changelog
+
+Read `references/changelog.md` and present a clear, organized summary:
+
+> ## What's New in v{targetVersion}
+>
+> **Breaking changes:** {list or "None"}
+> **New features:** {list}
+> **Bug fixes:** {list}
+> **Migration steps required:** {list or "None"}
 
-Read `references/changelog.md` to understand:
-- Breaking changes that need attention
-- New features being added
-- Bug fixes included
-- Migration steps if any
+Then ask: *"Ready to proceed with the file analysis?"*
+
+Wait for the user to confirm before continuing.
 
 ### Step 3: Classify Files
 
@@ -41,23 +92,37 @@ Read `references/changelog.md` to understand:
 node __SKILL_ROOT__/generatesaas-update/scripts/classify-files.js
 ```
 
-Compares local file hashes (from `.generatesaas/hashes.json`) against current files to determine which the user has customized. Outputs `references/classification.json` with categories:
+Read `references/classification.json`. It contains:
 
-- **unmodified** — file matches the original hash, safe to auto-update
-- **modified** — user has customized this file, needs careful merge
-- **deleted** — user deleted this file, skip update
+- **unmodified** — file matches the original template, safe to replace
+- **modified** — user has customized this file, needs careful review
+- **deleted** — user deleted this file, skip update for it
 - **new** — file doesn't exist locally, safe to create
-- **removed** — file was removed upstream, review before deleting
+- **removed** — file was removed upstream, user decides whether to delete
+- **crossDependencies** — import relationships between categories (if detected)
 
-### Step 4: Generate Update Plan
+### Step 4: Analyze Dependencies
 
-**This is a critical step.** After classification, generate the update plan file at:
+This step prevents breaking the user's code through indirect effects.
 
-```
-.generatesaas/updates/update-{currentVersion}-to-{targetVersion}.md
-```
+1. **Read `crossDependencies`** from classification.json (if present). This shows:
+   - `modifiedImportsUnmodified` — modified files that import from auto-apply files
+   - `unmodifiedImportsModified` — auto-apply files that import from modified files
+   - `newImportsModified` — new files that import from modified files
+
+2. **For each cross-dependency**, read the relevant diff at `references/diffs/<path>.diff`:
+   - If an auto-apply file's diff changes **exports, function signatures, types, or interfaces** that a modified file uses → promote it from `unmodified` to `modified` (it needs user review alongside its dependent)
+   - If an auto-apply file imports from a modified file → flag it as needing review after the modified file is handled
+
+3. **Update `references/classification.json`**: before making any changes, copy the file to `references/classification-original.json` as a backup. Then move any promoted files from the `unmodified` array to the `modified` array. This ensures `apply-auto.js` only touches truly safe files. If you need to redo the analysis, restore from the backup.
 
-The plan must follow this format:
+4. If there are no cross-dependencies or all cross-dependencies are safe (no API changes), no reclassification is needed.
+
+### Step 5: Present Update Plan and Choose Mode
+
+Generate the plan file at `.generatesaas/updates/update-{currentVersion}-to-{targetVersion}.md`.
+
+Present the plan organized by category:
 
 ```markdown
 # Update: {currentVersion} → {targetVersion}
@@ -65,242 +130,294 @@ The plan must follow this format:
 Date: {YYYY-MM-DD}
 
 ## Summary
+{Brief description based on changelog}
 
-{Brief description of what this update includes based on the changelog}
+## Safe Auto-Updates ({count} files)
+These files haven't been customized and will be updated automatically:
+- [ ] `path/to/file.ts` — {brief description of change}
 
-## Auto-Updates (Unmodified Files)
+## New Files ({count} files)
+New in this version:
+- [ ] `path/to/new-file.ts` — {what this file does}
 
-These files haven't been modified and will be updated automatically:
+## Files Needing Review ({count} files)
+These files have your customizations. Each one will be presented for your decision:
+- [ ] `path/to/modified.ts` — Risk: {Low/Medium/High} — {what changed}
 
-- [x] `path/to/file.ts` — {brief description of change}
-- [x] `path/to/other.ts` — {brief description of change}
+## Removed Upstream ({count} files)
+Removed in the new version — you decide whether to delete:
+- [ ] `path/to/old-file.ts` — {why it was removed}
 
-## New Files
+## Skipped
+{Empty — items move here during execution with reasons}
+```
 
-These files are new in this version and will be created:
+Then ask the user to choose their interaction level:
 
-- [x] `path/to/new-file.ts` — {what this file does}
+> **How would you like to handle this update?**
+>
+> 1. **Recommended** — Auto-apply safe files, then I'll walk you through each modified file with my recommendation. You approve or adjust each one.
+> 2. **Careful** — I'll present every single change for your approval, including auto-updates. Nothing happens without your explicit OK.
+> 3. **Quick** — Auto-apply safe files, auto-apply my recommended merges for low-risk files, and only ask you about medium/high-risk changes.
 
-## Manual Merges (Modified Files)
+**Wait for the user's choice.** Default to **Recommended** if they just say "proceed" or similar.
 
-These files have been customized. Changes will be merged preserving your modifications:
+### Step 6: Apply Safe Auto-Updates
 
-- [ ] `path/to/modified.ts` — {what upstream changed vs what you changed}
-- [ ] `path/to/config.ts` — {description}
+Based on the user's chosen mode:
 
-## Removed Upstream
+**Recommended / Quick mode:**
+```bash
+node __SKILL_ROOT__/generatesaas-update/scripts/apply-auto.js
+```
+Report what was applied. Mark all auto-update and new file items as `[x]` in the plan.
 
-These files were removed in the new version. Review before deleting:
+**Careful mode:**
+Present the list of safe auto-updates and new files to the user:
+> These {N} files haven't been customized and can be safely replaced with the new version. {N} new files will be created. Want me to apply all of these, or would you like to review any specific ones first?
 
-- [ ] `path/to/old-file.ts` — {why it was removed}
+If the user wants to review specific files, show them the diff for each requested file. Apply only after approval.
 
-## Skipped
+### Step 7: Review Modified Files
 
-Changes that were not applied (with reasons):
+This is the most important step. Work through each file in the `modified` category.
+
+#### For Each Modified File
+
+For each file, you have three versions available for proper three-way merge context:
+
+1. **Old template:** `.generatesaas/template/<path>` — the original boilerplate version
+2. **New template:** `.generatesaas/staging/<path>` — the updated boilerplate version
+3. **User's version:** the current file on disk — their customized version
+
+The diff at `references/diffs/<path>.diff` shows **pure upstream changes** (old template → new template), making it easy to see exactly what we changed and why.
+
+If `.generatesaas/template/<path>` does not exist (backward compat), fall back to comparing the user's file against staging directly. If no diff file exists, read both files to understand the differences.
+
+**Present the situation clearly:**
 
-{empty until items are skipped during execution}
 ```
+### `{file path}`
 
-**Present this plan to the user.** Explain the key changes and ask if they want to exclude anything. Wait for confirmation before proceeding.
+**What changed upstream:** {describe changes from old template → new template, referencing the diff and changelog}
+**What you changed:** {describe changes from old template → user's file — compare the two to identify customizations}
+**Overlap:** {None / Partial / Significant}
+**Risk:** {Low / Medium / High}
 
-If the user wants to exclude items, move them to the **Skipped** section with the reason "Excluded by user".
+{Explain risk: Low = changes don't overlap. Medium = some overlap but cleanly resolvable. High = significant structural conflict or the file was heavily rewritten.}
 
-### Step 5: Apply Auto-Updates
+**My recommendation:** {one of the actions below}
 
-```bash
-node __SKILL_ROOT__/generatesaas-update/scripts/apply-auto.js
+{If recommending a merge, show the proposed result with comments marking the source:}
 ```
 
-Automatically updates `unmodified` files and creates `new` files. These are safe because:
-- Unmodified files have no user changes to preserve
-- New files don't conflict with anything
+**Then present the user's options:**
 
-After this completes, mark all auto-update and new file items as `[x]` in the plan.
+> **What would you like to do?**
+> 1. **Accept merge** — {brief description of the merged result}
+> 2. **Keep my version** — Skip this upstream change entirely
+> 3. **Use upstream version** — Replace with the new template version (your changes will be lost)
+> 4. **Show me the diff** — Display the raw upstream diff so I can review it
+> 5. **Let me customize** — Tell me exactly what you want
 
-### Step 6: Manual Merge (Modified Files)
+**In Quick mode:** For **Low risk** files, apply the recommended merge automatically and report what was done. For **Medium/High risk**, always ask.
 
-For each file in the `modified` category, work through the plan checklist one by one:
+**In Recommended mode:** Present each file and wait for the user's decision.
 
-1. Read the corresponding diff at `references/diffs/<path>.diff` (if no diff exists, the file was new upstream but already exists locally — read the staging copy at `.generatesaas/staging/<path>` instead)
-2. Read the current local file
-3. Understand what the user changed and why
-4. Apply upstream changes that are compatible with the user's modifications
-5. **Skip changes that would break user functionality** — move to Skipped section with explanation
-6. Mark the item as `[x]` in the plan when done
+**In Careful mode:** Present each file with the full proposed merged code shown, and wait for the user's decision.
 
-For `removed` files:
-1. Check if the user depends on the file
-2. If the user modified it or other files import it, move to Skipped with explanation
-3. If truly unused, delete it and mark as `[x]`
+#### For Removed Files
 
-**After each file, update the plan file** so progress is tracked in real-time.
+Before presenting each removed file, **search the entire project** for imports of it. Use grep to find `import ... from` or `require(...)` statements referencing the file's path (check relative paths, aliases, and package paths). This is critical — the classification script only scans files in the update, not user-created files that may also depend on the removed file.
 
-### Step 7: Complete Update
+```
+### `{file path}` — Removed Upstream
 
-After all items are processed:
+**Why it was removed:** {reason from changelog}
+**Your modifications:** {describe if the user modified it, or "None — file is unmodified"}
+**Files that import this:** {list ALL files found by searching, or "None found"}
 
-1. Review the plan — verify every item is either `[x]` (completed) or listed in Skipped with a reason
-2. If any items are still unchecked, address them or move to Skipped with explanation
-3. Run the completion script:
+> **What would you like to do?**
+> 1. **Delete it** — It's no longer needed upstream
+> 2. **Keep it** — I still use this file
+```
+
+If ANY files import the removed file, always warn before deletion and explain what would break.
+
+#### For Deleted-by-User Files
+
+Files the user intentionally deleted — skip silently. Just note in the plan: "Skipped — user previously deleted this file."
+
+#### After Each File
+
+1. Apply the user's chosen action immediately
+2. Mark the item as `[x]` (completed) or move to **Skipped** with the reason
+3. **Update the plan file** after every file so progress is saved
+
+#### Cascade Awareness
+
+After processing ALL modified files, review the results:
+
+- If any modified files were **skipped** (user chose to keep their version), check if any already-auto-applied files depend on the skipped file's original structure
+- If an auto-applied file imports from a skipped file and the auto-applied file's update expected the new version of that import: warn the user
+
+> I auto-applied `{auto-file}` in Step 6, but it may depend on changes in `{skipped-file}` which you chose to keep as-is. The new version of `{auto-file}` might not be fully compatible.
+>
+> **Options:**
+> 1. **Revert `{auto-file}`** to the previous version
+> 2. **Keep it** — I'll check if it still works
+> 3. **Let me look at both files** to decide
+
+Similarly, if an auto-applied file changed its exports and a modified file that imports from it was merged — verify the merge accounts for the new API.
+
+### Step 8: Post-Update Validation
+
+After all files are processed:
+
+1. **Check for obvious issues:**
+   - Scan merged files for syntax errors or broken imports
+   - If the project has TypeScript, suggest running type check
+   - Note: auto-applied files may have changed their exports/API in ways that affect **user-created files** (files not part of the template). The classification script only scans template files for cross-dependencies. A type check is the best way to catch breakage in user-created files.
+
+> All changes have been applied. Would you like me to run a type check / build to verify nothing is broken? This is especially important since some auto-applied files may have changed their API, which could affect your custom files.
+
+2. If issues are found, present them:
+
+> Found {N} issues after the update:
+> - `{file}:{line}` — {description}
+>
+> These appear to be caused by the update. Want me to fix them?
+
+3. Fix any issues the user approves, then re-verify.
+
+### Step 9: Complete Update
+
+1. **Record held-back files.** Write `.generatesaas/held-back.json` with the list of files where the **template change was NOT applied** to the project. This tells the completion script to preserve old template hashes so the next update generates correct diffs that include the missed changes.
+
+**Include** in held-back.json:
+- Modified files where the user chose "Keep my version"
+- Modified files that were skipped for any reason (couldn't merge, user excluded, etc.)
+- Auto-apply files that were reverted in the cascade awareness step
+
+**Do NOT include:**
+- Files where the user accepted a merge or chose "Use upstream version" (template changes were applied)
+- Removed files (not in staging — template-hashes handles these automatically)
+- New files, whether created or rejected (handled correctly by staging presence)
+- Any file where the template's intended change was successfully applied
+
+```json
+["path/to/skipped.ts", "path/to/another.ts"]
+```
+
+If no files were held back, skip creating this file.
+
+2. **Run the completion script:**
 
 ```bash
 node __SKILL_ROOT__/generatesaas-update/scripts/complete-update.js
 ```
 
-This regenerates `.generatesaas/hashes.json` with fresh file hashes and updates the version in `.generatesaas/manifest.json`. Cleans up the `references/` directory.
+This updates `.generatesaas/manifest.json` to the new version, regenerates file hashes, and cleans up staging.
 
-4. Add a final status to the plan file:
+3. **Present the final summary:**
 
 ```markdown
 ## Result
 
-- **Status**: Completed
-- **Files updated**: {count}
-- **Files created**: {count}
-- **Files merged**: {count}
-- **Items skipped**: {count}
-- **Post-update steps**: {e.g., "Run pnpm install", "Run migrations", etc.}
+- **Status:** Completed
+- **Files auto-updated:** {count}
+- **Files merged with your input:** {count}
+- **New files created:** {count}
+- **Changes skipped:** {count}
+- **Issues fixed:** {count or "None"}
+
+### Post-update steps
+- Run `pnpm install` if dependencies changed
+- Run database migrations if schema was updated
+- {any other steps from the changelog}
+
+### Skipped changes
+{For each skipped item: what was skipped and why — so the user can revisit later}
 ```
 
+---
+
 ## Merge Strategies
 
+Use these strategies when merging modified files. The goal is always: apply upstream improvements without losing user customizations.
+
 ### Config Files (`*.config.ts`, `config/index.ts`, `config/pricing.ts`)
 
-Config files are the most commonly customized. The upstream diff usually adds new options or changes defaults.
+Config files are the most commonly customized.
 
 - Preserve all user-set values
 - Add new config keys with their default values
-- If a key was renamed upstream, migrate the user's value to the new key
+- If a key was renamed upstream, migrate the user's value to the new key name
 - Keep user's formatting preferences if they differ
+- Present the merged config to the user for review
 
 ### Components (`.vue`, `.tsx`)
 
-- Preserve user-added props, slots, and event handlers
-- Apply upstream structural changes (new elements, changed layouts)
+- Preserve user-added props, slots, event handlers, and custom logic
+- Apply upstream structural changes (new elements, accessibility improvements, bug fixes)
 - Keep user's custom CSS classes and styles
-- If the component was significantly restructured upstream, present both versions and ask
+- If the component was significantly restructured upstream AND the user heavily modified it: present both versions side by side and let the user decide
 
 ### API Routes (`routes/*.ts`)
 
 - Preserve user-added endpoints and middleware
-- Apply upstream changes to existing endpoints (bug fixes, new validations)
+- Apply upstream bug fixes and security patches to existing endpoints
 - Keep user-added business logic intact
 - Watch for new imports or dependency changes
 
 ### Database (schema, migrations)
 
-- NEVER auto-merge schema files — always present changes for review
+- NEVER auto-merge schema files — always present for user review
 - New migration files can be added directly
-- Schema changes may require new migrations the user needs to create
+- Warn about schema changes that may require new migrations
 
 ### Package Dependencies (`package.json`)
 
 - Add new dependencies from upstream
-- Update version ranges for existing dependencies only if the upstream change is intentional (security fix, breaking change requirement)
+- Update version ranges only for intentional upstream changes (security, breaking change requirements)
 - Preserve user-added dependencies
-- Never modify `pnpm-lock.yaml` — user runs `pnpm install` after
+- Never touch `pnpm-lock.yaml` — user runs `pnpm install` after
 
 ### Translation Files (`en.json`)
 
 - Add new translation keys from upstream
 - Preserve user-modified translation values
-- Remove keys that were deleted upstream (they're unused)
+- Remove keys deleted upstream (they correspond to removed features)
 - Maintain alphabetical ordering within sections
 
 ### Environment Files (`.env.example`)
 
-- Add new environment variables with their example values
+- Add new environment variables with their example values and comments
 - Preserve user-added variables
-- Update comments for changed variables
 - Never touch actual `.env` files
 
-## When to Skip a Change
+## When to Skip
 
-Move the item to the **Skipped** section of the plan with a clear reason when:
+Move items to the **Skipped** section with a clear reason when:
 
-- The upstream change modifies code the user has significantly rewritten — applying it would undo their work
+- The upstream change modifies code the user has significantly rewritten
 - The upstream fix addresses a bug the user already fixed differently
-- A new feature conflicts with the user's custom implementation of the same thing
-- Applying the change would create invalid code, type errors, or runtime failures
-- The user explicitly asked to exclude it
+- A new feature conflicts with the user's custom implementation
+- Applying the change would create type errors or runtime failures
+- The user explicitly chose to keep their version
 
 When skipping, always explain:
-- What the upstream change was trying to do
-- Why it was skipped
-- Whether the user should manually review it later
-
-## When to Ask the User
-
-- Schema changes that might need migrations
-- Removed files or features the user might depend on
-- Config changes where the user's value conflicts with a new required format
-- Component restructures where preserving user changes is ambiguous
-- Any change where applying both upstream and user modifications would create invalid code
-- When you're unsure whether a user's modification was intentional
-
-## Examples
-
-### Config merge
-
-Upstream diff adds a new `analytics` field:
-```diff
- export default {
-   siteName: "My SaaS",
-+  analytics: {
-+    enabled: true,
-+    provider: "plausible",
-+  },
-   billing: {
-     scope: "organization",
-   },
- };
-```
+1. What the upstream change was trying to do
+2. Why it was skipped
+3. Whether the user should revisit it later
 
-User has customized `siteName` and `billing.scope`. Result:
-```typescript
-export default {
-  siteName: "Acme Corp",        // user's value preserved
-  analytics: {                   // new field added with defaults
-    enabled: true,
-    provider: "plausible",
-  },
-  billing: {
-    scope: "user",              // user's value preserved
-  },
-};
-```
-
-### Translation merge
-
-Upstream diff:
-```diff
- {
-   "dashboard": {
-     "title": "Dashboard",
--    "old_metric": "Old Metric",
-+    "new_metric": "New Metric",
-+    "analytics": "Analytics"
-   }
- }
-```
-
-User changed `dashboard.title` to `"Control Panel"`. Result:
-```json
-{
-  "dashboard": {
-    "title": "Control Panel",
-    "new_metric": "New Metric",
-    "analytics": "Analytics"
-  }
-}
-```
-`old_metric` removed (upstream deleted it), `title` preserved (user customized it), new keys added.
+## When to Always Ask
 
-### Skipped change example
+Even in Quick mode, always ask the user about:
 
-Plan entry:
-```markdown
-## Skipped
-
-- `app/components/PricingTable.vue` — Upstream restructured the pricing grid layout from CSS Grid to Flexbox. User has heavily customized this component with custom tier cards and comparison features. Applying the layout change would break the custom tier rendering. **User should review the diff manually if they want the new layout.**
-```
+- Database schema changes
+- Files where user modifications are extensive (>30% of the file differs from template)
+- Changes where upstream and user modifications touch the same code sections
+- Removed files that other code depends on
+- Config changes where user's value format conflicts with new requirements
+- Any change where you're unsure about the right action

package/dist/skill/content/scripts/_helpers.js

@@ -10,6 +10,7 @@ const INTERNAL_DIR = ".generatesaas";
 const MANIFEST_FILE = path.join(INTERNAL_DIR, "manifest.json");
 const HASHES_FILE = path.join(INTERNAL_DIR, "hashes.json");
 const TEMPLATE_HASHES_FILE = path.join(INTERNAL_DIR, "template-hashes.json");
+const TEMPLATE_DIR = path.join(INTERNAL_DIR, "template");
 const STAGING_DIR = path.join(INTERNAL_DIR, "staging");
 const STAGING_META_FILE = path.join(INTERNAL_DIR, "staging.json");
 
@@ -43,7 +44,7 @@ function hashFile(filePath) {
 // exclusions.ts, so most of these only matter when walking the live project root.
 const WALK_EXCLUSIONS = new Set([
 	".git", "node_modules", ".pnpm-store", ".env", ".env.test",
-	".turbo", ".nuxt", ".output", ".data", "dist",
+	".turbo", ".nuxt", ".output", ".data", "dist", "data",
 	".next", ".svelte-kit", ".netlify", ".wrangler",
 	".devcontainer", "playwright-report", "test-results",
 	INTERNAL_DIR,
@@ -89,6 +90,7 @@ module.exports = {
 	MANIFEST_FILE,
 	HASHES_FILE,
 	TEMPLATE_HASHES_FILE,
+	TEMPLATE_DIR,
 	STAGING_DIR,
 	STAGING_META_FILE,
 };