Changelog

This page consolidates the repository's historical changelog, handover corrections, validation notes, and Git baseline. Entries are in reverse chronological order. Dates are absolute.

2026-08-20 - QDB breeding-only web release (v0.2.0 to v0.3.2)

Delivered

• Integrated the QWebHub shared qdb-base.css design tokens and light/dark theme toggle across the breeding page, including report surfaces, form controls, status blocks, pedigree cells, and print-safe styling.
• Replaced every web pedigree read from qdb.runner with qdb.breeding. Horse, sire, and dam autocomplete now return breeding.id values, and sire/dam searches enforce the table's is_male role.
• Changed pedigree expansion to follow only breeding.sire_id and breeding.dam_id. A stored parent name without a linked breeding ID remains a visible unresolved leaf; the resolver does not fall back to runner data or make a weaker name-only guess.
• Replaced the BRUTAL x KISS MOON mock action with the uploaded WINX pedigree in qdb.breeding.
• Added country-of-origin suffixes by translating breeding.country_id through qdb.country. The country table is display-only; horse identity and every parent relationship remain authoritative in qdb.breeding.
• Moved the Existing horse lookup above the proposed-mating sire/dam controls.
• Published the QWebHub module at qdb.qdatasite.com/breeding-reports/, ending at web-module version 0.3.2.

Live verification

• WINX resolves as breeding ID 31 with all 30 four-generation positions populated and no pedigree issues.
• The first generation resolves to STREET CRY (IRE), breeding ID 22, and VEGAS SHOWGIRL (NZ), breeding ID 26.
• AL AKBAR displays as AL AKBAR (AUS) with year 1990 and breeding ID 1. Earlier large sire/dam IDs were stale legacy-runner identifiers and are not used by v0.3.x.
• Existing-horse search, sex-filtered sire/dam autocomplete, proposed-mating generation, the WINX shortcut, print-button enablement, and both theme states were exercised in Chrome without console warnings or errors.
• The web test suite passes 24 tests with one opt-in integration test deselected; Django system checks and JavaScript syntax checks also pass.
• Odin deployment used SHA-256 manifest comparison and remote verification. The final deployable selection matched 11 of 11 files, and the application was recycled with web.config preserved byte-for-byte.

Current web boundary

The browser pedigree summary reads qdb.breeding, plus qdb.country solely for country-code display. Legacy statistical report choices remain visible but disabled because their engines still depend on rs data and have not been ported to the QDB web contract. The labels sire ID and dam ID on pedigree cells refer to qdb.breeding.id.

2026-08-10 - QDB-only QWebHub pedigree page

• Added the gary_breeding_web Django module and the /breeding-reports/ route in QWebHub.
• Recreated the legacy 16-row, four-generation pedigree layout with existing-horse and proposed-mating entry, autocomplete controls, visible resolution notes, and A4 landscape browser printing.
• Kept legacy statistical report options visible but disabled with their QDB migration reasons; no web request executes rs.* SQL.
• Added a credential-free Odin launcher using the shared QWebHub deployment engine. The initial best-effort qdb.runner pedigree resolver from this release was superseded by the qdb.breeding-only v0.3.0 release on 2026-08-20.

2026-08-08 - Repository and knowledge-base baseline

Added

• Established the canonical private GitHub repository at RQDG/Gary-Breeding-Project.
• Initialised branch main and pushed baseline commit 114d269 (Initial commit: port breeding report tooling).
• Created the QDG KB project gary-breeding-project with overview, historical changelog, and report-output documentation.

Changed

• Expanded .gitignore to exclude credentials, environment overrides, Python/Node caches, build outputs, editor files, generated report files, validation directories, SQL dumps, and logs.
• Removed generated report and validation artifacts from the initial Git history before its first push.
• Preserved tests, source, renderer fixtures, matrix CSVs, schema/reference documents, and original golden PDFs in Git.

Verification

