jettypod 4.4.118 → 4.4.121

package/skills-templates/stable-mode/SKILL.md

@@ -18,7 +18,7 @@ description: Guide implementation of stable mode chores with comprehensive testi
 └─────────────────────────────────────────────────────────────────────┘
 ```
 
-## 🛑 CRITICAL HANDOFF REQUIREMENT
+## CRITICAL HANDOFF REQUIREMENT
 
 **After completing ALL stable mode chores:**
 
@@ -30,7 +30,7 @@ description: Guide implementation of stable mode chores with comprehensive testi
 1. Set feature mode to production
 2. **IMMEDIATELY invoke production-mode using the Skill tool**
 
-**🛑 STOP GATE:** For external projects, DO NOT end this skill without invoking production-mode. Stable mode makes it robust - production mode makes it ready for real users at scale.
+**STOP GATE:** For external projects, DO NOT end this skill without invoking production-mode. Stable mode makes it robust - production mode makes it ready for real users at scale.
 
 ---
 
@@ -40,7 +40,7 @@ Guides Claude Code through stable mode implementation with comprehensive testing
 
 When this skill is activated, you are helping implement a stable mode chore to add comprehensive testing and error handling. Follow this structured approach:
 
-## 🔑 Critical Context
+## Critical Context
 
 **You are working in an isolated git worktree:**
 - `work start [chore-id]` created a dedicated worktree for this chore
@@ -52,7 +52,7 @@ When this skill is activated, you are helping implement a stable mode chore to a
 
 ---
 
-## 🚨 SHELL CWD RECOVERY
+## SHELL CWD RECOVERY
 
 **If ALL bash commands start failing with "Error: Exit code 1" and no output:**
 
@@ -68,7 +68,7 @@ Your shell's working directory was likely inside a worktree that was deleted. Th
 
 ---
 
-## 🛑 PRE-FLIGHT VALIDATION (REQUIRED)
+## PRE-FLIGHT VALIDATION (REQUIRED)
 
 **Before proceeding with ANY implementation, you MUST validate the worktree exists.**
 
@@ -82,17 +82,17 @@ sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.status, wt.worktree_path,
 
 | worktree_path | What it means | Action |
 |---------------|---------------|--------|
-| **Has a path** (e.g., `/path/to/.jettypod-work/...`) | ✅ Worktree exists, ready to proceed | Continue to Step 0 |
-| **NULL or empty** | ❌ `work start` was not called | **STOP - run `jettypod work start [chore-id]` first** |
-| **No rows returned** | ❌ No chore is in progress | **STOP - verify the chore exists and run `work start`** |
+| **Has a path** (e.g., `/path/to/.jettypod-work/...`) | Worktree exists, ready to proceed | Continue to Step 0 |
+| **NULL or empty** | `work start` was not called | **STOP - run `jettypod work start [chore-id]` first** |
+| **No rows returned** | No chore is in progress | **STOP - verify the chore exists and run `work start`** |
 
-**🛑 STOP GATE:** If `worktree_path` is NULL or no rows returned, you MUST run `jettypod work start [chore-id]` before continuing. DO NOT proceed without a valid worktree.
+**STOP GATE:** If `worktree_path` is NULL or no rows returned, you MUST run `jettypod work start [chore-id]` before continuing. DO NOT proceed without a valid worktree.
 
-**🚫 FORBIDDEN: Manual Git Worktree Commands**
+**FORBIDDEN: Manual Git Worktree Commands**
 ```
-❌ git worktree add ...
-❌ git checkout -b feature/...
-❌ git branch feature/...
+git worktree add ...
+git checkout -b feature/...
+git branch feature/...
 ```
 **ALWAYS use `jettypod work start`** - it handles branch naming, path conventions, database tracking, and cleanup. Manual git commands will create orphaned worktrees that break the merge workflow.
 
@@ -109,7 +109,7 @@ sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.status, wt.worktree_path,
 
 ---
 
-## 🔒 WORKTREE PATH LOCK
+## WORKTREE PATH LOCK
 
 **After pre-flight validation passes, capture and lock the worktree path:**
 
@@ -119,7 +119,7 @@ From the pre-flight query output, extract and store:
 **Display:**
 
 ```
-🔒 WORKTREE LOCK ACTIVE
+WORKTREE LOCK ACTIVE
 Path: ${WORKTREE_PATH}
 
 All file writes will use this path.
@@ -154,7 +154,7 @@ jettypod ui gate worktree-started --data='{"path":"${WORKTREE_PATH}"}'
 **User Profile:** May not know how to code - Claude Code does the implementation autonomously.
 
 <details>
