← Hub

Agentic Programming Specification

A comprehensive audit and specification of the tooling, standards, and processes required for AI coding agents to effectively and safely contribute to the PeyePeye codebase — a single Express.js server with 11 HTML pages, a Storybook component library, and Railway deployment.

32%
Agent Readiness
28
Items Exist
9
Partial
43
Missing
10
Spec Areas
1
Repository

Executive Summary

4
Critical Priority Gaps
3
High Priority Gaps
3
Medium Priority Gaps

The PeyePeye codebase is currently at 32% readiness for agentic programming. Out of 80 audited items across 1 repository, 28 exist, 9 are partial, and 43 are missing.

Strengths: Storybook with 88 components across multiple categories, React Flow diagrams documenting diner and restaurant flows, Railway deployment at https://peyepeye-production.up.railway.app, and comprehensive HTML documentation pages (11 pages covering scope, investors, and prospectus). Full documentation suite with README.md, CONTRIBUTING.md, CLAUDE.md, and a browsable markdown docs viewer. Biggest gaps: Zero tests of any kind, no linting or code quality tooling, no CI/CD pipeline, and cookie-based auth with a plaintext password. Zod schemas now provide runtime type validation across all 8 entities.

The implementation roadmap spans 12 weeks in 3 phases: Foundation (git, standards & linting), Quality (testing & CI/CD), and Security (scanning & hardening). Completing this specification would bring agent readiness to approximately 85–95%.

Agent Readiness Levels

Level up your codebase to unlock increasingly powerful AI capabilities. Each tier is a milestone — complete the requirements and new tools become safe to use. Currently training toward Tier 1 using Cursor, VS Code Copilot, and Claude Code.

0
Pre-Training
Next: Copilot Pair Programming at 35%
32/100
Readiness XP
35%
60%
85%
Copilot
Supervised
Autonomous
Copilot
35%
Only 3 XP to go — ~1 week
91% complete
Tools: Cursor, VS Code Copilot, Claude Code (interactive)
Human drives, AI suggests. Autocomplete, code generation, inline refactoring — with a developer approving every change.
Unlock Requirements
  • ESLint + Prettier enforced 0%
  • Git repository initialized 0%
  • .env.example + dev setup docs 30%
  • Component library documented 65%
Abilities Unlocked
  • Autocomplete functions, props, types
  • Generate boilerplate components & routes
  • AI-assisted refactoring
  • Auto-generate JSDoc/TSDoc
Supervised
60%
42 XP to go — ~12 weeks
30% complete
Tools: Claude Code (agentic), Cursor Composer, Copilot Workspace
AI drives, human reviews PRs. Agent writes features, opens PRs, fixes CI failures — with human approval before merge.
Unlock Requirements
  • Testing framework running 0%
  • CI quality gates on PRs 0%
  • Git workflow + branch protection 0%
  • API docs / route documentation 55%
Abilities Unlocked
  • Full feature branches (code + tests + PR)
  • Auto-fix CI failures in feedback loops
  • Generate Storybook stories
  • Run and interpret E2E tests
Autonomous
85%
67 XP to go — ~20 weeks
21% complete
Tools: Claude Code (headless), GitHub Copilot Agents, AI pipelines
AI operates independently. Triages issues, plans work, writes code + tests, opens PRs, auto-merges after CI + approval.
Unlock Requirements
  • SAST + dependency scanning 0%
  • 60%+ test coverage 0%
  • State + data flow documented 40%
  • Security audit completed 0%
Abilities Unlocked
  • Auto-implement from issue backlog
  • Auto-merge after CI + 1 approval
  • Monitor errors & create fix PRs
  • Nightly AI regression + triage
