scitex 2.13.0__py3-none-any.whl → 2.15.1__py3-none-any.whl

scitex/scholar/docs/to_claude/guidelines/programming_common/renaming-and-cleaning-workflow.md

@@ -1,311 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-05-25 16:15:00
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/guidelines-programming-Renaming-and-Cleaning-Workflow.md
-!-- --- -->
-
-# Renaming and Cleaning Workflow Guidelines
-
-## Overview
-Systematic approach for refactoring duplicate functions, aliases, and inconsistent naming across codebases.
-
-## Pre-requisites
-- Version control (git) with clean working directory
-- Comprehensive test suite
-- Backup strategy
-
-## Phase 1: Discovery and Analysis
-
-### 1.1 Identify Duplicates
-```bash
-# Find duplicate function definitions
-grep -r "^(defun\|^def\|^function\|^const.*=.*function" --include="*.el" --include="*.py" --include="*.js" src/ | sort | uniq -d
-
-# Find aliases (language-specific)
-grep -r "defalias\|alias\|=.*function" --include="*.el" --include="*.py" --include="*.js" src/
-```
-
-### 1.2 Analyze Patterns
-- Functions with similar names (e.g., `start` vs `enable`)
-- Deprecated names still in use
-- Inconsistent naming conventions
-- Module-specific vs global naming
-
-### 1.3 Create Analysis Script
-```bash
-#!/bin/bash
-# analyze-duplicates.sh
-# Extract and compare duplicate definitions
-# Show references and usage patterns
-# Generate recommendations
-```
-
-## Phase 2: Planning
-
-### 2.1 Categorize Changes
-1. **Naming standardization**: Align with project conventions
-2. **Alias removal**: Replace short/unclear aliases with descriptive names
-3. **Duplicate elimination**: Keep most appropriate implementation
-4. **Module consolidation**: Move functions to proper modules
-
-### 2.2 Create Replacement Map
-```bash
-# Format: old_name → new_name (reason)
-REPLACEMENTS=(
-    "short-name:descriptive-name:Use descriptive naming"
-    "old-func:new-func:Standardize naming convention"
-    "duplicate-1:canonical-name:Remove duplicate"
-)
-```
-
-## Phase 3: Implementation
-
-### 3.1 Automated Renaming Script
-```bash
-#!/bin/bash
-# refactor-aliases.sh
-
-# Configuration
-DRY_RUN=true  # Always start with dry run
-RENAME_SCRIPT="./path/to/replace_and_rename.sh"
-
-# Function to perform systematic renaming
-rename_function() {
-    local old="$1"
-    local new="$2"
-    local reason="$3"
-    
-    echo "Renaming: $old → $new"
-    echo "Reason: $reason"
-    
-    if [ "$DRY_RUN" = true ]; then
-        "$RENAME_SCRIPT" "$old" "$new" .
-    else
-        "$RENAME_SCRIPT" -n "$old" "$new" .
-    fi
-}
-
-# Process replacements in phases
-# Phase 1: Standardize naming
-# Phase 2: Remove aliases
-# Phase 3: Consolidate modules
-```
-
-### 3.2 Replace and Rename Tool
-Essential features:
-- Replace in file contents
-- Rename files/directories
-- Preserve git history
-- Handle regex patterns
-- Dry run capability
-
-## Phase 4: Cleanup
-
-### 4.1 Remove Duplicates
-```bash
-#!/bin/bash
-# remove-duplicates.sh
-
-# Create backup
-BACKUP_DIR=".backup-$(date +%Y%m%d-%H%M%S)"
-
-# Remove duplicate definitions
-# Remove obsolete aliases
-# Update provide/require statements
-```
-
-### 4.2 Manual Review Required
-- Duplicate function definitions (decide which to keep)
-- Module boundaries and dependencies
-- Public API changes
-- Documentation updates
-
-## Phase 5: Validation
-
-### 5.1 Testing
-```bash
-# Run all tests
-./run_tests.sh
-
-# Check for undefined references
-grep -r "undefined.*function" test-output.log
-
-# Verify module loading
-find . -name "*.el" -exec emacs --batch -l {} \;
-```
-
-### 5.2 Linting
-```bash
-# Language-specific linting
-# Python: black, flake8, mypy
-# JavaScript: eslint
-# Elisp: byte-compile warnings
-```
-
-## Phase 6: Documentation
-
-### 6.1 Update References
-- README files
-- API documentation
-- Code comments
-- Configuration examples
-
-### 6.2 Migration Guide
-For public APIs, provide:
-- Deprecation notices
-- Migration timeline
-- Compatibility shims
-
-## Best Practices
-
-### DO:
-1. **Always dry run first**
-2. **Work in phases** - don't change everything at once
-3. **Create backups** before destructive operations
-4. **Test after each phase**
-5. **Document breaking changes**
-6. **Use version control** - commit after each successful phase
-
-### DON'T:
-1. **Don't mix refactoring with feature changes**
-2. **Don't ignore test failures**
-3. **Don't rush cleanup** - careful analysis prevents mistakes
-4. **Don't forget transitive dependencies**
-5. **Don't rename without understanding usage**
-
-## Common Patterns
-
-### Naming Conventions
-```
-# Short alias → Descriptive name
-start → module-feature-enable
-stop → module-feature-disable
-toggle → module-feature-toggle
-
-# Module prefixing
-generic-name → module-specific-name
-```
-
-### State Functions
-```
-# Consolidate state detection
-detect-simple-state → detect-state
-detect-enhanced-state → detect-state
-get-state-property → state-get-property
-```
-
-### Notification/Event Patterns
-```
-# Standardize event naming
-auto-notify-* → notification-*
-on-* → handle-*
-```
-
-## Recovery Procedures
-
-### If Something Goes Wrong:
-1. **Stop immediately**
-2. **Check backup directory**
-3. **Use git to review changes**: `git diff`
-4. **Restore from backup if needed**
-5. **Analyze what went wrong**
-6. **Adjust scripts and retry**
-
-## Tooling Requirements
-
-### Essential Tools:
-- `grep` / `ripgrep` for searching
-- `sed` / `awk` for text processing
-- `find` for file operations
-- Version control (git)
-- Language-specific parsers for AST-based refactoring
-
-### Global Helper Scripts:
-Located in `~/.claude/to_claude/bin/`:
-
-1. **`replace_and_rename.sh`** - Core renaming tool
-   - Replaces text in files and renames files/directories
-   - Supports dry run mode
-   - Usage: `replace_and_rename.sh [-n] <search> <replace> [directory]`
-
-2. **`analyze-duplicates.sh`** - Discovery and analysis
-   - Auto-detects language (elisp, python, js)
-   - Finds duplicate function definitions
-   - Identifies aliases and naming inconsistencies
-   - Usage: `analyze-duplicates.sh [directory] [language]`
-
-3. **`refactor-rename.sh`** - Orchestration script
-   - Processes rename mappings in phases
-   - Creates backups automatically
-   - Supports dry run mode
-   - Usage: `DRY_RUN=false refactor-rename.sh [directory] [mappings.txt]`
-
-4. **`cleanup-duplicates.sh`** - Cleanup script
-   - Removes duplicate functions and obsolete aliases
-   - Works with cleanup plan file
-   - Generates summary report
-   - Usage: `DRY_RUN=false cleanup-duplicates.sh [directory] [cleanup-plan.txt]`
-
-### Quick Start:
-```bash
-# 1. Analyze current state
-~/.claude/to_claude/bin/analyze-duplicates.sh ./src elisp
-
-# 2. Create rename mappings file
-cat > rename-mappings.txt << EOF
-old-func:new-func:Reason for change
-another-old:another-new:Different reason
-EOF
-
-# 3. Perform renaming (dry run first)
-~/.claude/to_claude/bin/refactor-rename.sh ./src rename-mappings.txt
-
-# 4. Apply changes
-DRY_RUN=false ~/.claude/to_claude/bin/refactor-rename.sh ./src rename-mappings.txt
-
-# 5. Create cleanup plan
-cat > cleanup-plan.txt << EOF
-remove-function:src/module.el:duplicate-func:Keep version in main module
-remove-alias:src/api.el:old-alias:Replaced with new name
-EOF
-
-# 6. Clean up duplicates
-DRY_RUN=false ~/.claude/to_claude/bin/cleanup-duplicates.sh ./src cleanup-plan.txt
-```
-
-## Language-Specific Considerations
-
-### Emacs Lisp:
-- Check `defalias` statements
-- Update `provide`/`require` forms
-- Handle autoloads
-- Consider byte-compilation
-
-### Python:
-- Update `__all__` exports
-- Fix import statements
-- Handle `@property` decorators
-- Update type hints
-
-### JavaScript:
-- Update export/import statements
-- Handle default exports
-- Fix destructuring assignments
-- Update TypeScript definitions
-
-## Checklist
-
-- [ ] Clean git working directory
-- [ ] All tests passing
-- [ ] Duplicates identified and analyzed
-- [ ] Replacement map created and reviewed
-- [ ] Dry run completed successfully
-- [ ] Backups created
-- [ ] Live run executed
-- [ ] Duplicates removed
-- [ ] Tests passing after refactor
-- [ ] Documentation updated
-- [ ] Changes committed with clear message
-- [ ] Team notified of breaking changes
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/screen.md

