68 Commits

Include renames

Author	SHA1	Message	Date
timothy	628ae46f7f	fix(622): bind H10 merge consent to the reviewed sha via a required commit status ... `pretooluse-merge-consent.sh` proves all three consent conditions at the moment the merge tool is called. With `merge_when_checks_succeed=true`, condition (a) is delegated to Gitea, which then merges whatever head is green at ITS merge time — while (b) Done-when and (c) the head-referencing verdict were proven against the head at SCHEDULING time. Every commit pushed in between merges unreviewed. The gate is not bypassed; it is satisfied against a snapshot that stops being true. Demonstrated as a controlled A/B rather than inferred, with a CI check left pending so Gitea waits as it really does: without a required verdict context: unreviewed commit B MERGED with it: same sequence REFUSED after reviewing B and posting it: merges — blocked, not deadlocked NOTE the anecdote in #622 is wrong and is corrected in the docs rather than repeated: PR #619 does carry `Review-verdict: MERGEABLE @ 02c82b35`, posted six seconds before the merge, explicitly re-reviewing the follow-up commits. #622 was filed off a lagging API read. The hole is real regardless, and structural — nothing FORCED that re-review inside the window Gitea would have merged in. This turns a property that held by diligence into one that holds by construction. The fix is the sha, not a smarter check. A Gitea commit status belongs to exactly one commit, so a status written for a parent cannot be inherited by a child that did not exist yet. `review-verdict/h10` becomes a REQUIRED status check on main: push a new head and the context is simply absent, which Gitea reads as not-passing (verified against 1.25.4: missing AND pending both block, and auto-merge re-checks the current head). It also covers merge paths the hook never sees — Gitea UI, raw API, another agent's session. - scripts/post-review-verdict.sh writes the comment and the status together so they cannot drift, and re-reads head after commenting: if a commit landed mid-flight it writes NO status and exits non-zero rather than retargeting the verdict at a commit nobody read. - .gitea/workflows/review-verdict.yml auto-passes the two exempt classes that would otherwise deadlock — Renovate-authored (platformAutomerge) and docs-only — and marks everything else pending. Exemptions are void when the PR touches .claude/, .gitea/, .husky/, scripts/ or docker/ci/. - The hook refuses to SCHEDULE an auto-merge unless that status is green on head, and no longer claims "CI green" on the mwcs path, where it never read CI. Two silent false negatives in the exemption path, both found by verifying rather than reasoning, both fixed at BOTH call sites (workflow and the hook's pre-existing docs-only carve-out): - The files endpoint caps at 50 rows and IGNORES a larger `limit` — PR #619 has 194 changed files and `?limit=100` returns 50. A single page saw ZERO protected paths there where the full enumeration finds ten. Both now page to exhaustion and withhold the exemption if they cannot complete. - A rename is ONE row whose `filename` is the destination, the source only in `previous_filename`. Verified live: `.gitea/workflows/renovate.yml` -> `docs/innocuous-note.md` presented as docs-only with no protected path visible. Both now read BOTH sides. Limits are documented, not papered over: base changes leave the head sha (and so the verdict) unchanged, and a PR editing the workflow is judged by its own edited copy — so PROTECTED is a guardrail against accident, not a tamper-proof control. fixes #622	2026-07-25 21:51:02 +02:00
timothyandClaude Opus 5	f49556b6ef	docs(609): qualify the two ci-cd.md mentions as non-merge ... Last review Low, marked safe-to-defer but it is two words in a file this PR already edits. Both prose mentions of the marker now say "non-merge commit", matching the decision Rule, the catalog, the module comment and the function docstring. Docs-only. fixes #609 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 18:40:55 +02:00
timothyandClaude Opus 5	c597c49f02	fix(609): arm the decisions body-diff with a git trailer, not a bare substring ... The rationale-edit exemption was a substring test over the whole commit range, so any message containing the literal marker armed it -- including prose explaining why no marker was needed, which is how it fired live in PR #605: a green --base/--head run that was vacuous on the body-diff dimension, in the one PR that hand-resolved a merge conflict inside the corpus the guard exists to police. Now read as an affirmative `Decisions-Edit:` git trailer. Git parses trailers only in the final paragraph, so a quoted example message cannot arm it -- which matters because this commit and its decision record both quote one. A non-affirmative value (`no`) does not arm it either; the retired substring arms nothing and gets a ::warning:: nudge. Tests: negative controls (prose mention, quoted mid-body trailer, `no` value, retired substring) plus positive controls (trailer, uppercase, alongside Co-Authored-By). All four negative controls verified red against the old matcher. fixes #609 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 18:21:12 +02:00
timothy	5dd0b147e8	docs(445): record that rebasing invalidates the CI toolchain image pin ... Hit this for real on this branch. `ci-image-pin` went red after a rebase that was otherwise clean, and the failure is confusing on three counts: - the pin must equal the short sha of the commit that touched docker/ci, and a rebase REWRITES that sha (e9fd26f6 -> 9130274c here); - the pin still resolves to a real commit and the tagged image still exists in the registry, so nothing looks broken; - the force-push does NOT republish: ci-image.yml filters on `paths: docker/ci/**`, and a rebase that leaves the Dockerfile's content unchanged produces no diff for that path. And it cannot be fixed by re-dispatching ci-image.yml, because that tags `git rev-parse --short HEAD` — the branch HEAD, not the commit that touched docker/ci. The two coincide only when the docker/ci commit IS HEAD, which is why the original two-step worked and the post-rebase state does not. Recorded in docs/ci-cd.md with the recovery, plus the cheaper lesson: land a toolchain-image change on its OWN branch first, so the consuming branch never carries the docker/ci commit through a rebase. This commit is also the recovery itself — it touches docker/ci, so it becomes the commit ci-image.yml tags, restoring the pin dance. Refs #445	2026-07-25 14:04:52 +02:00
timothy	f7fa57c816	docs(445): fix dangling decision key + clarify UI-E2E step reference [decisions-edit] ... Two review findings from the cold docs/convention pass. HIGH — the new `ci.ui-e2e-harness` record cited `` `ci.toolchain-image` `` as if it were a resolvable decision key. No such key exists anywhere in the corpus (verified: the only occurrence in all of docs/ was that citation itself). #390's toolchain-image work was deliberately never migrated to a standalone record — `ci.runner-placement`'s own Signals line says so. This is exactly the breadcrumb hazard docs/README.md -> "Knowledge retrieval" warns about: a future session (or a MemPalace lookup) resolving that key gets nothing back, and cannot distinguish "retired" from "never existed". Replaced with an explicit pointer to #390, `ci.runner-placement`, and docs/ci-cd.md, and stated outright that #390 has no standalone record. Swept the whole class rather than the one instance: every dotted key cited in added lines across the diff now resolves (ci.functional-e2e-harness, ci.runner-placement, ci.ui-e2e-harness). NIT — docs/ci-cd.md said the UI-E2E step is "Step 4 of this same job", which refers to the doc's own 4-item prose summary, not the YAML step list (where it is the 11th `steps:` entry). Reworded to name the actual step so a reader skimming the workflow isn't sent looking for a 4th YAML step. Refs #445	2026-07-25 14:03:59 +02:00
timothy	d8c0b3e752	feat(445,533): headless Playwright UI-E2E flows + fix e2e-local readiness probe [decisions-edit] ... Adds the last deferred #299/#363 follow-up: the flows that CANNOT be expressed as curl calls. Scope rule (the durable part) — assert only what the curl harness structurally cannot reach: 1. client-side form validation (the Setup confirm-password gate is pure React state and makes no request, so there is no HTTP contract to assert) 2. AuthGate's RENDERED states (Setup vs Login vs app) 3. the session cookie authenticating the SPA's OWN /api XHRs — curl proves the cookie works for curl, not that the app sends it 4. sign-out through the UserMenu back to the login gate New: web/e2e/boot-gate.spec.ts, web/playwright.config.ts, scripts/e2e-ui.sh (owns the whole lifecycle: fresh config dir -> boot -> specs -> always kill). Runs as a second step of the EXISTING advisory `functional-e2e` job rather than a new job: the dominant cost there is `npm ci` + the Release build, both already done, so this adds ~5s instead of duplicating a heavy job. It boots its own fresh instance on port 8410 because the first spec asserts the one-shot Setup gate that the curl step has already claimed on its config dir. Determinism (the issue asked for it explicitly): `serial`, `workers: 1`, `retries: 0` even in CI — a retry would let a flaky flow merge looking green. Measured 5 consecutive clean runs, ~2s each. Pins all five `container:` jobs to the toolchain image built by the preceding commit, which bakes `chromium-headless-shell`. Non-obvious coupling fixed: vitest's default include glob would have collected web/e2e/*.spec.ts and run it under jsdom. Excluded `e2e/**` by spreading `configDefaults.exclude` rather than narrowing `include` to `src/**`, because web/scripts/ holds a real vitest test an src-only include would silently stop running. `RebuildSearchIndexHandler` logs one of two mutually-exclusive lines just before `SystemStartup.SearchIndexIsReady()`: fresh config -> "Done migrating search index in {Duration}" reused config -> "Search index is already version {Version}" The probe watched only the first, so a reused dir waited out the full 120s timeout and then killed a perfectly healthy server. Widened to a `grep -Eq` alternation; the handler's if/else is exhaustive, so the pair covers every path to readiness. Verified with a negative control: on a reused dir the server is ready in 2s via the "already version" line, and the OLD probe string is genuinely ABSENT from that run's log — so the old code would have hung, i.e. the fix is load-bearing rather than incidentally passing. The "prefer a fresh config dir" guidance stays: that guards state bleed, which is a separate concern from the probe hanging. - `wait "$PID"` in the cleanup trap was a NO-OP: the server is a grandchild (launched in e2e-local.sh's subshell, which then exits), so `wait` fails instantly and was swallowed by `|| true` — cleanup did not actually ensure the port was released, exactly what its comment claimed. Replaced with a bounded `kill -0` poll, then SIGKILL. - Added a port pre-flight check: previously an occupied port surfaced as a 120s readiness timeout that reads like a broken build. Now fails in 0s naming the PIDs, and warns against blanket-killing `dotnet ErsatzTV.dll` (that reaps other sessions' servers). - UI-E2E: 5x clean (3 specs, ~2s); back-to-back runs pass with no manual cleanup - curl harness unaffected by the boot-script change: 45/45 PASS - web: 983 tests / 105 files green; typecheck + lint clean - vitest collection verified: excludes web/e2e, still collects web/scripts - Dockerfile sequence + browser launch validated verbatim in a container on the real amd64 base before committing; chromium launches as root with NO sandbox opt-out needed - decisions validator green; catalog regenerated - docs/decisions.md TOC repaired: it had drifted to 69 of 97 records and held a dangling anchor to the #72 record that #415 superseded into archive/. Regenerated with a generator validated against the 68 existing anchors (0 mismatches) -> 97/97, no dangling, no duplicates. Docs: docs/e2e-local.md (new "UI-E2E harness" section), docs/ci-cd.md (toolchain image + UI-E2E step), docs/testing.md, docs/README.md, docs/decisions.md (new `ci.ui-e2e-harness` record; `ci.functional-e2e-harness` amended — its Rule said "curl-only", now accurate). Refs #445 #533	2026-07-25 14:03:59 +02:00
timothyandClaude Opus 5	c8e79f49f4	chore(586,594,485): PID-scoped E2E cleanup, ci-image-pin length guard, .gitignore core fix ... Three independent CI/repo-hygiene fixes swept together; disjoint file sets. fixes #586 — E2E cleanup is scoped by PID, never a pattern-wide pkill - New decision record `testing.e2e-cleanup-scope-by-pid`. - docs/e2e-local.md states the constraint where a BRIEF-WRITER sees it (the #586 root cause was a delegation gap, not agent error). - scripts/e2e-local.sh: reviewed against e2e-ui.sh's trap lifecycle and deliberately does NOT adopt it — its contract is to hand a running instance back to its caller, so an EXIT trap would kill the server the instant the launcher returned (both callers use `OUT="$(e2e-local.sh ...)"`). Recorded. - Instead it gains what actually prevents the incident: an lsof pre-flight that NAMES a foreign listener's PID rather than letting Kestrel fail its bind and surface as "process N exited before becoming ready". - Pre-flight probes BOTH bound ports, and ETV_STREAMING_PORT now defaults to ETV_UI_PORT. Program.cs binds a second listener whose port defaults to 8409 independently of ETV_UI_PORT, so `ETV_UI_PORT=8420` alone still bound 8409 and died against a foreign holder — i.e. the documented escape hatch was a dead end that led straight back to the confusion behind the pattern kill. fixes #594 — ci-image-pin accepts any hex length - Length is a separate invariant from correctness: the resolve/staleness checks compare resolved shas, so an 8-char pin of the right commit passes green while matching NO registry tag, and all five container: jobs then die at image-pull with `manifest unknown` (reads like a registry outage). - Guard fails at the gate and prints the exact tag to use. Verified against doctored pins: 7 green; 6/8/10 red. - Uses a literal 7 rather than a derived `--short=7`: in a full clone git may widen an ambiguous abbreviation, demanding a pin ci-image.yml can never publish. Escape hatch documented inline. - Also fixes a pre-existing misdiagnosis: zero pins reported "MORE THAN ONE". - docs/ci-cd.md documents the 7-char rule and `git rev-parse --short=7 HEAD`. fixes #485 — .gitignore `core` silently ignored `*/Core/` files - A bare `core` matched any path component named `core`; case-insensitively on macOS that swallowed every `*/Core/` SOURCE dir, so new untracked files were dropped by `git add -A` while tracked ones stayed fine — a clean local build and a CI checkout that fails to compile. - Now `/core` + `/core.[0-9]*`, both anchored (an unanchored `core.[0-9]*` would re-introduce the same silent-exclusion class this fixes). - Verified by diffing the full ignored-file set before/after: identical, and the three real Core/ dirs are trackable without -f. Docs updated in-PR: docs/e2e-local.md, docs/ci-cd.md, docs/decisions/ workflow-process.md (+ regenerated catalog), docs/handoffs/chicorytv-issue-queue.md. Follow-ups filed: #596 (the same shared-host reap in the Playwright-MCP recovery record) and the ci-image.yml `--short=7` publisher-side fix, which cannot ride this PR — editing ci-image.yml re-points ci-image-pin's `expected` at this commit and reds the gate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 12:46:13 +02:00
timothyandClaude Opus 4.8	b4ac46fce1	ci(535): split PR-only git gates into pr-checks.yml so release tags don't red ... Three PR-only git-diff gates (ci-image-pin, docs-reminder, decisions-guard) lived in docker-build.yml, which also triggers on push to main and v* tags. Gitea dispatches a job as a runner task even when its `if` skips it, so on every tag/main push these three were dispatched to the `small` lane just to evaluate the skip. On the v26.12.0 tag those dispatched skip-tasks wedged in act's setup phase and were killed by a runner restart mid-setup, reporting `failure` (no logs) and reddening the tag's overall commit status even though the release built, scanned, and deployed fine. The two identical-`if:` jobs on ubuntu-latest (api-docs, format) skipped cleanly — the job logic was never the problem; the kill lands in the dispatch window before any step or skip runs, so tweaking the `if:`/step logic could not fix it. Relocate exactly those three (pure checkout + git-diff, no container:, no image pin) verbatim into a dedicated pr-checks.yml that triggers `on: pull_request` only. Gitea evaluates a workflow's trigger before creating any job, so on a tag/main push this workflow produces zero jobs: no dispatch, no kill, no spurious red — for the whole class, permanently. - ci-image-pin carries no pin and still greps docker-build.yml, where all five pin-bearing jobs (test/migrations/functional-e2e/api-docs/format) remain, so its validation is unchanged. - None of the three are required checks (only Build & test + EF migration integrity are), so the status-context prefix change (Build ErsatzTV Image / ... -> PR Gates / ...) does not affect merges; the merge-consent hook reads the prefix-agnostic combined status. - pr-checks.yml declares `defaults: run: shell: bash` (ci-image-pin uses mapfile / set -o pipefail). docs/ci-cd.md: new "PR gates workflow" section + cross-references. fixes #535 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 18:07:56 +02:00
timothyandClaude Opus 4.8	6148805e37	docs(release): v26.12.0 headline — ErsatzTV MCP server (#58) + external-logo download (#525) ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 16:47:20 +02:00
timothyandClaude Opus 4.8	962dc2a31a	feat(520): parallel orientation+selection startup; retire #237 as live state; #642 retrieval bullets [decisions-edit] ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 11:48:14 +02:00
timothyandClaude Opus 4.8	f93458c76c	fix(521): whole-branch review — correct Gitea anchors, guard archive+demotion, reciprocal links, stale append-only refs, budget warning [decisions-edit] ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 03:00:15 +02:00
timothyandClaude Opus 4.8	b1e7e08884	feat(521): rework decisions guard — lifecycle validator + narrow [decisions-edit]; header + CI rewrite [decisions-edit] ... Retire the line-level append-only mechanic (ersatztv#303 H9) in favor of the lifecycle validator built in Tasks 1-5. .claude/hooks/decisions-guard.sh is now a thin fail-open shim around scripts/decisions_validate.py; .husky/pre-commit calls it for the structural (working-tree) checks, .husky/commit-msg drops the old staged/[decisions-edit]-deletion block and keeps only the Co-Authored-By check. The Gitea decisions-guard job is renamed "decisions lifecycle" and now runs decisions_validate.py --base/--head (structural + body-diff + no-vanish) and build_decisions_catalog.py --check (active catalog drift), with actions/setup-python@v5 added since the bare `small` lane doesn't guarantee python3; the old 1800-line consolidation-floor step is removed (replaced by the validator's aggregate active-corpus budget). docs/decisions.md's header is rewritten from append-only to lifecycle framing (metadata schema, statuses, generated catalog, archive, same-PR supersession); [decisions-edit] is re-scoped (not removed) to rationale-prose edits/factual corrections only. docs/ci-cd.md's release ritual and hook/job descriptions are rewritten to match. Also fixes a pre-existing validator false-positive surfaced while sanity-checking against origin/main: Task 6's #303 H9/H3 split (commit d09be57e) renamed the archived record's heading away from the pre-split original, which the validator's heading-based relocation check reads as "removed without an archive copy." Restored the archived heading to match the original text (functionally unchanged — still status: superseded, same key) and updated the two prose cross-references (migration-map.md, release-ci-governance.md) that pointed at the old anchor. PR1 scope only (per brief): does NOT wire the kickoff-guard CI step or touch the kickoff/README/select-queue docs — that's Task 8/PR2. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 03:00:15 +02:00
timothy	7248416bd6	docs(release): Komodo stack is jazz-media; no auto-update fallback ... Verified live while promoting v26.11.0. Two corrections: 1. `DeployStack media-servers` targets a DEAD stack. The Komodo stack name changed to `jazz-media` with the move to jazz; the compose PROJECT is still `media-servers` (which is what container labels show, so the labels don't catch this). A `media-servers` stack still exists on bumblebee in state `unhealthy` — the stopped migration leftovers — so the documented command silently deploys the wrong, dead thing. 2. There is no Global Auto Update fallback: `jazz-media` has auto_update=false (poll_for_updates=true only). Promotion is manual, full stop, and the 'don't cut a tag near the 03:00 run' caveat is obsolete. The pre-deploy safety chain is intact and jazz-aware (#635) — verified by reading the deploy's Pre Deploy stage: image-change trigger fired, 286M backup with integrity_check=ok plus off-box PBS, migration smoke PASS against the prod-copy, then only ersatztv recreated.	2026-07-20 23:04:34 +02:00
timothyandClaude Opus 4.8	4263cf7919	ci(508): move both docker build jobs off the small lane ... `runs-on: small` carried two jobs that are not small: docker-build.yml's image build, and ci-image.yml's toolchain buildx. The second reads as lightweight because it is "docker-only, no toolchain needed — it *builds* the toolchain", which is true and yet describes the heaviest job in the lane. A lane's per-job memory cap is set by its worst member, not its median, so these two pinned `small` at --memory=10g. On bumblebee's 25 GiB — also the prod media host — that permits exactly ONE slot, and four jobs shared it. So "widen the lane" and "keep the heavy jobs" were never simultaneously available. The symptom that forces the issue is not queue wait. A saturated lane also wedges DISPATCHED jobs in act's setup phase: >10 min in_progress, no log file written at all, then failure, before Checkout runs. That is where "decisions.md is a known flake, just rerun it" came from — the rerun works only because it lands after load clears, so a capacity problem read as a bug in the guard. With both builds on ubuntu-latest, `small` is a checkout plus a `git diff` and server-management#639 caps it at 1 GiB, widening it to 4 slots across two hosts while committing LESS RAM to CI than the single slot did. so it cannot be dispatched until the jobs it would queue behind have finished. refs #508 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 22:24:12 +02:00
timothy	a352d832ad	docs(release): v26.11.0 headline is the QSV VA-API decode fix (#498) + unified logo bug (#67) ... The release range grew after the host-correction PR landed: #67 and #498 both merged into main. #498 in particular flips a default (QsvPreferNativeDecoder is ON), so it leads the row rather than sitting in a fixes list.	2026-07-20 22:20:52 +02:00
timothy	d6aec6de76	docs(release): prepare v26.11.0 promotion — correct the deploy host to jazz ... The media transcoders (Jellyfin, ersatztv, ersatztv-test) moved from bumblebee to jazz (192.168.1.29) on 2026-07-20, server-management#633. Our docs still sent the release operator to bumblebee for security-scan.sh and named it as the docker host, which would have scanned the wrong box. Also fixes the inverse error: `jazz` was an EARLIER name for the .99 host, so three pre-migration references meaning today's bumblebee read as jazz. Those are now bumblebee, and a Hosts table + name-reuse warning is added at the top of ci-cd.md so the next session resolves hostnames by IP rather than re-breaking it in either direction. Version table had drifted (stopped at v26.9.0) — adds v26.10.0 + v26.11.0.	2026-07-20 19:18:03 +02:00
timothy	c5369b1d69	ci(412): sample true peak-anon in the test job, not cache-inflated memory.peak ... The test-job memory instrument (#411) reported memory.peak — the high-water mark of memory.current, which charges reclaimable page cache to the cgroup. A build does heavy NuGet/npm/obj/bin/coverage I/O, so cache can dominate the peak, and page cache is reclaimed under a tighter cap rather than OOM-killed. Sizing a per-job cap (server-management#604) off memory.peak therefore inverts the decision. The OOM-forcing quantity is peak anon, which the kernel exposes no counter for and which the end-of-job split misses (a job that peaks mid-dotnet-test then frees reports a low anon). New scripts/ci-peak-anon.sh: a `start` step (before Build/Test/Coverage) launches a detached background sampler tracking the high-water mark of cgroup anon; a `report` step (last) stops it and prints the sampled peak anon as the headline, keeping memory.peak + end-of-job split as a cache-inflated ceiling and reference. Both continue-on-error + fail-open so they never redden a build. Validated on bumblebee: survives step-boundary re-execs, catches a transient 2.5 GiB anon spike the snapshot reports as 0, stops cleanly on kill, degrades gracefully. Compiler-server A/B (swap-off, sampled peak-anon, n=2 interleaved): OFF (CI config) ~5.84 GiB consistent; ON (defaults) 6.3-7.6 GiB, always higher, + a ~3 GiB resident VBCSCompiler. Disabling the servers is worth it, but OFF sits right at 6 GiB for the build phase alone and the test job adds test+coverage, so #406's "budget loosens well under 6 GiB" premise is not supported. Size the cap off the live test-job sampler. Docs: ci-cd.md instrument section rewritten (peak-anon headline + A/B table + premise verdict); decisions.md entry added. No .cs touched. fixes #412	2026-07-19 20:49:08 +02:00
timothyandClaude Opus 4.8	33657b4753	docs(469): sweep remaining stale format-job cost/memory claims (review) ... Cold adversarial review (MERGEABLE) flagged two spots still describing the pre-#469 heavy `format` job as current, plus a wording imprecision: - ci-cd.md CI-lane table row: annotate `format` runtime 37s → ~0.5s (#469). - ci-cd.md #406 memory narrative: note the 3.95 GiB Roslyn heap is now moot (folder mode loads no workspace); api-docs remains the lane's real consumer. - Precise the coverage mechanism in ci-cd.md + decisions.md: the naming rule passes the full gate because naming violations have no `dotnet format` batch code-fixer (so `--verify-no-changes` sees no change), not merely a severity floor. Docs-only; no workflow/hook logic change from the reviewed commit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 19:34:43 +02:00
timothyandClaude Opus 4.8	eafb2e39e2	perf(469): format gate uses dotnet format whitespace --folder (~480s → ~0.5s) ... The blocking `format` CI job and the Husky pre-commit hook verified changed .cs files with `dotnet format ErsatzTV.sln --no-restore --verify-no-changes --include <files>`. `--include` only narrows *which* files are checked, never what gets loaded: the full recipe loaded the ~10-project MSBuild workspace and built a Roslyn compilation per project before checking a single line (~480s locally, whole-solution). Switch both to `dotnet format whitespace . --folder --verify-no-changes --include <files>`, which treats the tree as a plain folder of files, skips MSBuild/Roslyn entirely (~0.5s), and needs no `dotnet restore` (NuGet-cache + Restore steps removed). Coverage is unchanged: folder mode reads .editorconfig and enforces exactly the gate's purpose — whitespace + charset (BOM). Proven non-vacuous (error WHITESPACE on a trailing-space line, error CHARSET on a prepended BOM, exit 0 clean). The full gate never enforced the style/analyzer pass either — a warning-severity naming violation passes the full solution format (exit 0) — and the analyzers that must block (NU1904, S3981) are enforced at compile via WarningsAsErrors, not by this job. Docs: ci-cd.md Formatting section + the obsolete #406 memory note; decisions.md. fixes #469 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 18:33:31 +02:00
timothyandClaude Opus 4.8	038703fe67	test(444): deterministic functional-E2E for the playout-build lock 409 + isLocked projection ... Adds "Flow C" to scripts/e2e-functional.sh, the last deferred lock-contention flow from #363. A playout build is enqueued onto the single-consumer WorkerService channel and the trigger returns before BuildPlayoutHandler acquires the lock, so an accepted trigger does not prove the lock is held. Flow C makes it deterministic: seed a Classic Flood schedule over a few short ffmpeg episodes, crank PlayoutDaysToBuild=5 (~43k items ~= ~1s build), then POLL GET /playouts/{id} until isLocked:true before firing. Asserts PUT /playouts/{id} -> 409, reset -> 409, and the list-projection isLocked:true while locked; then isLocked:false + PUT -> 200 after the build (proving the 409 is lock-specific). Each racing assertion is guarded so a build that finishes mid-flight degrades to an advisory skip, never a false red; the whole flow self-skips without ffmpeg or if the build is never observed locked. Sized by measurement on a fresh instance -- going wider is counter-productive (a 777k-item build saturates the single worker with post-build gap/overlap jobs). Verified green across 6 fresh-instance runs; cold adversarial review MERGEABLE. Docs: docs/e2e-local.md + docs/ci-cd.md updated to describe Flow C and drop it from the "deferred" lists. fixes #444 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 17:37:50 +02:00
timothyandClaude Opus 4.8	dd55f00ed4	docs(420): sharpen the skip's honest hit-rate (rebase-before-merge) + cite live combined-status check ... Review nits from the scoped #420 review. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 20:53:23 +02:00
timothy	922b1ef53c	docs(398,420): document the #420 skip + record build-once measured-and-rejected	2026-07-18 20:53:23 +02:00
timothyandtimothy	ab8e5d7a91	ci(338): distinguish ZAP warning (exit 2) from failure (exit 1) in security-scan (#452) ... Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com>	2026-07-18 16:16:41 +00:00
timothyandClaude Opus 4.8	a1b75c1f2c	docs(363): sweep the scan-flow drift the re-review caught ... The fix commit softened the script's scan-409 wording + dropped ?deep=true but left the docs describing the old behavior. Match them: - docs/e2e-local.md: POST .../scan (no ?deep; note local scans always ForceScan) + "409, deterministic bar a tiny residual TOCTOU gap" (was "guaranteed 409") - docs/ci-cd.md: same "guaranteed 409" -> "409 (deterministic bar ...)" Docs-only; harness behavior unchanged (still 38/38 green, deterministic). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 15:44:47 +02:00
timothyandClaude Opus 4.8	4345180a56	review(363): robustness + wording fixes from cold review ... - check seed_library_path succeeded (print lastrowid) so a silent seeding failure surfaces as a FAIL instead of degrading Flow A to an advisory skip with no diagnostic (Medium) - anchor the scan-status match to '"libraryId":2,' so it can't substring-match "libraryId":20/23 if the suite ever creates more libraries (Low) - drop the no-op ?deep=true (local scans always ForceScan; deep only affects Plex/Jellyfin/Emby) + note why (Low) - soften "guaranteed 409" for the scan flow to note the tiny residual TOCTOU gap the multi-second scan covers; Flow B stays race-free by construction (Low) - correct the "WAL tolerates a second writer" wording to the real reason (the busy-timeout retry serializes the writer) in the script + both docs (Nit) - use TEST-NET-1 192.0.2.1 (RFC 5737) instead of RFC1918 10.255.255.1 for the non-routable Jellyfin address (Nit) Re-verified: fresh-instance harness runs green (38/38), lock section deterministic. Functional E2E CI job already green on the prior head. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 15:33:39 +02:00
timothyandClaude Opus 4.8	8a85f9ddb5	test(363): functional-E2E harness — add deterministic scan-lock + collections-lock 409 flows ... Extends scripts/e2e-functional.sh with the two IEntityLocker 409 contracts the first cut (ersatztv#299) deferred as "racy", made DETERMINISTIC by firing the racing request only once the lock is provably held (no sleep-and-hope): - library-scan "already scanning" 409: seed ~60 tiny ffmpeg clips into the built-in Shows library so the scanner subprocess runs a few seconds, poll GET /libraries/scan-status until the library is active (that window is a strict subset of the scan lock's held window — StartScan after LockLibrary, EndScan before UnlockLibrary), then a second POST .../scan is a guaranteed 409. Self-skips (advisory) when ffmpeg is absent. - external-collections "already scanning" 409: seed a Jellyfin media-source row pointing at a non-routable address so the background sync hangs and the per-family lock stays held; the lock is taken synchronously before the 202, so the 202 proves it held. collections-scan-status corroborates; unknown source 404. Seeding uses python3's stdlib sqlite3 (already a harness dep) to insert rows the API can't create (LibraryPath, media-source); WAL mode tolerates the second writer. No new CI step/dependency — ffmpeg ships in the toolchain image. Verified: 4/4 fresh-instance runs green (38/38), lock section deterministic. Still deferred to #363 follow-ups: the playout-build lock 409 + isLocked projection (#215) and the UI-interactive Playwright flows. Docs updated same PR: docs/e2e-local.md, docs/ci-cd.md, the functional-e2e job comment in .gitea/workflows/docker-build.yml. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 15:17:21 +02:00
timothy	082124f706	docs(416): note shallow-checkout FETCH_HEAD/two-dot fix (ci-cd + decisions) ... Refs #416	2026-07-17 22:02:06 +02:00
timothy	92bb63b6da	docs(416): document docs-only CI skip ... ci-cd.md gains a 'Docs-only skip' section + triggers-table note; decisions.md records the decision. Cross-refs the separate PR-vs-main rerun redundancy (#420) and the within-run triple build (#398). Refs #416	2026-07-17 19:44:25 +02:00
timothyandClaude Opus 4.8	469d725559	ci(406): apply the memory-swap rule to our own two sites; stop leaning on the peak reading [decisions-edit] ... Re-review of the fix commits came back MERGEABLE with three findings worth acting on. MEDIUM -- the PR documented a standing rule ("--memory without --memory-swap silently grants 2x in swap") and then didn't apply it to the two sites this repo owns: docker-build.yml's smoke container and scripts/migration-smoke.sh, both `--memory 2g` with no --memory-swap. Pre-existing rather than a regression, but a rule you don't follow in your own repo isn't a rule. The migration-smoke one matters most: it runs on the PROD host in the release path, so a runaway migration should die against its cap rather than quietly swap out the box serving media. LOW -- and this is the important one: the docs leaned "peak 8305 MiB is probably mostly reclaimable cache". An independent probe (full solution build, same CI image, shared compilation off) measured peak 9457 MiB / anon 7134 MiB / file 421 MiB. ANON DOMINATED. Having verified the *mechanism* (peak overstates because it counts page cache), I guessed the *magnitude* in the direction I preferred -- the exact failure this entry criticises, committed inside the entry criticising it. Corrected in ci-cd.md, decisions.md and on server-management#604 (where the previous comment could have led to an unsafe 6g cap). Consequences now recorded honestly: a 6g cap looks UNSAFE, #570's "6g proved too tight" is the rule not an outlier, and #406's premise ("if this brings peak RSS well under 6 GiB the whole budget loosens") is looking DEAD -- the 7134 MiB anon was measured with shared compilation already off. The switches remain right; the looser budget they were meant to buy does not follow. NIT -- dropped the unverified claim that this also disables the Razor build server. The UseRazorBuildServer -> UseSharedCompilation fallback is .NET 5-era; Razor has been an in-process source generator since .NET 6, so there is likely no separate server to disable on .NET 10. Unverified, zero impact, so it has no business in a doc arguing for measurement over assumption. [decisions-edit]: the touched docs/decisions.md lines were added by this PR's own earlier commits, not settled entries on main -- net vs origin/main remains a pure insertion (0 deletions, verified). Also the sanctioned reason: the entry was factually wrong (see LOW). Verified: both workflows parse; migration-smoke.sh passes bash -n; the parsed mysql option string is `--memory=2g --memory-swap=2g --cpus=2`. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:13:39 +02:00
timothyandClaude Opus 4.8	7859510c78	ci(406): report anon/file split — memory.peak counts page cache, not just RSS [decisions-edit] ... The peak-memory step from the previous commit worked on its first real CI run and immediately produced a number that would have led #604 to the WRONG decision: peak container memory: 8305 MiB (8708448256 bytes, from /sys/fs/cgroup/memory.peak) Read naively that says "the test job needs 8.1 GiB, so the 10g cap must stay and #406's 'the budget loosens' premise is dead". That reading is probably wrong, because `memory.peak` is the high-water mark of `memory.current`, which charges PAGE CACHE to the cgroup as well as anonymous memory. It is not peak RSS, and a build job does heavy NuGet/npm/obj/bin/coverage I/O. Proven on bumblebee -- a container with ZERO anonymous memory that merely reads an 800MB file: memory.peak : 826 MiB anon : 0 MiB file : 800 MiB This inverts the decision: page cache is RECLAIMED under a tighter cap, not OOM-killed, so a large peak that is mostly `file` is NOT evidence that the cap must stay high. `anon` is what forces an OOM. So the step now prints the anon/file split and says, in the log and the docs, to size caps on anon rather than peak. Honest about what this still isn't: the split is read at end-of-job, so it is the composition then, not at the peak instant -- a job peaking mid-`dotnet test` and freeing after would under-report anon. Sampling a true peak-anon is ersatztv#412, filed with the options. Also recorded there and in ci-cd.md: there is NO pre-change baseline from this instrument (7.8 GB VBCSCompiler was measured host-wide across concurrent jobs, not inside one job container), so #406's premise is neither confirmed nor killed yet. What IS established: no persistent compiler server survives a build, and migrations is green with mysql capped at 2g with swap disabled. The irony is the point, and it is now written into decisions.md: this repo's CI perf work keeps stating numbers from plausibility rather than measurement (#390's "2-4min" apt-ffmpeg estimate; real 110s). Measuring the wrong quantity precisely is the same failure wearing a lab coat -- and it bit this very change, whose whole purpose was to replace an inherited number with a measured one. Verified: shellcheck clean; the real step body run inside a --memory=2g container under `bash -e -o pipefail` reads memory.peak, prints the split, writes the step summary, exits 0; and it degrades to a skip + exit 0 where no cgroup file exists. [decisions-edit]: the modified docs/decisions.md lines are ones THIS PR added in its own earlier commits, not a settled entry on main -- net vs origin/main is still a pure insertion (0 deletions, verified). It is also the sanctioned reason: the entry as written was factually wrong about what memory.peak measures. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:53:24 +02:00
timothyandClaude Opus 4.8	04e3a5249d	ci(406): disable swap on the capped mysql; fix peak-step placement and failure mode [decisions-edit] ... Review fixes from the cold adversarial pass on PR #411. Verdict was MERGEABLE, but one HIGH is a genuine defect worth the round-trip. [decisions-edit] rationale: the 12 "modified" lines in docs/decisions.md are lines THIS PR added in its own previous commit (e33205e8), not a settled entry on main. The hook diffs against HEAD; net against origin/main this file is still a pure insertion (65 added, 0 deleted -- verified, and CI's decisions-guard diffs against the PR base). It is also the sanctioned reason regardless: the entry as first written contained a factual error (see HIGH below). HIGH -- `--memory=2g` alone silently grants 2g of SWAP as well. Docker defaults an unset --memory-swap to 2x --memory. Verified live on bumblebee: `--memory=2g` alone gives memory.max=2147483648 AND memory.swap.max=2147483648; adding `--memory-swap=2g` gives memory.swap.max=0. Capping RAM while permitting swap is close to the worst outcome on the one host whose swap thrash is the entire reason for the cap -- and a swapping mysqld mid-DDL is exactly the pathology behind the known `Command Timeout expired` migrations flake, so the naive cap could have made that flake worse rather than better. The comment promising "if this ever OOM-kills the service" described a failure mode that would not have happened first: it would have swapped, silently. Now --memory-swap=2g (swap off); prefer a loud OOM over silent degradation. The same 2x applies to the runners' 10g job slots (10 GiB RAM + 10 GiB swap each), which is a plausible direct mechanism for the incident's 21 GiB swapped. That is #604's boundary -- reporting it there. MEDIUM -- `if: always()` does not make a step advisory. It controls whether the step RUNS, not whether its failure fails the job, and defaults.run.shell: bash means -e is on, so a failed cat/redirect in an informational step could redden a green test job. Use continue-on-error: true, matching the neighbouring Coverage summary step. MEDIUM -- the peak step must run LAST. memory.peak read at step N reports the peak only up to N, so sitting before Coverage summary excluded reportgenerator's memory -- under- reporting the very number #604 sizes caps on. Moved after it. LOW -- dependency-scan.yml gets the env too; workflow env does not cross workflow files, and that one runs unattended on a cron against the prod media host. NIT -- Dockerfile ENV moved below the openapi-generator wget: an ENV invalidates every layer under it, and that ~30MB download is deliberately ordered early to stay cached (#190). Nothing between it and restore compiles, so this placement is free. NIT -- docs no longer imply this shrinks `format`. dotnet format loads Roslyn in-process via MSBuildWorkspace and never spawns csc, so its 3.95 GiB is untouched; sizing the small lane on the assumption it shrank would be a trap. Also record honestly that 543 MiB is init+idle rather than the 787-migration replay (so 2g is a measured floor + headroom, not a measured ceiling -- the migrations job going green is what validates it) and that --cpus=2 is judgement with no measurement behind it. The entry criticises dressing estimates as measurements; it should not do that itself. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:36:18 +02:00
timothyandClaude Opus 4.8	e33205e8eb	ci(406): disable persistent compiler servers, cap the mysql service, report peak RSS ... Refs #406, server-management#604. Items 1 and 2 of #406 (item 3 landed in PR #407). Root cause of the 2026-07-17 bumblebee incident (load 340, 21 GiB swapped, prod media down until reboot) is CI-induced memory pressure, and the largest single consumer was Roslyn's persistent VBCSCompiler at 7.8 GB RSS. It is a compiler *server*: it outlives the build that started it to keep its heap warm for the next one. In CI there is no next build -- each job container is torn down at the end of the run -- so it is pure cost, and it is the actual reason each job needed a 10 GiB cap. 1. Disable the compiler servers via the workflow's top-level env (UseSharedCompilation, DOTNET_CLI_USE_MSBUILD_SERVER, MSBUILDDISABLENODEREUSE). MSBuild surfaces env vars as properties and only defaults UseSharedCompilation when empty, so the env var wins and every dotnet call is covered without touching each call site. Also set as ENV in the Dockerfile's SDK stage: the workflow env reaches runner-side jobs only, and the `build` job compiles inside `docker build` where it does not propagate -- that is the job server-management#570 measured pegging 5.999/6 GiB, so it is the one that most needs this. Build stage only; the final image is FROM runtime-base, so nothing lands in the shipped image. Verified locally: a default build leaves 1 VBCSCompiler alive, the same build under these vars leaves 0, and ErsatzTV.sln still builds clean (0 errors). Trade-off: csc runs per project instead of via the server, costing some build time. 2. Cap the mysql service (--memory=2g --cpus=2). A runner's container.options applies to the job container ONLY: a live migrations job reported HostConfig.Memory=10737418240 for the job and mem=0 nanocpus=0 for its mysql service, i.e. unbounded. 2g is sized on measurement -- mysql:8.4 with this exact env peaked at 543 MiB during init, 481 MiB idle (probed on bumblebee) -- not on inheritance. Also add a `Report peak container memory` step to the test job (cgroup memory.peak, always(), never fails a build). server-management#604 sizes both runners' caps on that number and it was inherited rather than measured; now every run reports it. Docs: ci-cd.md gains the compiler-server + services-cap sections and the lane table is corrected (PR #407 reverted the #390 lane move without updating it). decisions.md records all three, incl. the standing rule that a services: container never inherits a cap. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:22:31 +02:00
timothy	07048b8c96	ci(390): address cold review — pin-drift guard, honest cron, doc fixes ... Cold adversarial review findings: - MEDIUM (Renovate generates pin drift): add a blocking ci-image-pin job. Renovate manages docker/ci/Dockerfile's base pins but cannot bump an opaque :<sha> in container.image, so a base bump would publish a new image, test the OLD one, and merge with the Dockerfile disagreeing with the pin. The guard fails when the pin isn't the last commit to touch docker/ci, or when the 5 jobs pin different tags — making the documented two-step enforced rather than remembered. - MEDIUM (cron was a no-op): the weekly rebuild updated nothing (jobs pin :<sha>) and buildcache would have restored the apt layer verbatim, collecting none of the base updates it existed for. Added no-cache on the schedule path and rewrote the comment to state what it actually is: a build canary + a fresh :latest for the next bump. - LOW: FFMPEG_TAG was referenced in the Dockerfile + docs but never existed (the FROM is hardcoded); reworded both. - LOW: paths: filtered the exact file while the docs claimed docker/ci/** — use **. - NIT: docs oversold ENTRYPOINT reset as a gotcha; act overrides it anyway. Marked defensive. Refs #390	2026-07-17 09:34:46 +02:00
timothy	84756eebab	ci(390): default run steps to bash — act_runner uses sh inside container: ... The migrations job died in 0.13s with 'set: Illegal option -o pipefail'. Root cause: inside a container: act_runner does not default to bash, it falls back to 'sh -e {0}' (dash), since it cannot assume bash exists in an arbitrary image. Every multi-line script in this workflow is bash (set -o pipefail, arrays, shopt, mapfile), so dash fails them immediately. The format job passed only because it already declared shell: bash explicitly. Declare it once at the workflow level instead of per step; non-container jobs already defaulted to bash, so nothing changes for them. Documented in docs/ci-cd.md as a container gotcha — it surfaces only once a job is containerized and does not look like a shell problem. Refs #390	2026-07-17 09:26:43 +02:00
timothy	afa42b0b6f	ci(390): run toolchain jobs in the shared CI image; drop 110s apt-ffmpeg; rebalance lanes ... Converts test/migrations/functional-e2e/api-docs/format to run inside ersatztv-ci:6a9e27c via container:, removing per-run setup-dotnet, setup-node, apt-get ffmpeg and dotnet tool install. NuGet/npm caches stay (project deps); setup-node's implicit npm cache is replaced with an explicit actions/cache. Rolled-up wins found while auditing every job's steps (evidence in #390): - Drop the apt-ffmpeg step (110s/run). It was never load-bearing: the app's only startup ffmpeg touch is a LogWarning from FFmpegLocatorService, and the harness drives curl-only contracts that never transcode. The image ships prod-identical ffmpeg 8.1.2 anyway, which #299's seeded-media follow-ups will need. - Bake dotnet-ef + reportgenerator into the image (2 per-run tool installs gone; versions now live in one tracked place). - Move api-docs (5s) and format (37s) to the idle 'small' lane — they were each queueing ~29min in the saturated ubuntu-latest lane. Also drops that lane from 5 jobs to 3. Only possible because container: makes them self-contained. Measured, not assumed: the image itself is worth only ~15-40s/job. The dominant costs are queue wait (server-management#604) and 742s of redundant compilation (#398) — both filed rather than silently bundled here. Refs #390	2026-07-17 09:16:04 +02:00
timothy	dbd4bb43f7	Merge pull request 'feat(analyzers): enable incremental latest-All enforcement' (#375) from feat/15-analyzer-promotion into main	2026-07-16 20:19:07 +00:00
timothyandClaude Opus 4.8	a2c056dd7a	docs(release): prepare v26.9.0 promotion [decisions-edit] ... Consolidate docs/decisions.md (1923 -> 1028) by extracting four cohesive topic clusters into docs/decisions/ (optimistic-concurrency, api-auth-security, release-ci-governance, spa-modularization) — content relocated verbatim (lossless; all rationale + reversals preserved), main Index rebuilt to reference the topic files plus the remaining in-file entries, docs/README.md points back at the decisions Index. Add the v26.9.0 row to the ci-cd.md version table. refs #340 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 22:17:23 +02:00
timothyandCodex	10ae885b47	fix(analyzers): preserve non-CPM and image builds ... Guard analyzer package references for the inline-version MCP tool and copy the SDK suggestion baseline into the Docker build context before restore. Refs #15 Co-Authored-By: Codex <codex@openai.com>	2026-07-16 21:52:27 +02:00
timothyandCodex	8f90cea5cc	feat(analyzers): enable incremental latest-All enforcement ... Centralize SDK and threading analyzers, baseline the .NET 10 All rule inventory at suggestion severity, and promote S3981 repo-wide. Fix the always-true worker count predicate and cover the idle/active branches. Fixes #15 Co-Authored-By: Codex <codex@openai.com>	2026-07-16 21:52:27 +02:00
timothyandClaude Opus 4.8	e78aa01c05	ci(coverage): exclude generated EF migrations to stop coverage OOM (exit 137) ... The shared Build & test job OOM-killed (exit 137) with coverage enabled: the whole-solution Architecture.Tests process instruments both EF migration folders (~2.59M generated lines vs ~200k authored), ballooning coverlet's in-memory hit-count arrays past the runner's limit. Add coverlet.runsettings excluding **/Migrations/*.cs (+ generated/compiler attributes) and pass it via --settings on the Test step. This cuts the instrumented surface ~126x (2,510,185 -> 19,963 coverable lines in the Architecture.Tests process, verified locally) and makes the reported percentage reflect authored code. Documented in docs/ci-cd.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 19:03:54 +02:00
timothyandClaude Opus 4.8	2090f7865c	ci(coverage): collect code coverage and publish a summary (refs #15) ... #15 scope item 4 ("collect with coverlet and publish a summary; decide on a floor later"). coverlet.collector was already referenced by four of the six test projects but the CI Test step never passed --collect and nothing summarized the result. - Add coverlet.collector to ErsatzTV.Core.Tests and ErsatzTV.Tests so coverage is uniform across all *.Tests projects. - CI Test step now runs --collect:"XPlat Code Coverage" --results-directory ./coverage, then a best-effort Coverage summary step merges the per-project Cobertura reports with ReportGenerator (TextSummary to the log, MarkdownSummaryGithub to the job step summary). No floor is enforced yet; continue-on-error keeps it purely informational. - gitignore /coverage/; document the step in docs/ci-cd.md (test job). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 18:45:32 +02:00
timothyandClaude Opus 4.8	0d7803079c	ci: add advisory functional-E2E curl harness (fixes #299) ... Codify the manual live-E2E curl flows sessions have been re-running by hand into a CI regression net: a new `functional-e2e` job boots the app from source (via scripts/e2e-local.sh, parameterized for Release) and drives scripts/ e2e-functional.sh against it. First-cut contracts (all curl-only, deterministic, no seeded media/ffmpeg/browser): - legacy->SPA redirect sweep + the /api,/artwork never-redirect exemption - auth/CSRF/security-stamp flow (setup-claim, read-gate, CSRF, login, logout+revoke) - library-scan status contract (404/202/scan-status) - optimistic-concurrency If-Match/412 round-trip Advisory by design (separate job, not a `build` dependency, not a required check) so a functional-E2E flake can't block the unit-test gate; promote once proven, mirroring the migrations-job rollout. SQLite default -> no DB service. Deferred to #299 follow-ups (need scanner+seeded media or a browser to be deterministic): the racy 409 re-trigger, playout-build lock 409, Playwright UI flows. Assertions verified 30/30 green against a real Release-built instance; caught /artwork/* returning 400 (not the 404 a static read suggested). Docs updated same PR: docs/ci-cd.md (new job), docs/e2e-local.md (harness), docs/decisions.md (append-only). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 13:49:33 +02:00
timothyandCodex	985eed072c	docs(release): prepare v26.8.0 promotion [decisions-edit] ... refs #335 Co-Authored-By: Codex <noreply@openai.com>	2026-07-13 19:50:39 +02:00
timothyandClaude Opus 4.8	366d5d316c	feat(ci): #314 — repeatable black-box security scan (authenticated ZAP + semgrep) ... scripts/security-scan.sh: boots a THROWAWAY container from the image under test (fresh config volume; never the deployed prod/test container — the active scan attacks write endpoints), reads its machine key, and runs an authenticated OWASP ZAP api-scan that imports /openapi/v1.json (all 160 /api/v1 ops) and injects X-Api-Key on every request via a replacer rule so it reaches the [RequiresAuthentication] + RequireKeyForReads surface — then a semgrep SAST cross-check. Wrapped in `timeout` because zap-api-scan can hang in post-scan cleanup after the report is already written. docs/ci-cd.md: new 'Security scanning' section (out-of-ecosystem black-box gate, run on the docker host per-release like migration-smoke, not a per-PR CI job) + the Microsoft.OpenApi 2.7.5 pin note in dependency management. refs #314 #197 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 08:28:13 +02:00
timothyandClaude Opus 4.8	4da2b67ab2	feat(ci): #315 migration-on-prod-copy smoke for the release path ... CI's migrations job only proves a migration is well-formed against a fresh, empty DB. It never exercises the migration — or ErsatzTV's startup data steps (DatabaseMigratorService -> DbInitializer + PopulatePathHashes over the real MediaFile table) — against the accumulated prod SQLite, so a migration green on a fresh DB can still fail/corrupt on prod, found only mid-deploy. scripts/migration-smoke.sh rehearses it on a THROWAWAY copy of the latest prod backup: boots the new image against the copy, gates PASS on the "Done applying database migrations" log line (the migrator is a BackgroundService running concurrently with Kestrel, so HTTP readiness alone doesn't prove migrations finished), FAILs on early container exit / migration exception / timeout / not serving afterwards. Always operates on a copy, never the live DB; tears down its container + temp dir (incl. the container's root-owned config files) on exit. Validated live 2026-07-12: :latest vs a copy of the 283MB prod backup -> migrations applied cleanly, app booted+served, temp dir removed. Home split: this repo owns the script + docs; wiring it into the Komodo pre-deploy step is server-management#589 (cross-repo). Docs: docs/ci-cd.md (Migration integrity), docs/decisions.md (new entry, pure insertion). fixes #315 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 21:18:16 +02:00
timothyandClaude Opus 4.8	6e92a951eb	feat(process): #303 decisions.md consolidation size-floor (read-cost, non-blocking) [decisions-edit] ... Timothy's refinement: the between-releases consolidation floor triggers on the file's READ COST — its line count, i.e. the context an agent burns reading the log — not entry count. The decisions-guard CI job now emits a non-blocking ::warning:: once decisions.md exceeds 1800 lines (the point past which it no longer fits one default 2000-line agent Read). Documented in the decisions.md header, the H9 entry, and ci-cd.md (job description + release-checklist note). Touches committed H9 lines, hence [decisions-edit]. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 18:23:58 +02:00
timothyandClaude Opus 4.8	59ecafecce	docs(process): #303 fold review nits — H3 case-insensitive, granularity wording, newline note [decisions-edit] ... Adversarial review (PR #305, MERGEABLE) nits: - H3: `grep -iE` so a root `Screenshot.PNG` is caught too (was lowercase-only). - decisions-guard.sh: comment the trailing-newline assumption (dropping the final newline would make git render the next append as a last-line modify -> false-block; self-correcting via [decisions-edit], .editorconfig enforces the newline). - docs: clarify CI is PR-wide (`range`) vs Husky per-commit (`staged`) — shared detection logic, deliberately different granularity; local hook is the stricter gate. Replaces the slightly-overstated "can't drift" wording. Touches the committed H9 decisions.md entry, hence the [decisions-edit] token. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 18:18:30 +02:00
timothyandClaude Opus 4.8	997f96c1f5	docs(process): #303 append-only supersession + consolidation convention [decisions-edit] ... decisions.md header now documents the enforced append-only rule, the `[decisions-edit]` escape, mark-and-keep supersession (banner on the reversed entry + `(superseded)` TOC tag), and consolidation at each release. ci-cd.md documents H3/H9 hooks + the decisions-guard job and adds a "consolidate decisions.md" step to the release checklist. New decisions.md entry records the H9/H3 mechanization. The header edit modifies existing lines, so this commit carries the [decisions-edit] token — the guard working as designed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 18:13:13 +02:00
timothyandClaude Opus 4.8	fa2d787ac1	ci: make the MySql migration-apply resilient to concurrent-runner contention ... Root cause (diagnosed from run logs 513/515/516): the EF migration-integrity job's "MySql apply all migrations to a fresh DB" step flakes when two migration jobs land on the SAME runner host at once — each `services: mysql:8.4` container starves the other, so the 787-migration replay either exceeds MySqlConnector's 30s default command timeout ("Command Timeout expired", run 513 on ci-runner) or has its connection dropped mid-replay ("MySqlEndOfStreamException", run 516 on bumblebee-runner). It's pure infra contention: `has-pending-model-changes` (the model check) passes both providers, and the identical tree passes on a quieter host (run 515). Both runners have both passed and failed — not one bad runner. Fix (runner-agnostic, repo-owned workflow only — no runner-host change needed): - Raise `DefaultCommandTimeout` to 300s in the MySql connection string. - Wrap the apply in a 3× retry that resumes from `__EFMigrationsHistory` (EF commits each migration in its own transaction, so an interrupted one rolls back and the retry continues). A real migration failure fails on every attempt, so the retry can't mask a genuine problem. Docs: ci-cd.md migration-integrity section documents the contention + retry. Refs #13 #236 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 00:42:49 +02:00
timothyandClaude Opus 4.8	1b5efd7b9d	ci: prod follows :prod (remove version-pin bump-prod-compose job) ... Timothy reversed the version-pin decision: prod's media-servers compose now follows the floating :prod tag, redeployed by Komodo Global Auto Update. The bump-prod-compose job (#275) rewrote a :<version> pin, which would flip :prod -> :26.8.0 on the next release — remove it. docs/ci-cd.md reconciled to the :prod model (+ flags the open caveat: verify Global Auto Update runs the #553 pre-deploy backup, else releases deploy without a backup). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 22:20:14 +02:00