-<summary><strong>📋 What Stable Mode Includes (click to expand)</strong></summary>
+<summary><strong>What Stable Mode Includes (click to expand)</strong></summary>
 
 **Stable Mode is NOT just error handling. It includes:**
 
@@ -194,7 +194,7 @@ jettypod ui gate worktree-started --data='{"path":"${WORKTREE_PATH}"}'
 
 ---
 
-## 🧪 Unit Testing in Stable Mode - True TDD
+## Unit Testing in Stable Mode - True TDD
 
 **Unit tests are written DURING implementation, not after.**
 
@@ -214,10 +214,10 @@ jettypod ui gate worktree-started --data='{"path":"${WORKTREE_PATH}"}'
 - State consistency (transaction rollback, cleanup on failure)
 
 <details>
-<summary><strong>📋 Unit Test Examples (click to expand)</strong></summary>
+<summary><strong>Unit Test Examples (click to expand)</strong></summary>
 
 ```javascript
-// ✅ Stable mode unit tests (error paths and edge cases)
+// Stable mode unit tests (error paths and edge cases)
 test('createUser throws ValidationError for null email', () => {
   expect(() => createUser('John', null)).toThrow(ValidationError);
   expect(() => createUser('John', null)).toThrow('Email is required');
@@ -266,7 +266,7 @@ test('getUserById returns null for non-existent user', () => {
 sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.parent_id, parent.title as parent_title, parent.scenario_file, wt.worktree_path, wt.branch_name FROM work_items wi LEFT JOIN work_items parent ON wi.parent_id = parent.id LEFT JOIN worktrees wt ON wi.id = wt.work_item_id WHERE wi.status = 'in_progress' AND wi.type = 'chore'"
 ```
 
-**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+**WORKFLOW INTEGRATION: Start workflow tracking**
 
 After getting the work context, register this skill execution:
 
@@ -280,7 +280,7 @@ This validates that `speed_mode_complete` gate is passed and creates an executio
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🛡️  STABLE MODE: Implementing Chore #[id]
+ STABLE MODE: Implementing Chore #[id]
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Chore: [title]
@@ -299,11 +299,11 @@ Analyzing stable mode BDD scenarios to determine what error handling and validat
 
 **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is an ANALYSIS step.** File writes happen in Step 5.
 
@@ -331,15 +331,15 @@ sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.description, wi.parent_id,
 4. If no match found, list available scenarios and ask which one to implement
 
 **Handle errors gracefully:**
-- If no current work: "❌ No current work found. Run: jettypod work start <chore-id>"
-- If no parent feature: "❌ Current work has no parent feature."
-- If no scenario_file: "❌ Feature has no scenario_file."
+- If no current work: "No current work found. Run: jettypod work start <chore-id>"
+- If no parent feature: "Current work has no parent feature."
+- If no scenario_file: "Feature has no scenario_file."
 - If can't match chore to scenario: List available scenarios and ask user
 
 **Display to user:**
 
 ```
-🧪 Stable Mode: [Feature Name]
+Stable Mode: [Feature Name]
 
 Target Scenario:
 [Scenario title]
@@ -364,11 +364,11 @@ Now reviewing speed mode implementation...
 
 **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is an ANALYSIS step.** File writes happen in Step 5.
 
@@ -399,14 +399,14 @@ Then use the Read tool to examine the implementation files.
 **Display analysis:**
 
 ```
-📊 Code Analysis Complete
+Code Analysis Complete
 
 Current Implementation:
 • Files: [list]
-• Success scenarios: ✅ Working (from speed mode)
-• Error handling: ❌ Missing [specific gaps]
-• Validation: ❌ Missing [specific gaps]
-• Edge cases: ❌ Not handled [specific gaps]
+• Success scenarios: Working (from speed mode)
+• Error handling: Missing [specific gaps]
+• Validation: Missing [specific gaps]
+• Edge cases: Not handled [specific gaps]
 
 To pass the target scenario, I need to:
 1. [Specific change]
