Website Vibe Coding
Build and release a full-stack web product with AI while keeping product decisions, code review, testing, security, data, and operations under human control.
Curriculum
0%0 of 21 skills complete
Phase 1Product, Stack & Git Guardrails0/5
Phase 2Data, Security & Vertical Slices0/5
Phase 3Testing & Evidence-Based Debugging0/5
Phase 4Hardening, Operations & Release0/6
Website Vibe Coding · selected skill
OpenProduct Scope & Acceptance Criteria
Target user and problem
Understand the building blocks and choices behind Product Scope & Acceptance Criteria.
0 of 5 complete- In plain language
- Target user and problem is one specific set of knowledge and decisions inside Product Scope & Acceptance Criteria.
- Why it matters
- Define the smallest valuable user outcome and postpone everything not required to prove it.
- Real example
- Interview one target user, write one problem statement, then convert desired behavior and failure cases into testable acceptance criteria.
- You understand it when
- Another developer can test every requirement without asking what success means.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillScope and explicit exclusions
Scope and explicit exclusions
Use this part of Product Scope & Acceptance Criteria in a realistic workflow.
0 of 5 complete- In plain language
- Scope and explicit exclusions is one specific set of knowledge and decisions inside Product Scope & Acceptance Criteria.
- Why it matters
- Define the smallest valuable user outcome and postpone everything not required to prove it.
- Real example
- Interview one target user, write one problem statement, then convert desired behavior and failure cases into testable acceptance criteria.
- You understand it when
- Another developer can test every requirement without asking what success means.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillObservable acceptance criteria
Observable acceptance criteria
Handle the boundaries and prove the result for Product Scope & Acceptance Criteria.
0 of 7 complete- In plain language
- Observable acceptance criteria is one specific set of knowledge and decisions inside Product Scope & Acceptance Criteria.
- Why it matters
- Define the smallest valuable user outcome and postpone everything not required to prove it.
- Real example
- Interview one target user, write one problem statement, then convert desired behavior and failure cases into testable acceptance criteria.
- You understand it when
- Another developer can test every requirement without asking what success means.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillTech Stack Contract
Website Vibe Coding · selected skill
OpenTech Stack Contract
Framework and version contract
Understand the building blocks and choices behind Tech Stack Contract.
0 of 6 complete- In plain language
- A written list of the exact frameworks, major versions, and runtime the project will use.
- Why it matters
- It stops an assistant from mixing incompatible routers, APIs, styling systems, or outdated examples.
- Real example
- The project specifies Next.js App Router, TypeScript, Tailwind, Prisma, PostgreSQL, and Node 22.
- You understand it when
- A fresh assistant can repeat the stack and rejects a request to add React Router or Mongoose.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillArchitecture and package boundaries
Architecture and package boundaries
Use this part of Tech Stack Contract in a realistic workflow.
0 of 6 complete- In plain language
- Rules describing which folder or package owns UI, business logic, validation, and database access.
- Why it matters
- Clear ownership prevents generated code from importing server secrets into browser code or creating circular dependencies.
- Real example
- UI imports a typed service contract, while only the server data layer imports Prisma.
- You understand it when
- You can trace one feature from UI to route to database without crossed or circular boundaries.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillWorkspace AI rules and prohibited alternatives
Workspace AI rules and prohibited alternatives
Handle the boundaries and prove the result for Tech Stack Contract.
0 of 8 complete- In plain language
- Project-level instructions that tell an AI what it may change, what it must use, and when it must stop.
- Why it matters
- The same guardrails apply in every new chat instead of depending on remembered conversation context.
- Real example
- Rules require App Router and forbid new dependencies, destructive commands, and edits outside named files without approval.
- You understand it when
- A deliberately conflicting prompt is refused or paused with a clear question.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillDependency Lockdown
Website Vibe Coding · selected skill
OpenDependency Lockdown
Package manifest and lockfile
Understand the building blocks and choices behind Dependency Lockdown.
0 of 6 complete- In plain language
- package.json describes direct packages and scripts; the lockfile records the exact resolved dependency graph.
- Why it matters
- Together they make installations repeatable across machines and expose unexpected package changes in review.
- Real example
- A pull request changes package.json and package-lock.json together and explains the added package.
- You understand it when
- npm ci succeeds twice from clean folders and resolves the same versions.
- Learn first if this is unfamiliar
- JavaScript fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillDependency approval and version policy
Dependency approval and version policy
Use this part of Dependency Lockdown in a realistic workflow.
0 of 6 complete- In plain language
- A decision process for deciding whether a new library is necessary, maintained, compatible, and safe enough.
- Why it matters
- AI assistants often install packages to avoid small tasks, increasing security, bundle, and maintenance costs.
- Real example
- Before adding a date library, compare the platform API, bundle size, license, releases, and advisories.
- You understand it when
- Every direct dependency has a documented purpose, approved version range, and removal path.
- Learn first if this is unfamiliar
- JavaScript fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillClean install and build reproduction
Clean install and build reproduction
Handle the boundaries and prove the result for Dependency Lockdown.
0 of 8 complete- In plain language
- Proving a new checkout can install, test, and build using only committed files and documented commands.
- Why it matters
- It reveals hidden global tools, uncommitted environment files, and machine-specific assumptions before deployment.
- Real example
- Clone into a temporary directory, run npm ci, tests, and the production build.
- You understand it when
- The complete setup works on a clean machine without manual fixes or surprise installs.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillGit Checkpoints & Safe Recovery
Website Vibe Coding · selected skill
OpenGit Checkpoints & Safe Recovery
Small verified commits
Understand the building blocks and choices behind Git Checkpoints & Safe Recovery.
0 of 5 complete- In plain language
- Small verified commits is one specific set of knowledge and decisions inside Git Checkpoints & Safe Recovery.
- Why it matters
- Choose restore, revert, reset, or reflog from whether changes are committed, shared, and independently valuable.
- Real example
- Create a feature branch, verify one small change, inspect its diff, and commit a named checkpoint before prompting for more work.
- You understand it when
- The project returns to the chosen verified state and all unrelated work remains intact.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillDiff review before commit
Diff review before commit
Use this part of Git Checkpoints & Safe Recovery in a realistic workflow.
0 of 5 complete- In plain language
- Diff review before commit is one specific set of knowledge and decisions inside Git Checkpoints & Safe Recovery.
- Why it matters
- Choose restore, revert, reset, or reflog from whether changes are committed, shared, and independently valuable.
- Real example
- Create a feature branch, verify one small change, inspect its diff, and commit a named checkpoint before prompting for more work.
- You understand it when
- The project returns to the chosen verified state and all unrelated work remains intact.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillRestore, revert, and reflog
Restore, revert, and reflog
Handle the boundaries and prove the result for Git Checkpoints & Safe Recovery.
0 of 7 complete- In plain language
- Restore, revert, and reflog is one specific set of knowledge and decisions inside Git Checkpoints & Safe Recovery.
- Why it matters
- Choose restore, revert, reset, or reflog from whether changes are committed, shared, and independently valuable.
- Real example
- Create a feature branch, verify one small change, inspect its diff, and commit a named checkpoint before prompting for more work.
- You understand it when
- The project returns to the chosen verified state and all unrelated work remains intact.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillAI Context & Data Boundaries
Website Vibe Coding · selected skill
OpenAI Context & Data Boundaries
Context minimization
Understand the building blocks and choices behind AI Context & Data Boundaries.
0 of 5 complete- In plain language
- Context minimization is one specific set of knowledge and decisions inside AI Context & Data Boundaries.
- Why it matters
- Share a file only when its contents are necessary, permitted, sanitized, and appropriate for the selected AI provider.
- Real example
- Classify project files by sensitivity, exclude private sources, and provide only the minimum sanitized context required for one task.
- You understand it when
- Prompts contain only approved project context and scans detect no secrets or personal records.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillSecret and personal data exclusion
Secret and personal data exclusion
Use this part of AI Context & Data Boundaries in a realistic workflow.
0 of 5 complete- In plain language
- Secret and personal data exclusion is one specific set of knowledge and decisions inside AI Context & Data Boundaries.
- Why it matters
- Share a file only when its contents are necessary, permitted, sanitized, and appropriate for the selected AI provider.
- Real example
- Classify project files by sensitivity, exclude private sources, and provide only the minimum sanitized context required for one task.
- You understand it when
- Prompts contain only approved project context and scans detect no secrets or personal records.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillRetention and provider settings
Retention and provider settings
Handle the boundaries and prove the result for AI Context & Data Boundaries.
0 of 7 complete- In plain language
- Retention and provider settings is one specific set of knowledge and decisions inside AI Context & Data Boundaries.
- Why it matters
- Share a file only when its contents are necessary, permitted, sanitized, and appropriate for the selected AI provider.
- Real example
- Classify project files by sensitivity, exclude private sources, and provide only the minimum sanitized context required for one task.
- You understand it when
- Prompts contain only approved project context and scans detect no secrets or personal records.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillDatabase-First Data Model
Website Vibe Coding · selected skill
OpenDatabase-First Data Model
Entities, fields, and relationships
Understand the building blocks and choices behind Database-First Data Model.
0 of 6 complete- In plain language
- The database description of real things, their data types, and how records connect to one another.
- Why it matters
- A stable data model keeps generated forms and APIs from inventing conflicting shapes.
- Real example
- A Project belongs to a User and has many Tasks; each field has a deliberate type and owner.
- You understand it when
- You can explain every field, relation, null value, and deletion behavior in the schema.
- Learn first if this is unfamiliar
- SQL fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillConstraints, indexes, and migrations
Constraints, indexes, and migrations
Use this part of Database-First Data Model in a realistic workflow.
0 of 6 complete- In plain language
- Database rules, query-speed structures, and versioned files that change the schema safely.
- Why it matters
- Application validation can fail or be bypassed; database constraints protect the final stored state.
- Real example
- A unique email constraint rejects duplicates, an index supports lookup, and a migration adds both.
- You understand it when
- Invalid rows are rejected and the migration works with both empty and existing data.
- Learn first if this is unfamiliar
- SQL fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillSeed data and schema verification
Seed data and schema verification
Handle the boundaries and prove the result for Database-First Data Model.
0 of 8 complete- In plain language
- Repeatable sample records and checks used to prove a new database has the expected structure and behavior.
- Why it matters
- Reliable fixtures make generated UI, API tests, and onboarding independent from one developer’s database.
- Real example
- A seed creates known users, projects, empty states, and boundary cases using stable identifiers.
- You understand it when
- Resetting and reseeding produces the same valid dataset and expected failing cases.
- Learn first if this is unfamiliar
- SQL fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillAuthentication & Authorization Boundaries
Website Vibe Coding · selected skill
OpenAuthentication & Authorization Boundaries
Identity and session lifecycle
Understand the building blocks and choices behind Authentication & Authorization Boundaries.
0 of 5 complete- In plain language
- Identity and session lifecycle is one specific set of knowledge and decisions inside Authentication & Authorization Boundaries.
- Why it matters
- Grant each actor only the operations required for owned resources and deny every unspecified server action.
- Real example
- List actors, resources, operations, and abuse cases, then enforce authentication and authorization again at every trusted server boundary.
- You understand it when
- Unauthenticated, forbidden, cross-tenant, replayed, and excessive requests fail safely in automated tests.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillRole and resource authorization
Role and resource authorization
Use this part of Authentication & Authorization Boundaries in a realistic workflow.
0 of 5 complete- In plain language
- Role and resource authorization is one specific set of knowledge and decisions inside Authentication & Authorization Boundaries.
- Why it matters
- Grant each actor only the operations required for owned resources and deny every unspecified server action.
- Real example
- List actors, resources, operations, and abuse cases, then enforce authentication and authorization again at every trusted server boundary.
- You understand it when
- Unauthenticated, forbidden, cross-tenant, replayed, and excessive requests fail safely in automated tests.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillAbuse cases and rate limits
Abuse cases and rate limits
Handle the boundaries and prove the result for Authentication & Authorization Boundaries.
0 of 7 complete- In plain language
- Abuse cases and rate limits is one specific set of knowledge and decisions inside Authentication & Authorization Boundaries.
- Why it matters
- Grant each actor only the operations required for owned resources and deny every unspecified server action.
- Real example
- List actors, resources, operations, and abuse cases, then enforce authentication and authorization again at every trusted server boundary.
- You understand it when
- Unauthenticated, forbidden, cross-tenant, replayed, and excessive requests fail safely in automated tests.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillSchema-Driven Forms & Tables
Website Vibe Coding · selected skill
OpenSchema-Driven Forms & Tables
Schema-to-validation mapping
Understand the building blocks and choices behind Schema-Driven Forms & Tables.
0 of 6 complete- In plain language
- Translating database and API rules into a runtime validation schema for untrusted input.
- Why it matters
- TypeScript types disappear at runtime, so real requests still need validation before reaching the database.
- Real example
- A Prisma enum and length rule are represented in a Zod create-input schema.
- You understand it when
- Valid input is normalized and invalid, extra, or forbidden fields are rejected consistently.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillTyped form fields and error states
Typed form fields and error states
Use this part of Schema-Driven Forms & Tables in a realistic workflow.
0 of 6 complete- In plain language
- Form controls connected to typed values, validation rules, submission state, and accessible feedback.
- Why it matters
- Generated happy-path forms often lose user input or hide server errors when a request fails.
- Real example
- React Hook Form preserves values and links each Zod error to the correct field.
- You understand it when
- Keyboard users can submit, find errors, correct values, and recover from a server failure.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillTable columns, mutations, and server-owned fields
Table columns, mutations, and server-owned fields
Handle the boundaries and prove the result for Schema-Driven Forms & Tables.
0 of 8 complete- In plain language
- Choosing what a table displays and what create, update, or delete operations a user may request.
- Why it matters
- Directly binding database records can expose internal fields or let clients overwrite ownership and audit data.
- Real example
- The UI shows status and dates but never sends ownerId, createdAt, or permission fields.
- You understand it when
- Captured requests contain only allowed fields and refresh to confirmed server state.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillRoute-Specific Context
Website Vibe Coding · selected skill
OpenRoute-Specific Context
HTTP route contract and status codes
Understand the building blocks and choices behind Route-Specific Context.
0 of 6 complete- In plain language
- The documented request method, path, input, output, and status for an API endpoint.
- Why it matters
- A clear contract prevents the UI and generated server code from making different assumptions.
- Real example
- POST /api/tasks accepts one validated shape and documents 201, 400, 401, 403, and 409 responses.
- You understand it when
- Contract tests prove every documented response and reject undocumented input.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillValidation, authentication, and authorization
Validation, authentication, and authorization
Use this part of Route-Specific Context in a realistic workflow.
0 of 6 complete- In plain language
- Validation checks input; authentication identifies the caller; authorization decides what that caller may do.
- Why it matters
- Generated code often checks that a user is logged in but forgets resource ownership or permissions.
- Real example
- A signed-in user still receives 403 when attempting to update another user’s project.
- You understand it when
- Tests cover malformed, anonymous, wrong-owner, wrong-role, and allowed requests on the server.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillDatabase transaction and error boundary
Database transaction and error boundary
Handle the boundaries and prove the result for Route-Specific Context.
0 of 8 complete- In plain language
- A transaction makes related writes succeed together, while an error boundary maps failures to safe responses.
- Why it matters
- Without both, a request can leave partial data or expose database details to clients.
- Real example
- Creating an order and its items rolls back completely if one item fails.
- You understand it when
- A forced mid-operation failure leaves no partial rows and returns a stable public error.
- Learn first if this is unfamiliar
- SQL fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillComponent Slicing & Integration
Website Vibe Coding · selected skill
OpenComponent Slicing & Integration
Presentational component boundary
Understand the building blocks and choices behind Component Slicing & Integration.
0 of 6 complete- In plain language
- A UI component that receives data and events without owning networking or application-wide business rules.
- Why it matters
- Small visual units are easier to preview, verify, reuse, and replace when generated code is imperfect.
- Real example
- A TaskList renders loading, empty, error, and populated states from props.
- You understand it when
- The component can be reviewed and tested without a database or live API.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillGenerated UI import and dependency audit
Generated UI import and dependency audit
Use this part of Component Slicing & Integration in a realistic workflow.
0 of 6 complete- In plain language
- Reviewing copied UI code, packages, markup, tokens, and interactions before accepting it into the project.
- Why it matters
- UI generators may add inaccessible controls, duplicate design systems, or unnecessary dependencies.
- Real example
- A generated dialog is converted to existing tokens and an approved accessible dialog primitive.
- You understand it when
- The component adds no unexplained package and passes keyboard, semantics, and responsive checks.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillIncremental state and API integration
Incremental state and API integration
Handle the boundaries and prove the result for Component Slicing & Integration.
0 of 8 complete- In plain language
- Connecting a verified UI to state and server data in small, separately testable changes.
- Why it matters
- Separating visual work from data work makes failures easier to locate and rollback.
- Real example
- First render fixture data, then add query state, then add a mutation with recovery.
- You understand it when
- Each commit runs independently and the final component handles every request state.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillUnit, Integration & E2E Tests
Website Vibe Coding · selected skill
OpenUnit, Integration & E2E Tests
Risk-based test selection
Understand the building blocks and choices behind Unit, Integration & E2E Tests.
0 of 5 complete- In plain language
- Risk-based test selection is one specific set of knowledge and decisions inside Unit, Integration & E2E Tests.
- Why it matters
- Test pure rules with units, boundaries with integrations, and only critical user journeys through the browser.
- Real example
- Map product risks to unit, integration, and browser tests, then write the smallest reliable check at the lowest useful layer.
- You understand it when
- Tests fail for seeded regressions, pass consistently, and explain which product risk they protect.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillUnit and integration boundaries
Unit and integration boundaries
Use this part of Unit, Integration & E2E Tests in a realistic workflow.
0 of 5 complete- In plain language
- Unit and integration boundaries is one specific set of knowledge and decisions inside Unit, Integration & E2E Tests.
- Why it matters
- Test pure rules with units, boundaries with integrations, and only critical user journeys through the browser.
- Real example
- Map product risks to unit, integration, and browser tests, then write the smallest reliable check at the lowest useful layer.
- You understand it when
- Tests fail for seeded regressions, pass consistently, and explain which product risk they protect.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillCritical end-to-end journeys
Critical end-to-end journeys
Handle the boundaries and prove the result for Unit, Integration & E2E Tests.
0 of 7 complete- In plain language
- Critical end-to-end journeys is one specific set of knowledge and decisions inside Unit, Integration & E2E Tests.
- Why it matters
- Test pure rules with units, boundaries with integrations, and only critical user journeys through the browser.
- Real example
- Map product risks to unit, integration, and browser tests, then write the smallest reliable check at the lowest useful layer.
- You understand it when
- Tests fail for seeded regressions, pass consistently, and explain which product risk they protect.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillAccessibility & Responsive Verification
Website Vibe Coding · selected skill
OpenAccessibility & Responsive Verification
Semantic controls and names
Understand the building blocks and choices behind Accessibility & Responsive Verification.
0 of 5 complete- In plain language
- Semantic controls and names is one specific set of knowledge and decisions inside Accessibility & Responsive Verification.
- Why it matters
- Prefer native elements and content-driven layouts before adding ARIA, custom controls, or device-specific breakpoints.
- Real example
- Complete every critical flow using keyboard and screen reader, then inspect mobile, tablet, zoom, and long-content layouts.
- You understand it when
- The journey remains understandable and operable without pointer, perfect vision, or a desktop viewport.
- Learn first if this is unfamiliar
- Frontend Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillKeyboard and focus behavior
Keyboard and focus behavior
Use this part of Accessibility & Responsive Verification in a realistic workflow.
0 of 5 complete- In plain language
- Keyboard and focus behavior is one specific set of knowledge and decisions inside Accessibility & Responsive Verification.
- Why it matters
- Prefer native elements and content-driven layouts before adding ARIA, custom controls, or device-specific breakpoints.
- Real example
- Complete every critical flow using keyboard and screen reader, then inspect mobile, tablet, zoom, and long-content layouts.
- You understand it when
- The journey remains understandable and operable without pointer, perfect vision, or a desktop viewport.
- Learn first if this is unfamiliar
- Frontend Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillZoom and responsive layouts
Zoom and responsive layouts
Handle the boundaries and prove the result for Accessibility & Responsive Verification.
0 of 7 complete- In plain language
- Zoom and responsive layouts is one specific set of knowledge and decisions inside Accessibility & Responsive Verification.
- Why it matters
- Prefer native elements and content-driven layouts before adding ARIA, custom controls, or device-specific breakpoints.
- Real example
- Complete every critical flow using keyboard and screen reader, then inspect mobile, tablet, zoom, and long-content layouts.
- You understand it when
- The journey remains understandable and operable without pointer, perfect vision, or a desktop viewport.
- Learn first if this is unfamiliar
- Frontend Developer fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillNetwork Payload Diagnostics
Website Vibe Coding · selected skill
OpenNetwork Payload Diagnostics
Request payload, headers, and timing
Understand the building blocks and choices behind Network Payload Diagnostics.
0 of 6 complete- In plain language
- The exact data a browser sends, the metadata around it, and how long each network stage takes.
- Why it matters
- These facts distinguish a broken UI payload from authentication, redirect, CORS, or server latency problems.
- Real example
- DevTools shows a POST sent as text instead of application/json and a missing session cookie.
- You understand it when
- You can capture and safely explain the failing request without guessing or exposing secrets.
- Learn first if this is unfamiliar
- JavaScript fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillResponse status, body, and server evidence
Response status, body, and server evidence
Use this part of Network Payload Diagnostics in a realistic workflow.
0 of 6 complete- In plain language
- The server’s HTTP result combined with the matching route and database logs.
- Why it matters
- A visible error message alone rarely identifies whether validation, authorization, or storage failed.
- Real example
- A 409 response contains a safe code and correlation ID that matches a unique-constraint log.
- You understand it when
- One timeline connects the browser response to the precise server-side failure.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillMinimal replay with sanitized data
Minimal replay with sanitized data
Handle the boundaries and prove the result for Network Payload Diagnostics.
0 of 8 complete- In plain language
- A small repeatable request using invented data that reproduces the same failure outside the interface.
- Why it matters
- It protects private information and removes unrelated UI behavior from the investigation.
- Real example
- A redacted curl command reproduces the failing API response with one test record.
- You understand it when
- Another developer can run the replay and observe the same result safely.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillReact Hydration Recovery
Website Vibe Coding · selected skill
OpenReact Hydration Recovery
Server versus client render boundary
Understand the building blocks and choices behind React Hydration Recovery.
0 of 6 complete- In plain language
- The line between HTML produced on the server and interactive code that runs in the browser.
- Why it matters
- Crossing the boundary incorrectly causes secret exposure, serialization errors, or hydration failures.
- Real example
- A server component loads data and passes serializable props to a small client form.
- You understand it when
- You can identify where every component runs and no server-only value reaches browser code.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillDeterministic initial markup
Deterministic initial markup
Use this part of React Hydration Recovery in a realistic workflow.
0 of 6 complete- In plain language
- The server and browser produce the same HTML for the browser’s first render.
- Why it matters
- Dates, randomness, browser storage, or invalid nesting can make React reject or replace server output.
- Real example
- A timestamp is formatted on the server once instead of calling Date.now during both renders.
- You understand it when
- Direct page loads produce no mismatch and the initial DOM is identical.
- Learn first if this is unfamiliar
- JavaScript fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillHydration warning and DOM mismatch evidence
Hydration warning and DOM mismatch evidence
Handle the boundaries and prove the result for React Hydration Recovery.
0 of 8 complete- In plain language
- The exact React warning, component stack, and differing server/client element that identify a hydration problem.
- Why it matters
- Precise evidence prevents an assistant from disabling SSR or rewriting unrelated components.
- Real example
- The warning shows a server span but a client div inside the named component.
- You understand it when
- A production browser test fails on the original warning and passes after the focused fix.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillInstrumentation Before Rewrites
Website Vibe Coding · selected skill
OpenInstrumentation Before Rewrites
Function input and branch checkpoints
Understand the building blocks and choices behind Instrumentation Before Rewrites.
0 of 6 complete- In plain language
- Temporary observations showing what enters a function and which conditional path it follows.
- Why it matters
- They reveal where correct data first becomes missing or incorrect before code is rewritten.
- Real example
- Logs record the validated input and the reason an early return was chosen.
- You understand it when
- One reproduction identifies the first wrong checkpoint and the fix changes only that boundary.
- Learn first if this is unfamiliar
- JavaScript fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillAsync boundary and data-shape logging
Async boundary and data-shape logging
Use this part of Instrumentation Before Rewrites in a realistic workflow.
0 of 6 complete- In plain language
- Structured observations before and after awaited work, including result shapes, timing, and error causes.
- Why it matters
- Asynchronous failures can arrive out of order or return unexpected shapes that simple logs hide.
- Real example
- A trace records request start, database result count, transformation, and response completion.
- You understand it when
- Concurrent requests remain distinguishable and no secret or personal payload is logged.
- Learn first if this is unfamiliar
- JavaScript fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillCorrelation IDs and diagnostic cleanup
Correlation IDs and diagnostic cleanup
Handle the boundaries and prove the result for Instrumentation Before Rewrites.
0 of 8 complete- In plain language
- A unique request identifier carried across logs, followed by removal or reduction of temporary diagnostics.
- Why it matters
- It joins browser and server evidence without leaving noisy or sensitive debugging statements in production.
- Real example
- The response header and every server log line share request ID req_123.
- You understand it when
- A single request is traceable end to end and the final diff contains only approved durable logging.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillEnvironment & Secret Audits
Website Vibe Coding · selected skill
OpenEnvironment & Secret Audits
Public and server-only variable boundaries
Understand the building blocks and choices behind Environment & Secret Audits.
0 of 6 complete- In plain language
- Rules determining which configuration may be bundled into browser code and which must stay on the server.
- Why it matters
- A wrongly prefixed environment variable can publish a database key or other credential to every visitor.
- Real example
- NEXT_PUBLIC_API_ORIGIN is public, while DATABASE_URL is read only by server code.
- You understand it when
- A browser-bundle inspection finds no server secret and missing variables fail clearly at startup.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillRepository and history secret scanning
Repository and history secret scanning
Use this part of Environment & Secret Audits in a realistic workflow.
0 of 6 complete- In plain language
- Searching current files, previous commits, build output, and source maps for credentials or private data.
- Why it matters
- Deleting a secret from the latest file does not remove it from Git history or generated artifacts.
- Real example
- A scanner finds an old token in a commit and a test credential in a source map.
- You understand it when
- The repository, history, and production output contain no live secret after remediation.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillCredential rotation and configuration validation
Credential rotation and configuration validation
Handle the boundaries and prove the result for Environment & Secret Audits.
0 of 8 complete- In plain language
- Revoking exposed credentials, issuing replacements, updating consumers, and validating required settings.
- Why it matters
- Once a secret may be exposed, hiding the old text cannot make that credential trustworthy again.
- Real example
- Rotate the database password, update hosting secrets, invalidate sessions, and verify old access fails.
- You understand it when
- Old credentials are unusable and every environment starts with validated replacement configuration.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillGenerated Code & Provenance Review
Website Vibe Coding · selected skill
OpenGenerated Code & Provenance Review
Line-by-line behavior review
Understand the building blocks and choices behind Generated Code & Provenance Review.
0 of 5 complete- In plain language
- Line-by-line behavior review is one specific set of knowledge and decisions inside Generated Code & Provenance Review.
- Why it matters
- Accept generated code only when the team can explain, test, secure, license, operate, and maintain it.
- Real example
- Review one generated patch line by line for behavior, permissions, failure handling, copied material, dependencies, and maintainable ownership.
- You understand it when
- Every changed line has an understood purpose, acceptable provenance, and a passing verification path.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillDependency and license provenance
Dependency and license provenance
Use this part of Generated Code & Provenance Review in a realistic workflow.
0 of 5 complete- In plain language
- Dependency and license provenance is one specific set of knowledge and decisions inside Generated Code & Provenance Review.
- Why it matters
- Accept generated code only when the team can explain, test, secure, license, operate, and maintain it.
- Real example
- Review one generated patch line by line for behavior, permissions, failure handling, copied material, dependencies, and maintainable ownership.
- You understand it when
- Every changed line has an understood purpose, acceptable provenance, and a passing verification path.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillOwnership and maintainability
Ownership and maintainability
Handle the boundaries and prove the result for Generated Code & Provenance Review.
0 of 7 complete- In plain language
- Ownership and maintainability is one specific set of knowledge and decisions inside Generated Code & Provenance Review.
- Why it matters
- Accept generated code only when the team can explain, test, secure, license, operate, and maintain it.
- Real example
- Review one generated patch line by line for behavior, permissions, failure handling, copied material, dependencies, and maintainable ownership.
- You understand it when
- Every changed line has an understood purpose, acceptable provenance, and a passing verification path.
- Learn first if this is unfamiliar
- Git & GitHub fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillTailwind & Component Cleanup
Website Vibe Coding · selected skill
OpenTailwind & Component Cleanup
Repeated markup and class inventory
Understand the building blocks and choices behind Tailwind & Component Cleanup.
0 of 6 complete- In plain language
- A list of duplicated UI structures, Tailwind class groups, state variants, and inconsistent design tokens.
- Why it matters
- An inventory distinguishes a real shared component from two elements that merely look similar.
- Real example
- Five buttons repeat the same layout but differ only by intent and disabled state.
- You understand it when
- Every proposed extraction names its shared semantics, variants, and current call sites.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillReusable component and variant extraction
Reusable component and variant extraction
Use this part of Tailwind & Component Cleanup in a realistic workflow.
0 of 6 complete- In plain language
- Moving a proven repeated pattern into a focused component with typed, limited variants.
- Why it matters
- It reduces generated div soup while keeping behavior and styling changes consistent.
- Real example
- Repeated button markup becomes a Button with primary, quiet, and danger variants.
- You understand it when
- All call sites use the component without a giant list of boolean customization props.
- Learn first if this is unfamiliar
- React fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillAccessibility and visual regression verification
Accessibility and visual regression verification
Handle the boundaries and prove the result for Tailwind & Component Cleanup.
0 of 8 complete- In plain language
- Checking semantics, keyboard behavior, contrast, responsiveness, and screenshots before and after cleanup.
- Why it matters
- A refactor can look correct while silently breaking focus, names, zoom, or small-screen layout.
- Real example
- Run keyboard checks, an accessibility scan, and responsive screenshots for every extracted component state.
- You understand it when
- Behavior and appearance remain stable at mobile, desktop, keyboard, and 200% zoom.
- Learn first if this is unfamiliar
- Frontend Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Next skillPerformance & Observability
Website Vibe Coding · selected skill
OpenPerformance & Observability
Core Web Vitals baseline
Understand the building blocks and choices behind Performance & Observability.
0 of 5 complete- In plain language
- Core Web Vitals baseline is one specific set of knowledge and decisions inside Performance & Observability.
- Why it matters
- Instrument signals that reveal user impact and actionable causes instead of collecting every available event.
- Real example
- Measure one critical journey, establish a baseline, then add structured logs, traces, errors, and health signals around its boundaries.
- You understand it when
- A simulated failure identifies the affected journey, responsible boundary, release version, and recovery action.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillStructured logs and traces
Structured logs and traces
Use this part of Performance & Observability in a realistic workflow.
0 of 5 complete- In plain language
- Structured logs and traces is one specific set of knowledge and decisions inside Performance & Observability.
- Why it matters
- Instrument signals that reveal user impact and actionable causes instead of collecting every available event.
- Real example
- Measure one critical journey, establish a baseline, then add structured logs, traces, errors, and health signals around its boundaries.
- You understand it when
- A simulated failure identifies the affected journey, responsible boundary, release version, and recovery action.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillErrors, health, and alerts
Errors, health, and alerts
Handle the boundaries and prove the result for Performance & Observability.
0 of 7 complete- In plain language
- Errors, health, and alerts is one specific set of knowledge and decisions inside Performance & Observability.
- Why it matters
- Instrument signals that reveal user impact and actionable causes instead of collecting every available event.
- Real example
- Measure one critical journey, establish a baseline, then add structured logs, traces, errors, and health signals around its boundaries.
- You understand it when
- A simulated failure identifies the affected journey, responsible boundary, release version, and recovery action.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillBackups & Data Recovery
Website Vibe Coding · selected skill
OpenBackups & Data Recovery
Recovery point and time objectives
Understand the building blocks and choices behind Backups & Data Recovery.
0 of 5 complete- In plain language
- Recovery point and time objectives is one specific set of knowledge and decisions inside Backups & Data Recovery.
- Why it matters
- Choose backup frequency, retention, isolation, and restore priority from business impact and data change rate.
- Real example
- Define recovery targets, create encrypted automated backups, restore into isolation, and verify records and application behavior.
- You understand it when
- A clean environment restores verified data within the documented recovery targets without production access.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillEncrypted backup lifecycle
Encrypted backup lifecycle
Use this part of Backups & Data Recovery in a realistic workflow.
0 of 5 complete- In plain language
- Encrypted backup lifecycle is one specific set of knowledge and decisions inside Backups & Data Recovery.
- Why it matters
- Choose backup frequency, retention, isolation, and restore priority from business impact and data change rate.
- Real example
- Define recovery targets, create encrypted automated backups, restore into isolation, and verify records and application behavior.
- You understand it when
- A clean environment restores verified data within the documented recovery targets without production access.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 4 learned
Exercise0 of 1 complete
Next sub-skillRestore verification and drills
Restore verification and drills
Handle the boundaries and prove the result for Backups & Data Recovery.
0 of 7 complete- In plain language
- Restore verification and drills is one specific set of knowledge and decisions inside Backups & Data Recovery.
- Why it matters
- Choose backup frequency, retention, isolation, and restore priority from business impact and data change rate.
- Real example
- Define recovery targets, create encrypted automated backups, restore into isolation, and verify records and application behavior.
- You understand it when
- A clean environment restores verified data within the documented recovery targets without production access.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 4 learned
Exercise0 of 3 complete
Next skillProduction Configuration Isolation
Website Vibe Coding · selected skill
OpenProduction Configuration Isolation
Runtime, region, build, and route configuration
Understand the building blocks and choices behind Production Configuration Isolation.
0 of 6 complete- In plain language
- Hosting settings that decide where code runs, how it builds, and which limits apply to each route.
- Why it matters
- A package that works in Node may fail at the edge, and the wrong region can add latency or violate requirements.
- Real example
- A Prisma route uses Node runtime near the database while a cacheable route uses the edge.
- You understand it when
- The selected runtime supports every dependency and the production build matches hosting limits.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillCORS, caching, domains, and environment separation
CORS, caching, domains, and environment separation
Use this part of Production Configuration Isolation in a realistic workflow.
0 of 6 complete- In plain language
- Rules for allowed browser origins, cached responses, custom domains, and distinct local, preview, and production settings.
- Why it matters
- Incorrect configuration can leak personalized data, block valid requests, or connect production code to test services.
- Real example
- Only the production domain may send credentialed requests, and private responses are never publicly cached.
- You understand it when
- Origin, cache, TLS, and environment tests pass independently for preview and production.
- Learn first if this is unfamiliar
- Full Stack Developer fundamentals
What to learn inside0 of 5 learned
Exercise0 of 1 complete
Next sub-skillProduction smoke checks, monitoring, and rollback
Production smoke checks, monitoring, and rollback
Handle the boundaries and prove the result for Production Configuration Isolation.
0 of 8 complete- In plain language
- Small post-deployment tests, health signals, and a rehearsed method for restoring the previous release.
- Why it matters
- A successful build does not prove login, database writes, migrations, or critical user journeys work in production.
- Real example
- After deployment, test health, login, one read, one write, error reporting, and rollback.
- You understand it when
- Critical checks pass, monitoring identifies the release, and the previous version can be restored safely.
- Learn first if this is unfamiliar
- DevOps deployment fundamentals
What to learn inside0 of 5 learned
Exercise0 of 3 complete
Roadmap completeYou reached the end of the roadmap