docs(i18n): #642 GDrive Rules migration table (24→21 audit trail) - #656
Merged
Conversation
Companion artefact to the #642 structural analysis (#646). Records, for each of the 24 legacy GDrive "Cards" rows, the best repo record match + migration verdict: 1 IDENTICAL, 0 PRESERVED, 1 FRAGMENT, 10 GARBAGE-MT, 12 NO-MATCH (variant games not in repo Rules CSV, preserved verbatim in archived tab). Documents the audit trail proving no authentic partner content (juliadespb) was silently lost when Option 3 was applied (2 clean sheets byte-perfect from repo master + legacy tab archived under neutral name). Generated by code from live GDrive snapshot + repo master (code=truth, not hand-authored). Base master cb98905. Co-Authored-By: Claude-Code <noreply@anthropic.com>
jsboige
added a commit
that referenced
this pull request
Jul 3, 2026
…t artefact, variants ARE in repo (#658) Correction to PR #656's audit-trail note. The original note (and the PR #656 description) stated the 12 NO-MATCH rows were "variant game rules not present in the repo". That conclusion was WRONG. Verified against repo (code=truth): the 4 variants ARE present — Rules_07 (Le Bingo mixologie), Rules_09 (Le dernier beau parleur), Rules_11 (Le moulin à baratin), Rules_13 (La parlote coinchée). The repo holds the full 15-card set. The 12 NO-MATCH are a layout-alignment artefact: the legacy GSheet used a 24-fine-row layout; the repo uses a condensed 15-card structure (#438/#250 restructure). The row-by-row sentence-overlap matcher could not align GSheet title-rows against merged repo cards, so it reported NO-MATCH. The 24->15 restructure lost 0 character (16446 FR chars identical, verified by ai-01). The migration lost no data. The note now documents this correctly. Root-cause of the error: interpreting a matcher's NO-MATCH signal as "content absent from repo" without empirically verifying the repo records exist (pattern [[test-counter-empirical-dotnet-test]]). Co-authored-by: Your <your.email@example.com> Co-authored-by: Claude-Code <noreply@anthropic.com>
jsboige
added a commit
that referenced
this pull request
Jul 25, 2026
… (0 run, 0 prod CSV) (#903) Prepares the worker-side translation harness for #684 (DNN Rule prose, 7 langs × ~30 entities) ahead of the #681 (2sxc App export) artefact, per ai-01 dispatch. Turns the export wait into concrete readiness. Design doc + draft prompt: - docs/dnn-localization/684-rule-prose-translation-harness.md — the harness design: Option C task config (ready-to-paste C# snippet: UseResponsesApi=true, ReasoningEffort="low", MaxOutputTokens=7000, gpt-5.5, UseFunctionCalling=true, Enabled=false), Option C 5-record pilot protocol (#855 reco), cell-by-cell verification (3 dimensions: non-empty / not-FR- contaminated / language-correct — lessons #803 r7 false-0, #656 matcher-no-match), 7-language acceptance grid (DoD from #684), report format, serialization gate. - DatasetUpdater/Resources/PromptDnnRuleProseTranslateEnUser.txt — draft EN user prompt adapting the #487 DNN UI-strings pattern to Rule prose (function calling, HTML preservation, placeholders {0}/{1}, RTL/CJK, zero-FR-contamination). Closes the gap #855 flagged: every gpt-5.5 task today is wired to legacy Chat Completions (UseResponsesApi unset on 0/48) → latent empty-Content on reasoning models. The harness specifies the Option C routing for the Rule-prose task so the first Enabled=true flip doesn't silently produce empty output. Honest scope — no compiled config entry added: the source prose is DB-only (arrives via #681 export, no KnownDataSets.DnnRuleProse today) and the field model is pending #682. A compiled entry with guessed field names would be dead code that looks ready. The snippet is the ready-to-paste form, instantiated once the export format is known. 0 run, 0 prod CSV, 0 DB mutation. Enabled=false held until #681 + #682 + pilot PASS + T&A #802. Re-import is jsboige-side; visual QA verdict is ai-01-only. Co-authored-by: Your <your.email@example.com> Co-authored-by: Claude-Code <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Companion artefact to the #642 structural analysis (PR #646). Records the 24 → 21 migration audit trail for the GDrive Rules sync.
When Option 3 was applied (jsboige decision) — 2 clean sheets populated byte-perfect from repo master + legacy
Cardstab archived under neutral nameCards (archive 24x5)— this table documents, for each of the 24 legacy rows, the best repo record match and the migration verdict, proving no authentic partner content (juliadespb) was silently lost.Migration verdicts (computed from live data, code=truth)
Partner-edited cells (authentic juliadespb, non-garbage): 25 — all preserved verbatim in the archived tab.
Why this matters
The legacy sheet used a 24-row linear layout splitting markdown rules across rows; the repo stores each rule as a single cell with embedded line breaks. A 1:1 row mapping is structurally impossible (proven in #646). The clean-sheet approach is the lossless resolution; this table is the traceability layer for review.
Verification
Rules main(16×10) +Rules PP(7×10) readback EXACT MATCH byte-for-byte (REST diff + MCP read + dimension check)build_642_migration_table.pyfrom live GDrive snapshot + repo mastercb989051(not hand-authored)Test plan
Cards (archive 24x5)tabRelates #642. Companion: #646 (structural analysis), #647 (scanner anti-FP). Base master
cb989051.🤖 Generated with Claude Code