1
Storybook / Component Library
A living component library with Storybook enables AI agents to visually verify UI changes, understand component APIs, and generate new components that match existing patterns.
Key Gap: Storybook exists with 88 components but is hosted externally — not integrated into the project build or CI pipeline
Current State: 5 of 8 items exist 65%
peyepeye
ItemStatus
Storybook installed & configured ✓ Exists88 components across multiple categories
Component stories documented ✓ ExistsAuto-docs enabled with props/usage examples
Design tokens documented ✓ ExistsColors, spacing, typography in Storybook
Chromatic or visual regression ✗ Missing
Storybook CI deployment ◐ PartialHosted externally, no CI build
Component naming conventions ✓ ExistsConsistent patterns across 88 components
NPM package for sharing ✗ Missing
Components consumed by main app ✓ ExistsReferenced in HTML pages
Build NPM Package for Component Library High
The Storybook has 88 components but no NPM package build. Create a distributable package so components can be imported directly into the Express app or future frontend builds.
Acceptance Criteria
  • Build script produces dist/ with ESM output
  • package.json exports field configured correctly
  • All 88 components exported and importable
  • Design tokens (colors, spacing, typography) exported
Agent Instructions ▶

Create a build step for the Storybook component library so components can be consumed as an NPM package rather than only being available through the external Storybook instance.

# Add build configuration for component library
# npm install -D vite-plugin-dts
# Configure vite.config.ts in library mode
# Add scripts: "build:lib": "vite build"
# Update package.json with main/module/types fields
Visual Regression Testing with Chromatic Medium
Integrate Chromatic for automated visual diff testing on every PR, giving agents confidence their UI changes don't break existing components.
Acceptance Criteria
  • Chromatic project created and linked to peyepeye repo
  • GitHub Actions runs Chromatic on every PR
  • Baseline snapshots captured for all 88 component stories
  • Visual diff threshold configured
  • PR comments include Chromatic build link
Agent Instructions ▶

Add visual regression testing so that when an agent changes a component, Chromatic automatically catches any unintended visual differences before the PR is merged.

npm install --save-dev chromatic
# Add GitHub Actions workflow:
# - uses: chromaui/action@latest
#   with:
#     projectToken: ${{ secrets.CHROMATIC_TOKEN }}
Integrate Storybook into CI Build High
Move Storybook from external hosting into the project's CI pipeline so it builds and deploys automatically on every push.
Acceptance Criteria
  • Storybook build step added to CI pipeline
  • Storybook deployed automatically on merge to main
  • Build failures block PR merge
  • Storybook accessible via a project URL
Agent Instructions ▶

Move Storybook hosting into the project's own CI/CD pipeline so it builds and publishes automatically, giving agents a reliable reference for component patterns.

# Add to GitHub Actions workflow:
# - name: Build Storybook
#   run: npx storybook build
# - name: Deploy Storybook
#   uses: actions/upload-pages-artifact@v3
#   with: { path: storybook-static }
2
Architecture & Coding Standards
Documented architecture decisions, coding conventions, and contribution guidelines are essential for AI agents to generate code that fits the existing codebase patterns.
Key Gap: No TypeScript yet — Zod schemas provide runtime type validation for all 8 entities. Comprehensive docs exist (README, CONTRIBUTING, CLAUDE.md, ARCHITECTURE.md with 7 ADRs)
Current State: 7 of 12 items exist 58%
peyepeye
ItemStatus
CONTRIBUTING.md ✓ ExistsFull contribution guide with design system, naming conventions
Architecture Decision Records ✓ Exists7 ADRs documented in ARCHITECTURE.md
Folder structure documentation ✓ ExistsDocumented in README.md project structure tree
CLAUDE.md / AGENTS.md ✓ ExistsAI agent context with architecture, auth flow, commands, patterns
TypeScript ◐ PartialZod schemas provide runtime type validation for all 8 entities; full TypeScript not yet configured
Import path aliases ✗ Missing
Code patterns guide ✓ ExistsCoding patterns section in ARCHITECTURE.md
Error handling patterns ✓ ExistsZod validate() middleware with structured VALIDATION_ERROR responses; documented in ARCHITECTURE.md
README.md ✓ ExistsFull project overview with tech stack, setup, structure, deployment
Component patterns guide ◐ PartialStorybook has some patterns
File naming conventions ◐ PartialDocumented in CONTRIBUTING.md naming conventions table
Express route documentation ◐ PartialDocumented in CLAUDE.md auth flow and key files
Create CONTRIBUTING.md and README.md Critical
A comprehensive contribution guide and project README that AI agents can reference before making any code changes. Covers the Express.js server structure, HTML page conventions, and development workflow.
Acceptance Criteria
  • CONTRIBUTING.md exists in project root
  • README.md with project overview, setup instructions, and architecture summary
  • Includes: file naming conventions, HTML page structure
  • Includes: Express route patterns and middleware usage
  • Includes: commit message format (Conventional Commits)
