morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4852] [Bug] XML plist decoder reports Apple-rejected integer, real, date and boolean text as observed values #3017

New issue

Closed

opened 2026-10-31 00:34:54 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-31 00:34:54 +00:00

Owner

Originally created by @apitoagents on GitHub (Oct 17, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4852

Before submitting

I searched the open and closed issues for a related report. #4714 concerns malformed XML (undeclared entities, unquoted attributes); #3373/#4042/#4834 concern value loss in well-formed literals. This report is about well-formed XML whose scalar text Apple's parser refuses.
I removed credentials, tokens, private paths, and sensitive target data. All fixtures are self-authored one-value plists.

Area

Evidence, artifacts, or reconstruction

Observed behavior

REA's own XML plist decoder (parseXmlPropertyList, used by inspect-keyed-archive, Interface Builder documents and the non-macOS plist paths) accepts <integer>, <real>, <date> and <true> text that Apple's property-list parser rejects, and returns a value with status: observed and Evidence confidence observed. In most cases no limitation discloses that the text was not a valid literal. One case also depends on the host time zone.

Each row is one keyed archive whose $objects[1] holds the element shown. plutil is /usr/bin/plutil -p / -lint on the same file; REA is the built CLI inspect-keyed-archive <file> --json --full-output on main 742b6f587.

`$objects[1]`	plutil	REA value (`observed`)	Limitation in output
`<integer> 42 </integer>`	rejected: Unknown character ' ' (0x20) in `<integer>`	`42`	none
`<integer>42abc</integer>`	rejected: Hex digit in non-hex `<integer>`	`42`	integer-precision limitation only
`<integer>4.2</integer>`	rejected: Unknown character '.'	`4`	integer-precision limitation only
`<integer>1e3</integer>`	rejected: Hex digit in non-hex `<integer>`	`1`	integer-precision limitation only
`<integer>4<!-- c -->2</integer>`	rejected: unexpected character !	`4`	integer-precision limitation only
`<integer><![CDATA[42]]></integer>`	rejected: Encountered empty `<integer>`	`42`	integer-precision limitation only
`<real> 1.5 </real>`	rejected: misformatted real	`1.5`	none
`<real>1.5abc</real>`	rejected: misformatted real	`1.5`	none
`<real>1,5</real>`	rejected: misformatted real	`1`	none
`<real>0x1p3</real>`	rejected: misformatted real	`0`	none
`<date>2026-10-17T12:00:00+02:00</date>`	rejected: Could not interpret `<date>`	`2026-10-17T10:00:00.000Z`	none
`<date>2026-10-17T12:00:00.5Z</date>`	rejected: Could not interpret `<date>`	`2026-10-17T12:00:00.500Z`	none
`<date>2026-10-17T12:00:00</date>`	rejected: Could not interpret `<date>`	`2026-10-17T10:00:00.000Z` on a UTC+2 host	none
`<true>x</true>`	rejected: Encountered non-empty `<true>`	`true`	none

Controls on the same path: <integer>42</integer>, <integer>+42</integer>, <integer>042</integer>, <real>.5</real>, <real>5.</real>, <real>1e3</real>, <real>1<![CDATA[.5]]></real> and <date>…Z</date> agree with plutil. <integer></integer> and <real></real> are refused by both (REA with a generic artifact_operation_failed / execution_failure rather than a typed format error).

Reproduction

Executed on macOS 13.2.1 arm64, Node 24.15.0, source build of main 742b6f587, host time zone UTC+2. For one row:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict><key>$archiver</key><string>NSKeyedArchiver</string><key>$version</key><integer>100000</integer><key>$objects</key><array><string>$null</string><real>1,5</real></array><key>$top</key><dict><key>root</key><dict><key>CF$UID</key><integer>1</integer></dict></dict></dict></plist>

/usr/bin/plutil -lint real_comma.plist → Encountered misformatted real on line 3.
node scripts/rea.mjs inspect-keyed-archive /absolute/path/real_comma.plist --json --full-output → exit 0, objects[1] = {"kind":"scalar","status":"observed","value":1}, confidence: "observed", limitations contain only the three standing keyed-archive notes.

Each row in the table was executed once the same way; the controls were executed once each.

Expected behavior

A literal Apple's parser refuses should not become an observed value. Either refuse the document with a typed format error naming the element and text, as the <integer></integer> case already does in spirit, or return an explicit unknown with a limitation naming the invalid literal. Which of the two fits the Evidence contract is a maintainer decision; what should not happen is status: observed with the wrong number, a time-zone-dependent date, or no disclosure.

Decoding should also not depend on the host time zone: <date> without a zone designator is invalid for Apple, and REA currently returns a different instant on each machine.

Impact and scope

Affects every consumer of parseXmlPropertyList: keyed archives, Interface Builder documents, and inspect_plist on Linux and Windows (on macOS inspect_plist goes through plutil, which refuses these files, so the macOS native path is not affected). Hand-edited or generated plists are where such text appears; frequency in shipped applications is unknown and was not measured. Binary plists are unaffected.

REA version

source commit 742b6f587 (main), package 6.5.0

Runtime and platform

Node 24.15.0; macOS 13.2.1 arm64; plutil from that macOS as the control

Target and artifact context

Self-authored one-value XML keyed archives; no third-party target

Interface

CLI

Earliest failure stage

Request parsing or validation

Relevant output or evidence

inspect-keyed-archive on the <real>1,5</real> fixture (trimmed):

{"id":1,"kind":"scalar","class_id":null,"class_name":null,"status":"observed","value":1}

confidence: "observed", no limitation beyond the standing keyed-archive notes.

Typed outcome or recovery expected

A typed format/input failure for the document, or an explicit unknown scalar with a limitation naming the element and literal. Not an observed value.

Analysis or suspected cause

Source-derived, src/domain/propertyListXml.ts:

integer: when parsePlistIntegerLiteral returns undefined, the decoder falls back to Number.parseInt(first.nodeValue, 10) and only calls numbers.markIncomplete(). parseInt reads a leading decimal prefix, so 42abc, 4.2, 1e3 and 42 decode to a number, and the only disclosure is the integer-precision limitation, which describes a different problem. <integer> 42 </integer> passes parsePlistIntegerLiteral after trimming, so nothing is marked.
real: Number.parseFloat(literal.text) accepts leading whitespace and stops at the first non-numeric character, so 1,5 → 1, 1.5abc → 1.5, 0x1p3 → 0, and literal.complete is true, so numbers.real(value) records them as good reals.
date: new Date(string) accepts ISO 8601 offsets, fractional seconds and zone-less text, and treats zone-less text as local time.
true / false: the element content is not checked.

A strict literal grammar at this one owner (sign + digits or 0x hex for integers, as parsePlistIntegerLiteral already defines; a decimal/exponent grammar for reals; YYYY-MM-DDTHH:MM:SSZ for dates; empty content for booleans) would make the decoder agree with the native parser. I can prepare a PR once the maintainers choose between refusal and explicit unknown.

Additional context

Found while cross-checking REA's decoder against plutil on a set of 50 edge-case plists; the other rows agreed. Related but distinct: #4714 (malformed XML admission) and #4849 (lost plutil diagnostic on macOS).

Originally created by @apitoagents on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4852 ### Before submitting - [x] I searched the open and closed issues for a related report. #4714 concerns malformed XML (undeclared entities, unquoted attributes); #3373/#4042/#4834 concern value loss in well-formed literals. This report is about well-formed XML whose scalar text Apple's parser refuses. - [x] I removed credentials, tokens, private paths, and sensitive target data. All fixtures are self-authored one-value plists. ### Area Evidence, artifacts, or reconstruction ### Observed behavior REA's own XML plist decoder (`parseXmlPropertyList`, used by `inspect-keyed-archive`, Interface Builder documents and the non-macOS plist paths) accepts `<integer>`, `<real>`, `<date>` and `<true>` text that Apple's property-list parser rejects, and returns a value with `status: observed` and Evidence confidence `observed`. In most cases no limitation discloses that the text was not a valid literal. One case also depends on the host time zone. Each row is one keyed archive whose `$objects[1]` holds the element shown. `plutil` is `/usr/bin/plutil -p` / `-lint` on the same file; REA is the built CLI `inspect-keyed-archive <file> --json --full-output` on main `742b6f587`. | `$objects[1]` | plutil | REA value (`observed`) | Limitation in output | | --- | --- | --- | --- | | `<integer> 42 </integer>` | rejected: Unknown character ' ' (0x20) in `<integer>` | `42` | none | | `<integer>42abc</integer>` | rejected: Hex digit in non-hex `<integer>` | `42` | integer-precision limitation only | | `<integer>4.2</integer>` | rejected: Unknown character '.' | `4` | integer-precision limitation only | | `<integer>1e3</integer>` | rejected: Hex digit in non-hex `<integer>` | `1` | integer-precision limitation only | | `<integer>42</integer>` | rejected: unexpected character ! | `4` | integer-precision limitation only | | `<integer><![CDATA[42]]></integer>` | rejected: Encountered empty `<integer>` | `42` | integer-precision limitation only | | `<real> 1.5 </real>` | rejected: misformatted real | `1.5` | none | | `<real>1.5abc</real>` | rejected: misformatted real | `1.5` | none | | `<real>1,5</real>` | rejected: misformatted real | `1` | none | | `<real>0x1p3</real>` | rejected: misformatted real | `0` | none | | `<date>2026-10-17T12:00:00+02:00</date>` | rejected: Could not interpret `<date>` | `2026-10-17T10:00:00.000Z` | none | | `<date>2026-10-17T12:00:00.5Z</date>` | rejected: Could not interpret `<date>` | `2026-10-17T12:00:00.500Z` | none | | `<date>2026-10-17T12:00:00</date>` | rejected: Could not interpret `<date>` | `2026-10-17T10:00:00.000Z` on a UTC+2 host | none | | `<true>x</true>` | rejected: Encountered non-empty `<true>` | `true` | none | Controls on the same path: `<integer>42</integer>`, `<integer>+42</integer>`, `<integer>042</integer>`, `<real>.5</real>`, `<real>5.</real>`, `<real>1e3</real>`, `<real>1<![CDATA[.5]]></real>` and `<date>…Z</date>` agree with plutil. `<integer></integer>` and `<real></real>` are refused by both (REA with a generic `artifact_operation_failed` / `execution_failure` rather than a typed format error). ### Reproduction Executed on macOS 13.2.1 arm64, Node 24.15.0, source build of main `742b6f587`, host time zone UTC+2. For one row: ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"><dict><key>$archiver</key><string>NSKeyedArchiver</string><key>$version</key><integer>100000</integer><key>$objects</key><array><string>$null</string><real>1,5</real></array><key>$top</key><dict><key>root</key><dict><key>CF$UID</key><integer>1</integer></dict></dict></dict></plist> ``` 1. `/usr/bin/plutil -lint real_comma.plist` → `Encountered misformatted real on line 3`. 2. `node scripts/rea.mjs inspect-keyed-archive /absolute/path/real_comma.plist --json --full-output` → exit 0, `objects[1]` = `{"kind":"scalar","status":"observed","value":1}`, `confidence: "observed"`, `limitations` contain only the three standing keyed-archive notes. Each row in the table was executed once the same way; the controls were executed once each. ### Expected behavior A literal Apple's parser refuses should not become an observed value. Either refuse the document with a typed format error naming the element and text, as the `<integer></integer>` case already does in spirit, or return an explicit unknown with a limitation naming the invalid literal. Which of the two fits the Evidence contract is a maintainer decision; what should not happen is `status: observed` with the wrong number, a time-zone-dependent date, or no disclosure. Decoding should also not depend on the host time zone: `<date>` without a zone designator is invalid for Apple, and REA currently returns a different instant on each machine. ### Impact and scope Affects every consumer of `parseXmlPropertyList`: keyed archives, Interface Builder documents, and `inspect_plist` on Linux and Windows (on macOS `inspect_plist` goes through plutil, which refuses these files, so the macOS native path is not affected). Hand-edited or generated plists are where such text appears; frequency in shipped applications is unknown and was not measured. Binary plists are unaffected. ### REA version source commit 742b6f587 (main), package 6.5.0 ### Runtime and platform Node 24.15.0; macOS 13.2.1 arm64; plutil from that macOS as the control ### Target and artifact context Self-authored one-value XML keyed archives; no third-party target ### Interface CLI ### Earliest failure stage Request parsing or validation ### Relevant output or evidence `inspect-keyed-archive` on the `<real>1,5</real>` fixture (trimmed): ```json {"id":1,"kind":"scalar","class_id":null,"class_name":null,"status":"observed","value":1} ``` `confidence: "observed"`, no limitation beyond the standing keyed-archive notes. ### Typed outcome or recovery expected A typed format/input failure for the document, or an explicit unknown scalar with a limitation naming the element and literal. Not an observed value. ### Analysis or suspected cause Source-derived, `src/domain/propertyListXml.ts`: - `integer`: when `parsePlistIntegerLiteral` returns `undefined`, the decoder falls back to `Number.parseInt(first.nodeValue, 10)` and only calls `numbers.markIncomplete()`. `parseInt` reads a leading decimal prefix, so `42abc`, `4.2`, `1e3` and `42` decode to a number, and the only disclosure is the integer-precision limitation, which describes a different problem. `<integer> 42 </integer>` passes `parsePlistIntegerLiteral` after trimming, so nothing is marked. - `real`: `Number.parseFloat(literal.text)` accepts leading whitespace and stops at the first non-numeric character, so `1,5` → `1`, `1.5abc` → `1.5`, `0x1p3` → `0`, and `literal.complete` is true, so `numbers.real(value)` records them as good reals. - `date`: `new Date(string)` accepts ISO 8601 offsets, fractional seconds and zone-less text, and treats zone-less text as local time. - `true` / `false`: the element content is not checked. A strict literal grammar at this one owner (sign + digits or `0x` hex for integers, as `parsePlistIntegerLiteral` already defines; a decimal/exponent grammar for reals; `YYYY-MM-DDTHH:MM:SSZ` for dates; empty content for booleans) would make the decoder agree with the native parser. I can prepare a PR once the maintainers choose between refusal and explicit unknown. ### Additional context Found while cross-checking REA's decoder against plutil on a set of 50 edge-case plists; the other rows agreed. Related but distinct: #4714 (malformed XML admission) and #4849 (lost plutil diagnostic on macOS).

bsakaguchi closed this issue

2026-10-31 00:34:54 +00:00

bsakaguchi commented

2026-10-31 00:34:55 +00:00

Author

Owner

@xu91102 commented on GitHub (Oct 17, 2026):

Independently reproduced through the built public CLI on main 3460ceac3f5dc93c767b1e7c39a511f026b41baa, Node 24.18.0, macOS arm64, using self-authored keyed archives.

/usr/bin/plutil -lint rejects each of these five inputs, while inspect-keyed-archive --json --full-output exits 0 and reports the scalar as observed, with Evidence confidence observed:

<integer> 42 </integer> and <integer>42abc</integer> become 42.
<real>1,5</real> becomes 1.
<date>2026-10-17T12:00:00+02:00</date> becomes a UTC timestamp.
<true>x</true> becomes true.

Four positive controls (plain integer, plain real, a real split across text and CDATA, and a UTC date) succeed in both tools. All nine input hashes remain unchanged. These are our own executions, not a replay of another contributor's results.

The first incorrect interpretation is in the shared XML scalar decoder: prefix numeric parsing, permissive JavaScript date parsing, and ignored boolean content. I am preparing a focused admission fix there, using the existing format-failure path. Native controls also confirm that non-finite reals, short/extended years, and real CDATA need to retain their supported handling. No Windows/Linux or other contributor's branch execution is claimed.

Compatibility note after checking the owning contract: current docs/native-investigation.md explicitly says that mixed XML numeric content and unclassified integer text retain decoded values with a precision limitation. That existing fallback policy conflicts with making all such inputs format failures. No production code has been changed, and I am not claiming a completed fix or submitting a contract-changing patch. The reproduction and native controls above remain valid.

@xu91102 commented on GitHub (Oct 17, 2026): Independently reproduced through the built public CLI on main `3460ceac3f5dc93c767b1e7c39a511f026b41baa`, Node 24.18.0, macOS arm64, using self-authored keyed archives. `/usr/bin/plutil -lint` rejects each of these five inputs, while `inspect-keyed-archive --json --full-output` exits 0 and reports the scalar as `observed`, with Evidence confidence `observed`: - `<integer> 42 </integer>` and `<integer>42abc</integer>` become `42`. - `<real>1,5</real>` becomes `1`. - `<date>2026-10-17T12:00:00+02:00</date>` becomes a UTC timestamp. - `<true>x</true>` becomes `true`. Four positive controls (plain integer, plain real, a real split across text and CDATA, and a UTC date) succeed in both tools. All nine input hashes remain unchanged. These are our own executions, not a replay of another contributor's results. The first incorrect interpretation is in the shared XML scalar decoder: prefix numeric parsing, permissive JavaScript date parsing, and ignored boolean content. I am preparing a focused admission fix there, using the existing format-failure path. Native controls also confirm that non-finite reals, short/extended years, and real CDATA need to retain their supported handling. No Windows/Linux or other contributor's branch execution is claimed. Compatibility note after checking the owning contract: current `docs/native-investigation.md` explicitly says that mixed XML numeric content and unclassified integer text retain decoded values with a precision limitation. That existing fallback policy conflicts with making all such inputs format failures. No production code has been changed, and I am not claiming a completed fix or submitting a contract-changing patch. The reproduction and native controls above remain valid.

bsakaguchi commented

2026-10-31 00:34:56 +00:00

Author

Owner

@shivsingh78 commented on GitHub (Oct 17, 2026):

I've reproduced the issue and have a local patch with strict scalar validation and regression tests. The focused suite passes, but the change makes malformed integer literals and mixed numeric markup fail where docs/native-investigation.md currently specifies retaining decoded values with a precision limitation.
Before submitting a PR, could a maintainer confirm whether this issue should change that documented contract to reject malformed scalar content, or preserve the existing fallback behavior and report an explicit unknown/limitation instead?
I have not committed or opened a PR because this decision affects the decoder's existing behavior and compatibility contract.

@shivsingh78 commented on GitHub (Oct 17, 2026): I've reproduced the issue and have a local patch with strict scalar validation and regression tests. The focused suite passes, but the change makes malformed integer literals and mixed numeric markup fail where docs/native-investigation.md currently specifies retaining decoded values with a precision limitation. Before submitting a PR, could a maintainer confirm whether this issue should change that documented contract to reject malformed scalar content, or preserve the existing fallback behavior and report an explicit unknown/limitation instead? I have not committed or opened a PR because this decision affects the decoder's existing behavior and compatibility contract.

bsakaguchi commented

2026-10-31 00:34:57 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 18, 2026):

