Language: Respond in the same language the user uses. Code comments should match.

bash /workspace/start.sh

1. Read each image using the Read tool — you are multimodal, examine them directly.
2. For each image, document:
   • Page identity: which page/view this represents
   • Layout structure: header, sidebar, main content, footer, modals
   • Component inventory: every button, form, card, table, list, nav element
   • Content inventory: all visible text, numbers, labels, placeholder content
   • Color extraction: primary, secondary, accent, background, text colors (hex values)
   • Typography: font sizes, weights, hierarchy observed
   • Interactive states: hover effects, active tabs, selected items, toggles
   • Data patterns: what data populates lists/tables/cards — this drives seed data
3. Build a page map showing navigation flow between prototype pages.

• Table/collection name
• All fields with types, constraints, defaults
• Relationships (foreign keys, many-to-many)
• Indexes needed for query patterns
• Content mapping: which prototype elements map to which fields

products table:
  id          SERIAL PRIMARY KEY
  name        VARCHAR(200) NOT NULL    ← from product card title
  price       DECIMAL(10,2) NOT NULL   ← from product card price label
  image_url   TEXT NOT NULL             ← from product card image
  category_id INTEGER REFERENCES categories(id) ← from category filter
  ...

• Method + path
• Request params/body schema
• Response schema with example
• Which prototype interaction triggers this API
• Error responses

• Component hierarchy (tree structure)
• Route definitions mapping to prototype pages
• State management approach
• How each prototype page maps to components

1. Extract from prototypes: Every piece of visible text, image, number in the prototype images must appear in seed data. Read each prototype image again and transcribe content.
2. Complete coverage:
   • Every list/table must have the exact number of items shown in prototypes
   • Every card must have the content matching the prototype
   • Every dropdown must have options matching the prototype
   • Navigation items must match prototype navigation
   • Statistics/counters must match prototype numbers
3. Use resource files: Map resource files (images, videos, icons) from

   /workspace/resources/

   to seed data entries. Use relative paths or copy to public/static dir.
4. No placeholders: No "Lorem ipsum", no "Test Item 1", no

   placeholder.com

   images.
5. Support all states: Include data that exercises empty states, loaded states, error scenarios as specified in the PRD.

• SQL seed files, or
• JSON fixtures, or
• ORM seed scripts

/workspace/backend/src/seed/

• Create migration files for all tables
• Include proper constraints, indexes, foreign keys
• Run migrations to verify they work

1. Implement route handler
2. Add input validation (validate types, required fields, ranges)
3. Add error handling with proper HTTP status codes
4. Test with curl or equivalent to verify response format

• Implement a seed script that:
  • Clears existing data (for idempotent re-seeding)
  • Inserts all seed data in correct dependency order
  • Copies resource files to the correct static serving location
• Verify seed data loads without errors

• Configure the backend to serve resource files (images, videos, etc.)
• Ensure frontend can access them via proper URLs

• Color variables matching prototype colors
• Typography scale matching prototype fonts
• Spacing/sizing system matching prototype spacing
• Common component styles (buttons, cards, inputs, etc.)

1. Re-read the prototype image — keep it fresh in your context
2. Build the page component matching the layout exactly:
   • Match spacing and proportions
   • Match colors and typography
   • Match visual hierarchy
   • Match content placement
3. Wire up API calls to the backend
4. Implement all interactions visible or implied:
   • Navigation between pages
   • Form submissions
   • Search and filter
   • Sorting
   • Modals and dialogs
   • Loading states
   • Error states
   • Hover effects
   • Active/selected states

• Copy all resources from

  /workspace/resources/

  to frontend assets
• Reference them correctly in components
• Ensure images render at proper sizes matching prototypes

• Match the viewport width shown in prototypes
• If prototypes show mobile views, implement responsive breakpoints

1. Read the prototype image from

   /workspace/prototypes/

2. Read the rendered screenshot
3. Compare systematically:
   • Layout: Are sections in the right positions?
   • Colors: Do colors match?
   • Typography: Are font sizes/weights correct?
   • Content: Is all prototype content present?
   • Spacing: Are margins and paddings close?
   • Images: Are all images rendering?
   • Components: Are all UI components present and correct?

1. Identify the specific CSS/component change needed
2. Apply the fix
3. Re-render and re-compare

1. Open the app at

   http://localhost:3000

2. Navigate to each page
3. Test each interactive feature
4. Verify data loads from the database
5. Verify forms submit correctly
6. Verify search/filter/sort work

1. Be fully self-contained — no prior setup assumed
2. Work in a fresh environment
3. Install all system dependencies (Node.js, Python, DB, etc.)
4. Clean any previous state
5. Set up the database from scratch
6. Run all migrations
7. Load all seed data
8. Build the frontend (if needed)
9. Start both backend and frontend
10. Make the app available at

    http://localhost:3000

1. chmod +x /workspace/start.sh

2. Run it:

   bash /workspace/start.sh

3. Wait for startup
4. Verify

   http://localhost:3000

   responds
5. Spot-check a few API endpoints
6. Fix any startup issues

• Final system architecture
• Final data model (with any fields added during dev)
• Technology stack
• Deployment architecture
• API reference

• Frontend: ...
• Backend: ...
• Database: ...

• All PRD features implemented — no features skipped
• All prototype pages built — no pages merged or omitted
• Visual match with prototypes — verified via screenshot comparison
• All resource files used where they appear in prototypes
• Seed data matches prototype content exactly
• All API endpoints working and returning correct data
• All interactive elements functional (forms, search, filters, modals, navigation)

• bash /workspace/start.sh

  works from a clean state
• App accessible at

  http://localhost:3000

• Design document complete
• README with deployment instructions

1. Prototypes are truth — when PRD text and prototype images conflict, the prototype wins for visual/layout decisions.
2. No shortcuts on data — every piece of content visible in prototypes must come from the database via APIs. No hardcoded data in frontend components.
3. Complete implementation — every page, every feature, every interaction. Don't skip "minor" features. Don't merge separate pages into one.
4. Resources must be used — if the prototype shows an image and a matching file exists in

   /workspace/resources/

   , use that file. Don't substitute with placeholder URLs.
5. Reproducibility —

   start.sh

   must work from absolute zero. If it needs Node 18+, it installs Node 18+. If it needs PostgreSQL, it sets up PostgreSQL.
6. Verify, don't assume — use the visual verification loop (Phase 5) to actually compare your output against prototypes. Use API checks to verify endpoints. Run start.sh to verify deployment.