Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions CLAUDE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# Claude Code Task Management Guide

## Documentation Available

📚 **Project Documentation**: Check the documentation files in this directory for project-specific setup instructions and guides.
**Project Tasks**: Check the tasks directory in documentation/tasks for the list of tasks to be completed. Use the CLI commands below to interact with them.

## MANDATORY Task Management Workflow

🚨 **YOU MUST FOLLOW THIS EXACT WORKFLOW - NO EXCEPTIONS** 🚨

### **STEP 1: DISCOVER TASKS (MANDATORY)**
You MUST start by running this command to see all available tasks:
```bash
task-manager list-tasks
```

### **STEP 2: START EACH TASK (MANDATORY)**
Before working on any task, you MUST mark it as started:
```bash
task-manager start-task <task_id>
```

### **STEP 3: COMPLETE OR CANCEL EACH TASK (MANDATORY)**
After finishing implementation, you MUST mark the task as completed, or cancel if you cannot complete it:
```bash
task-manager complete-task <task_id> "Brief description of what was implemented"
# or
task-manager cancel-task <task_id> "Reason for cancellation"
```

## Task Files Location

📁 **Task Data**: Your tasks are organized in the `documentation/tasks/` directory:
- Task JSON files contain complete task information
- Use ONLY the `task-manager` commands listed above
- Follow the mandatory workflow sequence for each task

## MANDATORY Task Workflow Sequence

🔄 **For EACH individual task, you MUST follow this sequence:**

1. 📋 **DISCOVER**: `task-manager list-tasks` (first time only)
2. 🚀 **START**: `task-manager start-task <task_id>` (mark as in progress)
3. 💻 **IMPLEMENT**: Do the actual coding/implementation work
4. ✅ **COMPLETE**: `task-manager complete-task <task_id> "What was done"` (or cancel with `task-manager cancel-task <task_id> "Reason"`)
5. 🔁 **REPEAT**: Go to next task (start from step 2)

## Task Status Options

- `pending` - Ready to work on
- `in_progress` - Currently being worked on
- `completed` - Successfully finished
- `blocked` - Cannot proceed (waiting for dependencies)
- `cancelled` - No longer needed

## CRITICAL WORKFLOW RULES

❌ **NEVER skip** the `task-manager start-task` command
❌ **NEVER skip** the `task-manager complete-task` command (use `task-manager cancel-task` if a task is not planned, not required, or you must stop it)
❌ **NEVER work on multiple tasks simultaneously**
✅ **ALWAYS complete one task fully before starting the next**
✅ **ALWAYS provide completion details in the complete command**
✅ **ALWAYS follow the exact 3-step sequence: list → start → complete (or cancel if not required)**
14 changes: 7 additions & 7 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# CodeGuide Starter Kit
# Codeguide Starter Fullstack

A modern web application starter template built with Next.js 15, featuring authentication, database integration, and dark mode support.

Expand All @@ -25,7 +25,7 @@ Before you begin, ensure you have the following:
1. **Clone the repository**
```bash
git clone <repository-url>
cd codeguide-starter
cd codeguide-starter-fullstack
```

2. **Install dependencies**
Expand Down Expand Up @@ -116,7 +116,7 @@ NEXT_PUBLIC_BETTER_AUTH_URL=http://localhost:3000
## Project Structure

```
codeguide-starter/
codeguide-starter-fullstack/
├── app/ # Next.js app router pages
│ ├── globals.css # Global styles with dark mode
│ ├── layout.tsx # Root layout with providers
Expand Down Expand Up @@ -230,7 +230,7 @@ npm run db:dev
1. **Clone and setup on your server:**
```bash
git clone <your-repo>
cd codeguide-starter
cd codeguide-starter-fullstack
cp .env.example .env
```

Expand All @@ -256,10 +256,10 @@ npm run db:dev
1. **Build and push image:**
```bash
# Build the image
docker build -t your-registry/codeguide-starter:latest .
docker build -t your-registry/codeguide-starter-fullstack:latest .

