feat: adopt column descriptions

.cursor/rules/cursor/rules.mdc

@@ -0,0 +1,152 @@
+---
+description: How to create or update Cursor rule files for GoodData Python SDK repository
+alwaysApply: false
+---
+
+# How to Create/Update Cursor Rule Files
+
+## Rule File Structure
+
+```
+.cursor/rules/
+├── cursor/                      # Meta-rules about Cursor
+│   ├── rules.mdc               # This file
+│   └── workflow-validation.mdc
+├── general/                     # Always-applied core rules
+│   └── workflow-and-testing.mdc # ESSENTIAL: Keep concise!
+└── libraries/                   # Library-specific rules
+    └── gooddata-api-client.mdc
+```
+
+## Rule Categories
+
+### General Rules (alwaysApply: true)
+Located in `general/`, always included in context.
+
+**CRITICAL**: Keep these concise - they're always loaded!
+- Focus on essential workflows
+- Use tables for quick reference
+- Remove redundancy
+- Typical size: 100-200 lines max
+
+Example: `workflow-and-testing.mdc` (merged workflow + testing essentials)
+
+### Library Rules (alwaysApply: false)
+Located in `libraries/`, loaded when relevant.
+
+Can be more detailed since they're conditional.
+
+Example: `gooddata-api-client.mdc` (API client regeneration)
+
+## Rule File Format
+
+```markdown
+---
+description: Specific, keyword-rich description for Cursor's relevance detection
+alwaysApply: true  # or false
+---
+
+# Clear Title
+
+## Essential sections only
+```
+
+### Writing Concise Rules
+
+**DO**:
+- ✅ Focus on commands and workflows
+- ✅ Use tables for quick reference
+- ✅ Include concrete examples
+- ✅ Keep always-applied rules under 200 lines
+- ✅ Merge related topics to avoid redundancy
+
+**DON'T**:
+- ❌ Repeat information across files
+- ❌ Include every possible detail
+- ❌ Write long explanations for obvious things
+- ❌ Create separate files for related topics
+
+## Description Guidelines
+
+The `description` field is critical for Cursor's relevance matching.
+
+**Good**:
+```yaml
+description: Essential development workflow and testing commands for GoodData Python SDK - formatting, linting, testing, and validation procedures
+```
+
+**Bad**:
+```yaml
+description: How to work with the code
+```
+
+Include keywords: package names, technologies, workflows, concepts.
+
+## Creating New Rules
+
+### When to Create
+
+- ✅ Critical workflow not covered
+- ✅ Library-specific patterns needed
+- ✅ Common mistakes to prevent
+
+### Process
+
+1. **Determine category**: General (always) or Library (conditional)?
+2. **Keep it concise**: Merge related topics
+3. **Test usefulness**: Would this solve real problems?
+4. **Check redundancy**: Does existing rule cover this?
+
+### Example: Adding Library Rule
+
+**User**: "Add rules for gooddata-sdk"
+
+**Action**:
+```bash
+# Create libraries/gooddata-sdk.mdc with:
+# - SDK-specific patterns (catalog services, data sources)
+# - Common imports and class structures
+# - Testing patterns for SDK
+# - Integration with API client
+```
+
+Keep focused on SDK-specific knowledge, not general workflow (already in `general/`).
+
+## Repository Context
+
+### Package Structure
+```
+gooddata-api-client/    # Generated (DO NOT EDIT)
+gooddata-sdk/           # Core SDK
+gooddata-pandas/        # Pandas integration
+gooddata-pipelines/     # Pipelines
+```
+
+### Key Files
+- `Makefile` - Root commands (api-client, test, lint)
+- `project_common.mk` - Shared package rules
+- `pyproject.toml` - Ruff configuration
+- `.pre-commit-config.yaml` - Pre-commit hooks
+
+## Validation Checklist
+
+Before committing a rule:
+
+- [ ] Description is specific and keyword-rich
+- [ ] If `alwaysApply: true`, file is under 200 lines
+- [ ] No redundancy with other rules
+- [ ] Commands are accurate and tested
+- [ ] Examples are concrete
+- [ ] File is in correct directory
+
+## TODO: Future Rules
+
+Only create if truly needed:
+- [ ] `libraries/gooddata-sdk.mdc` - SDK patterns (if not covered by api-client rule)
+- [ ] `libraries/gooddata-pandas.mdc` - Pandas integration (if needed)
+
+## Related Rules
+
+- **workflow-validation.mdc** - How Cursor reports used rules
+- **workflow-and-testing.mdc** - Example of concise, merged general rule
+- **libraries/gooddata-api-client.mdc** - Example of library-specific rule

.cursor/rules/cursor/workflow-validation.mdc

