Crate slipcase_open 

The slipcase-open engine: everything the tool does that is not a user interface. Concept 8 keeps this free of any dependency on how the tool presents itself, so that the session model is one body of code on three platforms rather than three programs sharing a name, and so that every security-relevant decision — validation, policy, the launch path, the write-back — lives in one place and is testable without a desktop.

src/main.rs is the command line over it, which concept 9 keeps as the floor beneath the notifications and the tray.

Modules

content

The one content check, and everything it deliberately does not do. Concept 5.1 settles that policy keys on the extension, because that is what ShellExecuteEx, open and xdg-open resolve a handler from and none of them reads the bytes. Sniffing a content type and checking policy against it would be checking a value with no bearing on what executes.

endpoint

Where the front door is, and who is allowed through it. Concept 8: where no instance is running, the invocation starts one and hands over; where one is, it hands over and exits.

extension

What counts as a payload’s extension, and how it is compared against policy. Concept 5.1 puts policy on the extension rather than on a sniffed content type, because ShellExecuteEx, open and xdg-open all resolve a handler from the name and none of them reads the bytes. The extension is what decides what runs, so it is what policy has to be written against.

extract

Putting the payload where the target application can open it. Concept 5, steps 3 and 4: the payload is written into the session’s own payload/ directory (concept 6.4) and then carries whatever the platform records about where the container came from.

flow

Concept 5’s steps, joined into a session. Open and validate, decide, extract, mark, launch, watch, write back, close. Everything security-relevant that this tool does happens on the path through open, which is what concept 8 means by the engine being one body of code on three platforms.

i18n

What this tool says, in the language the desktop asks for.

identity

What makes two paths the same file. Concept 8 keys the live session table on file identity rather than on a path, and the reason is the case §7 already warns about: a container reachable under two hard links is two paths and one file. Canonicalising resolves symbolic links and does nothing about that, so a table keyed on the canonical path would open two sessions on one container, both repacking it, the second write-back overwriting the first with nothing said.

ipc

The front door: one instance, and every other invocation a client of it. Concept 8. Launching a document returns at once, so something has to outlive the launch to hold the watch, and a session list in the plural means a second invocation hands its container to the first rather than starting a rival with a list of its own.

outside

The three things the engine works against that are not its own state. Where policy is read from, what opens a payload, and how the person is spoken to. They travel together because they are chosen together — once, by main, from what the machine turns out to be — and because the engine passes all three down the same path: concept 10 puts the policy decision immediately before the launch, and concept 5.1’s warning is said about the same payload in the same breath.

platform

The parts that differ by platform, behind one small trait. Concept 12 structures the differences as a trait with three implementations rather than treating cross-platform as a yes-or-no decision. This is the launch half of it; the policy sources and the presentation join it in PLAN.md Phases 3 and 4.

policy

What the tool will open, and who gets to say. Concept 10. Four layers — machine policy, user policy, user configuration, built-in default — resolved into one answer, and one function that answers it for a payload.

present

What the tool says to the person using it, and how it asks. Concept 9. A notification carrying actions is the baseline and exists on all three platforms; the command line is the floor beneath it. This is the trait both sit behind, so the engine can narrate and ask without knowing which of the two is listening, and so the tray — an enhancement on the two platforms that have one — joins later without the engine noticing.

recover

What to do with a session that outlived the process holding it. Concept 6.3, amended 2026-09-03. Recovery writes back an edit whose container has not moved, and asks about everything else.

resident

The instance that holds the sessions, and the loop that serves it. Concept 8. One process holds every open session; every other invocation reaches it through the front door and exits.

session

Where a session lives on disk, and what it remembers. Concept 6.4. Not the system temporary directory, which is the obvious place and the wrong one: a reboot, a tmpfiles cleaner or Storage Sense may delete anything there, and doing so would destroy an edit the user has made and the tool has not yet written back — silently, in the window concept 6.3 exists to survive.

table

The live sessions, and how a container is matched against them. Concept 8: a container that already has a live session is not opened twice, because two sessions on one container would both repack it and the second write-back would overwrite the first with nothing said.

watch

Watching the payload directory, and what the events in it mean. The watch is on the directory and never on the file, which concept 6 calls one of the three things that make write-back detection hard. A serious editor saves by writing a temporary sibling and renaming it over the target, so a watcher registered on the payload loses its handle on the first save and never fires again. notify will watch a directory on all three platforms, but only if it is asked to.

writeback

Putting an edited payload back into the container. Concept 7. Repack to a temporary container beside the original and swap it over: never modify in place, because an interruption mid-write corrupts the only copy.