8 Commits

Include renames

Author	SHA1	Message	Date
timothyandClaude Opus 5	528383cf3a	fix(880): an absent recurrence array means unrestricted, an explicit [] is rejected (#892) ... The three recurrence arrays are read CONJUNCTIVELY by AlternateScheduleSelector.GetScheduleForDate, so an empty set matches no date. `?? []` on an omitted array therefore returned HTTP 200 while storing an alternate-schedule or template item that could never apply, silently -- while the read side (#823) already read a NULL column as the All*() sets. Absent and explicitly-empty are two different requests and get two answers: ABSENT (missing, or explicit null) normalizes to AlternateScheduleSelector.All*(), the same symbols the read side substitutes; EXPLICIT [] is rejected with a 422 naming the consequence, via RecurrenceSetBounds called from both replace handlers. The rejection lives in the handlers, not the controller, because api.ffmpeg-profile-numeric-bounds' "accept an UNCHANGED bad value" rule binds hardest here: both PUT paths are whole-list replaces, so rejecting a pre-existing empty set would make every OTHER item in the list uneditable. That comparison needs the stored row. The validated set is derived from `incoming`, so the highest-Index catch-all -- whose recurrence the handler discards -- is excluded by construction. Verified: full ErsatzTV.Tests suite green; three mutation proofs with disjoint reddened sets; live-E2E against a real instance confirmed an OMITTED property round-trips as unrestricted (the Newtonsoft missing-property chain unit tests cannot reach), an explicit [] returns the 422, and [] on the catch-all is accepted. Cross-family cold review BLOCKED the first implementation with 3 findings, all real and all fixed; re-review returned MERGEABLE. Follow-up #894 filed: the SPA can still build the empty state the server rejects. fixes #880 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 09:29:02 +00:00
timothyandClaude Opus 5	9685132ee0	fix(823): three cleanups from the coherence pass — a wrong witness, a wrong because, a duplicated paths: ... Round-five review confirmed the decision record is coherent with no third survivor of the empty reading, and returned three LOW findings. All are in prose I wrote in the last two commits. - The comment defending `(IsAbstract && !IsSealed)` cited AlternateScheduleSelectorTests as an in-repo static-fixture witness. That class IS static, but it merely NESTS its [TestFixture]es and declares no test of its own, so it would fail the sibling "declares no runnable test" assertion rather than demonstrating the point. The rule is right and the witness was wrong, which is the worse of the two failures because a wrong example is what a reader checks the rule against. No witness is cited now, and why is stated. - A mis-bound `because` in `rule:`: "assigning a null and calling SaveChanges SUCCEEDS ... because only the HTTP request records normalize with `?? []`". The `?? []` clause explains how a null could REACH the entity; what makes the save succeed is the column being nullable. A right observation with a wrong cause attached. Split into the two claims. - `signals:` carried the literal token `paths:` twice, an artifact of appending the #823 path list to the existing one. It degrades the field the discovery surface parses. Also recorded from that review, and NOT changed: `MonthsOfYear ?? AllDaysOfMonth()` survives the selector fixture and no date can kill it -- 1..31 contains every valid month, so it is an EQUIVALENT mutant there rather than a coverage gap. Its non-equivalent twin at the DTO boundary is pinned per-dimension by RecurrenceLimitsMapperNullTests. Left alone deliberately: chasing an equivalent mutant with a contrived date would buy nothing and cost the fixture's readability. Local gate: ErsatzTV.Tests 2091 passed / 6 skipped, Core.Tests 697/1 -- 0 failures. Format clean, no BOM. decisions_validate OK. Refs #823 Refs #824 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 21:14:27 +02:00
timothyandClaude Opus 5	3951fcf516	fix(823): stop patching the record by grep — a second ?? [] survived, and my "swept it" claim was false ... Round-four review. One HIGH, again in the decision record, and the previous commit message asserted this exact class was cleared. It was not. THE HIGH, and the reason it recurred. A second sentence still described the rejected reading: "The guard form is `?? []` into a local rather than this record's Optional(x).Flatten(), a STATED deviation". The shipped guard is `?? AllDaysOfWeek()`. That sentence is the one that dictates guard FORM to the next implementer, so it would have taught the `[]` reading the same record spends a paragraph calling data corruption -- and it had already propagated into docs/decisions/README.md, the mandated entry point, which carries `rule:` verbatim. The mechanism, not the sentence, is the defect. I swept with a regex keyed on "null" plus a reading word; this sentence talks about guard FORM and contains neither, so it could not match. That is grepping the retracted WORDING instead of sweeping the CONCEPT, which is exactly what this corpus warns about -- and three rounds in a row have now found a defect introduced by the previous round's targeted string edit. So the fix is not another targeted edit: the whole `rule:` field was split into its 39 sentences and read back one by one against the code. Everything below came out of that pass rather than a grep. Its secondary damage is worth recording because it is the shape of a rationale that outlives its claim: the deviation was justified by ".ToList() allocates for nothing", which is now BOTH irrelevant to the choice AND false about the shipped code, since AllDaysOfMonth()/AllMonthsOfYear() are themselves Enumerable.Range(...).ToList() on exactly the null path it describes. - The opening sentence of `rule:` prescribed Optional(x).Flatten() as THE read-site form. It is the sentence most likely to be read in isolation, and it is wrong for six of the eight columns. It now separates the universal half (a LOCAL, never assigned back) from the half that is not (the substituted value), and names where each applies. - `signals:` had never been touched, so roughly 60% of `rule:` was unreachable by the discovery surface built for it -- no AlternateScheduleSelector, no mapper, no "unrestricted", and its paths: list named none of the files this work touched. It also advertised "Optional Flatten hoisted local" as the form, which is precisely what the six do NOT use. - The body prose was still entirely about SongMetadata while `rule:` had grown a whole second subject. Added the two results that contradicted the prior reasoning, in prose, where a reader meets them. A REAL BUG in my own guard, not just prose: fixture.IsAbstract.ShouldBeFalse(...) A C# `static class` compiles to `abstract sealed`, and NUnit runs tests declared in one -- this repo already has such a fixture (AlternateScheduleSelectorTests is `public static class`). So the check I added one commit ago to reject an un-runnable fixture would have falsely reddened a perfectly good static one. Now rejects an abstract BASE (abstract and NOT sealed), which is the case NUnit actually cannot instantiate. A SURVIVING MUTANT the added controls did not kill: AnyDate was 2024-03-06. With a day <= 12 a CROSS-WIRED substitution survives the whole fixture -- `DaysOfMonth ?? AllMonthsOfYear()` hands back 1..12, which still contains day 6, so every assertion passes while the guard substitutes the wrong set. Moved to 2024-03-20, still a Wednesday in March, outside 1..12. Measured both ways rather than reasoned: the cross-wire mutant passes the old fixture and FAILS 2 of 11 on the new one. Also re-witnessed, because I had modified that file and never re-proved it: restoring `??=` in LuceneSearchIndex reddens the LUCENE fixture (1 red, 1 green) -- the exact mirror of the Elastic mutation. Extracting ThrowOnWarningLogger did not cost #701 its proof, and the two fixtures are independently load-bearing in both directions. The record is now 73 prose lines, over the 60-line WARNING ceiling. Stated rather than trimmed: it is 42nd of 42 records over that line, and the added content is distinct findings (a second subject, a migration analysis and three residuals), not redundancy against a sibling. Local gate: ErsatzTV.Tests 2091 passed / 6 skipped (the three fixtures' MySQL halves), Core.Tests 697/1 -- 0 failures. Format clean, no BOM. decisions validate OK. Refs #823 Refs #824 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 21:00:22 +02:00
timothyandClaude Opus 5	ea888011aa	fix(823): the decision record argued BOTH readings — and the per-dimension mutant that survived the fixture ... Round-three review findings. One HIGH, and it was in the durable artifact rather than the code. THE HIGH: the record stated the shipped reading and its inverse. The semantic reversal (empty -> unrestricted) rewrote the residual and the write-half of `media.nullable-primitive-collection-mutation` but left the ORIGINAL reasoning standing two sentences earlier: "A null reads as EMPTY, so the item matches nothing"; "the REJECTED alternative was the All*() set"; "SKIPPING the row is the conservative repair". The shipped code is `?? AllDaysOfWeek()` -- precisely the alternative that passage calls rejected. The previous commit then inserted residual (1), which reasons entirely FROM the All*() reading, two sentences after the sentence denying it. That is worse than a stale comment. A session resolving this key -- or reading the MemPalace mirror, which carries `rule:` verbatim -- would have been told to write the guard the other way, i.e. talked into the `[]` reading that the same record elsewhere argues is data corruption one save later. Replaced the whole passage, then swept the record for every other mention of the empty reading rather than trusting the one replacement: the only survivor is the new sentence that records EMPTY as the rejected alternative, which is the direction that stops it being re-adopted. THE MEDIUM: one arrangement did not close the hole it claimed to. The discriminating control added last commit nulls DaysOfWeek against a restrictive MonthsOfYear. It excludes "any NULL matches unconditionally" only for that dimension. The review supplied the surviving mutant -- `if (item.MonthsOfYear is null) { return item; }` ahead of the checks -- and traced it green through all nine tests. Verified by EXECUTION, not by reading: applied to the previous fixture it passes; applied now it FAILS 1 of 11. Each of the three dimensions is now nulled against a restriction on a different dimension. The rest, all from the same round: - The coverage guard's test detection listed attribute TYPES, and each list falsely reddened whatever it omitted: TestAttribute alone missed [TestCase], and the three-type replacement missed [Theory]. Now decided by NUnit's own ITestBuilder/ISimpleTestBuilder interfaces, which cannot fall behind the vocabulary. It also dropped BindingFlags.Static (GetMethods() defaults to including it), which would have falsely reddened a static test method. - The same guard accepted an ABSTRACT fixture -- NUnit never instantiates one. The indexer population already filtered IsAbstract; the fixture side now mirrors it. - The record's `mechanics:` still described the old `[Test]`-only clause, in the same file the change edited. - An <inheritdoc> made the ProgramScheduleAlternate empty-case test inherit a docstring written from the PlayoutTemplate test's viewpoint. Two more mutations executed: - `if (item.MonthsOfYear is null) return item;` -> 1 red, 10 green. This is the mutant that survived the previous head; it no longer does. - an abstract type named in the covered set -> coverage guard red. Local gate: ErsatzTV.Tests 2091 passed / 6 skipped (the three fixtures' MySQL halves, skipping visibly without ETV_TEST_MYSQL_CONNECTION), Core.Tests 697/1 -- 0 failures. Format clean, no BOM on the touched set. decisions_validate OK. Refs #823 Refs #824 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 20:43:07 +02:00
timothyandClaude Opus 5	6200713965	fix(823,824): close the review round's findings — a discriminating control, the second mapper's empty case, and honest test detection ... Follow-up commit (the branch is pushed, so not an amend). Two more cold reviews landed on the previous head; both reported 0 Blocker and 0 High, and these are their Mediums and Lows. Each fix carries its own witnessed mutation. 1. The selector fixture could not tell the fix from a much broader one. Every null test set a NULL and expected the item SELECTED, so all of them pass equally under "NULL means unrestricted" and under "any NULL makes this item match unconditionally" -- a refactor short-circuiting the whole date check on any null kept them green. Added the discriminating control: a NULL DaysOfWeek paired with MonthsOfYear = [1] against a MARCH date must be None. Only the narrow reading passes. 2. A_Null_Item_Does_Not_Disturb_Selection_Of_A_Later_Item never measured its own docstring. The nulled item was unrestricted and at Index 0, so it always won and the second item was never evaluated -- the stated invariant ("a null on the first item must not decide the second") went unmeasured while the test passed. Split into two: one where the nulled item genuinely does not match, which measures that the loop CONTINUES; and one that pins the index-order win separately. 3. The empty-preservation control existed for one of two identical mappers. The anti-mutant test for "empty or null becomes All*" covered only Playouts.Mapper; Scheduling.Mapper is a byte-identical triple in another file and had none, so a defensive edit to it alone would have rewritten a deliberately-empty user selection to 1..31 with the suite green. That is the one-helper-two-callers shape this repo has been bitten by. Added the matching test. 4. The coverage guard's [Test] clause did not check what its message claimed. GetMethods() without BindingFlags returns INHERITED methods, so a fixture that merely subclasses another satisfied it while driving the wrong indexer -- and Values.Distinct() cannot catch that, since the two Types differ. It also matched TestAttribute alone, so a future fixture written as [TestCase] would have falsely reddened, and it accepted an [Explicit]/[Ignore]d fixture that never runs, which is the "wired is not running" failure the guard exists to prevent. Now DeclaredOnly, the full test-method vocabulary, and Explicit/Ignore rejected at both method and fixture level. 5. Three residuals recorded on media.nullable-primitive-collection-mutation that the previous head asserted nothing about: - the LOUDNESS change, worst for an all-three-NULL ProgramScheduleAlternate, which now matches unconditionally and shadows the default schedule where it previously threw. Unreachable today, and a choice over an unreachable state rather than a measured requirement -- said plainly. - the normalization is ONE-WAY and WHOLE-LIST: both PUT paths are full replaces, so editing any row persists All*() over EVERY NULL row in that playout, and afterwards "the operator selected all 31" and "this is a legacy row" are indistinguishable. An ordinary user action closes that door. - the WRITE side disagrees with the READ side about what ABSENCE means: an omitted daysOfWeek normalizes to [] ("never applies") while a NULL column reads as unrestricted, so an API client gets HTTP 200 and a row that silently never fires. Filed as #880 rather than folded in here, because a client omitting a field on a write is a different question from what a legacy NULL meant. Two more mutations executed, both witnessed: - DaysOfWeek guard disarmed in Scheduling.Mapper -> 1 red, 3 green. - A fixture with no DECLARED test named in the covered set -> coverage red. Local gate (MySQL lane armed): ErsatzTV.Tests 2097 passed / 0 skipped, Core.Tests 695/1 -- 0 failures. Format clean, no BOM on the touched set with the population count asserted. decisions_validate OK. Refs #823 Refs #824 Refs #880 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 20:27:33 +02:00
timothyandClaude Opus 5	95b2700f09	fix(823,824): a scheduling NULL collection reads as UNRESTRICTED and is guarded at both read sites; the Elastic indexer gets its own mutation proof ... Both issues are #701 deferrals, and they land together because both rewrite the same decision record. #823 -- can a null reach one of the six collection-valued scalar columns? MEASURED against a real TvContext on BOTH providers (SQLite, and MySQL 8.4 on an ephemeral server), because the reasoning available beforehand pointed the wrong way. The two converters differ on their read side -- IntCollectionValueConverter maps null-or-blank to Array.Empty<int>(), while EnumCollectionJsonValueConverter would dereference the result of JsonConvert.DeserializeObject -- so the expectation was that a NULL row behaves differently per column. NEITHER RUNS: EF does not invoke a value converter for a NULL column at all. All six materialize as CLR null, the int converter's null-to-empty branch is dead on this path, and unguarded each .Contains in AlternateScheduleSelector throws NullReferenceException. A NULL reads as UNRESTRICTED -- the All*() sets -- not as empty. This is the whole semantic question and the first draft got it backwards. It is decided by the one NULL reachable WITHOUT any code writing one: Sqlite's 20240113140741_Add_PlayoutTemplate_DaysOfMonth adds the column with nullable:true and NO defaultValue, so a PlayoutTemplate row inserted before it holds NULL and by construction had no day-of-month restriction. Reading that as empty INVERTS the row's meaning and silently stops the template applying at all. All*() preserves it, and is how "no restriction recorded" is already represented (GetPlayoutAlternateSchedulesHandler, PreviewBlockPlayoutHandler). What does NOT decide it, and was wrongly cited in the first draft: the API request records normalize an omitted field with `?? []`, but that is a client omitting a field on a WRITE and says nothing about what a legacy database NULL meant. Two read sites, not one. Guarding only the selector would have left the entity->DTO mappers unguarded, and those feed the SPA: PlayoutScheduleEditors spreads the collection (`[...template.daysOfMonth]` -> TypeError on a JSON null) and playoutTemplateCalendar's appliesToDate -- an exact port of GetScheduleForDate -- calls .includes on it. Both mappers now substitute the SAME defaults, so the preview agrees with what is actually scheduled. Neither guard is assigned back onto the entity, which is the media.nullable-primitive-collection-mutation mechanism. Reachability, stated precisely rather than overclaimed. All six are nullable:true on both providers, but a nullable column does not produce a NULL row: five of the six were present at CreateTable, so a NULL there still needs code to write one, and on MySQL there is NO code-path-free NULL for any of the six. The write path ACCEPTS a null (SaveChanges succeeds, stores SQL NULL) but no caller supplies one today -- every production construction of the two commands goes through the request records. That is a property of the code, not a live caller; claiming otherwise would be the banned "it's AsNoTracking today" argument pointed the other way. #824 -- ElasticSearchIndex.UpdateSong had no regression test Issue option 1 (a non-network transport) shipped, and needed no new package: Elastic.Transport.InMemoryRequestInvoker is public in the pinned version and ElasticsearchClientSettings(NodePool, IRequestInvoker) accepts it, injected into the private _client the way #701 injects the Lucene IndexWriter. UpdateItems never runs `_client ??= CreateClient()`, so the injected instance is the one used. Two traps there are load-bearing, both measured: the canned response must carry an `X-Elastic-Product: Elasticsearch` header or the client's product check throws UnsupportedProductException INTO UpdateSong's catch, and an empty body fails to deserialize the same way. Either turns the fixture into a green measurement of the error path -- which is how it first failed here, caught by the ThrowOnWarningLogger. The document id is asserted as the LAST PATH SEGMENT, not by substring: the index name carries digits, so ShouldContain would stop discriminating for a song whose id collided with one. Six mutations executed, each disarming ITS OWN clause alone: - `??=` restored in ElasticSearchIndex only -> the Elastic fixture reddens on "metadata.Artists should be null but was []" while the LUCENE fixture stays GREEN. The #824 hole demonstrated, not described. - DaysOfWeek guard disarmed in the selector -> 4 red, 3 green (DaysOfMonth and MonthsOfYear unaffected). Each clause is independently load-bearing. - DaysOfMonth guard disarmed in Playouts.Mapper -> 1 red, 2 green. - Elastic dropped from the covered set / mapped to the SAME fixture as Lucene / mapped to a class with no [Test] -> SearchIndexMutationCoverageTests reddens on each. That coverage guard is the boundary fix the issue asked for: the covered set is compared against an ISearchIndex population DERIVED FROM THE ASSEMBLY. Its claim stops where the check does -- no static check can establish that a named fixture actually DRIVES its indexer, so it forces a human to look rather than proving coverage. ThrowOnWarningLogger moved to ErsatzTV.Tests/Support so both fixtures share it; the Lucene fixture's assertions are otherwise untouched, since it is a witnessed proof artifact. No production change in ElasticSearchIndex.cs -- #824 is coverage only. Docs: testing.md gains a "Provider-parity fixtures" section naming all THREE opt-in-MySQL fixtures and recording that CI runs none of them (#627); docs/README.md gains the matching task signal; guard-inventory.md's hand-written C# guard list goes from five files to six. Scheduling/Mapper.cs loses the UTF-8 BOM it inherited, per #311 fix-as-you-touch. Local gate (with the MySQL lane armed): ErsatzTV.Tests 2096 passed / 0 skipped, Core.Tests 693/1, Infrastructure.Tests 114, Architecture.Tests 7, Scanner.Tests 1504 -- 0 failures in each. scripts/tests 1228 passed / 2 skipped. dotnet format whitespace --verify-no-changes clean; BOM check over the touched set with the population COUNT asserted, because a bare zsh loop silently checks one concatenated filename. decisions_validate OK. Fixes #823 Fixes #824 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 20:02:52 +02:00
timothyandClaude Opus 5	b5dee26202	fix(701): guard SongMetadata's nullable primitive collections at the read site ... Both search indexers opened UpdateSong with metadata.AlbumArtists ??= []; metadata.Artists ??= []; Artists/AlbumArtists hold the whole list in ONE COLUMN rather than being navigations. So unlike the same `??= []` idiom on Genres/Tags/Artwork all around them, the property IS the column value: assigning it on a TRACKED entity flips the entry to Modified and the next SaveChanges writes [] over a NULL column. This is the mechanism an adversarial review demonstrated in #691, which is why that issue's entity-level guard was reverted in favour of guarding at the read site. Measured rather than reasoned about, per the issue's first done-when box. Restoring ONLY the `??= []` clause (the real predecessor lines, not a hand-written mutant) reddens the new fixture on `metadata.Artists should be null but was []`; a probe variant with the first two assertions replaced by prints reports STATE=Modified and the raw column moving from NULL to "[]". Today's two feeds are both AsNoTracking (SearchRepository.GetItemToIndex and GetAllSongs), so no shipped caller loses data -- but that is a property of two callers, not of the indexer, and #691 already recorded it as a loaded gun. The fixture pins the indexer's own contract instead. Removing the assignment is not sufficient alone: it was load-bearing for the four reads below it, and deleting it by itself converts a silent write into a live throw on every untagged song. Measured by deleting only those two lines from the real predecessor file: NullReferenceException, thrown at the foreach (cited by symbol: a line number in a mutant that exists in no committed tree is unreproducible by construction). The exception type follows the read FORM, not the field -- foreach yields NRE, string.Join/ToList yield ArgumentNullException -- and this PR contains two of each, which is why no single exception-name grep characterises the class. So each site moves together with its reads: - LuceneSearchIndex.UpdateSong / ElasticSearchIndex.UpdateSong: hoist Optional(...).Flatten().ToList() locals and read those. - RefreshChannelDataHandler: the Scriban context took the raw nullable lists (the issue's second item). The shipped _song.sbntxt only does array.join, but a custom template is free to do anything. The population was derived from the MODEL rather than from the issue's file list, and the obvious derivation is wrong: "the IList<string> properties under ErsatzTV.Core/Domain" returns two of eight. It misses the six value-converted collections (ProgramScheduleAlternate and PlayoutTemplate each carrying DaysOfMonth, MonthsOfYear, DaysOfWeek), declared as plain ICollection<T> and made single columns only in Data/Configurations -- and their storage differs (comma-separated text for the int converter, JSON for the enum one), so the shared property is "one scalar column", not the serialization. No site applies `??=` to any of the six, so this defect has no instance there; whether a null can REACH one at runtime is unverified and is filed as #823 rather than asserted either way. Only the SongMetadata pair is left NULL in practice, by FallbackMetadataProvider. Every site touching either field was then swept; the remaining readers were already guarded by #691. The fixture carries two anti-vacuity guards, both witnessed: - A POSITIVE CONTROL (`writer.NumDocs.ShouldBe(1)`). Every other assertion says something did NOT happen, so all of them hold vacuously if UpdateSong never runs -- and it silently stops running if a future refactor gates UpdateItems on `_initialized`, which this fixture bypasses by injecting the writer. Verified BOTH directions: with that gate added the control fails `NumDocs should be 1 but was 0`, and with the control removed the whole test PASSES while the code under test is unreachable. - A capturing logger, because UpdateSong wraps its body in a catch that assigns metadata.Song = null -- severing a required relationship and cascading the metadata to Deleted. Without it the probe silently measures the error path; on the first run it did exactly that (a bare ILanguageCodeService substitute NPEs inside AddLanguages). The raw column helper also fails loudly on a missing row, since ExecuteScalar returns CLR null for both "NULL column" and "no such row". ElasticSearchIndex has no equivalent fixture -- it needs a stubbed transport -- so its change is by inspection against the Lucene one, and the gap is filed as #824 rather than covered by a source-text guard. The whitespace-only churn in ElasticSearchIndex.cs is the #311 fix-as-you-touch format gate: it scopes to whole changed FILES. `git diff -w` over that file shows only the two hunks above. Local gate: ErsatzTV.Tests 2006 passed / 4 pre-existing skips, Core.Tests 685/1 skip, Infrastructure.Tests 114, Architecture.Tests 7, Scanner.Tests 1504 -- 0 failures in each. scripts/tests 874 passed / 2 skipped. dotnet format whitespace --verify-no-changes clean on the four touched files, no BOM on any. decisions_validate OK. Fixes #701 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 00:49:57 +02:00
timothy	fba5233caf	feat(610): split the decision corpus into one YAML-frontmatter file per record ... 168 records -> docs/decisions/records/<area>/<topic>.md (163 active, 23 dirs) and docs/decisions/archive/<area>/<topic>.md (5 archived). The filename IS the key, so one-active-record-per-key becomes a filesystem property rather than a validator check, and supersession becomes a `git mv`. WHY: the monolith was a concurrency problem before an aesthetic one. A 3,900-line append target made parallel sessions collide -- PR #605 and PR #614 both hit append-vs-append conflicts during routine rebases, and hand-resolving those inside the corpus is exactly the operation the rationale-rewrite guard exists to police. HOW IT IS VERIFIED: a ~170-file diff cannot be meaningfully read, so correctness does not rest on reading it. The parser was taught BOTH formats first, so the body-diff guard parses the old form at the merge-base and the new form at head -- the migration validates itself, no bypass. The proof is a field-level equivalence harness: 168 records before and after, zero lost, zero gained, zero field mismatches, zero rationale bodies differing. Reviewers should scrutinise the harness; it is the actual evidence. What measuring caught that reading would not have: - ~500 lines sit OUTSIDE any record -- decisions.md's lifecycle schema and each topic file's preamble, mostly the only copy. Source files are kept and stripped, never deleted. They also cannot be filed per-area: topic files hold several areas and 4 of 23 areas span several files. - Archive discovery was a non-recursive glob; after the split it found ZERO archived records, surfacing as four bogus "supersedes points to unknown key" errors rather than an obvious failure. - ~32 live docs point into the corpus BY DATE, which the split dangles. Each stripped file now ends with a generated "Records formerly in this file" index, which also rescues the identical breadcrumbs in old issue comments. - decisions.md's "In this file:" list was 97 same-file anchor bullets that the split makes WRONG, not merely stale. Dropped; the generated index replaces them with links that resolve. The equivalence harness now runs against a checked-in FIXTURE, not the live corpus. The earlier version migrated the real tree, which made it a one-shot: the moment the migration landed there was nothing left to move and the tests failed for reasons unrelated to the code. A fixture keeps them testing the SCRIPT rather than the repo's current state. Keys preserved verbatim, warts included: `sched` (12) and `scheduling` (1) remain two directories for one concept. Renaming a key is not a move -- it changes identity, breaks the equivalence proof, and invalidates MemPalace's per-key drawers. Taxonomy normalisation is separate work. refs #610	2026-07-25 19:45:09 +02:00