Agent Instructions ▶

Create foundational documentation so agents know how to work with the single Express.js server, 11 HTML pages, and Storybook components.

# Create CONTRIBUTING.md in project root
# Must cover:
# 1. Project structure: server.js, public/*.html, Storybook
# 2. How to add new HTML pages
# 3. Express route conventions
# 4. Cookie auth mechanism
# 5. Deployment via Railway
Create CLAUDE.md for Agent Guidance Critical
Create a CLAUDE.md file that gives AI agents context about the project architecture, coding patterns, and key decisions.
Acceptance Criteria
  • CLAUDE.md exists in project root
  • Documents: project architecture (Express + static HTML + Storybook)
  • Documents: authentication flow (cookie-based, password: dino2026)
  • Documents: deployment process (Railway)
  • Documents: key files and their purposes
Agent Instructions ▶

Create a CLAUDE.md that gives AI coding agents immediate context about the project structure, tech stack, and key patterns so they can contribute effectively from the first prompt.

# Create CLAUDE.md in project root
# Cover: tech stack, file structure, auth mechanism,
# deployment, HTML page conventions, Storybook location
3
Testing Strategy
A comprehensive testing strategy is the single most critical requirement for agentic programming. Without tests, agents cannot verify their changes don't break existing functionality.
Key Gap: Zero tests of any kind — no unit tests, no integration tests, no E2E tests
Current State: 0 of 10 items exist 0%
peyepeye
ItemStatus
Unit testing framework ✗ Missing
Test runner configured ✗ Missing
Unit tests for server ✗ Missing
Integration tests ✗ Missing
E2E testing framework ✗ Missing
API endpoint tests ✗ Missing
HTML page smoke tests ✗ Missing
Test coverage reporting ✗ Missing
CI runs tests ✗ Missing
Test data/fixtures ✗ Missing
Install Jest and Set Up Test Runner Critical
Install a test framework (Jest or Vitest) and configure it for the Express.js server. This is the foundational step — nothing else works without a test runner.
Acceptance Criteria
  • Jest installed and configured
  • package.json has "test" and "test:coverage" scripts
  • A sample test passes for server.js routes
  • Coverage reporter configured
Agent Instructions ▶

Install the foundational test runner so the Express server can run tests. Without this, there is zero ability to verify any code change — this is the single biggest blocker to agentic programming.

npm install -D jest supertest
# Create jest.config.js
# Add to package.json scripts:
# "test": "jest",
# "test:coverage": "jest --coverage"
# Create first test: test/server.test.js
# const request = require('supertest');
# const app = require('./server');
# describe('GET /login', () => {
#   it('returns login page', async () => {
#     const res = await request(app).get('/login');
#     expect(res.status).toBe(200);
#   });
# });
Write API Endpoint Tests with Supertest Critical
Write integration tests for the Express routes using Supertest — covering authentication, static file serving, and cookie-based session handling.
Acceptance Criteria
  • Tests for login/auth endpoint (password validation, cookie setting)
  • Tests for protected routes (redirect when not authenticated)
  • Tests for all 11 HTML pages (200 status when authenticated)
  • Tests for static file serving
Agent Instructions ▶

Write integration tests for the Express server routes using Supertest. Cover the auth flow (cookie-based login with password dino2026), protected page access, and static file serving.

