CODITECT WO System Website — Build Prompt Series

Classification: Internal — Implementation Guide
Date: 2026-02-13
Version: 1.0
Purpose: Sequential, self-contained prompts to build the full documentation/dashboard website
Deployment: Local (open access) + GCP Cloud Run (CODITECT-registered, NDA-gated)

Build Overview

Phase	Prompts	Scope	Estimated Time
Phase 0	P00–P02	Project scaffolding, config, CI/CD	2–3 hours
Phase 1	P03–P08	Core site: MDX rendering, navigation, all 31 markdown docs	4–6 hours
Phase 2	P09–P13	Interactive dashboards: all 25 JSX components embedded	4–6 hours
Phase 3	P14–P19	Auth, NDA workflow, CODITECT registration, role gating	6–8 hours
Phase 4	P20–P24	GCP deployment: Cloud Run, Cloud SQL, IAP, CDN	4–6 hours
Phase 5	P25–P28	Polish: search, analytics, PDF export, performance	3–4 hours
Phase 6	P29–P31	Living docs: CI/CD content pipeline, automated updates	2–3 hours

Total: 32 prompts · ~30 hours estimated build time

Phase 0: Project Foundation

P00: Project Scaffolding & Monorepo Structure

Context: CODITECT WO System documentation comprises 56 artifacts (31 markdown + 25 JSX dashboards) that must run as a Next.js 14+ App Router site. The site has two deployment targets: local (no auth, full access) and GCP Cloud Run (NDA-gated, role-filtered). All JSX dashboards are self-contained React components using Tailwind CSS core utilities and Lucide React icons.

Task: Create the complete Next.js project scaffold with the following structure:

coditect-wo-docs/
├── app/                          # Next.js App Router
│   ├── layout.tsx                # Root layout with nav + footer
│   ├── page.tsx                  # Landing page
│   ├── (public)/                 # Route group: no auth required
│   │   └── reference/            # Glossary, inventory
│   ├── (gated)/                  # Route group: auth required on GCP
│   │   ├── investors/
│   │   ├── engineers/
│   │   ├── compliance/
│   │   └── product/
│   └── (auth)/                   # Auth routes (GCP only)
│       ├── register/
│       ├── nda/
│       └── pending-approval/
├── content/
│   ├── docs/                     # All 31 .md files (01–31)
│   └── dashboards/               # All 25 .jsx files (32–56)
├── components/
│   ├── layout/                   # Nav, sidebar, footer, breadcrumbs
│   ├── content/                  # MDX renderer, TOC, related docs
│   ├── dashboard/                # Dashboard wrapper, loading states
│   └── auth/                     # NDA form, registration, gates
├── lib/
│   ├── content.ts                # Content loading, frontmatter parsing
│   ├── navigation.ts             # Nav tree, reading paths
│   ├── auth.ts                   # Auth helpers (no-op local, real on GCP)
│   └── config.ts                 # Environment-based config
├── config/
│   ├── navigation.json           # Full site navigation tree
│   ├── reading-paths.json        # Audience-specific document paths
│   ├── cross-references.json     # Document relationship graph
│   └── dashboards.json           # Dashboard metadata + category mapping
├── public/                       # Static assets
├── Dockerfile                    # Multi-stage build for Cloud Run
├── docker-compose.yml            # Local dev with optional Postgres
├── .env.example                  # Environment template
├── tailwind.config.ts
├── next.config.mjs               # MDX plugin config
└── package.json

Requirements:

next.config.mjs with MDX support (@next/mdx + remark-gfm + rehype-slug + rehype-highlight)
tailwind.config.ts covering all utility classes used across 25 JSX dashboards
package.json with all dependencies: next@14, react@18, @next/mdx, lucide-react@0.263.1, recharts, tailwindcss, @tailwindcss/typography
Environment-based auth mode: AUTH_MODE=none (local) vs AUTH_MODE=gcp (production)
docker-compose.yml for local dev (Next.js + optional Postgres for auth persistence)
Dockerfile multi-stage build optimized for Cloud Run (builder + runner, <200MB image)
TypeScript strict mode throughout

Expected Output: Complete project scaffold with all config files, ready for npm install && npm run dev.

CODITECT Value: Foundation for all subsequent prompts. Environment-based auth switching is the key architectural decision enabling dual-mode deployment.

P01: Configuration Data Files

Context: The website needs structured configuration data to drive navigation, reading paths, cross-references, and dashboard metadata. This data is derived from the 56-artifact inventory documented in 30-document-inventory.md.

Task: Generate 4 JSON configuration files:

navigation.json — Complete site navigation tree matching the URL structure from 31-website-plan.md. Each node: { path, label, icon?, docId?, dashboardId?, children? }. Include all 56 artifacts mapped to their correct routes.

reading-paths.json — Six audience reading paths from the document inventory:

{
  "investor": { "label": "Investor / Board", "time": "30 min", "steps": [1,2,3,8,9,10,44] },
  "technical_advisor": { ... },
  "compliance_officer": { ... },
  "product_manager": { ... },
  "engineer": { ... },
  "full": { ... }
}

cross-references.json — Document relationship graph. For each document ID (1–56), list related: number[] and supersedes?: number (e.g., doc 02 supersedes doc 01). Include the key metrics cross-reference table (TAM, SAM, SOM, ACV, etc.) with source document IDs.

dashboards.json — Metadata for all 25 JSX dashboards:

{
  "id": 34,
  "file": "34-wo-state-machine-visualizer.jsx",
  "title": "WO State Machine Visualizer",
  "description": "Interactive 9-state FSM with simulator, transition explorer, RBAC roles, and SOD rules",
  "category": "system_architecture",
  "audience": ["engineers", "compliance"],
  "sourceDocIds": [18, 19, 22],
  "route": "/engineers/dashboards/state-machine"
}

Expected Output: 4 complete JSON files with all 56 artifacts mapped.

CODITECT Value: Single source of truth for navigation, relationships, and metadata — prevents hardcoding across components.

P02: CI/CD Pipeline & Infrastructure as Code

Context: The website deploys to two targets: local development (no auth, docker compose up) and Google Cloud Run (NDA-gated, behind CODITECT registration). GCP deployment requires Cloud Run, Cloud SQL (PostgreSQL for user/NDA data), Cloud CDN, and Cloud Build.

Task: Create the complete CI/CD and infrastructure configuration:

cloudbuild.yaml — Google Cloud Build pipeline:
- Build Docker image
- Push to Artifact Registry
- Deploy to Cloud Run (staging on PR, production on main merge)
- Run Lighthouse CI on staging URL
- Notify on failure
terraform/main.tf — GCP infrastructure:
- Cloud Run service (min 0, max 10 instances, 512MB/1vCPU)
- Cloud SQL PostgreSQL 15 instance (db-f1-micro for auth data)
- Cloud CDN for static assets
- Secret Manager for env vars (DB credentials, auth secrets, NDA signing key)
- IAM service accounts with least-privilege
- Custom domain mapping
- VPC connector for Cloud Run → Cloud SQL
terraform/variables.tf — Parameterized: project ID, region, domain, DB tier
.github/workflows/deploy.yml — Alternative GitHub Actions workflow if not using Cloud Build:
- On push to main → build + deploy production
- On PR → build + deploy preview + comment URL

Makefile — Developer commands:

dev:        # npm run dev (local, no auth)
dev-auth:   # docker compose up (local with Postgres + auth)
build:      # next build
deploy-staging:   # gcloud run deploy --tag staging
deploy-prod:      # gcloud run deploy
db-migrate:       # prisma migrate deploy
db-seed:          # seed NDA template + admin user

Requirements:

Cloud Run must serve on custom domain with managed SSL
Cloud SQL connection via Unix socket (Cloud SQL Auth Proxy in sidecar)
All secrets in Secret Manager, never in env files
Preview deployments for content PRs (Cloud Run revisions with traffic tags)
Rollback capability via Cloud Run revision management

Expected Output: Complete IaC + CI/CD configuration files.

CODITECT Value: Production-grade GCP deployment with preview environments for content review before publish.

Phase 1: Core Documentation Site

Context: The website serves 4 distinct audiences (investors, engineers, compliance, product) with role-specific navigation paths. The layout must work on desktop (sidebar + content), tablet (collapsible sidebar), and mobile (bottom nav + hamburger). Navigation data comes from navigation.json.

Task: Build the root layout and navigation components:

app/layout.tsx — Root layout with:
- <html> with light-mode-only theme (no dark mode)
- Font loading: IBM Plex Sans (matches dashboard typography)
- Global Tailwind styles
- <NavShell> wrapping {children}
components/layout/NavShell.tsx — Responsive navigation shell:
- Desktop (≥1024px): Fixed left sidebar (240px) with collapsible sections, sticky header with search + auth
- Tablet (768–1023px): Collapsible sidebar (hamburger trigger), full-width content
- Mobile (<768px): Bottom tab bar (Home, Investors, Engineers, Compliance, More), hamburger for full nav
- Active route highlighting with smooth transitions
- Audience selector: 4 color-coded audience badges at top of sidebar
- Reading progress indicator (scroll-based) on document pages
components/layout/Breadcrumbs.tsx — Auto-generated from route path using navigation.json
components/layout/Footer.tsx — Company info, document inventory link, "Confidential — CODITECT" notice, version/date
components/layout/TableOfContents.tsx — Auto-extracted from MDX headings, sticky on right side (desktop), collapsible (mobile)

Design System:

Background: #FFFFFF content, #F8FAFC sidebar, #F1F5F9 page background
Text: #111827 primary, #374151 secondary — NEVER light gray on white
Accent colors per audience: Investors #2563eb, Engineers #059669, Compliance #7c3aed, Product #d97706
Typography: IBM Plex Sans, 16px body, prose class for MDX content
All interactive elements: focus-visible:ring-2 focus-visible:ring-blue-500

Expected Output: Complete layout system rendering navigation from JSON config.

CODITECT Value: Role-specific navigation is a key differentiator — investors see business docs first, engineers see architecture first.

P04: MDX Content Pipeline & Document Renderer

Context: 31 markdown artifacts (docs 01–31) must render as documentation pages with frontmatter metadata, auto-generated TOC, syntax-highlighted code blocks, and cross-reference links. Content lives in /content/docs/ as .md files.

Task: Build the content rendering pipeline:

lib/content.ts — Content utilities:
- getAllDocs() — Scan /content/docs/, parse frontmatter, return sorted list
- getDocBySlug(slug) — Load single document with parsed content
- getRelatedDocs(docId) — Look up cross-references.json for related documents
- getReadingPath(audience) — Return ordered document list for audience
- Frontmatter schema: { id, title, category, classification, date, version, readTime, audience[], related[] }
components/content/MDXRenderer.tsx — MDX rendering with:
- @tailwindcss/typography prose styling
- Syntax highlighting for code blocks (Python, TypeScript, SQL, YAML, JSON, Mermaid)
- Custom components: <Callout type="warning|info|critical">, <MetricCard>, <ComplianceTag>
- Auto-link headings for deep linking
- Table rendering with horizontal scroll on mobile
- Mermaid diagram rendering (client-side via mermaid library)
components/content/DocumentPage.tsx — Standard document page template:
- Breadcrumbs
- Title + metadata bar (doc number, version, date, classification, read time)
- Auto-generated Table of Contents (right sidebar on desktop)
- Rendered MDX content
- Related documents section (cards with title, category, read time)
- Previous / Next navigation within category
- "Last updated" + "Edit on GitHub" link
app/(gated)/[audience]/[...slug]/page.tsx — Dynamic catch-all route that:
- Maps URL to document based on navigation.json
- Renders document through DocumentPage component
- Handles 404 for unknown routes

Add frontmatter headers to all 31 markdown files — Generate a script that adds YAML frontmatter to each existing .md file:

---
id: 12
title: "System Design Document"
category: "Architecture & Design"
classification: "Internal — Technical"
date: "2026-02-13"
version: "2.0"
readTime: "12 min"
audience: ["engineers", "compliance"]
related: [13, 14, 15, 16]
---

Expected Output: Working document renderer that serves all 31 markdown artifacts as navigable pages.

CODITECT Value: All existing content renders without modification. Frontmatter enables programmatic navigation and cross-referencing.

P05: Landing Page

Context: The landing page is the first touchpoint for all audiences. It must immediately communicate CODITECT's value proposition, direct visitors to their relevant content path, and demonstrate technical sophistication through an embedded interactive dashboard.

Task: Build app/page.tsx with:

Hero Section:
- Headline: "Autonomous Change Control for Regulated Industries"
- Subhead: "The first AI platform where agents execute compliant work orders — with human approval gates built in, not bolted on."
- Three metric cards: "$3.5B Market" · "70–80% Faster Cycles" · "60% Token Savings"
- Three CTA buttons (color-coded by audience): "For Investors →" | "For Engineers →" | "For Compliance →"
- Subtle animated gradient background (blues/greens, no purple)
Problem/Solution Grid (2×3):
- Pain cards (red-tinted): Manual change control 15–45 days, CSV burden 120–400 hours, AI locked out of GxP
- Solution cards (green-tinted): 9-state FSM with guards, 7 AI agents with checkpoints, Part 11 e-signatures native
Interactive Demo Section:
- Embedded WO State Machine Visualizer (dashboard 34), dynamically imported (ssr: false)
- "Try the simulator →" CTA that opens directly on the Simulator tab
- Fallback loading skeleton while dashboard hydrates
Credibility Section:
- Google AI Accelerator badge
- Regulatory framework logos (FDA, HIPAA, SOC 2) — use styled text badges, not images
- Architecture stats: "20+ entities · 9 states · 7 agents · 235+ glossary terms · 56 artifacts"
Audience Quick-Nav:
- Four cards, one per audience, showing reading path summary and estimated time
- Card click navigates to audience hub page

Design Constraints:

No dark mode. White/light gray backgrounds only.
No emojis in production text (OK in card labels).
Animations: subtle, CSS-only, prefers-reduced-motion respected.
Performance: LCP < 2.5s (defer dashboard load, preload hero fonts).

Expected Output: Complete landing page with embedded dashboard and audience routing.

CODITECT Value: The embedded simulator on the landing page is a key conversion hook — visitors interact with the product architecture immediately.

P06: Audience Hub Pages (4 pages)

Context: Each audience (Investors, Engineers, Compliance, Product) has a hub page that serves as the entry point to their content path. Hub pages follow a consistent template but with audience-specific messaging and featured dashboards.

Task: Build 4 hub pages using a shared template component:

