kash-shell 0.3.35__tar.gz → 0.3.37__tar.gz

kash_shell-0.3.37/.claude/.gitignore

@@ -0,0 +1,2 @@
+# Backup files
+*.bak

kash_shell-0.3.37/.claude/hooks/tbd-closing-reminder.sh

@@ -0,0 +1,15 @@
+#!/bin/bash
+# Remind about close protocol after git push
+# Installed by: tbd setup claude
+
+input=$(cat)
+command=$(echo "$input" | jq -r '.tool_input.command // empty')
+
+# Check if this is a git push command and .tbd exists
+if [[ "$command" == git\ push* ]] || [[ "$command" == *"&& git push"* ]] || [[ "$command" == *"; git push"* ]]; then
+  if [ -d ".tbd" ]; then
+    tbd closing
+  fi
+fi
+
+exit 0

kash_shell-0.3.37/.claude/scripts/ensure-gh-cli.sh

@@ -0,0 +1,88 @@
+#!/bin/bash
+# Automated GitHub CLI setup for Claude Code sessions
+# This script runs on SessionStart to ensure gh CLI is available and authenticated
+
+set -e
+
+# Add common binary locations to PATH
+export PATH="$HOME/.local/bin:$HOME/bin:/usr/local/bin:$PATH"
+
+# Check if gh is already installed
+if command -v gh &> /dev/null; then
+    echo "[gh] CLI found at $(which gh)"
+else
+    echo "[gh] CLI not found, installing..."
+
+    # Detect platform
+    OS=$(uname -s | tr '[:upper:]' '[:lower:]')
+    ARCH=$(uname -m)
+    [ "$ARCH" = "x86_64" ] && ARCH="amd64"
+    [ "$ARCH" = "aarch64" ] && ARCH="arm64"
+
+    echo "[gh] Detected platform: ${OS}_${ARCH}"
+
+    # Get latest version from GitHub API (with fallback)
+    GH_VERSION=$(curl -fsSL https://api.github.com/repos/cli/cli/releases/latest 2>/dev/null \
+        | grep -o '"tag_name": *"v[^"]*"' | head -1 | sed 's/.*"v\([^"]*\)".*/\1/')
+
+    # Fallback version if API fails
+    GH_VERSION=${GH_VERSION:-2.83.1}
+
+    echo "[gh] Version: ${GH_VERSION}"
+
+    # Build download URL based on platform
+    if [ "$OS" = "darwin" ]; then
+        DOWNLOAD_URL="https://github.com/cli/cli/releases/download/v${GH_VERSION}/gh_${GH_VERSION}_macOS_${ARCH}.zip"
+        ARCHIVE_EXT="zip"
+    else
+        DOWNLOAD_URL="https://github.com/cli/cli/releases/download/v${GH_VERSION}/gh_${GH_VERSION}_${OS}_${ARCH}.tar.gz"
+        ARCHIVE_EXT="tar.gz"
+    fi
+
+    echo "[gh] Downloading from ${DOWNLOAD_URL}..."
+
+    # Download
+    curl -fsSL -o "/tmp/gh.${ARCHIVE_EXT}" "$DOWNLOAD_URL"
+
+    # Extract based on archive type
+    if [ "$ARCHIVE_EXT" = "zip" ]; then
+        unzip -q "/tmp/gh.zip" -d /tmp
+        EXTRACT_DIR="/tmp/gh_${GH_VERSION}_macOS_${ARCH}"
+    else
+        tar -xzf "/tmp/gh.tar.gz" -C /tmp
+        EXTRACT_DIR="/tmp/gh_${GH_VERSION}_${OS}_${ARCH}"
+    fi
+
+    # Install to ~/.local/bin (works in cloud and local)
+    mkdir -p ~/.local/bin
+    cp "${EXTRACT_DIR}/bin/gh" ~/.local/bin/gh
+    chmod +x ~/.local/bin/gh
+
+    # Clean up
+    rm -rf "${EXTRACT_DIR}" "/tmp/gh.${ARCHIVE_EXT}"
+
+    echo "[gh] Installed to ~/.local/bin/gh"
+fi
+
+# Verify gh is now in PATH
+if ! command -v gh &> /dev/null; then
+    echo "[gh] ERROR: gh CLI still not found in PATH after installation"
+    echo "[gh] Ensure ~/.local/bin is in your PATH"
+    exit 1
+fi
+
+# Check authentication status
+if [ -n "$GH_TOKEN" ]; then
+    # GH_TOKEN is set, verify it works
+    if gh auth status &> /dev/null; then
+        echo "[gh] Authenticated successfully"
+    else
+        echo "[gh] WARNING: GH_TOKEN is set but authentication check failed"
+        echo "[gh] Token may be invalid or expired"
+    fi
+else
+    echo "[gh] NOTE: GH_TOKEN not set - some operations may require authentication"
+    echo "[gh] See: docs/general/agent-setup/github-cli-setup.md"
+fi
+
+exit 0

