make /deft read-only

[visionik]

idea: stuff in /deft is templates / defaults.

put changed files elsewhere, such as ./config-deft

Thanks to Brent and Markus for this one.

[mhahn-sighthoundlabs]

Or maybe just .deft, as the dynamic portion of it, as with .git - though it will be part of a commit of latter.

[visionik]

what about:

1. .deft in the project directory for project and lower changes, and
2. .deft in your user directory for your USER.md changes?

[orlandobrent]

After sitting on this idea for a while, here's what I came up with. (Final formatting and polish by ChatGPT)

Goal: keep Deft core versioned/updatable without getting a dirty working tree from runtime outputs, while allowing project-specific overrides to live in the project repo.

Core (read-only, versioned separately)

• <projectPath>/.deft/core/
  • Contains the Deft repo files and is treated as read-only.
  • Recommended as a git submodule so the project can pin a specific Deft commit.
  • Note: the submodule pointer is committed to the project repo; we just don’t edit Deft files directly.

Cache / runtime output (mutable, NOT committed)

• <projectPath>/.deft/cache/
  • Any generated files, logs, resolved-context snapshots, indexes, etc. go here.
  • This folder is gitignored and should be the only place tooling writes inside .deft/.

Project overrides (editable, committed)

• <projectPath>/deft/
  • Contains project-owned override files (e.g. project.md, conventions.md, extra context files).
  • This folder is committed to the project repo so teammates get consistent behavior.
  • Overrides take precedence over files in .deft/core.

User-specific context (editable, NOT committed)

For user.md specifically, preferred location:

• ~/.deft/user.md
  • User-specific and not project-owned.

Optional “local override” pattern (dotenv-style):

• <projectPath>/deft/user.local.md
  • Any *.local.md files are gitignored (not committed), allowing per-developer/per-machine tweaks without affecting the repo.

Suggested precedence order

1. <projectPath>/deft/*.local.md
2. ~/.deft/user.md (and/or ~/.deft/*.md overrides)
3. <projectPath>/deft/*.md
4. <projectPath>/.deft/core/*.md (Deft defaults)

Guardrail

Tooling should refuse to write anywhere under <projectPath>/.deft/core/ (fail fast) to prevent accidental dirtiness.

[orlandobrent]

Ultimately, I feel this project will have an NPM and/or PIP package CLI (and that'll be a different Github Issue), but the Project Overrides and User-specific context from above should still work the same.