rex-machine 0.2.0__tar.gz → 0.2.2__tar.gz

{rex_machine-0.2.0 → rex_machine-0.2.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: rex-machine
-Version: 0.2.0
+Version: 0.2.2
 Summary: Extract lessons learned (REX) from code repositories
 Project-URL: Homepage, https://github.com/NicoJuiced/rex-machine
 Project-URL: Repository, https://github.com/NicoJuiced/rex-machine
@@ -36,8 +36,6 @@ Description-Content-Type: text/markdown
 
 **Your codebase has lessons no one wrote down. This finds them.**
 
-[![Star History Chart](https://api.star-history.com/svg?repos=NicoJuiced/rex-machine&type=Date)](https://star-history.com/#NicoJuiced/rex-machine&Date)
-
 rex-machine scans any code repository and extracts structured technical lessons learned — what problems the team faced, what they tried, what worked. Claude navigates your repo autonomously (reading files, grepping, following imports) and produces a grounded report, not a vague summary.
 
 Works on any language, any framework, any repo size.
@@ -134,3 +132,7 @@ rex status        # show current config
 ## License
 
 [Apache 2.0](LICENSE)
+
+## Star History
+
+[![Star History Chart](https://api.star-history.com/svg?repos=NicoJuiced/rex-machine&type=Date)](https://star-history.com/#NicoJuiced/rex-machine&Date)

{rex_machine-0.2.0 → rex_machine-0.2.2}/README.md

@@ -2,8 +2,6 @@
 
 **Your codebase has lessons no one wrote down. This finds them.**
 
-[![Star History Chart](https://api.star-history.com/svg?repos=NicoJuiced/rex-machine&type=Date)](https://star-history.com/#NicoJuiced/rex-machine&Date)
-
 rex-machine scans any code repository and extracts structured technical lessons learned — what problems the team faced, what they tried, what worked. Claude navigates your repo autonomously (reading files, grepping, following imports) and produces a grounded report, not a vague summary.
 
 Works on any language, any framework, any repo size.
@@ -100,3 +98,7 @@ rex status        # show current config
 ## License
 
 [Apache 2.0](LICENSE)
+
+## Star History
+
+[![Star History Chart](https://api.star-history.com/svg?repos=NicoJuiced/rex-machine&type=Date)](https://star-history.com/#NicoJuiced/rex-machine&Date)

{rex_machine-0.2.0 → rex_machine-0.2.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "rex-machine"
-version = "0.2.0"
+version = "0.2.2"
 description = "Extract lessons learned (REX) from code repositories"
 readme = "README.md"
 requires-python = ">=3.10"

{rex_machine-0.2.0 → rex_machine-0.2.2}/src/rex_machine/__init__.py

@@ -1,3 +1,3 @@
 """rex-machine - Extract lessons learned from code repositories."""
 
-__version__ = "0.2.0"
+__version__ = "0.2.2"

{rex_machine-0.2.0 → rex_machine-0.2.2}/src/rex_machine/templates/prompts/code_pattern_analyzer.j2

@@ -13,12 +13,21 @@ Look for REX signals in:
 - Defensive programming: path validation, input sanitization, safety caps, timeout handling
 - Abstraction levels: is the code over-engineered or under-abstracted? Where was complexity invested?
 
-For each finding, cite specific files and line numbers. Distinguish between "this IS the pattern used" vs "this COULD be improved" — both can be REX.
-
 FORMAT YOUR OUTPUT AS A LIST OF FINDINGS. For each finding, use this structure:
 
 ### Finding: [short title]
 - **Problem/Context**: What challenge or decision was at stake
 - **What was done**: The approach taken (and alternatives if visible, including things that didn't work)
-- **Evidence**: Specific file paths and line numbers
-- **Lesson**: The takeaway for other teams
+- **Code**: Copy the actual code lines that show the pattern. Include imports, function signatures, key parameters, the specific arguments used. For example:
+  ```python
+  # src/worker/main.py:160-175
+  async def _progress_callback(job_id: str, progress: float) -> bool:
+      async with async_session_maker() as session:
+          job = await session.get(OptimizationJob, job_id)
+          if job.status == JobStatus.CANCELLED:
+              return True  # signal optimizer to stop
+      return False
+  ```
+- **Lesson**: The takeaway for other teams
+
+Always include real code from files you read — not paraphrases, not "see line 42". The reader should understand the pattern, the function names, the parameters, and the packages used without opening the repo.

{rex_machine-0.2.0 → rex_machine-0.2.2}/src/rex_machine/templates/prompts/config_analyzer.j2

@@ -13,12 +13,21 @@ Look for REX signals in:
 - Cross-platform concerns: does the config handle Windows/Linux/Mac differences?
 - Publishing / deployment: how is the package published? Manual or automated? What triggers a release?
 
-For each finding, cite specific files and line numbers. Configuration choices often reveal hard-won lessons about what went wrong in the past.
-
 FORMAT YOUR OUTPUT AS A LIST OF FINDINGS. For each finding, use this structure:
 
 ### Finding: [short title]
 - **Problem/Context**: What challenge or decision was at stake
 - **What was done**: The approach taken (and alternatives if visible)
-- **Evidence**: Specific file paths and line numbers
-- **Lesson**: The takeaway for other teams
+- **Code**: Copy the actual config/code lines that show the pattern. Include the real values, parameters, package names. For example:
+  ```yaml
+  # .github/workflows/deploy.yml:18-25
+  - name: Build container
+    run: |
+      docker build --target production \
+        --build-arg PYTHON_VERSION=3.12 \
+        --cache-from type=gha \
+        -t {% raw %}${{ env.IMAGE }}:${{ github.sha }}{% endraw %} .
+  ```
+- **Lesson**: The takeaway for other teams
+
+Always include real config/code from files you read — not paraphrases. The reader should see the exact commands, package versions, and settings used.

{rex_machine-0.2.0 → rex_machine-0.2.2}/src/rex_machine/templates/prompts/doc_analyzer.j2

@@ -12,12 +12,19 @@ Look for REX signals in:
 - API documentation: is the external API documented separately from implementation?
 - CHANGELOG/versioning: is there a changelog? Is it maintained?
 
-For each finding, cite specific files and line numbers. A gap in documentation is just as valuable as good documentation — both carry lessons.
-
 FORMAT YOUR OUTPUT AS A LIST OF FINDINGS. For each finding, use this structure:
 
 ### Finding: [short title]
 - **Problem/Context**: What challenge or decision was at stake
 - **What was done**: The approach taken (and alternatives if visible)
-- **Evidence**: Specific file paths and line numbers
-- **Lesson**: The takeaway for other teams
+- **Code**: Copy the actual code or documentation lines that illustrate the finding. For example:
+  ```python
+  # src/core/optimizer.py:45-48
+  # We use DBSCAN instead of K-means here because the number of
+  # annotation clusters is unknown and annotations can have
+  # irregular shapes. eps=15 tuned on the validation set.
+  clusters = DBSCAN(eps=15, min_samples=3).fit_predict(coords)
+  ```
+- **Lesson**: The takeaway for other teams
+
+Always include real code or documentation excerpts — not paraphrases. The reader should see exactly what the codebase does.

{rex_machine-0.2.0 → rex_machine-0.2.2}/src/rex_machine/templates/prompts/structure_analyzer.j2

@@ -11,12 +11,18 @@ Look for REX signals in:
 - Build system: why was this build tool chosen? Are there traces of a previous one?
 - Dependency structure: are deps well-organized? Pinned vs floating? Dev vs prod separation?
 
-For each finding, explain WHAT you observed, WHERE in the code (file paths + line numbers), and WHY it matters as a lesson learned.
-
 FORMAT YOUR OUTPUT AS A LIST OF FINDINGS. For each finding, use this structure:
 
 ### Finding: [short title]
 - **Problem/Context**: What challenge or decision was at stake
 - **What was done**: The approach taken (and alternatives if visible)
-- **Evidence**: Specific file paths and line numbers
-- **Lesson**: The takeaway for other teams
+- **Code**: Copy the actual code lines that show the pattern. Include imports, function signatures, key parameters. For example:
+  ```python
+  # src/api/deps.py:12-18
+  async def get_db_session() -> AsyncGenerator[AsyncSession, None]:
+      async with async_session_maker() as session:
+          yield session
+  ```
+- **Lesson**: The takeaway for other teams
+
+Always include real code from files you read — not paraphrases, not line number references. The reader should understand the pattern without opening the repo.

{rex_machine-0.2.0 → rex_machine-0.2.2}/src/rex_machine/templates/prompts/synthesis.j2

@@ -24,7 +24,7 @@ For each REX item, fill ALL fields:
 - theme: short category (e.g., "Error Handling", "Testing", "Architecture")
 - context: where this applies in the codebase
 - problem: the challenge or decision that was at stake
-- approaches: at least one Approach with description, worked (true/false/null), and details with file evidence
+- approaches: at least one Approach with description, worked (true/false/null), and details that INCLUDE the actual code snippets from the sub-agent reports. Copy the real code — function names, imports, parameters, specific arguments. The reader must understand the pattern without opening the repo.
 - learning: the takeaway
 - recommendation: actionable advice
 - confidence: based on evidence strength