P3: the IIF in plain ASCII with every change listed, and the CPA package as of one day (defects 7, 21)

The CPA package's general-journal.iif now holds every posted entry through
as_of (closing entries left out, D-36), written as plain ASCII with CR LF,
DOCNUM the entry id, QuickBooks Desktop's field limits and subaccount types
honoured, and every character written differently listed in the export's
warnings and the README (grouped by substitution, TINs masked). The 1099
worksheet stops at as_of too. PDFs print CJK, Arabic, Hebrew, Thai and
Devanagari (Noto fallbacks, OFL), and so does the viewer. has_full_tin reads
Unicode separators.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T3gXMVt7XJPi6ens1or9Dj

docs/spec/rules.md

@@ -490,7 +490,8 @@ years after 2026, indexed to inflation and rounded to the nearest $100
 Attorneys' gross proceeds stay at $600 (not modeled).
 
 What counts as paid: payments made in the calendar year (§6041(a)), so a
-prepayment counts when made. The engine counts credits minus debits to the
+prepayment counts when made. A worksheet as of a day (the CPA package's,
+B-33) counts the year's payments from January 1 through that day. The engine counts credits minus debits to the
 payment sources on a vendor's tagged entries: `[books] cash_accounts` and
 `financing_accounts` (a member or lender paying on the company's behalf;
 the company is still the payer). A card charge leaves neither (1099-K); a
@@ -680,7 +681,12 @@ with `include_tins` (DECISION, the owner, 2026-10-15: for the CPA, when
 asked): a refusal that quotes its input masks any TIN in it
 (`parties::redact_full_tins`, checked by `refusals_never_echo_a_tin`),
 and a party text field refuses nine digits however they are separated
