src/Novelly.Mcp was a separate stdio process, unbuilt by CI, that
looped back over HTTP to the same REST API the previous commit's /mcp
endpoint now calls in-process. Nothing else referenced it (not CI, not
Docker, not the AppHost), so removal is just the project, its solution
entry, and scripts/publish-mcp.sh.
Updates .mcp.json / .mcp.json.example to the type: http form, fixes
.claude/agents/outline-importer.md's already-stale tool references
(list_projects/create_project/etc. never existed; the real names are
list_novels/create_novel/etc.), and rewrites README + CLAUDE.md's
description of the MCP surface and how to verify it at runtime.
MCP server is a stdio process run outside docker, pointed at the API
over HTTP via NOVELLY_API_URL. The api container previously had no
port mapping, so it was unreachable outside the compose network.
Program.cs: wrap the boot-time MigrateAsync in try/catch (was an unhandled
exception into a restart:unless-stopped crash-loop), log critical and exit(1)
on failure, and add a --migrate-only flag that applies migrations then exits
0 without starting the web host.
deploy.sh: run migrations as a preflight via the new --migrate-only image
against the live novelly-data volume, before the running (old-image) stack
is touched. A failing migration now aborts the deploy with the old
containers still serving traffic, instead of swapping to a crash-looping
new container first and finding out from the health-check timeout.
Dual-engine workflow (.github/workflows/ci.yml, read by both GitHub Actions
and Gitea Actions): build, test, coverage badge on every push; on Gitea main
pushes only, build+push API/web images to the Gitea registry and redeploy
the persistent LAN stack via the shared [self-hosted, qa] runner. Replaces
the ad hoc docker-compose.deploy.yml manual workflow with
deploy/qa/docker-compose.qa.yml, pulled by CI — data volume preserved
across deploys (no -v on down), unlike mic-check's throwaway QA stack.
Aspire doesn't run or manage src/Novelly.Mcp — it's a separate stdio
process the MCP client spawns from a published binary that nothing
rebuilds automatically. It had drifted 12 days out of date and was
silently missing the service-API-key auth header, causing confusing
401s. Script wraps the existing dotnet publish command via the shared
ensure_dotnet helper; README points at it instead of the raw command.
Also registers a UserSecretsId on Novelly.Api so Auth:ServiceApiKey
can be set locally without landing in appsettings.
Introduces accounts (ASP.NET Identity + cookie auth), four global
roles (Admin/Writer/Editor/Reviewer), per-novel ownership and grants
via ProjectMember, and a service-API-key principal for the MCP server
and background import jobs. Enforcement lives in the application
services (not endpoint filters) so the embedded agent and MCP tools,
which call the same services directly, can't bypass it. Web client
gets a login page, session-aware routing, and a People section for
managing per-novel access.
Also includes prior in-flight changes from this branch (CLAUDE.md
compliance pass, dev-deploy docker-compose setup) that were
uncommitted when this feature work started.
A git hook runs with a stripped PATH, so `command -v dotnet` missed the SDK
that was already installed and ensure_dotnet fell through to downloading one.
It asked for the current channel, got .NET 9, and failed every project in the
solution with NETSDK1045 — the build only breaks when the hook actually runs,
which is precisely when it is least welcome.
ensure_dotnet now looks in DOTNET_ROOT and the usual per-user and system install
locations before downloading anything, and the download is pinned to the channel
matching the repo's TargetFramework rather than whatever is current.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S56bfZMGe1hnhpWP4CjjNw
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
James Wampler