reverse-engineering-anything/docs/specs/desktop-app-environments/state-view/spec.md

Read a captured application's state

Outcome

rea inspect-desktop-application-state <capture-folder> turns a capture folder into the application's state: every retained or changed file with a role, a typed JSON view of each version and the kinds of change between versions. Export reads this to choose the seed and the data paths; task generation reads the kinds of change.

Requirements

• CLI only, like the capture. The folder's capture.json must be capture_desktop_application Evidence from provider rea-desktop v1 with a valid result, including its baseline non-file inventory; anything else is refused as invalid input. Captures from before that inventory was recorded must be made again.
• Retained bytes are read without following links and used only when their SHA-256 matches the name they are stored under.
• A path in a folder beside a state directory whose name differs from it only in letter case, such as GIMP's ~/.config/GIMP beside ~/.config/gimp, lies in that state directory.
• Each path gets the reasons the capture supports (state directory, open file, window title, selected path, dconf application keys, shared desktop location) and one role derived from them.
• Each version is the baseline or the file after a checkpoint that changed it. Formats: SQLite through REA's worker on a private copy with any retained -wal or -journal beside it (a hot journal is refused by the worker), refused when either existed but was not retained or the capture did not record whether it existed (unknown is never read as absent; absence holds only under content roots the baseline walked completely, with no truncation, unreadable directory or unchecked path, outside recorded exclusions). A later incomplete walk leaves a database or sidecar unconfirmed until an explicit change records it; a subsequent complete walk alone cannot recover a change the incomplete walk missed. Read SQLite only when the database and both sidecars are confirmed at that version; dconf through dconf dump / on a private file profile, keeping only groups whose path names the application; JSON up to 4 MiB and 500 levels with exact numbers; XML through the shared strict parser, a DOCTYPE read only when it has no internal subset and its DTD never read (XML text checks); key files up to 4 MiB whose every line parses; zip archives by their local file header, as their entries with each entry's own format and view (document views); text; binary. A gzip file, told by its magic bytes, is read as the document inside, its members joined, within a zip entry's 16 MiB and 100-times limits, and its version records compression: "gzip" beside that document's format; past the limits, or damaged, it has a view_error.
• Changes between versions are created, deleted, or lines, values, keys or rows with added, removed and changed lists (100 each, with counts); content for binary files and unreadable when a view is missing. Values are JSON pointers to every value, containers included, compared on one shared path so memory follows depth, and a pointer over 4096 characters is counted but not listed; keys are group/key with the key escaped as a JSON pointer segment, so distinct entries never share a name. Zip values name array members by selector where one names a member in both versions.
• The Evidence has operation inspect_desktop_application_state, predicate type rea.desktop-application-state and confidence inferred.

Non-goals

• No export, seed selection or task generation.
• No parsing of other binary formats (GVDB other than dconf, LevelDB, Realm, protobuf), or of compression other than gzip (xz, Zstandard, bzip2); they are listed as binary.
• No redaction: views contain the user's real data, as the capture does.