chore: keep project docs private

This commit is contained in:
null 2026-05-12 01:09:21 -05:00
parent bd17e964b3
commit 8352558240
9 changed files with 9 additions and 1395 deletions

10
.gitignore vendored
View File

@ -1,4 +1,12 @@
# Project docs managed in repo unless explicitly excluded elsewhere # Private project/agent docs — never commit
DEVELOPMENT_LOG.md
PROJECT.md
STRUCTURE.md
FUTURE.md
HISTORY.md
BUILD_SUMMARY.md
SCRIPTS.md
OVERHAUL_PLAN.md
# Dependencies # Dependencies
node_modules/ node_modules/

View File

@ -1,125 +0,0 @@
# Queue North Website — Build Summary
## Completed Tasks
### Phase 1: Foundation
- ✅ Vite + React + Tailwind setup
- ✅ React Router with all required routes
- ✅ Express backend with /api/health, /api/leads, /api/support
- ✅ SQLite database with leads and support_requests tables
- ✅ TypeScript type definitions via @types packages
### Phase 2: UI Components
- ✅ Layout components: Header, Footer, MobileNav
- ✅ shadcn/ui-style primitives: Button, Card, Input, Textarea, Select, Badge, Sheet
- ✅ TanStack Query provider for server state
- ✅ Sonner for toast notifications
- ✅ Lucide React for icons
### Phase 3: Pages
- ✅ Home page with hero, services preview, industries, CTAs
- ✅ About page
- ✅ Services page and individual service detail pages
- ✅ Industries page and individual industry detail pages
- ✅ 8x8 partner page
- ✅ Contact page with form submission to /api/leads
- ✅ Support page with form submission to /api/support
### Data Files
- ✅ Services data (7 services with full descriptions)
- ✅ Industries data (4 industries with pain points/solutions)
### Scripts
- ✅ npm run dev (frontend + backend concurrently)
- ✅ npm run build (production build)
- ✅ npm run preview
- ✅ npm run server
## Test Results
```
$ npm run build
✓ built in 1.10s
dist/index.html 0.99 kB
dist/assets/index-CsZTyVVr.css 20.07 kB
dist/assets/index-G07G4G_D.js 333.59 kB
```
```
$ npm run server
Server running on http://localhost:3001
Health check: http://localhost:3001/api/health
{"status":"ok","timestamp":"2026-05-12T05:48:42.213Z"}
```
## Next Steps (for Scarlett)
1. Run `npm run dev` to start both frontend and backend servers
2. Test the application in browser at http://localhost:5173
3. Verify all routes work correctly
4. Test contact form submission
5. Test support form submission
6. Check mobile responsiveness
7. Run `npm run build` to verify production build
## Known Issues / Limitations
- Sheet component doesn't use TypeScript generics (simplified for build)
- Image assets need to be updated from actual Queue North branding
- The database creates in `db/` directory which should be .gitignored
- Consider adding rate limiting for API endpoints
## Files Created/Modified
### New Files:
- `server/index.js` - Express backend
- `server/db/schema.sql` - SQLite schema (created on first run)
- `src/router.jsx` - React Router configuration
- `src/lib/api.js` - API helper with TanStack Query
- `src/lib/queryClient.js` - QueryClient configuration
- `src/data/services.js` - Services data
- `src/data/industries.js` - Industries data
- All component files in `src/components/`
- All page files in `src/pages/`
### Modified Files:
- `package.json` - Added dependencies (sonner, @radix-ui/react-dialog, lucide-react)
- `vite.config.js` - Added path alias for @/ imports
- `index.html` - Updated to use proper logo path
- `src/App.jsx` - Added MobileNav component
- `src/App.css` - Updated with proper Tailwind imports
- `tailwind.config.js` - Already had Scarlett's color palette
- `README.md` - Already had overhaul plan context
## Database Schema
```sql
CREATE TABLE IF NOT EXISTS leads (
id INTEGER PRIMARY KEY AUTOINCREMENT,
company TEXT NOT NULL,
name TEXT NOT NULL,
email TEXT NOT NULL,
phone TEXT,
zip TEXT,
message TEXT,
service_interest TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
)
CREATE TABLE IF NOT EXISTS support_requests (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
company TEXT NOT NULL,
email TEXT NOT NULL,
phone TEXT,
issue TEXT NOT NULL,
priority TEXT DEFAULT 'medium',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
)
```
---
Built with 🔒 Security in mind
Data integrity maintained
API contracts documented

View File