kash_shell-0.3.37/.claude/scripts/tbd-session.sh

@@ -0,0 +1,77 @@
+#!/bin/bash
+# Ensure tbd CLI is installed and run tbd prime for Claude Code sessions
+# Installed by: tbd setup --auto
+# This script runs on SessionStart and PreCompact
+
+# Get npm global bin directory (if npm is available)
+NPM_GLOBAL_BIN=""
+if command -v npm &> /dev/null; then
+    NPM_PREFIX=$(npm config get prefix 2>/dev/null)
+    if [ -n "$NPM_PREFIX" ] && [ -d "$NPM_PREFIX/bin" ]; then
+        NPM_GLOBAL_BIN="$NPM_PREFIX/bin"
+    fi
+fi
+
+# Add common binary locations to PATH (persists for entire script)
+# Include npm global bin if found
+export PATH="$NPM_GLOBAL_BIN:$HOME/.local/bin:$HOME/bin:/usr/local/bin:$PATH"
+
+# Function to ensure tbd is available
+ensure_tbd() {
+    # Check if tbd is already installed
+    if command -v tbd &> /dev/null; then
+        return 0
+    fi
+
+    echo "[tbd] CLI not found, installing..."
+
+    # Try npm first (most common for Node.js tools)
+    if command -v npm &> /dev/null; then
+        echo "[tbd] Installing via npm..."
+        npm install -g get-tbd 2>/dev/null || {
+            # If global install fails (permissions), try local install
+            echo "[tbd] Global npm install failed, trying user install..."
+            mkdir -p ~/.local/bin
+            npm install --prefix ~/.local get-tbd
+            # Create symlink if needed
+            if [ -f ~/.local/node_modules/.bin/tbd ]; then
+                ln -sf ~/.local/node_modules/.bin/tbd ~/.local/bin/tbd
+            fi
+        }
+    elif command -v pnpm &> /dev/null; then
+        echo "[tbd] Installing via pnpm..."
+        pnpm add -g get-tbd
+    elif command -v yarn &> /dev/null; then
+        echo "[tbd] Installing via yarn..."
+        yarn global add get-tbd
+    else
+        echo "[tbd] ERROR: No package manager found (npm, pnpm, or yarn required)"
+        echo "[tbd] Please install Node.js and npm, then run: npm install -g get-tbd"
+        return 1
+    fi
+
+    # Verify installation
+    if command -v tbd &> /dev/null; then
+        echo "[tbd] Successfully installed to $(which tbd)"
+        return 0
+    else
+        echo "[tbd] WARNING: tbd installed but not found in PATH"
+        echo "[tbd] Checking common locations..."
+        # Try to find and add to path (include npm global bin)
+        for dir in "$NPM_GLOBAL_BIN" ~/.local/bin ~/.local/node_modules/.bin /usr/local/bin; do
+            if [ -n "$dir" ] && [ -x "$dir/tbd" ]; then
+                export PATH="$dir:$PATH"
+                echo "[tbd] Found at $dir/tbd"
+                return 0
+            fi
+        done
+        echo "[tbd] Could not locate tbd after installation"
+        return 1
+    fi
+}
+
+# Main
+ensure_tbd || exit 1
+
+# Run tbd prime with any passed arguments (e.g., --brief for PreCompact)
+tbd prime "$@"

