My development approach
Today, as part of the development of CrowFORGE V1.1, I completed a series of improvements that directly affect everyday software development. I focused my work on file and memory management, Python environments, protecting source code, Git operations, and learning to use the application. I combined the improvements in the first release candidate with RC2 fixes for problems we identified during use. My aim is to provide a development environment where users can create projects through clearer steps, understand the cause of a problem they encounter, and track the changes they make.
I base CrowFORGE's product direction and development priorities on real usage experience. I carry out technical implementation, code review, and validation with support from Codex. Working with the existing React and TypeScript interface, Electron desktop layer, and CodeMirror editor infrastructure, I assess the entire flow, from how a feature appears in the interface to the result it produces in the file system. A substantial part of today's updates involved making behavior consistent across these layers.
File and memory management
In file management, I first corrected the old limits of 1 MB per file and 5 MB of total content that some opening operations were still using. I connected local file operations to a shared limit definition: in RC2, an editable text file is supported up to 20 MB, and the total text loaded into memory across all projects in the application is supported up to 100 MB, measured in UTF-8 bytes. This total does not refer to the space the project folder occupies on disk. When a folder is opened, the file catalog appears first; contents are read when the user selects the relevant file. The existing catalog capacity remains 20,000 files per project, and the open workspace capacity remains 30 projects.
To manage memory use, I added a mechanism that removes the contents of clean, closed local files from memory when necessary. Unsaved edits, on-device drafts, open tabs, and documents used in the second editor are protected. The behavior when selecting multiple files—opening the first file and keeping the others in the file tree—was also brought into line with this flow. I ensured that the total text budget is taken into account during concurrent reads, when retrieving content from history, and when importing a backup. This removed conflicting limit checks from different parts of the application.
I also developed a lightweight editor mode for large documents. When a document exceeds two million UTF-16 units, the minimap, line wrapping, language parsing, and language server operations are paused; editing, searching, and saving remain available. Personal settings are reapplied when switching to a smaller document. During normal editing, we update the document size based on the changed text instead of recalculating it from scratch on every keystroke. Caching checks for unsaved changes and briefly pausing the Matrix and brand animations while typing are among the other improvements I made to reduce unnecessary load in the workspace.
Protecting and recovering code
One file-system issue I paid particular attention to was protecting content changed outside the application. We identified a situation where a file read during a refresh could change the baseline used for save comparisons before the editor had accepted that content. I fixed this by separating reading and acceptance into two stages. The content is read first; the comparison baseline is updated once the editor has adopted it and the disk state is still appropriate. We verified this behavior with separate tests to ensure that a read rejected because of its size, or a response left unused because of a concurrent edit, cannot allow an external change to be overwritten during a later save.
The local work recovery and file history I added in V1.1 continue this approach. Open work is regularly saved to the application's data area, and shutdown waits for the final recovery operation to complete. Record integrity is checked, and if the latest record cannot be read, the previous intact record is considered. File history retains the previous version of content that has been changed and saved. Users can compare versions side by side; restored content first appears in the editor, and the file on disk does not change until the Save command is issued. Limits on the number and total size of history records prevent uncontrolled disk consumption.
I also brought work backups into line with the new file limits. Project contents are read in sequence, integrity is verified, and compatibility with older JSON backups is retained. Imported projects open with new identifiers as separate on-device drafts; existing projects are not overwritten. This mechanism is intended to protect text-based work. I explicitly stated in the training and release notes that the project folder, including images, models, and other binary assets, must be backed up separately.
Python environments and libraries
One of the most extensive Python additions was Project Doctor. I added a flow that checks the selected interpreter, virtual environment, and supported dependency declarations in requirements.txt and pyproject.toml. Users can see missing or incompatible components and review the environment in which a proposed operation will be applied. Once an operation is approved, the report, environment, and relevant project declarations are checked again to ensure they have not changed. The project application or build script is not run during the check; dynamic and unsupported dependency definitions are identified in the report.
In RC2, I also strengthened Python discovery. The Windows launcher, PATH entries, standard installation locations, and a manually selected interpreter are evaluated more consistently. In particular, I fixed the bug that caused a manually selected Python interpreter not to be used when creating a virtual environment. Missing Python, venv, ensurepip, and pip components are now shown separately. Users can select an interpreter, recheck the environment, create a project virtual environment, and repair pip in a suitable environment. If Python is not installed on the computer, a link to the official installation page is offered, and the check can be run again after installation.
I also connected the Libraries screen to this environment management. The target project and Python path are now visible, and package search results are distinguished from the status of installed packages. PyPI was selected as the default repository, and I fixed installation buttons misleadingly appearing enabled when the required prerequisites were not met. Installation of offline examples into the selected environment and reporting of the results were verified. For C# packages, the .NET SDK requirement was clarified; for C++, the steps between adding a source package to a project and being able to compile it were clarified. Selected example libraries come with the application; other packages are installed from the relevant repositories as needed. Python, the .NET SDK, and a C++ compiler must be available separately in the operating system.
Your first project and practical training
To reduce the uncertainty a new user faces in their first project, I prepared a four-step project wizard. Users first choose a language and project name, then select a location, check the working environment, and move on to the first-use steps. Python is the primary focus, with JavaScript, TypeScript, Web, C#, and C++ options also available. The distinction between a project folder on the computer and an on-device draft is shown. Missing tools can be configured later; creating a project does not automatically run code or install packages.
I supported this wizard with a training center that covers the entire application. Accessible through F1 or the Help menu, the training is available in Turkish and English and includes 11 sections, 37 practical steps, and a 5-question assessment. The file tree, tabs, editor, search, Python environments, packages, terminal, tests, debugging, C#/C++ tools, Git, history, backups, and personalization are covered in the same learning flow. Each step includes the action to take, the expected result, and what to check if a problem occurs. The final section includes a small Python application, a test, and a requests exercise. Progress is stored on the device through checklists marked by the user. I also prepared HTML and Markdown guides containing the same material that can be read independently of the application. The HTML guides can be read without an internet connection; links to official external resources require internet access.
Git and everyday workflow
For tracking source code, I improved Git comparison. Changes in working files, changes staged for a commit, and conflicts can be examined more clearly. Previous and subsequent content is compared at the line level, and individual files can be staged and unstaged. In conflicts, inspecting the common base, current side, and incoming side helps users make their decision. The Ctrl+Shift+O structure search I added for navigating long files also makes it possible to jump to the relevant location using function and class names. This feature uses a suitable language server or a supported local syntax structure.
For day-to-day work, I added beginner and advanced view options, searchable settings, and selectable keyboard shortcuts for certain commands. Preferences for the file panel, bottom panel, split view, and run profile are remembered per project. When restarting a run, the application first waits for the current task to exit. When the Python environment changes, users are informed that an open terminal may still be using the old environment and are offered the option to open a new terminal. Known environment, compiler, and access errors direct users to the relevant check. I extended Turkish and English support to the new panels and simplified the interface by hiding unconfigured account and AI entries in the main workspace. I also fixed the status bar so that when switching documents, it shows the new file's actual cursor position.
I built these improvements on the existing five themes, crystal logo, minimap, split editor, and preview tabs. These were core features of the previous version; today's work complemented that foundation with a more consistent and understandable flow of use. My decision to offer CrowFORGE free of charge remains in place. No account or subscription is required to use the local development tools.
Validation and next steps
For validation, 26 test groups were completed successfully, including the final installation checks. 11 interface checks passed in a real Electron window on Linux x64; one of these checks tested the missing-Python condition using controlled sample data. File reading and saving, preservation of large edits after reopening, the project wizard, creation of a real virtual environment, offline package installation, and training progress were evaluated. Windows x64 and ARM64 Setup files and Linux x64 and ARM64 archives were prepared. Package contents, processor architectures, Windows icon and metadata fields, compiled KVKK pages, archive integrity, and SHA256 values were checked. I also removed an unnecessary temporary file found during package inspection and rebuilt the Windows x64 installer with clean output.
I prepared the current release as 1.1.0-rc.2. Actual installation and Defender acceptance tests on Windows, along with execution validation on ARM64 hardware, have not yet been completed; the code-signing certificate is also pending. External debugger connections for C# and C++ remain experimental. I have not enabled account, cloud, AI, or automatic update services in this release. Existing users can update using the appropriate Setup file after saving and backing up their work and closing the application. I will also set my next development priorities according to the results of use in real projects: understanding the working environment, protecting code, and making the next step clear to the user will remain central to my work on CrowFORGE.