Reorganise by feature, rename to Novelly, add Aspire and a pre-push hook

The layered split into Domain/Application/Infrastructure/Api was forcing
organisation by layer: adding one capability meant touching four projects and
four folders that each held a slice of it. Those four projects are now one
feature-organised Novelly.Api, where each folder — Projects, Characters,
Chapters, Beats, Scenes, Tags, Agent — holds its entity, DTOs, service and
endpoints together. Common/ holds what genuinely crosses features (the patch
semantics, the two exception types, DraftStatus) and Data/ holds the DbContext
and migrations.

Six .NET projects become five: the three layer projects are gone, and
Novelly.AppHost and Novelly.ServiceDefaults are new.

- Namespaces move from NovelSoftware.* to Novelly.*, including the entity type
  names recorded in the EF model snapshots. The migration ids are untouched, so
  an existing novel.db still migrates cleanly — verified against a fresh file.
- Aspire orchestration mirrors the mic-check setup: the AppHost starts the API
  on :5080 and the Vite dev server on :5173, and the API picks up OpenTelemetry,
  health checks and service discovery from ServiceDefaults. /health and /alive
  now answer in development.
- A Husky pre-push hook runs scripts/ci/prepush.sh: build, test, then a web
  build. The scripts are plain bash so CI can run the same steps.
- The MCP server's env var is now NOVELLY_API_URL.

Verified beyond the build: 44 tests pass, the web client builds, the API was
exercised over curl (project/chapter/beat/tag round trip, tag cross-reference,
503 on the agent without a key while conversation listing still returns 200),
the MCP server was driven over stdio JSON-RPC (26 tools, errors still surface
the API's own message rather than being flattened), and the AppHost was run to
confirm both resources come up and Vite proxies /api through to the API.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S56bfZMGe1hnhpWP4CjjNw

README.md

@@ -1,4 +1,4 @@
-# Novel Software
+# Novelly
 
 Software for planning and writing a novel. You outline the book, keep character
 dossiers, break chapters into scenes, and draft prose — with a Claude-powered agent
@@ -14,23 +14,40 @@ same edit.
 
 | Piece | Built with |
 |---|---|
-| `NovelSoftware.Api` | ASP.NET Core 10 minimal APIs, OpenAPI |
-| `NovelSoftware.Application` | Services, DTOs, the agent tool-use loop |
-| `NovelSoftware.Domain` | Entities and enums, no dependencies |
-| `NovelSoftware.Infrastructure` | EF Core 10 + SQLite, Anthropic SDK client |
-| `NovelSoftware.Mcp` | MCP stdio server (`ModelContextProtocol`) |
-| `NovelSoftware.Web` | React 19, TypeScript, Vite, TanStack Query, Tailwind v4 |
+| `Novelly.Api` | ASP.NET Core 10 minimal APIs, EF Core 10 + SQLite, Anthropic SDK, OpenAPI |
+| `Novelly.AppHost` | .NET Aspire orchestration for the API and the web client |
+| `Novelly.ServiceDefaults` | Shared OpenTelemetry, health checks and service discovery |
+| `Novelly.Mcp` | MCP stdio server (`ModelContextProtocol`) |
+| `Novelly.Web` | React 19, TypeScript, Vite, TanStack Query, Tailwind v4 |
+
+The back end is one project organised by feature, not by layer. Each feature folder —
+`Projects/`, `Characters/`, `Chapters/`, `Beats/`, `Scenes/`, `Tags/`, `Agent/` — holds its
+entity, DTOs, service and endpoints together, so adding a capability means touching one
+folder rather than four. `Common/` holds what genuinely crosses features and `Data/` holds
+the `DbContext` and migrations.
 
 ## Running it
 
 Prerequisites: .NET 10 SDK and Node 20+.
 
+Everything at once, through Aspire:
+
+```bash
+cd src/Novelly.Web && npm install && cd -
+dotnet run --project src/Novelly.AppHost
+```
+
+That starts the API on :5080 and the Vite dev server on :5173, and opens the Aspire
+dashboard for logs, traces and metrics across both.
+
+Or run the two halves separately:
+
 ```bash
 # 1. API — creates and migrates novel.db on first run, listens on :5080
-ASPNETCORE_URLS=http://localhost:5080 dotnet run --project src/NovelSoftware.Api
+ASPNETCORE_URLS=http://localhost:5080 dotnet run --project src/Novelly.Api
 
 # 2. Web — dev server on :5173, proxies /api to :5080
-cd src/NovelSoftware.Web && npm install && npm run dev
+cd src/Novelly.Web && npm install && npm run dev
 ```
 
 Open http://localhost:5173.
@@ -48,16 +65,19 @@ and everything else keeps working.
 ### Tests
 
 ```bash
-dotnet test                                 # 44 tests
-cd src/NovelSoftware.Web && npm run build   # typecheck + bundle
+dotnet test                             # 44 tests
+cd src/Novelly.Web && npm run build     # typecheck + bundle
 ```
 
+`git push` runs both through a Husky pre-push hook (`scripts/ci/prepush.sh`). Install the
+hook once with `npm install` at the repo root.
+
 Tests run against real in-memory SQLite rather than the EF in-memory provider, so they
 exercise the cascade deletes and query translation the app actually ships with.
 
 ## Configuration
 
-`src/NovelSoftware.Api/appsettings.json`:
+`src/Novelly.Api/appsettings.json`:
 
 ```jsonc
 {
@@ -139,7 +159,7 @@ its own — it is a second front end, not a second implementation.
 Build it, then point your MCP client at the produced binary:
 
 ```bash
-dotnet publish src/NovelSoftware.Mcp -c Release -o ./mcp-server
+dotnet publish src/Novelly.Mcp -c Release -o ./mcp-server
 ```
 
 `.mcp.json` (or Claude Desktop's config):
@@ -147,9 +167,9 @@ dotnet publish src/NovelSoftware.Mcp -c Release -o ./mcp-server
 ```jsonc
 {
   "mcpServers": {
-    "novel-software": {
-      "command": "/absolute/path/to/mcp-server/NovelSoftware.Mcp",
-      "env": { "NOVELSOFTWARE_API_URL": "http://localhost:5080" }
+    "novelly": {
+      "command": "/absolute/path/to/mcp-server/Novelly.Mcp",
+      "env": { "NOVELLY_API_URL": "http://localhost:5080" }
     }
   }
 }