kash_shell-0.3.37/.claude/settings.json

@@ -0,0 +1,47 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .claude/scripts/tbd-session.sh"
+          }
+        ]
+      },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .claude/scripts/ensure-gh-cli.sh",
+            "timeout": 120
+          }
+        ]
+      }
+    ],
+    "PreCompact": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .claude/scripts/tbd-session.sh --brief"
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/tbd-closing-reminder.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

kash_shell-0.3.37/.claude/skills/tbd/SKILL.md

@@ -0,0 +1,254 @@
+---
+allowed-tools: Bash(tbd:*), Read, Write
+description: |-
+  Git-native issue tracking (beads), coding guidelines, knowledge injection, and spec-driven planning for AI agents. Drop-in replacement for bd/Beads with simpler architecture.
+  Use for: tracking issues/beads with dependencies, creating bugs/features/tasks, planning specs, implementing features from specs, code reviews, committing code, creating PRs, loading coding guidelines (TypeScript, Python, TDD, golden testing, Convex, monorepo patterns), code cleanup, research briefs, architecture docs, agent handoffs, and checking out third-party library source code.
+  Invoke when user mentions: tbd, beads, bd, shortcuts, issues, bugs, tasks, features, epics, todo, tracking, specs, planning, implementation, validation, guidelines, templates, commit, PR, pull request, code review, testing, TDD, test-driven, golden testing, snapshot testing, TypeScript, Python, Convex, monorepo, cleanup, dead code, refactor, handoff, research, architecture, labels, search, checkout library, source code review, or any workflow shortcut.
+name: tbd
+---
+<!-- DO NOT EDIT: Generated by tbd setup.
+Run 'tbd setup' to update.
+-->
+
+---
+title: tbd Workflow
+description: Full tbd workflow guide for agents
+---
+**`tbd` helps humans and agents ship code with greater speed, quality, and discipline.**
+
+1. **Beads**: Git-native issue tracking (tasks, bugs, features).
+   Never lose work across sessions.
+   Drop-in replacement for `bd`.
+2. **Spec-Driven Workflows**: Plan features → break into beads → implement
+   systematically.
+3. **Knowledge Injection**: 17+ engineering guidelines (TypeScript, Python, TDD,
+   testing, Convex, monorepos) available on demand.
+4. **Shortcuts**: Reusable instruction templates for common workflows (code review,
+   commits, PRs, cleanup, handoffs).
+
+## Installation
+
+```bash
+npm install -g get-tbd@latest
+tbd setup --auto --prefix=<name>   # Fresh project (--prefix is REQUIRED: 2-8 alphabetic chars recommended. ALWAYS ASK THE USER FOR THE PREFIX; do not guess it)
+tbd setup --auto                   # Existing tbd project (prefix already set)
+tbd setup --from-beads             # Migration from .beads/ if `bd` has been used
+```
+
+## Routine Commands
+
+```bash
+tbd --help    # Command reference
+tbd status    # Status
+tbd doctor    # If there are problems
+
+tbd setup --auto   # Run any time to refresh setup
+tbd prime      # Restore full context on tbd after compaction
+```
+
+## CRITICAL: You Operate tbd — The User Doesn’t
+
+**You are the tbd operator:** Users talk naturally; you translate their requests to tbd
+actions. DO NOT tell users to run tbd commands.
+That’s your job.
+
+- **WRONG**: "Run `tbd create` to track this bug"
+
+- **RIGHT**: *(you run `tbd create` yourself and tell the user it’s tracked)*
+
+**Welcoming a user:** When users ask “what is tbd?”
+or want help → run `tbd shortcut welcome-user`
+
+## User Request → Agent Action
+
+| User Says | You (the Agent) Run |
+| --- | --- |
+| **Issues/Beads** |  |
+| "There's a bug where ..." | `tbd create "..." --type=bug` |
+| "Create a task/feature for ..." | `tbd create "..." --type=task` or `--type=feature` |
+| "Let's work on issues/beads" | `tbd ready` |
+| "Show me issue X" | `tbd show <id>` |
+| "Close this issue" | `tbd close <id>` |
+| "Search issues for X" | `tbd search "X"` |
+| "Add label X to issue" | `tbd label add <id> <label>` |
+| "What issues are stale?" | `tbd stale` |
+| **Planning & Specs** |  |
+| "Plan a new feature" / "Create a spec" | `tbd shortcut new-plan-spec` |
+| "Break spec into beads" | `tbd shortcut plan-implementation-with-beads` |
+| "Implement these beads" | `tbd shortcut implement-beads` |
+| **Code Review & Commits** |  |
+| "Review this code" / "Code review" | `tbd shortcut review-code` |
+| "Review this PR" | `tbd shortcut review-github-pr` |
+| "Commit this" / "Use the commit shortcut" | `tbd shortcut code-review-and-commit` |
+| "Create a PR" / "File a PR" | `tbd shortcut create-or-update-pr-simple` |
+| "Merge main into my branch" | `tbd shortcut merge-upstream` |
+| **Guidelines & Knowledge** |  |
+| "Use TypeScript best practices" | `tbd guidelines typescript-rules` |
+| "Use Python best practices" | `tbd guidelines python-rules` |
+| "Build a TypeScript CLI" | `tbd guidelines typescript-cli-tool-rules` |
+| "Improve monorepo setup" | `tbd guidelines pnpm-monorepo-patterns` or `bun-monorepo-patterns` |
+| "Add golden/e2e testing" | `tbd guidelines golden-testing-guidelines` |
+| "Use TDD" / "Test-driven development" | `tbd guidelines general-tdd-guidelines` |
+| "Convex best practices" | `tbd guidelines convex-rules` |
+| **Documentation** |  |
+| "Research this topic" | `tbd shortcut new-research-brief` |
+| "Document architecture" | `tbd shortcut new-architecture-doc` |
+| **Cleanup & Maintenance** |  |
+| "Clean up this code" / "Remove dead code" | `tbd shortcut code-cleanup-all` |
+| "Fix repository problems" | `tbd doctor --fix` |
+| **Sessions & Handoffs** |  |
+| "Hand off to another agent" | `tbd shortcut agent-handoff` |
+| "Check out this library's source" | `tbd shortcut checkout-third-party-repo` |
+| *(your choice whenever appropriate)* | `tbd list`, `tbd dep add`, `tbd close`, `tbd sync`, etc. |
+
+## CRITICAL: Session Closing Protocol
+
+**Before saying “done”, you MUST complete this checklist:**
+
+```
+[ ] 1. git add + git commit
+[ ] 2. git push
+[ ] 3. gh pr checks <PR> --watch 2>&1 (IMPORTANT: WAIT for final summary, do NOT tell user it is done until you confirm it passes CI!)
+[ ] 4. tbd close/update <id> for all beads worked on
+[ ] 5. tbd sync
+[ ] 6. CONFIRM CI passed (if failed: fix, run tests, re-push, restart from step 3)
+```
+
+**Work is not done until pushed, CI passes, and tbd is synced.**
+
+## Bead Tracking Rules
+
+- Track all task work not done immediately as beads (discovered work, TODOs,
+  multi-session work)
+- When in doubt, create a bead
+- Check `tbd ready` when not given specific directions
+- Always close/update beads and run `tbd sync` at session end
+
+## Commands
+
+### Finding Work
+
+| Command | Purpose |
+| --- | --- |
+| `tbd ready` | Beads ready to work (no blockers) |
+| `tbd list --status open` | All open beads |
+| `tbd list --status in_progress` | Your active work |
+| `tbd show <id>` | Bead details with dependencies |
+
+### Creating & Updating
+
+| Command | Purpose |
+| --- | --- |
+| `tbd create "title" --type task\|bug\|feature --priority=P2` | New bead (P0-P4, not "high/medium/low") |
+| `tbd update <id> --status in_progress` | Claim work |
+| `tbd close <id> [--reason "..."]` | Mark complete |
+
+### Dependencies & Sync
+
+| Command | Purpose |
+| --- | --- |
+| `tbd dep add <bead> <depends-on>` | Add dependency |
+| `tbd blocked` | Show blocked beads |
+| `tbd sync` | Sync with git remote (run at session end) |
+| `tbd stats` | Project statistics |
+| `tbd doctor` | Check for problems |
+| `tbd doctor --fix` | Auto-fix repository problems |
+
+### Labels & Search
+
+| Command | Purpose |
+| --- | --- |
+| `tbd search <query>` | Search issues by text |
+| `tbd label add <id> <label>` | Add label to issue |
+| `tbd label remove <id> <label>` | Remove label from issue |
+| `tbd label list` | List all labels in use |
+| `tbd stale` | List issues not updated recently |
+
+### Documentation
+
+| Command | Purpose |
+| --- | --- |
+| `tbd shortcut <name>` | Run a shortcut |
+| `tbd shortcut --list` | List shortcuts |
+| `tbd guidelines <name>` | Load coding guidelines |
+| `tbd guidelines --list` | List guidelines |
+| `tbd template <name>` | Output a template |
+
+## Quick Reference
+
+- **Priority**: P0=critical, P1=high, P2=medium (default), P3=low, P4=backlog
+- **Types**: task, bug, feature, epic
+- **Status**: open, in_progress, closed
+- **JSON output**: Add `--json` to any command
+
+<!-- BEGIN SHORTCUT DIRECTORY -->
+## Available Shortcuts
+
+Run `tbd shortcut <name>` to use any of these shortcuts:
+
+| Name | Description |
+| --- | --- |
+| agent-handoff | Generate a concise handoff prompt for another coding agent to continue work |
+| checkout-third-party-repo | Get source code for libraries and third-party repos using git. Essential for reliable source code review. Prefer this to web searches or fetching of web pages from github.com as it is far more effective (github.com blocks web scraping from main website). |
+| code-cleanup-all | Full cleanup cycle including duplicate removal, dead code, and code quality improvements |
+| code-cleanup-docstrings | Review and add concise docstrings to major functions and types |
+| code-cleanup-tests | Review and remove tests that do not add meaningful coverage |
+| code-review-and-commit | Run pre-commit checks, review changes, and commit code |
+| coding-spike | Prototype to validate a spec through hands-on implementation |
+| create-or-update-pr-simple | Create or update a pull request with a concise summary |
+| create-or-update-pr-with-validation-plan | Create or update a pull request with a detailed test/validation plan |
+| implement-beads | Implement beads from a spec, following TDD and project rules |
+| merge-upstream | Merge origin/main into current branch with conflict resolution |
+| new-architecture-doc | Create an architecture document for a system or component design |
+| new-guideline | Create a new coding guideline document for tbd |
+| new-plan-spec | Create a new feature planning specification document |
+| new-research-brief | Create a research document for investigating a topic or technology |
+| new-shortcut | Create a new shortcut (reusable instruction template) for tbd |
+| new-validation-plan | Create a validation/test plan showing what's tested and what remains |
+| plan-implementation-with-beads | Create implementation beads from a feature planning spec |
+| precommit-process | Full pre-commit checklist including spec sync, code review, and testing |
+| review-code | Comprehensive code review for uncommitted changes, branch work, or GitHub PRs |
+| review-code-python | Python-focused code review (language-specific rules only) |
+| review-code-typescript | TypeScript-focused code review (language-specific rules only) |
+| review-github-pr | Review a GitHub pull request with follow-up actions (comment, fix, CI check) |
+| revise-all-architecture-docs | Comprehensive revision of all current architecture documents |
+| revise-architecture-doc | Update an architecture document to reflect current codebase state |
+| setup-github-cli | Ensure GitHub CLI (gh) is installed and working |
+| sync-failure-recovery | Handle tbd sync failures by saving to workspace and recovering later |
+| update-specs-status | Review active specs and sync their status with tbd issues |
+| welcome-user | Welcome message for users after tbd installation or setup |
+
+## Available Guidelines
+
+Run `tbd guidelines <name>` to apply any of these guidelines:
+
+| Name | Description |
+| --- | --- |
+| backward-compatibility-rules | Guidelines for maintaining backward compatibility across code, APIs, file formats, and database schemas |
+| bun-monorepo-patterns | Modern patterns for Bun-based TypeScript monorepo architecture |
+| cli-agent-skill-patterns | Best practices for building TypeScript CLIs that function as agent skills in Claude Code and other AI coding agents |
+| commit-conventions | Conventional Commits format with extensions for agentic workflows |
+| convex-limits-best-practices | Comprehensive reference for Convex platform limits, workarounds, and performance best practices |
+| convex-rules | Guidelines and best practices for building Convex projects, including database schema design, queries, mutations, and real-world examples |
+| electron-app-development-patterns | Guidelines for Electron development ecosystems including npm, pnpm, and Bun, with security baselines and framework comparisons |
+| error-handling-rules | Rules for handling errors, failures, and exceptional conditions |
+| general-coding-rules | Rules for constants, magic numbers, and general coding practices |
+| general-comment-rules | Language-agnostic rules for writing clean, maintainable comments |
+| general-eng-assistant-rules | Rules for AI assistants acting as senior engineers, including objectivity and communication guidelines |
+| general-style-rules | Style guidelines for auto-formatting, emoji usage, and output formatting |
+| general-tdd-guidelines | Test-Driven Development methodology and best practices |
+| general-testing-rules | Rules for writing minimal, effective tests with maximum coverage |
+| golden-testing-guidelines | Guidelines for implementing golden/snapshot testing for complex systems |
+| pnpm-monorepo-patterns | Modern patterns for pnpm-based TypeScript monorepo architecture |
+| python-cli-patterns | Modern patterns for Python CLI application architecture |
+| python-modern-guidelines | Guidelines for modern Python projects using uv, with a few more opinionated practices |
+| python-rules | General Python coding rules and best practices |
+| release-notes-guidelines | Guidelines for writing clear, accurate release notes |
+| tbd-sync-troubleshooting | Common issues and solutions for tbd sync and workspace operations |
+| typescript-cli-tool-rules | Rules for building CLI tools with Commander.js, picocolors, and TypeScript |
+| typescript-code-coverage | Best practices for code coverage in TypeScript with Vitest and v8 provider |
+| typescript-rules | TypeScript coding rules and best practices |
+| typescript-sorting-patterns | Deterministic sorting patterns and comparison chains for TypeScript |
+| typescript-yaml-handling-rules | Best practices for parsing and serializing YAML in TypeScript |
+
+<!-- END SHORTCUT DIRECTORY -->

