Add a first-class bring-your-own-web-app path to the docs

Fulora's current docs describe the greenfield template path well, but
teams with an existing web product still have to infer too much of the
adoption model from scattered bridge, hosting, and CLI references. This
change adds a dedicated BYO-web-app quickstart plus a fuller guide, and
links that path from the README and docs index so existing-product teams
can find the right entrypoint immediately.

Constraint: Keep the docs aligned with the current shipped DX path rather than speculating about future commands that do not exist yet
Constraint: Preserve the main greenfield onboarding path while adding a parallel existing-web adoption path
Rejected: Fold all BYO guidance into Getting Started only | would over-expand the default onboarding path and bury the most relevant guidance for migration/adoption teams
Rejected: Write only a deep long-form guide | users also need a short top-level entrypoint that explains the adoption model quickly
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Maintain both quickstart and full-guide versions of the BYO-web-app story so README/index can stay concise while the deeper guide stays thorough
Tested: `dotnet test tests/Agibuild.Fulora.UnitTests/Agibuild.Fulora.UnitTests.csproj --filter "FullyQualifiedName~DocumentationGovernanceTests" -v minimal` (28 passed)
Tested: `dotnet docfx docs/docfx.json` (succeeded)
Not-tested: Public reader comprehension of the new guidance without user research
Related: 95c22d0

Author: Hongwei-MB

README.md

@@ -28,6 +28,41 @@ Need a little more than just a WebView? Fulora gives your app typed app services
 
 Go deeper with [Getting Started](docs/articles/getting-started.md), the [Documentation Index](docs/index.md), [Bridge guide](docs/articles/bridge-guide.md), and [SPA hosting](docs/articles/spa-hosting.md).
 
+## Already have a web app?
+
+You do not need to rebuild your frontend to adopt Fulora.
+
+The recommended path is:
+
+1. keep your existing React/Vue/Next-style web app
+2. point Fulora at your dev server during development
+3. switch to embedded or packaged static assets in production
+4. add native capabilities gradually through typed app services
+
+In development, that usually looks like:
+
+```csharp
+webView.EnableSpaHosting(new SpaHostingOptions
+{
+    DevServerUrl = "http://localhost:5173"
+});
+
+await webView.NavigateAsync(new Uri("app://localhost/index.html"));
+```
+
+Your frontend can then use generated services such as:
+
+```ts
+import { services } from "./bridge/client";
+
+const profile = await services.userProfile.get();
+```
+
+Start here:
+
+- [Bring Your Existing Web App — Quick Start](docs/articles/bring-your-own-web-app-quickstart.md)
+- [Bring Your Existing Web App](docs/articles/bring-your-own-web-app.md)
+
 If you want a different onboarding path:
 
 **Alternative (template only):**

docs/articles/bring-your-own-web-app-quickstart.md

@@ -0,0 +1,91 @@
+# Bring Your Existing Web App to Fulora — Quick Start
+
+If you already have a React, Vue, or similar web application, you can adopt Fulora without rewriting your frontend.
+
+The recommended path is:
+
+1. keep your existing web project
+2. add a lightweight Avalonia + Fulora desktop host
+3. connect the host to your web dev server in development
+4. add native capabilities gradually through typed services
+
+## Development model
+
+In development, your web app continues to run through its normal dev server:
+
+```bash
+cd app/web
+npm run dev
+```
+
+Your Fulora host points to it:
+
+```csharp
+WebView.EnableSpaHosting(new SpaHostingOptions
+{
+    DevServerUrl = "http://localhost:5173"
+});
+
+await WebView.NavigateAsync(new Uri("app://localhost/index.html"));
+```
+
+That keeps HMR and the existing frontend workflow intact.
+
+## Production model
+
+In production, switch to embedded or packaged static assets:
+
+```csharp
+WebView.EnableSpaHosting(new SpaHostingOptions
+{
+    EmbeddedResourcePrefix = "wwwroot",
+    ResourceAssembly = typeof(MainWindow).Assembly
+});
+
+await WebView.NavigateAsync(new Uri("app://localhost/index.html"));
+```
+
+The same `app://localhost/...` surface works in both development and production.
+
+## Add native capabilities only where needed
+
+Expose host capabilities through typed bridge services:
+
+```csharp
+[JsExport]
+public interface IUserProfileService
+{
+    Task<UserProfileDto> Get();
+}
+```
+
+Use them from the frontend through the generated app-service surface:
+
+```ts
+import { services } from "./bridge/client";
+
+const profile = await services.userProfile.get();
+```
+
+## Best practices
+
+- keep your existing frontend framework and structure
+- use the dev server in development
+- use packaged assets in production
+- keep generated bridge files under `src/bridge/generated`
+- let app code use `services.*`, not raw RPC calls
+- use preflight checks before development and packaging
+
+## Useful commands
+
+```bash
+fulora dev --preflight-only
+fulora package --profile desktop-public --preflight-only
+fulora generate types --project ./app/bridge/MyProduct.Bridge.csproj
+```
+
+## Next step
+
+For the full recommended structure, integration steps, and troubleshooting guidance, see the full guide:
+
+- [Bring Your Existing Web App to Fulora](./bring-your-own-web-app.md)