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.
Executive Summary
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.
- ESLint + Prettier enforced 0%
- Git repository initialized 0%
- .env.example + dev setup docs 30%
- Component library documented 65%
- Autocomplete functions, props, types
- Generate boilerplate components & routes
- AI-assisted refactoring
- Auto-generate JSDoc/TSDoc
- Testing framework running 0%
- CI quality gates on PRs 0%
- Git workflow + branch protection 0%
- API docs / route documentation 55%
- Full feature branches (code + tests + PR)
- Auto-fix CI failures in feedback loops
- Generate Storybook stories
- Run and interpret E2E tests
- SAST + dependency scanning 0%
- 60%+ test coverage 0%
- State + data flow documented 40%
- Security audit completed 0%
- Auto-implement from issue backlog
- Auto-merge after CI + 1 approval
- Monitor errors & create fix PRs
- Nightly AI regression + triage
| Item | Status |
|---|---|
| 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 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
- 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 }}
- 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 }
| Item | Status |
|---|---|
| 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 |
- 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
- 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
| Item | Status |
|---|---|
| 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 |
- 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);
# });
# });
- 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
- 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
| Item | Status |
|---|---|
| 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 |
- 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
- 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
| Item | Status |
|---|---|
| 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 |
- 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
- 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
| Item | Status |
|---|---|
| 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 |
- .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
- 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
| Item | Status |
|---|---|
| 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 |
- 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
- 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
| Item | Status |
|---|---|
| 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 |
- 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
- 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
| Item | Status |
|---|---|
| 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 |
- .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}`));
- 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" }
| Item | Status |
|---|---|
| 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 |
- 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
- 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.