shotgun-sh 0.3.3.dev2__tar.gz → 0.3.4.dev1__tar.gz

{shotgun_sh-0.3.3.dev2 → shotgun_sh-0.3.4.dev1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: shotgun-sh
-Version: 0.3.3.dev2
+Version: 0.3.4.dev1
 Summary: AI-powered research, planning, and task management CLI tool
 Project-URL: Homepage, https://shotgun.sh/
 Project-URL: Repository, https://github.com/shotgun-sh/shotgun
@@ -27,7 +27,6 @@ Requires-Dist: dependency-injector>=4.41.0
 Requires-Dist: genai-prices>=0.0.27
 Requires-Dist: httpx>=0.27.0
 Requires-Dist: jinja2>=3.1.0
-Requires-Dist: kuzu>=0.7.0
 Requires-Dist: logfire>=2.0.0
 Requires-Dist: openai>=1.0.0
 Requires-Dist: packaging>=23.0
@@ -35,6 +34,7 @@ Requires-Dist: posthog>=3.0.0
 Requires-Dist: pydantic-ai>=1.26.0
 Requires-Dist: pydantic-settings>=2.0.0
 Requires-Dist: pyperclip>=1.10.0
+Requires-Dist: real-ladybug>=0.12.0
 Requires-Dist: rich>=13.0.0
 Requires-Dist: sentencepiece>=0.2.0
 Requires-Dist: sentry-sdk[pure-eval]>=2.0.0

{shotgun_sh-0.3.3.dev2 → shotgun_sh-0.3.4.dev1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "shotgun-sh"
-version = "0.3.3.dev2"
+version = "0.3.4.dev1"
 description = "AI-powered research, planning, and task management CLI tool"
 readme = "README.md"
 license = { text = "MIT" }
@@ -34,7 +34,7 @@ dependencies = [
     "textual>=6.1.0",
     "textual-dev>=1.7.0",
     "textual-serve>=0.1.0",
-    "kuzu>=0.7.0",
+    "real_ladybug>=0.12.0",
     "tree-sitter>=0.21.0",
     "tree-sitter-python>=0.23.0",
     "tree-sitter-javascript>=0.23.0",
@@ -171,4 +171,4 @@ skip_covered = false
 show_missing = true
 
 [tool.uv.pip]
-only-binary = ["kuzu"]
+only-binary = ["real_ladybug"]

{shotgun_sh-0.3.3.dev2 → shotgun_sh-0.3.4.dev1}/src/shotgun/codebase/core/change_detector.py

@@ -7,7 +7,7 @@ from pathlib import Path
 from typing import Any, cast
 
 import aiofiles
-import kuzu
+import real_ladybug as kuzu
 
 from shotgun.logging_config import get_logger
 

{shotgun_sh-0.3.3.dev2 → shotgun_sh-0.3.4.dev1}/src/shotgun/codebase/core/ingestor.py

@@ -11,7 +11,7 @@ from pathlib import Path
 from typing import Any
 
 import aiofiles
-import kuzu
+import real_ladybug as kuzu
 from tree_sitter import Node, Parser, QueryCursor
 
 from shotgun.codebase.core.language_config import LANGUAGE_CONFIGS, get_language_config

{shotgun_sh-0.3.3.dev2 → shotgun_sh-0.3.4.dev1}/src/shotgun/codebase/core/manager.py

@@ -12,7 +12,7 @@ from pathlib import Path
 from typing import Any, ClassVar
 
 import anyio
-import kuzu
+import real_ladybug as kuzu
 from watchdog.events import FileSystemEvent, FileSystemEventHandler
 from watchdog.observers import Observer
 

{shotgun_sh-0.3.3.dev2 → shotgun_sh-0.3.4.dev1}/src/shotgun/prompts/agents/specify.j2

@@ -50,6 +50,8 @@ specification.md is your prose documentation file. It should contain:
 - Configuration requirements described (e.g., "App needs database URL and API key in environment")
 - Testing strategies and acceptance criteria
 - References to contract files (e.g., "See contracts/user_models.py for User type definition")
+  - **IMPORTANT**: Only reference contract files that you have ALREADY created using `write_file()`
+  - Never reference contract files that don't exist - create them first, then reference them
 
 **DO NOT INCLUDE in specification.md:**
 - Code blocks, type definitions, or function signatures (those go in contracts/)
@@ -355,8 +357,9 @@ For specification tasks:
 2. **Check research**: Read `research.md` if it exists to understand technical context and findings
 3. **Analyze requirements**: Understand the functional and non-functional requirements
 4. **Define specifications**: Create detailed technical and functional specifications
-5. **Write TLDR section**: Start specification.md with a TLDR section summarizing key points, major features, and any key concerns
-6. **Structure documentation**: Use `write_file("specification.md", content)` to save comprehensive specifications
+5. **Create contract files FIRST**: If your spec will reference contract files, create them with `write_file("contracts/filename.ext", content)` BEFORE writing specification.md
+6. **Write TLDR section**: Start specification.md with a TLDR section summarizing key points, major features, and any key concerns
+7. **Structure documentation**: Use `write_file("specification.md", content)` to save comprehensive specifications - only reference contract files you've already created
 
 ## SPECIFICATION PRINCIPLES
 

{shotgun_sh-0.3.3.dev2 → shotgun_sh-0.3.4.dev1}/src/shotgun/prompts/agents/tasks.j2

@@ -27,9 +27,9 @@ NEVER offer to do work outside your scope:
 - This is your persistent memory store - ALWAYS load it first
 - Compress content regularly to stay within context limits
 - Keep your file updated as you work - it's your memory across sessions
-- Archive completed tasks to a compressed section at the bottom
+- Keep completed tasks marked with `[X]` for reference
 - Consolidate similar or duplicate tasks when compressing
-- Maintain structure: Active Tasks → Backlog → Archived (compressed)
+- Maintain structure: Stages with numbered tasks (Stage 1, Stage 2, etc.)
 
 ## AI AGENT PIPELINE AWARENESS
 
@@ -56,9 +56,10 @@ Example task format:
 For task management:
 1. **Load existing tasks**: ALWAYS first use `read_file("tasks.md")` to see what tasks already exist (if the file exists)
 2. **Review context**: Read `plan.md` and `specification.md` if they exist to understand project context
-3. **Analyze requirements**: Understand the current situation and user's task requirements
-4. **Create structured tasks**: Use `write_file("tasks.md", content)` to save organized tasks
-5. **Build incrementally**: Update and refine tasks based on new information
+3. **Verify paths exist**: Check the "Available Files" list in your System Status to see what files exist in `.shotgun/`. If a path doesn't exist, tasks must CREATE it, not modify files within it.
+4. **Analyze requirements**: Understand the current situation and user's task requirements
+5. **Create structured tasks**: Use `write_file("tasks.md", content)` to save organized tasks
+6. **Build incrementally**: Update and refine tasks based on new information
 
 ## TASK FORMAT
 
@@ -69,33 +70,36 @@ For task management:
 
 ## TASK FILE STRUCTURE
 
-Start tasks.md with these instructions:
+**CRITICAL**: Start tasks.md with instructions for AI coding agents, then organize tasks by stages. Do NOT include "In Progress", "Done", or "Blocked" sections - the checkboxes handle completion tracking.
+
 ```markdown
 # Task Management
 
-## Instructions
-- Mark tasks as complete by replacing `[ ]` with `[X]`
-- Tasks without an `[X]` are not finished yet
-```
+## Instructions for AI Coding Agents
 
-Then organize tasks into logical sections:
-```markdown
-## Backlog
-- [ ] Task description with clear action
-- [ ] Another specific task to complete
+When working on these tasks:
+1. Focus on ONE stage at a time, completing all tasks in that stage before moving to the next
+2. Mark each task complete by replacing `[ ]` with `[X]` as you finish it
+3. Do NOT modify any other content in this file unless explicitly instructed by the user
+4. Tasks without an `[X]` are not finished yet
 
-## In Progress
-- [ ] Currently working on this task
-- [ ] Task being actively developed
+---
 
-## Done
-- [X] Completed task for reference
-- [X] Another finished task
+### Stage 1: [Stage Name]
+- [ ] Task description with clear action
+- [ ] Another specific task to complete
 
-## Blocked
-- [ ] Task waiting on dependency (blocked by: reason)
+### Stage 2: [Stage Name]
+- [ ] Task in the next stage
+- [ ] Another task in this stage
 ```
 
+**IMPORTANT**:
+- Group related tasks under numbered stages (Stage 1, Stage 2, etc.)
+- Do NOT create separate "In Progress", "Done", or "Blocked" sections
+- The `[ ]` / `[X]` checkboxes are the ONLY mechanism for tracking completion
+- Each stage should be completable independently before moving to the next
+
 ## TASK CREATION PRINCIPLES
 
 - **ALWAYS use checkbox format `[ ]` for every task**
@@ -145,6 +149,14 @@ INTEGRATION WITH RESEARCH & PLAN:
 - Create validation/testing tasks for success criteria from plan
 - Break down high-level plan steps into granular, executable tasks
 
+PATH VERIFICATION (CRITICAL):
+- Before generating tasks that reference specific file paths in `.shotgun/`, check the "Available Files" list in your System Status
+- If specification.md references files under `.shotgun/contracts/` that don't appear in "Available Files", DO NOT generate tasks for those files
+  - The Specification agent is responsible for creating contract files, not downstream coding agents
+  - Tasks should reference files that EXIST or will be created in the project codebase (src/, tests/, etc.), not in `.shotgun/`
+- Only generate tasks for `.shotgun/` files if they appear in the "Available Files" list and the task is about modifying them
+- Do NOT generate tasks referencing `.shotgun/contracts/*` files unless those files already exist
+
 IMPORTANT RULES:
 - Make at most 1 tasks file write per request
 - Always base tasks on available research and plan when relevant