{kash_shell-0.3.35 → kash_shell-0.3.37}/.copier-answers.yml

@@ -1,5 +1,5 @@
 # Changes here will be overwritten by Copier. Do not edit manually.
-_commit: v0.2.14
+_commit: v0.2.19
 _src_path: gh:jlevy/simple-modern-uv
 package_author_email: joshua@cal.berkeley.edu
 package_author_name: Joshua Levy

{kash_shell-0.3.35 → kash_shell-0.3.37}/.cursor/rules/general.mdc

@@ -7,7 +7,7 @@ alwaysApply: true
 
 **Your fundamental responsibility:** Remember you are a senior engineer and have a
 serious responsibility to be clear, factual, think step by step and be systematic,
-express expert opinion, and make use of the user's attention wisely.
+express expert opinion, and make use of the user’s attention wisely.
 
 **Rules must be followed:** It is your responsibility to carefully read these rules as
 well as Python or other language-specific rules included here.
@@ -22,19 +22,19 @@ Therefore:
   confirmation.
 
 - If you can think of a much better approach that the user requests, be sure to mention
-  it. It's your responsibility to suggest approaches that lead to better, simpler
+  it. It’s your responsibility to suggest approaches that lead to better, simpler
   solutions.
 
-- Give thoughtful opinions on better/worse approaches, but NEVER say "great idea!"
-  or "good job" or other compliments, encouragement, or non-essential banter.
+- Give thoughtful opinions on better/worse approaches, but NEVER say “great idea!”
+  or “good job” or other compliments, encouragement, or non-essential banter.
   Your job is to give expert opinions and to solve problems, not to motivate the user.
 
 - Avoid gratuitous enthusiasm or generalizations.
