Some checks failed
Deploy monie-landing (kaniko) / build-and-deploy (push) Failing after 20m45s
500 lines
11 KiB
Markdown
500 lines
11 KiB
Markdown
# AGENTS.md
|
||
|
||
## Project
|
||
Monie Landing — marketing website for a product for individual service masters.
|
||
|
||
This is not a salon CRM.
|
||
This is not an enterprise business automation system.
|
||
This is not a dashboard-first product.
|
||
|
||
The product is built for independent masters:
|
||
- nail artists
|
||
- barbers
|
||
- brow artists
|
||
- lash makers
|
||
- cosmetologists
|
||
- massage specialists
|
||
- other solo beauty/service professionals
|
||
|
||
The landing page must present Monie as a simple, modern tool that helps one master manage bookings, clients, and income without complexity.
|
||
|
||
---
|
||
|
||
## Core product idea
|
||
Monie is a personal business page for a master.
|
||
|
||
It combines:
|
||
- personal profile
|
||
- services and prices
|
||
- online booking
|
||
- simple calendar
|
||
- client list
|
||
- income visibility
|
||
|
||
The product should feel like:
|
||
- a personal brand page
|
||
- a booking tool
|
||
- a lightweight work assistant
|
||
|
||
It should NOT feel like:
|
||
- a salon admin panel
|
||
- a CRM for teams
|
||
- an overloaded ERP-like system
|
||
- a back office for managers
|
||
|
||
---
|
||
|
||
## Strategic positioning
|
||
YCLIENTS is positioned around business automation: online booking, customer base automation, notifications, analytics, finance, payroll, stock control, and management of larger operations.
|
||
|
||
Monie must be positioned differently:
|
||
- not for business owners managing staff
|
||
- not for networks and franchises
|
||
- not for administrators
|
||
- for the master personally
|
||
|
||
The key shift is:
|
||
from "manage a business"
|
||
to "run your own practice simply"
|
||
|
||
---
|
||
|
||
## Main message
|
||
The user is not a company.
|
||
The user is a master.
|
||
|
||
The landing should communicate this feeling immediately:
|
||
|
||
"I am a master. I want a beautiful page, easy booking, and clear control over my work and income."
|
||
|
||
---
|
||
|
||
## Design direction
|
||
The visual style must be:
|
||
- modern
|
||
- premium
|
||
- clean
|
||
- soft
|
||
- confident
|
||
- minimal
|
||
- mobile-first
|
||
- conversion-focused
|
||
|
||
The emotional tone must be:
|
||
- personal
|
||
- calm
|
||
- aesthetic
|
||
- trustworthy
|
||
- not corporate
|
||
- not aggressive
|
||
- not noisy
|
||
|
||
Avoid:
|
||
- enterprise SaaS look
|
||
- complex tables on first screens
|
||
- admin-dashboard feel
|
||
- too much dense UI
|
||
- “business automation” aesthetics
|
||
- generic startup gradients everywhere
|
||
- crypto-like visual language
|
||
- ugly CRM blocks
|
||
- too many borders and widgets
|
||
|
||
---
|
||
|
||
## Product metaphor
|
||
Think of the product as closer to:
|
||
- a personal booking page
|
||
- a professional profile
|
||
- a master’s mini-site
|
||
- a simple scheduling assistant
|
||
|
||
Not as:
|
||
- a back office
|
||
- a team management system
|
||
- a reporting center
|
||
|
||
---
|
||
|
||
## UX principles
|
||
Every UI decision must optimize for:
|
||
1. clarity
|
||
2. trust
|
||
3. speed of understanding
|
||
4. emotional comfort
|
||
5. conversion
|
||
|
||
The landing must explain the product in a few seconds.
|
||
|
||
The visitor should instantly understand:
|
||
- this is for masters
|
||
- this helps with bookings
|
||
- this helps avoid chaos in messages
|
||
- this helps track work and income
|
||
- this gives them a professional online presence
|
||
|
||
---
|
||
|
||
## Hero section rules
|
||
The hero must communicate 3 things immediately:
|
||
1. what the product is
|
||
2. who it is for
|
||
3. what action to take next
|
||
|
||
Hero should feel personal, not corporate.
|
||
|
||
Bad direction:
|
||
- “Business automation platform”
|
||
- “CRM and analytics for service companies”
|
||
- “Optimize operational efficiency”
|
||
|
||
Good direction:
|
||
- “Your personal booking page”
|
||
- “All your clients and appointments in one place”
|
||
- “For masters who want less chaos and more income”
|
||
- “Accept bookings without chats, spreadsheets, and confusion”
|
||
|
||
---
|
||
|
||
## Landing page structure
|
||
Preferred structure:
|
||
|
||
1. Hero
|
||
2. Problem
|
||
3. Solution
|
||
4. Product preview
|
||
5. Benefits
|
||
6. How it works
|
||
7. Personal page / profile feature
|
||
8. Social proof or trust block
|
||
9. FAQ
|
||
10. Final CTA
|
||
11. Footer
|
||
|
||
---
|
||
|
||
## Section intent
|
||
### 1. Hero
|
||
Make the value instantly clear.
|
||
Focus on one master, not a team.
|
||
|
||
### 2. Problem
|
||
Show current pain:
|
||
- bookings in messengers
|
||
- scattered notes
|
||
- forgotten appointments
|
||
- no clear client history
|
||
- no clear income view
|
||
|
||
### 3. Solution
|
||
Monie gives the master one clean place for:
|
||
- profile
|
||
- services
|
||
- booking
|
||
- calendar
|
||
- clients
|
||
- earnings
|
||
|
||
### 4. Product preview
|
||
Show interface as elegant and simple.
|
||
The UI should look closer to a polished consumer product than to CRM software.
|
||
|
||
### 5. Benefits
|
||
Explain outcomes, not enterprise functions.
|
||
|
||
Prefer:
|
||
- “clients can book you anytime”
|
||
- “all appointments in one calendar”
|
||
- “see how much you earned”
|
||
- “keep your services and prices in order”
|
||
- “look more professional online”
|
||
|
||
Avoid:
|
||
- “automation of business processes”
|
||
- “deep operational analytics”
|
||
- “staff access rights”
|
||
- “warehouse management”
|
||
- “franchise scaling”
|
||
|
||
### 6. How it works
|
||
Keep it simple and linear:
|
||
- create profile
|
||
- add services
|
||
- share link
|
||
- get bookings
|
||
|
||
### 7. Personal page feature
|
||
This is a key product idea.
|
||
The master should get a page like:
|
||
- monie.app/anna-nails
|
||
- monie.app/david-barber
|
||
|
||
This page should feel like a major product advantage.
|
||
|
||
### 8. Trust block
|
||
Use trust elements that fit solo specialists:
|
||
- looks professional
|
||
- simple to start
|
||
- saves time
|
||
- helps avoid missed bookings
|
||
|
||
### 9. FAQ
|
||
Answer practical concerns:
|
||
- do I need a website?
|
||
- can I set my own services and prices?
|
||
- can clients book online?
|
||
- is it good for a solo master?
|
||
- can I use it from phone?
|
||
|
||
### 10. Final CTA
|
||
Clear, direct, simple.
|
||
Bring the user back to one primary action.
|
||
|
||
---
|
||
|
||
## Visual system
|
||
### Layout
|
||
- Use a strong central container
|
||
- Keep generous whitespace
|
||
- Prefer large clean sections
|
||
- Build obvious visual rhythm
|
||
- Make scanning effortless
|
||
|
||
### Spacing
|
||
- Use a consistent spacing system
|
||
- Prefer breathing room over density
|
||
- Never make sections feel cramped
|
||
|
||
### Typography
|
||
- Strong, short headings
|
||
- Short supporting text
|
||
- High contrast and clear hierarchy
|
||
- No long walls of text
|
||
|
||
### Cards
|
||
- Use cards consistently
|
||
- Same radius language across sections
|
||
- Same shadow logic across sections
|
||
- Same padding logic across sections
|
||
|
||
Do not invent a new card style in every block.
|
||
|
||
### Buttons
|
||
Primary CTA must be obvious.
|
||
Secondary CTA must be quieter.
|
||
|
||
Prefer CTA labels like:
|
||
- Start free
|
||
- Create your page
|
||
- Get started
|
||
- Accept bookings online
|
||
|
||
Avoid vague labels like:
|
||
- Learn more
|
||
- Explore platform
|
||
- Discover solution
|
||
|
||
---
|
||
|
||
## UI tone
|
||
The interface should feel like a beautiful assistant for a master.
|
||
|
||
It should feel:
|
||
- feminine or neutral depending on styling direction
|
||
- elegant
|
||
- clean
|
||
- easy
|
||
- pleasant to use
|
||
- human
|
||
|
||
Never make it feel:
|
||
- bureaucratic
|
||
- operationally heavy
|
||
- manager-oriented
|
||
- back-office first
|
||
|
||
---
|
||
|
||
## Image and mockup direction
|
||
When creating product visuals or mockups:
|
||
- show a personal profile
|
||
- show services and prices
|
||
- show available booking times
|
||
- show simple schedule/calendar
|
||
- show compact client info
|
||
- show income summary in a lightweight way
|
||
|
||
Do not center the experience around:
|
||
- employees
|
||
- branches
|
||
- warehouse
|
||
- finance admin
|
||
- payroll management
|
||
- huge analytics dashboards
|
||
|
||
---
|
||
|
||
## Copywriting rules
|
||
Copy must be:
|
||
- short
|
||
- clear
|
||
- benefit-driven
|
||
- emotional but concrete
|
||
- easy to understand instantly
|
||
|
||
Prefer:
|
||
- plain language
|
||
- direct promises
|
||
- practical outcomes
|
||
|
||
Avoid:
|
||
- buzzwords
|
||
- abstract innovation language
|
||
- B2B corporate phrasing
|
||
- words that sound like enterprise software
|
||
|
||
Bad examples:
|
||
- revolutionary service business ecosystem
|
||
- end-to-end operational efficiency
|
||
- scalable management infrastructure
|
||
|
||
Good examples:
|
||
- all your bookings in one place
|
||
- your personal booking page
|
||
- simpler scheduling for masters
|
||
- clients can book you online anytime
|
||
- work with less chaos
|
||
|
||
---
|
||
|
||
## Mobile-first rule
|
||
This product is very likely to be discovered and used on phone.
|
||
|
||
All design decisions must work beautifully on mobile first:
|
||
- compact hero
|
||
- short copy
|
||
- clear CTA
|
||
- easy card scanning
|
||
- elegant stacked sections
|
||
- no tiny dense UI
|
||
|
||
Desktop should feel premium.
|
||
Mobile should feel natural.
|
||
|
||
---
|
||
|
||
## Conversion rule
|
||
This is a landing page, not a documentation page.
|
||
|
||
Every section must help the user move toward action.
|
||
If a section does not improve:
|
||
- clarity
|
||
- trust
|
||
- desire
|
||
- conversion
|
||
|
||
then remove it.
|
||
|
||
---
|
||
|
||
## What Codex should prioritize
|
||
When improving the landing, always prioritize in this order:
|
||
1. clarity
|
||
2. positioning for masters
|
||
3. emotional appeal
|
||
4. trust
|
||
5. conversion
|
||
6. visual consistency
|
||
7. polish
|
||
|
||
---
|
||
|
||
## Anti-patterns
|
||
Do not create:
|
||
- generic SaaS landing pages
|
||
- enterprise dashboard visuals
|
||
- complex CRM-like layouts
|
||
- feature grids with meaningless buzzwords
|
||
- too many UI styles in one page
|
||
- dark aggressive fintech aesthetics unless explicitly requested
|
||
- overloaded hero sections
|
||
- giant comparison tables unless specifically needed
|
||
- business-owner messaging instead of master messaging
|
||
|
||
---
|
||
|
||
## Component guidance
|
||
Preferred section/component set:
|
||
- HeroSection
|
||
- ProblemSection
|
||
- SolutionSection
|
||
- ProductPreviewSection
|
||
- BenefitsSection
|
||
- HowItWorksSection
|
||
- PersonalPageSection
|
||
- TrustSection
|
||
- FAQSection
|
||
- FinalCTASection
|
||
- Footer
|
||
|
||
Keep components modular and readable.
|
||
Prefer explicit names over abstract names.
|
||
|
||
---
|
||
|
||
## denjs-ui usage rule
|
||
Always check and use components from `denjs-ui` first.
|
||
|
||
Before creating any custom UI component:
|
||
1. Search in `denjs-ui` (`list_components`, `search_components`, `get_component`).
|
||
2. If a suitable component exists, use it.
|
||
3. Create a custom component only when no suitable `denjs-ui` option exists.
|
||
|
||
---
|
||
|
||
## FSD architecture rule
|
||
All new frontend work must follow Feature-Sliced Design (FSD).
|
||
|
||
Required layers:
|
||
- `src/app` — app init, providers, global styles, routing setup
|
||
- `src/pages` — route-level page composition only
|
||
- `src/widgets` — large page blocks/sections (Hero, FAQ, CTA, etc.)
|
||
- `src/features` — user scenarios and interactions (forms, actions, flows)
|
||
- `src/entities` — business entities (`master`, `booking`, `service`, `client`)
|
||
- `src/shared` — reusable UI, lib, config, api, assets
|
||
|
||
Rules:
|
||
- Keep strict dependency direction: upper layers can use lower layers only.
|
||
- Do not import across slices directly; use each slice public API (`index.ts`).
|
||
- Do not keep business UI logic directly in route files when it can live in `widgets/features/entities`.
|
||
- New sections/components for the landing should be created as FSD slices, not as flat files.
|
||
|
||
---
|
||
|
||
## Coding guidance
|
||
When generating frontend code:
|
||
- keep components small and reusable
|
||
- keep responsive behavior clean
|
||
- avoid unnecessary dependencies
|
||
- avoid overengineering
|
||
- keep styling tokens consistent
|
||
- use one visual language across the whole landing
|
||
- prefer simple structure over clever abstractions
|
||
|
||
---
|
||
|
||
## Decision filter
|
||
Before adding any element, ask:
|
||
- Does this make the product clearer?
|
||
- Does this make Monie feel more personal for a master?
|
||
- Does this increase trust?
|
||
- Does this improve conversion?
|
||
- Does this still avoid CRM/business-automation aesthetics?
|
||
|
||
If not, do not add it.
|
||
|
||
---
|
||
|
||
## One-sentence product definition
|
||
Monie is a simple, beautiful booking and client page for independent masters.
|