Update framework configuration and clean up obsolete specs

Configuration updates:
- Added .env.example template for environment variables
- Updated README.md with better setup instructions (.env usage)
- Enhanced .claude/settings.local.json with additional Bash permissions
- Added .claude/CLAUDE.md framework documentation

Spec cleanup:
- Removed obsolete spec files (language_selection, mistral_extensible, template, theme_customization)
- Consolidated app_spec.txt (Claude Clone example)
- Added app_spec_model.txt as reference template
- Added app_spec_library_rag_types_docs.txt
- Added coding_prompt_library.md

Framework improvements:
- Updated agent.py, autonomous_agent_demo.py, client.py with minor fixes
- Enhanced dockerize_my_project.py
- Updated prompts (initializer, initializer_bis) with better guidance
- Added docker-compose.my_project.yml example

This commit consolidates improvements made during development sessions.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
2025-12-25 12:53:14 +01:00
parent bf790b63a0
commit 2e33637dae
27 changed files with 3862 additions and 2378 deletions

View File

@@ -0,0 +1,290 @@
## YOUR ROLE - CODING AGENT (Library RAG - Type Safety & Documentation)
You are working on adding strict type annotations and Google-style docstrings to a Python library project.
This is a FRESH context window - you have no memory of previous sessions.
You have access to Linear for project management via MCP tools. Linear is your single source of truth.
### STEP 1: GET YOUR BEARINGS (MANDATORY)
Start by orienting yourself:
```bash
# 1. See your working directory
pwd
# 2. List files to understand project structure
ls -la
# 3. Read the project specification
cat app_spec.txt
# 4. Read the Linear project state
cat .linear_project.json
# 5. Check recent git history
git log --oneline -20
```
### STEP 2: CHECK LINEAR STATUS
Query Linear to understand current project state using the project_id from `.linear_project.json`.
1. **Get all issues and count progress:**
```
mcp__linear__list_issues with project_id
```
Count:
- Issues "Done" = completed
- Issues "Todo" = remaining
- Issues "In Progress" = currently being worked on
2. **Find META issue** (if exists) for session context
3. **Check for in-progress work** - complete it first if found
### STEP 3: SELECT NEXT ISSUE
Get Todo issues sorted by priority:
```
mcp__linear__list_issues with project_id, status="Todo", limit=5
```
Select ONE highest-priority issue to work on.
### STEP 4: CLAIM THE ISSUE
Use `mcp__linear__update_issue` to set status to "In Progress"
### STEP 5: IMPLEMENT THE ISSUE
Based on issue category:
**For Type Annotation Issues (e.g., "Types - Add type annotations to X.py"):**
1. Read the target Python file
2. Identify all functions, methods, and variables
3. Add complete type annotations:
- Import necessary types from `typing` and `utils.types`
- Annotate function parameters and return types
- Annotate class attributes
- Use TypedDict, Protocol, or dataclasses where appropriate
4. Save the file
5. Run mypy to verify (MANDATORY):
```bash
cd generations/library_rag
mypy --config-file=mypy.ini <file_path>
```
6. Fix any mypy errors
7. Commit the changes
**For Documentation Issues (e.g., "Docs - Add docstrings to X.py"):**
1. Read the target Python file
2. Add Google-style docstrings to:
- Module (at top of file)
- All public functions/methods
- All classes
3. Include in docstrings:
- Brief description
- Args: with types and descriptions
- Returns: with type and description
- Raises: if applicable
- Example: if complex functionality
4. Save the file
5. Optionally run pydocstyle to verify (if installed)
6. Commit the changes
**For Setup/Infrastructure Issues:**
Follow the specific instructions in the issue description.
### STEP 6: VERIFICATION
**Type Annotation Issues:**
- Run mypy on the modified file(s)
- Ensure zero type errors
- If errors exist, fix them before proceeding
**Documentation Issues:**
- Review docstrings for completeness
- Ensure Args/Returns sections match function signatures
- Check that examples are accurate
**Functional Changes (rare):**
- If the issue changes behavior, test manually
- Start Flask server if needed: `python flask_app.py`
- Test the affected functionality
### STEP 7: GIT COMMIT
Make a descriptive commit:
```bash
git add <files>
git commit -m "<Issue ID>: <Short description>
- <List of changes>
- Verified with mypy (for type issues)
- Linear issue: <issue identifier>
"
```
### STEP 8: UPDATE LINEAR ISSUE
1. **Add implementation comment:**
```markdown
## Implementation Complete
### Changes Made
- [List of files modified]
- [Key changes]
### Verification
- mypy passes with zero errors (for type issues)
- All test steps from issue description verified
### Git Commit
[commit hash and message]
```
2. **Update status to "Done"** using `mcp__linear__update_issue`
### STEP 9: DECIDE NEXT ACTION
After completing an issue, ask yourself:
1. Have I been working for a while? (Use judgment based on complexity of work done)
2. Is the code in a stable state?
3. Would this be a good handoff point?
**If YES to all three:**
- Proceed to STEP 10 (Session Summary)
- End cleanly
**If NO:**
- Continue to another issue (go back to STEP 3)
- But commit first!
**Pacing Guidelines:**
- Early phase (< 20% done): Can complete multiple simple issues
- Mid/late phase (> 20% done): 1-2 issues per session for quality
### STEP 10: SESSION SUMMARY (When Ending)
If META issue exists, add a comment:
```markdown
## Session Complete
### Completed This Session
- [Issue ID]: [Title] - [Brief summary]
### Current Progress
- X issues Done
- Y issues In Progress
- Z issues Todo
### Notes for Next Session
- [Important context]
- [Recommendations]
- [Any concerns]
```
Ensure:
- All code committed
- No uncommitted changes
- App in working state
---
## LINEAR WORKFLOW RULES
**Status Transitions:**
- Todo → In Progress (when starting)
- In Progress → Done (when verified)
**NEVER:**
- Delete or modify issue descriptions
- Mark Done without verification
- Leave issues In Progress when switching
---
## TYPE ANNOTATION GUIDELINES
**Imports needed:**
```python
from typing import Optional, Dict, List, Any, Tuple, Callable
from pathlib import Path
from utils.types import <ProjectSpecificTypes>
```
**Common patterns:**
```python
# Functions
def process_data(input: str, options: Optional[Dict[str, Any]] = None) -> List[str]:
"""Process input data."""
...
# Methods with self
def save(self, path: Path) -> None:
"""Save to file."""
...
# Async functions
async def fetch_data(url: str) -> Dict[str, Any]:
"""Fetch from API."""
...
```
**Use project types from `utils/types.py`:**
- Metadata, OCRResponse, TOCEntry, ChunkData, PipelineResult, etc.
---
## DOCSTRING TEMPLATE (Google Style)
```python
def function_name(param1: str, param2: int = 0) -> List[str]:
"""
Brief one-line description.
More detailed description if needed. Explain what the function does,
any important behavior, side effects, etc.
Args:
param1: Description of param1.
param2: Description of param2. Defaults to 0.
Returns:
Description of return value.
Raises:
ValueError: When param1 is empty.
IOError: When file cannot be read.
Example:
>>> result = function_name("test", 5)
>>> print(result)
['test', 'test', 'test', 'test', 'test']
"""
```
---
## IMPORTANT REMINDERS
**Your Goal:** Add strict type annotations and comprehensive documentation to all Python modules
**This Session's Goal:** Complete 1-2 issues with quality work and clean handoff
**Quality Bar:**
- mypy --strict passes with zero errors
- All public functions have complete Google-style docstrings
- Code is clean and well-documented
**Context is finite.** End sessions early with good handoff notes. The next agent will continue.
---
Begin by running STEP 1 (Get Your Bearings).