@@ -1,32 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-09-02 00:58:41
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/programming_common/screen.md
-!-- --- -->
-
-Agents can use THEIR OWN TERMINAL by using `screen` as follows:
-
-``` bash
-# Parameters
-ISSUE_ID="1234"
-TIMESTAMP=$(date +%Y%m%d_%H%M%S)
-SCREEN_NAME="debug_$ISSUE_ID_$TIMESTAMP"
-CAPTURE_FILE="./debug/$SCREEN_NAME.txt"
-WORKING_DIR="$(pwd)"
-
-# Create Screen Session
-screen -dmS "$SCREEN_NAME"
-# List created screen session as a confirmation
-screen -list | grep "$SCREEN_NAME"
-# Cat the contents in the screen session as humans see
-screen -S "$SCREEN_NAME" -X hardcopy -h "$CAPTURE_FILE" && cat "$CAPTURE_FILE"
-# Send commands to the screen session
-screen -S "$SCREEN_NAME" -X stuff "cd $WORKING_DIR\n"
-screen -S "$SCREEN_NAME" -X stuff "python script.py\n"
-# Although executing the script may take time, you can check the screen session anytime
-screen -S "$SCREEN_NAME" -X hardcopy -h "$CAPTURE_FILE" && cat "$CAPTURE_FILE"
-# Cleanup the screen session
-screen -S "$SCREEN_NAME" -X quit
-```
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-CLAUDE_ID.md

