morluto/rea

Fork 0

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

[GH-ISSUE #8913] [Bug] Markdown tables lose Unicode edge whitespace and collapse distinct keys #7788

New issue

Open

opened 2026-11-04 15:15:31 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-04 15:15:31 +00:00

Owner

Originally created by @gongfpp on GitHub (Nov 4, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8913

Before submitting

I searched open and closed issues and pull requests for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

CLI

Observed behavior

Rendered Markdown tables discard leading/trailing Unicode whitespace in Evidence keys and values. For example, distinct column names "\u00a0name" and "name" both render as name. The same loss occurs with U+202F (narrow no-break space) and U+2003 (em space). ASCII spaces and tabs survive.

Reproduction

I ran an owner-level harness on the unmodified Markdown formatter closure from the revision below, then rendered its output with the repository's pinned VitePress 1.6.4 and parsed the HTML with parse5 8.0.1. This is not yet a built-CLI reproduction.

Inputs included a row with keys "\u00a0name" and "name", whose values were "\u00a0value\u00a0" and "value". Both rendered headers became name and both values became value. Separate leading/trailing U+202F and U+2003 fixtures also lost their edge characters; ASCII-space/tab controls retained them.

Expected behavior

Preserve the exact key/value text when Markdown tables are rendered, keeping distinct caller-supplied identities distinct, as the existing ASCII-space/tab protections do.

Impact and scope

Confirmed for the shared table formatter, including headers and body cells. This is a presentation fidelity defect, not evidence of saved Evidence mutation. Full CLI and validation-error consumer verification is still pending. Paragraph formatting and unrelated Unicode normalization are outside the proposed scope.

REA version

Source revision 89317a39fab23df81efa4331311d09d2110377bd.

Runtime and platform

Node.js 24.22.1; macOS 26.6.2 arm64.

Target and artifact context

Synthetic ordinary-JSON Evidence keys/values; no external provider.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

encodeMarkdownTableCell only protects /^[ \t]+|[ \t]+$/g, leaving Unicode edge whitespace for the table renderer to trim:
github.com/morluto/rea@89317a39fa/src/cli/cliOutputFormatter.ts (L346-L364)

Related, already merged: #7506, #7938, #7978, #7813. The residual Unicode case remains in current main. Searches of all 790 open PRs (including Drafts), related issue keywords, and the prior contributors' public branches found no same-scope active work in the inspected public scope.

Additional context

I'm preparing a narrow fix in the shared table-cell encoder with real CLI → Markdown renderer regressions, including identity-collision and ASCII/tab controls. If anyone is already handling this exact residual case, or there is a reason to defer it, please let me know so we can coordinate. This note is not a request for exclusive assignment or a claim of maintainer approval.

AI assistance is being used; human author-readiness declarations will remain for the human owner.

Originally created by @gongfpp on GitHub (Nov 4, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8913 ### Before submitting - [x] I searched open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area CLI ### Observed behavior Rendered Markdown tables discard leading/trailing Unicode whitespace in Evidence keys and values. For example, distinct column names `"\u00a0name"` and `"name"` both render as `name`. The same loss occurs with U+202F (narrow no-break space) and U+2003 (em space). ASCII spaces and tabs survive. ### Reproduction I ran an owner-level harness on the unmodified Markdown formatter closure from the revision below, then rendered its output with the repository's pinned VitePress 1.6.4 and parsed the HTML with parse5 8.0.1. This is **not yet a built-CLI reproduction**. Inputs included a row with keys `"\u00a0name"` and `"name"`, whose values were `"\u00a0value\u00a0"` and `"value"`. Both rendered headers became `name` and both values became `value`. Separate leading/trailing U+202F and U+2003 fixtures also lost their edge characters; ASCII-space/tab controls retained them. ### Expected behavior Preserve the exact key/value text when Markdown tables are rendered, keeping distinct caller-supplied identities distinct, as the existing ASCII-space/tab protections do. ### Impact and scope Confirmed for the shared table formatter, including headers and body cells. This is a presentation fidelity defect, not evidence of saved Evidence mutation. Full CLI and validation-error consumer verification is still pending. Paragraph formatting and unrelated Unicode normalization are outside the proposed scope. ### REA version Source revision `89317a39fab23df81efa4331311d09d2110377bd`. ### Runtime and platform Node.js 24.22.1; macOS 26.6.2 arm64. ### Target and artifact context Synthetic ordinary-JSON Evidence keys/values; no external provider. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence `encodeMarkdownTableCell` only protects `/^[ \t]+|[ \t]+$/g`, leaving Unicode edge whitespace for the table renderer to trim: https://github.com/morluto/rea/blob/89317a39fab23df81efa4331311d09d2110377bd/src/cli/cliOutputFormatter.ts#L346-L364 Related, already merged: #7506, #7938, #7978, #7813. The residual Unicode case remains in current main. Searches of all 790 open PRs (including Drafts), related issue keywords, and the prior contributors' public branches found no same-scope active work in the inspected public scope. ### Additional context I'm preparing a narrow fix in the shared table-cell encoder with real CLI → Markdown renderer regressions, including identity-collision and ASCII/tab controls. If anyone is already handling this exact residual case, or there is a reason to defer it, please let me know so we can coordinate. This note is not a request for exclusive assignment or a claim of maintainer approval. AI assistance is being used; human author-readiness declarations will remain for the human owner.

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#7788

No description provided.

Rows
Columns