Loading page
Phase 1 · 9 modules
Orient the work: understand the agent, the machine, the program, the product decision, and the codebase that holds them together.
See a coding agent as a complete software system, then use its loop to recognize the parts of any program.
Repository patternJungle separates provider-neutral agent contracts, harness behavior, deterministic scenarios, and human approval so each guarantee has an owner.
Understand the machine and workspace your agent keeps referring to, from paths and processes to environment variables.
Builds on Agents as software systems
Repository patternCommands run with an explicit working directory, inputs, and exit status; their output is evidence, not an incantation copied without context.
Build a durable vocabulary for how programs represent information, make choices, repeat work, and fail.
Builds on The computer underneath
Repository patternOwned states use discriminated unions and exhaustive handling, while foreign values begin as unknown and are parsed before the program trusts them.
Read and control the history of a codebase so agent-made changes stay inspectable, reversible, and attributable.
Builds on The computer underneath
Repository patternTask-scoped commits preserve unrelated dirty work; worktrees give parallel agents isolation without hiding the shared repository history.
Turn an idea into a small, testable product decision before an agent turns ambiguity into code and accidental scope.
Builds on Agents as software systems
Repository patternFuture-facing work becomes a concrete plan with scope, non-goals, risks, and a stated verification method before implementation begins.
Know what a language, compiler, and runtime each contribute, and why TypeScript is a useful default rather than a universal answer.
Builds on Programming mental models
Repository patternTypeScript is the default general tool for product code; Zig or platform-native languages enter where binaries, memory, operating systems, or hardware demand control.
Read a large repository as a graph of owned boundaries, then know when shared history and atomic changes justify keeping products together.
Builds on Git and change history, Programming mental models
Repository patternApplications own product behavior, repository packages own proven cross-project foundations, and shared abstractions wait for a concrete consumer.
Treat every imported package and build tool as code you operate, update, audit, and may eventually need to replace.
Builds on Codebases, architecture, and monorepos, Languages, types, and runtimes
Repository patternOne Bun lockfile, a shared version catalog, workspace references, and direct manifest declarations make the dependency graph reproducible and inspectable.
Give coding agents durable instructions, retrievable context, narrow tasks, and verification loops that scale beyond one chat.
Builds on Agents as software systems, Git and change history, Codebases, architecture, and monorepos
Repository patternRoot and scoped AGENTS.md files route durable instructions; plans, notes, and executable checks hold context that should survive a chat window.
Phase 2 · 5 modules
Reach a person through the web: follow requests, define contracts, build interfaces, remove access barriers, and make the product discoverable.
Follow one request across the internet and understand the boundaries hidden behind a URL.
Builds on The computer underneath
Repository patternEvery public application declares its origin, routes, metadata, crawl policy, and deployable root as checked data rather than dashboard-only memory.
Make two systems cooperate through an explicit contract, then design for version drift, partial failure, duplicates, and hostile input.
Builds on How the web works, Programming mental models
Repository patternApplication-owned ports keep business behavior independent of a provider; adapters parse foreign input and expose the smallest contract the product needs.
Separate meaning, behavior, layout, and appearance, then learn the component names used in modern interface work.
Builds on How the web works, Programming mental models
Repository patternShared design foundations supply semantics and behavior, while product code composes them into page-specific components, layout, styling, and state.
Build interfaces whose meaning and operation survive different bodies, senses, input devices, languages, and network conditions.
Builds on Frontend and interface vocabulary
Repository patternPublic routes remain useful without interaction, preserve visible focus, honor reduced motion, and maintain usable targets across pointer and keyboard input.
Help browsers, search engines, social previews, and people find the right page without sacrificing a useful, accessible information architecture.
Builds on How the web works, Frontend and interface vocabulary
Repository patternA shared discovery package generates canonical metadata, robots rules, sitemaps, structured data, and social previews from one typed site description.
Phase 3 · 12 modules
Build the application boundaries: authority, identity, platforms, data, compute, asynchronous work, messaging, and money.
Develop the security instinct that browsers and model output are untrusted while the server owns authority.
Builds on APIs, contracts, and integrations, Programming mental models
Repository patternProduction and deterministic development adapters meet at an app-owned port, while secrets, authority, and untrusted input remain behind server boundaries.
Read a modern full-stack codebase without losing track of which code runs where or which data can cross the network.
Builds on Frontend and interface vocabulary, Backend and security boundaries
Repository patternNext.js applications default to server-rendered or static content and introduce client boundaries only where browser state or interaction requires them.
Separate proving who someone is from deciding what they may do, and design account recovery and revocation as first-class flows.
Builds on Backend and security boundaries
Repository patternIdentity-provider responses are foreign input; applications still own membership, authorization, recovery, deletion, and auditable sensitive actions.
Recognize what changes when software leaves the browser and must cooperate with an operating system, device hardware, signing, and app stores.
Builds on Programming mental models, Frontend and interface vocabulary
Repository patternNative work records device, operating-system, signing, and real-hardware verification instead of treating a simulator or web preview as final proof.
Choose a data model and database by where the data lives, how it changes, and who needs a consistent view.
Builds on Programming mental models, Backend and security boundaries
Repository patternLive data services and deterministic scenarios implement the same application-owned port, so tests simulate product behavior rather than impersonate a vendor client.
Know why you collect each piece of data, where it travels, how long it remains, and how a person can export or erase it.
Builds on Data and databases, Identity, authentication, and authorization
Repository patternData decisions name purpose, authority, retention, deletion propagation, backup behavior, regional constraints, and the evidence that each promise works.
Put bytes in the right place and predict the bill before images, audio, and downloads become expensive.
Builds on How the web works, Data lifecycle, privacy, and compliance
Repository patternBlob decisions compare access control, retrieval path, cache behavior, ingress, egress, and dated provider pricing before choosing an implementation.
Distinguish a server from a deployment model and recognize where state, concurrency, and background work can live.
Builds on How the web works, Backend and security boundaries
Repository patternEach deployable directory is an independently registered project with an explicit root, runtime, region, and dependency graph inside the monorepo.
Move slow or failure-prone work off the request path without losing jobs, repeating side effects, or hiding an inconsistent state.
Builds on Servers, serverless, and edge compute, Data and databases, APIs, contracts, and integrations
Repository patternDurable workflows own idempotency keys, retry state, reconciliation, concurrency bounds, and a deterministic way to reproduce every transition.
Treat an AI model as probabilistic external compute, then design the product contract, evidence, privacy, and fallback around it.
Builds on Agents as software systems, APIs, contracts, and integrations, Data and databases, Queues, schedules, and background work
Repository patternProvider-neutral model contracts make paid and probabilistic calls explicit, while deterministic scenarios test product behavior without pretending a fake model proves output quality.
Send email, push, text, and in-product messages as durable product workflows with consent, delivery state, and provider failure in view.
Builds on Queues, schedules, and background work, Identity, authentication, and authorization
Repository patternProvider delivery events pass through an owned boundary and become product state only after signature checks, deduplication, and consent rules.
Model money as an externally settled workflow whose retries, disputes, taxes, refunds, and entitlements must remain reconcilable.
Builds on Queues, schedules, and background work, Identity, authentication, and authorization, Data and databases
Repository patternSettlement remains provider-owned while orders and entitlements remain application-owned; signed events and reconciliation repair disagreement between them.
Phase 4 · 8 modules
Earn confidence in production with configuration, tests, telemetry, analytics, reliability engineering, delivery, operations, and cost control.
Make behavior vary deliberately across environments without baking secrets into code or creating an unknowable combination of switches.
Builds on Servers, serverless, and edge compute, Dependencies, builds, and supply chains
Repository patternForeign configuration is parsed into a typed state at startup, secrets are scoped, and every temporary flag has an owner and removal condition.
Replace ‘it seems to work’ with a stack of evidence that helps both people and agents find the next failure.
Builds on Programming mental models, Git and change history, Dependencies, builds, and supply chains
Repository patternConcrete examples prove named cases, property tests search broad input spaces, and deterministic application scenarios expose states that browser control alone cannot create.
Ask new questions of a running system by correlating the signals it emits, while controlling noise, sensitive data, cardinality, and telemetry cost.
Builds on Servers, serverless, and edge compute, Testing, debugging, and proof
Repository patternOperational signals preserve correlation across browser, server, job, database, and provider boundaries while explicitly limiting cardinality, secrets, and retention.
Measure whether people reach the intended outcome without confusing product behavior with system health or collecting data without a decision to make.
Builds on Product definition and scope, Data lifecycle, privacy, and compliance, Observability, telemetry, and alerting
Repository patternA product event exists only when its contract, decision, identity rules, consent, deletion path, and server-versus-client source of truth are named.
Design for the ordinary failures of networks, concurrency, overload, and change, then choose explicit reliability targets instead of promising perfection.
Builds on Servers, serverless, and edge compute, Data and databases, Observability, telemetry, and alerting, Testing, debugging, and proof
Repository patternUncertainty becomes a focused property, fault, load, concurrency, or recovery test, with reliability targets stated before extra machinery is added.
Move a reviewed change through repeatable checks into the right environment, then make promotion, rollback, and provenance visible.
Builds on Git and change history, Dependencies, builds, and supply chains, Configuration, secrets, and feature control, Testing, debugging, and proof
Repository patternRepository checks reproduce the supported command surface, deployment projects are checked data, and current-head production proof closes the release loop.
Prepare the people and mechanisms that restore service when production behaves differently from every local and preview environment.
Builds on Observability, telemetry, and alerting, Reliability, performance, and scale, CI, releases, and deployment
Repository patternReadiness means named ownership, observable failure modes, rollback and restore procedures, capacity evidence, and a practiced route to disable risky behavior.
Connect architecture to a dated cost model, an exit path, and the human work required to operate each provider you adopt.
Builds on Servers, serverless, and edge compute, Files, blobs, and cloud costs, Production operations and incidents
Repository patternProvider choices record dated prices and limits, workload assumptions, operational cost, failure exposure, portability, and a measurable reevaluation trigger.
Phase 5 · 1 module
Ship one small product end to end and defend its behavior, security, recovery path, evidence, and operating cost.
Use a coding agent to specify, build, test, ship, and observe one small product while keeping every trust boundary visible.
Builds on Product definition and scope, Frameworks and full-stack Next.js, Data lifecycle, privacy, and compliance, Testing, debugging, and proof, Observability, telemetry, and alerting, CI, releases, and deployment, Production operations and incidents, Costs, capacity, and vendor decisions
Repository patternThe final evidence bundle contains the specification, threat and data model, dependency rationale, tests, preview review, production telemetry, recovery drill, and cost model.
11 primary references · reviewed 2026-07-26
The sequence is grounded in standards-based web education and the practices used to operate contemporary production systems. Product names appear as dated examples; the durable concept comes first.
Defines a standards-based core for semantic HTML, CSS, JavaScript, accessibility, design, and collaboration without binding the learner to one framework.
Provides a current full-stack teaching sequence that reaches testing, containers, relational data, continuous delivery, and typed application development.
Distinguishes monorepos from monoliths and explains shared-code, atomic-change, dependency-graph, and repository-boundary tradeoffs.
Frames dependencies, build systems, package registries, provenance, and automated updates as parts of the software supply chain.
Supplies a verification-oriented map of application security controls that is broader and more testable than a short vulnerability checklist.
Organizes generative-AI work around measured risks, documented system boundaries, testing and evaluation, human oversight, privacy, security, and incident learning.
Defines the operational signals behind modern observability—traces, metrics, logs, and baggage—and how correlation creates useful context.
Explains the current delivery-performance metrics and the need to interpret speed, recovery, failure, and reliability together rather than optimize one number.
Describes production readiness as an explicit review of architecture, failure modes, capacity, monitoring, emergency response, and operational ownership.
Grounds user-facing performance in measurable loading, interaction, and visual-stability outcomes rather than framework-specific optimization folklore.
Documents how deployment roots, dependency graphs, ignored builds, and project boundaries interact when applications ship from a monorepo.
Interface vocabulary · 199 names
A component has semantic purpose, behavior, state, and an API. Layout places it. Styling changes its visual treatment. State describes its current condition. A button in a flex row with green rounded corners is still one button, one layout decision, one style, and several possible states.
Containers establish reading order, spatial relationships, and responsive behavior. They are not interactive controls by themselves.
Navigation changes the user’s location or visible destination. A link goes somewhere; a button does something.
Action controls change state, submit work, or reveal another control surface.
Inputs collect a value. The field includes its label, help, validation message, and state, not only the control.
These components present information. Some become interactive composites when they add selection, editing, or navigation.
Feedback reports what happened, what is happening, or what the system needs from the user.
These patterns reveal secondary information or place a temporary layer above the current context.
Page patterns combine many components into a familiar job or workflow.
State is the condition represented now. It is separate from the component’s structure and its visual styling.