# Create test/routes.test.js:
# Test login with correct password returns cookie
# Test login with wrong password returns error
# Test protected pages redirect without cookie
# Test all 11 HTML pages return 200 with valid cookie
Add E2E Testing with Playwright High
Set up Playwright for end-to-end testing of the HTML pages, verifying they render correctly and interactive elements work.
Acceptance Criteria
  • Playwright installed and configured
  • Smoke tests for all 11 HTML pages
  • Login flow tested end-to-end
  • Visual snapshot tests for key pages
Agent Instructions ▶

Add Playwright E2E tests to verify the HTML pages render correctly in a browser and the login flow works end-to-end.

npm install -D @playwright/test
npx playwright install
# Create e2e/pages.spec.ts:
# Navigate to each HTML page, verify title and key elements
# Test login flow with password authentication
4
Linting & Code Quality
Consistent linting and formatting ensures AI agents produce code that matches existing style and catches errors before review.
Key Gap: No ESLint, no Prettier, no pre-commit hooks — zero code quality tooling
Current State: 0 of 8 items exist 0%
peyepeye
ItemStatus
ESLint configured ✗ Missing
Prettier configured ✗ Missing
Husky pre-commit hooks ✗ Missing
lint-staged ✗ Missing
TypeScript strict mode ✗ MissingNo TypeScript
Import sorting ✗ Missing
JSDoc enforcement ✗ Missing
HTML linting ✗ Missing
Configure ESLint + Prettier for Express Server High
Install and configure ESLint with Node.js/Express rules and Prettier for consistent code formatting across server.js and all JavaScript files.
Acceptance Criteria
  • ESLint installed with Node.js recommended rules
  • Prettier installed with .prettierrc configuration
  • eslint-plugin-security installed for security-focused rules
  • npm run lint passes without errors
  • All existing files formatted (one-time commit)
Agent Instructions ▶

Install ESLint and Prettier so the project has baseline code quality enforcement. This is essential for agents to produce consistent code.

npm install -D eslint prettier eslint-plugin-security eslint-config-prettier
# Create .eslintrc.js with Node.js rules
# Create .prettierrc
# Add to package.json: "lint": "eslint .",  "format": "prettier --write ."
# Run: npx eslint . --fix
Add Husky + lint-staged Pre-commit Hooks High
Install Husky and lint-staged to automatically run linting and formatting on every commit, preventing bad code from entering the codebase.
Acceptance Criteria
  • Husky installed with pre-commit hook
  • lint-staged runs eslint --fix and prettier --write on staged files
  • .prettierignore configured for node_modules
Agent Instructions ▶

Add pre-commit hooks so every commit is auto-formatted and linted. This prevents agents from committing code that doesn't match the project's style.

npm install -D husky lint-staged
npx husky init
# Add to package.json:
# "lint-staged": { "*.js": ["prettier --write", "eslint --fix"], "*.html": ["prettier --write"] }
# Create .husky/pre-commit: npx lint-staged
5
Git Branch Strategy & PR Workflow
A documented branching model and PR workflow enables AI agents to create branches, open PRs, and follow the correct merge process without human guidance.
Key Gap: No git repository at all — no branching, no commits, no history
Current State: 1 of 8 items exist 8%
peyepeye
ItemStatus
Git repository initialized ✗ Missing
.gitignore configured ✓ Existsnode_modules, .env, .DS_Store, storybook-static, logs
Branch naming convention ✗ Missing
PR template ✗ Missing
Branch protection rules ✗ Missing
Conventional commits ✗ Missing
Release tagging strategy ✗ Missing
Changelog generation ✗ Missing
Initialize Git Repository and Push to GitHub Critical
Initialize a git repository, create a .gitignore, make the initial commit, and push to GitHub. This is the most fundamental prerequisite for all other development workflows.
Acceptance Criteria
  • git init completed with initial commit
  • .gitignore configured (node_modules, .env, etc.)
  • Repository pushed to GitHub
  • Branch naming convention documented
  • PR template created (.github/PULL_REQUEST_TEMPLATE.md)
Agent Instructions ▶

Initialize a git repo so the project has version control. Without this, there is no way for agents to create branches, open PRs, or track changes.

