GENERATED FILES

Intentloom commands are local and deterministic. A generated header is not ownership proof: only a valid .aif/source-map.json record with normalized relative path and matching checksum establishes aif-owned-generated status. Generated destinations are written before the lock and source map; metadata finalizes only after destination writes succeed. A recoverable failure restores prior files and removes newly created files.

The manifest lock and source map declare schema version 1, framework version, adapter-output version, local metadata-format version, adapter and canonical source identifiers, checksums, and ownership metadata. Their strict schemas are validated before ownership or transaction logic. Generated next-state metadata is also validated before any write. Absolute-looking and malformed path strings fail structurally; actual root escape and symlink safety remain semantic.

The manifest also pins the resolved profile, selected adapter ids and versions, schema-family versions, and SHA-256 hashes of every canonical catalog source used by generated outputs. These pins are deterministic and contain no timestamps. They do not replace re-reading actual generated bytes during doctor or post-write validation.

The CLI derives canonical source hashes from catalog file bytes. A programmatic caller that injects an in-memory catalog must supply the corresponding content hash evidence; Intentloom rejects the plan rather than hashing a source identifier or emitting a misleading pin. Adapter pins use the version exported by the adapter module, so generation and lock metadata have one version authority.

Before a write plan is accepted, Intentloom evaluates a portable normalized collision key (POSIX separators, NFC Unicode normalization, and case-folding) and resolves existing destination parents against the project root. This mitigates link escapes but cannot eliminate a filesystem TOCTOU race between validation and replacement.

The collision sequence rejects absolute/null-byte input, converts separators, normalizes dot segments, rejects root escape, removes redundant ./, applies NFC, then locale-independent lowercase comparison. This is deterministic but is not a complete Unicode case-folding implementation.

The v0.1 policy rejects every symlink component, including links whose current target is inside the project. Paths are revalidated immediately before each replacement; this narrows but cannot eliminate TOCTOU races.

Normalized collisions are reported with a stable destination-collision code, collision key, sorted original paths, and sorted canonical/adapter source identifiers. No colliding output is selected based on input order.

Collision rejection is side-effect free: existing generated bytes, manifest, source map, and legitimate pre-existing staging/backup contents remain unchanged; absent metadata remains absent.

Programmatic transaction results expose stable generated/manifest/source-map stage identifiers, rollback status, and project-relative rollback failures. After generated destinations, the manifest, and the source map are finalized, the post-write validator re-reads their actual filesystem bytes. It validates paths, normalized uniqueness, ownership, adapter and canonical-source identity, framework/adapter/metadata versions, all checksum relationships, and exact agreement with the planned finalized bytes before success can be returned.

A valid post-write result reports checked generated, manifest-entry, and source-map-entry counts plus successful checksum, ownership, path, version, and metadata-byte validation. An invalid result reports one stable corruption code, project-relative affected paths, and safe identifiers. It never includes generated contents, metadata contents, or external absolute paths.

Stable post-write corruption codes are grouped as follows:

• JSON: manifest-json-malformed, source-map-json-malformed.
• Relationships: manifest-entry-missing, source-map-entry-missing, manifest-destination-missing, source-map-destination-missing, generated-file-without-ownership, ownership-record-without-generated-file.
• Checksums and bytes: generated-checksum-mismatch, manifest-source-map-checksum-mismatch, manifest-generated-checksum-mismatch, committed-generated-bytes-mismatch, committed-manifest-bytes-mismatch, committed-source-map-bytes-mismatch.
• Paths and duplicates: manifest-absolute-path, source-map-absolute-path, manifest-path-escape, source-map-path-escape, manifest-duplicate-destination, source-map-duplicate-ownership, normalized-destination-duplicate.
• Identity and versions: ownership-classification-invalid, adapter-id-missing, adapter-id-mismatch, canonical-source-id-missing, canonical-source-id-mismatch, framework-version-missing, framework-version-incompatible, adapter-output-version-missing, adapter-output-version-incompatible, metadata-format-version-incompatible.

Every invalid post-write result fails at post-write-consistency and enters the normal transaction rollback path. Existing generated and metadata bytes are restored, newly created destinations are removed, unrelated files remain unchanged, and success is never reported. The deterministic corruption callback is dependency-injected only through the programmatic transaction test seam after finalization; normal configuration and CLI commands cannot enable it.

An incomplete rollback adds the stable transaction-rollback-incomplete diagnostic without replacing the original transaction failure. Manual inspection is required for the listed project-relative paths.

The real intentloom sync path now executes this transaction and maps its result directly to CLI output and exit codes. Transaction summaries expose sorted created, updated, and unchanged generated paths; manifest/source-map update flags; consistency status; and cleanup status. A pre-write ownership, collision, or path-security conflict does not enter the transaction and exits with code 3.

Adoption uses this same transaction path only after a proposal has no manual decisions. Existing mapped instructions and documentation do not receive source-map records. A generated-looking header or byte-identical candidate without a valid ownership record remains project-owned and blocks replacement. Doctor separately reports missing records/files, orphaned records, checksum and version drift, missing supported headers, and headers without ownership proof; it never repairs them.