build-oxpecker-web-app

Build Oxpecker Web App

Use Oxpecker's endpoint-routing model deliberately. Its F# DSL sits on ASP.NET Core Endpoint Routing, so native endpoint metadata and middleware behavior remain part of the application contract.

Source Check

Inspect the existing host, endpoints, middleware, project references, tests, and configuration. Use the Oxpecker documentation and ASP.NET Core routing documentation when local evidence does not answer the question.

Workflow

1. Confirm Oxpecker is selected through dotnet:choose-fsharp-web-framework.
2. Model one endpoint as an EndpointHandler: validate or bind input, invoke a focused domain operation, and produce the response.
3. Use EndpointMiddleware for a reusable pipeline concern with an explicit before/after or short-circuit behavior. Do not use it as a generic service locator or business-rule container.
4. Keep route patterns, HTTP methods, authorization requirements, tags, and other endpoint metadata co-located enough to review as one API contract.
5. Continue using ASP.NET Core for host configuration, authentication, authorization, logging, and cross-cutting middleware. Preserve its pipeline ordering when introducing Oxpecker endpoints.
6. Test domain behavior independently and endpoint behavior for routing, binding, status, metadata, authorization, and serialized response contracts.

Validation

Use the smallest project-level validation available, normally:

dotnet build <web-project.fsproj>
dotnet test <test-project.fsproj>

Boundaries

• Keep .fsproj file ordering explicit and preserve Task boundaries at the HttpContext edge.
• Do not assume Giraffe handlers or middleware map mechanically to Oxpecker; migrate only with an explicit route and test-contract review.
• Use the official Azure Skills plugin for Azure architecture, provisioning, diagnostics, and deployment decisions.