[docs, cursor rules] Docs have been actualized, cursor rules - added

.cursor/rules/architecture.mdc

@@ -0,0 +1,34 @@
+---
+description: Keep architecture docs in sync with structural changes
+globs:
+  - "pkg/**/*.go"
+  - "internal/**/*.go"
+  - "tests/**/*.go"
+alwaysApply: true
+---
+
+# Architecture Documentation
+
+When making architectural changes, update `docs/ARCHITECTURE.md` to keep it in sync.
+
+## What counts as an architectural change
+
+- Adding, removing, or renaming a package (directory under `pkg/`, `internal/`, or `tests/`)
+- Adding or removing a file in the package tree shown in Section 1.1
+- Changing the layer a component belongs to (e.g. moving code from `internal/` to `pkg/`)
+- Adding a new cluster creation mode or major workflow
+- Changing core interfaces or types (e.g. `TestClusterResources`, `ClusterDefinition`)
+
+## What to update
+
+1. **Section 1.1 (Package Structure)** — the directory tree listing.
+2. **Section 3.x (Module Details)** — the file listing and description for the affected module.
+3. **Section 3.6 (Public API)** — the `pkg/` tree if public packages changed.
+4. **Section 7 (Environment Variables)** — if new env vars were introduced.
+5. **Section 9 (Future Improvements)** — mark items as done or add new ones.
+
+## Rules
+
+- Only update sections that are directly affected by the change.
+- Keep descriptions concise and factual.
+- Do not rewrite unrelated sections.

.cursor/rules/backward-compatibility.mdc