@ -1,45 +0,0 @@
# Queue-North-Website — Development Log
## v0.1.1 — Phase 1 Agent-Pass Checkpoint — 2026-05-12
**Ripley** — Version correction and push rule alignment
- Corrected Phase 1 version from `0.1.0` to `0.1.1` after user clarified that each completed agent pass/checkpoint should be uploaded to `dev` and reflected as a patch increment.
- Updated package/version docs to make patch increments map to completed agent passes within the active phase.
- Re-ran build and backend health check before committing/pushing.
## v0.1.0 — Phase 1 Foundation — 2026-05-12
**Scarlett** — Design brief and UI polish
- Added the design implementation brief to `OVERHAUL_PLAN.md`.
- Established light-first business palette and layout rules.
- Completed focused UI/accessibility polish after Neo scaffold.
- Added Georgia numeric font token guidance and applied numeric styling to visible trust metric content.
- Improved Sheet/Header accessibility and standardized selected page containers/spacing.
- Confirmed old `styles.css` was used only as legacy context, not ported into the new design.
**Neo** — Phase 1 implementation
- Built Vite + React + Tailwind foundation.
- Added React Router route structure.
- Added Express backend and better-sqlite3 database integration.
- Added contact/support form API wiring.
- Set package version to `0.1.0` for Phase 1.
**Bishop** — Verification
- Verified `package.json` version matches Phase 1 (`0.1.0`).
- Verified frontend build with `npm run build`.
- Verified backend health endpoint responds OK.
- Verified required routes and API paths are configured.
- Confirmed `.gitignore` excludes `node_modules/`, `dist/`, and SQLite runtime database files.
- Approved Phase 1 for Ripley commit/push to `dev`.
**Ripley** — Coordination and final gate
- Verified repository remote and pushed README setup commit.
- Documented phase-based versioning in PROJECT.md, OVERHAUL_PLAN.md, and STRUCTURE.md.
- Documented the phase completion rule: after every verified phase, Ripley commits and pushes to `dev`.
- Running final build/health checks before committing Phase 1.
## v0.0.1 — 2026-05-11
**Ripley** — Project initialized
- Created project directory at `/home/kaspa/.openclaw/Projects/Queue-North-Website/`.
- Set up initial PROJECT.md, STRUCTURE.md, FUTURE.md, HISTORY.md, DEVELOPMENT_LOG.md.

View File

@ -1,8 +0,0 @@
# Queue-North-Website — Planning
## Next Items
*Awaiting project requirements from _null.*
---
*Add items here as they are defined. Priority levels: CRITICAL, HIGH, MEDIUM, LOW*

View File

@ -1,41 +0,0 @@
# Queue-North-Website — Changelog
## v0.1.1 — Phase 1 Agent-Pass Checkpoint — 2026-05-12
### Changed
- Corrected Phase 1 version to reflect completed agent-pass checkpoint semantics.
- Documented that every completed agent pass/checkpoint within a phase increments the patch version.
- Confirmed Phase 1 verified output is pushed to `dev` at `0.1.1`.
### Verified
- `npm run build` passes.
- Backend health endpoint responds successfully at `/api/health`.
## v0.1.0 — Phase 1 Foundation — 2026-05-12
### Added
- Rebuilt project foundation on Vite + React SPA with React Router.
- Added Tailwind CSS with Queue North light-first business palette.
- Added shadcn/ui-style local primitives for buttons, cards, inputs, textarea, select, badge, sheet, and dialog usage.
- Added Sonner toast support and TanStack Query provider/API helper.
- Added Express backend with `/api/health`, `/api/leads`, and `/api/support`.
- Added better-sqlite3 storage for `leads` and `support_requests`.
- Added all planned frontend routes for home, about, services, service details, industries, industry details, 8x8, contact, and support.
- Added Phase 1 documentation, build summary, script reference, and phase-based versioning rules.
### Changed
- Replaced the static HTML/CSS/JS entry with the Vite React entry.
- Updated README to point to `OVERHAUL_PLAN.md` as the design source of truth.
- Standardized versioning so Phase 1 uses `0.1.x`, Phase 2 uses `0.2.x`, and later phases follow the same pattern.
- Added Bishop verification rules and the requirement that Ripley pushes to `dev` after each verified phase.
### Verified
- `npm run build` passes.
- Backend health endpoint responds successfully at `/api/health`.
- Required routes are configured.
- Contact and support API paths exist and write through SQLite.
## v0.0.1 — Project Initialization — 2026-05-11
### Added
- Project initialized with PROJECT.md, STRUCTURE.md, FUTURE.md, HISTORY.md, DEVELOPMENT_LOG.md.

View File

