morluto/rea

Fork 0

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

[GH-ISSUE #5749] [Bug] inspect-model-artifact byte-swaps unsupported GGUF versions #3494

New issue

Closed

opened 2026-10-31 00:41:08 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:41:08 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5749

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

inspect-model-artifact refuses a little-endian GGUF v1 header with a reason claiming its version is 16777216. A synthetic little-endian v4 probe similarly reports 67108864. Both exit 1 with code and category equal to unsupported_target. Refusing these versions is appropriate; the reported version number is misleading. Supported little-endian v2/v3 and big-endian v3 controls succeed.

Reproduction

From the source checkout below, with locked dependencies installed and the CLI built, run:

work_dir="$(mktemp -d)"
mkdir -p "$work_dir/home" "$work_dir/cfg" "$work_dir/data" "$work_dir/cache" "$work_dir/state" "$work_dir/tmp"
python3 -I - "$work_dir" <<'PYTHON'
from pathlib import Path
import struct
import sys
root = Path(sys.argv[1])
(root / "le-v1.gguf").write_bytes(b"GGUF" + struct.pack("<III", 1, 0, 0))
for name, order, version in [
    ("le-v4", "<", 4),
    ("le-v2", "<", 2),
    ("le-v3", "<", 3),
    ("be-v3", ">", 3),
    ("be-v2", ">", 2),
]:
    (root / f"{name}.gguf").write_bytes(
        b"GGUF" + struct.pack(order + "IQQ", version, 0, 0)
    )
for name in ("le-v1", "le-v4"):
    raw = (root / f"{name}.gguf").read_bytes()[4:8]
    print(name, "version bytes:", raw.hex(), "little-endian value:", struct.unpack("<I", raw)[0])
PYTHON
run_rea() {
  env -i PATH="$PATH" HOME="$work_dir/home" XDG_CONFIG_HOME="$work_dir/cfg" \
    XDG_DATA_HOME="$work_dir/data" XDG_CACHE_HOME="$work_dir/cache" \
    XDG_STATE_HOME="$work_dir/state" TMPDIR="$work_dir/tmp" REA_LOG_LEVEL=silent \
    node scripts/rea.mjs inspect-model-artifact "$1" --json
}
for name in le-v1 le-v4 le-v2 le-v3 be-v3 be-v2; do
  run_rea "$work_dir/$name.gguf" > "$work_dir/$name.json"
  result=$?
  printf '%s exit=%s\n' "$name" "$result"
  jq -c 'if .code then {code,category,reason:.details.reason} else .normalized_result | {format,version,byte_order} end' "$work_dir/$name.json"
done

The independent verifier and submitter each executed this reproduction at the baseline and observed the results below. The v1 fixture uses its original 32-bit zero counts. The v4 fixture is an unsupported-version probe using the current header layout, not a claim about an existing future format.

Expected behavior

Keep unsupported versions refused, but preserve the declared version in the reason or explicitly qualify byte-order uncertainty. Failure to recognize a supported little-endian version does not establish big-endian byte order.

The repository contract requires meaningful failure reasons, preservation of source values, and explicit unknowns. The model guide documents content-based v2/v3 inspection including byte order. The pinned GGUF specification defaults to little-endian absent additional byte-order information.

Impact and scope

P3: misleading wording in an unsupported-input refusal. No supported-input inspection failure, incorrect acceptance, data loss, or security impact was observed. Reading and decoding the four version bytes independently recovers the affected diagnostic fact. The observed scope is the generated fixtures; real model files and MCP transport were not tested for this report.

REA version

rea-agents 6.7.0, source commit 9d8e7803326a382cbbb3ffdb900f5e93e5442d68. Fetched and rechecked main at d0067ba34a39ea47dd7e11bb2e6169bc0938cc3f: no changes since baseline in AGENTS.md, docs/model-artifacts.md, src/model/GgufHeader.ts, src/model/ModelArtifactProvider.ts, or tests/boundary/model/modelArtifact.test.ts. Runtime reproduction used the baseline build; main was checked by source history, not rebuilt or executed.

Runtime and platform

Node.js v26.12.0; macOS 27.0.1; arm64. Hopper/Ghidra are not involved.

Target and artifact context

Locally generated GGUF headers with zero tensors and metadata entries; no model weights, providers, credentials, downloads, or network services. The 16-byte v1 header and 24-byte v4 probe both encode their version little-endian.

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Observed JSON subsets from the real built CLI:

{"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 16777216 is unsupported; supported versions are 2 and 3"}
{"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 67108864 is unsupported; supported versions are 2 and 3"}

Python independently decodes version bytes 01000000 as little-endian 1 and 04000000 as little-endian 4. The reported values are their big-endian interpretations. In the same run, little-endian v2/v3 and big-endian v3 exit 0 with the matching version and byte_order in normalized_result. Big-endian v2 exits 1 with code: target_unavailable, category: unsupported_target, and reason Big-endian GGUF requires version 3. Stderr is empty.

The independent verifier additionally reproduced v1 with 64-bit probe counts and a little-endian version 999 probe reporting 3875733504. Evidence provenance: observed; local verification: independently reproduced.

Typed outcome or recovery expected

Keep unsupported_target for unsupported versions and guidance that the reader supports versions 2 and 3. Report version 1 and the synthetic version 4 accurately, or preserve the uncertainty explicitly. A repair should keep little-endian v2/v3 and big-endian v3 successful and big-endian v2 refused. This report requests accurate diagnostics, not support for inspecting older or unknown formats.

Analysis or suspected cause

Source-derived reasoning: GgufHeader.ts:241-253 selects little-endian only when its reading equals 2 or 3. Otherwise it reads the same bytes big-endian and interpolates that value into the unsupported-version reason. ModelArtifactProvider.ts:115-135 preserves that reason in the public unsupported-target error. This explanation agrees with the observed CLI results; no bundled dependency was identified as the cause.

The existing version 999 test checks the unsupported classification without asserting the diagnostic version number.

Additional context

Prepared with AI assistance and independent verification. #3323 and #5603 introduced model inspection; #5625 concerns cancellation losing validated metadata, and #3666 requests quantization reconstruction. None covers this refusal diagnostic. No earlier known-good version or successful restoration has been established.

Originally created by @coygeek on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5749 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior `inspect-model-artifact` refuses a little-endian GGUF v1 header with a reason claiming its version is 16777216. A synthetic little-endian v4 probe similarly reports 67108864. Both exit 1 with `code` and `category` equal to `unsupported_target`. Refusing these versions is appropriate; the reported version number is misleading. Supported little-endian v2/v3 and big-endian v3 controls succeed. ### Reproduction From the source checkout below, with locked dependencies installed and the CLI built, run: ```sh work_dir="$(mktemp -d)" mkdir -p "$work_dir/home" "$work_dir/cfg" "$work_dir/data" "$work_dir/cache" "$work_dir/state" "$work_dir/tmp" python3 -I - "$work_dir" <<'PYTHON' from pathlib import Path import struct import sys root = Path(sys.argv[1]) (root / "le-v1.gguf").write_bytes(b"GGUF" + struct.pack("<III", 1, 0, 0)) for name, order, version in [ ("le-v4", "<", 4), ("le-v2", "<", 2), ("le-v3", "<", 3), ("be-v3", ">", 3), ("be-v2", ">", 2), ]: (root / f"{name}.gguf").write_bytes( b"GGUF" + struct.pack(order + "IQQ", version, 0, 0) ) for name in ("le-v1", "le-v4"): raw = (root / f"{name}.gguf").read_bytes()[4:8] print(name, "version bytes:", raw.hex(), "little-endian value:", struct.unpack("<I", raw)[0]) PYTHON run_rea() { env -i PATH="$PATH" HOME="$work_dir/home" XDG_CONFIG_HOME="$work_dir/cfg" \ XDG_DATA_HOME="$work_dir/data" XDG_CACHE_HOME="$work_dir/cache" \ XDG_STATE_HOME="$work_dir/state" TMPDIR="$work_dir/tmp" REA_LOG_LEVEL=silent \ node scripts/rea.mjs inspect-model-artifact "$1" --json } for name in le-v1 le-v4 le-v2 le-v3 be-v3 be-v2; do run_rea "$work_dir/$name.gguf" > "$work_dir/$name.json" result=$? printf '%s exit=%s\n' "$name" "$result" jq -c 'if .code then {code,category,reason:.details.reason} else .normalized_result | {format,version,byte_order} end' "$work_dir/$name.json" done ``` The independent verifier and submitter each executed this reproduction at the baseline and observed the results below. The v1 fixture uses its original 32-bit zero counts. The v4 fixture is an unsupported-version probe using the current header layout, not a claim about an existing future format. ### Expected behavior Keep unsupported versions refused, but preserve the declared version in the reason or explicitly qualify byte-order uncertainty. Failure to recognize a supported little-endian version does not establish big-endian byte order. The [repository contract](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/AGENTS.md#architecture-and-cleanup) requires meaningful failure reasons, preservation of source values, and explicit unknowns. The [model guide](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/docs/model-artifacts.md) documents content-based v2/v3 inspection including byte order. The pinned [GGUF specification](https://github.com/ggml-org/ggml/blob/da8e2a54b919557b816b1c2beb432ccb766f7ce0/docs/gguf.md#file-structure) defaults to little-endian absent additional byte-order information. ### Impact and scope P3: misleading wording in an unsupported-input refusal. No supported-input inspection failure, incorrect acceptance, data loss, or security impact was observed. Reading and decoding the four version bytes independently recovers the affected diagnostic fact. The observed scope is the generated fixtures; real model files and MCP transport were not tested for this report. ### REA version `rea-agents` 6.7.0, source commit `9d8e7803326a382cbbb3ffdb900f5e93e5442d68`. Fetched and rechecked main at `d0067ba34a39ea47dd7e11bb2e6169bc0938cc3f`: no changes since baseline in `AGENTS.md`, `docs/model-artifacts.md`, `src/model/GgufHeader.ts`, `src/model/ModelArtifactProvider.ts`, or `tests/boundary/model/modelArtifact.test.ts`. Runtime reproduction used the baseline build; main was checked by source history, not rebuilt or executed. ### Runtime and platform Node.js v26.12.0; macOS 27.0.1; arm64. Hopper/Ghidra are not involved. ### Target and artifact context Locally generated GGUF headers with zero tensors and metadata entries; no model weights, providers, credentials, downloads, or network services. The 16-byte v1 header and 24-byte v4 probe both encode their version little-endian. ### Interface CLI ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence Observed JSON subsets from the real built CLI: ```json {"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 16777216 is unsupported; supported versions are 2 and 3"} {"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 67108864 is unsupported; supported versions are 2 and 3"} ``` Python independently decodes version bytes `01000000` as little-endian 1 and `04000000` as little-endian 4. The reported values are their big-endian interpretations. In the same run, little-endian v2/v3 and big-endian v3 exit 0 with the matching `version` and `byte_order` in `normalized_result`. Big-endian v2 exits 1 with `code: target_unavailable`, `category: unsupported_target`, and reason `Big-endian GGUF requires version 3`. Stderr is empty. The independent verifier additionally reproduced v1 with 64-bit probe counts and a little-endian version 999 probe reporting 3875733504. Evidence provenance: observed; local verification: independently reproduced. ### Typed outcome or recovery expected Keep `unsupported_target` for unsupported versions and guidance that the reader supports versions 2 and 3. Report version 1 and the synthetic version 4 accurately, or preserve the uncertainty explicitly. A repair should keep little-endian v2/v3 and big-endian v3 successful and big-endian v2 refused. This report requests accurate diagnostics, not support for inspecting older or unknown formats. ### Analysis or suspected cause Source-derived reasoning: [GgufHeader.ts:241-253](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/model/GgufHeader.ts#L241-L253) selects little-endian only when its reading equals 2 or 3. Otherwise it reads the same bytes big-endian and interpolates that value into the unsupported-version reason. [ModelArtifactProvider.ts:115-135](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/model/ModelArtifactProvider.ts#L115-L135) preserves that reason in the public unsupported-target error. This explanation agrees with the observed CLI results; no bundled dependency was identified as the cause. The [existing version 999 test](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/tests/boundary/model/modelArtifact.test.ts#L508-L522) checks the unsupported classification without asserting the diagnostic version number. ### Additional context Prepared with AI assistance and independent verification. #3323 and #5603 introduced model inspection; #5625 concerns cancellation losing validated metadata, and #3666 requests quantization reconstruction. None covers this refusal diagnostic. No earlier known-good version or successful restoration has been established.

bsakaguchi closed this issue

2026-10-31 00:41:08 +00:00

bsakaguchi commented

2026-10-31 00:41:09 +00:00

Author

Owner

@sledz9224-ops commented on GitHub (Oct 21, 2026):

śr., 21 paź 2026, 03:34 użytkownik Coy Geek @.***>
napisał:

coygeek created an issue (morluto/rea#5749)
https://github.com/morluto/rea/issues/5749
Before submitting

I searched the open and closed issues for a related report.

I removed credentials, tokens, private paths, and sensitive target
data.

Area

Evidence, artifacts, or reconstruction
Observed behavior

inspect-model-artifact refuses a little-endian GGUF v1 header with a
reason claiming its version is 16777216. A synthetic little-endian v4 probe
similarly reports 67108864. Both exit 1 with code and category equal to
unsupported_target. Refusing these versions is appropriate; the reported
version number is misleading. Supported little-endian v2/v3 and big-endian
v3 controls succeed.
Reproduction

From the source checkout below, with locked dependencies installed and the
CLI built, run:

work_dir="$(mktemp -d)"
mkdir -p "$work_dir/home" "$work_dir/cfg" "$work_dir/data" "$work_dir/cache" "$work_dir/state" "$work_dir/tmp"
python3 -I - "$work_dir" <<'PYTHON'from pathlib import Pathimport structimport sysroot = Path(sys.argv[1])(root / "le-v1.gguf").write_bytes(b"GGUF" + struct.pack("<III", 1, 0, 0))for name, order, version in [ ("le-v4", "<", 4), ("le-v2", "<", 2), ("le-v3", "<", 3), ("be-v3", ">", 3), ("be-v2", ">", 2),]: (root / f"{name}.gguf").write_bytes( b"GGUF" + struct.pack(order + "IQQ", version, 0, 0) )for name in ("le-v1", "le-v4"): raw = (root / f"{name}.gguf").read_bytes()[4:8] print(name, "version bytes:", raw.hex(), "little-endian value:", struct.unpack("<I", raw)[0])PYTHONrun_rea() {
env -i PATH="$PATH" HOME="$work_dir/home" XDG_CONFIG_HOME="$work_dir/cfg"
XDG_DATA_HOME="$work_dir/data" XDG_CACHE_HOME="$work_dir/cache"
XDG_STATE_HOME="$work_dir/state" TMPDIR="$work_dir/tmp" REA_LOG_LEVEL=silent
node scripts/rea.mjs inspect-model-artifact "$1" --json
}for name in le-v1 le-v4 le-v2 le-v3 be-v3 be-v2; do
run_rea "$work_dir/$name.gguf" > "$work_dir/$name.json"
result=$?
printf '%s exit=%s\n' "$name" "$result"
jq -c 'if .code then {code,category,reason:.details.reason} else .normalized_result | {format,version,byte_order} end' "$work_dir/$name.json"done

The independent verifier and submitter each executed this reproduction at
the baseline and observed the results below. The v1 fixture uses its
original 32-bit zero counts. The v4 fixture is an unsupported-version probe
using the current header layout, not a claim about an existing future
format.
Expected behavior

Keep unsupported versions refused, but preserve the declared version in
the reason or explicitly qualify byte-order uncertainty. Failure to
recognize a supported little-endian version does not establish big-endian
byte order.

The repository contract
https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/AGENTS.md#architecture-and-cleanup
requires meaningful failure reasons, preservation of source values, and
explicit unknowns. The model guide
https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/docs/model-artifacts.md
documents content-based v2/v3 inspection including byte order. The pinned GGUF
specification
https://github.com/ggml-org/ggml/blob/da8e2a54b919557b816b1c2beb432ccb766f7ce0/docs/gguf.md#file-structure
defaults to little-endian absent additional byte-order information.
Impact and scope

P3: misleading wording in an unsupported-input refusal. No supported-input
inspection failure, incorrect acceptance, data loss, or security impact was
observed. Reading and decoding the four version bytes independently
recovers the affected diagnostic fact. The observed scope is the generated
fixtures; real model files and MCP transport were not tested for this
report.
REA version

rea-agents 6.7.0, source commit 9d8e780332.
Fetched and rechecked main at d0067ba34a:
no changes since baseline in AGENTS.md, docs/model-artifacts.md,
src/model/GgufHeader.ts, src/model/ModelArtifactProvider.ts, or
tests/boundary/model/modelArtifact.test.ts. Runtime reproduction used the
baseline build; main was checked by source history, not rebuilt or executed.
Runtime and platform

Node.js v26.12.0; macOS 27.0.1; arm64. Hopper/Ghidra are not involved.
Target and artifact context

Locally generated GGUF headers with zero tensors and metadata entries; no
model weights, providers, credentials, downloads, or network services. The
16-byte v1 header and 24-byte v4 probe both encode their version
little-endian.
Interface

CLI
Earliest failure stage

Native analysis or reconstruction
Relevant output or evidence

Observed JSON subsets from the real built CLI:

{"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 16777216 is unsupported; supported versions are 2 and 3"}
{"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 67108864 is unsupported; supported versions are 2 and 3"}

Python independently decodes version bytes 01000000 as little-endian 1
and 04000000 as little-endian 4. The reported values are their big-endian
interpretations. In the same run, little-endian v2/v3 and big-endian v3
exit 0 with the matching version and byte_order in normalized_result.
Big-endian v2 exits 1 with code: target_unavailable, category:
unsupported_target, and reason Big-endian GGUF requires version 3. Stderr
is empty.

The independent verifier additionally reproduced v1 with 64-bit probe
counts and a little-endian version 999 probe reporting 3875733504. Evidence
provenance: observed; local verification: independently reproduced.
Typed outcome or recovery expected

Keep unsupported_target for unsupported versions and guidance that the
reader supports versions 2 and 3. Report version 1 and the synthetic
version 4 accurately, or preserve the uncertainty explicitly. A repair
should keep little-endian v2/v3 and big-endian v3 successful and big-endian
v2 refused. This report requests accurate diagnostics, not support for
inspecting older or unknown formats.
Analysis or suspected cause

Source-derived reasoning: GgufHeader.ts:241-253
https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/model/GgufHeader.ts#L241-L253
selects little-endian only when its reading equals 2 or 3. Otherwise it
reads the same bytes big-endian and interpolates that value into the
unsupported-version reason. ModelArtifactProvider.ts:115-135
https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/model/ModelArtifactProvider.ts#L115-L135
preserves that reason in the public unsupported-target error. This
explanation agrees with the observed CLI results; no bundled dependency was
identified as the cause.

The existing version 999 test
https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/tests/boundary/model/modelArtifact.test.ts#L508-L522
checks the unsupported classification without asserting the diagnostic
version number.
Additional context

Prepared with AI assistance and independent verification. #3323
https://github.com/morluto/rea/issues/3323 and #5603
https://github.com/morluto/rea/pull/5603 introduced model inspection;
#5625 https://github.com/morluto/rea/issues/5625 concerns cancellation
losing validated metadata, and #3666
https://github.com/morluto/rea/issues/3666 requests quantization
reconstruction. None covers this refusal diagnostic. No earlier known-good
version or successful restoration has been established.

—
Reply to this email directly, view it on GitHub
https://github.com/morluto/rea/issues/5749?email_source=notifications&email_token=CN4FRZJNMYKLWW4KPR5XKJ35VAODNA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJZGUZTCNRRGQYDTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/CN4FRZP6MAQ3S32AUST6PVD5VAODNAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMBZHE3DMOJTGM5US43TOVSTWNJZGUZTCNRRGQYDTILWAI
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
https://github.com/notifications/mobile/ios/CN4FRZPPBYDT2UWWTUKC3VT5VAODNA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJZGUZTCNRRGQYDTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG
and Android
https://github.com/notifications/mobile/android/CN4FRZNXDMNAYB3FAXSAD7L5VAODNA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJZGUZTCNRRGQYDTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA.
Download it today!
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@sledz9224-ops commented on GitHub (Oct 21, 2026): śr., 21 paź 2026, 03:34 użytkownik Coy Geek ***@***.***> napisał: > *coygeek* created an issue (morluto/rea#5749) > <https://github.com/morluto/rea/issues/5749> > Before submitting > > - I searched the open and closed issues for a related report. > - I removed credentials, tokens, private paths, and sensitive target > data. > > Area > > Evidence, artifacts, or reconstruction > Observed behavior > > inspect-model-artifact refuses a little-endian GGUF v1 header with a > reason claiming its version is 16777216. A synthetic little-endian v4 probe > similarly reports 67108864. Both exit 1 with code and category equal to > unsupported_target. Refusing these versions is appropriate; the reported > version number is misleading. Supported little-endian v2/v3 and big-endian > v3 controls succeed. > Reproduction > > From the source checkout below, with locked dependencies installed and the > CLI built, run: > > work_dir="$(mktemp -d)" > mkdir -p "$work_dir/home" "$work_dir/cfg" "$work_dir/data" "$work_dir/cache" "$work_dir/state" "$work_dir/tmp" > python3 -I - "$work_dir" <<'PYTHON'from pathlib import Pathimport structimport sysroot = Path(sys.argv[1])(root / "le-v1.gguf").write_bytes(b"GGUF" + struct.pack("<III", 1, 0, 0))for name, order, version in [ ("le-v4", "<", 4), ("le-v2", "<", 2), ("le-v3", "<", 3), ("be-v3", ">", 3), ("be-v2", ">", 2),]: (root / f"{name}.gguf").write_bytes( b"GGUF" + struct.pack(order + "IQQ", version, 0, 0) )for name in ("le-v1", "le-v4"): raw = (root / f"{name}.gguf").read_bytes()[4:8] print(name, "version bytes:", raw.hex(), "little-endian value:", struct.unpack("<I", raw)[0])PYTHONrun_rea() { > env -i PATH="$PATH" HOME="$work_dir/home" XDG_CONFIG_HOME="$work_dir/cfg" \ > XDG_DATA_HOME="$work_dir/data" XDG_CACHE_HOME="$work_dir/cache" \ > XDG_STATE_HOME="$work_dir/state" TMPDIR="$work_dir/tmp" REA_LOG_LEVEL=silent \ > node scripts/rea.mjs inspect-model-artifact "$1" --json > }for name in le-v1 le-v4 le-v2 le-v3 be-v3 be-v2; do > run_rea "$work_dir/$name.gguf" > "$work_dir/$name.json" > result=$? > printf '%s exit=%s\n' "$name" "$result" > jq -c 'if .code then {code,category,reason:.details.reason} else .normalized_result | {format,version,byte_order} end' "$work_dir/$name.json"done > > The independent verifier and submitter each executed this reproduction at > the baseline and observed the results below. The v1 fixture uses its > original 32-bit zero counts. The v4 fixture is an unsupported-version probe > using the current header layout, not a claim about an existing future > format. > Expected behavior > > Keep unsupported versions refused, but preserve the declared version in > the reason or explicitly qualify byte-order uncertainty. Failure to > recognize a supported little-endian version does not establish big-endian > byte order. > > The repository contract > <https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/AGENTS.md#architecture-and-cleanup> > requires meaningful failure reasons, preservation of source values, and > explicit unknowns. The model guide > <https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/docs/model-artifacts.md> > documents content-based v2/v3 inspection including byte order. The pinned GGUF > specification > <https://github.com/ggml-org/ggml/blob/da8e2a54b919557b816b1c2beb432ccb766f7ce0/docs/gguf.md#file-structure> > defaults to little-endian absent additional byte-order information. > Impact and scope > > P3: misleading wording in an unsupported-input refusal. No supported-input > inspection failure, incorrect acceptance, data loss, or security impact was > observed. Reading and decoding the four version bytes independently > recovers the affected diagnostic fact. The observed scope is the generated > fixtures; real model files and MCP transport were not tested for this > report. > REA version > > rea-agents 6.7.0, source commit 9d8e7803326a382cbbb3ffdb900f5e93e5442d68. > Fetched and rechecked main at d0067ba34a39ea47dd7e11bb2e6169bc0938cc3f: > no changes since baseline in AGENTS.md, docs/model-artifacts.md, > src/model/GgufHeader.ts, src/model/ModelArtifactProvider.ts, or > tests/boundary/model/modelArtifact.test.ts. Runtime reproduction used the > baseline build; main was checked by source history, not rebuilt or executed. > Runtime and platform > > Node.js v26.12.0; macOS 27.0.1; arm64. Hopper/Ghidra are not involved. > Target and artifact context > > Locally generated GGUF headers with zero tensors and metadata entries; no > model weights, providers, credentials, downloads, or network services. The > 16-byte v1 header and 24-byte v4 probe both encode their version > little-endian. > Interface > > CLI > Earliest failure stage > > Native analysis or reconstruction > Relevant output or evidence > > Observed JSON subsets from the real built CLI: > > {"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 16777216 is unsupported; supported versions are 2 and 3"} > {"code":"unsupported_target","category":"unsupported_target","reason":"GGUF version 67108864 is unsupported; supported versions are 2 and 3"} > > Python independently decodes version bytes 01000000 as little-endian 1 > and 04000000 as little-endian 4. The reported values are their big-endian > interpretations. In the same run, little-endian v2/v3 and big-endian v3 > exit 0 with the matching version and byte_order in normalized_result. > Big-endian v2 exits 1 with code: target_unavailable, category: > unsupported_target, and reason Big-endian GGUF requires version 3. Stderr > is empty. > > The independent verifier additionally reproduced v1 with 64-bit probe > counts and a little-endian version 999 probe reporting 3875733504. Evidence > provenance: observed; local verification: independently reproduced. > Typed outcome or recovery expected > > Keep unsupported_target for unsupported versions and guidance that the > reader supports versions 2 and 3. Report version 1 and the synthetic > version 4 accurately, or preserve the uncertainty explicitly. A repair > should keep little-endian v2/v3 and big-endian v3 successful and big-endian > v2 refused. This report requests accurate diagnostics, not support for > inspecting older or unknown formats. > Analysis or suspected cause > > Source-derived reasoning: GgufHeader.ts:241-253 > <https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/model/GgufHeader.ts#L241-L253> > selects little-endian only when its reading equals 2 or 3. Otherwise it > reads the same bytes big-endian and interpolates that value into the > unsupported-version reason. ModelArtifactProvider.ts:115-135 > <https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/model/ModelArtifactProvider.ts#L115-L135> > preserves that reason in the public unsupported-target error. This > explanation agrees with the observed CLI results; no bundled dependency was > identified as the cause. > > The existing version 999 test > <https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/tests/boundary/model/modelArtifact.test.ts#L508-L522> > checks the unsupported classification without asserting the diagnostic > version number. > Additional context > > Prepared with AI assistance and independent verification. #3323 > <https://github.com/morluto/rea/issues/3323> and #5603 > <https://github.com/morluto/rea/pull/5603> introduced model inspection; > #5625 <https://github.com/morluto/rea/issues/5625> concerns cancellation > losing validated metadata, and #3666 > <https://github.com/morluto/rea/issues/3666> requests quantization > reconstruction. None covers this refusal diagnostic. No earlier known-good > version or successful restoration has been established. > > — > Reply to this email directly, view it on GitHub > <https://github.com/morluto/rea/issues/5749?email_source=notifications&email_token=CN4FRZJNMYKLWW4KPR5XKJ35VAODNA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJZGUZTCNRRGQYDTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/CN4FRZP6MAQ3S32AUST6PVD5VAODNAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMBZHE3DMOJTGM5US43TOVSTWNJZGUZTCNRRGQYDTILWAI> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/CN4FRZPPBYDT2UWWTUKC3VT5VAODNA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJZGUZTCNRRGQYDTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> > and Android > <https://github.com/notifications/mobile/android/CN4FRZNXDMNAYB3FAXSAD7L5VAODNA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJZGUZTCNRRGQYDTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. > Download it today! > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

bsakaguchi commented

2026-10-31 00:41:09 +00:00

Author

Owner

@gensokyo-dev commented on GitHub (Oct 21, 2026):

I am taking this unclaimed diagnostic bug. I will reproduce it on current main, preserve version/byte-order uncertainty at the GGUF boundary, and verify supported little-/big-endian controls and real-model CLI/MCP behavior before submitting a focused fix.

@gensokyo-dev commented on GitHub (Oct 21, 2026): I am taking this unclaimed diagnostic bug. I will reproduce it on current main, preserve version/byte-order uncertainty at the GGUF boundary, and verify supported little-/big-endian controls and real-model CLI/MCP behavior before submitting a focused fix.

bsakaguchi referenced this issue

2026-10-31 00:44:31 +00:00

[GH-ISSUE #6408] [Feature] Inspect MFC CRuntimeClass metadata in PE binaries and link each serializable class to its Serialize(CArchive&) function #3840

bsakaguchi referenced this issue

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

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471