Seperation of context and permissions

[ddevz]

Issue

TLDR; we are missing ways to express things like "the contents of this file is not added to the context by default, but you can add chunks of this file to the context without asking for permission" (without giving permission to everything which can distract it)

I've been thinking. It seems like for any file there are multiple AI statuses, which I'll group into "context" and "permissions".

Permissions:

• permission for the AI to know about the existence of the file (I.E. it is in the git directory listing and thus the filename itself is included into the context)
• permission for the AI to read the contents of the file (which would include permission to do things like a "search with line number and add the result to the context")
• permissions for the AI to write to the file

permissions seem to come in 3 variants, Allow/Deny/and "ask me and i'll think about it"

Context:

• Add the filename to the context
• Add the filename and a summary of the file
• Add the entire file to the context

Now in cecli:

• filenames and some file summaries are handled by files being registered in git which seems fine for the most part.
• The important one that seems to be missing is: "the file is not added to the context by default, but if the AI feels the contents of this file might be relevant, the AI is automatically authorized to run the 'search file for string and add the results to the context' or even add the entire file to the context."
• --yes-always and --yes-always-commands are for giving permission to everything (and --yes-always-commands does not seem to actually work)

Examples:

A program that will be written as a client and a server

some example directories:
program1/client/src/
program1/client/tests/
program1/server/src/
program1/server/tests/

Some desirables:

• One would want to be able to say things like "you may never modify the server code when you are working on the client"
• Stay out of program1/client/src/idea-that-didnt-work/* because things under that directory will just dilute your context and distract you from a actual solution.
• It's ok to look at program1/server/src/api.py when working on the client
• When fixing a failing test, you are not allowed to edit the test without asking (and giving a explanation as to why it should be allowed)

Thoughts?

Version and model info

No response

[dwash96]

So this gets rather in the weeds of discrete file permissioning and granular read/write access. I'm not strictly opposed, but it it is a rather extensive set of modifications to the system and a user configuration complexity challenge to specifically split out files into readable and writeable sets (especially if updating those bindings needs to be done during run time). The current .cecli.ignore file stuff can handle the "stay out of path " as an idea.

A lot of this also comes down to using tools like docker, bubblewrap, or firejail to define these types of sandbox permissions