• Workstream A: 24 selected tests passed; one live integration test deselected.
• Workstream B: 30 selected tests passed; two live integration tests deselected.
• Node syntax checks passed for renderer/render.js and renderer/lib/chromosome.js.
• Remote main and local main both resolve to 114d269fa5788c4cacc4773b67996c1ae5fcaed9.

Known metadata issue

The living documentation and package version do not currently agree: CHANGELOG.md says 0.5.2, HANDOVER.md says 0.5.1, and breeding_report_v3.__version__ says 0.4.1. Treat the dated changelog and repository commit as authoritative until version metadata is reconciled.

2026-08-05 - Group B and Group C reports completed

Added

Six remaining report builders were ported from the legacy TrotBetAdmin PDFController.cs:

• sire_progeny / New Sire Breakdown
• order_of_foal_report / Order of Foal Stats
• damsire_timeform_stats
• sire_forensic_report
• dam_sire_report / Individual DamSire Statistics
• bs_breeding_report / Bloodstock Dam

Other additions:

• MySqlQueryRunner.call_multi() for ordered multi-result-set queries.
• ReportModel.tables and ReportModel.extra for non-pedigree table reports.
• BSParent and ReportModel.bs_parents.
• breeding_report_v3/bsparent.py, porting the legacy FillBSParent path.
• CLI params_only dispatch for multi-ID reports.
• An id_param override so the DamSire report can reuse --sire-id while treating it as damSireId.
• Generic table and Bloodstock Dam renderer functions.
• validate_group_bc_against_odin.bat.

Changed

• The JSON shared-reference guard now supports both RSParent and BSParent.
• The PDF conversion path tries soffice first on Windows and libreoffice first elsewhere.

Validation status

All six builders passed fake-runner wiring and serialisation checks, and the renderer passed syntax checks. They have not yet been executed end-to-end against live rs data. The generated DOCX files therefore still require SQL and visual review.

The Sire Forensic validation script currently assumes foal year 2021 and the date range 2022-01-01 through 2026-02-01. These parameters need business confirmation.

2026-08-05 - Group A validation and four confirmed fixes

Fixed

1. build_seasonal_stats() now forwards stats_before instead of always using live data.
2. The renderer now parses date-only ISO values by their year/month/day components, preventing an AEST/UTC one-day rollback.
3. Sire Report V2 now renders the Seasonal Stats section that was already present in its JSON.
4. The sire description is composed from age, colour, and parent type, matching the legacy Razor view rather than reading a non-existent Description property.

Verification

A live rerun confirmed:

• Foal date renders as 06 Sep 2015.
• Last race date renders as 02 Nov 2019.
• Description renders as 11yo BR Stallion; the age difference from an older golden is live source-data drift.
• Sire Report V2 includes Seasonal Stats and the All column.
• Standalone Seasonal Stats includes only 23/24, 24/25, and 25/26 under the cutoff.
• The three season values match between the two reports.

Operational finding

A stale breeding_report_v3/__pycache__ initially caused old behavior to run after source files were updated. Clearing the cache resolved the mismatch.

2026-08-04 - Shared QDB connection with explicit RS reads

Changed

• Both Python packages now default to C:\Users\Robert\projects_config\db.json.
• The active connection may open QDB while legacy report queries use explicitly qualified rs.* tables.
• Remaining unqualified sibling-query references were corrected.
• Configuration precedence and schema-qualification tests were added.

Verification

Live application execution confirmed active database qdb, visibility of both qdb and rs, access to sire 93686, and successful sibling-query execution.

2026-07-03 - Sire Report V2 and Seasonal Stats

Added

• build_sire_report_v2()
• build_seasonal_stats()
• CLI report entries sire_report_v2 and seasonal_stats
• Sire/dam overview rendering
• Race record and strike-rate rendering
• Stake win/place table
• 100+ Timeform progeny tables split by sex
• Progeny-by-age rendering
• Dynamic seasonal-stat tables
• R&S disclaimer block
• Renderer dispatch by report_type

Verification