@@ -0,0 +1,19 @@
+---
+alwaysApply: true
+---
+# Cursor IDE Workflow Validation
+
+## Workflow and output constraints
+
+- Include all rules related to the user question; if rules mention dependencies, include those too.
+- After fully answering, report the list of used rules.
+- Example: **Used rules**: general/general, technologies/python, libraries/gooddata-sdk
+- Do not print rule previews or long plans.
+- Keep status updates to one short sentence.
+- Never inline full rule contents; reference by rule path only when needed.
+- Only list rule IDs in "Used rules:".
+
+## Rule Search Requirements
+
+Always look for relevant cursor rules in this repository based on the character of the changes.
+Do not inline rule contents; reference rules by path only when necessary.

.cursor/rules/general/workflow-and-testing.mdc

@@ -0,0 +1,139 @@
+---
+description: Essential development workflow and testing commands for GoodData Python SDK - formatting, linting, testing, and validation procedures
+alwaysApply: true
+---
+
+# Development Workflow & Testing
+
+## After ANY Code Change - Run This
+
+```bash
+# From repository root:
+make format-fix    # Auto-format code
+make lint          # Check for issues
+
+# From package directory (e.g., cd gooddata-sdk):
+TEST_ENVS=py313 ADD_ARGS="-k relevant_test" make test
+```
+
+## Virtual Environment
+
+- **Location**: `.venv/` at repository root
+- **NEVER** use system `python` or `pip` directly
+- **ALWAYS** use `.venv/bin/tox`, `.venv/bin/ruff`, etc.
+
+## Monorepo Structure
+
+```
+gooddata-api-client/    # Generated from OpenAPI (DO NOT EDIT)
+gooddata-sdk/           # Core SDK (depends on api-client)
+gooddata-pandas/        # Pandas integration (depends on sdk)
+gooddata-pipelines/     # Pipelines (depends on sdk)
+```
+
+**Dependency chain**: api-client → sdk → pandas, pipelines, etc.
+
+## Testing Commands
+
+### Quick Reference
+
+| Command | Use When |
+|---------|----------|
+| `TEST_ENVS=py313 make test` | Quick test, one Python version |
+| `TEST_ENVS=py313 ADD_ARGS="-k test_name" make test` | Test specific functionality |
+| `../.venv/bin/tox -e py313 -- -k test_name` | Rapid iteration (from package dir) |
+| `make test` | Full test suite, all Python versions |
+
+### Environment Variables
+
+- `TEST_ENVS=py313` - Test with Python 3.13 only (faster)
+- `ADD_ARGS="-k scan"` - Run tests matching keyword
+- `RECREATE_ENVS=1` - Force recreate tox environments
+
+## Standard Workflow Example
+
+```bash
+# 1. Make code changes
+vim gooddata-sdk/gooddata_sdk/some_file.py
+
+# 2. Format and lint
+make format-fix && make lint
+
+# 3. Run relevant tests
+cd gooddata-sdk
+TEST_ENVS=py313 ADD_ARGS="-k relevant" make test
+
+# 4. Review and commit
+cd ..
+git diff
+git add gooddata-sdk/
+git commit -m "feat: add new feature"
+```
+
+## API Client Change Workflow
+
+```bash
+# 1. Regenerate API client
+make api-client
+
+# 2. Update SDK wrapper classes
+vim gooddata-sdk/gooddata_sdk/catalog/.../column.py
+# Add new field: description: Optional[str] = None
+
+# 3. Format, lint, test
+make format-fix && make lint
+cd gooddata-sdk
+TEST_ENVS=py313 ADD_ARGS="-k scan" make test
+
+# 4. Commit all changes
+cd ..
+git add gooddata-api-client/ gooddata-sdk/ schemas/
+git commit -m "feat: adopt column description from scan API"
+```
+
+## Common Commands
+
+| Task | Command |
+|------|---------|
+| Setup dev environment | `make dev` |
+| Format code | `make format-fix` |
+| Check linting | `make lint` |
+| Run tests (all versions) | `make test` |
+| Regenerate API client | `make api-client` |
+| Type checking | `make mypy` |
+
+## Pre-commit Hooks
+
+Pre-commit hooks run automatically when committing. If they fail:
+- Auto-corrections aren't staged
+- Review the changes: `git diff`
+- Re-stage and commit again
+
+## Git Commit Format
+
+Use Conventional Commits:
+- `feat:` - New feature
+- `fix:` - Bug fix
+- `docs:` - Documentation
+- `test:` - Tests
+- `refactor:` - Code refactoring
+
+## Critical Rules
+
+❌ **DON'T**:
+- Edit files in `gooddata-api-client/` manually
+- Use system Python directly
+- Skip `make format-fix` before committing
+- Commit without running tests
+
+✅ **DO**:
+- Use `.venv/bin/` tools
+- Run `make format-fix && make lint` always
+- Test in relevant package: `cd <package> && TEST_ENVS=py313 make test`
+- Export new public classes in `__init__.py`
+
+## Need More Details?
+
+- API client regeneration → See `libraries/gooddata-api-client.mdc`
+- Pre-commit config → See `.pre-commit-config.yaml`
+- Full guide → See `CONTRIBUTING.md`