-(space, hyphen, dot, slash, underscore; `has_full_tin`). Files holding one (`books.get_w9`, `books.vendor_1099`'s
+(`has_full_tin`: up to three spaces, hyphens, dots, slashes or
+underscores between neighbors, in any script's digits; past ASCII every
+Unicode space and dash and the fullwidth and small forms count, and
+invisible characters such as a zero-width space or a right-to-left mark
+don't count toward the three: `sources/unicode-tin-text.md`, Unicode
+17.0). Files holding one (`books.get_w9`, `books.vendor_1099`'s
 `csv` with `include_tins`, and the CPA package, whose K-1 and 1099
 worksheets carry every member's and payee's TIN by default) are never
 written to a path: no tool takes one (D-29, P2 slice 6). Each is handed
@@ -1015,3 +1021,170 @@ checked to change no figure or entry; `approval_rules_off_by_default`,
 (`exports_round_trip`) and codec unit tests; `ledger-mcp`
 `tests/spec_kept.rs`; Lean `Step.record_changes_no_figure`,
 `Reachable.records`; fuzz `fuzz_settings_replay`.
+
+## B-33 A package as of a day shows the books through that day
+
+**Status:** CONVENTION (a report as of a day reports the books on that
+day: balances through it, a period's activity from the period's start
+through it; nearest authorities the accounting period, IRS Pub. 538,
+`sources/irs-periods-and-methods.md`, and the information returns'
+calendar year, `sources/irs-1099-thresholds.md`); DECISION (owner,
+2026-10-20, plan D-36: the 1099 worksheet stops at as_of too)
+
+Nothing in the CPA package made as of a day (`books.export_cpa_package`,
+the viewer's Export for CPA) reflects anything dated after it: no figure,
+entry, receipt or worksheet row. The statements and the ledgers cover
+the fiscal year containing as_of, through it; the balance sheet, the
+trial balance and the fixed asset register are as of it (the register
+only when an asset was bought by then); receipts/ holds the evidence of
+the year's entries through it; the members' equity statement and the
+K-1 worksheet, the year to date; general-journal.iif, every posted entry
+from the first through it (B-34). The 1099 worksheet counts the payments
+of as_of's calendar year from January 1 through as_of: information
+returns add up what is paid "in any calendar year" (26 U.S.C. §6041(a);
+"during such calendar year", §6041A(a)(2)), so a worksheet as of June 30
+is the year to date, and a vendor not yet at the threshold is not yet
+reportable; a December 31 package counts the whole year, as before. The
+chart of accounts and documents/ are as they stand when the package is
+made. One list of cash accounts and one of financing accounts serve the
+whole package (the request's, else the settings'): the cash flow, the
+K-1 worksheet, the IIF's bank accounts and the 1099 payments read the
+same.
+
+**Enforced:** `ledger_package::build_package` (INVARIANTS 1, 6, 7),
+`ledger_package::export_iif`, `ledger_package::vendor_1099_report` and
+`ledger_core::vendor_1099_report_with_members` (`through`).
+**Checked:** `ledger-package` `tests/package.rs`
+(`every_file_in_an_as_of_package_stops_at_as_of`: books the same through
+as_of, with and without activity after it (a 1099 payment with its
+receipt, an asset bought, a reversal of an entry dated as_of, the
+members' contributions, an earlier asset sold), make the same package
+byte for byte, every file and which files there are, with and without a
+fixed asset register, mid-year and at year end; `as_of_package_iif_stops_at_as_of`,
+`the_iif_through_as_of_at_its_edges`,
+`the_1099_worksheet_stops_at_as_of`,
+`one_list_of_cash_accounts_per_package`; the property
+`iif_ties_to_the_trial_balance_as_of`, 2,000 cases); `ledger-mcp`
+`oracle_mcp.rs` (`cpa_package_holds_the_year_and_its_evidence`); the
+bookspec examples `bookspec/examples/as-of-package-stops-at-as-of.toml`
+and `bookspec/examples/1099-worksheet-through-as-of.toml`.
+
+## B-34 The QuickBooks Desktop file (IIF): plain ASCII, every entry through as_of, closes left out
+
+**Status:** AUTHORITY (Intuit, `sources/intuit-iif.md`: IIF files are
+ASCII text, tab-separated, with no escape; an account is known by its
+NAME, a subaccount's NAME its path joined by colons; lists come before
+what uses them; DOCNUM is "the transaction's number"; the kit's 2007+
+example file ends every line CR LF; QuickBooks Desktop holds an account
+name of 31 characters, an account number of 7 and a memo of 4,095; "The
+parent and subaccount must be the same account type"; a journal entry
+to accounts receivable or payable needs a customer or vendor, and takes
+one such account a transaction); CONVENTION (a QuickBooks integrator and
+an IIF importer, same file: a longer name is cut on a chart import but not
+in a journal's lines; a double quote is a text delimiter); DECISION (owner, 2026-10-20, plan D-36: plain ASCII, what isn't
+ASCII transliterated and listed; CR LF; DOCNUM the entry's id; closing
+entries left out; every entry since the company began until the CPA
+says otherwise); Unicode Standard Annex #14 (the mandatory line breaks)
+
+1. **One transaction per posted entry dated on or before as_of**, from
+   the first, in the order posted, **except period-closing entries**:
+   QuickBooks keeps no closing entries (it works out retained earnings
+   itself; its "closing date" only locks a period), so an imported close
+   would zero its period's profit. The file's balances are the trial
+   balance as of as_of without the closes, and its income and expenses
+   each period's profit and loss; the members' shares are in the
+   package's members' equity statement and K-1 worksheet.
+   `books.export` iif takes as_of (default today), never a range.
+   Whether the file should hold only the fiscal year instead goes to the
+   CPA before the 2027 package (D-36); for the first year the two are
+   the same.
+2. **DOCNUM is the entry's id** in the books, on the TRNS and every SPL,
+   so the CPA can trace a QuickBooks transaction to its entry and its
+   receipts.
+3. **The file is ASCII and every line ends CR LF.** In a field (a NAME,
+   an ACCNUM, a MEMO) a tab or a mandatory line break (LF, VT, FF, CR,
+   NEL, U+2028, U+2029) is a space; any other control character is '?';
+   printable ASCII is itself, but a double quote, which is a single one
+   (QuickBooks reads a double quote as a text delimiter); any other
+   character is its transliteration by deunicode 1.6.0, pinned exactly
+   ("René" "Rene", "北京" "Bei Jing", "—" "--", "“" "'", "😀" "grinning";
+   a transliterated word's trailing space dropped at the end or before a
+   space), or '?' when it has none. Every other file in the package keeps
+   the books' text (the PDFs carry Inter and Noto fallbacks for Chinese,
+   Japanese, Korean, Arabic, Hebrew, Thai and Devanagari, Arabic and
+   Hebrew set right to left; no emoji font, so an emoji prints as an
+   empty box).
+4. **An account's own name**, so written, has each ':' replaced by '-'
+   (a fullwidth colon too), is trimmed ('?' if nothing is left) and cut
+   to 31 characters (QuickBooks Desktop's limit; cut by QuickBooks, the
+   ACCNT line and the transactions' would no longer match); its NAME is
+   its parents' NAMEs and its own, joined by ':'. A subaccount whose
+   QuickBooks type differs from its parent's (a bank account under a
+   header that is no bank, an asset's cost under a "Fixed assets" header)
+   is written at the top level, its own subaccounts with it: QuickBooks
+   gives a subaccount its parent's type, and the type decides where its
+   balance shows. Each parent is declared before its subaccounts, the
+   accounts otherwise in the order of their codes. Accounts whose NAMEs
+   would match ignoring case, which QuickBooks would merge, get
+   " (code)" after their own names (the name cut to make room, the code
+   written like a name, "no number" for a blank one), level by level from
+   the top and again until no two match; a match left after that (two
+   codes written alike, ignoring case, or alike in their first 30
+   characters) is refused.
+5. **ACCNUM is the account's code**, written as a field and trimmed, or
+   left blank (ACCNUM is optional; the NAME identifies the account) when
+   it is longer than 7 characters (QuickBooks Desktop's limit) or another
+   account's would be written the same, ignoring case. **A MEMO** is cut
+   to 4,095 characters (QuickBooks Desktop's limit).
+6. **Nothing changes silently.** Each account name, number or place and
+   each memo the file writes differently from the books (`Iif::changes`)
+   is said, both texts quoted and escaped, one line each, in the
+   `warnings` of `books.export` and `books.export_cpa_package` and in the
+   package README (the viewer's note counts them): each account's name,
+   number and place a line; the memos grouped by what is written
+   differently, each run of changed characters once with every entry it
+   is in (`"—" is written "--" in the memos of entries 3, 5, 9`), then
+   the memos cut. No line holds a full TIN (B-26): a run of nine digits,
+   in any script's digits and separators, is masked, and so is every
+   numeral of a text that holds one once written as a field (digits a
+   tab apart, letters deunicode writes as digits); a memo line whose
+   digits are masked says so.
+7. **No customer or vendor NAME.** Intuit's IIF help makes NAME
+   optional and states no need of it in a journal; QuickBooks Desktop
+   asks for a customer or vendor on a journal entry to accounts
+   receivable or payable, and takes one A/R or A/P account a transaction
+   (Intuit staff and help, `sources/intuit-iif.md`). Writing names would
+   need the customer and vendor lists declared as well, with names unique
+   across them. So the file names none, and the package README names the
+   entries with a line on an A/R or A/P account (`Iif::receivable_payable`),
+   so the CPA can add the name if QuickBooks asks.
+
+**Enforced:** `ledger_import::iif` (`field`, `iif_accounts`,
+`journal_to_iif`, `Iif::warnings`), `ledger_package::export_iif` and
+`build_package`, `ledger-mcp` `books.export` and
+`books.export_cpa_package`.
+**Checked:** `ledger-import` `iif.rs` unit tests (every one of the
+1,112,064 Unicode scalar values written as printable ASCII, alone and
+beside a letter, and kept by a second pass; the transliteration table
+pinned); `tests/spec_import.rs` (`iif_docnum_is_the_entry_id`,
+`iif_writes_plain_ascii_and_lists_every_change`,
+`iif_every_line_ends_cr_lf`, `iif_distinct_accounts_never_share_a_name`,
+`iif_a_subaccount_of_another_type_stands_at_the_top_level`,
+`iif_declares_each_parent_before_its_subaccounts`,
+`iif_fits_quickbooks_desktop_limits`,
+`iif_warnings_group_the_memos_by_what_is_written_differently`,
+`iif_warnings_never_hold_a_tin`,
+`iif_change_warnings_are_one_line_each`,
+`iif_keeps_a_tin_readable_to_the_package_scan`, the properties
+`iif_round_trips_random_books` and
+`iif_names_never_clash_and_every_change_is_listed`); `ledger-package`
+`tests/package.rs` (`iif_leaves_out_period_closes`,
+`the_readme_lists_what_the_iif_writes_differently`,
+`the_readme_names_the_entries_on_receivables_and_payables`,
+`the_bookspec_iif_example_matches_the_engine`, and B-33's); the bookspec
+example `bookspec/examples/iif-quickbooks-journal-file.toml` (formats
+appendix: the file line by line and its changes, derived by hand);
+`ledger-mcp` `oracle_mcp.rs`
+(`iif_declares_accounts_by_role_and_balances_every_transaction`,
+`iif_without_as_of_is_as_of_today_and_ties_to_the_trial_balance`),
+`mcp_stdio.rs` (`mcp_import_export_over_stdio`).

docs/spec/sources/intuit-iif.md

@@ -107,12 +107,84 @@ SHA-256 of the retrieved file (`journal.zip`): `4f578d227810f5bfadde142cdab9f941
 
 Cited (not quoted): its read-me says list declarations (accounts, classes, customers, vendors, other names) come first so names land on the correct lists, and that header columns must be present even when left blank. Its `!ACCNT` rows show a subaccount written `Construction:Labor`. Its address fields that contain a comma are wrapped in double quotes (`"Anywhere, AZ 85740"`), as a spreadsheet writes tab-delimited text; the kit does not say whether QuickBooks strips those quotes.
 
+## Character limitations for fields in QuickBooks (US, updated 8/3/2026)
+Source: <https://quickbooks.intuit.com/learn-support/en-us/help-article/printing-preferences/character-limitations-fields-quickbooks/L7eIy5gE3_US_en_US>  
+Retrieved: 2026-10-20  
+SHA-256: not available (read through a fetch tool; a direct download was refused by the server)
+
+Tagged for QuickBooks Desktop (Mac Plus, Premier Plus, Pro Plus). Its one sentence of text:
+
+> Each field in your company data file has a maximum number of characters that can be entered.
+
+Cited (not quoted), from its table: Account Name 31; Account Numbers 7; Memo 4,095 (of which printed checks show about 30 to 60 and the Transaction Detail report 96); invoice number 11; customer, vendor and other names 41. It has no row for a journal entry's number, and says nothing of what QuickBooks does with longer text, on import or otherwise.
+
+The same article for the UK (`.../en-uk/help-article/printing-preferences/character-limitations-fields-quickbooks/L7eIy5gE3_GB_en_GB`, retrieved 2026-10-20) gives Account Name 31 but Account Numbers 25: a different product. The books are a US company's, so the US figures hold.
+
+## Intuit's .NET SDK reference: `Account.Name`
+Source: <https://static.developer.intuit.com/sdkdocs/qbv3doc/ippdotnetdevkitv3/html/cd41295e-8e12-8b96-1ff3-728a807fa9cd.htm>  
+Retrieved: 2026-10-20
+
+Cited (not quoted): "User recognizable name for the Account", with ValidRange "QBW: Max=31" (QuickBooks Desktop; QuickBooks Online: 100). Its `Account.AcctNum` page (`.../95a0835b-80bd-4fe1-2d7f-96ea2c372442.htm`) states no length.
+
+So the limits are Intuit's own: an account name (one level of a subaccount's NAME, as the account's own name is entered) at most 31 characters, an account number at most 7, a memo at most 4,095. The books write each within them: a longer level is cut to 31 (then no two NAMEs may match), a longer number is left out of ACCNUM (it is optional; the NAME identifies the account), a longer memo is cut to 4,095, and every one is listed (rules.md B-34).
+
+## Add, edit, or delete accounts in QuickBooks Desktop (US, updated 8/4/2026)
+Source: <https://quickbooks.intuit.com/learn-support/en-us/help-article/chart-accounts/add-edit-delete-accounts-quickbooks-desktop-mac/L95VT34uN_US_en_US>  
+Retrieved: 2026-10-20  
+SHA-256: not available (read through a fetch tool)
+
+Tagged for QuickBooks Desktop (Mac Plus, Premier Plus, Pro Plus, Accountant, Enterprise). Under "Add a subaccount", a note:
+
+> The parent and subaccount must be the same account type.
+
+So the books write a subaccount whose QuickBooks type differs from its parent's (a bank account under a header that is no bank, an asset's cost account under a "Fixed assets" header) at the top level, its own subaccounts with it, and list it (rules.md B-34). Intuit's own journal sample (`journal.zip`, above) declares `Construction:Labor` without ever declaring `Construction`, so QuickBooks makes a missing parent itself; the books declare each parent before its subaccounts all the same, so a parent keeps its own type and number rather than taking ones QuickBooks guesses.
+
+## Customer and vendor names on accounts receivable and payable
+
+Searched 2026-10-20. What Intuit says:
+
+- The IIF Import Kit's header help (`!TRNS.htm`, `!SPL.htm`, above) marks TRNSTYPE, ACCNT and AMOUNT required; NAME is "the name of the customer, vendor, payee, or employee", not marked required, with no word on accounts receivable or payable. The kit's General Journal example and the journal sample have no NAME column at all.
+- The journal sample's read-me (`journal.zip`, `General Journal IIF file read me.txt`, SHA-256 `2e45b0f7a15d78f487d510547084d401d99bda02630d10747e37e00ca56f2c52`): "A customer name attached to the spl line of a General Journal transaction will import to the vendor list and the vendor name attached to the trns line of a General Journal transaction will import to the other names list unless the names are already on the correct lists." So a NAME written without declaring the customer and vendor lists first lands on the wrong list.
+- Intuit's QuickBooks Team, answering "Can I post a journal entry to Accounts Receivable without specifying a customer name?" (Maybelle_S, QuickBooks Team badge, 12 January 2024), <https://quickbooks.intuit.com/community/reports-and-accounting-5/can-i-post-a-journal-entry-to-accounts-receivable-without-specifying-a-customer-name-64395> (retrieved 2026-10-20), about QuickBooks Desktop:
+
+  > Accounts Receivable (AR) or Accounts Payable (AP) requires a customer or vendor name assignment.
+
+- "Troubleshoot ... Warning: You Cannot Use More Than One" (US, updated 8/5/2026; QuickBooks Desktop Mac Plus, Premier Plus, Pro Plus), <https://quickbooks.intuit.com/learn-support/en-us/help-article/accounts-receivable/warning-cannot-use-one-ar-ap-account-transaction/L7xqDWcmE_US_en_US> (retrieved 2026-10-20): QuickBooks will not record a transaction with two A/R accounts, two A/P accounts, or one of each; its message:
+
+  > Warning: You cannot use more than one A/R or A/P account in the same transaction.
+
+Not Intuit, for the record: a third-party IIF vendor answering on Intuit's community (BigRedConsulting, 14 April 2020, <https://quickbooks.intuit.com/learn-support/en-us/other-questions/iif-import-error-3040/00/535675>) wrote that "a NAME is required for any AR row", about a bill, not a journal; QuickBooks Desktop sync tools quote the refusal "Transaction split lines to accounts receivable must include a customer on that split line" (Acctivate, <https://hub.acctivate.com/articles/troubleshoot/synchronization/transaction-split-lines-to-accounts-receivable-must-include-a-customer-on-that-split-line>).
+
+No Intuit source says what an IIF journal import does with an A/R or A/P line that has no NAME (refuses it, imports it, or asks). So the books write no NAME (writing names would need the customer and vendor lists declared too, with a name unique across them) and the package README names the entries with an A/R or A/P line, so the CPA can add the name in QuickBooks if it asks (rules.md B-34 rule 7).
+
+## What QuickBooks does with an over-long name (not Intuit)
+Source: Thomson Reuters, Accounting CS help, "Export payroll journal entries", <https://thomsonreuters.com/en-us/help/accounting-cs/integrate-data-with-other-applications/export-payroll-journal-entries>  
+Retrieved: 2026-10-20
+
+Cited (not quoted), a QuickBooks integrator's documentation, not Intuit's: QuickBooks limits an account's name to 31 characters; importing a chart of accounts IIF file cuts a longer name to 31, but importing a journal IIF file does not, so the journal's accounts no longer match and QuickBooks creates a new (duplicate) bank account for each it doesn't recognize. It advises names of 31 characters or fewer. This is why the books cut each level themselves: the ACCNT line and every TRNS and SPL line then carry the same name.
+
+## Double quotes in an IIF field (not Intuit)
+Intuit's own journal sample (above) wraps fields holding a comma in double quotes, as a spreadsheet writes tab-delimited text, so QuickBooks' reader treats a double quote as more than a character. Two non-Intuit sources say so outright:
+
+- Reckon, "Importing the IIF file in Reckon Accounts Business, changes the Inch “ symbol to Feet ‘ symbol", <https://help.reckon.com/article/1ap8nwl0v2-kba-5589-importing-the-iif-file-in-reckon-accounts-business-changes-the-inch-symbol-to-feet-symbol> (retrieved 2026-10-20, no date given). Cited (not quoted): Reckon Accounts Business, which imports IIF files, changes each double quote to a single one by design, because many file formats treat the double quote as a special character.
+- Jonathan Clark, interchange-users mailing list, 28 July 2003, <https://www.interchangecommerce.org/pipermail/interchange-users/2003-July/034578.html>:
+
+  > From what we can tell, QB uses double quotation marks (") as text delimiters when there are certain characters in the field.
+
+  > For imports, you will break the import if you have double quotes within your text
+
+So the books write a double quote as a single one, listed like any other change (rules.md B-34).
+
 ## Not found in any Intuit source
 
-Searched 2026-10-13 (the help articles above and every document in the IIF Import Kit and journal sample); none states:
+Searched 2026-10-13 and 2026-10-20 (the help articles above and every document in the IIF Import Kit and journal sample); none states:
 
-- an escaping mechanism for tabs, line breaks, or double quotes inside a field (no escape syntax is documented; the only safe reading is that fields must not contain tabs or line breaks);
+- an escaping mechanism for tabs, line breaks, or double quotes inside a field (no escape syntax is documented; the only safe reading is that fields must not contain tabs or line breaks, and, from the reports above, double quotes);
 - an explicit sentence that a transaction's TRNS and SPL amounts must sum to zero (every example does; the sign rule implies it);
 - the allowed number of decimal places, or whether thousands separators or currency symbols are accepted in AMOUNT;
-- the character encoding beyond "ASCII text";
-- whether a four-digit year is accepted everywhere despite the "MM/DD/YY" wording (Intuit's 2007+ example uses one).
+- the character encoding beyond "ASCII text" (so the books write plain ASCII, transliterating anything else and listing what changed: rules.md B-34, DECISION D-36);
+- whether a four-digit year is accepted everywhere despite the "MM/DD/YY" wording (Intuit's 2007+ example uses one);
+- what QuickBooks Desktop does on import with an account name, account number or memo longer than its limits (only the non-Intuit note above, for names), how many levels of subaccounts it allows, or a limit on a whole NAME with its parents;
+- how long a journal entry's number (DOCNUM) may be (the limits article has no row for it; the books' entry ids are a few digits);
+- whether QuickBooks matches account names or numbers ignoring case (the books keep no two alike even ignoring case);
+- what an IIF journal import does with a line on accounts receivable or payable that names no customer or vendor (above).

docs/spec/sources/unicode-tin-text.md

@@ -0,0 +1,65 @@
+# Unicode character properties: how a TIN can be written
+
+Governs `ledger_core::parties::has_full_tin` (rules.md B-26): which
+characters separate a TIN's digits, and which are invisible between them.
+The Unicode Character Database is © Unicode, Inc., under the Unicode
+License v3, which permits copying the data files; the code point lists
+below are transcribed from them (facts, not prose).
+
+## PropList.txt, Unicode 17.0.0 (2025-06-30)
+Source: <https://www.unicode.org/Public/17.0.0/ucd/PropList.txt>  
+Retrieved: 2026-10-20  
+SHA-256 of the retrieved file: `130dcddcaadaf071008bdfce1e7743e04fdfbc910886f017d9f9ac931d8c64dd`
+
+**Dash** (every dash and hyphen): U+002D, U+058A ARMENIAN HYPHEN, U+05BE
+HEBREW PUNCTUATION MAQAF, U+1400, U+1806, U+2010..U+2015 (HYPHEN,
+NON-BREAKING HYPHEN, FIGURE DASH, EN DASH, EM DASH, HORIZONTAL BAR),
+U+2053 SWUNG DASH, U+207B SUPERSCRIPT MINUS, U+208B SUBSCRIPT MINUS,
+U+2212 MINUS SIGN, U+2E17, U+2E1A, U+2E3A..U+2E3B, U+2E40, U+2E5D,
+U+301C WAVE DASH, U+3030 WAVY DASH, U+30A0, U+FE31..U+FE32, U+FE58 SMALL
+EM DASH, U+FE63 SMALL HYPHEN-MINUS, U+FF0D FULLWIDTH HYPHEN-MINUS,
+U+10D6E, U+10EAD.
+
+**White_Space**: U+0009..U+000D, U+0020, U+0085, U+00A0, U+1680,
+U+2000..U+200A, U+2028 LINE SEPARATOR, U+2029 PARAGRAPH SEPARATOR,
+U+202F, U+205F, U+3000 IDEOGRAPHIC SPACE. Less the controls and the two
+line and paragraph separators, these are the space separators (general
+category Zs). Rust's `char::is_whitespace` is this property.
+
+## DerivedCoreProperties.txt, Unicode 17.0.0
+Source: <https://www.unicode.org/Public/17.0.0/ucd/DerivedCoreProperties.txt>  
+Retrieved: 2026-10-20  
+SHA-256 of the retrieved file: `24c7fed1195c482faaefd5c1e7eb821c5ee1fb6de07ecdbaa64b56a99da22c08`
+
+**Default_Ignorable_Code_Point** (drawn as nothing when not supported):
+U+00AD SOFT HYPHEN, U+034F, U+061C ARABIC LETTER MARK, U+115F..U+1160,
+U+17B4..U+17B5, U+180B..U+180F, U+200B..U+200F (ZERO WIDTH SPACE, the
+joiners, LEFT-TO-RIGHT and RIGHT-TO-LEFT MARK), U+202A..U+202E,
+U+2060..U+206F (WORD JOINER, the invisible operators, the directional
+isolates), U+3164, U+FE00..U+FE0F (variation selectors), U+FEFF ZERO
+WIDTH NO-BREAK SPACE, U+FFA0, U+FFF0..U+FFF8, U+1BCA0..U+1BCA3,
+U+1D173..U+1D17A, U+E0000..U+E0FFF (tags, variation selectors
+supplement).
+
+## Compatibility decompositions (UnicodeData.txt)
+Derived 2026-10-20 with Python's `unicodedata` (Unicode 16.0.0; these
+mappings are unchanged in 17.0): the characters past ASCII whose NFKC
+form is one of the ASCII separators.
+
+- `' '`: U+00A0, U+2000..U+200A, U+202F, U+205F, U+3000 (all Zs).
+- `'-'`: U+FE63, U+FF0D (both Dash).
+- `'.'`: U+2024 ONE DOT LEADER, U+FE52 SMALL FULL STOP, U+FF0E FULLWIDTH
+  FULL STOP.
+- `'/'`: U+FF0F FULLWIDTH SOLIDUS.
+- `'_'`: U+FE33, U+FE34, U+FE4D..U+FE4F, U+FF3F FULLWIDTH LOW LINE.
+
+## How the books read them (rules.md B-26)
+
+A TIN is nine numerals (any script's: `char::is_numeric`) with at most
+three separators between neighbors. In ASCII the separators are exactly
+the space, hyphen, dot, slash and underscore (a tab or line break is
+not one). Past ASCII they are every Zs space, every Dash character, and
+the compatibility forms of the dot, slash and underscore above; the line
+and paragraph separators and NEL are line breaks, as in ASCII, and end a
+run. Default-ignorable characters are invisible, so any number of them
+may sit between two digits without counting toward the three.