git init
# Create .gitignore: node_modules/, .env, *.log
git add .
git commit -m "feat: initial commit"
# Create GitHub repo and push
# Create .github/PULL_REQUEST_TEMPLATE.md
Set Up Branch Protection and Conventional Commits High
Configure branch protection rules on main and enforce conventional commit messages for clean git history.
Acceptance Criteria
  • Branch protection on main (require PR, require CI to pass)
  • Conventional commits enforced via commitlint
  • Auto-delete branches after merge
  • Squash-and-merge as default merge strategy
Agent Instructions ▶

Set up branch protection and conventional commits so agents follow a structured workflow when contributing code.

npm install -D @commitlint/cli @commitlint/config-conventional
# Create commitlint.config.js
# Add Husky commit-msg hook
# Configure GitHub branch protection rules via Settings
6
CI/CD Pipeline
A robust CI/CD pipeline that runs tests, linting, and security checks on every PR gives agents immediate feedback on whether their changes are safe to merge.
Key Gap: Railway deployment exists but no CI/CD pipeline, no quality gates, no automated checks
Current State: 2 of 8 items exist 25%
peyepeye
ItemStatus
Hosting platform configured ✓ ExistsRailway, https://peyepeye-production.up.railway.app
Manual deployment working ✓ Existsrailway up command
GitHub Actions workflows ✗ Missing
Build verification in CI ✗ Missing
CI runs lint on PR ✗ Missing
CI runs tests on PR ✗ Missing
Preview deployments ✗ Missing
Automated deployment on merge ✗ Missing
Create GitHub Actions CI Workflow Critical
Create a GitHub Actions CI workflow that runs lint, tests, and build verification on every PR. This is the foundation for all quality gates.
Acceptance Criteria
  • .github/workflows/ci.yml triggers on all PRs to main
  • Steps: install, lint, test, build verification
  • Each step fails the PR if it doesn't pass
  • Status checks required before merge
Agent Instructions ▶

Create a CI workflow that blocks PRs unless lint and tests pass. This gives agents immediate feedback on code quality.

# Create .github/workflows/ci.yml:
name: CI Quality Gate
on:
  pull_request:
    branches: [main]
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 18, cache: npm }
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: node server.js & sleep 2 && curl -f http://localhost:3000/login
Set Up Automated Railway Deployment High
Configure Railway to automatically deploy on merge to main, replacing the manual `railway up` workflow.
Acceptance Criteria
  • Railway connected to GitHub repository
  • Auto-deploy on push to main branch
  • Preview environments for PRs (if available)
  • Health check endpoint verified post-deploy
Agent Instructions ▶

Connect Railway to the GitHub repo so deployments happen automatically on merge to main. This eliminates the manual railway up step.

# Connect Railway to GitHub repo:
# railway link --environment production
# Enable auto-deploy in Railway dashboard
# Configure health check endpoint
7
Security Audit
AI-generated code introduces unique security risks. Automated security scanning in the CI/CD pipeline catches vulnerabilities before they reach production.
Key Gap: Cookie-based auth with plaintext password, no SAST/DAST, no secret detection
Current State: 0 of 8 items exist 0%
peyepeye
ItemStatus
SAST scanning ✗ Missing
Dependency vulnerability scanning ✗ Missing
Secret detection ✗ Missing
Authentication audit ✗ MissingCookie auth with plaintext password
HTTPS enforcement ✗ Missing
OWASP Top 10 checklist ✗ Missing
Rate limiting ✗ Missing
Input validation ✗ Missing
Add SAST Scanning and Dependency Auditing Critical
Integrate static analysis security testing and dependency scanning into the CI pipeline to catch vulnerabilities in AI-generated code.
Acceptance Criteria
  • CodeQL or Semgrep configured
  • Scans run on every PR
  • npm audit runs in CI
  • Critical findings block PR merge
Agent Instructions ▶

Add automated static security scanning and dependency auditing so every PR gets checked for vulnerabilities. This is especially critical when AI agents generate code.

# Create .github/workflows/codeql.yml:
name: CodeQL Analysis
on:
  pull_request:
    branches: [main]
jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with: { languages: javascript }
      - uses: github/codeql-action/analyze@v3
