`C_EncodingUtil` is the one namespace in this family that is pure
algorithm, which is why it is built properly rather than stubbed: all
eight members, in the REAL formats. pfUI's profile sharing is the reader
and its own header names the pipeline — SerializeCBOR → CompressString
(zlib) → EncodeBase64, prefixed `!pf1!` — with the export path NOT inside
a pcall, so clicking Export raised, and the import path inside one, so it
failed silently.
A profile string is pasted between players, so a blob this client writes
has to be readable by the real one and the other way round. So: zlib
through flate2 (already the workspace's inflate for MPQ sectors and its
compressor for CMSG_AUTH_SESSION's addon block, so this adds a crate to
one more manifest and not to the build), RFC 4648 base64, RFC 8949 CBOR,
RFC 8259 JSON. Nothing invented here — the trap a hand-rolled codec falls
into is round-tripping with ITSELF while being wrong.
The decoders are written for hostile input, because a profile string
arrives pasted from a forum: every length is checked against what is
actually left, nesting is capped, the inflate output is capped at 16 MiB,
and a malformed blob answers nil rather than raising or allocating what a
crafted header asked for. Tests run the RFCs' own vectors in both
directions — including the half-float and tag forms we never write but a
real encoder may — a truncated/overlong/deep-nested set, and pfUI's whole
export/import pipeline end to end.
`C_EquipmentSet` and `C_LootHistory` are subsystems 1.12 does not have at
all, and both answer an honest nothing rather than being absent, because
pfUI builds both windows and reaches one member of each OUTSIDE its own
gate (the equipment manager's `CanUseEquipmentSets` test is one line in
one addon; the loot window's Clear button has no test at all).
What each would take is written down rather than guessed at. Equipment
sets are persistent state 1.12's wire has no concept of — a feature to
decide on, not a gap to close, and pfUI already supplies the UI. The loot
log is closer than it looks: both packets already carry what the getters
answer and `ui_loot_roll.rs` handles them, so it is a bounded list plus
three events — but the getters' tuple order is the one thing here that IS
a guess, read out of pfUI's own destructures, and building the log would
make that guess load-bearing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
The generated map shows each description, so the numbers pointed every
reader at records that are not in this repo. Only `description` changes;
every other key parses identical.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
One line per dependency where the reason is not obvious, measurements
kept as the number and the unit. Parsed with tomllib before and after,
every manifest is identical.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- a panic writes benilla-config/Diagnostics/crash-<time>.txt with the build id, the location, a backtrace and the last 200 log lines, and names the file as its last line, so a bug report can attach it (2266)
- every wire-count allocation hint is capped and the compressed update object reads through the cursor, so a malformed packet can no longer ask for gigabytes (2266)
- the 23 in-world run conditions are one set, the 45 probe variables one registry, the install-gated tests say when they skip, and every gate is timed (2266)
- one workspace-level lint allowance replaces 413 per-site attributes, and the decision corpus gets a lint in the gate (2266)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
gromandClaude Opus 5