root/
├── start_*.py          # Entry points (must work)
├── src/               # Core modules
├── utils/             # Utilities
├── tests/             # Working test files
├── docs/              # Documentation (no emojis)
├── data/              # Data files
├── reports/           # Generated reports
└── legacy/            # Old/deprecated files

Naming Conventions

Use underscore_case for files
Avoid version numbers in filenames (v2, v3)
Use descriptive, professional names
No "executive", "improved", "advanced" in names

TESTING REQUIREMENTS

All Tests Must:

Actually run without errors
Have clear, working examples
Be maintained and updated
Use real, existing file paths
Handle missing dependencies gracefully

Entry Points Must:

Work when called without arguments (show help)
Support --help, --version, -h, -v flags
Provide working examples in help text
Exit gracefully on errors

AI ASSISTANT BEHAVIOR

When Editing Code:

READ existing code first
UNDERSTAND current patterns
SUGGEST improvements, don't assume
CREATE _dev versions for major changes
PRESERVE working functionality
TEST references and imports

When Creating Documentation:

NO emojis, accents, or special characters
Use plain ASCII text only
Provide clear, working examples
Keep technical, professional tone

When Fixing Bugs:

Find ROOT CAUSE of the problem
Fix ALL related instances
Update ALL cross-references
Test the fix works
Don't introduce new problems

COMMON MISTAKES TO AVOID

File References

Don't reference moved/renamed files with old names
Don't assume file locations without checking
Update import statements when moving files
Maintain entry point compatibility

Dependencies

Don't suggest pip install for built-in modules
Verify import syntax before suggesting fixes
Test dependency checks work correctly
Handle missing optional dependencies gracefully

Character Usage

Never use emojis in ANY output
Replace accented characters with ASCII equivalents
Use professional, neutral language
Avoid casual/informal expressions

IMPLEMENTATION CHECKLIST

Before submitting any code:

PROJECT-SPECIFIC GUIDELINES (RENAMEPDFEPUB)

These complement the global rules with expectations specific to this repository:

Editing conduct: sober, professional tone; avoid hype terms (final/ultra/definitivo/melhorado/refinado/superior).
Modular design: use specialized, descriptive functions; group related logic; imports at file top; add concise docstrings for new functions.
UI/UX: add inline hints and non-blocking validation; group rename controls in a single row (pattern/underscore/preview/apply); keep interfaces responsive with background work and clear feedback; avoid “cringe” or playful copy.
Rename patterns: allowed placeholders {title}, {author}, {year}, {publisher}, {isbn}; validate and warn the user; keep sanitization consistent (ASCII fallback, underscore option).
Error handling: no try/except just to silence errors; provide meaningful handling and centralized logging; avoid raw stack traces in UI.
Rollback and safety: dry-run first; create backups before destructive DB/file changes; separate preview from apply.
Testing: write meaningful tests for each feature; avoid trivial tests; validate expected UI behaviors when feasible.
Performance: limit previews and log reads; use efficient queries; ensure background tasks do not block the UI.
CLI usage: avoid very long command lines and quoting pitfalls; prefer short flags or config files.
Cross-platform: keep Windows 11, macOS, and Debian 13 compatibility; handle PyQt6 font/spacing differences on macOS as needed.
Environment: maintain up-to-date requirements.txt; prefer project-specific virtualenv (venv/pyenv/direnv) with activation/deactivation scripts when applicable.
Documentation: update relevant docs on behavior changes; keep short “what changed/what next” notes; maintain CHANGELOG entries when appropriate.