# Push to registry
docker push your-registry/codeguide-starter:latest
docker push your-registry/codeguide-starter-fullstack:latest
```

2. **Deploy using your cloud provider's container service**
Expand Down Expand Up @@ -326,4 +326,4 @@ This starter is optimized for AI coding agents:
## Contributing

Contributions are welcome! Please feel free to submit a Pull Request.
# codeguide-starter
# codeguide-starter-fullstack
2 changes: 1 addition & 1 deletion app/layout.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ const parkinsans = Parkinsans({
});

export const metadata: Metadata = {
title: "CodeGuide Starter Kit",
title: "Codeguide Starter Fullstack",
description:
"A modern Next.js starter with TypeScript, TailwindCSS, shadcn/ui, Better Auth, and Drizzle ORM",
};
Expand Down
2 changes: 1 addition & 1 deletion app/page.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ export default function Home() {
className="rounded-xl sm:w-[60px] sm:h-[60px]"
/>
<h1 className="text-3xl sm:text-4xl lg:text-5xl font-bold bg-gradient-to-r from-blue-600 via-blue-500 to-blue-400 bg-clip-text text-transparent font-parkinsans">
CodeGuide Starter
Codeguide Starter Fullstack
</h1>
</div>
<p className="text-lg sm:text-xl text-muted-foreground max-w-2xl mx-auto px-4 mb-8">
Expand Down
14 changes: 7 additions & 7 deletions docker-compose.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ services:
# PostgreSQL Database
postgres:
image: postgres:16-alpine
container_name: codeguide-postgres
container_name: codeguide-starter-fullstack-postgres
restart: unless-stopped
environment:
POSTGRES_DB: ${POSTGRES_DB}
Expand All @@ -16,14 +16,14 @@ services:
- postgres_data:/var/lib/postgresql/data
- ./docker/postgres/init.sql:/docker-entrypoint-initdb.d/init.sql
networks:
- codeguide-network
- codeguide-starter-fullstack-network

# Next.js Application
app:
build:
context: .
dockerfile: Dockerfile
container_name: codeguide-app
container_name: codeguide-starter-fullstack-app
restart: unless-stopped
environment:
- NODE_ENV=production
Expand All @@ -35,12 +35,12 @@ services:
depends_on:
- postgres
networks:
- codeguide-network
- codeguide-starter-fullstack-network

# Development database only
postgres-dev:
image: postgres:16-alpine
container_name: codeguide-postgres-dev
container_name: codeguide-starter-fullstack-postgres-dev
restart: unless-stopped
environment:
POSTGRES_DB: ${POSTGRES_DB:-postgres}
Expand All @@ -51,7 +51,7 @@ services:
volumes:
- postgres_dev_data:/var/lib/postgresql/data
networks:
- codeguide-network
- codeguide-starter-fullstack-network
profiles:
- dev

Expand All @@ -62,5 +62,5 @@ volumes:
driver: local

networks:
codeguide-network:
codeguide-starter-fullstack-network:
driver: bridge
41 changes: 41 additions & 0 deletions documentation/app_flow_document.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# App Flow Document

## Onboarding and Sign-In/Sign-Up

When a new visitor arrives at the application’s root URL, they land on a welcome page that offers clear buttons or links to either create an account or sign in. Clicking on the “Sign Up” link takes the visitor to a registration page where they enter their email address and choose a password. Once they submit the form, the application sends a POST request to the authentication API endpoint, which handles password hashing and user creation. If registration succeeds, the new user is automatically signed in and redirected to the dashboard. If there are validation errors, such as a password that is too short or an email already in use, the form reappears with inline messages explaining what must be corrected.

For returning users, clicking the “Sign In” link from the welcome page or from a persistent header link opens the login form. They input their email and password, and upon submission the app sends a request to the same authentication API with login credentials. A successful login leads directly to the dashboard. If the credentials are invalid, the page reloads with a clear error message prompting the user to try again.

Signing out is available from within the dashboard via a logout button in the main navigation or header. When clicked, the application clears the user’s session or token, and then navigates back to the welcome page. Currently, there is no built-in password recovery or reset flow in this version, so users who forget their password are prompted to contact support for assistance.

## Main Dashboard or Home Page

After authentication, the user lands on the dashboard, which serves as the main home page. The dashboard is wrapped in a layout that displays a header bar and a sidebar navigation tailored for logged-in users. The header bar typically shows the application’s logo on the left and a Logout link on the right. The sidebar sits on the left side of the screen and may contain links back to the dashboard’s main panel or to future features.

The central area of the dashboard page displays data pulled from a static JSON file. This content might appear in cards or tables to give users a quick overview of information. All styling for this section comes from a dedicated theme stylesheet to keep the look consistent. Users can click items or links here, but those actions are placeholders for future dynamic data features.

From this dashboard view, users may revisit the welcome page or any other main area by selecting navigation items in the sidebar or header. The layout ensures that the logout link remains accessible at all times, and that the user cannot leave the authenticated area without signing out manually or having their session expire.

## Detailed Feature Flows and Page Transitions

When a visitor lands on the root page, JavaScript on the client reads the route and displays either the welcome interface or automatically redirects them to the dashboard if a valid session exists. For new user registration, the user clicks the Sign Up link and is taken to the sign-up page. The sign-up form collects email and password fields, and on submission it triggers a client-side POST to the API route. Once the API responds with success, the client redirects the user to the dashboard page.

Returning users choose the Sign In link and arrive at the sign-in page, which offers the same fields as the sign-up page but is wired to authenticate rather than create a new account. On form submit, the user sees a loading indication until the API confirms valid credentials. If successful, the client pushes the dashboard route and loads the dashboard layout and content.

All authenticated pages reside under the `/dashboard` path. When the user attempts to navigate directly to `/dashboard` without a valid session, server-side redirection logic intercepts the request and sends the user back to the sign-in page. This ensures that protected content never shows to unauthorized visitors.

Signing out happens entirely on the client side by calling an API or clearing a cookie, then navigating back to the welcome page. The client code listens for the logout action, invalidates the current session, and then reloads or reroutes the application state to the landing interface.

## Settings and Account Management

At present, users cannot change profile information, update their email, or configure notifications from within the interface. The only account management available is the ability to sign out from any dashboard view. In future iterations, a dedicated settings page could be added to let users update personal details or adjust preferences, but in this version, those capabilities are not provided. After signing out, users always return to the welcome page and must sign in again to regain access to the dashboard.

## Error States and Alternate Paths

If a user types an incorrect email or password on the sign-in page, the authentication API responds with an error status and a message. The form then displays an inline alert near the input fields explaining the issue, such as “Invalid email or password,” allowing the user to correct and resubmit. During sign up, validation errors like a missing field or weak password appear immediately under the relevant input.

Network failures trigger a generic error notification at the top of the form, informing the user that the request could not be completed and advising them to check their connection. If the dashboard content fails to load due to a broken or missing static data file, a fallback message appears in the main panel stating that data could not be loaded and suggesting a page refresh. Trying to access a protected route without a session sends the user to the sign-in page automatically, making it clear that authentication is required.

## Conclusion and Overall App Journey

A typical user journey starts with visiting the application’s root URL, signing up with an email and password, then being welcomed in the dashboard area that displays sample data. Returning users go directly through the sign-in page to the dashboard. Throughout each step, clear messages guide the user in case of errors or invalid input. The layout remains consistent, with a header and navigation ensuring that users always know where they are and can sign out at any time. This flow lays the foundation for adding dynamic data, user profile management, and richer features in future releases.
14 changes: 14 additions & 0 deletions documentation/app_flowchart.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
flowchart TD
Start[Landing Page]
SignUpPage[Sign Up Page]
SignInPage[Sign In Page]
AuthAPI[Authentication API Endpoint]
DashboardPage[Dashboard Page]
Start -->|Select Sign Up| SignUpPage
Start -->|Select Sign In| SignInPage
SignUpPage -->|Submit Credentials| AuthAPI
SignInPage -->|Submit Credentials| AuthAPI
AuthAPI -->|Success| DashboardPage
AuthAPI -->|Error| SignUpPage
AuthAPI -->|Error| SignInPage
DashboardPage -->|Click Logout| Start
Loading