@@ -416,7 +416,7 @@ To pass the target scenario, I need to:
 Now proposing comprehensive implementation...
 ```
 
-**🔄 WORKFLOW CHECKPOINT: Code analysis complete**
+**WORKFLOW CHECKPOINT: Code analysis complete**
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=2
@@ -424,11 +424,11 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 ### Step 3: Decide if Confirmation Needed
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is a DECISION step.** File writes happen in Step 5.
 
@@ -448,20 +448,20 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 ### Step 3A: Propose Implementation Approach (Conditional)
 
-**⚡ ASYNC BOUNDARY - Only execute this if confirmation needed**
+**ASYNC BOUNDARY - Only execute this if confirmation needed**
 
-**🚫 FORBIDDEN: Writing Files at This Step**
+**FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to any path
-❌ Edit tool to any path
-❌ Any file creation or modification
+Write tool to any path
+Edit tool to any path
+Any file creation or modification
 ```
 **This is a PROPOSAL step.** File writes happen in Step 5.
 
 **Present your analysis and proposal to the user:**
 
 ```
-💡 Implementation Proposal
+Implementation Proposal
 
 I see multiple ways to approach this error handling. Here's what I'm thinking:
 
@@ -476,7 +476,7 @@ I see multiple ways to approach this error handling. Here's what I'm thinking:
 Sound good, or would you prefer a different approach?
 ```
 
-**⚡ WAIT for user confirmation or adjustments.**
+**WAIT for user confirmation or adjustments.**
 
 If user adjusts: revise proposal and confirm again before proceeding.
 
@@ -484,6 +484,16 @@ If user adjusts: revise proposal and confirm again before proceeding.
 
 ---
 
+### BDD Step Definition Constraints (ENFORCED)
+
+Before writing any step definitions, read `templates/bdd-guidance.md`. BANNED in step defs: `setTimeout`/`sleep`, module-level `let`/`var`, raw SQL, assertions in Given/When, loops/branching, self-fulfilling mocks (setting state then asserting it). Steps must be 1-5 lines calling one helper via Cucumber World (`this`). Read `features/support/helpers/` and reuse before creating.
+
+**Scaffolding:** If `features/support/helpers/` does not exist in the project, scaffold it before writing step definitions. Copy `templates/bdd-scaffolding/wait.js` to `features/support/helpers/wait.js` and `templates/bdd-scaffolding/world.js` to `features/support/world.js`.
+
+**Helper Reuse:** Before writing step definitions, glob `features/support/helpers/**/*.js` and read each file. Import and call existing helpers in your steps — never duplicate functionality that already exists.
+
+---
+
 ### Step 4: Establish RED Baseline
 
 **CRITICAL:** After user confirms (or skips confirmation), execute autonomously - no permission needed for code changes.
@@ -528,25 +538,25 @@ Parse the output to identify:
 
 **Display RED baseline:**
 ```
-🔴 Establishing RED baseline...
+Establishing RED baseline...
 
 RED Baseline: 3 of 11 steps failing (stable mode scenarios)
 
 Failing steps:
-  ✖ Then it should throw a validation error
-  ✖ And the error message should be "Email is required"
-  ✖ When I provide an empty string as input
+  Then it should throw a validation error
+  And the error message should be "Email is required"
+  When I provide an empty string as input
 
 First error:
   Step: Then it should throw a validation error
   Error: Error: Expected function to throw but it didn't
 
-🎯 Goal: Make all stable mode scenarios pass
+Goal: Make all stable mode scenarios pass
 
 Now implementing...
 ```
 
-**🔄 WORKFLOW CHECKPOINT: RED baseline established**
+**WORKFLOW CHECKPOINT: RED baseline established**
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=4
@@ -556,9 +566,9 @@ jettypod workflow checkpoint <feature-id> --step=4
 
 ### Step 5: RED→GREEN→REFACTOR Loop
 
-**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured after pre-flight validation.
+**WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured after pre-flight validation.
 
-**✅ NOW you may write files** - worktree is locked, approach is confirmed.
+**NOW you may write files** - worktree is locked, approach is confirmed.
 
 **Emit gate signal:**
 
@@ -581,23 +591,23 @@ jettypod ui gate implementing --data='{"description":"[stable mode error handlin
 **Show progress each iteration:**
 ```
 ━━━ Iteration 3/10 ━━━
-📝 Unit test: test/user.test.js - validates email format
+Unit test: test/user.test.js - validates email format
    RED: Test fails - no validation exists yet
-✍️  Implementation: src/user.js - added email format validation
+ Implementation: src/user.js - added email format validation
    GREEN: Unit test passes
-🧪 Running BDD scenarios...
-📊 Progress: 9/11 BDD steps passing
-✅ Newly passing: Then it should throw a validation error
-🔧 Next failure: And the error message should be user-friendly
+Running BDD scenarios...
+Progress: 9/11 BDD steps passing
+Newly passing: Then it should throw a validation error
+Next failure: And the error message should be user-friendly
     BDD step: Then the error message should be "Email format is invalid"
 ```
 
 **When GREEN achieved:**
 ```
-🎉 GREEN: All stable mode scenarios passing!
+GREEN: All stable mode scenarios passing!
 ```
 