components/content/HubPage.tsx — Shared hub page template:
- Role-specific hero with headline, 2–3 key metrics, and accent color
- Quick-nav card grid (3–4 cards) linking to sub-sections
- Featured interactive dashboard (dynamically imported)
- Reading path with time estimate and progress tracking
- Key takeaways (3–5 bullet callouts)
Investor Hub (app/(gated)/investors/page.tsx):
- Hero: "Investment-Grade Architecture for a $3.5B Market"
- Metrics: LTV:CAC 18.7× · 78% Gross Margin · 7-Month Payback
- Cards: Executive Summary → Market Opportunity → Business Case → Revenue Model
- Featured dashboard: Executive Decision Brief (44)
- Reading path: 01→02→03→08→09→10→44 (30 min)
- Key narrative from website-plan §3.2
Engineer Hub (app/(gated)/engineers/page.tsx):
- Hero: "Production-Grade Architecture, Open to Extension"
- Metrics: 20+ Entities · 9 States · 7 Agent Nodes · 60% Token Savings
- Cards: Quick Start → Architecture (C4) → Agent Orchestration → TDD + ADRs
- Featured dashboard: WO Unified System Dashboard (33)
- Reading path: 01→04→05→06→13→14→28→29→30→44 (3 hr)
Compliance Hub (app/(gated)/compliance/page.tsx):
- Hero: "Every Transition Maps to FDA, HIPAA, and SOC 2"
- Metrics: 35 Requirements · 93% Audit Ready · 6 SOD Rules · 3 Enforcement Layers
- Cards: FDA Part 11 → HIPAA → SOC 2 → RBAC & SOD → E-Signatures
- Featured dashboard: Comprehensive Compliance Dashboard (40)
- Reading path: 01→19→20→21→22→23→24→25 (1.5 hr)
Product Hub (app/(gated)/product/page.tsx):
- Hero: "From Mid-Tier Biotech to Top-50 Pharma"
- Metrics: Phase 1 $8–15K/mo · Phase 2 $15–40K/mo · Phase 3 $40–150K/mo
- Cards: Roadmap → CODITECT Integration → Competitive Landscape → Strategic Fit
- Featured dashboard: Strategic Fit Dashboard (45)

Expected Output: 4 hub pages + shared template component, each with embedded dashboard.

CODITECT Value: Audience-first information architecture — visitors never see content irrelevant to their role.

P07: Document Sub-Pages & Category Indexes

Context: Within each audience hub, there are 4–8 document sub-pages and category index pages. Category indexes show a filtered list of documents within that topic area.

Task: Build the document routing and category index system:

Category index pages — For routes like /engineers/architecture/:
- List all documents in that category with title, description, read time
- Show which documents the visitor has already viewed (client-side state)
- Sort by reading path order
- Link to relevant dashboards in that category
Document pages — For routes like /engineers/architecture/c4:
- Render document 14 (c4-architecture.md) through the DocumentPage component
- Inline related dashboard link: "See this architecture in the interactive C4 dashboard →"
- Previous/Next within category

Route mapping — Create the route mapping from URL slugs to document IDs:

/investors/executive-summary     → 01 + 02 (tabbed: original + updated)
/investors/market-opportunity    → 05 + 06 + 07 (tabbed or sequential)
/engineers/architecture/c4       → 14
/engineers/architecture/state-machine → 18 + 19 (original + guards)
/compliance/fda-part-11          → filtered view of 20 + 22

Handle multi-document pages where several artifacts cover the same topic.

Multi-document pages — When multiple artifacts cover one topic:
- Tabbed view: "Original | Enhanced" for docs 01/02
- Sequential view: "Overview → Deep Dive → TAM/SAM/SOM" for docs 05/06/07
- Filtered view: extract FDA-specific sections from docs 20/22 for /compliance/fda-part-11

Expected Output: All document routes working, category indexes listing documents, multi-document pages handled.

CODITECT Value: Clean URL structure makes every document shareable and linkable from pitch decks, emails, and Slack.

P08: Glossary & Reference Pages

Context: The glossary contains 235+ terms (doc 29) and the document inventory (doc 30) serves as a master index. These reference pages need search, filtering, and cross-linking capabilities beyond basic markdown rendering.

Task: Build specialized reference pages:

app/(public)/reference/glossary/page.tsx — Interactive glossary:
- Load and parse 29-glossary.md table into structured data
- Alphabet quick-nav (A–Z sticky bar at top)
- Real-time search/filter (term, definition, CODITECT equivalent, ecosystem analogs)
- Click-to-expand: show full definition + related terms
- Deep-link support: /reference/glossary#rbac scrolls to and highlights RBAC
- Count display: "235 terms · Showing 12 matching 'compliance'"
- Export: "Copy as JSON" for programmatic use
app/(public)/reference/inventory/page.tsx — Interactive document inventory:
- Load and parse 30-document-inventory.md into structured data
- Category filters (7 categories as toggle chips)
- Format filters (Markdown, JSX Dashboard)
- Audience filters (Investor, Engineer, Compliance, Product)
- Each document links to its rendered page
- Reading path selector: choose audience → see highlighted path with "Start reading →"
- Progress tracking (client-side): checkmark documents the visitor has viewed
app/(public)/reference/metrics/page.tsx — Key metrics cross-reference:
- Extract metrics table from doc 30 (TAM, SAM, SOM, ACV, etc.)
- Each metric links to all source documents
- Sortable by metric name, value, or source count
- Visual: bar chart of key financial metrics (recharts)

Expected Output: Three interactive reference pages with search, filtering, and cross-linking.

CODITECT Value: Glossary search and metric cross-referencing are high-value features for due diligence — investors and compliance officers use these heavily.

Phase 2: Interactive Dashboards

P09: Dashboard Wrapper & Dynamic Import System

Context: 25 JSX dashboards (docs 32–56) are self-contained React components with default exports. They use Tailwind CSS core utilities and Lucide React icons. Each needs to be dynamically imported (no SSR) and wrapped in a consistent container with metadata, loading states, and source document links.

Task: Build the dashboard embedding infrastructure:

components/dashboard/DashboardWrapper.tsx — Standard wrapper:
- Breadcrumb path
- Title + description (from dashboards.json)
- "Source data" links to underlying markdown documents
- Loading skeleton (animated pulse) while component hydrates
- Error boundary with graceful fallback ("Dashboard failed to load — try refreshing")
- Full-width container (max-w-7xl mx-auto) — dashboards already have max-w-6xl internally
- Print-friendly mode: button to hide nav and render dashboard full-screen

components/dashboard/DashboardLoader.tsx — Dynamic import wrapper:

// Maps dashboard ID to dynamic import
const DASHBOARD_MAP = {
  32: () => import('@/content/dashboards/32-tech-architecture-analyzer'),
  33: () => import('@/content/dashboards/33-wo-unified-system-dashboard'),
  // ... all 25
};