@@ -0,0 +1,24 @@
+---
+description: Guard backward compatibility of exported API
+globs:
+  - "pkg/**/*.go"
+alwaysApply: true
+---
+
+# Backward Compatibility
+
+This repository is imported as a library by other repos. Breaking the public API is costly.
+
+## What counts as a breaking change
+
+- Removing or renaming an exported function, type, constant, or variable in `pkg/`
+- Changing the signature of an exported function (parameters, return types)
+- Changing the behavior of an exported function in a way that existing callers would not expect
+- Removing or renaming a field in an exported struct
+
+## Rules
+
+1. **Always ask the user** before making any change that could break backward compatibility. Phrase it clearly: "This renames/removes an exported symbol — existing importers will break. Proceed?"
+2. If the user confirms, **add `[Possible compatibility break]`** to the worklog entry in `docs/WORKLOG.md` for that change.
+3. Prefer **adding new symbols** alongside old ones (deprecate, don't delete) when possible.
+4. When renaming, add a comment into code with the old name and link to the new one, like this `// Deprecated: renamed to NewName.`

.cursor/rules/functions-glossary.mdc

@@ -0,0 +1,24 @@
+---
+description: Check function glossary before adding new exported functions
+globs:
+  - "pkg/**/*.go"
+alwaysApply: true
+---
+
+# Functions Glossary Guard
+
+Before adding any new exported function in the `pkg/` directory, you MUST check `docs/FUNCTIONS_GLOSSARY.md` for similar existing functions.
+
+## Workflow
+
+1. **Before creating a new exported function**, search `docs/FUNCTIONS_GLOSSARY.md` for functions with similar names or purposes.
+2. **If a similar function already exists**, suggest it to the user: "Function `ExistingFunc` in `pkg/path/file.go` already does something similar. Would you like to use or extend it instead?"
+3. **If the user declines and wants a new function anyway**, add the new function to `docs/FUNCTIONS_GLOSSARY.md` in the appropriate section with the comment `<!-- duplicates func ExistingFuncName -->` appended to the entry line.
+4. **If no similar function exists**, add the new function to `docs/FUNCTIONS_GLOSSARY.md` in the appropriate section (matching the file it belongs to).
+5. **When renaming or removing exported functions**, update the corresponding entries in `docs/FUNCTIONS_GLOSSARY.md`.
+
+## Entry format
+
+```markdown
+- `FuncName(param1, param2)` — Brief description of what the function does.
+```

.cursor/rules/todo-command.mdc

@@ -0,0 +1,37 @@
+---
+description: Handle /todo command for managing TODO.md
+globs: []
+alwaysApply: true
+---
+
+# /todo Command
+
+When the user types a message starting with `/todo`, manage records in `docs/TODO.md`.
+
+## Syntax
+
+- `/todo Add <description>` — Append a new TODO item.
+- `/todo Remove <description>` — Remove a matching TODO item (fuzzy match on description text).
+- `/todo Check` or `/todo List` — Read and display all current TODO items.
+- `/todo Done <description>` — Mark a TODO item as done by striking it through (`~~text~~`).
+
+## Format in TODO.md
+
+Each TODO item is a markdown list entry under a category heading:
+
+```markdown
+## Category Name
+
+- [ ] Description of the task
+- [x] ~~Completed task~~
+```
+
+If no category is specified, add items under a `## General` heading.
+
+## Rules
+
+1. Read `docs/TODO.md` before making changes to avoid duplicates.
+2. When adding, append to the end of the appropriate section.
+3. When removing, delete the entire line. If the section becomes empty (no items), remove the section heading too.
+4. After any change, confirm to the user what was done (e.g. "Added TODO: ..." or "Removed TODO: ...").
+5. Also append a worklog entry to `docs/WORKLOG.md` describing the TODO change.

.cursor/rules/versatile-functions.mdc

@@ -0,0 +1,33 @@
+---
+description: Ensure new functions are general-purpose and reusable
+globs:
+  - "pkg/**/*.go"
+alwaysApply: true
+---
+
+# Versatile Function Design
+
+Functions in `pkg/` are shared across multiple repos. Every new function must be general-purpose and reusable.
+
+## Principles
+
+1. **Return data, not decisions.** Prefer functions that return rich objects (structs, slices) over functions that return booleans for a specific check. Let the caller decide what to inspect.
+   - Good: `GetWorkerNodes(ctx, kubeconfig) ([]corev1.Node, error)` — caller can check length, filter by name, inspect labels, etc.
+   - Bad: `EnsureNode2IsWorker(ctx, kubeconfig) error` — single-purpose, not reusable.
+
+2. **No hardcoded names or indices.** Never bake specific resource names, node indices, or counts into a function. Accept them as parameters instead.
+   - Good: `IsNodeCordoned(ctx, kubeconfig, nodeName) (bool, error)`
+   - Bad: `IsFirstMasterCordoned(ctx, kubeconfig) (bool, error)`
+
+3. **Compose from existing functions.** Before writing new logic, check if the task can be achieved by combining existing functions from `docs/FUNCTIONS_GLOSSARY.md`. If a small wrapper is needed, make sure it is still generic.
+
+4. **Accept interfaces, return structs.** Where practical, accept broad types (context, rest.Config) and return concrete Kubernetes objects so callers have full access to the data.
+
+5. **No empty wrappers.** Do not add functions that merely call another function and reformat or filter its output without adding meaningful logic. If the caller can achieve the same result with a one-liner on the original function's return value, do not create a wrapper.
+   - Bad: `GetWorkerNodeNames(ctx, cfg)` that just calls `GetWorkerNodes` and extracts `.Name` from each element — the caller can do that itself.
+   - Bad: `GetFirstNode(ctx, cfg)` that just calls `GetNodes` and returns `[0]`.
+   - Acceptable: a wrapper that adds retry logic, caching, or non-trivial filtering/transformation.
+
+## When reviewing a new function
+
+Ask yourself: "Could a different test or a different repo use this function as-is?" If the answer is no, redesign it to be more general before adding it.

.cursor/rules/worklog.mdc

@@ -0,0 +1,32 @@
+---
+description: Maintain the work log on any code changes
+globs:
+  - "**/*.go"
+  - "**/*.yml"
+  - "**/*.yaml"
+  - "**/*.tpl"
+  - "**/*.sh"
+alwaysApply: true
+---
+
+# Work Log Maintenance
+
+After making any code changes (new features, refactors, renames, bug fixes, deletions), append a brief entry to `docs/WORKLOG.md`.
+
+## Format
+
+Each entry is a single line under today's date heading (`## YYYY-MM-DD`):
+
+```
+- **Type** description of what was changed and why
+```
+
+Where **Type** is one of: `Add`, `Remove`, `Rename`, `Refactor`, `Bugfix`, `Update`, `Move`.
+
+## Rules
+
+1. If today's date heading does not exist yet, add it at the bottom of the file before your entries.
+2. Append new entries under the current date heading — never prepend or reorder.
+3. If changes are rolled back in the same session, remove only today's corresponding entries. **Never touch entries from previous days.**
+4. Keep entries concise (one line each). Reference the file path and function/type name when relevant.
+5. Group related changes into a single entry when they form one logical unit (e.g. a rename + caller updates = one entry).

README.md

@@ -69,7 +69,7 @@ Run the test: `go test -timeout=120m -v ./tests/csi-all-stress-tests -count=1`
 
 ## Functions Glossary (exportable only)
 
-See [pkg/FUNCTIONS_GLOSSARY.md](pkg/FUNCTIONS_GLOSSARY.md) for a full list of all exported functions in the `pkg/` directory, grouped by resource (cluster, VM, PVC, LVMVolumeGroup, etc.).
+See [docs/FUNCTIONS_GLOSSARY.md](docs/FUNCTIONS_GLOSSARY.md) for a full list of all exported functions in the `pkg/` directory, grouped by resource (cluster, VM, PVC, LVMVolumeGroup, etc.).
 
 
 ## Environment Variables