# STAGE_0_CAPTURES.md **The five D7 captures — run, for the first time, on 2026-08-25.** `EXECUTION_RUNBOOK.md` Stage 0: *"Nothing in Stage 2 may run before these."* All five are now executed and recorded. **No STOP condition was triggered.** This is also the **first time any artefact in this repository has ever been executed.** `MIGRATION_STATE.md` warned that every claim in it was static-analysis only. Running things found three defects that reading could not — §6. Raw output is kept in `.logs/d7_*.out`. **D7 was not modified: no file, no schema, no row.** --- ## 1. Results at a glance | # | capture | STOP condition | result | |---|---|---|---| | 1 | `d7_webform_components` | load-bearing cids 30/27 absent | ✅ both present | | 2 | `d7_quiz` | Q-4 returns rows | ✅ empty — explanation (i) | | 3 | `d7_view_quiz_certificate` | V-1 empty (view in code) | ✅ view is in the DB, sort captured | | 4 | `d7_certificate_snapshots` | S-1 = `i:1;` with snapshots present | ✅ OFF, table empty | | 5 | `d7_payment_audit` | P-2 or P-3 non-zero | ✅ both zero | --- ## 2. Capture 1 — the webform component map ⭐ The mitigation `MIGRATION_STATE.md` calls *"the single highest-risk detail in the whole migration"* is now in place. ``` node 27, 28 components captured cid 30 -> 'course' ⭐ course_actions reads data[30] cid 27 -> 'please_comment_on_any_aspect_of_the_course' ⭐ webform_document reads data[27] ``` `ce_migrate.webform_component_map` is **populated and live**: ``` isCaptured() : true hasLoadBearingComponents() : true ``` The YAML was **generated by parsing `.logs/d7_webform_components.out`**, not transcribed, so no value was retyped. The config had never been installed at all (§6.2), so it was imported and exported to `config/sync`; `drush config:status` is clean. **Volumes all match the register exactly:** 21,064 submissions · 441,970 data rows · 20,873 with cid 30 · 20,580 resolving to a course · 3 to a non-course · **4 non-numeric** · 73 dead-uid submissions. > 🛑 **Residual risk, recorded in the config file itself.** Webform limits an element key to 64 > characters and **6 of the 28 form_keys exceed it** (cids 6, 7, 16, 19, 21, 25 — up to 99 chars). > `webform_migrate` will alter those. They must be re-verified against the real migrated webform. > **Neither load-bearing component is affected** — `course` is 6 chars and the comment key is 41. --- ## 3. Capture 2 — the quiz pass-rate question, settled **Explanation (i). The documented `35 + 28 + 5 = 68` counts `quiz_node_properties` ROWS, which are per-revision.** No quiz ever changed its pass mark, so no student's pass/fail depends on which revision they took. Q-4 returned no rows, and a restated query confirmed it (`.logs/task27-quiz-verify.sh`). | | rows | distinct nids | |---|---|---| | pass_rate 100 | 35 | 31 | | pass_rate 75 | 28 | 24 | | pass_rate 0 | 5 | 5 | | **total** | **68** | **60** | **The distinct count is 60 against 59 quiz nodes.** The 60th is **`nid = 0`** — a garbage row in `quiz_node_properties` pointing at no node. Real quizzes reconcile at 59. A migration that treats `nid` as a valid node reference will trip over it; `ce_quiz_properties` reads `quiz_node_properties` and must tolerate `nid = 0` the same way the webform migration must tolerate the 4 non-numeric cid-30 values. Other figures: 3,973 attempts = 3,922 evaluated + 51 abandoned ✅ · 59 quizzes · 128 questions · 275 relationships ✅ · 2,595 distinct users · **3 quizzes never attempted** (56 of 59 have attempts) · 4 attempts by deleted users · 0 results pointing at a missing revision · `takes = 0` (unlimited) on all 68 rows. **Q-5 — the five unfailable quizzes** (272, 278, 284, 291, 405) are confirmed, and `would_fail_at_75` is **0 for every one of them** across 202 attempts. The "tempting fix" would retroactively fail nobody. That does **not** make it safe — it changes the rule going forward — but the historical blast radius is zero, which is worth knowing. **Q-6 — 0 attempts** are a pass by one mark and a fail by the other. The theme's hard-coded 75 and the per-quiz `pass_rate` do not currently disagree on any real attempt. --- ## 4. Capture 3 — the certificate sort ⭐ THE ANSWER The `quiz_certificate` view **is in the database** (vid 32), so V-1's STOP does not apply. The sort that decides *which attempt dates a certificate*: ``` display: page (path quiz-certificate) pager : some, items_per_page = 1, offset 0 <- exactly one row; the sort is decisive sorts : score DESC time_end DESC filters : type = quiz_result, is_evaluated = 1, is_invalid = 0 arguments: nid (index 0), uid (index 1) <- correct order fields : result_id (excluded), score (suffix %), title (via nid), time_start, time_end ``` > **The certificate shows the HIGHEST-SCORING attempt, tie-broken by the LATEST `time_end`.** > It is **not** "the most recent attempt". A D10 rebuild that sorts by date — the intuitive > choice — prints a different score and a different date. **Blast radius (V-5/V-6):** 153 user/quiz pairs have more than one evaluated attempt, covering 377 attempts, with one user reaching 10 attempts. For **all 153**, the earliest and latest `time_end` differ — so all 153 certificates would change if the sort were guessed wrong. `quiz_certificate` (schema 0) and `certificate` (7002) are both enabled; `certificate_test` and `signup_certificate` are not. **Next:** the V-3 blob is in `.logs/d7_view_quiz_certificate.out` and belongs in `CERTIFICATE_EXTRACTION.md` §3. Branch A stays inert until the view is rebuilt — `EXECUTE_VIEW_IMPLEMENTED` must still be flipped by hand. --- ## 5. Captures 4 and 5 — snapshots off, payloads clean **Snapshots (S-1): OFF, and the table is empty.** The `certificate_snapshots` variable was never set, so D7 uses its default of 0, and `certificate_snapshots` holds **0 rows**. The two facts agree, which is what §4's warning asked for. `ce_certificate.settings:snapshots_enabled` already shipped `false` and now **matches a measured D7 value rather than an assumption** — the config was missing from active storage entirely (§6.2) and has been imported. Certificates in D10 will therefore be **generated live**, exactly as D7 does today. Template mapping is intact: 108 `certificate_node` rows over 108 courses, 64 `certificate_node_settings` rows, all `landscape`. **Payment audit — no STOP.** | check | result | |---|---| | P-2 `x_login` / `x_tran_key` / acceptjs / transaction key | **0 / 0 / 0 / 0** of 26,797 rows | | P-3 full PAN / CVV | **0 / 0** | | P-3 masked PAN | 26,590 — normal in an AIM response, not a violation | **No merchant credentials and no cardholder data are stored.** The code reading in `MIGRATION_PLUGINS.md` §8e is confirmed by measurement. No payload stripping is required and no credential rotation is triggered. Volumes: 26,797 transactions / 21,392 successful ✅ matches R-4 · 28.6 MB of payload (avg 1.09 KB) · 38 transactions with a missing order · 158 with a dead uid. **P-5 — the test gateway is real:** `commerce_payment_example` holds **25 transactions, all marked successful**. Decision 4 stands — it must never become an active D10 gateway, and those 25 remain historical data. **P-7 — R-3 reconciles exactly.** Successful payments against non-completed orders, by state: ``` checkout_complete 42 checkout_payment 18 checkout_review 3 checkout_checkout 1 -> checkout_* = 64 ✅ the 64-set canceled 5 cart 5 ``` This is the per-state breakdown the runbook wanted precisely so that four checkout states collapsing into one cannot hide behind a correct total. --- ## 6. 🛑 Three defects that only execution could find ### 6.1 Four of the five capture scripts read the WRONG DATABASE, with errors suppressed `d7_quiz.sh`, `d7_view_quiz_certificate.sh`, `d7_certificate_snapshots.sh`, `d7_payment_audit.sh` and `d7_config_export.sh` all used: ```bash run() { mysql -u db -pdb -h db "$DB" -e "$1" 2>/dev/null; } ``` Two defects in one line: - **`-h db` is the container's own database.** Run from the D10 container — which is where the D7 reader credential lives — this pointed at D10's *empty* database. Every table was missing (error 1146) and `2>/dev/null` swallowed it. - **Run from the D7 container instead, `-u db -pdb` is DDEV's default account, which is WRITE-CAPABLE against D7** — contradicting each script's own "SELECT ONLY" docblock and `MIGRATION_STATE.md` §8. **Why it mattered more than a broken script normally would.** The first run of `d7_quiz.sh` printed every heading and **not one row**. Its STOP condition reads *"Q-4 empty = explanation (i), harmless"* — and **every** Stage 0 STOP condition is phrased "empty / zero = safe": | capture | what silence would have looked like | |---|---| | `d7_quiz` | Q-4 empty → "no quiz changed pass mark" | | `d7_view_quiz_certificate` | V-1 empty → "the view is in code" | | `d7_certificate_snapshots` | S-1 absent → "snapshotting is off" | | `d7_payment_audit` | P-2/P-3 zero → **"no credentials, no CVV"** | A silent connection failure is **indistinguishable from a clean pass**, and would have been recorded as one — the payment audit especially, which exists to clear a PCI question. **Fixed.** All five now use the proven read-only path (`ddev-ceonline-db` / `d10_migration_reader`, whose SELECT-only privileges are demonstrated in `MIGRATION_STATE.md` §3) with errors **visible** (`2>&1`). Originals are in `.logs/prefix-backup-2026-08-25/`. Only `d7_webform_components.sh` was already correct — which is why capture 1 worked first time. **The runbook's Stage 0 command is also wrong** and should be corrected: it says `cd /Users/apple/neerja/ceonline` and reaches the scripts via `/var/www/html/../ceonline-d10/…`. The scripts read D10's `settings.local.php`, so they must run from the **D10** project: ``` ddev exec bash /var/www/html/scripts/reconcile/