Lazy load with React.lazy + Suspense
Preload on hover (prefetch module when user hovers nav link)
Error boundary per dashboard (one crash doesn't take down the page)

components/dashboard/DashboardGallery.tsx — Gallery view for hub pages:
- Grid of dashboard cards (2×2 or 3×2) with title, description, category badge
- Thumbnail preview (screenshot or icon-based placeholder)
- Click navigates to full dashboard page
- Filter by category within the gallery
Dashboard route handler — app/(gated)/[audience]/dashboards/[slug]/page.tsx:
- Map slug to dashboard ID via dashboards.json
- Render through DashboardWrapper
- Pass searchParams for deep-linking to specific tabs (e.g., ?tab=simulator)

Requirements:

Zero SSR for dashboards — all ssr: false or React.lazy
Each dashboard < 150KB gzipped (they're already lightweight)
Loading skeleton must match dashboard aspect ratio
Error boundary must not block other page content

Expected Output: Dashboard infrastructure that can render any of the 25 JSX components via URL.

CODITECT Value: Dynamic import system means dashboard code only loads when visited — critical for landing page performance.

P10: System & Architecture Dashboards (8 dashboards)

Context: Category 7A contains 8 system/architecture dashboards that serve primarily engineers and technical advisors. These must be integrated into the /engineers/dashboards/ routes.

Task: Create dashboard pages for:

#	Dashboard	Route	Source Docs
32	Tech Architecture Analyzer	`/engineers/dashboards/architecture`	12, 13, 14
33	WO Unified System Dashboard	`/engineers/dashboards/system`	12, 16, 18, 25
34	WO State Machine Visualizer	`/engineers/dashboards/state-machine`	18, 19, 22
35	WO Data Model Explorer	`/engineers/dashboards/data-model`	16
36	Data Model ERD Explorer	`/engineers/dashboards/erd`	16
37	WO Lifecycle Simulator	`/engineers/dashboards/lifecycle`	18, 19
38	WO Ecosystem Map	`/engineers/dashboards/ecosystem`	12, 27
39	Agent Orchestration Visualizer	`/engineers/dashboards/agents`	24, 25, 26

For each dashboard page:

Create the route file using the DashboardWrapper
Write a 2–3 sentence description for the metadata bar
Map source document links
Add "Related dashboards" sidebar showing other dashboards in this category
Support tab deep-linking via URL params where applicable (e.g., ?tab=simulator for 34)

Additionally:

Create /engineers/dashboards/page.tsx — gallery index showing all 8 dashboards
Add dashboard cards to the Engineer hub page

Expected Output: 8 dashboard pages + gallery index, all accessible from navigation.

CODITECT Value: Engineers can explore the full system architecture interactively — state machine, data model, agent graph — without reading a single document.

P11: Compliance Dashboards (4 dashboards)

Context: Category 7B contains 4 compliance dashboards targeting compliance officers and auditors. These map to /compliance/dashboards/ routes.

Task: Create dashboard pages for:

#	Dashboard	Route	Source Docs
40	Comprehensive Compliance Dashboard	`/compliance/dashboards/comprehensive`	20, 21, 22
41	Regulatory Compliance Tracker	`/compliance/dashboards/tracker`	20
42	Compliance Value Chain	`/compliance/dashboards/value-chain`	10, 20, 27
43	Compliance ROI Calculator	`/compliance/dashboards/roi`	10

For each dashboard page:

Route file with DashboardWrapper
Compliance-specific metadata: applicable regulations (FDA/HIPAA/SOC2) as badge chips
Source document links
"Export audit evidence" placeholder button (future: PDF export of dashboard state)

Additionally:

Create /compliance/dashboards/page.tsx — gallery index
Add "Audit Readiness Score: 93%" callout to Compliance hub page
The comprehensive dashboard (40) should also be embeddable on the landing page as an alternative to the state machine visualizer

Expected Output: 4 compliance dashboard pages + gallery index.

CODITECT Value: Compliance dashboards are the highest-value conversion tool for pharma/biotech prospects — auditors interact with these during due diligence.

P12: Business & Market Dashboards (8 dashboards)

Context: Category 7C contains 8 business/market dashboards for investors and product managers. These map to /investors/dashboards/ and cross-link to /product/dashboards/.

Task: Create dashboard pages for:

#	Dashboard	Route	Source Docs
44	Executive Decision Brief	`/investors/dashboards/executive`	01, 02, 03
45	Strategic Fit Dashboard	`/product/dashboards/strategic-fit`	12, 27
46	Market Opportunity Dashboard	`/investors/dashboards/market`	05, 06, 07
47	Market Impact Analyzer	`/investors/dashboards/impact`	06, 10
48	TAM/SAM/SOM Visualizer	`/investors/dashboards/tam-sam-som`	07
49	Revenue Model Dashboard	`/investors/dashboards/revenue`	09, 10
50	Investor Pitch Dashboard	`/investors/dashboards/pitch`	04
51	Business Case Calculator	`/investors/dashboards/calculator`	03, 10

Additionally:

Gallery indexes for both /investors/dashboards/ and /product/dashboards/
Cross-audience linking: Strategic Fit (45) appears in both Product and Investor navigation
Revenue Model (49) and Business Case Calculator (51) should have a "Share with investor" button (copies URL)

Expected Output: 8 business dashboard pages + 2 gallery indexes.

CODITECT Value: Interactive financial dashboards (revenue model, ROI calculator) are rare in pre-seed pitches — strong differentiation.

P13: Planning & Operations Dashboards (5 dashboards)

Context: Category 7D contains 5 planning/operations dashboards. These distribute across /product/dashboards/ and /engineers/dashboards/.

Task: Create dashboard pages for:

#	Dashboard	Route	Source Docs
52	CODITECT Impact Dashboard	`/product/dashboards/impact`	27
53	CODITECT Integration Playbook	`/product/dashboards/integration`	27, 12
54	Competitive Comparison	`/product/dashboards/comparison`	08
55	Implementation Planner	`/engineers/dashboards/planner`	13
56	Product Roadmap Visualizer	`/product/dashboards/roadmap`	11

Additionally:

Complete the Product hub's dashboard gallery
Add Implementation Planner (55) to Engineer hub's gallery
Competitive Comparison (54) should also be accessible from Investor navigation

Expected Output: 5 dashboard pages, completing all 25 dashboards across the site.

CODITECT Value: Full 56-artifact coverage — every document and dashboard is accessible and navigable.

Phase 3: Authentication & NDA Gating

P14: Auth Architecture — Dual-Mode Design

Context: The site runs in two modes controlled by AUTH_MODE environment variable:

none (local): No auth. All routes accessible. Auth components render nothing.
gcp (production): Full auth with CODITECT registration, NDA signing, and admin approval required before accessing gated content.

Task: Design and implement the auth abstraction layer:

lib/auth.ts — Auth provider abstraction:

export interface AuthUser {
  id: string;
  email: string;
  name: string;
  company: string;
  role: 'investor' | 'engineer' | 'compliance' | 'product' | 'admin';
  ndaSigned: boolean;
  ndaSignedAt?: Date;
  approved: boolean;
  approvedBy?: string;
  approvedAt?: Date;
}

export interface AuthProvider {
  getUser(): Promise<AuthUser | null>;
  isAuthenticated(): Promise<boolean>;
  isApproved(): Promise<boolean>;
  requireAuth(redirect?: string): Promise<AuthUser>;
}

lib/auth-none.ts — No-op provider (local mode):
- All methods return approved user with full access
- Auth gates are invisible pass-throughs
lib/auth-gcp.ts — Real provider (GCP mode):
- NextAuth.js with Google OAuth + email/password
- Session stored in Cloud SQL (PostgreSQL)
- User status flow: registered → nda_pending → nda_signed → approved → active
- Admin endpoints for approval/rejection

components/auth/AuthGate.tsx — Conditional wrapper:

// In AUTH_MODE=none: renders children immediately
// In AUTH_MODE=gcp: checks auth status, redirects if needed
<AuthGate requiredStatus="approved">
  {children}
</AuthGate>

Middleware — middleware.ts:
- AUTH_MODE=none: pass all requests through
- AUTH_MODE=gcp: check session for /investors/*, /engineers/*, /compliance/*, /product/*
- Public routes (always accessible): /, /reference/*, /register, /nda, /pending-approval

Expected Output: Complete auth abstraction that can be toggled via environment variable with zero code changes.

CODITECT Value: Dual-mode deployment means the same codebase serves local demo and production NDA-gated site.

P15: Registration Flow

Context: On GCP deployment, new users must register with CODITECT before accessing any gated content. Registration collects identity and company information needed for NDA generation.

Task: Build the registration system:

app/(auth)/register/page.tsx — Registration form:
- Fields: Full name, email, company name, company type (dropdown: Pharma, Biotech, MedDev, CRO, Financial Services, Technology, VC/PE, Other), title/role, interest area (multi-select: Investment, Technical Evaluation, Compliance Review, Partnership)
- Google OAuth option ("Register with Google") pre-fills name + email
- Email verification (send code, verify before proceeding)
- Terms of service checkbox
- Submit → redirect to NDA page

Database schema (Prisma):

model User {
  id            String    @id @default(cuid())
  email         String    @unique
  name          String
  company       String
  companyType   String
  title         String
  interestAreas String[]
  status        UserStatus @default(REGISTERED)
  ndaSignedAt   DateTime?
  ndaVersion    String?
  approvedAt    DateTime?
  approvedBy    String?
  rejectedAt    DateTime?
  rejectedReason String?
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt
  sessions      Session[]
  auditTrail    AuditEntry[]
}

enum UserStatus {
  REGISTERED
  NDA_PENDING
  NDA_SIGNED
  APPROVED
  REJECTED
  SUSPENDED
}

Audit trail — Every status change logged:

model AuditEntry {
  id        String   @id @default(cuid())
  userId    String
  action    String   // REGISTERED, NDA_SIGNED, APPROVED, REJECTED, etc.
  details   Json?
  ipAddress String?
  userAgent String?
  createdAt DateTime @default(now())
  user      User     @relation(fields: [userId], references: [id])
}

Email notifications:
- User: "Registration received — please sign the NDA to continue"
- Admin (CODITECT team): "New registration: [name] from [company] — [interest]"

Expected Output: Complete registration flow with database persistence and email notifications.

CODITECT Value: Registration data feeds sales pipeline — every visitor is a qualified lead with company, role, and interest area captured.

P16: NDA Signing Flow

Context: After registration, users must sign a Non-Disclosure Agreement before accessing any confidential content. The NDA is presented as an e-signature flow within the website — no external DocuSign/HelloSign dependency.

Task: Build the NDA signing system:

app/(auth)/nda/page.tsx — NDA presentation and signing page:
- NDA document rendered as formatted HTML (stored in database as versioned template)
- Scrollable document viewer with "I have read the entire document" enforcement (must scroll to bottom)
- Signing section at bottom:
  - Type-to-sign: full legal name (must match registration name)
  - Date/time auto-populated (UTC)
  - IP address captured
  - User agent captured
  - Check: "I agree to the terms of this Non-Disclosure Agreement"
  - "Sign & Submit" button (disabled until all fields complete)
- After signing → redirect to pending approval page

NDA template system:

model NDATemplate {
  id        String   @id @default(cuid())
  version   String   @unique // "1.0", "1.1", etc.
  title     String
  content   String   // HTML content of the NDA
  active    Boolean  @default(false)
  createdAt DateTime @default(now())
  createdBy String
}

model NDASignature {
  id            String   @id @default(cuid())
  userId        String
  templateId    String
  signedName    String
  signedAt      DateTime @default(now())
  ipAddress     String
  userAgent     String
  signatureHash String   // SHA-256(userId + templateId + signedName + signedAt)
  user          User     @relation(fields: [userId], references: [id])
  template      NDATemplate @relation(fields: [templateId], references: [id])
}

NDA content — Draft a standard mutual NDA template:
- Parties: CODITECT (AZ1.AI Inc.) and the Recipient
- Confidential information definition (covers all 56 artifacts, architecture, business data)
- Obligations: non-disclosure, limited use (evaluation only), return/destroy on request
- Exclusions: public info, prior knowledge, independently developed, legally required
- Term: 2 years from signing date
- Governing law: State of Florida
- Electronic signature acknowledgment (valid under ESIGN Act + UETA)
- Rendered in clean HTML with CODITECT branding
Signature verification:
- SHA-256 hash of signing data stored for integrity verification
- Admin can view signed NDA with all metadata
- PDF export of signed NDA (sent to both user and admin)

Expected Output: Complete NDA signing flow with versioned templates, e-signature capture, and audit trail.

CODITECT Value: Self-service NDA removes friction from the evaluation process — no back-and-forth with legal teams for standard NDAs.

P17: Approval Workflow & Admin Panel

Context: After NDA signing, a CODITECT admin must approve the user before they gain access to gated content. This prevents unauthorized access even with a signed NDA.

Task: Build the approval system:

app/(auth)/pending-approval/page.tsx — Waiting room:
- "Your NDA has been received. A CODITECT team member will review your access request."
- Status indicator: NDA Signed ✓ → Pending Review ⏳ → Approved/Rejected
- Estimated review time: "Typically within 24 hours"
- Contact: "Questions? Email access@coditect.ai"
- Auto-poll status every 30 seconds (or use WebSocket)
- On approval → auto-redirect to audience hub based on interest area
app/(auth)/admin/page.tsx — Admin approval dashboard:
- Protected route (requires role: admin)
- Pending approvals queue with:
  - Name, company, company type, title, interest areas
  - Registration date, NDA signed date
  - "Approve" and "Reject" buttons
  - Reject requires reason text
- Approved users list with:
  - Last login, pages viewed, dashboards accessed
  - "Suspend" and "Revoke" actions
- Statistics: total registered, pending, approved, rejected, active in last 7 days
Approval notifications:
- On approval: email user with "Access granted — click here to explore"
- On rejection: email user with reason and "Contact us if you believe this is an error"
- Daily digest to admin: new registrations, pending approvals, engagement stats
Auto-approval rules (configurable):
- Auto-approve if email domain matches whitelist (e.g., @google.com for accelerator)
- Auto-approve if referred by existing approved user
- Always manual for: VC/PE company type, competitor domains (configurable blacklist)

Expected Output: Approval workflow with admin panel, notifications, and auto-approval rules.

CODITECT Value: Manual approval ensures only qualified evaluators see confidential architecture and financial data. Auto-approval for trusted domains reduces friction for accelerator partners.

P18: Role-Based Content Filtering

Context: Approved users have a primary role (investor, engineer, compliance, product) that determines their default view. However, users should be able to access cross-role content when explicitly navigated.

Task: Implement role-based content presentation:

Default view: User's primary role determines:
- Which hub page they land on after login
- Navigation sidebar order (their section first)
- Featured dashboards and reading path
- "Recommended for you" content cards
Cross-role access: Users can navigate to any section:
- Non-primary sections show a subtle banner: "You're viewing engineering content as an investor"
- All content accessible — roles affect presentation, not access (access is binary: approved or not)
Personalized elements:
- "Continue reading" — resume from last viewed document
- "Your reading path" — progress bar through audience-specific path
- "Recently viewed" — last 5 documents/dashboards visited
- All stored in client-side state (local mode) or database (GCP mode)
Content classification indicators:
- Every page shows classification badge: "Internal — Technical", "Internal — Business", "Internal — Strategy"
- Dashboards show audience badges: "Investors", "Engineers", etc.
- Cross-reference count: "Referenced by 4 other documents"

Expected Output: Role-based content filtering that personalizes without restricting.

CODITECT Value: Role-based personalization reduces cognitive load — each visitor sees the most relevant content first while retaining full access.

P19: Session Management & Security Hardening

Context: GCP deployment handles confidential business and technical data. Session management must be secure, and the site must prevent common web security vulnerabilities.

Task: Implement security hardening:

Session management:
- JWT tokens with 1-hour expiry, refresh token with 7-day expiry
- Secure, HttpOnly, SameSite=Strict cookies
- Session invalidation on: password change, admin suspension, NDA revocation
- Concurrent session limit: 3 devices per user
- Session activity logging: login, logout, page views (for audit)
Security headers (Next.js headers() in next.config.mjs):
- Content-Security-Policy: strict, allow self + CDN for fonts/icons
- X-Frame-Options: DENY — prevent embedding
- X-Content-Type-Options: nosniff
- Strict-Transport-Security: max-age=31536000; includeSubDomains
- Referrer-Policy: strict-origin-when-cross-origin
- Permissions-Policy: camera=(), microphone=(), geolocation=()
Rate limiting:
- Registration: 3 per IP per hour
- Login: 5 attempts per account per 15 minutes, then lockout
- API routes: 100 requests per minute per session
Content protection:
- Right-click disable on dashboard pages (deterrent, not prevention)
- Watermark overlay on PDF exports: "Confidential — [User Name] — [Date]"
- Copy event logging: track if user copies content (for awareness, not blocking)
- No caching of gated pages: Cache-Control: no-store, must-revalidate
Audit logging:
- All auth events: login, logout, registration, NDA sign, approval
- All content access: document views, dashboard interactions
- All admin actions: approve, reject, suspend, revoke
- Stored in Cloud SQL with 2-year retention

Expected Output: Security-hardened session management with audit logging.

CODITECT Value: Enterprise-grade security is table stakes for regulated industry prospects — they will audit the documentation site itself.

Phase 4: GCP Deployment

P20: Cloud Run Deployment Configuration

Context: The production site runs on Google Cloud Run with auto-scaling, custom domain, and managed SSL. The Docker image must be optimized for cold start performance.

Task: Create the complete Cloud Run deployment:

Optimized Dockerfile:
- Multi-stage build: node:20-alpine builder → node:20-alpine runner
- Pre-build: copy package.json + lockfile → npm ci --production=false → build → prune dev deps
- Final image < 200MB
- NEXT_TELEMETRY_DISABLED=1
- Non-root user (nextjs:nodejs)
- Healthcheck endpoint: /api/health
Cloud Run service config:
- Min instances: 1 (avoid cold starts for demo scenarios)
- Max instances: 10
- Memory: 512MB
- CPU: 1 vCPU
- Concurrency: 80
- Startup probe: /api/health with 10s timeout
- Environment variables from Secret Manager
Custom domain setup:
- Map docs.coditect.ai (or similar) to Cloud Run service
- Managed SSL certificate
- Cloud CDN for static assets (/_next/static/*)
Deployment script — scripts/deploy.sh:
- Build image
- Push to Artifact Registry
- Deploy new revision
- Run smoke tests against new revision URL
- If smoke tests pass → route 100% traffic
- If fail → rollback to previous revision

Expected Output: Complete Cloud Run deployment configuration with optimized Docker image.

P21: Cloud SQL Setup & Database Migrations

Context: GCP mode uses Cloud SQL (PostgreSQL 15) for user management, NDA signatures, sessions, and audit logs.

Task: Set up the database layer:

Prisma schema — Complete schema covering:
- User, Session, Account (NextAuth tables)
- NDATemplate, NDASignature
- AuditEntry
- ContentView (tracking which docs/dashboards users visit)
- All with proper indexes, constraints, and cascading deletes
Migration strategy:
- prisma migrate dev for local development
- prisma migrate deploy for Cloud SQL (in Cloud Build pipeline)
- Seed script: default admin user, NDA template v1.0, test users for each role
Cloud SQL connection:
- Cloud SQL Auth Proxy as Cloud Run sidecar
- Unix socket connection string
- Connection pooling via PgBouncer (if needed at scale)
- Automatic backup: daily, 7-day retention

Data model for analytics:

model ContentView {
  id          String   @id @default(cuid())
  userId      String?  // null for local mode
  contentType String   // "document" | "dashboard"
  contentId   Int      // doc/dashboard number (1-56)
  route       String   // full URL path
  duration    Int?     // seconds on page
  tabViewed   String?  // for dashboards with tabs
  createdAt   DateTime @default(now())
}

Expected Output: Complete database schema, migrations, and seed data.

P22: Environment Configuration & Secret Management

Context: The site must work identically in local dev (.env.local) and GCP production (Secret Manager). Secrets include database credentials, OAuth client secrets, email API keys, and NDA signing keys.

Task: Create the environment configuration system:

.env.example — Template with all variables:

# Mode
AUTH_MODE=none                          # none | gcp

# Database (GCP mode only)
DATABASE_URL=postgresql://...           # Cloud SQL connection
SHADOW_DATABASE_URL=postgresql://...    # Prisma shadow DB

# Auth (GCP mode only)
NEXTAUTH_SECRET=                        # Random 32-byte hex
NEXTAUTH_URL=https://docs.coditect.ai
GOOGLE_CLIENT_ID=                       # OAuth
GOOGLE_CLIENT_SECRET=

# Email (GCP mode only)
RESEND_API_KEY=                         # Or SendGrid/SES
ADMIN_EMAIL=access@coditect.ai

# NDA
NDA_SIGNING_KEY=                        # For signature hash

# Analytics (optional)
PLAUSIBLE_DOMAIN=docs.coditect.ai
POSTHOG_KEY=

# Site
SITE_URL=http://localhost:3000          # Or production URL
SITE_NAME=CODITECT WO System

lib/config.ts — Type-safe config loader:
- Validates all required vars at startup
- Throws descriptive error if missing in GCP mode
- Returns safe defaults for local mode
- Never exposes secrets to client-side code
GCP Secret Manager mapping:
- Each secret → Secret Manager secret
- Cloud Run service account has secretAccessor role
- Secrets mounted as environment variables (not files)
Local development:
- docker-compose.yml includes PostgreSQL for auth testing
- AUTH_MODE=none skips all auth (default for npm run dev)
- AUTH_MODE=gcp with local Postgres for testing auth flows

Expected Output: Complete environment configuration with Secret Manager integration.

P23: CDN, Caching & Performance Optimization

Context: The site must load fast for global audiences (investors may be in US, Europe, Asia). Static assets should be CDN-cached, dynamic pages should use ISR or SSR with proper cache headers.

Task: Optimize performance:

Cloud CDN configuration:
- Cache /_next/static/* with 1-year TTL (content-hashed filenames)
- Cache images and fonts with 30-day TTL
- No cache for /api/*, /register, /nda, /admin
- Stale-while-revalidate for document pages (5 min)
Next.js optimization:
- output: 'standalone' for Docker
- Image optimization: next/image with Cloud CDN loader
- Font optimization: self-hosted IBM Plex Sans (no Google Fonts external request)
- Bundle analysis: ensure no dashboard loads on pages that don't need it
- Prefetch priority: prefetch audience hub page based on referrer
ISR for document pages:
- revalidate: 3600 (1 hour) for markdown documents
- On-demand revalidation webhook for content updates
- Dashboard pages: no ISR (fully client-rendered after shell)
Performance budgets:
- LCP < 2.5s (landing page)
- FID < 100ms
- CLS < 0.1
- Total JS < 200KB (first load, excluding lazy dashboards)
- Dashboard JS < 150KB per component (lazy loaded)
Lighthouse CI:
- Run on every deployment
- Fail build if score < 90 on any category
- Store results for trend tracking

Expected Output: CDN configuration, caching strategy, and performance optimization.

P24: Monitoring, Alerting & Observability

Context: Production deployment needs observability for both application health and user engagement.

Task: Set up monitoring:

Google Cloud Monitoring:
- Cloud Run metrics: request count, latency (p50/p95/p99), error rate, instance count
- Cloud SQL metrics: connections, query latency, storage usage
- Custom metrics: registration count, NDA sign rate, approval queue depth
Alerting policies:
- Error rate > 5% for 5 minutes → PagerDuty/Slack
- Latency p95 > 3s for 10 minutes → Slack
- Cloud SQL connections > 80% → Slack
- Zero instances for > 5 minutes → Slack (cold start risk)
- Approval queue > 5 pending for > 24 hours → Email admin
Application logging:
- Structured JSON logs to Cloud Logging
- Request ID propagation
- Log levels: ERROR (failures), WARN (degraded), INFO (auth events), DEBUG (content access)
- PII masking: never log email/name in plain text
User engagement dashboard (Cloud Monitoring or PostHog):
- Daily active users
- Most viewed documents (top 10)
- Most used dashboards (top 10)
- Reading path completion rates
- Average session duration
- Funnel: Register → NDA → Approved → First document → First dashboard

Expected Output: Complete observability setup with monitoring, alerting, and engagement tracking.

Phase 5: Polish & Enhancement

P25: Full-Text Search

Context: With 56 artifacts containing 235+ glossary terms, extensive technical documentation, and financial data, search is essential. Users must find content across documents, dashboards, and the glossary.

Task: Implement full-text search:

Search index:
- Index all 31 markdown documents (title, headings, body text, metadata)
- Index glossary terms and definitions
- Index dashboard titles and descriptions
- Index cross-reference metrics
Implementation options (pick one):
- Pagefind (static, no backend): Build-time indexing, client-side search, zero API cost
- Algolia DocSearch (hosted): Real-time indexing, instant results, free for docs sites
- Custom (Postgres full-text): tsvector search on GCP mode, Pagefind on local mode
Search UI:
- Cmd+K / Ctrl+K keyboard shortcut opens search modal
- Instant results grouped by category (Documents, Dashboards, Glossary, Metrics)
- Result preview: title, category, 2-line snippet with highlighted match
- Recent searches (client-side)
- Navigate to result on Enter or click
Search analytics:
- Track search queries (anonymized)
- Track "no results" queries (content gap identification)
- Track click-through rate from search results

Expected Output: Full-text search across all 56 artifacts with keyboard shortcut and grouped results.

CODITECT Value: Investors searching for "LTV" or "Part 11" should find relevant content in < 2 seconds.

P26: PDF Export & Print Optimization

Context: Investors and compliance officers frequently need to export content for offline review, board presentations, or audit evidence packages.

Task: Implement PDF export:

Document PDF export:
- "Download PDF" button on every document page
- Rendered with CODITECT branding, header/footer
- In GCP mode: watermark with user name and date
- Table of contents for multi-page documents
- Syntax-highlighted code blocks preserved
Dashboard PDF export:
- "Export as PDF" button on dashboard pages
- Captures current dashboard state (active tab, filter selections)
- Uses html2canvas + jspdf (client-side) or Puppeteer (server-side)
- Include dashboard title, description, and timestamp
Bulk export:
- "Download reading path" — exports all documents in an audience's reading path as a single PDF
- "Download audit package" — exports all compliance documents + dashboard screenshots
Print optimization:
- @media print styles for clean printing
- Hide navigation, show full content
- Page breaks at section boundaries
- Print-specific header with document number and classification

Expected Output: PDF export for documents and dashboards with watermarking on GCP.

P27: Analytics Integration

Context: The site needs privacy-friendly analytics to track engagement, identify content gaps, and measure the effectiveness of the reading path recommendations.

Task: Integrate analytics:

Plausible or PostHog integration:
- Page views by route
- Custom events: dashboard tab changes, glossary searches, reading path progress
- Funnel tracking: landing → hub → first document → first dashboard → second dashboard
- No cookies required (Plausible), GDPR/CCPA compliant
Custom engagement tracking:
- Time on page (for documents)
- Scroll depth (for long documents)
- Dashboard interaction depth (how many tabs visited)
- Reading path completion percentage
- Cross-audience navigation patterns
Admin analytics dashboard (/admin/analytics):
- Real-time visitors
- Top content (last 7 days, 30 days)
- User journey visualization (Sankey diagram)
- Conversion funnel: Register → NDA → Approved → Engaged
- Content gap identification: pages with high bounce rate

Expected Output: Analytics integration with custom engagement tracking and admin dashboard.

P28: Accessibility & Mobile Optimization

Context: The site must be accessible to users with disabilities and work well on mobile devices. Compliance officers may review content on tablets during audits.

Task: Implement accessibility and mobile optimization:

WCAG 2.1 AA compliance:
- All interactive elements keyboard navigable
- ARIA labels on dashboard controls
- Color contrast ≥ 4.5:1 for all text (already enforced by design system)
- Focus indicators on all interactive elements
- Screen reader testing for document pages and navigation
- Alt text for all informational images/icons
- Skip-to-content link
Mobile optimization:
- All 25 dashboards responsive (most already have flex-wrap)
- Dashboard tables: horizontal scroll on narrow screens
- Navigation: bottom tab bar + hamburger for full nav
- Touch targets: minimum 44×44px
- Glossary: swipe-friendly alphabet navigation
Performance on mobile:
- Critical CSS inlined
- Images lazy-loaded below fold
- Dashboard deferred until tab is visible
- Offline: service worker caches document pages for offline reading
Testing:
- Lighthouse accessibility score ≥ 95
- axe-core automated testing in CI
- Manual testing with VoiceOver (macOS) and NVDA (Windows)
- Tested on: iPhone 14, iPad, Pixel 7, Samsung Galaxy S23

Expected Output: WCAG 2.1 AA accessible, mobile-optimized site with automated testing.

Phase 6: Living Documentation

P29: Git-Based Content Workflow

Context: As the WO system evolves, documentation must stay current. Content updates should follow a Git-based workflow with preview deployments and review.

Task: Implement the content update pipeline:

Git workflow:
- main branch = production (auto-deploys)
- Feature branches for content updates
- PR template with checklist: frontmatter updated, cross-references updated, glossary terms added
- Preview deployment per PR (Cloud Run revision with traffic tag)
Content validation CI:
- Frontmatter schema validation for all markdown files
- Broken link checker (internal cross-references)
- Glossary coverage checker: flag new terms in documents not in glossary
- Dashboard import validation: ensure all referenced dashboards exist
- Markdown linting (markdownlint)
Automated updates:
- Script to extract glossary terms from all documents and flag missing entries
- Script to update document inventory when files are added/removed
- Script to regenerate cross-references from frontmatter related fields
- Script to validate dashboard metadata against actual JSX files

Expected Output: Git-based content workflow with validation, preview deployments, and automated checks.

P30: API for Programmatic Access

Context: CODITECT's autonomous agents may need to access documentation programmatically — to reference architecture decisions, check compliance requirements, or retrieve glossary definitions during development.

Task: Build a read-only API:

API routes:

GET /api/docs                    → List all documents (metadata only)
GET /api/docs/:id                → Get document by ID (metadata + content)
GET /api/docs/:id/content        → Get raw markdown content
GET /api/dashboards              → List all dashboards (metadata only)
GET /api/glossary                → Full glossary as JSON
GET /api/glossary/:term          → Single term lookup
GET /api/metrics                 → Key metrics cross-reference
GET /api/reading-paths           → All reading paths
GET /api/reading-paths/:audience → Specific audience path
GET /api/search?q=              → Full-text search

Authentication:
- Local mode: no auth required
- GCP mode: API key or Bearer token (separate from web session)
- Rate limit: 1000 requests per hour per key

Response format:

{
  "data": { ... },
  "meta": {
    "version": "2026-02-13",
    "total": 56,
    "requestId": "..."
  }
}

OpenAPI 3.1 spec — Auto-generated from route definitions, served at /api/docs/openapi.json

Expected Output: Read-only REST API with OpenAPI spec for programmatic access.

CODITECT Value: Agents can query architecture decisions and compliance requirements during autonomous development — closing the loop between documentation and implementation.

P31: Changelog & Version Tracking

Context: As the documentation evolves, visitors need to know what's changed. This is especially important for compliance officers who need to track document version history.

Task: Build changelog and version tracking:

app/(public)/reference/changelog/page.tsx — Changelog page:
- Auto-generated from git history of /content/ directory
- Grouped by date, showing: document title, change type (added/modified/removed), brief description
- Filter by: date range, document category, change type
- RSS feed for changelog updates
Document version indicator:
- Every document page shows version number and last modified date
- "View history" link opens git log for that file
- Diff view between versions (future enhancement)
Notification system (GCP mode):
- Approved users can subscribe to categories
- Email digest (weekly) of changed documents in subscribed categories
- Unsubscribe link in every email
Compliance audit support:
- "Document was last modified on [date] by [author]"
- Version history exportable as PDF for audit evidence
- Immutable history (git provides this inherently)

Expected Output: Changelog page with auto-generation, version indicators, and notification system.

CODITECT Value: Version-tracked documentation is a compliance requirement — auditors need to verify document currency and change history.

Execution Notes

Prompt Dependencies

P00 → P01 → P02 (foundation, can run in parallel after P00)
P03 → P04 → P05 → P06 → P07 → P08 (sequential, each builds on previous)
P09 → P10 → P11 → P12 → P13 (sequential, P09 is infrastructure for P10-13)
P14 → P15 → P16 → P17 → P18 → P19 (sequential auth chain)
P20 → P21 → P22 → P23 → P24 (sequential GCP chain)
P25, P26, P27, P28 (can run in parallel)
P29 → P30 → P31 (sequential)

Critical Path

Minimum viable site (local): P00 → P01 → P03 → P04 → P05 → P09 → P10–13 = ~15 hours

Add GCP deployment: + P02 → P14–19 → P20–22 = ~15 hours additional

Full polish: + P25–P31 = ~10 hours additional

Content Files Required

All 56 artifacts must be placed in the project:

/content/docs/01-executive-summary.md through /content/docs/31-website-plan.md
/content/dashboards/32-tech-architecture-analyzer.jsx through /content/dashboards/56-product-roadmap-visualizer.jsx

No modifications needed to existing files except adding YAML frontmatter headers to markdown docs (scripted in P04).

Last updated: 2026-02-13
Maintained by: AZ1.AI Inc. / CODITECT Platform Team

Build Overview​

Phase 0: Project Foundation​

P00: Project Scaffolding & Monorepo Structure​

P01: Configuration Data Files​

P02: CI/CD Pipeline & Infrastructure as Code​

Phase 1: Core Documentation Site​

P03: Root Layout, Navigation & Responsive Shell​

P04: MDX Content Pipeline & Document Renderer​

P05: Landing Page​

P06: Audience Hub Pages (4 pages)​

P07: Document Sub-Pages & Category Indexes​

P08: Glossary & Reference Pages​

Phase 2: Interactive Dashboards​

P09: Dashboard Wrapper & Dynamic Import System​

P10: System & Architecture Dashboards (8 dashboards)​

P11: Compliance Dashboards (4 dashboards)​

P12: Business & Market Dashboards (8 dashboards)​

P13: Planning & Operations Dashboards (5 dashboards)​

Phase 3: Authentication & NDA Gating​

P14: Auth Architecture — Dual-Mode Design​

P15: Registration Flow​

P16: NDA Signing Flow​

P17: Approval Workflow & Admin Panel​

P18: Role-Based Content Filtering​

P19: Session Management & Security Hardening​

Phase 4: GCP Deployment​

P20: Cloud Run Deployment Configuration​

P21: Cloud SQL Setup & Database Migrations​

P22: Environment Configuration & Secret Management​

P23: CDN, Caching & Performance Optimization​

P24: Monitoring, Alerting & Observability​

Phase 5: Polish & Enhancement​

P25: Full-Text Search​

P26: PDF Export & Print Optimization​

P27: Analytics Integration​

P28: Accessibility & Mobile Optimization​

Phase 6: Living Documentation​

P29: Git-Based Content Workflow​

P30: API for Programmatic Access​

P31: Changelog & Version Tracking​

Execution Notes​

Prompt Dependencies​

Critical Path​

Content Files Required​

Build Overview

Phase 0: Project Foundation

P00: Project Scaffolding & Monorepo Structure

P01: Configuration Data Files

P02: CI/CD Pipeline & Infrastructure as Code

Phase 1: Core Documentation Site

P03: Root Layout, Navigation & Responsive Shell

P04: MDX Content Pipeline & Document Renderer

P05: Landing Page

P06: Audience Hub Pages (4 pages)

P07: Document Sub-Pages & Category Indexes

P08: Glossary & Reference Pages

Phase 2: Interactive Dashboards

P09: Dashboard Wrapper & Dynamic Import System

P10: System & Architecture Dashboards (8 dashboards)

P11: Compliance Dashboards (4 dashboards)

P12: Business & Market Dashboards (8 dashboards)

P13: Planning & Operations Dashboards (5 dashboards)

Phase 3: Authentication & NDA Gating

P14: Auth Architecture — Dual-Mode Design

P15: Registration Flow

P16: NDA Signing Flow

P17: Approval Workflow & Admin Panel

P18: Role-Based Content Filtering

P19: Session Management & Security Hardening

Phase 4: GCP Deployment

P20: Cloud Run Deployment Configuration

P21: Cloud SQL Setup & Database Migrations

P22: Environment Configuration & Secret Management

P23: CDN, Caching & Performance Optimization

P24: Monitoring, Alerting & Observability

Phase 5: Polish & Enhancement

P25: Full-Text Search

P26: PDF Export & Print Optimization

P27: Analytics Integration

P28: Accessibility & Mobile Optimization

Phase 6: Living Documentation

P29: Git-Based Content Workflow

P30: API for Programmatic Access

P31: Changelog & Version Tracking

Execution Notes

Prompt Dependencies

Critical Path

Content Files Required