Skip to content

Latest commit

 

History

History
46 lines (38 loc) · 2.81 KB

File metadata and controls

46 lines (38 loc) · 2.81 KB

File scope and lifecycle

REQ-FILE-001 — File scope and lifecycle

An invocation has one immutable baseline for each touched existing file. The first in PATH loads the regular UTF-8 contents visible at invocation start and makes that logical file active. Returning to the same logical file reuses that baseline and retains its pending edits. There are no generations and no command can materialize pending content as a new target baseline inside the script.

new PATH creates and activates a pending empty file. It fails if the logical path exists in the invocation workspace or pending state. Its immediately following nonblank command may be one targetless type VALUE initializer; any intervening command closes that initialization opportunity. The initializer is consumed even when its value is empty. No target-bearing mutation is valid on a new file because no invocation baseline exists for it. Further or dependent content changes require a successful invocation. A later invocation may use exact authored current text as an unanchored literal target; a fresh read is required only when exact current content is unknown or ambiguous.

mv PATH moves the active logical file to an unoccupied pending path. The destination becomes active; its original baseline and pending edits move with it. Later in resolves the new path, not the old one. Repeated moves collapse to one original-to-final move.

rm marks the active existing file deleted and clears the active file. Removing an existing file after any content mutation in the same invocation is an edit conflict; pending content is never silently discarded. Removing a moved, otherwise unedited file deletes its invocation-original path. Removing a file created in the same invocation cancels that creation, including an empty initializer.

in fails for missing or deleted paths. mv and rm fail without an active file. new and mv fail on destination collision. Parents of new and mv destinations must already exist. Hpatch does not create directories. All file and content changes remain in memory until the complete invocation crosses the apply or translation boundary.

Acceptance:

  1. A script can edit multiple files and return to an earlier path without shifting that file's targets or losing pending disjoint edits.
  2. A new file accepts at most one immediately following targetless initializer and does not expose introduced content as a same-script target.
  3. Moves preserve baseline identity and pending edits; repeated moves collapse to one net action.
  4. Removal after an existing-file content mutation, path collision, use after deletion, unsupported target-bearing new-file edits, and lifecycle commands without an active file reject before external mutation or patch output.
  5. Failure or cancellation after any number of commands exposes no intermediate change.