# Also add: npm audit --production --audit-level=high
Harden Authentication and Add Secret Detection Critical
Replace plaintext password authentication with secure hashing, add secret detection to prevent credentials from being committed, and implement basic security hardening.
Acceptance Criteria
  • Password hashed (bcrypt) instead of plaintext comparison
  • gitleaks or git-secrets installed as pre-commit hook
  • Rate limiting on login endpoint
  • HTTPS enforced in production
  • SECURITY.md with responsible disclosure policy
Agent Instructions ▶

Replace the plaintext password check with bcrypt hashing, add rate limiting to the login endpoint, and install gitleaks to prevent secrets from being committed.

npm install bcrypt express-rate-limit helmet
# Hash password with bcrypt instead of plaintext comparison
# Add helmet() middleware for security headers
# Add rate limiting to /login endpoint
# Install gitleaks: brew install gitleaks
# Add pre-commit hook for secret detection
8
API Contract / Documentation
Documented API routes and contracts allow AI agents to understand every endpoint, its request/response shape, and authentication requirements — critical for generating correct server-side code.
Key Gap: API.md + Zod schemas provide full route and request/response documentation; still missing OpenAPI spec, API versioning, and rate limiting docs
Current State: 6 of 10 items exist 60%
peyepeye
ItemStatus
Express server running ✓ Exists
Static file serving configured ✓ Exists
Cookie-based auth endpoint ✓ Exists
OpenAPI / Swagger spec ✗ Missing
Route documentation ✓ ExistsFull route catalog with methods, auth, and responses in API.md
Request/response schemas ✓ ExistsZod schemas define all request/response types for 8 entities; documented in API.md
Error response format ✓ ExistsStandardized via Zod validate() middleware — VALIDATION_ERROR with structured issues array
API versioning ✗ Missing
Health check endpoint ✗ Missing
Rate limiting docs ✗ Missing
Document Express Routes and Add Health Check High
Document all Express routes in server.js and add a health check endpoint for monitoring.
Acceptance Criteria
  • All Express routes documented with JSDoc comments
  • GET /health endpoint returns server status
  • Authentication flow documented (login, cookie, logout)
  • Static file serving routes listed
Agent Instructions ▶

Document all Express routes in server.js so agents know every endpoint, its method, authentication requirements, and response. Add a health check for monitoring.

# Add JSDoc comments to each route in server.js
# Add GET /health endpoint:
# app.get('/health', (req, res) => res.json({ status: 'ok', uptime: process.uptime() }));
# Document: login POST, logout, static serving, protected routes
Add Swagger/OpenAPI Documentation Medium
Install swagger-ui-express to provide interactive API documentation at /api-docs.
Acceptance Criteria
  • swagger-ui-express installed and configured
  • All routes documented in OpenAPI 3.0 format
  • Authentication requirements documented per endpoint
  • /api-docs route serves Swagger UI
Agent Instructions ▶

Add Swagger UI so the Express server's routes are self-documenting and agents can reference the API contract directly.

npm install swagger-ui-express swagger-jsdoc
# Add swagger-jsdoc annotations to server.js routes
# Serve Swagger UI at /api-docs
9
Environment & Configuration
Proper environment configuration and setup documentation enables AI agents to understand the runtime context and helps new developers (human or AI) get started quickly.
Key Gap: .env.example exists; no Docker, no env validation, no health endpoint
Current State: 3 of 10 items exist 30%
peyepeye
ItemStatus
package.json exists ✓ ExistsDependencies and scripts defined
.env.example with all required variables ✓ ExistsPORT and SITE_PASSWORD documented
Local development setup guide ✓ ExistsREADME.md Quick Start section
Docker / docker-compose for local dev ✗ Missing
Environment variable validation ✗ MissingNo validation; PORT hardcoded to 3000
Node.js version documented ✗ MissingNo .nvmrc or engines field in package.json
PORT configuration via environment ✗ MissingHardcoded: app.listen(3000)
Production vs development config ✗ MissingNo NODE_ENV handling; same config everywhere
Secrets management ✗ MissingPassword "dino2026" hardcoded in server.js
Health monitoring endpoint ✗ MissingNo /health or /readiness route
Create .env and Environment Configuration High
Extract hardcoded values (PORT, password, cookie secret) into environment variables with a .env.example template.
Acceptance Criteria
  • .env.example exists in project root with all required variables
  • PORT read from process.env.PORT instead of hardcoded 3000
  • AUTH_PASSWORD read from environment instead of hardcoded "dino2026"
  • Cookie secret externalized to COOKIE_SECRET env var
  • .env is in .gitignore
  • dotenv package installed and loaded at startup
