Implementation Plan

nviaOTP was built in five phases. Each had a narrow goal and a definition of done that could be checked in a browser, not just in a code review. This document records what each phase delivered so that future work starts from an accurate picture.

Phase A — identity

Goal: replace a generic course template with a distinct lab-bench identity while keeping the brand DNA fixed (primary blue, cyan accent, gold for celebration, ink navy text, serif prose, monospace code).

• New wordmark treatment with the gradient on “OTP” and the tagline “OTP engineering, from RFC to attack surface.”
• Brand favicon set: vector icon, 32×32 fallback and 180×180 touch icon.
• Home rebuilt around a live RFC 6238 card with base32 secret, rotating code and countdown ring.
• “New chapters this week” computed from publish dates at runtime; “Continue learning” shown only with progress.
• Three role paths with their own pages; library preview with progress rings; custom oscilloscope illustration.
• Dim mode toggle persisted on the device; footer with docs link.

Phase B — curriculum (B1–B3)

Goal: thirty-one chapters of original, technically accurate prose for engineers, each with a diagram and a quiz, with honest reading times.

• B1: series 1, OTP Cryptography Internals, and series 2, Phishing-Resistant Auth — ten chapters using RFC test vectors and fresh fictional organisations.
• B2: series 3, Threat Modeling OTP Flows (six chapters), and series 4, Rate Limiting & Abuse Economics (five), introducing attacker/defender panels and consistent severity badges.
• B3: series 5, Risk-Based Step-Up & Account Recovery, and series 6, Detection Engineering for Auth — ten chapters with policy matrices and a seasonal baseline chart.
• Prerequisite data finalised for the graph; every reading time recomputed from words / 200; verification script confirming 6 series and 31 chapters.

Phase C — the lab

Goal: make the site’s claims checkable, with every demo agreeing with its lesson.

• TOTP workbench with step-by-step truncation, drift windows and a live panel recomputing the RFC 4226 and RFC 6238 vectors.
• Attack simulator covering SIM swap, AitM relay, MFA fatigue and SMS pumping with five toggleable defenses and severity output.
• WebAuthn ceremony mock with real P-256 signatures and nine pass/fail checks.
• Policy engine with a live JSON rules editor and sample sessions.
• Thirteen playgrounds on domain exercises with lab.pass assertions; seven animated before→after diffs; a Lab index and per-module pages.
• Browser verification that every playground prints only PASS and no page errors occur.

Phase D — shared comments and docs

Goal: turn per-device comments into a real shared discussion with basic moderation, and rewrite these six documents to describe the product that actually exists.

• Managed database with the comments and reports tables, locked by row-level security and reachable only through three validated functions.
• Display name, timestamp, body and one level of replies; report link; automatic hide at three distinct reports; honest empty state.
• Spam-light validation: minimum length, link limit, duplicate check and per-browser rate limits.
• Removal of all seeded comments and of the old local comment store; the table ships empty.
• PRD, TRD, App Flow, Design Brief, Background Schema and this plan rewritten, each specific to this build.

Phase E — release (next)

Goal: ship to nviaotp.me with confidence and keep it correct. This phase is planned; the items below are its checklist.

• Full-site pass at mobile, tablet and desktop widths in both themes, including keyboard-only navigation of labs and comments.
• Metadata audit: unique title and description per route, link previews checked for chapters and lab pages.
• Performance pass on lazy-loaded editors and lab modules so content pages stay fast on first load.
• Publish to the custom domain with the www host redirecting to the apex.
• Operating routine: weekly review of hidden comments, a release checklist that re-runs the RFC vectors and playground assertions, and a content review whenever a referenced standard changes.

How each phase was verified

Every phase ended with a browser run, not just a successful build. Phase A was checked by watching the hero ring tick across a 30-second boundary and confirming the code changed. Phase B was checked by a script that loaded all content, counted series, chapters, words, figures and quizzes, and printed computed reading times. Phase C was checked by opening every chapter with a playground, waiting for output and confirming there were no FAIL lines and no page errors, then screenshotting each lab module. Phase D was checked by posting a comment, a reply and reports from separate browser sessions against the real database, confirming the rate limit and hide-at-three behaviour, and then deleting those test rows so the table returned to empty.

Risks carried forward

• Comment spam beyond what per-browser limits catch — mitigated by low report threshold and operator review; accounts remain a non-goal.
• Drift between prose and demos as chapters are edited — mitigated by assertions and the change-control rule above.
• Browser support for Web Crypto algorithms — all used algorithms are baseline in current browsers; the workbench reports failures visibly rather than silently.