确认这是与 #4714（畸形 XML）不同的一类问题：本报告针对 well-formed 但 Apple 解析器拒绝的 scalar 文本，REA 自带的 XML plist 解码器却把它们当作 observed values 输出。看到 #4849 及后续 fix(plist) 系列提交已按"保留 observed 非有限 real 拼写 / 让 XML 数值未知化"的方向处理，方向合理——解析器应当反映 Apple plutil 的判定边界，而不是把非法文本包装成合法值。建议为这些被 Apple 拒绝的 integer/real/date/boolean 文本各补一个回归测试，防止将来解码器放宽后重新吞掉判定。

@XinwangTao commented on GitHub (Oct 18, 2026): 确认这是与 #4714（畸形 XML）不同的一类问题：本报告针对 well-formed 但 Apple 解析器拒绝的 scalar 文本，REA 自带的 XML plist 解码器却把它们当作 observed values 输出。看到 #4849 及后续 fix(plist) 系列提交已按"保留 observed 非有限 real 拼写 / 让 XML 数值未知化"的方向处理，方向合理——解析器应当反映 Apple plutil 的判定边界，而不是把非法文本包装成合法值。建议为这些被 Apple 拒绝的 integer/real/date/boolean 文本各补一个回归测试，防止将来解码器放宽后重新吞掉判定。

