Development Guidelines

EliteSoftwareTech Co. - EliteTaskbar Development Rules

1. Feature Preservation & Settings Toggles

During development, NEVER completely remove or obliterate an existing feature or implementation method, even if a superior one is being developed. Instead, you must:

1. Preserve the old code path.
2. Add a new checkbox/radio toggle in the UI (TaskbarProperties.cpp and resources.rc).
3. Add a registry key switch to dynamically flip between the legacy behavior and the new behavior at runtime.
4. Explain the limitation and options to the user.
5. Make the newly developed option the default when launched and change the existing registry setting if needed to achive this!

2. Mandatory Pre-Flight & Changelog Rules

CRITICAL ENFORCEMENT: You are absolutely FORBIDDEN from starting a task or making ANY code edits before you have completely read and reviewed every .md and .txt file in the project directory (including this one).

• Pre-Flight: Read all documentation files first.
• Action: Only after reading documentation, follow the user's explicit task directives.
• Post-Flight: After every single file edit, you MUST immediately update CHANGELOG.md to reflect exactly what was changed and why. Never skip this step.
• Feature Documentation: Every time a new feature or core capability is added to the project, you MUST update the comprehensive features list in README.md to include it, organizing it into the correct collapsible section.
• reference C:\Users\Administrator\Desktop\Elite-TaskBar\Documentation\BuildRequirements.md C:\Users\Administrator\Desktop\Elite-TaskBar\Documentation\PROJECT_SOURCE_MAP.md C:\Users\Administrator\Desktop\Elite-TaskBar\Documentation\SourceMap_And_Architecture.md C:\Users\Administrator\Desktop\Elite-TaskBar\Documentation\BuildGuide-FeatureRequirement_CheckList.md before each development process is started!
• Update Source Map as needed
• Add to development checklist for user requests then check off when finished!
• Also reference gemini.md before development to be sure user has not added any additional rules! or changed existing ones!

3. UI/UX Rules

• Flat design is absolutely forbidden.
• Native visual styles (EnableVisualStyles()) must always be utilized.
• UI elements must never rely on pure hard-coded colors; they must use system colors or rich 3D gradients.
• Always include an "i" or "Help" mechanism where applicable.
• All interactive controls MUST feature hover tooltips (when possible) or clear descriptive labels.

4. Git Hygiene

• Do not push massive binary objects to the repository unless strictly necessary. Ensure things like .pdf or compiler temporary objects are stripped or placed in .gitignore.
• Backups and outputs should be kept out of remote tracking where applicable, while signed binaries must be preserved.

5. Native Replication & Co-existence

• Native Replication: The taskbar replacement must be as native replicated as possible. It must interact with the system and other applications in the exact same manner the native Windows taskbar does, unless literally impossible.
• Co-existence: While achieving native behavior, it must seamlessly co-exist with, and preserve, all custom settings and additional features (things added in addition to the native things) without interfering with core operations.

6. Build Tool Execution

the entire build process for all exe files in the entire project and sub folders MUST BE MANAGED BY "C:\Users\Administrator\Desktop\Elite-TaskBar\build.ps1" chain and nothing else When executing build tools or scripts (e.g., build.ps1), you MUST run them normally within your current terminal so you can directly parse the output and track the build process accurately. Do NOT launch external windows for the build process.

7. Mirrored CPL and Settings EXE

Any change made to the UI, behavior, or underlying mechanics of the settings executable must always be perfectly mirrored and 100% identically implemented within the standalone CPL. They must never diverge in functionality or appearance.