James WamplerandClaude Opus 5
725758ccd9
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
39 lines
1.2 KiB
Bash
Executable File
39 lines
1.2 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Shared helpers for scripts/ci/*.sh. Everything here is plain bash so the same script
|
|
# runs identically on a developer's machine and on a bare CI runner.
|
|
set -euo pipefail
|
|
|
|
log() {
|
|
echo "[$(date -u +'%Y-%m-%dT%H:%M:%SZ')] $*"
|
|
}
|
|
|
|
fail() {
|
|
echo "[$(date -u +'%Y-%m-%dT%H:%M:%SZ')] ERROR: $*" >&2
|
|
exit 1
|
|
}
|
|
|
|
# Repo root, regardless of the caller's cwd.
|
|
CI_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)"
|
|
|
|
# Prepends a locally installed .NET SDK to PATH when `dotnet` is missing, so a runner
|
|
# with no SDK preinstalled behaves the same as a dev machine.
|
|
ensure_dotnet() {
|
|
if command -v dotnet > /dev/null 2>&1; then
|
|
return 0
|
|
fi
|
|
|
|
local install_dir="$CI_ROOT/.dotnet"
|
|
if [[ ! -x "$install_dir/dotnet" ]]; then
|
|
log "dotnet not found on PATH; installing the .NET SDK"
|
|
curl -fsSL https://dot.net/v1/dotnet-install.sh -o "/tmp/dotnet-install.sh"
|
|
bash "/tmp/dotnet-install.sh" --channel STS --install-dir "$install_dir"
|
|
rm -f "/tmp/dotnet-install.sh"
|
|
fi
|
|
export PATH="$install_dir:$PATH"
|
|
export DOTNET_ROOT="$install_dir"
|
|
}
|
|
|
|
ensure_node() {
|
|
command -v npm > /dev/null 2>&1 || fail "npm not found on PATH; install Node.js to build the web client"
|
|
}
|