bsakaguchi commented

2026-10-31 00:34:57 +00:00

Author

Owner

@morluto commented on GitHub (Oct 18, 2026):

Fixed in 3537e58c1.

The root cause was permissive downstream JavaScript interpretation: numeric prefixes, string-date parsing and ignored boolean content turned invalid literals into apparent values. The shared XML owner now interprets complete original scalar spans. Malformed or unrepresentable scalars retain their element, exact content and failure reason in $plist_type: "unknown" wrappers, with counted limitations. The surrounding archive remains useful. Unknown numerics never enter the number facts, so unrelated unsafe integers keep their exact decimal identity. Runtime wrapper identity keeps lookalike user dictionaries ordinary.

This replaces the old partial-number fallback and XML real/value:null unknown representation; the commit marks that compatibility change as breaking and updates the documented contract. Real references and CDATA remain supported; integer/date parsing uses raw spelling. Date fields are parsed in UTC. Unsupported calendar overflow remains unknown rather than emulating CoreFoundation normalization. Object status still describes observation of the serialized slot; an unknown wrapper does not assert an observed scalar value.

Validation executed on macOS/Node 24.18:

276 source tests across 12 files and 60 compiled/public tests across eight files passed; the final scalar changes were rerun through source tests and the public CLI/MCP regression.
Original main reproduced the host-time-zone-dependent date; measured baseline public CLI also confirmed 1,5 became 1. The fix's expanded public archive checks 20 invalid scalars, valid controls, both host time zones, CLI/MCP agreement, exact unsafe-integer recovery and unchanged original-byte digests.
68 tiny native plutil whitespace controls, plus independent scalar controls; actual macOS plist XML/binary conversion is covered in the 60 compiled tests. Full static/architecture checks, check:fast and docs checks passed. Two independent design/consumer reviews caught whitespace and ownership details before publication.

External research: DeepWiki, pinned Apple CF source, and Context7's xmldom locator/normalization documentation checked against installed 0.9.12. Native controls take precedence where older CF source differs (notably U+202F).

Tiny completed CLI costs: three calls per variant/task, separate first process and two alternating repeated processes, no true cold-cache claim. Repeated medians for a canonical task: 597→597 estimated cl100k output tokens, 0.447→0.441 s elapsed, 0.655→0.647 s CPU, 360→354 MB sampled peak process-family RSS. Malformed-real task: 596→704 output tokens, 0.435→0.439 s elapsed, 0.672→0.653 s CPU, 367→359 MB sampled RSS. These are small, noisy controls, not a speedup claim; whole-agent/catalog/request/MCP/large-input costs are unmeasured. An earlier exploratory round overlapped validation and is excluded from these medians.

No Linux/Windows or deep-provider runtime qualification, and no full CoreFoundation parity claim. The broader parser/lifecycle audit remains open.

@morluto commented on GitHub (Oct 18, 2026): Fixed in [3537e58c1](https://github.com/morluto/rea/commit/3537e58c1ab29309f06eabf50bc52adba9817a0c). The root cause was permissive downstream JavaScript interpretation: numeric prefixes, string-date parsing and ignored boolean content turned invalid literals into apparent values. The shared XML owner now interprets complete original scalar spans. Malformed or unrepresentable scalars retain their element, exact content and failure reason in `$plist_type: "unknown"` wrappers, with counted limitations. The surrounding archive remains useful. Unknown numerics never enter the number facts, so unrelated unsafe integers keep their exact decimal identity. Runtime wrapper identity keeps lookalike user dictionaries ordinary. This replaces the old partial-number fallback and XML `real/value:null` unknown representation; the commit marks that compatibility change as breaking and updates the documented contract. Real references and CDATA remain supported; integer/date parsing uses raw spelling. Date fields are parsed in UTC. Unsupported calendar overflow remains unknown rather than emulating CoreFoundation normalization. Object status still describes observation of the serialized slot; an unknown wrapper does not assert an observed scalar value. Validation executed on macOS/Node 24.18: - 276 source tests across 12 files and 60 compiled/public tests across eight files passed; the final scalar changes were rerun through source tests and the public CLI/MCP regression. - Original main reproduced the host-time-zone-dependent date; measured baseline public CLI also confirmed `1,5` became `1`. The fix's expanded public archive checks 20 invalid scalars, valid controls, both host time zones, CLI/MCP agreement, exact unsafe-integer recovery and unchanged original-byte digests. - 68 tiny native `plutil` whitespace controls, plus independent scalar controls; actual macOS plist XML/binary conversion is covered in the 60 compiled tests. Full static/architecture checks, check:fast and docs checks passed. Two independent design/consumer reviews caught whitespace and ownership details before publication. External research: [DeepWiki](https://deepwiki.com/search/in-cfpropertylistc-how-do-pars_224109fa-a9ef-4071-9c03-0343f5d26918), [pinned Apple CF source](https://github.com/apple-oss-distributions/CF/blob/384ff680be7c7445fee6ce0c55e9ae11a46e07c5/CFPropertyList.c), and Context7's xmldom locator/normalization documentation checked against installed 0.9.12. Native controls take precedence where older CF source differs (notably U+202F). Tiny completed CLI costs: three calls per variant/task, separate first process and two alternating repeated processes, no true cold-cache claim. Repeated medians for a canonical task: 597→597 estimated cl100k output tokens, 0.447→0.441 s elapsed, 0.655→0.647 s CPU, 360→354 MB sampled peak process-family RSS. Malformed-real task: 596→704 output tokens, 0.435→0.439 s elapsed, 0.672→0.653 s CPU, 367→359 MB sampled RSS. These are small, noisy controls, not a speedup claim; whole-agent/catalog/request/MCP/large-input costs are unmeasured. An earlier exploratory round overlapped validation and is excluded from these medians. No Linux/Windows or deep-provider runtime qualification, and no full CoreFoundation parity claim. The broader parser/lifecycle audit remains open.

bsakaguchi referenced this issue

2026-11-01 21:10:54 +00:00

[GH-ISSUE #3795] [Tracker] Open documentation issues and pull requests (October 2026) #1468

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3017

No description provided.

Rows
Columns