diff --git a/.gemini/commands/constitution.toml b/.gemini/commands/constitution.toml
new file mode 100644
index 0000000..f2742f2
--- /dev/null
+++ b/.gemini/commands/constitution.toml
@@ -0,0 +1,72 @@
+description = "Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync."
+
+prompt = """
+---
+description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
+# (No scripts section: constitution edits are manual authoring assisted by the agent)
+---
+
+You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+
+Follow this execution flow:
+
+1. Load the existing constitution template at `.specify/memory/constitution.md`.
+   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
+   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+
+2. Collect/derive values for placeholders:
+   - If user input (conversation) supplies a value, use it.
+   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
+   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
+   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
+     * MAJOR: Backward incompatible governance/principle removals or redefinitions.
+     * MINOR: New principle/section added or materially expanded guidance.
+     * PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
+   - If version bump type ambiguous, propose reasoning before finalizing.
+
+3. Draft the updated constitution content:
+   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
+   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+
+4. Consistency propagation checklist (convert prior checklist into active validations):
+   - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
+   - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
+   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
+
+5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
+   - Version change: old → new
+   - List of modified principles (old title → new title if renamed)
+   - Added sections
+   - Removed sections
+   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
+   - Follow-up TODOs if any placeholders intentionally deferred.
+
+6. Validation before final output:
+   - No remaining unexplained bracket tokens.
+   - Version line matches report.
+   - Dates ISO format YYYY-MM-DD.
+   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
+
+7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
+
+8. Output a final summary to the user with:
+   - New version and bump rationale.
+   - Any files flagged for manual follow-up.
+   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
+
+Formatting & Style Requirements:
+- Use Markdown headings exactly as in the template (do not demote/promote levels).
+- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
+- Keep a single blank line between sections.
+- Avoid trailing whitespace.
+
+If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
+
+If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
+
+Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
+"""
diff --git a/.gemini/commands/implement.toml b/.gemini/commands/implement.toml
new file mode 100644
index 0000000..4b3aa2e
--- /dev/null
+++ b/.gemini/commands/implement.toml
@@ -0,0 +1,56 @@
+description = "Execute the implementation plan by processing and executing all tasks defined in tasks.md"
+
+prompt = """
+---
+description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
+---
+
+Given the current feature context, do this:
+
+1. Run `.specify/scripts/bash/check-implementation-prerequisites.sh --json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
+
+2. Load and analyze the implementation context:
+   - **REQUIRED**: Read tasks.md for the complete task list and execution plan
+   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
+   - **IF EXISTS**: Read data-model.md for entities and relationships
+   - **IF EXISTS**: Read contracts/ for API specifications and test requirements
+   - **IF EXISTS**: Read research.md for technical decisions and constraints
+   - **IF EXISTS**: Read quickstart.md for integration scenarios
+
+3. Parse tasks.md structure and extract:
+   - **Task phases**: Setup, Tests, Core, Integration, Polish
+   - **Task dependencies**: Sequential vs parallel execution rules
+   - **Task details**: ID, description, file paths, parallel markers [P]
+   - **Execution flow**: Order and dependency requirements
+
+4. Execute implementation following the task plan:
+   - **Phase-by-phase execution**: Complete each phase before moving to the next
+   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
+   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
+   - **File-based coordination**: Tasks affecting the same files must run sequentially
+   - **Validation checkpoints**: Verify each phase completion before proceeding
+
+5. Implementation execution rules:
+   - **Setup first**: Initialize project structure, dependencies, configuration
+   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
+   - **Core development**: Implement models, services, CLI commands, endpoints
+   - **Integration work**: Database connections, middleware, logging, external services
+   - **Polish and validation**: Unit tests, performance optimization, documentation
+
+6. Progress tracking and error handling:
+   - Report progress after each completed task
+   - Halt execution if any non-parallel task fails
+   - For parallel tasks [P], continue with successful tasks, report failed ones
+   - Provide clear error messages with context for debugging
+   - Suggest next steps if implementation cannot proceed
+   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
+
+7. Completion validation:
+   - Verify all required tasks are completed
+   - Check that implemented features match the original specification
+   - Validate that tests pass and coverage meets requirements
+   - Confirm the implementation follows the technical plan
+   - Report final status with summary of completed work
+
+Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/tasks` first to regenerate the task list.
+"""
diff --git a/.gemini/commands/plan.toml b/.gemini/commands/plan.toml
new file mode 100644
index 0000000..191b350
--- /dev/null
+++ b/.gemini/commands/plan.toml
@@ -0,0 +1,40 @@
+description = "Execute the implementation planning workflow using the plan template to generate design artifacts."
+
+prompt = """
+---
+description: Execute the implementation planning workflow using the plan template to generate design artifacts.
+---
+
+Given the implementation details provided as an argument, do this:
+
+1. Run `.specify/scripts/bash/setup-plan.sh --json` from the repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. All future file paths must be absolute.
+2. Read and analyze the feature specification to understand:
+   - The feature requirements and user stories
+   - Functional and non-functional requirements
+   - Success criteria and acceptance criteria
+   - Any technical constraints or dependencies mentioned
+
+3. Read the constitution at `.specify/memory/constitution.md` to understand constitutional requirements.
+
+4. Execute the implementation plan template:
+   - Load `.specify/templates/plan-template.md` (already copied to IMPL_PLAN path)
+   - Set Input path to FEATURE_SPEC
+   - Run the Execution Flow (main) function steps 1-9
+   - The template is self-contained and executable
+   - Follow error handling and gate checks as specified
+   - Let the template guide artifact generation in $SPECS_DIR:
+     * Phase 0 generates research.md
+     * Phase 1 generates data-model.md, contracts/, quickstart.md
+     * Phase 2 generates tasks.md
+   - Incorporate user-provided details from arguments into Technical Context: {{args}}
+   - Update Progress Tracking as you complete each phase
+
+5. Verify execution completed:
+   - Check Progress Tracking shows all phases complete
+   - Ensure all required artifacts were generated
+   - Confirm no ERROR states in execution
+
+6. Report results with branch name, file paths, and generated artifacts.
+
+Use absolute paths with the repository root for all file operations to avoid path issues.
+"""
diff --git a/.gemini/commands/specify.toml b/.gemini/commands/specify.toml
new file mode 100644
index 0000000..a8588f8
--- /dev/null
+++ b/.gemini/commands/specify.toml
@@ -0,0 +1,17 @@
+description = "Create or update the feature specification from a natural language feature description."
+
+prompt = """
+---
+description: Create or update the feature specification from a natural language feature description.
+---
+
+Given the feature description provided as an argument, do this:
+
+1. Run the script `.specify/scripts/bash/create-new-feature.sh --json "{{args}}"` from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE. All file paths must be absolute.
+  **IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
+2. Load `.specify/templates/spec-template.md` to understand required sections.
+3. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
+4. Report completion with branch name, spec file path, and readiness for the next phase.
+
+Note: The script creates and checks out the new branch and initializes the spec file before writing.
+"""
diff --git a/.gemini/commands/tasks.toml b/.gemini/commands/tasks.toml
new file mode 100644
index 0000000..b85fa64
--- /dev/null
+++ b/.gemini/commands/tasks.toml
@@ -0,0 +1,62 @@
+description = "Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts."
+
+prompt = """
+---
+description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
+---
+
+Given the context provided as an argument, do this:
+
+1. Run `.specify/scripts/bash/check-task-prerequisites.sh --json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
+2. Load and analyze available design documents:
+   - Always read plan.md for tech stack and libraries
+   - IF EXISTS: Read data-model.md for entities
+   - IF EXISTS: Read contracts/ for API endpoints
+   - IF EXISTS: Read research.md for technical decisions
+   - IF EXISTS: Read quickstart.md for test scenarios
+
+   Note: Not all projects have all documents. For example:
+   - CLI tools might not have contracts/
+   - Simple libraries might not need data-model.md
+   - Generate tasks based on what's available
+
+3. Generate tasks following the template:
+   - Use `.specify/templates/tasks-template.md` as the base
+   - Replace example tasks with actual tasks based on:
+     * **Setup tasks**: Project init, dependencies, linting
+     * **Test tasks [P]**: One per contract, one per integration scenario
+     * **Core tasks**: One per entity, service, CLI command, endpoint
+     * **Integration tasks**: DB connections, middleware, logging
+     * **Polish tasks [P]**: Unit tests, performance, docs
+
+4. Task generation rules:
+   - Each contract file → contract test task marked [P]
+   - Each entity in data-model → model creation task marked [P]
+   - Each endpoint → implementation task (not parallel if shared files)
+   - Each user story → integration test marked [P]
+   - Different files = can be parallel [P]
+   - Same file = sequential (no [P])
+
+5. Order tasks by dependencies:
+   - Setup before everything
+   - Tests before implementation (TDD)
+   - Models before services
+   - Services before endpoints
+   - Core before integration
+   - Everything before polish
+
+6. Include parallel execution examples:
+   - Group [P] tasks that can run together
+   - Show actual Task agent commands
+
+7. Create FEATURE_DIR/tasks.md with:
+   - Correct feature name from implementation plan
+   - Numbered tasks (T001, T002, etc.)
+   - Clear file paths for each task
+   - Dependency notes
+   - Parallel execution guidance
+
+Context for task generation: {{args}}
+
+The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
+"""
diff --git a/.specify/scripts/bash/check-implementation-prerequisites.sh b/.specify/scripts/bash/check-implementation-prerequisites.sh
new file mode 100755
index 0000000..c660ffa
--- /dev/null
+++ b/.specify/scripts/bash/check-implementation-prerequisites.sh
@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+set -e
+JSON_MODE=false
+for arg in "$@"; do case "$arg" in --json) JSON_MODE=true ;; --help|-h) echo "Usage: $0 [--json]"; exit 0 ;; esac; done
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+source "$SCRIPT_DIR/common.sh"
+eval $(get_feature_paths)
+check_feature_branch "$CURRENT_BRANCH" || exit 1
+if [[ ! -d "$FEATURE_DIR" ]]; then echo "ERROR: Feature directory not found: $FEATURE_DIR"; echo "Run /specify first."; exit 1; fi
+if [[ ! -f "$IMPL_PLAN" ]]; then echo "ERROR: plan.md not found in $FEATURE_DIR"; echo "Run /plan first."; exit 1; fi
+if [[ ! -f "$TASKS" ]]; then echo "ERROR: tasks.md not found in $FEATURE_DIR"; echo "Run /tasks first."; exit 1; fi
+if $JSON_MODE; then
+  docs=(); [[ -f "$RESEARCH" ]] && docs+=("research.md"); [[ -f "$DATA_MODEL" ]] && docs+=("data-model.md"); ([[ -d "$CONTRACTS_DIR" ]] && [[ -n "$(ls -A "$CONTRACTS_DIR" 2>/dev/null)" ]]) && docs+=("contracts/"); [[ -f "$QUICKSTART" ]] && docs+=("quickstart.md"); [[ -f "$TASKS" ]] && docs+=("tasks.md");
+  json_docs=$(printf '"%s",' "${docs[@]}"); json_docs="[${json_docs%,}]"; printf '{"FEATURE_DIR":"%s","AVAILABLE_DOCS":%s}\n' "$FEATURE_DIR" "$json_docs"
+else
+  echo "FEATURE_DIR:$FEATURE_DIR"; echo "AVAILABLE_DOCS:"; check_file "$RESEARCH" "research.md"; check_file "$DATA_MODEL" "data-model.md"; check_dir "$CONTRACTS_DIR" "contracts/"; check_file "$QUICKSTART" "quickstart.md"; check_file "$TASKS" "tasks.md"; fi
\ No newline at end of file
diff --git a/.specify/templates/plan-template.md b/.specify/templates/plan-template.md
index 8429845..7ff4b3f 100644
--- a/.specify/templates/plan-template.md
+++ b/.specify/templates/plan-template.md
@@ -145,7 +145,7 @@ ios/ or android/
    - Quickstart test = story validation steps
 
 5. **Update agent file incrementally** (O(1) operation):