-**🔄 WORKFLOW CHECKPOINT: GREEN achieved**
+**WORKFLOW CHECKPOINT: GREEN achieved**
 
 ```bash
 jettypod workflow checkpoint <feature-id> --step=5
@@ -612,7 +622,7 @@ jettypod workflow checkpoint <feature-id> --step=5
 **Re-run tests after refactor** to ensure nothing broke.
 
 <details>
-<summary><strong>📋 TDD Loop Guidelines (click to expand)</strong></summary>
+<summary><strong>TDD Loop Guidelines (click to expand)</strong></summary>
 
 **Iteration strategy:**
 - Start with first failing stable mode step
@@ -632,6 +642,8 @@ jettypod workflow checkpoint <feature-id> --step=5
 
 </details>
 
+**Quality Gate:** Before committing, review every `.steps.js` file you wrote or modified. Check for banlist violations: `setTimeout`/`sleep`, module-level `let`/`var`, raw SQL, assertions in Given/When, self-fulfilling mocks, steps longer than 5 lines. Fix violations before proceeding.
+
 ---
 
 ### Step 6: Route After Chore Completion
@@ -654,10 +666,10 @@ sqlite3 .jettypod/work.db "SELECT id, title FROM work_items WHERE parent_id = <f
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 Stable Mode Chore Complete
+Stable Mode Chore Complete
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-✅ Error handling and validation scenarios pass for this chore
+Error handling and validation scenarios pass for this chore
 
 More stable mode chores remain. Starting next chore:
 #[next-chore-id]: [next-chore-title]
@@ -675,6 +687,8 @@ git add . && git commit -m "feat: [brief description of error handling added]"
 jettypod work merge [current-chore-id]
 ```
 
+**If merge fails with `Uncommitted changes detected`:** `git stash` from main repo CWD → create a work item for the stashed changes → `jettypod work start <id>` → `git stash pop` in that worktree → commit → merge → cleanup → then retry your original merge.
+
 ```bash
 # Step 2: cd to main repo
 cd /path/to/main/repo
@@ -699,7 +713,7 @@ If the query returns no remaining chores, proceed to Step 7.
 
 ### Step 7: Complete Feature or Transition to Production Mode
 
-**🛑 CRITICAL: This step ONLY runs after ALL stable chores are complete.**
+**CRITICAL: This step ONLY runs after ALL stable chores are complete.**
 
 **First, merge the final stable chore:**
 
@@ -729,6 +743,31 @@ pwd && ls .jettypod  # verify
 jettypod work cleanup [current-chore-id]
 ```
 
+**Then generate QA checklist for the parent feature:**
+
+Read the BDD scenario file for the parent feature. Based on the scenarios and your knowledge of what was implemented, generate specific, human-actionable QA checklist steps. Each step should be something a QA tester can verify manually in the running app.
+
+Write a JSON array to `/tmp/qa-steps.json`:
+```json
+[
+  {"section": "Section Name", "text": "Action to perform and expected result", "detail": "Additional context if needed"},
+  ...
+]
+```
+
+Guidelines for good QA steps:
+- Be specific: "Open Settings, click Claude Code section" not "Navigate to the feature"
+- Include expected outcomes: "dropdown shows Haiku as selected" not "model is selected"
+- One verifiable action per step
+- Group into sections (e.g., "Model Selection", "Persistence", "Error Handling")
+- Cover happy paths AND edge cases from the BDD scenarios
+- 5-15 steps total (not too few to be useless, not too many to be tedious)
+
+Then store them:
+```bash
+jettypod work set-qa-steps [parent-feature-id] --from=/tmp/qa-steps.json
+```
+
 **Then check project state:**
 
 ```bash
@@ -741,6 +780,26 @@ sqlite3 .jettypod/work.db "SELECT project_state FROM project_config WHERE id = 1
 
 **If project_state = 'internal':**
 
+**Prove It Works (REQUIRED):**
+
+Before marking the feature complete, demonstrate it works in practice — not just that tests pass.
+
+1. **Run or build the actual code** — compile, start the server, execute the command, or trigger the relevant workflow
+2. **Show real output** — display console output, build result, or observable behavior
+3. **Confirm it matches expectations** — verify the output is what was requested
+
+**Display:**
+
+```
+Verifying in practice...
+
+[Actual output from running/building the code]
+
+Verified: [what was confirmed]
+```
+
+**If the change cannot be run directly** (requires hardware, external service, or manual UI interaction), state what the user should verify manually and why you can't verify it yourself.
+
 **The merge command automatically sets the feature as ready for review.**
 It will appear with accept/reject buttons on the kanban board. Do NOT call `jettypod work status <feature-id> done` — that bypasses the review gate.
 
@@ -748,19 +807,19 @@ It will appear with accept/reject buttons on the kanban board. Do NOT call `jett
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-✅ FEATURE COMPLETE!
+FEATURE COMPLETE!
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Feature: #[id] [Feature Title]
-Status: ✅ DONE
+Status: DONE
 
 What we accomplished:
