YSFOML (Yasir Sultan File Operations Markup Language) is a powerful and intuitive markup language designed to streamline and automate file system operations. It provides a structured and human-readable way to define a series of file-related tasks, making complex operations simple and repeatable. YSFOML aims to bridge the gap between human intent and automated file management, offering a robust framework for various development and maintenance workflows.
One of the primary motivations behind the creation and continuous development of YSFOML is to empower programmers in their development process through the strategic use of Artificial Intelligence. YSFOML is meticulously designed to facilitate AI interaction with file systems, while simultaneously upholding the highest levels of security through its inherent 'human-in-the-loop' model. This crucial design choice ensures that AI models can leverage YSFOML for powerful automation without the risk of accessing sensitive data or executing malicious behaviors, thereby providing a secure and controlled environment for AI-driven development.
It is important to clarify that while the MCP protocol and YSFOML are distinct entities. please check section (YSFOML future aspects)
YSFOML operations are defined within <YSFOML>
and </YSFOML>
tags. Each
block represents a single file system operation.
Syntax:
<YSFOML>
action: [action_name];
[parameter1]:[value1];
[parameter2]:[value2]
...
</YSFOML>
[Optional Content associated with the action]
<YSFOML>
and </YSFOML>
: These tags delimit an
YSFOML instruction block.key:value;
pairs, with each instruction typically ending with a semicolon. The action
key is mandatory
and specifies the operation to be performed.</YSFOML>
closing tag
(until the next <YSFOML>
tag or end of document) is considered the "content"
associated with that specific YSFOML block. This content is used by certain actions (e.g.,
create
, append
, insertAt
).
Parameters are key-value pairs within the YSFOML block that provide specific details for the action.
General Syntax: parameter_name:parameter_value;
parameter_name
: The name of the parameter (e.g., filename
,
foldername
, searchString
).
parameter_value
: The value for the parameter. This can be a file path,
folder name, string, URL, line number, column number, etc.;
): Each parameter definition should end with a semicolon.All file system operations performed by the YSFOML parser are relative to a designated "base folder"
(referred to as project_folder_name
in the provided Python parser). If a file or folder path is
specified without a leading slash (e.g., file1.txt
,
my_new_folder/nested_file.txt
), it is assumed to be relative to this base folder.
YSFOML operations are categorized by security levels to indicate the potential impact on the file system. The YSFOML parser application may use these levels to enforce permissions or require higher user confirmation for more impactful operations.
low
: Read-only operations that inspect the file system without making changes (e.g.,
listing files, searching content).medium
: Operations that create, modify, or move files/folders without permanent deletion
(e.g., creating files, appending content, renaming). These operations often include backup mechanisms.
high
: Operations that permanently delete files or folders. These are considered highly
destructive and irreversible.extremelyHigh
: (Future/Reserved) Operations that could involve arbitrary code execution or
significant system-wide changes. Currently, no YSFOML actions support this level, and external scripting
is explicitly not supported.actionSource: userAdded
) ↑ TopWhile YSFOML provides a comprehensive set of built-in actions, future versions may allow for the definition
of new, custom actions. If you are defining a new action that is not part of the standard YSFOML
specification, you *must* include the actionSource: userAdded;
parameter within the YSFOML
block. This parameter signals to the parser that the action is a custom, user-defined one. Current YSFOML
processors may log these actions as unsupported, but this mechanism is in place for future extensibility.
Example for a hypothetical user-added action:
<YSFOML>
action:myCustomAction;
actionSource:userAdded;
param1:value1;
param2:value2
</YSFOML>
This is content for my custom action.
#ffd8e6
(Pink)
#add8e6
(Light Blue)
#e0f2f7
(Very Light Blue)
#ffff99
(Light Yellow)
#90ee90
(Light Green)
#ffcc99
(Light Orange)
action:create
↑ Top
filename
: (Required, String) The path and name of the file to create, relative to
the base folder.medium
<YSFOML>
action:create;
filename:file1.txt
</YSFOML>
hey,
this is the first file1
by Yasir Sultan
action:append
↑ Top
filename
: (Required, String) The path and name of the file to append to, relative
to the base folder.medium
<YSFOML>
action:append;
filename:file2.txt
</YSFOML>
hey,
this is the second file
developed by Yasir Sultan
-- Appended content --
action:delete
↑ Top
filename
: (Required, String) The path and name of the file to delete, relative to
the base folder.high
<YSFOML>
action:delete;
filename:renamed_file1.txt
</YSFOML>
action:createFolder
↑ Topfoldername
: (Required, String) The path and name of the folder to create, relative
to the base folder.medium
<YSFOML>
action:createFolder;
foldername:my_new_folder
</YSFOML>
action:deleteFolder
↑ Topfoldername
: (Required, String) The path and name of the folder to delete,
relative to the base folder.high
<YSFOML>
action:deleteFolder;
foldername:my_new_folder
</YSFOML>
action:rename
↑
Topfilename
: (Required, String) The current path and name of the file to rename,
relative to the base folder.filename2
: (Required, String) The new path and name for the file, relative to
the base folder.medium
action:move
.
<YSFOML>
action:rename;
filename:file1.txt;
filename2:renamed_file1.txt
</YSFOML>
action:move
↑ Top
filepath1
: (Required, String) The current path and name of the file to move,
relative to the base folder.filepath2
: (Required, String) The destination path and new name for the file,
relative to the base folder.medium
<YSFOML>
action:move;
filepath1:file2.txt;
filepath2:my_new_folder/moved_file2.txt
</YSFOML>
action:treeFolders
↑ Topfoldername
: (Optional, String) The folder from which to start the tree
display, relative to the base folder. If omitted, the base folder itself is used.low
<YSFOML>
action:treeFolders;
foldername:my_new_folder
</YSFOML>
action:treeFiles
↑ Topfoldername
: (Optional, String) The folder from which to start the tree
display, relative to the base folder. If omitted, the base folder itself is used.low
<YSFOML>
action:treeFiles;
foldername:
</YSFOML>
action:findFile
↑ Topfilename
: (Required, String) The name of the file to search for.foldername
: (Optional, String) The folder to start the search from,
relative to the base folder. If omitted, the base folder itself is used.low
<YSFOML>
action:findFile;
filename:renamed_file1.txt;
foldername:
</YSFOML>
action:findInFile
↑ Topfilename
: (Required, String) The path and name of the file to search
within, relative to the base folder.searchString
: (Required, String) The string to search for.low
searchString
to the "Operation Results" panel.
<YSFOML>
action:findInFile;
filename:daily_report.txt;
searchString:sales
</YSFOML>
action:replaceInFile
↑ TopsearchString
with a
newString
within a specified file.
filename
: (Required, String) The path and name of the file to
modify, relative to the base folder.searchString
: (Required, String) The string to find and replace.
newString
: (Required, String) The string to replace
searchString
with. Can be an empty string to delete occurrences.
medium
searchString
is not found, no changes are made to the file, and
a message is logged.<YSFOML>
action:replaceInFile;
filename:daily_report.txt;
searchString:$;
newString:USD
</YSFOML>
action:readFileAll
↑ Topfilename
: (Required, String) The path and name of the file to read,
relative to the base folder.low
<YSFOML>
action:readFileAll;
filename:daily_report.txt
</YSFOML>
action:readFileLines
↑ Topfilename
: (Required, String) The path and name of the file to
read, relative to the base folder.startLine
: (Optional, Integer) The starting line number
(1-indexed). Defaults to 1.endLine
: (Optional, Integer) The ending line number
(1-indexed). Defaults to the last line of the file if omitted or set to -1.
low
startLine
is out of bounds, an error is logged.<YSFOML>
action:readFileLines;
filename:daily_report.txt;
startLine:2;
endLine:3
</YSFOML>
action:insertAt
↑ Topfilename
: (Required, String) The path and name of the file to
modify, relative to the base folder.lineNum
: (Required, Integer) The 1-indexed line number where
the text should be inserted.colNum
: (Required, Integer) The 1-indexed column number within
the specified line where the text should be inserted.medium
lineNum
is out of bounds, an error is logged.colNum
is greater than the length of the line, the text
is appended to the end of that line.<YSFOML>
action:insertAt;
filename:daily_report.txt;
lineNum:1;
colNum:1
</YSFOML>
--- START OF REPORT ---
action:treeFoldersJSON
↑ Top
foldername
: (Optional, String) The folder from which to
start the tree generation, relative to the base folder. If omitted,
the base folder itself is used.low
<YSFOML>
action:treeFoldersJSON;
foldername:my_new_folder
</YSFOML>
action:treeFilesJSON
↑ Top
foldername
: (Optional, String) The folder from which to
start the tree generation, relative to the base folder. If omitted,
the base folder itself is used.low
<YSFOML>
action:treeFilesJSON;
foldername:
</YSFOML>
Looking to the future, a significant advancement planned for the YSFOML ecosystem involves the integration of the Multi-Client Protocol (MCP) directly within the YSFOML parser application. This strategic integration will largely eliminate the current need for manual copy-pasting of YSFOML code into the parser, although this option will remain available for flexibility. Instead, developers will be able to receive and review YSFOML code directly within a rich GUI environment, facilitating a more seamless and efficient workflow where their primary role shifts to critical review and approval.
It is important to clarify that while the MCP protocol and YSFOML are distinct entities--YSFOML defining file operations and MCP facilitating communication and interaction--their integration is designed to create a profoundly secure and exceptionally user-friendly development workspace. This synergy will combine YSFOML's precise control over file operations with MCP's robust communication capabilities, resulting in an environment where AI-driven file management is both powerful and inherently safe.
Further enhancing YSFOML's utility and flexibility, future iterations are planned to incorporate the crucial concepts of variables and conditional logic. These additions will enable more dynamic and intelligent file operation sequences, allowing YSFOML to adapt to varying contexts and execute operations based on specific criteria.
To address the critical need for running scripts and compiling code in a strict secured way, YSFOML will introduce new actions and security protocols designed to integrate these powerful capabilities without compromising the system's integrity. This will involve:
executeScript
and compileCode
,
will be introduced. These actions will be classified under the
extremelyHigh
security level, mandating explicit human review
and approval via the rich GUI provided by the MCP integration. Parameters
for these actions will include the script/source file path,
interpreter/compiler executable, arguments, and options for capturing output
(stdout/stderr).
executeScript
or compileCode
actions.
This display will highlight the exact command to be executed, its
parameters, and any potential security implications, ensuring the human
operator has all necessary information for a fully informed approval or
rejection.findFile
or readFileAll
to verify the content or
digital signature of a script before executeScript
is allowed
to proceed, or compileCode
could be conditional on the
successful outcome of a prior security scan. This allows for highly
sophisticated, self-regulating security protocols defined directly within
YSFOML.
By meticulously designing these new capabilities with security as the paramount concern, YSFOML will empower AI models to automate complex development tasks, including building and testing, while maintaining the essential human oversight that guarantees safety and control.
YSFOML is designed with Artificial Intelligence (AI) interaction in mind, serving as a structured and human-readable language for AI models to specify file system operations. This allows AI to communicate desired file manipulations in a clear, auditable format.
A core principle of YSFOML's design, especially when used with AI, is the "human-in-the-loop" security model. AI models can generate YSFOML instructions based on user requests (e.g., "Please create a Python script and save it as 'hello.py'"). However, the execution of these instructions is intentionally manual: the AI provides the YSFOML text, and the user must then copy and paste this text into the YSFOML Parser application. This manual step acts as a critical security layer, preventing direct, unsupervised AI access to your local file system.
By generating YSFOML instructions, AI can help users understand, create, and edit code, manage project files, or perform other file-related tasks. This approach empowers users with AI assistance while maintaining ultimate control and oversight over their file system.
It is crucial to understand that the execution of any YSFOML instructions,
whether generated by an AI or written manually, is entirely at the user's own
risk. Users are strongly advised to always review the generated YSFOML content
carefully before processing it with the YSFOML Parser, especially for actions
with medium
or high
security levels that can modify or
delete files.
For an AI to effectively assist with file system operations, especially in
complex projects, it's essential for the AI to first gain an understanding of
the project's structure and existing content. The
action:treeFoldersJSON
and action:treeFilesJSON
actions are specifically designed for this purpose.
action:treeFoldersJSON
(for a high-level folder structure) or
action:treeFilesJSON
(for a detailed view including all files).
This provides the AI with a structured, machine-readable map of the project.
action:readFileAll
or action:readFileLines
to read
their content and understand their purpose or identify areas for
modification.
action:create
, action:append
,
action:replaceInFile
, or action:insertAt
to make
the desired changes. This iterative process of "read-then-write" ensures
that AI-generated modifications are contextually aware and accurate.
This structured approach allows the AI to provide more intelligent and targeted assistance, while the human-in-the-loop model ensures safety and oversight.
YSFOML offers several powerful and secure ways for Artificial Intelligence (AI) to interact with file systems:
In summary, YSFOML serves as a structured, human-readable interface that allows AI to understand, query, and propose modifications to file systems, while ensuring a critical human review step for security and control.
An AI is asked to create a new Python script for a simple "Hello World" program.
<YSFOML>
action:create;
filename:hello_world.py
</YSFOML>
print("Hello, YSFOML World!")
An AI needs to add a new log entry to an existing
application.log
file.
<YSFOML>
action:append;
filename:application.log
</YSFOML>
[2025-06-28 15:30:00] INFO: User 'admin' logged in successfully.
An AI identifies a placeholder in a configuration file and needs to replace it with an actual value.
<YSFOML>
action:replaceInFile;
filename:config.ini;
searchString:DB_PASSWORD=YOUR_PASSWORD;
newString:DB_PASSWORD=secure_ai_pass123;
</YSFOML>
An AI needs to add a new function definition at the beginning of a Python script.
<YSFOML>
action:insertAt;
filename:my_utility.py;
lineNum:1;
colNum:1
</YSFOML>
def calculate_sum(a, b):
return a + b
An AI needs a high-level overview of the project's directories to understand its organization.
<YSFOML>
action:treeFoldersJSON;
foldername:src/components;
</YSFOML>
An AI needs a detailed map of all files and folders within a specific directory to plan modifications.
<YSFOML>
action:treeFilesJSON;
foldername:public/assets;
</YSFOML>
An AI needs to analyze the content of a specific source code file.
<YSFOML>
action:readFileAll;
filename:src/main.js
</YSFOML>
An AI is looking for all occurrences of a specific variable name
(user_id
) in a database script.
<YSFOML>
action:findInFile;
filename:database/schema.sql;
searchString:user_id;
</YSFOML>
An AI needs to locate all instances of config.json
across the
project.
<YSFOML>
action:findFile;
filename:config.json;
foldername:;
</YSFOML>
This scenario is represented by the overall workflow and the use of security
levels. An AI would generate one of the YSFOML blocks, and a human
user would then review it before feeding it into the YSFOML Parser
application. For instance, a deleteFolder
instruction has a
high
security level, requiring careful human review.
<YSFOML>
action:deleteFolder;
foldername:old_backup_data;
</YSFOML>
The provided Python script YSFOML_GUI
acts as a parser and executor
for YSFOML documents.
tkinter
(usually included with Python)requests
library (pip install requests
)action:json
with jsonPath
, a JSONPath library
might be required (e.g., pip install jsonpath-ng
)..py
file (e.g.,
ysfoml_parser.py
).
python ysfoml_parser.py
The GUI provides the following main components:
YSFOML_output
folder in the current
working directory.treeFolders
, findFile
,
readFileAll
, etc.
The parser automatically saves three log files for each processing run within
a logs
subfolder inside your chosen project folder:
input_[timestamp].txt
: A copy of the YSFOML content that
was processed.processing_log_[timestamp].txt
: The full content of the
"Processing Logs" panel.results_log_[timestamp].txt
: The full content of the
"Operation Results" panel.key:value;
pairs might lead to
parameters not being correctly parsed, resulting in "Warning: No 'key'
found" messages.</YSFOML>
tags will result in
warnings and incomplete parsing.tkinter.messagebox
will appear.
create
, append
,
replaceInFile
, and action:json
(write mode)
operations, the parser creates a timestamped backup of the original file
before modification. This is a crucial safety feature to prevent
accidental data loss. Backups are stored in the same directory as the
original file.
delete
or
deleteFolder
.
</YSFOML>
tag.os.path.join
is used for path construction, complex path
manipulations or platform-specific characters might behave unexpectedly.
YSFOML (Yasir Sultan File Operations Markup Language) and the YSFOML Processor application are currently under development. They are provided "as is" without warranty of any kind, either express or implied. Use at your own risk. The developer is not responsible for any data loss or other damages incurred from the use of this software.