@ -1,993 +0,0 @@
# Queue North Website — 2026 Overhaul Plan
## TL;DR
Rebuild the current static HTML/CSS/JS website into a modern full-stack app using:
- **Vite** — build tool, not Next.js
- **React** — SPA with client-side routing via React Router
- **Tailwind CSS** — utility-first styling
- **shadcn/ui** — component primitives
- **Sonner** — toast notifications
- **TanStack Query** — server state management
- **Express** — backend API
- **better-sqlite3** — local SQLite database
The current website has good business content, but the structure and visual design feel dated. The rebuild should make Queue North Technologies feel like a modern, trustworthy, premium communications and infrastructure partner.
---
## Current Site Assessment
The current project is a static site with:
- `index.html` — all pages live in one large file
- `styles.css` — large hand-written stylesheet with many page-specific overrides
- `main.js` — manual hash-based routing and interactions
- Inline Zoho webform scripts
- Static assets in `assets/`
### Current Problems
1. **Single giant HTML file**
- All pages live inside `index.html`.
- Routing is manually handled through hash-based JavaScript.
- The structure is hard to maintain and scale.
2. **CSS is doing too much**
- `styles.css` is very large.
- Many page-specific rules and overrides exist.
- Layout feels patched together instead of systemized.
3. **Old visual language**
- Current colors lean heavily on dark teal and beige.
- Header/logo behavior feels awkward and dated.
- Repeated cards and sections lack a strong modern design system.
- The site communicates the right business, but not with enough polish.
4. **Fragile contact form flow**
- Inline Zoho scripts.
- Hidden iframe submission.
- Difficult to validate, style, and control in a modern app.
5. **No real application architecture**
- No component system.
- No API layer.
- No database.
- No modern routing.
- No server-state management.
---
## Target Architecture
## Frontend Stack
Use:
- **Vite**
- **React**
- **React Router**
- **Tailwind CSS**
- **shadcn/ui**
- **Sonner**
- **TanStack Query**
### Suggested Frontend Structure
```txt
client/
src/
app/
App.jsx
router.jsx
components/
layout/
Header.jsx
Footer.jsx
MobileNav.jsx
sections/
Hero.jsx
TrustBar.jsx
ServicesGrid.jsx
IndustriesGrid.jsx
PartnerSection.jsx
ContactCTA.jsx
ui/
shadcn components
pages/
Home.jsx
About.jsx
Services.jsx
ServiceDetail.jsx
Industries.jsx
IndustryDetail.jsx
EightXEight.jsx
Contact.jsx
Support.jsx
lib/
api.js
queryClient.js
data/
services.js
industries.js
```
---
## Backend Stack
Use:
- **Express**
- **better-sqlite3**
### Suggested Backend Structure
```txt
server/
index.js
db/
connection.js
schema.sql
routes/
leads.js
support.js
health.js
services/
leadService.js
supportService.js
```
### Initial API Routes
```txt
GET /api/health
POST /api/leads
POST /api/support
GET /api/services
GET /api/industries
```
---
## Database Plan
Use SQLite through `better-sqlite3`.
### Initial Tables
```txt
leads
- id
- company
- name
- email
- phone
- zip
- message
- service_interest
- created_at
support_requests
- id
- name
- company
- email
- phone
- issue
- priority
- created_at
```
### Zoho Integration
Zoho should not drive the frontend anymore.
Recommended path:
1. Frontend submits to Express.
2. Express validates request.
3. Express stores submission in SQLite.
4. Optional later: backend forwards lead data to Zoho.
This keeps the website clean, testable, and controllable.
---
## New Visual Direction
## Brand Feel
Target vibe:
**Bright enterprise communications partner. Clean, trustworthy, modern, approachable, and premium.**
The site should feel less like a local IT website from the early 2000s and more like a serious communications, contact center, and infrastructure partner for modern businesses.
Because this is a business services website, the visual direction should be **light-first**, not fully dark/cyber. A mostly dark interface can look sleek, but it may also feel too niche, too technical, or too startup/gaming-adjacent for SMB and enterprise buyers. The better direction is a bright, polished base with strong navy sections and crisp blue/cyan accents.
## Recommended Color Scheme
### Primary Light-First Palette
```txt
Background: #F8FAFC
Section Alt: #EEF6FB
Card: #FFFFFF
Border: #D8E3EA
Text: #0F172A
Muted: #475569
Soft Text: #64748B
Primary Navy: #0B2A3C
Deep Navy: #071A2A
Trust Blue: #0EA5E9
Accent Cyan: #22D3EE
```
### Optional Warm Accent
```txt
Signal Gold: #F59E0B
```
Use gold sparingly for badges, stats, certification highlights, or key trust moments.
### Dark Usage Guidance
Use dark navy intentionally, not everywhere:
- Header or top navigation
- Hero section
- Footer
- CTA bands
- Certification/trust moments
Keep most body sections bright and readable:
- White cards
- Light blue-gray section backgrounds
- Dark readable text
- Blue/cyan action accents
This gives the site a modern 2026 look without making it feel like a cybersecurity, crypto, or gaming landing page.
---
## Layout Direction
This section is the primary design brief for Scarlett.
The layout should feel like a modern B2B technology services website: bright, structured, confident, and conversion-focused. Avoid the early-2000s pattern of giant logos, crowded nav, heavy gradients everywhere, oversized generic images, and repeated boxed sections without rhythm.
### Global Layout Principles
- Use a **light-first page body** with strategic dark navy moments.
- Use a consistent max-width container: approximately `1200px` to `1280px`.
- Use generous vertical spacing:
- Mobile sections: `64px` to `80px`
- Desktop sections: `96px` to `128px`
- Use a clear rhythm:
- Dark hero
- Light trust section
- White/soft-blue service sections
- Dark CTA band
- Light detail sections
- Dark footer
- Keep the site visually calm. Do not use too many competing gradients, glows, borders, and shadows at once.
- Cards should feel premium and clean, not like old Bootstrap panels.
- Prefer fewer stronger sections over many cramped sections.
- Every page should have one obvious primary action: usually `Request Consultation` or `Contact Us`.
### Header / Navigation Layout
Desktop header:
- Sticky top header.
- Dark navy or white header is acceptable, but it must be compact and polished.
- Logo should be normal-sized and aligned, not oversized or bleeding into content.
- Navigation should be single-line and calm:
```txt
Home
Services
Industries
8x8
About
Contact
Support
```
- Primary CTA button on the right:
- `Request Consultation`
- Use shadcn/ui `NavigationMenu` if dropdowns are retained.
- Avoid wrapping nav links.
- Avoid huge dropdown panels unless they add real clarity.
Mobile header:
- Use shadcn/ui `Sheet` for navigation.
- Menu should slide in cleanly.
- Primary routes appear first.
- Service and industry subroutes can appear under simple section labels.
- CTA button should be visible in the sheet.
### Home Page Layout
Recommended home page structure:
1. **Hero**
- Use a dark navy hero section with bright text.
- Large modern headline.
- Suggested headline:
`Modern Communications Infrastructure Without the Vendor Noise`
- Subheading focused on UCaaS, Contact Center, networking, deployment, and managed lifecycle support.
- Two CTAs:
- Primary: `Request Consultation`
- Secondary: `Explore Services`
- Right side visual:
- Use a refined communications/network image, abstract interface panel, or polished existing asset.
- Do not use a raw stock-image block that feels pasted in.
- Trust chips below copy:
- `8x8 Certified Partner`
- `Veteran Owned`
- `25+ Years Experience`
- `SMB to Enterprise`
2. **Trust / Certification Bar**
- Light section directly below hero.
- Include 8x8 partner logo or certification language.
- Purpose: quickly establish credibility before services.
- Keep it compact and horizontal on desktop, stacked on mobile.
3. **Services Preview**
- Bright section with white cards.
- 6-7 concise service cards.
- Each card should include:
- Icon or small visual marker
- Service name
- One-sentence value statement
- Subtle `Learn more` affordance
- Avoid large image tiles unless imagery is carefully cropped and consistent.
4. **Why Queue North**
- Three-pillar layout:
- `Architecture`
- `Deployment`
- `Lifecycle Support`
- This section should explain how Queue North works, not just what it sells.
- Recommended style: alternating light background with strong typography and small supporting cards.
5. **Industries**
- Healthcare
- Retail
- Manufacturing
- Education & Finance
- These should feel like solution pathways.
- Do not present them as generic stock categories.
- Each industry card should connect pain point → Queue North solution.
6. **Final CTA**
- Dark navy CTA band near bottom of page.
- Suggested copy:
`Tell us what you're trying to fix. We'll help map the path.`
- CTA button:
`Request Consultation`
### Inner Page Layouts
Every inner page should use a consistent pattern:
1. **Page Hero**
- Short headline.
- One paragraph explaining the page value.
- Optional badge, e.g. `Service`, `Industry`, or `8x8 Partner`.
2. **Main Content Section**
- Use a two-column layout on desktop when useful:
- Left: core explanation
- Right: card with key benefits, use cases, or CTA
- Stack cleanly on mobile.
3. **Supporting Cards**
- Use 3-card or 4-card grids for benefits, capabilities, or outcomes.
- Keep card heights balanced.
4. **CTA Footer Band**
- Each major page should end with a CTA leading to contact.
### Services Page Layout
The `/services` page should act as a service hub.
- Top page hero explains the whole service model.
- Follow with a card grid for all services.
- Each service card links to its detail route.
- Recommended service card structure:
```txt
[small icon]
Service Name
Short outcome-driven description
Learn more →
```
Service detail pages should include:
- Hero with service name and value proposition.
- Section: `What this solves`
- Section: `How Queue North helps`
- Section: `Ideal for`
- CTA: `Talk to us about this service`
### Industries Page Layout
The `/industries` page should explain that Queue North adapts communications and support to operational realities.
Industry detail pages should include:
- Hero with industry-specific value proposition.
- Pain points.
- Queue North solution approach.
- Relevant services.
- CTA.
### Contact / Support Layout
Contact and support pages must feel trustworthy and simple.
- Use shadcn/ui form primitives.
- Keep forms visually clean with clear labels.
- Use Sonner toast for success/error states.
- Avoid giant intimidating forms.
- Use a two-column desktop layout:
- Left: reassurance, contact expectations, phone/email if available
- Right: form card
- On mobile, form comes after the intro copy.
### Design Quality Bar
Scarlett should treat the design as unacceptable if it has any of these issues:
- Nav wraps on desktop.
- Logo is oversized or visually collides with content.
- Cards look like default boxes with no hierarchy.
- Text contrast is weak.
- Sections feel cramped.
- Mobile layout feels like a collapsed desktop site.
- Images are inconsistent in crop, tone, or quality.
- There is no clear CTA above the fold.
- The site feels like cybersecurity/gaming/crypto instead of business communications.
---
## Navigation Plan
Current dropdown navigation should be simplified.
### Desktop Navigation
```txt
Home
Services
Industries
8x8
About
Contact
Support
```
### Mobile Navigation
Use shadcn/ui `Sheet`.
Mobile nav should:
- Open cleanly from a menu button.
- Avoid wrapping links.
- Show primary routes first.
- Include service and industry routes in grouped sections if needed.
---
## Route Plan
Replace hash routing with React Router paths.
```txt
/
/about
/services
/services/unified-communications
/services/contact-center
/services/managed-support
/services/consulting-training
/services/infrastructure-cabling
/services/wireless-access
/services/local-networking
/industries
/industries/healthcare
/industries/retail
/industries/manufacturing
/industries/education-finance
/8x8
/contact
/support
```
---
## Component System
Use shadcn/ui primitives wherever available.
Required primitives:
- `Button`
- `Card`
- `Sheet`
- `Dialog`
- `Input`
- `Textarea`
- `Select`
- `Badge`
- `Accordion`
- `NavigationMenu`
- `Toaster` / Sonner integration
This will modernize interactions and keep the UI consistent.
---
## Content Model
Move repeated content into data files.
Suggested files:
```txt
client/src/data/services.js
client/src/data/industries.js
client/src/data/certifications.js
client/src/data/stats.js
```
Use these files to render:
- Service overview cards
- Service detail pages
- Industry cards
- Industry detail pages
- Footer links
- Navigation links
- Trust badges
This prevents duplication and keeps future edits simple.
---
## Scarlett Design Implementation Brief
### Tailwind Theme Tokens
Using the **light-first business palette** defined in OVERHAUL_PLAN.md:
```js
// tailwind.config.js theme extension
theme: {
extend: {
colors: {
background: '#F8FAFC',
'section-alt': '#EEF6FB',
card: '#FFFFFF',
border: '#D8E3EA',
text: '#0F172A',
muted: '#475569',
'soft-text': '#64748B',
primary: {
navy: '#0B2A3C',
'navy-dark': '#071A2A',
blue: '#0EA5E9',
cyan: '#22D3EE',
},
accent: {
gold: '#F59E0B',
},
},
fontFamily: {
sans: ['Inter', 'sans-serif'],
},
},
}
```
### Numeric Typography Rule
All numbers in the visual design should use **Georgia**. This applies to stats, counters, years, version displays, numeric badges, metrics, and prominent numeric callouts.
Implementation guidance:
- Add a reusable Tailwind font family such as `font-numeric` mapped to `Georgia, serif`.
- Use the numeric font only on numeric content.
- Do not switch body text, headings, nav, or general copy to Georgia.
### Typography Scale
```css
/* Base: 16px */
.text-xs: 12px / 16px
.text-sm: 14px / 20px
.text-base: 16px / 24px
.text-lg: 18px / 28px
.text-xl: 20px / 30px
.text-2xl: 24px / 36px
.text-3xl: 30px / 44px
.text-4xl: 36px / 52px
.text-5xl: 48px / 64px
```
### Section Spacing / Container Sizes
| Breakpoint | Container Max | Section Vertical Spacing |
|------------|---------------|--------------------------|
| Mobile | `100%` | `64px` / `80px` (bottom) |
| Desktop | `1200px` | `96px` / `128px` (bottom) |
Use `container mx-auto px-4 md:px-6 lg:px-8` pattern.
### Radius / Shadow / Border Rules
```css
/* Borders */
border: 1px solid border-color
rounded-lg: 8px
rounded-xl: 12px
rounded-2xl: 16px
/* Shadows */
shadow-sm: 0 1px 2px 0 rgb(0 0 0 / 0.05)
shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1)
shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1)
shadow-lg: 0 10px 15px -3px rgb(0 0 0 / 0.1), 0 4px 6px -4px rgb(0 0 0 / 0.1)
/* Cards */
- White background
- subtle border radius (12px)
- light shadow
- no heavy borders
```
### shadcn/ui Components to Use
Required primitives from `@/components/ui/`:
- `Button` — primary/secondary/callouts
- `Card` — service cards, industry cards
- `Sheet` — mobile navigation
- `Input`, `Textarea`, `Select` — forms
- `Badge` — certifications, status indicators
- `Accordion` — FAQ or details sections
- `NavigationMenu` — desktop nav (optional if simple)
- `Toast` / `Toaster` — success/error feedback
- `Dialog` — optional modal content
### Home Page Layout Blueprint
**1. Hero (Dark Navy)**
- Full-width, dark background (`bg-primary-navy`)
- Max-width container (`1200px`)
- Two-column desktop: copy left, visual right
- Mobile: stacked, copy first
- Headline: `Modern Communications Infrastructure Without the Vendor Noise`
- Subhead: UCaaS, Contact Center, Deployment, Lifecycle
- Two CTAs: Primary (`Request Consultation`), Secondary (`Explore Services`)
- Trust chips below: 8x8 Partner, Veteran Owned, 25+ Years, SMB to Enterprise
**2. Trust Bar (Light Section)**
- Background: `bg-section-alt`
- Horizontal center-aligned icons/logos
- Mobile: stacked, centered
**3. Services Grid (White Cards)**
- Background: `bg-background`
- Grid: 2 cols mobile, 3 cols tablet, 4 cols desktop
- Each card: icon, name, 1-sentence value, subtle `Learn more`
- Shadow: `shadow-sm`
**4. Why Queue North (Three Pillars)**
- Alternating light/dark sections optional
- Card grid: `Architecture | Deployment | Lifecycle Support`
- Light background with navy accent text
**5. Industries Preview (Solution Pathways)**
- Background: `bg-section-alt`
- Grid: Healthcare, Retail, Manufacturing, Education & Finance
- Each card: pain point → Queue North solution
- 2 cols mobile, 4 cols desktop
**6. Final CTA (Dark Band)**
- Dark navy background
- Centered copy: `Tell us what you're trying to fix. We'll help map the path.`
- Single CTA: `Request Consultation`
### Service / Industry Detail Layout Blueprint
**Page Hero**
- Section background: `bg-background`
- Left-aligned headline + short intro paragraph
- Optional badge (Service / Industry / 8x8 Partner)
**Main Content (Two-Column Desktop)**
- Desktop: Left = core explanation, Right = benefits/CTA card
- Mobile: stacked
- Left column: `prose` or clean `p + ul` text
- Right column: Card with checklist, use cases, or brief differentiators
**Supporting Cards Grid**
- 3 or 4 cards
- Icons, short titles, 1-sentence descriptions
- Grid: 1 col mobile, 2 col tablet, 3 col desktop
**CTA Footer Band**
- Each major page ends with CTA
- Dark navy section
- Centered copy + primary button
### Contact / Support Form Layout
**Desktop: Two-Column**
- Left: reassurance copy, phone/email if available, trust badges
- Right: Form Card
- Background: `bg-background`
**Mobile: Stacked**
- Copy first
- Form second
- Single-column input stacking
**Form Components**
- `Input` — name, company, email, phone, zip (if needed)
- `Textarea` — message or issue description
- `Select` — service interest or priority (if applicable)
- `Button` — Submit with loading state
- `Toast` — success/error via Sonner
### Responsive / Mobile Behavior
**Mobile First Rule**
- Sections stack vertically
- Grids: 1 col → 2 col → 3+ col
- Nav: `Sheet` menu slides in from right
- Buttons full-width on mobile, constrained width on desktop
- Images: full-width or max `max-w-full`, object-cover
**Typography Scaling**
- Headlines shrink for mobile (e.g., `text-4xl md:text-5xl`)
- Body text: `text-base` minimum
- Ensure contrast ratio ≥ 4.5:1
**Spacing Rhythm**
- Mobile section padding: `py-16` (64px)
- Desktop section padding: `py-24` (96px)
- Card padding: `p-4 md:p-6`
### Asset / Image Treatment
**Guidelines**
- Images: consistent aspect ratio (16:9 or 4:3 for hero)
- Avoid inconsistent stock-photo quality
- Use `object-cover` for hero banners
- For card visuals, use consistent sizing and cropping
- Replace generic stock with custom illustrations or refined photos
**Current Assets Check**
- Review `assets/` folder
- Confirm logo PNG/SVG at 2x size for retina
- Favicon: 32px, 48px, 180px (iPhone), 192px (Android)
- Replace placeholder images with clean B2B visuals
### Explicit Anti-Patterns to Avoid
❌ Nav wraps on desktop (single line only)
❌ Oversized logo bleeding into content
❌ Cards with default Bootstrap-style borders
❌ Weak text contrast (dark gray on white, light gray on white)
❌ Sections feeling cramped or inconsistent spacing
❌ Mobile layout feeling like collapsed desktop (no mobile-first grid)
❌ Images inconsistent in crop, tone, or quality
❌ No clear primary CTA above the fold on home
❌ Dark navy used everywhere (feels crypto/cyber/gaming instead of business)
❌ Gradient overlays on every section
❌ Multiple competing typefaces
❌ Large font sizes without line-height spacing
---
## Phase-Based Versioning
Version numbers must correlate directly to the active overhaul phase.
- **Phase 1** uses `0.1.x`
- First Phase 1 release: `0.1.0`
- Every completed agent pass/checkpoint within Phase 1: `0.1.1`, `0.1.2`, etc.
- **Phase 2** uses `0.2.x`
- First Phase 2 release: `0.2.0`
- Iterations/fixes within Phase 2: `0.2.1`, `0.2.2`, etc.
- **Phase 3** uses `0.3.x`
- **Phase 4** uses `0.4.x`
- **Phase 5** uses `0.5.x`
Rule: the minor version maps to the phase number; the patch version maps to each completed agent pass/checkpoint inside that phase. Do not use unrelated semantic version bumps during the overhaul.
---
## Migration Phases
## Phase 1: Scaffold the Stack
Goals:
- Create Vite React app.
- Add Tailwind CSS.
- Add shadcn/ui.
- Add React Router.
- Add Sonner.
- Add TanStack Query.
- Create Express server.
- Add better-sqlite3.
- Set up development scripts.
Result:
- Frontend boots.
- Backend boots.
- API health check works.
- Frontend can call backend.
---
## Phase 2: Rebuild Layout
Goals:
- Build application shell:
- Header
- Footer
- Layout wrapper
- Mobile navigation
- Build route pages.
- Port existing business content into React components.
- Replace hash routing with React Router.
- Move repeated content into data files.
Result:
- Site content exists in the new React app.
- Routes are clean and shareable.
- Structure is maintainable.
---
## Phase 3: Visual Overhaul
Scarlett owns this phase.
Goals:
- Define Tailwind theme tokens.
- Apply new color system.
- Improve typography.
- Improve spacing scale.
- Build responsive-first layouts.
- Replace dated cards/sections with modern component patterns.
- Improve logo/header placement.
- Remove layout jank.
- Ensure mobile experience feels intentional.
Result:
- Website feels modern, premium, and trustworthy.
- Visual system is reusable across pages.
---
## Phase 4: Forms + Backend
Goals:
- Replace inline Zoho iframe form with React form.
- Submit contact requests to Express API.
- Submit support requests to Express API.
- Save submissions in SQLite.
- Use Sonner for success/error messages.
- Add validation.
- Optional later: forward leads to Zoho from backend.
Result:
- Forms are owned by the application.
- Leads/support requests are stored locally.
- UX is cleaner and easier to test.
---
## Phase 5: Verification
Bishop owns verification.
Goals:
- Confirm frontend build works.
- Confirm backend starts.
- Confirm all routes load.
- Confirm mobile navigation works.
- Confirm contact form submits.
- Confirm support form submits.
- Confirm SQLite writes succeed.
- Confirm no obvious console errors.
- Confirm basic accessibility expectations.
- Update project documentation.
Result:
- Rebuild is tested and documented.
---
## Agent Plan
Recommended pipeline:
1. **Scarlett**
- Create design direction.
- Define Tailwind theme.
- Define layout system and component expectations.
2. **Neo**
- Scaffold Vite + React + Express + SQLite.
- Build API/database foundation.
- Convert static site into structured app.
3. **Scarlett**
- Polish UI implementation.
- Enforce shadcn/ui and Tailwind standards.
- Review responsive behavior and visual quality.
4. **Bishop**
- Verify build/runtime/routes/forms.
- Update docs.
5. **Ripley**
- Final test.
- Commit and push.
---
## Recommendation
Start with **Scarlett first**, then move to Neo.
Reason:
This is primarily a brand and layout overhaul. If the app is scaffolded before the visual system is defined, the team may build clean code around the wrong structure. The better path is:
```txt
Design system first → scaffold/build → polish → verify
```
---
## Success Criteria
The overhaul is successful when:
- The site no longer looks or feels early-2000s.
- The app runs on the requested stack.
- Routing uses React Router, not hash switching.
- Styling uses Tailwind, not a giant global stylesheet.
- shadcn/ui primitives are used for common UI elements.
- Contact/support forms submit through Express.
- Form submissions are stored in SQLite.
- The site is responsive and polished on mobile.
- The content still clearly communicates Queue North's services, 8x8 partnership, and operational expertise.

