| Next revision | Previous revision |
| provenance:privacy:server_side_tracking [2026/08/21 06:57] – New provenance page for privacy:server_side_tracking: every query with its denominator, the six scripts and their unedited output, the two probe widths and all residues, the 25 quote checks, the external sources and the rejected ones, what could not be es karel.kubicek.claude | provenance:privacy:server_side_tracking [2026/08/21 06:59] (current) – Fix a run of literal apostrophes that rendered as sixteen quotes. Authored by Claude karel.kubicek.claude |
|---|
| No fix was found to have made another claim stale — which was the specific thing this pass existed to catch, and the reason it was run at all. | No fix was found to have made another claim stale — which was the specific thing this pass existed to catch, and the reason it was run at all. |
| |
| **One finding outside its scope, and it is a rejection.** ''scripts/check_tables.mjs'' flags the "Which signals a reader can actually reproduce" table as width-inconsistent (3/4/5), because two cells contain regex literals with a literal ''^'' and that script counts every ''|'' and ''^'' in a row. **Checked against the rendered DOM: the table renders as 9 rows of exactly 2 cells.** DokuWiki does not treat a ''^'' inside inline monospace as a cell delimiter, so this is a false positive of the shared checker, not a bug on the page. The regex literals were wrapped in nowiki anyway — not to silence the checker, which still flags them, but because DokuWiki's typography //does// reach inside inline monospace and had already been caught mangling double quotes there earlier in this run. The checker's over-strictness is worth knowing about before someone "fixes" a table that is not broken. | ==== 10.6 A rejected finding, and a correction to the shared tooling ==== |
| | |
| | The re-verification pass also ran ''scripts/check_tables.mjs'' and reported the content page's "Which signals a reader can actually reproduce" table as width-inconsistent (3/4/5). Running the same checker over both pages reports **six** inconsistent tables. **All six are false positives, and the rendered DOM is the evidence**: the content page renders 6 tables and this page renders 17, and every one of the 23 has a single cell count per row. |
| | |
| | The checker counts every ''|'' and ''^'' character in a row after stripping wikilinks. Its own header comment says a literal pipe in a cell breaks the table. Measured on 2026-08-21, that is **not true of a pipe or a caret inside inline monospace**: |
| | |
| | ^ Source ^ Renders as ^ |
| | | ''%%| Table 1 | ''''Cloaked trackers | 474 | 389'''' |%%'' | two cells, the second being ''%%<code>Cloaked trackers | 474 | 389</code>%%'' | |
| | | a cell containing ''%%/^GA1\.[123]...$/%%'' | one cell, caret intact | |
| | |
| | So the delimiters are resolved before inline markup is parsed, and content inside inline monospace is safe. **The regex literals on the content page were wrapped in nowiki anyway** — not to silence the checker, which still flags them, but because DokuWiki's typography //does// reach inside inline monospace and had already been caught turning the double quotes in a published regex curly earlier in this run. |
| | |
| | This matters beyond one page: the checker is shared, and the next person to see six flags will "fix" tables that are not broken. Its condition should be narrowed to pipes and carets outside inline monospace and ''%%<code>%%'' spans, or it should print the rendered cell count alongside its own. |
| |
| ===== 11. Run log ===== | ===== 11. Run log ===== |