@@ -1,15 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-01 02:30:57
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/project/IMPORTANT-CLAUDE_ID.md
-!-- --- -->
-
-# Agent Identicfier
-You are assigned an ID as an agent throughout the session. Check it by running `echo $CLAUDE_ID` and remember it for your signature.
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-`MY CLAUDE ID IS: $CLAUDE_ID`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-beyond-control.md

@@ -1,14 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-01 01:12:42
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/project/IMPORTANT-beyond-control.md
-!-- --- -->
-
-# Beyond Control
-If you find problems you cannot solve, raise the problem in `./project_management/beyond-control`
-
-e.g., 
-`./project_management/beyond-control/feature-request-<title>-in-yyyy-package.md`
-`./project_management/beyond-control/bug-report-<title>-in-zzz-system.md`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-bug-report.md

@@ -1,43 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-01 02:11:57
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/project/IMPORTANT-bug-report.md
-!-- --- -->
-
-# Local Bug Report Rules
-
-## Locations
-- Bug report MUST be written as:
-  `./project_management/bug-reports/bug-report-<title>.md`
-- Bug report MUST be as much simple as possible
-- Once solved, bug reports MUST be moved to:
-  `./project_management/bug-reports/solved/bug-report-<title>.md`
-
-## How to solve bug reports
-1. Think potential causes and make a plan to troubleshoot
-   2. Identify the root cause with simple temporal testing
-   3. If route cause is not identified, THINK MORE DEEPLY and restart from step 1.
-4. Add debugging code to potential code
-5. List your opinions, priorities, and reasons
-6. Make a plan to fix the problem
-7. If fixation will be simple, just fix there
-8. Otherwise, create a dedicated `feature/bug-fix-<title>` feature branch from
-9. Once bug report is solved, merge the `feature/bug-fix-<title>` branch back to the original branch
-
-## When solving problem is difficult
-Consider reverting to the latest commit which did not raise the problem. We sometimes make mistakes but retry with experiences and updated ideas.
-
-## Format
-- Add progress section in `./project_management/bug-reports/bug-report-<title>.md` as follows:
-  ```
-  ## Bug Fix Progress
-  - [x] Identify root cause
-  - [ ] Fix XXX
-  ```
-- Once merge succeeded, delete the merged feature branch
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-cleanliness.md