View File

@ -1,69 +0,0 @@
# Queue North Website
## Overview
Project: Queue-North-Website
Created: 2026-05-11
Status: Active (Phase 1 Complete - 0.1.1)
Rebuild Phase: 1 (Vite + React + Express + SQLite)
## Description
Website for Queue North Technologies — an 8x8 Certified Partner delivering UCaaS, Contact Center, deployment, and managed lifecycle support for SMB and enterprise organizations.
## Tech Stack (Phase 1)
- **Vite** — build tool and dev server
- **React 19** — SPA with client-side routing via React Router 7
- **Tailwind CSS** — utility-first styling with custom theme
- **shadcn/ui-style** — component primitives built in
- **Sonner** — toast notifications
- **TanStack Query** — server state management
- **Express** — backend API server
- **better-sqlite3** — local SQLite database
## Directory Structure (Phase 1)
- `index.html` — Entry point (Vite + React entry)
- `src/main.jsx` — React entry point with QueryClient and Toaster
- `src/App.jsx` — Layout wrapper with Header, MobileNav, Footer
- `src/router.jsx` — React Router configuration
- `src/lib/api.js` — API helper with TanStack Query
- `src/data/services.js` — Services data
- `src/data/industries.js` — Industries data
- `src/components/ui/` — UI primitives (Button, Card, Input, etc.)
- `src/components/layout/` — Header, Footer, MobileNav
- `src/pages/` — Route pages (Home, About, Services, etc.)
- `server/index.js` — Express backend with SQLite
- `db/queuenorth.db` — SQLite database (created on first run)
- `assets/` — Images, icons, logos
## Git
- **Branch:** `dev` (working), `main` (stable)
- **Remote:** `ssh://forgejo/null/Queue-North-Website.git`
## Versioning
Version numbers must correlate to the active overhaul phase.
- Phase 1 releases use `0.1.x`
- Phase 1 baseline: `0.1.0`
- Every completed agent pass/checkpoint within Phase 1 increments patch: `0.1.1`, `0.1.2`, etc.
- Phase 2 releases use `0.2.x`
- Phase 2 baseline: `0.2.0`
- Phase 2 patches/iterations: `0.2.1`, `0.2.2`, etc.
- Phase 3 releases use `0.3.x`
- Phase 4 releases use `0.4.x`
- Phase 5 releases use `0.5.x`
Do not use unrelated semantic version bumps during the overhaul. The minor number tracks the phase; the patch number tracks changes within that phase.
## Phase Completion Git Rule
Push to `dev` after every completed and verified phase.
- Agents do not touch git.
- Bishop verifies and updates docs.
- Ripley performs final checks, commits, and pushes to `dev`.
## Conventions
- Follow AGENTS.md for agent dispatch protocol
- Ripley coordinates, Neo codes, Scarlett styles, Bishop verifies, Hudson secures
- All agents read STRUCTURE.md before starting tasks
- Ripley owns git — no agent touches git directly