-  Use thoughtful comparisons like saying which code is "cleaner" but don't congratulate
+  Use thoughtful comparisons like saying which code is “cleaner” but don’t congratulate
   yourself. Avoid subjective descriptions.
-  For example, don't say "I've meticulously improved the code and it is in great shape!"
+  For example, don’t say “I’ve meticulously improved the code and it is in great shape!”
   That is useless generalization.
-  Instead, specifically say what you've done, e.g., "I've added types, including
+  Instead, specifically say what you’ve done, e.g., "I’ve added types, including
   generics, to all the methods in `Foo` and fixed all linter errors."
 
 # General Coding Guidelines
@@ -49,17 +49,17 @@ Therefore:
 - DO NOT repeat in comments what is obvious from the names of functions or variables or
   types.
 
-- DO NOT include comments that reflect what you did, such as "Added this function" as
+- DO NOT include comments that reflect what you did, such as “Added this function” as
   this is meaningless to anyone reading the code later.
   (Instead, describe in your message to the user any other contextual information.)
 
-- DO NOT use fancy or needlessly decorated headings like "===== MIGRATION TOOLS ====="
+- DO NOT use fancy or needlessly decorated headings like “===== MIGRATION TOOLS =====”
   in comments
 
 - DO NOT number steps in comments.
   These are hard to maintain if the code changes.