@@ -1,162 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-05-21 02:22:31
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/IMPORTANT-guidelines-programming-Cleanup-Rules.md
-!-- --- -->
-
-# Cleanup Guidelines
-
-Follow these guidelines when preparing the codebase for production. The goal is to achieve product-ready quality.
-
-## Table of Contents
-- [Setup Safety Mechanisms](#setup-safety-mechanisms)
-- [Review Code Quality Standards](#review-code-quality-standards)
-- [Inventory Project Structure](#inventory-project-structure)
-- [Develop a Cleanup Plan](#develop-a-cleanup-plan)
-- [Clean Project Directories](#clean-project-directories)
-- [Handle File Removal Safely](#handle-file-removal-safely)
-- [Standardize File Naming](#standardize-file-naming)
-- [Complete the Process](#complete-the-process)
-- [Examples](#examples)
-  - [Branch Creation Examples](#branch-creation-examples)
-  - [File Naming Examples](#file-naming-examples)
-  - [Safe Removal Examples](#safe-removal-examples)
-
-## Setup Safety Mechanisms
-1. Create a feature branch: `feature/cleanup-YYYY-MMDD-HHmmss`
-2. Create a checkpoint branch: `checkpoint/before-cleanup-YYYY-MMDD-HHmmss`
-3. In the checkpoint branch, save ALL FILES (including uncommitted and hidden files)
-
-## Review Code Quality Standards
-1. Review Clean Code Rules: `./docs/to_claude/guidelines/IMPORTANT-guidelines-programming-Clean-Code-Rules.md`
-2. Review Readable Code: `./docs/to_claude/guidelines/the-art-of-readable-code.pdf`
-
-## Inventory Project Structure
-1. Run `tree -a` to view all the files
-2. Document the current state before cleanup
-
-## Develop a Cleanup Plan
-1. Prioritize tasks
-2. Set clear acceptance criteria
-3. Create a cleanup checklist
-
-## Clean Project Directories
-1. Source code: `./src`, `./scripts`
-2. Documentation: `./docs/`
-3. Examples: `./examples`
-4. Project management: `./project_management`
-5. Tests: `./tests`
-
-## Handle File Removal Safely
-1. Never use `rm` directly
-2. Use `./docs/to_claude/bin/safe_rm.sh` to move obsolete files to `.old` directories
-3. Reference `./docs/to_claude/guidelines/guidelines-command-rm.md`
-
-## Standardize File Naming
-1. Eliminate development patterns such as `-v01`, `-fix`, `-improved`, `-consolidated`, `-enhanced`
-2. Use clean production names: `filename.ext`
-
-## Complete the Process
-1. Verify all tests pass
-2. Merge `feature/cleanup-YYYY-MMDD-HHmmss` back to the original branch
-
-## Examples
-
-### Branch Creation Examples
-
-| ❌ DO NOT | ✅ DO |
-|-----------|------|
-| ```bash
-# Directly making changes on main/develop branch
-git checkout develop
-# Start editing files directly
-``` | ```bash
-# Create feature and checkpoint branches
-git checkout develop
-git checkout -b feature/cleanup-2025-0521-022230
-git checkout -b checkpoint/before-cleanup-2025-0521-022230
-# Make a complete backup
-git add -A
-git commit -m "Complete checkpoint before cleanup"
-git checkout feature/cleanup-2025-0521-022230
-``` |
-| ```bash
-# Using ambiguous branch names
-git checkout -b cleanup
-git checkout -b backup
-``` | ```bash
-# Using specific timestamped branch names
-git checkout -b feature/cleanup-2025-0521-022230
-git checkout -b checkpoint/before-cleanup-2025-0521-022230
-``` |
-
-### File Naming Examples
-
-| ❌ DO NOT | ✅ DO |
-|-----------|------|
-| ```
-utils-v01.py
-utils-v02.py
-utils-improved.py
-utils-new.py
-utils-final.py
-utils-final-v2.py
-``` | ```
-utils.py
-``` |
-| ```
-data_processor-initial.py
-data_processor-with-fix.py
-data_processor-optimized.py
-data_processor-production.py
-``` | ```
-data_processor.py
-``` |
-| ```
-# Multiple files with similar functionality
-user_validator.py
-validate_user.py
-user_validation_improved.py
-``` | ```
-# Single consolidated file
-user_validation.py
-``` |
-
-### Safe Removal Examples
-
-| ❌ DO NOT | ✅ DO |
-|-----------|------|
-| ```bash
-# Directly removing files
-rm obsolete_script.py
-rm -rf old_directory
-``` | ```bash
-# Using safe_rm.sh for removal
-./docs/to_claude/bin/safe_rm.sh obsolete_script.py
-./docs/to_claude/bin/safe_rm.sh old_directory
-``` |
-| ```bash
-# Hard-deleting configuration files
-rm config-old.json
-rm config-backup.json
-``` | ```bash
-# Safely moving old config files
-./docs/to_claude/bin/safe_rm.sh config-old.json
-./docs/to_claude/bin/safe_rm.sh config-backup.json
-# Creates:
-# .old/config-old.json
-# .old/config-backup.json
-``` |
-| ```bash
-# Mass deletion without review
-rm *.tmp
-rm *-old.*
-rm -rf __pycache__
-``` | ```bash
-# Review and use safe removal
-find . -name "*.tmp" -type f > to_remove.txt
-# Review to_remove.txt carefully
-cat to_remove.txt | xargs -I{} ./docs/to_claude/bin/safe_rm.sh {}
-``` |
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-communication.md

@@ -1,13 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-07 02:31:38
-!-- Author: ywatanabe
-!-- File: /ssh:ywatanabe@sp:/home/ywatanabe/.claude/to_claude/guidelines/project/IMPORTANT-communication.md
-!-- --- -->
-
-## Communication Standards
-- Explain findings with supporting evidence
-- Prioritize figures, diagrams, tables over text
-- Link all claims to evidence files: src/test/example/playground code and outputs
-- Understand other agents' claims for effective collaboration
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-do-not-create-any-new-file-nor-directory-in-project-root.md

@@ -1,9 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-05-26 06:50:50
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/project/do-not-create-any-new-file-nor-directory-in-project-root.md
-!-- --- -->
-
-DO NOT CREATE ANY NEW FILE NOR DIRECTORY IN PROJECT ROOT.
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-documentation.md

@@ -1,11 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-07 02:30:49
-!-- Author: ywatanabe
-!-- File: /ssh:ywatanabe@sp:/home/ywatanabe/.claude/to_claude/guidelines/project/IMPORTANT-documentation.md
-!-- --- -->
-
-## Documentation
-- Write documents under ./docs/by_agents
-- Write README.md in each directory
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/project/IMPORTANT-feature-request.md

@@ -1,33 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-05-18 02:25:08
-!-- Author: ywatanabe
-!-- File: /ssh:ywatanabe@sp:/home/ywatanabe/.claude/to_claude/guidelines/guidelines_programming_feature_request_rules.md
-!-- --- -->
-
-# Local Feature Request Rules
-
-## Locations
-- Local feature requests should be written as:
-  `./project_management/feature_requests/feature-request-<title>.md`
-- Note that feature request should be as much simple as possible
-- Once solved, feature requests should be moved to:
-  `./project_management/feature_requrests/solved/feature-request-<title>.md`
-
-## How to solve feature requests
-- Create `feature/<title>` branch from `develop`
-- Add progress section in `./project_management/feature_requests/feature-request-<title>.md` as follows:
-  ```
-  # Feature Request <title>
-
-  ...
-
-  # Progress
-  - [x] TASK 1
-  - [ ] TASK 2
-  - [ ] ...
-  ```
-- Once feature request is solved, merge the `feature/<title>` branch to `develop` branch
-
-- Once merge succeeded, delete the merged feature branch
-
-<!-- EOF -->