Agent Instructions ▶

Extract all hardcoded configuration from server.js into environment variables. The app currently hardcodes PORT (3000) and the auth password ("dino2026"). Without env vars, agents cannot configure the app for different environments.

# Install dotenv:
# npm install dotenv
# Create .env.example:
# PORT=3000
# AUTH_PASSWORD=your_password_here
# COOKIE_SECRET=your_cookie_secret_here
# NODE_ENV=development
#
# Update server.js:
# require('dotenv').config();
# const PORT = process.env.PORT || 3000;
# const AUTH_PASSWORD = process.env.AUTH_PASSWORD || 'dino2026';
# app.listen(PORT, () => console.log(`Server running on port ${PORT}`));
Add Health Check and Node.js Version Pinning Medium
Add a /health endpoint for Railway monitoring and pin the Node.js version with .nvmrc and engines field.
Acceptance Criteria
  • GET /health returns { status: "ok", uptime, version }
  • .nvmrc file specifies Node.js version (e.g., 20)
  • package.json engines field matches .nvmrc
  • Railway configured to use health check endpoint
  • NODE_ENV-aware configuration (dev vs production logging, error details)
Agent Instructions ▶

Add a health check endpoint and pin the Node.js version. Railway needs a health endpoint to monitor the service, and version pinning prevents "works on my machine" issues when agents or developers use different Node versions.

# Add to server.js:
# app.get('/health', (req, res) => {
#   res.json({
#     status: 'ok',
#     uptime: process.uptime(),
#     timestamp: new Date().toISOString(),
#     version: require('./package.json').version
#   });
# });
#
# Create .nvmrc:
# 20
#
# Add to package.json:
# "engines": { "node": ">=20.0.0" }
10
Data Flow & State Architecture
Documenting how data flows through the application — from user request to server route to HTML page — enables AI agents to add features without breaking navigation or authentication patterns.
Key Gap: Zod schemas define all 8 entities with validation; DATA-MODELS.md documents relationships, payment flows, and user journeys; still missing error handling flow docs
Current State: 6 of 10 items exist 75%
peyepeye
ItemStatus
System architecture diagrams ✓ ExistsReact Flow diagram in architecture.html
Data flow documentation ◐ PartialReact Flow diagrams exist but no written docs
API integration patterns ◐ PartialZod validate() middleware and /api/schemas validation endpoint; route patterns documented
Authentication flow documented ✓ ExistsAuth flow and session management documented in DATA-MODELS.md
Payment flow documented ✓ ExistsReact Flow payment flow diagram
Database schema docs ✓ Exists8 Zod entity schemas in schemas/ directory define all data models with validation rules
State management patterns ◐ PartialZod schemas define entity state shapes for all 8 data models; client-side state TBD
Error handling flow ✗ MissingNo error handling middleware or error pages
Investor/prospectus documentation ✓ Existsprospectus.html and investor-facing pages
Consumer journey documented ✓ ExistsUser journeys for diner, restaurant owner, and KDS documented in DATA-MODELS.md
Document Express Route Map and Auth Flow High
Create documentation mapping all Express routes, middleware chain, cookie-based authentication flow, and which pages are protected vs public.
Acceptance Criteria
  • docs/routes.md catalogs every Express route in server.js
  • Each route entry includes: method, path, middleware, response type
  • Authentication flow documented: login form → POST /login → cookie set → redirect
  • Protected vs public routes clearly identified
  • Static file serving pattern documented (public/ directory)
  • Error handling flow documented (what happens on 404, auth failure)
