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
- Confirm Oxpecker is selected through
dotnet:choose-fsharp-web-framework.
- Model one endpoint as an
EndpointHandler: validate or bind input, invoke a
focused domain operation, and produce the response.
- 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.
- Keep route patterns, HTTP methods, authorization requirements, tags, and
other endpoint metadata co-located enough to review as one API contract.
- Continue using ASP.NET Core for host configuration, authentication,
authorization, logging, and cross-cutting middleware. Preserve its pipeline
ordering when introducing Oxpecker endpoints.
- 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.
1---2name: build-oxpecker-web-app3description: Build or modify an Oxpecker web application in idiomatic F#, using endpoint routing, functional EndpointHandler and EndpointMiddleware composition, ASP.NET Core metadata, and focused endpoint tests.4---56# Build Oxpecker Web App78Use Oxpecker's endpoint-routing model deliberately. Its F# DSL sits on ASP.NET9Core Endpoint Routing, so native endpoint metadata and middleware behavior remain10part of the application contract.1112## Source Check1314Inspect the existing host, endpoints, middleware, project references, tests, and15configuration. Use the [Oxpecker documentation](https://lanayx.github.io/Oxpecker/src/Oxpecker/)16and [ASP.NET Core routing documentation](https://learn.microsoft.com/aspnet/core/fundamentals/routing)17when local evidence does not answer the question.1819## Workflow20211. Confirm Oxpecker is selected through `dotnet:choose-fsharp-web-framework`.222. Model one endpoint as an `EndpointHandler`: validate or bind input, invoke a23 focused domain operation, and produce the response.243. Use `EndpointMiddleware` for a reusable pipeline concern with an explicit25 before/after or short-circuit behavior. Do not use it as a generic service26 locator or business-rule container.274. Keep route patterns, HTTP methods, authorization requirements, tags, and28 other endpoint metadata co-located enough to review as one API contract.295. Continue using ASP.NET Core for host configuration, authentication,30 authorization, logging, and cross-cutting middleware. Preserve its pipeline31 ordering when introducing Oxpecker endpoints.326. Test domain behavior independently and endpoint behavior for routing, binding,33 status, metadata, authorization, and serialized response contracts.3435## Validation3637Use the smallest project-level validation available, normally:3839```zsh40dotnet build <web-project.fsproj>41dotnet test <test-project.fsproj>42```4344## Boundaries4546- Keep `.fsproj` file ordering explicit and preserve `Task` boundaries at the47 `HttpContext` edge.48- Do not assume Giraffe handlers or middleware map mechanically to Oxpecker;49 migrate only with an explicit route and test-contract review.50- Use the official Azure Skills plugin for Azure architecture, provisioning,51 diagnostics, and deployment decisions.
gaelic-ghost