-  NEVER DO THIS: "// Step 3: Fetch the data from the cache"\
-  This is fine: "// Now fetch the data from the cache"
+  NEVER DO THIS: “// Step 3: Fetch the data from the cache”\
+  This is fine: “// Now fetch the data from the cache”
 
 - DO NOT use emojis or special unicode characters like ① or • or – or — in comments.
 

{kash_shell-0.3.35 → kash_shell-0.3.37}/.cursor/rules/python.mdc

@@ -87,7 +87,7 @@ Always use full type annotations, generics, and other modern practices.
 - Use pathlib `Path` instead of strings.
   Use `Path(filename).read_text()` instead of two-line `with open(...)` blocks.
 
-- Use strif's `atomic_output_file` context manager when writing files to ensure output
+- Use strif’s `atomic_output_file` context manager when writing files to ensure output
   files are written atomically.
 
 ## Use Modern Python Practices
@@ -112,7 +112,7 @@ Always use full type annotations, generics, and other modern practices.
 
 - You can run such individual tests with `uv run pytest -s src/.../path/to/test`
 
-- Don't add docs to assertions unless it's not obvious what they're checking - the
+- Don’t add docs to assertions unless it’s not obvious what they’re checking - the
   assertion appears in the stack trace.
   Do NOT write `assert x == 5, "x should be 5"`. Do NOT write `assert x == 5 # Check if
   x is 5`. That is redundant.
@@ -122,7 +122,7 @@ Always use full type annotations, generics, and other modern practices.
   assertions that confirm the value of a constant setting.
 
 - NEVER write `assert False`. If a test reaches an unexpected branch and must fail
-  explicitly, `raise AssertionError("Explanation")` instead.
+  explicitly, `raise AssertionError("Some explanation")` instead.
   This is best typical best practice in Python since assertions can be removed with
   optimization.
 
@@ -132,6 +132,21 @@ Always use full type annotations, generics, and other modern practices.
   This is also preferable because then simple tests have no explicit pytest dependencies
   and can be placed in code anywhere.
 
+- DO NOT write trivial tests that test something we know already works, like
+  instantiating a Pydantic object.
+
+  ```python
+  class Link(BaseModel):
+    url: str
+    title: str = None
+  
+  # DO NOT write tests like this. They are trivial and only create clutter!
+  def test_link_model():
+    link = Link(url="https://example.com", title="Example")
+    assert link.url == "https://example.com"
+    assert link.title == "Example"
+  ```
+
 ## Types and Type Annotations
 
 - Use modern union syntax: `str | None` instead of `Optional[str]`, `dict[str]` instead
@@ -142,7 +157,7 @@ Always use full type annotations, generics, and other modern practices.
 - Use modern enums like `StrEnum` if appropriate.
 
 - One exception to common practice on enums: If an enum has many values that are