View File

@ -1,57 +0,0 @@
# Queue North Website — Script Reference
Run these from the project root.
## Install
```bash
npm install
```
## Development
Start frontend and backend together:
```bash
npm run dev
```
Frontend runs through Vite. Backend runs through Express.
## Build
```bash
npm run build
```
Creates the production frontend build in `dist/`.
## Preview Frontend Build
```bash
npm run preview
```
## Start Backend Only
```bash
npm start
```
Equivalent compatibility script:
```bash
npm run server
```
## Health Check
```bash
curl http://localhost:3001/api/health
```
Expected response shape:
```json
{"status":"ok","timestamp":"..."}
```

View File

@ -1,56 +0,0 @@
# Queue-North-Website — Project Structure
## Agent Roles
| Agent | Role | Focus Area |
|-------|------|------------|
| Neo | Backend Coder | Server code, APIs, database, build system |
| Scarlett | UI/Design | Frontend components, Tailwind CSS, layout, visuals |
| Bishop | Verification | Build, runtime tests, documentation, version bumps |
| Private_Hudson | Security | Auth, data exposure, input validation, dependency audit |
| Ripley | Coordinator | Git, deploy, pipeline, task dispatch |
## Code Ownership
TBD — will be defined as the project takes shape.
## Key Files
- `PROJECT.md` — Project overview and conventions
- `STRUCTURE.md` — This file. Agent roles, code ownership, critical paths
- `FUTURE.md` — Planning doc (what to build next)
- `HISTORY.md` — Version changelog
- `DEVELOPMENT_LOG.md` — Agent activity log
## Versioning Rules for Bishop
Bishop owns verification documentation and must ensure version numbers correlate to the active overhaul phase.
- Phase 1 uses `0.1.x`
- Phase 1 baseline: `0.1.0`
- Every completed agent pass/checkpoint within Phase 1 increments patch: `0.1.1`, `0.1.2`, etc.
- Phase 2 uses `0.2.x`
- Phase 2 baseline: `0.2.0`
- Phase 2 follow-up fixes/iterations: `0.2.1`, `0.2.2`, etc.
- Phase 3 uses `0.3.x`
- Phase 4 uses `0.4.x`
- Phase 5 uses `0.5.x`
Rule: the minor version maps to the phase number; the patch version maps to each completed agent pass/checkpoint inside that phase. Do not use unrelated semantic version bumps during this overhaul.
Before Bishop marks work verified, Bishop must check:
- `package.json` version follows the active phase
- `PROJECT.md` version/status matches the active phase
- `HISTORY.md` release notes use the same version
- Any verification summary references the correct phase/version
## Phase Completion Git Rule
Ripley must push to `dev` after every completed and verified phase.
- Agents do not touch git.
- Bishop verifies and updates docs.
- Ripley performs final local checks, commits, and pushes to `dev`.
- This applies to Phase 1 (`0.1.x`), Phase 2 (`0.2.x`), and all later phases.
## Cross-Cutting Concerns
- All agents must read this file before starting any task
- All agents report back to Ripley — no agent-to-agent handoffs