Agent Instructions ▶

Document the complete Express route map and authentication flow. The app uses cookie-based auth with a single password. Agents need to understand which routes exist, which are protected, and how the auth cookie works to add new pages or API endpoints correctly.

# Read server.js and document all routes:
# GET / → redirects to /login or /index.html based on auth
# POST /login → validates password, sets cookie, redirects
# GET /logout → clears cookie, redirects to /login
# Static: public/*.html served via express.static
#
# Auth flow:
# 1. User visits any page
# 2. Middleware checks for auth cookie
# 3. If no cookie → redirect to /login
# 4. POST /login with password "dino2026"
# 5. Cookie set → redirect to /index.html
Create Page Navigation Map and Error Handling Medium
Document the complete navigation structure across all 11 HTML pages and add proper error handling middleware.
Acceptance Criteria
  • docs/pages.md lists all 11 HTML pages with their purpose and navigation links
  • Page-to-page navigation paths documented (site map)
  • Custom 404 error page created
  • Express error-handling middleware added to server.js
  • Consumer journey documented for key user flows
Agent Instructions ▶

Map the navigation structure of all 11 HTML pages and add error handling. Currently there is no 404 page or error middleware — agents need to know the full page inventory and navigation paths to add new pages that integrate correctly.

# Inventory all pages in public/:
# index.html, prospectus.html, architecture.html,
# agentic-spec.html, etc.
# For each page, document:
# - Purpose/description
# - Navigation links to other pages
# - Whether it requires authentication
#
# Add error handling to server.js:
# app.use((req, res) => {
#   res.status(404).sendFile('public/404.html');
# });
# app.use((err, req, res, next) => {
#   console.error(err);
#   res.status(500).json({ error: 'Internal server error' });
# });

Implementation Roadmap

The roadmap spans 12 weeks in 3 phases, prioritized for a copilot-first approach. Phase 1 targets Tier 1 (Copilot Pair Programming) readiness by Week 4 — enabling Cursor, VS Code Copilot, and Claude Code in interactive mode. Phase 2 unlocks Tier 2 (Supervised Autonomous) by Week 8. Phase 3 targets full autonomy.

PeyePeye starts from a lower baseline than typical projects (no git, no tests, no linting), so Phase 1 focuses on foundational infrastructure that most projects already have. The Storybook component library (88 components) and React Flow diagrams provide a head start on documentation.

1
Copilot Ready
Tier 1: Copilot Pair Programming (35%)
Weeks 1–4
W1
W2
W3
W4
W5
W6
W7
W8
W9
W10
W11
W12
Git: Initialize repo + push to GitHub
W1
Linting: ESLint + Prettier for server.js + HTML
W1–W2
Environment: .env + dotenv + health check endpoint
W2–W3
Architecture: README + CONTRIBUTING.md + CLAUDE.md
W3–W4
Storybook: Integrate component library as NPM package
W3–W4
2
Supervised Autonomous
Tier 2: Supervised Autonomous (60%)
Weeks 5–8
W1
W2
W3
W4
W5
W6
W7
W8
W9
W10
W11
W12
Testing: Jest + Supertest for API routes
W5–W6
CI/CD: GitHub Actions (lint + test on PR)
W5–W6
Git Strategy: Branch protection + conventional commits
W5
API Contract: Document routes + Swagger/OpenAPI
W6–W7
Testing: Playwright E2E for auth + navigation
W7–W8
CI/CD: Automated Railway deployment on merge
W8
3
Fully Autonomous
Tier 3: Fully Autonomous (85%)
Weeks 9–12
W1
W2
W3
W4
W5
W6
W7
W8
W9
W10
W11
W12
Security: SAST + dependency scanning
W9–W10
Security: Harden auth + secret detection
W10–W11
Testing: 60%+ coverage target
W9–W10
Data Flow: Route map + page navigation docs
W10–W11
API Contract: Complete OpenAPI spec
W9–W11
Security: Pen testing + vulnerability review
W11–W12