Summarize engine type lane families
This commit is contained in:
parent
f3c3eb7262
commit
2d5f5dec10
3 changed files with 128 additions and 3 deletions
|
|
@ -13,7 +13,8 @@ This file is the short active queue for the current runtime and reverse-engineer
|
|||
- The active static parser head is now the `engine_types` semantics frontier.
|
||||
The repo now has structural inspectors for `.car`, `.lco`, `.cgo`, and `.cct`, but the binary side is still only partially semantic: the checked 1.05 corpus grounds `.car` fixed strings at `0x0c / 0x48 / 0x84` plus a second fixed stem slot at `0xa2` and a side-view resource name at `0xc0`, while `.lco` carries a stable primary stem at `0x04` and only conditional companion/body slots at `0x0c` and `0x12` when the leading stem slot is padded.
|
||||
The checked 1.05 corpus now also splits `.car` auxiliary stems into `126` direct matches, `14` role-neutral roots, and only `5` truly distinct cases, while `.cgo` collapses into five stable scalar ladders instead of arbitrary floats.
|
||||
The next honest static work is to keep promoting those fixed lanes into stable parser fields, explain the five remaining distinct auxiliary-stem cases, and decide how far the `.cgo` ladders and guarded `.lco` companion lanes can be grounded without overclaiming semantics.
|
||||
The early `.lco` lane block is now partially partitioned too: only offsets `0x20`, `0x34`, `0x38`, `0x3c`, `0x44`, `0x48`, and `0x54` behave like low-cardinality buckets, while the other early lanes still look high-variance.
|
||||
The next honest static work is to keep promoting those fixed lanes into stable parser fields, explain the five remaining distinct auxiliary-stem cases, and decide how far the `.cgo` ladders plus the low-cardinality `.lco` lanes can be grounded without overclaiming semantics.
|
||||
Preserved checked parser detail now lives in [EngineTypes parser semantics](rehost-queue/engine-types-parser-semantics-2026-04-21.md).
|
||||
Preserved checked format inventory detail now lives in [RT3 format inventory](rehost-queue/format-inventory-2026-04-21.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -30,6 +30,16 @@ first `.car` / `.lco` / `.cgo` / `.cct` inspector pass landed.
|
|||
- The checked 1.05 corpus (`66` `.lco` files) shows why the guard matters: long primary stems
|
||||
such as `AtlanticL` naturally spill across `0x0c`, so `0x0c` and `0x12` are not independent
|
||||
fixed fields unless the earlier slot is actually zero-padded.
|
||||
- The checked 1.05 corpus now also narrows the early `.lco` lane block into two categories:
|
||||
- low-cardinality lanes at `0x20`, `0x34`, `0x38`, `0x3c`, `0x44`, `0x48`, and `0x54`
|
||||
- high-variance lanes at `0x24`, `0x28`, `0x2c`, `0x30`, `0x40`, `0x4c`, and `0x50`
|
||||
- The low-cardinality side is now preserved directly in the inspector:
|
||||
- `0x20`: only `0x00000000` or `0x0000cdcd`
|
||||
- `0x34`: only `0x00000000 / 0x01000000 / 0x02000000 / 0x03000000`
|
||||
- `0x38`: only `0x02000000 .. 0x0a000000`
|
||||
- `0x3c` and `0x44`: always `0x00000000`
|
||||
- `0x48`: only ten values in the `0x003f8000 .. 0x00412000` range
|
||||
- `0x54`: only `0x00000000 .. 0x09000000`
|
||||
- `.cgo` looks structurally narrow right now: the checked 1.05 corpus has `37` files, all exactly
|
||||
`25` bytes long, each carrying one leading scalar lane plus an inline content stem at `0x04`.
|
||||
- The `.cgo` leading scalar is no longer just a loose raw count. The checked 1.05 corpus now
|
||||
|
|
@ -56,6 +66,7 @@ first `.car` / `.lco` / `.cgo` / `.cct` inspector pass landed.
|
|||
- conditional companion stem slot
|
||||
- conditional body-type label
|
||||
- early raw numeric lane block `0x20..0x54`
|
||||
- low-cardinality lane counts for the enumerated subset of that block
|
||||
- `.cgo`
|
||||
- leading scalar lane
|
||||
- content stem
|
||||
|
|
@ -73,8 +84,10 @@ first `.car` / `.lco` / `.cgo` / `.cct` inspector pass landed.
|
|||
- `.lco`
|
||||
- whether the guarded companion-stem slot is a tender/fallback display family, a foreign reuse
|
||||
key, or only a subset authoring convenience
|
||||
- how much of the early numeric lane block can be promoted from raw `u32/f32` views into stable
|
||||
typed semantics without dynamic evidence
|
||||
- whether the newly isolated low-cardinality lane subset can be promoted from raw `u32` buckets
|
||||
into named enums without overclaiming semantics
|
||||
- how much of the remaining high-variance lane subset can be promoted from raw `u32/f32` views
|
||||
into stable typed semantics without dynamic evidence
|
||||
- `.cgo`
|
||||
- whether the leading scalar ladders are enough to justify a named typed field, or whether they
|
||||
should stay conservative report-only ladders until more binary/code correlation exists
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue