Skip to content

EXISTING PROJECT ​

Use the local Intentloom CLI; it makes no network calls.

Safety ​

Start with --dry-run, inspect intentloom diff, and resolve conflicts explicitly. Intentloom never modifies Applye or another project unless it is the explicit root.

Adoption stages ​

Run intentloom adopt --root PATH --dry-run --json first. Adoption scans bounded repository evidence, reports profile candidates, inventories instruction and documentation mappings, and returns a sorted proposal before any write. Each item states its current/proposed classification, reason, canonical source, adapter/profile, conflict details, write eligibility, manual-decision flag, and safe next action.

Existing files remain project-owned by default. A matching path, Intentloom-like header, identical generated bytes, familiar filename, or equivalent canonical document never establishes ownership. README and mapped product/engineering documents remain project-owned; duplicated documentation concepts require a manual choice.

Record that choice with a self-mapping in the reviewed command, for example --project-owned-mapping AGENTS.md=AGENTS.md or --documentation-mapping README.md=README.md. The mapping is written to the generated config only after the complete proposal is safe; it is not an implicit claim over the existing file.

Without --dry-run, the command is explicit acceptance of the currently safe proposal. Clean generated creates use the existing transaction and ownership metadata path. Any manual decision or unowned generated destination blocks all writes. Recoverable partial failure rolls back, and repeating a successful adoption is idempotent.

Profile evidence ​

Detection uses repository files rather than README prose: package.json, tsconfig.json, angular.json, Cargo.toml, and Tauri configuration. Results include evidence paths, deterministic reasons, competing candidates, and a manual-confirmation flag. Ambiguous unrelated TypeScript/Rust evidence falls back to generic; colocated Angular and Tauri evidence selects angular-tauri.

Nx is workspace topology, not a .aif/config.yaml engineering profile. An Nx workspace still resolves to a supported profile such as typescript, angular, or generic. Inspection reports workspaceTopology: nx when Nx evidence is present. Overlay signals such as SQLite or security-sensitive paths remain candidates and never become the selected adopt profile.

Root README.md is the public-readme document. Nested README files, package READMEs, fixture/example READMEs, RFCs, and documentation indexes do not compete for that concept. docs/README.md maps to documentation-index. Only canonical high-level architecture filenames such as ARCHITECTURE.md, architecture.md, ARCHITECTURE_MAP.md, and architecture-overview.md participate in the generic architecture concept. Specialized *_ARCHITECTURE.md files, ADR/process notes, security architecture, and RFC design documents stay project-owned and do not create architecture ambiguity. Same-concept duplicates still require an explicit mapping.

Scanning ignores .git, dependency/vendor directories, build and coverage output, generated caches including .nx/cache, .nx/workspace-data, and .nx/installation, binaries, and symlinked directories. Root nx.json and other non-generated .nx files remain visible. The scan is bounded to 32 levels and 10,000 relevant files inside the explicit root.