-✅ All BDD scenarios passing (success + error handling + edge cases)
-✅ Comprehensive error handling and validation
-✅ Input validation and edge case coverage
-✅ State consistency and data integrity
+All BDD scenarios passing (success + error handling + edge cases)
+Comprehensive error handling and validation
+Input validation and edge case coverage
+State consistency and data integrity
 
-📝 INTERNAL PROJECT - STABLE MODE IS COMPLETE
+INTERNAL PROJECT - STABLE MODE IS COMPLETE
 
 This is an internal project - stable mode is the end state.
 Feature is complete and ready to use!
@@ -769,7 +828,7 @@ Note: If you later transition to external (accepting real users),
 run the external-transition skill to generate production chores.
 ```
 
-**🔄 WORKFLOW INTEGRATION: Complete workflow (internal project)**
+**WORKFLOW INTEGRATION: Complete workflow (internal project)**
 
 ```bash
 jettypod workflow complete stable-mode <feature-id>
@@ -791,7 +850,7 @@ This marks the `stable_mode_complete` gate as passed. For internal projects, thi
 
 **If project_state = 'external':**
 
-**🛑 CRITICAL HANDOFF - You MUST invoke production-mode using the Skill tool.**
+**CRITICAL HANDOFF - You MUST invoke production-mode using the Skill tool.**
 
 **Set feature mode to production:**
 
@@ -803,21 +862,21 @@ jettypod work set-mode <feature-id> production
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 Stable Mode Complete! Transitioning to Production Mode
+Stable Mode Complete! Transitioning to Production Mode
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-⚠️  CRITICAL: This is an EXTERNAL project.
+ CRITICAL: This is an EXTERNAL project.
 Stable mode makes it robust - production mode makes it ready for real users.
 
 What we accomplished:
-✅ All BDD scenarios passing (success + error handling + edge cases)
-✅ Comprehensive error handling and validation
-✅ Feature stable and ready for production hardening
+All BDD scenarios passing (success + error handling + edge cases)
+Comprehensive error handling and validation
+Feature stable and ready for production hardening
 
-🚀 Now invoking production-mode skill...
+Now invoking production-mode skill...
 ```
 
-**🔄 WORKFLOW INTEGRATION: Complete workflow (external project)**
+**WORKFLOW INTEGRATION: Complete workflow (external project)**
 
 ```bash
 jettypod workflow complete stable-mode <feature-id>
@@ -877,17 +936,17 @@ jettypod work start <chore-id>   # Create worktree and start chore
 
 **Set feature status/mode:**
 ```bash
-# ⚠️ Do NOT call `work status done` — merge sets the review gate automatically
+# Do NOT call `work status done` — merge sets the review gate automatically
 jettypod work set-mode <feature-id> production  # Set feature to production mode (external only)
 ```
 
-**❌ DO NOT use these to complete chores:**
+**DO NOT use these to complete chores:**
 - `jettypod work status <chore-id> done`
 - `jettypod work complete <id>`
 
 ---
 
-## ⚠️ Important: Sequential Workflow
+## Important: Sequential Workflow
 
 **Stable mode chores MUST be completed sequentially, not in parallel.**
 

package/apps/dashboard/README.md

@@ -1,36 +0,0 @@
-This is a [Next.js](https://nextjs.org) project bootstrapped with [`create-next-app`](https://nextjs.org/docs/app/api-reference/cli/create-next-app).
-
-## Getting Started
-
-First, run the development server:
-
-```bash
-npm run dev
-# or
-yarn dev
-# or
-pnpm dev
-# or
-bun dev
-```
-
-Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
-
-You can start editing the page by modifying `app/page.tsx`. The page auto-updates as you edit the file.
-
-This project uses [`next/font`](https://nextjs.org/docs/app/building-your-application/optimizing/fonts) to automatically optimize and load [Geist](https://vercel.com/font), a new font family for Vercel.
-
-## Learn More
-
-To learn more about Next.js, take a look at the following resources:
-
-- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
-- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
-
-You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js) - your feedback and contributions are welcome!
-
-## Deploy on Vercel
-
-The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
-
-Check out our [Next.js deployment documentation](https://nextjs.org/docs/app/building-your-application/deploying) for more details.