-  strings, and they have a literal value as a string (like in a JSON protocol), it's
+  strings, and they have a literal value as a string (like in a JSON protocol), it’s
   fine to use lower_snake_case for enum values to match the actual value.
   This is more readable than LONG_ALL_CAPS_VALUES, and you can simply set the value to
   be the same as the name for each.
@@ -228,7 +243,7 @@ Always use full type annotations, generics, and other modern practices.
 - For classes with many methods, use a concise docstring on the class that explains all
   the common information, and avoid repeating the same information on every method.
 
-- Docstrings should provide context or as concisely as possible explain "why", not
+- Docstrings should provide context or as concisely as possible explain “why”, not
   obvious details evident from the class names, function names, parameter names, and
   type annotations.
 
@@ -240,10 +255,10 @@ Always use full type annotations, generics, and other modern practices.
   name, variable name, or types.
   That is silly and obvious and makes the code longer for no reason.
 
-- Do NOT list args and return values if they're obvious.
+- Do NOT list args and return values if they’re obvious.
   In the above examples, you do not need and `Arguments:` or `Returns:` section, since
-  their meaning as obvious from context.
-  do list these if there are many arguments and their meaning isn't clear.
+  sections as it is obvious from context.
+  do list these if there are many arguments and their meaning isn’t clear.
   If it returns a less obvious type like a tuple, do explain in the pydoc.
 
 - Exported/public variables, functions, or methods SHOULD have concise docstrings.

{kash_shell-0.3.35 → kash_shell-0.3.37}/.github/workflows/ci.yml

@@ -42,7 +42,7 @@ jobs:
         uses: astral-sh/setup-uv@v5
         with:
           # Update this as needed:
-          version: "0.7.13"
+          version: "0.9.5"
           enable-cache: true
           python-version: ${{ matrix.python-version }}
 

{kash_shell-0.3.35 → kash_shell-0.3.37}/.github/workflows/publish.yml

@@ -25,7 +25,7 @@ jobs:
       - name: Install uv (official Astral action)
         uses: astral-sh/setup-uv@v5
         with:
-          version: "0.7.13"
+          version: "0.9.5"
           enable-cache: true
           python-version: "3.12"