-   - Run `.specify/scripts/bash/update-agent-context.sh claude` for your AI assistant
+   - Run `.specify/scripts/bash/update-agent-context.sh gemini` for your AI assistant
    - If exists: Add only NEW tech from current plan
    - Preserve manual additions between markers
    - Update recent changes (keep last 3)
diff --git a/PRD.md b/PRD.md
new file mode 100644
index 0000000..005bf4f
--- /dev/null
+++ b/PRD.md
@@ -0,0 +1,105 @@
+### **Product Requirements Document: `enchun.tw` Website Migration to Astro (v2)**
+
+**1. Introduction**
+
+This document outlines the requirements for migrating the existing `enchun.tw` website to a new, modern web application built with the Astro framework and managed by Payload CMS. The primary goal is to create a faster, more secure, and more maintainable website, complete with a secure authentication system and a user-friendly editing experience for copywriters. The project will preserve all existing content, functionality, and SEO value while implementing a more logical site structure.
+
+**2. Goals & Objectives**
+
+*   **Performance:** Achieve Lighthouse scores of 95+ on public-facing pages.
+*   **Maintainability:** Provide a user-friendly, web-based interface for content editors via Payload CMS, protected by a robust authentication system.
+*   **Developer Experience:** Leverage Astro's modern features for a fast frontend build process and easier component management.
+*   **Security:** Implement role-based access control (RBAC) to secure the CMS and dashboard areas.
+*   **Future-Proofing:** Build on a modern, flexible stack that can easily integrate with other services and APIs.
+
+**3. Target Audience**
+
+*   **Public Users:** Potential and existing clients, industry peers.
+*   **Authenticated Users:**
+    *   **Content Editors/Copywriters:** Internal team members who will manage website content.
+    *   **Administrators:** Technical staff responsible for managing users and site settings.
+
+**4. Functional Requirements**
+
+**4.1. Redesigned Page Structure & Routing**
+
+The application will feature a clear separation between public and protected routes.
+
+*   **Public Routes:**
+    *   `/` (Homepage)
+    *   `/about`
+    *   `/contact`
+    *   `/solutions`
+    *   `/blog` (Blog listing page)
+    *   `/blog/[slug]` (Individual blog posts)
+    *   `/blog/category/[category-slug]` (Blog category pages)
+    *   `/portfolio` (Portfolio listing page)
+    *   `/portfolio/[slug]` (Individual portfolio projects)
+    *   `/teams`
+    *   `/marketing-class`
+
+*   **Protected Routes (Require Authentication):**
+    *   `/admin/login` (Login page)
+    *   `/admin/dashboard` (A general dashboard for authenticated users)
+    *   `/admin/cms` (The embedded Payload CMS admin interface)
+
+**4.2. Authentication & Authorization**
+
+*   **Authentication Provider:** The site will use **Auth.js (`astro-auth`)** to handle user authentication.
+*   **Login:** A dedicated login page will be available at `/admin/login`.
+*   **Access Control:** All routes under `/admin/*` will be protected. Unauthenticated users attempting to access these routes will be redirected to the login page.
+*   **Role-Based Access Control (RBAC):**
+    *   **Administrator (`admin`):** Full access to the Payload CMS, including content creation/editing, user management, and system settings.
+    *   **Editor (`editor`):** Can create, edit, and manage content (blog posts, portfolio items) but cannot access system settings or manage users.
+    *   The CMS and dashboard will restrict visibility and actions based on the logged-in user's role.
+
+**4.3. Key Features**
+
+*   **Content Management:** All public content will be managed via a self-hosted Payload CMS instance. The CMS admin panel will be accessible only to authenticated users at `/admin/cms`.
+*   **Contact Form:** The public `/contact` page will feature a functional contact form. Submissions will be handled securely by a Cloudflare Worker.
+*   **SEO:**
+    *   A dynamic `sitemap.xml` will be automatically generated.
+    *   Payload CMS will include dedicated SEO fields (meta title, description, Open Graph tags) for all pages and collections.
+    *   **Redirects:** A 301 redirect map will be implemented to permanently redirect all old URLs from `enchun-sitemap.md` to their new, redesigned equivalents to preserve SEO equity.
+
+**5. Non-Functional Requirements**
+
+*   **Styling:** The project will use **Tailwind CSS**.
+*   **Accessibility:** The site must adhere to WCAG 2.1 AA standards.
+*   **Deployment:** The Astro frontend will be deployed on **Cloudflare Pages** in SSR (Server-Side Rendering) mode to support the authentication layer. The Payload CMS backend and serverless functions will run on **Cloudflare Workers**.
+
+**6. Technology Stack**
+
+*   **Framework:** Astro (in SSR mode)
+*   **Authentication:** Auth.js (`astro-auth`)
+*   **UI Components:** Astro components
+*   **Styling:** Tailwind CSS
+*   **CMS:** Payload CMS
+*   **Deployment:** Cloudflare Pages & Cloudflare Workers
+
+**7. Migration Plan (High-Level)**
+
+1.  **Phase 1: Project Setup**
+    *   Initialize a new Astro project configured for SSR.
+    *   Set up Payload CMS for Cloudflare Workers.
+    *   Configure Tailwind CSS.
+2.  **Phase 2: Authentication & CMS Setup**
+    *   Integrate `astro-auth` and configure the login flow.
+    *   Define the collections and user roles (`admin`, `editor`) within Payload.
+3.  **Phase 3: Content Migration**
+    *   Write a script to import content from the CSV files into the Payload CMS via its API.
+4.  **Phase 4: Page & Template Implementation**
+    *   Build all public pages and templates, fetching data from the Payload API.
+    *   Build the protected `/admin` area, including the dashboard and the embedded CMS panel.
+5.  **Phase 5: Functionality & SEO**
+    *   Implement the contact form with its Cloudflare Worker backend.
+    *   Implement the 301 redirect map and all other SEO requirements.
+6.  **Phase 6: Testing & Deployment**
+    *   Thoroughly test all public pages, protected routes, user roles, and functionality.
+    *   Deploy the full stack to Cloudflare.
+    *   Configure DNS and go live.
+
+**8. Out of Scope**
+
+*   Frontend user accounts or public-facing login capabilities.
+*   A complete visual redesign. The project aims to migrate the existing design to the new framework.
\ No newline at end of file
diff --git a/specs/001-users-pukpuk-dev/contracts/contact.yaml b/specs/001-users-pukpuk-dev/contracts/contact.yaml
new file mode 100644
index 0000000..02ad472
--- /dev/null
+++ b/specs/001-users-pukpuk-dev/contracts/contact.yaml
@@ -0,0 +1,27 @@
+openapi: 3.0.0
+info:
+  title: Contact Form API
+  version: 1.0.0
+paths:
+  /contact:
+    post:
+      summary: Submit a contact form
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                name:
+                  type: string
+                email:
+                  type: string
+                  format: email
+                message:
+                  type: string
+      responses:
+        '200':
+          description: Form submission successful
+        '400':
+          description: Invalid request
diff --git a/specs/001-users-pukpuk-dev/contracts/login.yaml b/specs/001-users-pukpuk-dev/contracts/login.yaml
new file mode 100644
index 0000000..0301074
--- /dev/null
+++ b/specs/001-users-pukpuk-dev/contracts/login.yaml
@@ -0,0 +1,32 @@
+openapi: 3.0.0
+info:
+  title: Login API
+  version: 1.0.0
+paths:
+  /admin/login:
+    post:
+      summary: Authenticate a user
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                email:
+                  type: string
+                  format: email
+                password:
+                  type: string
+      responses:
+        '200':
+          description: Authentication successful
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  token:
+                    type: string
+        '401':
+          description: Authentication failed
diff --git a/specs/001-users-pukpuk-dev/data-model.md b/specs/001-users-pukpuk-dev/data-model.md
new file mode 100644
index 0000000..8fc0700
--- /dev/null
+++ b/specs/001-users-pukpuk-dev/data-model.md
@@ -0,0 +1,39 @@
+# Data Model
+
+This document defines the data structures for the project, based on the entities identified in the feature specification.
+
+## User
+Represents an authenticated user of the admin panel.
+
+- **email**: `string` (required, unique)
+- **password**: `string` (required, hashed)
+- **role**: `enum` (required, values: `admin`, `editor`)
+
+## Blog Post
+Represents a single article.
+
+- **title**: `string` (required)
+- **slug**: `string` (required, unique)
+- **content**: `richText` (required)
+- **author**: `relationship` to `User` (required)
+- **category**: `relationship` to `Category` (required)
+- **publication_date**: `date` (required)
+- **meta_title**: `string` (required)
+- **meta_description**: `string` (required)
+
+## Portfolio Item
+Represents a single project.
+
+- **title**: `string` (required)
+- **slug**: `string` (required, unique)
+- **description**: `richText` (required)
+- **project_images**: `array` of `media` (required)
+- **completion_date**: `date` (required)
+- **meta_title**: `string` (required)
+- **meta_description**: `string` (required)
+
+## Category
+Represents a blog post category.
+
+- **name**: `string` (required)
+- **slug**: `string` (required, unique)
diff --git a/specs/001-users-pukpuk-dev/plan.md b/specs/001-users-pukpuk-dev/plan.md
new file mode 100644
index 0000000..c552c3f
--- /dev/null
+++ b/specs/001-users-pukpuk-dev/plan.md
@@ -0,0 +1,212 @@
+
+# Implementation Plan: Website Migration to Astro with Payload CMS
+
+**Branch**: `001-users-pukpuk-dev` | **Date**: 2025-09-19 | **Spec**: [spec.md](spec.md)
+**Input**: Feature specification from `/Users/pukpuk/Dev/website-enchuntw-migr/specs/001-users-pukpuk-dev/spec.md`
+
+## Execution Flow (/plan command scope)
+```
+1. Load feature spec from Input path
+   → If not found: ERROR "No feature spec at {path}"
+2. Fill Technical Context (scan for NEEDS CLARIFICATION)
+   → Detect Project Type from context (web=frontend+backend, mobile=app+api)
+   → Set Structure Decision based on project type
+3. Fill the Constitution Check section based on the content of the constitution document.
+4. Evaluate Constitution Check section below
+   → If violations exist: Document in Complexity Tracking
+   → If no justification possible: ERROR "Simplify approach first"
+   → Update Progress Tracking: Initial Constitution Check
+5. Execute Phase 0 → research.md
+   → If NEEDS CLARIFICATION remain: ERROR "Resolve unknowns"
+6. Execute Phase 1 → contracts, data-model.md, quickstart.md, agent-specific template file (e.g., `CLAUDE.md` for Claude Code, `.github/copilot-instructions.md` for GitHub Copilot, `GEMINI.md` for Gemini CLI, `QWEN.md` for Qwen Code or `AGENTS.md` for opencode).
+7. Re-evaluate Constitution Check section
+   → If new violations: Refactor design, return to Phase 1
+   → Update Progress Tracking: Post-Design Constitution Check
+8. Plan Phase 2 → Describe task generation approach (DO NOT create tasks.md)
+9. STOP - Ready for /tasks command
+```
+
+**IMPORTANT**: The /plan command STOPS at step 7. Phases 2-4 are executed by other commands:
+- Phase 2: /tasks command creates tasks.md
+- Phase 3-4: Implementation execution (manual or via tools)
+
+## Summary
+This plan outlines the migration of the enchun.tw website to a modern stack using Astro for the frontend and Payload CMS for the backend. The primary goal is to create a fast, static website with a secure, role-based admin area for content management. The technical approach involves using Astro for static site generation, Payload CMS for headless content management, and better-auth for authentication. The project will be deployed on Cloudflare Pages.
+
+## Technical Context
+**Language/Version**: Astro (JavaScript/TypeScript)
+**Primary Dependencies**: Astro, Payload CMS, better-auth
+**Storage**: N/A (handled by Payload CMS)
+**Testing**: Vitest (unit), Playwright (e2e)
+**Target Platform**: Cloudflare Pages
+**Project Type**: web
+**Performance Goals**: Google Lighthouse score of 90+ for Performance, Accessibility, Best Practices, and SEO.
+**Constraints**: 3-month timeline, $10,000 budget.
+**Scale/Scope**: ~50 blog posts, ~20 portfolio items.
+
+## Constitution Check
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+No specific constitutional requirements found as the constitution file is a template.
+
+## Project Structure
+
+### Documentation (this feature)
+```
+specs/[###-feature]/
+├── plan.md              # This file (/plan command output)
+├── research.md          # Phase 0 output (/plan command)
+├── data-model.md        # Phase 1 output (/plan command)
+├── quickstart.md        # Phase 1 output (/plan command)
+├── contracts/           # Phase 1 output (/plan command)
+└── tasks.md             # Phase 2 output (/tasks command - NOT created by /plan)
+```
+
+### Source Code (repository root)
+```
+# Option 1: Single project (DEFAULT)
+src/
+├── models/
+├── services/
+├── cli/
+└── lib/
+
+tests/
+├── contract/
+├── integration/
+└── unit/
+
+# Option 2: Web application (when "frontend" + "backend" detected)
+backend/
+├── src/
+│   ├── models/
+│   ├── services/
+│   └── api/
+└── tests/
+
+frontend/
+├── src/
+│   ├── components/
+│   ├── pages/
+│   └── services/
+└── tests/
+
+# Option 3: Mobile + API (when "iOS/Android" detected)
+api/
+└── [same as backend above]
+
+ios/ or android/
+└── [platform-specific structure]
+```
+
+**Structure Decision**: Option 2: Web application
+
+## Phase 0: Outline & Research
+1. **Extract unknowns from Technical Context** above:
+   - For each NEEDS CLARIFICATION → research task
+   - For each dependency → best practices task
+   - For each integration → patterns task
+
+2. **Generate and dispatch research agents**:
+   ```
+   For each unknown in Technical Context:
+     Task: "Research {unknown} for {feature context}"
+   For each technology choice:
+     Task: "Find best practices for {tech} in {domain}"
+   ```
+
+3. **Consolidate findings** in `research.md` using format:
+   - Decision: [what was chosen]
+   - Rationale: [why chosen]
+   - Alternatives considered: [what else evaluated]
+
+**Output**: research.md with all NEEDS CLARIFICATION resolved
+
+## Phase 1: Design & Contracts
+*Prerequisites: research.md complete*
+
+1. **Extract entities from feature spec** → `data-model.md`:
+   - Entity name, fields, relationships
+   - Validation rules from requirements
+   - State transitions if applicable
+
+2. **Generate API contracts** from functional requirements:
+   - For each user action → endpoint
+   - Use standard REST/GraphQL patterns
+   - Output OpenAPI/GraphQL schema to `/contracts/`
+
+3. **Generate contract tests** from contracts:
+   - One test file per endpoint
+   - Assert request/response schemas
+   - Tests must fail (no implementation yet)
+
+4. **Extract test scenarios** from user stories:
+   - Each story → integration test scenario
+   - Quickstart test = story validation steps
+
+5. **Update agent file incrementally** (O(1) operation):
+   - Run `.specify/scripts/bash/update-agent-context.sh gemini` for your AI assistant
+   - If exists: Add only NEW tech from current plan
+   - Preserve manual additions between markers
+   - Update recent changes (keep last 3)
+   - Keep under 150 lines for token efficiency
+   - Output to repository root
+
+**Output**: data-model.md, /contracts/*, failing tests, quickstart.md, agent-specific file
+
+## Phase 2: Task Planning Approach
+*This section describes what the /tasks command will do - DO NOT execute during /plan*
+
+**Task Generation Strategy**:
+- Load `.specify/templates/tasks-template.md` as base
+- **Astro Setup**: Create tasks for initializing the Astro project, installing dependencies, and configuring the project.
+- **Payload CMS Collections**: Generate tasks for creating the `Users`, `Blog Posts`, `Portfolio Items`, and `Categories` collections in Payload CMS, based on `data-model.md`.
+- **Authentication**: Create tasks for implementing the login functionality using `better-auth`, including creating the login page and protecting the admin routes.
+- **Frontend Development**: Generate tasks for creating the Astro components for the header, footer, blog page, portfolio page, and contact form.
+- **Content Migration**: Create tasks for migrating the content from the old site to the new Payload CMS.
+- **Deployment**: Generate tasks for setting up the deployment pipeline to Cloudflare Pages.
+
+**Ordering Strategy**:
+- TDD order: Tests before implementation
+- Dependency order: Payload CMS setup before frontend development.
+- Mark [P] for parallel execution (independent files)
+
+**Estimated Output**: 30-40 numbered, ordered tasks in tasks.md
+
+**IMPORTANT**: This phase is executed by the /tasks command, NOT by /plan
+
+## Phase 3+: Future Implementation
+*These phases are beyond the scope of the /plan command*
+
+**Phase 3**: Task execution (/tasks command creates tasks.md)  
+**Phase 4**: Implementation (execute tasks.md following constitutional principles)  
+**Phase 5**: Validation (run tests, execute quickstart.md, performance validation)
+
+## Complexity Tracking
+*Fill ONLY if Constitution Check has violations that must be justified*
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
+| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |
+
+
+## Progress Tracking
+*This checklist is updated during execution flow*
+
+**Phase Status**:
+- [X] Phase 0: Research complete (/plan command)
+- [X] Phase 1: Design complete (/plan command)
+- [X] Phase 2: Task planning complete (/plan command - describe approach only)
+- [ ] Phase 3: Tasks generated (/tasks command)
+- [ ] Phase 4: Implementation complete
+- [ ] Phase 5: Validation passed
+
+**Gate Status**:
+- [X] Initial Constitution Check: PASS
+- [X] Post-Design Constitution Check: PASS
+- [X] All NEEDS CLARIFICATION resolved
+- [ ] Complexity deviations documented
+
+---
+*Based on Constitution v2.1.1 - See `/memory/constitution.md`*
diff --git a/specs/001-users-pukpuk-dev/quickstart.md b/specs/001-users-pukpuk-dev/quickstart.md
new file mode 100644
index 0000000..1c19390
--- /dev/null
+++ b/specs/001-users-pukpuk-dev/quickstart.md
@@ -0,0 +1,50 @@
+# Quickstart Guide
+
+This guide provides instructions for setting up the project and running the tests.
+
+## Prerequisites
+
+- Node.js (v18 or later)
+- pnpm
+
+## Setup
+
+1.  **Clone the repository**:
+    ```bash
+    git clone <repository-url>
+    cd <repository-name>
+    ```
+
+2.  **Install dependencies**:
+    ```bash
+    pnpm install
+    ```
+
+3.  **Set up environment variables**:
+    Create a `.env` file in the root of the project and add the following variables:
+    ```
+    PAYLOAD_CMS_URL=...
+    PAYLOAD_CMS_API_KEY=...
+    ```
+
+## Running the development server
+
+```bash
+pnpm dev
+```
+
+The application will be available at `http://localhost:4321`.
+
+## Running the tests
+
+### Unit tests
+
+```bash
+pnpm test:unit
+```
+
+### End-to-end tests
+
+```bash
+pnpm test:e2e
+```
diff --git a/specs/001-users-pukpuk-dev/research.md b/specs/001-users-pukpuk-dev/research.md
new file mode 100644
index 0000000..dd23f0f
--- /dev/null
+++ b/specs/001-users-pukpuk-dev/research.md
@@ -0,0 +1,37 @@
+# Phase 0: Research
+
+## Testing Strategy
+
+**Decision**: Use Vitest for unit testing Astro components and Playwright for end-to-end testing.
+
+**Rationale**: 
+- **Vitest**: It's a fast and modern test runner that's compatible with Vite, which Astro uses under the hood. It's easy to set up and has a similar API to Jest.
+- **Playwright**: It's a powerful end-to-end testing framework that allows testing across different browsers. It's great for simulating user interactions and verifying the complete functionality of the site.
+
+**Alternatives considered**:
+- **Jest**: A popular testing framework, but Vitest is more modern and better integrated with the Vite ecosystem.
+- **Cypress**: Another popular end-to-end testing framework, but Playwright has better cross-browser support.
+
+## Performance Goals
+
+**Decision**: Aim for a Google Lighthouse score of 90+ for Performance, Accessibility, Best Practices, and SEO.
+
+**Rationale**: This is a widely accepted benchmark for web performance and user experience. Achieving these scores will ensure a fast and accessible website.
+
+**Alternatives considered**: None, as this is a standard best practice.
+
+## Constraints
+
+**Decision**: The project should be completed within 3 months and stay within a budget of $10,000.
+
+**Rationale**: These constraints are based on the client's requirements.
+
+**Alternatives considered**: None.
+
+## Scale/Scope
+
+**Decision**: The initial scope is to migrate the existing content from the old site to the new Astro and Payload CMS setup. This includes ~50 blog posts and ~20 portfolio items.
+
+**Rationale**: This is based on the analysis of the existing sitemap and CMS structure.
+
+**Alternatives considered**: None.
diff --git a/specs/001-users-pukpuk-dev/spec.md b/specs/001-users-pukpuk-dev/spec.md
new file mode 100644
index 0000000..32c4b81
--- /dev/null
+++ b/specs/001-users-pukpuk-dev/spec.md
@@ -0,0 +1,68 @@
+# Feature Specification: Website Migration to Astro with Payload CMS
+
+**Feature Branch**: `001-users-pukpuk-dev`
+**Created**: 2025-09-18
+**Status**: Draft
+**Input**: User description: "From PRD.md: Migrate enchun.tw to Astro, using Payload CMS for content. The site needs a secure admin area with role-based access for editors and admins. Deploy on Cloudflare."
+
+---
+
+## User Scenarios & Testing *(mandatory)*
+
+### Primary User Story
+As a content editor, I want to log in to a secure admin area to create, edit, and manage blog posts and portfolio items through a user-friendly interface, so that I can keep the website content up-to-date without needing technical assistance.
+
+As an administrator, I want to manage all site content and also control user access, so that I can ensure the site is secure and only authorized personnel can make changes.
+
+As a public visitor, I want to browse a fast, well-structured, and informative website to learn about the company's services.
+
+### Acceptance Scenarios
+1.  **Given** an unauthenticated user, **When** they navigate to `/admin/cms`, **Then** they are redirected to the `/admin/login` page.
+2.  **Given** a user with an `editor` role is logged in, **When** they navigate to `/admin/cms`, **Then** they can access the content editing interface for blogs and portfolios but cannot see user management settings.
+3.  **Given** a user with an `admin` role is logged in, **When** they navigate to `/admin/cms`, **Then** they can access all content editing and user management features.
+4.  **Given** a public visitor, **When** they navigate to a URL from the old sitemap (e.g., `/xing-xiao-fang-da-jing/storytelling`), **Then** they are permanently redirected (301) to the new URL (`/blog/storytelling`).
+
+### Edge Cases
+- What happens when a logged-in user's session expires? (System should redirect to the login page on the next action).
+- How does the system handle a user trying to access an admin URL they don't have the role for? (System should show a "Permission Denied" or 403 error page).
+- What happens if the Payload CMS API is unavailable during the static site build? (The build process should fail with a clear error message).
+
+---
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+- **FR-001**: The system MUST provide a secure login page at `/admin/login`.
+- **FR-002**: The system MUST protect all routes under the `/admin/` path, requiring user authentication.
+- **FR-003**: The system MUST define at least two user roles: `admin` and `editor`.
+- **FR-004**: `admin` users MUST have full access to all CMS collections and settings, including user management.
+- **FR-005**: `editor` users MUST have access to content-related collections (e.g., Posts, Portfolios, Categories) but MUST NOT have access to system settings or user management.
+- **FR-006**: The system MUST fetch all public content from a Payload CMS instance at build time to generate a static frontend.
+- **FR-007**: The system MUST implement a 301 redirect map for all URLs listed in the original sitemap to their new, redesigned equivalents.
+- **FR-008**: The system MUST provide a functional contact form on the `/contact` page.
+- **FR-009**: The system MUST generate a `sitemap.xml` file based on the content stored in the CMS.
+- **FR-010**: All content types in the CMS MUST include dedicated fields for SEO metadata (meta title, meta description).
+
+### Key Entities *(include if feature involves data)*
+- **User**: Represents an authenticated user of the admin panel. Attributes: email, password hash, role (`admin` or `editor`).
+- **Blog Post**: Represents a single article. Attributes: title, slug, content, author, category, publication date, SEO metadata.
+- **Portfolio Item**: Represents a single project. Attributes: title, slug, description, project images, completion date, SEO metadata.
+- **Category**: Represents a blog post category. Attributes: name, slug.
+
+---
+
+## Review & Acceptance Checklist
+*GATE: Automated checks run during main() execution*
+
+### Content Quality
+- [X] No implementation details (languages, frameworks, APIs)
+- [X] Focused on user value and business needs
+- [X] Written for non-technical stakeholders
+- [X] All mandatory sections completed
+
+### Requirement Completeness
+- [ ] No [NEEDS CLARIFICATION] markers remain
+- [X] Requirements are testable and unambiguous
+- [X] Success criteria are measurable
+- [X] Scope is clearly bounded
+- [X] Dependencies and assumptions identified