Both report types were initially exercised with synthetic JSON and checked by extracting text from the generated Word document XML. The subsequent live validation and fixes are recorded in the 2026-08-05 entry.

2026-06-27 - Phase 4 renderer

Added

• Programmatic DOCX renderer using the Node docx library.
• Foal Index header and total-score presentation.
• Pedigree Score table with criteria groups and Matrix Model Value section.
• Four-generation XX Chromosome Pathway grid.
• Australian sire and broodmare-sire ranking tables.
• Golden-derived renderer/sample_report.json.
• Optional LibreOffice headless PDF conversion.
• Renderer usage documentation and output exclusions.

Verification

The sample report rendered successfully and was visually checked against the Foal Index golden. Content matched the score, chromosome, and ranking sections. Pagination remained approximately four pages versus the legacy three.

2026-06-27 - Phase 2 orchestration, scoring and JSON contract

Added

• fmt.py for C#-compatible numeric, percentage, rounding, and text formatting.
• siblings.py for sibling and sales data.
• rankings.py for Australian sire and broodmare-sire rankings.
• matrix.py for the four matrix CSVs and band matching.
• scoring.py for sire/dam-line criteria, stake and peak calculations, and catalogue statistics.
• orchestrator.py for full pedigree assembly, cross positions, matrix values, rankings, chromosome map, flags, criteria groups, and lot data.
• serialize.py and the V3 CLI.

Verified values

• BRUTAL sire scoring block matched the golden criterion values.
• Matrix values matched the golden: Peak 167.37 / band 162.11 and Median 159.65 / band 169.42.
• Ranked sire and broodmare positions matched the golden behavior.
• KISS MOON racing-foal sibling records matched the golden.
• Sales-only sibling totals were documented as live-data dependent.

2026-06-27 - Phase 1 full pedigree path

Added

• MySQL runner compatible with the legacy multi-statement query behavior.
• parent_builder.py, porting FillRSParentV3, basic parent details, race information, seasonal statistics, medians, and helper formatting.
• Sire and dam construction entry points.
• SQL-dump development harness.
• Parent-builder unit and live integration tests.

Live validation

Using statsBefore=2026-02-01, the implementation was checked for:

• BRUTAL (sire 93686)
• KISS MOON (dam 531529)
• MALIBU MOON (dam sire 16790)
• the BRUTAL/MALIBU MOON cross
• KISS THE DEVIL (grand-dam 170769)
• DEVIL'S NELL (third dam 152911)

Race records, Timeform medians, progeny counts, stake data, cross performance, and top progeny matched the corresponding reference sections, subject to documented live sales-data drift.

2026-06-26 - Project foundation

Workstream A

• Analysed the 3,675-line legacy BreedingController.cs read path.
• Built the modular breeding_report package.
• Ported six meeting QA endpoints.
• Added 22 original unit tests plus an opt-in live integration test.
• Added configuration, architecture, query, and module documentation.

Scope correction

The actual Foal Index and Bloodstock reports were found to come from TrotBetAdmin PDFController.cs, not BreedingController.cs. This established a separate V3 report workstream.

Workstream B Phase 0

• Traced the full report call graph.
• Ported RSParent, criteria, statistics, lot, and report-envelope models.
• Added PedigreeInput.
• Copied the four matrix model CSV files.
• Established BRUTAL x KISS MOON as the canonical golden case.
• Added the first six V3 tests.
• Confirmed server runtime, legacy rs data source, JSON-to-DOCX-to-PDF pipeline, and explicit pedigree-ID inputs.

Historical corrections retained

• There is no master/ directory in the Gary Breeding repository.
• The legacy source used for report-port verification is in the sibling Global Assests\SourceCode\AdminPanel\TrotBetAdmin tree.
• Earlier notes that described the Node renderer and phases 1-4 as unwritten are superseded by later dated entries.
• The canonical golden total has appeared as both 985/990 in early planning and 935/920 in the later renderer fixture. Full live reconciliation remains the authority needed to close that discrepancy.